LLM 추론 라우팅을 위한 Rust 엔트로피 모니터 구축 — 벤치마크 결과 분석

Frontier LLM 추론은 비용이 많이 듭니다. 저는 클라우드 호출이 필요하기 전까지 4B 로컬 모델이 어디까지 갈 수 있는지, 그리고 클라우드 호출이 실제로 언제 가치를 더하는지 확인하고 싶었습니다.

그 결과물은 Buddy System입니다. 이는 Rust 엔트로피 모니터(entropy monitor)가 로컬 생성 중 토큰별 불확실성(uncertainty)을 감시하다가, 로컬 모델이 진정으로 막혔을 때만 Sonnet으로 라우팅하는 계층형 추론 아키텍처(tiered inference architecture)입니다. (Anthropic에 advisor 시스템이 있다는 것은 알고 있지만, 이것은 다릅니다)

GitHub: https://github.com/Manojython/buddy-system

작동 방식

Gemma 3 4B가 MLX를 통해 Apple Silicon에서 로컬로 생성됩니다. Rust EntropyMonitor(PyO3 확장 프로그램으로 컴파일됨)는 생성되는 모든 토큰에 대해 전체 토큰 어휘(vocabulary)에 대한 Shannon 엔트로피(Shannon entropy)를 계산합니다:

// bridge/src/entropy.rs
pub fn token_entropy(&self, logits: &[f32]) -> f32 {
    let max = logits.iter().cloned().fold(f32::NEG_INFINITY, f32::max);
...

높은 엔트로피(high-entropy) 절 경계(임계값: 0.8)에서, spaCy NER은 모델이 무엇에 대해 불확실한지 식별합니다. 단순히 "신뢰도가 낮음"이 아니라, 특정 개체명(named entity)이나 명사구(noun chunk)를 찾아냅니다:

# frugal/uncertainty.py
for ent in doc.ents:
    e = _span_entropy(ent.start_char, ent.end_char)
...

sentence-transformers 리트리버(retriever)가 관련 구절 청크(passage chunk)를 찾습니다. Sonnet은 타겟팅된 쿼리, 즉 불확실한 사실과 근거 문서(grounding document)를 전달받습니다. 모든 클라우드 호출은 로컬 생성이 완료된 후 비동기(async)로 실행되므로, 생성이 API 호출로 인해 차단(block)되지 않습니다.

고전적인 도구들(수학, 날짜, 단위)은 로컬과 클라우드 사이에 위치하여 비용 없이 결정론적(deterministic)인 답변을 처리합니다.

벤치마크 결과

3가지 조건, 7개의 HuggingFace 데이터셋, 총 140개의 샘플:

조건	정확도 (Accuracy)	비용 (Cost)
로컬 전용 (Gemma 3 4B)	70.7%	$0.00
...

데이터셋별 결과:

데이터셋	로컬 (Local)	Buddy	Advisor
AG News	75%	75%	75%
...

흥미로운 발견

흥미로운 발견

Advisor 패턴(Haiku가 생성하고 → Opus가 무조건 검토하는 방식)은 로컬 전용(local-only) 방식과 비교했을 때 SQuAD v2에서 30pp, HotpotQA에서 20pp의 성능 하락을 보였습니다. 그 메커니즘은 다음과 같습니다: 검토(review) 단계에서 Haiku의 답변은 전달받지만, 원문 문서(source document)는 전달받지 못합니다. Opus는 지문(passage)이 아닌 매개변수 메모리(parametric memory)를 바탕으로 수정 작업을 수행합니다.

이는 모델의 능력(capability) 문제가 아닙니다. 검토 계층(review tier)이 어떤 컨텍스트(context)를 전달받느냐의 문제입니다. 검토자에게 문서를 전달하면 결과가 달라지는데, 이것이 바로 Buddy System이 검색(retrieval) 단계를 통해 수행하는 방식과 정확히 일치합니다.