더 빠른 9B 모델을 테스트한 후에도 Ternary Bonsai 2 27B를 유지하게 된 이유

2026년 10월 16일

저희의 프로덕션 분류기는 11 GB VRAM이 장착된 RTX 2080 Ti 단일 GPU에서 실행됩니다. 이 모델은 매우 바쁜 경우가 많아 요청들이 호스팅되는 모델로 넘어가게 됩니다. PrismML이 10월 15일에 Ternary Bonsai 2 9B를 출시했을 때, 저희는 이를 테스트할 실질적인 이유가 있었습니다. 그 이유는 GGUF 파일 크기가 현재 사용 중인 27B의 6.70 GiB에 비해 2.25 GiB로 훨씬 작았기 때문입니다.

저희는 1,015개의 프로덕션 결정을 재현했습니다. 9B 모델은 저희 노트북 벤치마크에서 2.4–3.6배 더 빨랐지만, 두 번째 모델이 확인했던 65건의 에스컬레이션 중 15건을 하향 조정(downgraded)했습니다. 또 다른 작업에서는 답변의 43%가 애플리케이션 규칙과 모순되었습니다.

이는 단순한 교체로는 부족하다는 것을 의미했습니다. 저희가 테스트한 내용과 어떤 부분에서 문제가 발생했는지 알려드립니다.

개선이 필요했던 점

27B 모델은 llama.cpp를 사용하여 PQ2_0 가중치(weights), 두 개의 병렬 슬롯, 그리고 공유되는 32k 컨텍스트로 실행됩니다. 추론(Reasoning) 기능은 비활성화되어 있으며, 응답은 온도(temperature) 0에서 엄격한 json_schema 디코딩을 사용합니다.

요청에는 8초의 클라이언트 마감 시간(client deadline)이 주어집니다. 게이트웨이가 이 예산 내에 슬롯을 제공할 수 없으면 요청을 거부하고, 애플리케이션은 호스팅되는 폴백(fallback) 기능을 사용합니다. 20시간 동안 기록된 9,081개의 요청 중:

가장 바쁜 시간대에는 약 30%가 호스팅 모델로 넘어가게 됩니다. 서비스된 요청은 중앙값(median)이 4.3초, p95가 8.1초의 모델 시간을 소요했습니다. 더 빠른 모델을 사용하면 대기 및 폴백 비용을 모두 줄일 수 있습니다.

이 애플리케이션은 비공식적이고 영어 외의 게시물에 대해 세 가지 판단을 내립니다. 각 요청에는 현재 게시물과 스레드 내에서 최대 11개의 이전 게시물이 포함됩니다. 중앙값 프롬프트 길이는 약 0.7k에서 2.3k 토큰 범위이며, 응답은 JSON 형식으로 64–96 토큰으로 제한됩니다.

테스트 방법 (How we tested)

우리는 드문 결과들이 잘 표현되도록 현재 프롬프트 버전에서 기록된 결정들을 샘플링했습니다:

weight = (stratum의 행 수 / 샘플링된 행 수) × (1 / 로깅 확률)

Task A 샘플은 약 68k개의 생산 검사를 나타냅니다.

우리는 저장된 게시물과 스레드 창을 사용하여 애플리케이션 자체의 프롬프트 빌더로 요청들을 재구축했으며, 동일한 스키마, 토큰 제한 및 온도 값을 사용했습니다. 프롬프트 토큰 수는 우리가 확인한 모든 275개 사례에서 생산 환경과 일치했습니다.

재현은 llama.cpp를 사용하는 M1 Max에서 생산 서버 플래그로 실행되었습니다. 27B는 우리의 생산 빌드인 prism-b10709를 사용했고, 9B는 prism-b10777가 필요했습니다.

우리는 이미 27B의 기록된 답변을 가지고 있었기 때문에, 무작위 제어 서브셋과 모든 Task A 및 C 불일치 사례에 대해서만 275개 사례에서 재실행했습니다. 이는 275개 생산 결정 중 273개를 재현했습니다. 두 가지 경계상의 차이는 Metal/CUDA 수치적 차이를 반영할 수 있습니다. 이 확인 과정을 통해 우리는 두 번째 전체 실행을 요구하지 않고도 재현에 대한 신뢰를 얻었습니다.

Task A: 명확한 결정이 적고, 에스컬레이션 누락

가장 중요했던 것은 하향 조정된 15개의 '확인된 에스컬레이션'이었습니다. 27B 모델은 로컬 재실행에서 이 15개 사례를 모두 escalate로 재현했습니다. 그중 12개는 가장 심각하고 명시적인 서브타입을 가졌고, 3개는 비유적 언어(figurative-language) 서브타입을 가졌습니다. 반면, 9B 모델은 이 15개 사례 모두에 낮은 심각도의 서브타입을 할당했으며 자체 보고된 신뢰도는 0.85–0.9였습니다. 따라서 신뢰도 임계값으로는 이를 포착할 수 없었습니다.

저희는 또한 이러한 사례들을 직접 검토했습니다. 약 1112개는 명확하게 긍정적이었고, 34개는 애매한(borderline) 경우였습니다. 일부는 핵심 신호를 직접 언급했고, 다른 일부는 은유나 관용구(idiom)를 사용했습니다. 이것은 전문가 주석(expert annotation)이 아닌 비공식적인 검토였습니다.

더 광범위한 변화는 clarify 쪽으로 기울었습니다. 생산량 기준으로 재가중하면 다음과 같습니다:

또한 확인된 사례가 누락되었음에도 불구하고 가중치 에스컬레이션 비율을 두 배로 늘렸습니다. clarify 계층에서만 나온 새로운 에스컬레이션들은 기록 기간 동안 약 180개의 호스팅 모델 검토를 추가할 것입니다.

Task B: 유효한 JSON, 모순되는 답변

총 350개의 답변 중 151개(43%)에서 9B는

저희의 JSON 스키마가 이를 허용합니다. 프롬프트는 모델에게 사용하지 말라고 지시했습니다. 27B 모델은 저희의 제어 실행(control runs)에서 그 지침을 따랐습니다. 하지만 9B 모델은 자주 그렇지 못했습니다. 제약 디코딩(Constrained decoding)이 JSON 파싱 가능하게 유지했지만, 스키마에서 제외했던 관계를 강제할 수는 없었습니다.

긍정적인 경우의 유효한 답변들 사이에서도 일치율은 47개 중 23개에 불과했습니다. 가중치를 재조정(reweighting)한 후에도 모든 Task B 검사의 약 17%가 유효성 검사에서 실패하여 호스팅된 폴백(hosted fallback)으로 넘어가게 되었고, 이는 우리가 줄이고 싶었던 부하를 증가시켰습니다.

Task C: 더 나은 일치율, 제한적인 증거

9B 모델은 27B 모델이 플래그 지정하거나 긴급하다고 표시했던 103개 사례 중 91개에서 일치했습니다 (88.3%). 불일치 항목에는 none으로 떨어진 다섯 개의 플래그 지정된 사례와 flagged로 떨어진 세 개의 긴급 사례가 포함되었습니다.

저희에게는 오직 다섯 개의 none 사례만 있었기 때문에, 거짓 양성(false positives)을 추정하기에는 너무 적었습니다. 이 태스크는 저희에게 걱정할 만한 이유를 덜 주었지만, 동시에 증거도 훨씬 적게 주었습니다.

얼마나 더 빠를까?

저희는 플래시 어텐션(flash attention)이 활성화된 M1 Max에서 llama-bench를 실행했습니다. 또한 빌드 자체로 이 성능 향상이 설명되는지 확인하기 위해 27B 모델을 새로운 런타임(runtime)에서도 테스트했습니다.

The production 2080 Ti measures 749 tok/s for prefill and 42.6 tok/s for generation with the 27B. Applying the laptop speed ratios suggests checks might take about 1.5–2 s instead of 4.3 s. We have not measured the 9B on that GPU, so this remains an estimate.

다음으로 시도할 것들

이 테스트는 기존 프롬프트로 9B 모델이 27B 모델을 대체할 수 있는지에 대한 답을 제공합니다. 이것이 더 작은 모델이 할 수 있는 최고의 성능을 알려주는 것은 아닙니다. 저희는 27B를 위해 해당 프롬프트를 조정했고, 두 모델 모두에서 추론(reasoning) 기능을 비활성화했으며, 한 언어와 하나의 도메인에 대해 테스트했습니다. 또한 전체 정밀도(full-precision) Qwen3.5 9B를 실행하지 않았기 때문에, 모델 크기의 영향과 테너 양자화(ternary quantisation)를 분리할 수 없습니다.

테스트할 만한 첫 번째 변경 사항은 Task B의 출력 스키마입니다. 불리언(boolean)과 액션(action)을 하나의 열거형(enum)으로 병합하면 모순되는 조합을 불가능하게 만들 수 있습니다. 그러면 9B 모델에 대한 프롬프트를 조정하고 동일한 케이스를 재현할 것입니다. 작은 추론 예산(reasoning budget)도 속도의 일부를 희생하는 대가로 도움이 될 수 있습니다.

또 다른 가능성은 9B 모델을 Task A의 첫 번째 통과(first pass)에 사용하는 것이며, 그 결과 중 allow가 아닌 답변들을 27B 모델로 전송하는 것입니다. 이 샘플에서는 더 큰 모델이 전체 운영 검사(production checks)의 약 절반에 대해 건너뛰게 되어, 27B 모델의 clarify 케이스 중 대략 6%만 통과시키고 에스컬레이션(escalations)은 전혀 보내지 않습니다. 저희는 이것을 파이프라인으로 테스트한 적이 없습니다. 두 모델을 11GB 카드에 올리는 것은 빠듯할 것이며, 두 번째 단계(second hop)가 지연 시간(latency)을 추가할 것입니다.

현재로서는 27B 모델을 유지합니다. 운영 트래픽을 재현해 본 결과 이 결정은 간단했습니다. 속도 향상은 실제로 있었지만, 놓친 에스컬레이션 또한 마찬가지였습니다. 어떤 대체 모델이든 동일한 테스트를 거쳐야 하며, 확인된 긍정 사례(confirmed positives)에서는 누락이 없어야 하고, 잘못된 답변의 증가가 없어야 합니다.