안녕하세요 HN 여러분, Cactus의 Henry와 Roman입니다. 소규모 온디바이스 모델 (on-device model)은 빠르고 프라이버시 보호에 유리하지만 때때로 틀릴 수 있으며, 프론티어 모델 (frontier models)은 비용이 매우 빠르게 상승하고 있습니다. 그래서 저희는 Gemma 4 E2B가 자신이 언제 틀리는지 알 수 있도록 사후 학습 (post-trained) 시켰습니다. 모든 응답에는 0과 1 사이의 신뢰도 점수 (confidence score)가 함께 제공됩니다. 개발자는 신뢰도가 높을 때는 온디바이스 모델을 수용하고, 낮을 때는 더 큰 클라우드 모델로 작업을 넘길 수 있습니다. 쿼리의 15-35%만을 Gemini 3.1 Flash-Lite로 라우팅함으로써, Gemma-4-E2B는 대부분의 벤치마크에서 Gemini 3.1 Flash-Lite와 대등한 성능을 보여줍니다. - ChartQA: 15-20% - LibriSpeech: 25-30% - MMBench, GigaSpeech, MMAU: 30-35% - MMLU-Pro: 45-55% 저희는 하이브리드 앱이 의존하는 라우팅 신호들에 항상 좌절감을 느껴왔습니다. 모델에게 텍스트로 스스로를 평가하도록 요청하는 방식(신뢰할 수 없으며 산문을 파싱해야 함)이나, 토큰 엔트로피 (token entropy) 휴리스틱(저희 테스트 결과 동전 던지기보다 나을 게 거의 없음) 같은 방식 말이죠. 그래서 저희는 소규모 모델, 특히 Gemma 4에 대해 기계론적 연구 (mechanistic studies)를 수행했고, 서로 다른 레이어의 은닉 상태 (hidden state)가 다양한 상황에 대해 의미 있는 자기 인식 (self-awareness) 신호를 운반한다는 것을 발견했습니다. 이에 따라 저희는 68k 파라미터의 프로브 레이어 (probe layer) (LayerNorm, 저차원 투영 (low-rank projection), 어텐션 풀링 (attention pooling), 소형 MLP 헤드 구성)로 모델을 확장했습니다. 이 레이어는 디코딩 (decoding) 중에 하나의 중간 레이어를 읽어 p(wrong)을 예측합니다. 신뢰도 (confidence) = 1 - p(wrong)으로 계산되며, 구조화된 데이터 (structured data)로 반환되므로 답변 텍스트에서 파싱할 필요가 없습니다. 텍스트, 비전 (vision), 오디오 (audio)를 아우르는 12개의 홀드아웃 벤치마크 (hold-out benchmarks) 전반에서, 이 프로브는 토큰 엔트로피의 0.549 AUROC 대비 평균 0.814 AUROC를 기록했습니다. 이것이 실제임을 확신하게 만든 결과는 다음과 같습니다: 이 프로브는 오디오 데이터를 전혀 학습하지 않았음에도 불구하고, 엔트로피가 무작위 수준이거나 그보다 못한 (0.32-0.52) 4개의 오디오 벤치마크에서 0.79-0.88 AUROC를 기록했습니다. 이는 프로브가 훈련 데이터의 패턴을 암기하는 것이 아니라, 은닉 상태로부터 양식 독립적인 (modality-independent) 정확성 신호를 읽어내고 있음을 의미합니다. 저희는 모든 가중치 (weights)를 HuggingFace에 공개했으며, Transformers, MLX, Llama.cpp 또는 Cactus에서 실행할 수 있는 복사-붙여넣기 가능한 코드를 제공합니다. Ollama, vLLM, SGLang 등도 작업 중입니다. llama.cpp의 경우, 한 번 컴파일하면 되는 패치 시리즈를 제공합니다 (업스트리밍 (upstreaming) 계획 중입니다).

코드는 MIT 라이선스이며, Gemma 모델 사용은 Gemma 약관의 적용을 받습니다. GitHub: https://github.com/cactus-compute/cactus-hybrid Weights: https://huggingface.co/collections/Cactus-Compute/cactus-hyb... 몇 가지 주의 사항: - 프로브 (probe)는 생성된 첫 1024개 토큰까지의 단일 시퀀스 디코딩 (single-sequence decoding)만을 점수화합니다. - 핸드오프 (Handoff)는 단계별 (per step)이 아닌, 다단계 프로세스 내에서 작업별 (per task)로 라우팅할 때 가장 잘 작동합니다. - 계층적 라우팅 (Hierarchical routing)은 아직 개발 중입니다: Fable/GPT5.5/Gemini/Muse/Grok을 사용하기 전에 온디바이스 (on-device), 그 다음 DeepSeek v4 Flash를 시도해 보세요. - 이 기술은 각 모델에 맞춤형 (boutique)으로 제작되었으며, 각 가중치 (weights)가 출시되는 대로 공유할 예정입니다. 이러한 문제들은 현재 Cactus에서 해결 중이며, 업데이트된 가중치는 HuggingFace 컬렉션과 GitHub 저장소에 즉시 배포될 것입니다. 여러분의 의견을 알려주세요. 설계를 점진적으로 개선하는 데 큰 도움이 됩니다. 정말 감사합니다! /u/Henrie_the_dreamer 제출 [link] [comments]