Ternary Bonsai 2 27B: 5.9 GB에 들어가는 것, 그리고 98.2%가 말해주지 않는 것

Ternary Bonsai 2 27B는 Prism ML이 2026년 9월 17일에 발표한 273억 6천만 개의 파라미터를 가진 멀티모달 언어 모델이며, 이에 대해 이해해야 할 점은 그 언어 가중치가 정확히 세 가지 값 중 하나를 취한다는 것입니다. 그 기본 모델은 Qwen3.8 27B, 즉 27B 하이브리드 어텐션 모델이며, Bonsai는 그 아키텍처와 훈련, 그리고 그 형태를 유지하고, 언어 모델의 행렬 가중치를 삼진 표현으로 대체합니다. 배포된 파일은 5.93GB입니다. 전체 정밀도 참조 모델은 53.81GB입니다. 공급업체의 주요 주장은 원본의 벤치마크 평균의 98.2%를 유지한다는 것입니다.

가장 많은 보도가 그냥 지나칠 부분부터 시작하자: 그 98.2%는 Prism ML 자체 수치이며, Prism ML 자체의 20개 벤치마크 스위트에서, Prism ML 자체 하네스로 측정한 것이고, 회사 외부의 누구도 이를 재현하지 못했다. 이는 비난이 아니다 — 출시 하루 만에 나타나는 정상적인 상황이며, 바로 그런 지위를 부여해야 한다. 오늘 독립적으로 검증할 수 있는 것은 파일이다: Hugging Face API는 Ternary-Bonsai-2-27B-PTQ1_0.gguf를 FP16 참조 모델의 53.808 GB에 대해 5.947 GB로 표시하는데, 이는 9.05배 감소이며 누구를 믿을 필요 없이 벤더의 "대략 9배"와 일치한다. 크기는 사실이다. 품질 유지는 벤더의 측정치다. 흥미로운 내용은 그 사이에 있다 — 압축이 공짜인 곳과 그렇지 않은 곳을 정확히 보여주는 카테고리별 분석이다.

이번 릴리스에는 또 다른 얼굴도 있습니다. 9월 18일, 발표 하루 뒤에 OrcaRouter는 같은 모델의 런타임 어블리터레이션 변형을 공개했습니다 — OrcaRouter Ternary Bonsai 2 27B Uncensored — 이 변형은 추론 시점에 학습된 거부 방향을 제거하고 가중치는 비트 단위로 동일하게 유지합니다. 이는 아래의 별도 섹션에서 다루는데, 그 기법이 흥미로운 부분이고 그 한계가 결과만큼이나 교훈적이기 때문입니다.

이는 새로 학습된 모델이 아니라 압축된 Qwen3.8 27B입니다.

이 구분은 릴리스에 대해 설명하는 것과 보도자료를 그대로 반복하는 것 사이의 차이입니다. Prism ML은 27B 모델을 처음부터 학습하지 않았고 새로운 사전 학습 레시피를 실행하지도 않았습니다. 그것이 한 일은 Qwen3.8 27B를 가져와 가중치가 저장되고 계산되는 수치 표현을 바꾼 것입니다.

아키텍처는 변경되지 않았으며, 기본 모델의 아키텍처입니다: 대략 75% 선형 어텐션과 25% 전체 어텐션으로 구성된 하이브리드 어텐션 설계에 SwiGLU MLP 블록, RoPE, RMSNorm을 사용합니다. 이러한 하이브리드 백본은 262K 토큰 컨텍스트가 단순히 지원되는 것이 아니라 전체 컨텍스트를 처리할 수 있다고 설명되는 이유이기도 합니다 — 대부분 선형인 어텐션이 바로 기기에서 긴 컨텍스트를 감당 가능하게 유지하는 요소입니다. 이 모델은 비전-언어 모델입니다: 텍스트뿐 아니라 이미지도 입력으로 받으며, 비전 타워는 기본 제공되는, 양자화되지 않은 Qwen 타워로 별도로 패키징됩니다.

Prism ML이 기여한 것은 두 가지다. 첫째는 삼진 표현 자체와, 그것이 버틸 수 있게 해 주는 양자화 인식 학습이다. 둘째는 커널, 즉 Apple Silicon과 CUDA에서 그 하이브리드 어텐션 스택을 위한 맞춤형 저비트 커널이며, 이는 FP16으로 언패킹해 곱하는 대신 패킹된 가중치를 직접 연산한다. 두 번째 기여가 없다면 첫 번째는 빠른 속도로 사용할 방법이 없는 저장 형식에 불과하다.

Prism ML의 자체 백서에서는 파라미터 분할을 언어 백본에 64개 블록에 걸쳐 24.35B, 임베딩과 LM 헤드에 2.54B, 27개 블록으로 구성된 비전 타워에 0.47B로 보고하며, 총 27.36B입니다. 비전 타워는 진정으로 별개의 아티팩트인 유일한 부분입니다. GGUF 릴리스는 이를 약 0.63GB의 4비트 mmproj 파일로 패키징하며, 실제로 이미지가 도착할 때만 로드되므로 텍스트 전용 서빙에서는 이를 전혀 포함하지 않습니다.

이것은 같은 연구소에서 나온 2세대 Bonsai입니다. 첫 Bonsai 27B는 약 두 달 앞선 2026년 7월에 등장했으며, 두 세대 간의 비교는 충분히 타당한 질문입니다. 이는 여기서 중복해 다루기보다는 Bonsai 27B와의 정면 대결에서 다룹니다.

"ternary g128"이 구체적으로 무엇을 의미하는가

전에 삼진 가중치를 접해 본 적이 없다면, 이 문단이 다른 모든 내용을 이해할 수 있게 해 주는 문단입니다. 그래서 축약 없이 여기 그대로 옮깁니다.

신경망에서 일반적인 가중치는 16비트 부동소수점 수입니다 — 유용한 범위에서 약 65,536개의 구별 가능한 값을 가지며, 각각을 저장하는 데 16비트가 듭니다. 삼진 가중치는 작은 부동소수점 수가 아닙니다. 그것은 세 가지 기호 중 하나를 선택하는 것입니다: −1, 0, 또는 +1. 그것이 전체 어휘입니다. 그러한 기호 하나를 단순하게 저장하면 가중치당 2비트를 쓰게 되는데, 2비트는 네 가지 상태를 주지만 필요한 것은 세 가지뿐이기 때문입니다.

그 자체만으로는 표현력의 치명적인 손실이 될 것이며, 그래서 이 포맷은 결코 기호만으로 이루어지지 않는다. 연속된 128개 가중치의 각 그룹은 하나의 FP16 스케일 팩터를 공유하고, 실제 가중치 값은 삼진 기호에 해당 스케일을 곱한 값이다:

• w = ssub>g/sub> · t, 여기서 t ∈ {−1, 0, +1}이고, ssub>g/sub>는 128개로 구성된 그룹에 대한 하나의 공유 FP16 스케일입니다.

그래서 모델은 여전히 넓은 범위의 크기를 표현합니다 — 다만 가중치별 단계가 아니라 거칠고 그룹 단위의 단계로 표현할 뿐입니다. 0은 반올림 부산물이 아니라 실제 세 번째 상태이며, 이것이 있어야 128개 가중치로 이루어진 그룹이 필요할 때 대부분 조용할 수 있습니다.

회전된 기저가 사람들을 놀라게 하는 부분이다. 삼진 할당이 이루어지기 전에, 각 가중치 행렬은 블록 단위로 직교 회전 — 월시–아다마르 행렬에 고정된 ±1 부호의 대각선을 결합한 것으로, 블록 크기는 1024 — 을 통해 변환되며, 삼진 값은 바로 그 회전된 공간에서 선택된다. 회전은 준비 단계에서 저장되는 가중치 안에 접혀 들어가므로 추가 비트도, 추가 가중치 트래픽도 들지 않는다. 추론 시에는 런타임이 대응하는 변환을 활성값에 대신 적용하며, 패킹된 모델은 메타데이터에 자신의 회전을 명시하므로 런타임은 대응하는 변환을 적용하거나 아니면 파일 로드를 거부한다.

왜 굳이 이걸 하냐고? 하다마드 회전이 가중치 행렬의 에너지를 좌표 전반에 더 고르게 분산시켜 주기 때문에, 이어지는 3레벨 양자화가 가공되지 않은 뾰족한 분포에 적용할 때보다 훨씬 덜 손상적이기 때문이다. 이 회전은 장식이 아니다. 삼진 모델이 부모 모델의 품질에 그나마 근접한 무언가를 유지할 수 있는 이유가 바로 이것이다. 대가는 변환이 배치 크기 1에서 모든 프로젝션의 임계 경로에 놓인다는 점이며, 이는 실제 엔지니어링 문제다 — Prism ML은 Metal에서 부호 반전을 변환의 로드 경로에 융합하고 CUDA에서는 이를 전체 스레드 블록에 걸쳐 병렬화하여 이것이 디코드를 지배하지 않게 한다.

숫자를 주의 깊게: 1.585, 1.71, 1.72, 1.76

이번 릴리스와 관련해 네 가지 비트 폭 수치가 떠돌고 있습니다. 모두 정확하며, 각각 서로 다른 네 가지를 측정한 값입니다. 이들을 혼동하는 것이 이 사안에서 단연 가장 범하기 쉬운 실수입니다. 다음은 각 수치와 그것이 실제로 포괄하는 내용입니다.

• 가중치당 1.585비트 — 삼진 기호 하나의 정보량, log₂3입니다. 이는 포맷의 속성이지, 어떤 파일의 속성도 아닙니다. 출시된 어떤 것도 1.585비트/가중치로 실행되지 않습니다.

• 가중치당 1.71비트 — 삼진 텐서만 해당한다. 128개 가중치에 분산시킨 16비트 FP16 그룹 스케일을 더하면 log₂3 + 16/128 ≈ 1.71이 된다. 이는 아직 출시된 수치가 아니며, 삼진 텐서만을 따로 떼어낸 값이다.

• 가중치당 1.72비트 — 언어 모델의 모든 파라미터를 포함하며, 저비트 표현 위에 유지되는 소규모 집합도 포함합니다. Prism ML은 26,238,464개의 파라미터 — 언어 모델의 0.0976%, bf16에서 약 52 MB — 를 더 높은 정밀도로 유지하며, 대부분 선형 어텐션 레이어의 순환 상태 경로와 정규화 가중치입니다. 이 텐서들은 회전되지도 양자화되지도 않으며, 바로 이들이 수치를 1.71에서 1.72로 이동시킵니다. 1.72에서 이상적인 풋프린트는 5.80 GB이며, 약 9.3배 감소입니다. 이것은 Prism ML의 "True Ternary" 행이며, 다운로드하는 파일이 아니라 목표입니다.

• 가중치당 1.76비트 — 실제 배포된 GGUF입니다. 효율적인 커널에는 패킹 형식이 필요하며, Prism ML의 PTQ1_0은 트리트를 조밀하게 패킹하여 5.93GB에서 가중치당 1.76비트, 약 9.1배를 달성합니다. 이 파일은 발표에서 인용된 "5.9GB"와 "9배 더 작음" 둘 모두의 근거가 되는 파일이며, 위 측정값이 이를 확인해 줍니다.

두 번째 패킹은 PQ2_0이며, 각 트릿을 조밀하게 저장하지 않고 2비트 슬롯에 저장합니다. 더 저렴한 언패킹을 위해 더 많은 공간을 차지합니다: 7.25GB에서 2.16비트/가중치, 약 7.4배입니다. 어느 패킹도 일률적으로 더 빠르지는 않습니다 — PTQ1_0은 스텝당 가중치 데이터를 약 18% 덜 이동하지만 조밀한 트릿을 언패킹하는 산술 비용을 치르므로, 메모리가 병목 제약인 Ada 세대 카드와 L4에서는 이기고, 배치 1 디코딩이 대신 명령 처리량에 제한되는 Hopper, Blackwell, Apple 실리콘에서는 집니다. 프롬프트 처리는 연산 집약적이므로 어디서나 PQ2_0에 유리합니다.

이것들을 출처와 대조해 확인하려는 분들을 위한 두 가지 참고 사항. 첫째, Prism ML 자체 문서에서는 반올림이 약간 다릅니다 — 백서의 저장 표에서는 PTQ1_0을 5.93GB에서 1.76비트/가중치로 제시하는 반면, Hugging Face의 GGUF 모델 카드에서는 1.75와 5.95GB로 제시하며, 측정된 파일은 5.947GB입니다. 이는 동일한 파일을 서로 다른 정밀도로 설명한 것이지, 실질적인 내용에 대한 불일치가 아닙니다. 둘째, 발표된 "9배 이상" 감소는 공급업체가 제시한 것입니다. 실제 파일을 기준으로 측정하면 53.808 / 5.947 = 9.05배이며, 이는 일관됩니다.

벤치마크 그림: 평균이 아니라, 그 형태

헤드라인은 평균 83.9로, Qwen3.8 27B FP16 베이스라인의 85.4와 비교되며 이는 98.2%입니다. 그 평균은 그중에서 가장 흥미롭지 않은 부분입니다. 그 밑에 깔린 형태야말로 진짜 정보가 있는 곳이며, 그것은 균일하지 않습니다.

• 지시 수행 — 82.66 대 81.25. 압축된 모델이 전체 정밀도 원본 모델을 앞서는 유일한 범주입니다. 이는 누구나 대수롭지 않게 설명해 넘길 수 있는 잡음이 아닙니다. 공급업체 자체 스위트에서 거둔 범주 승리입니다.

• 수학 — 96.57 대 97.06, 코딩 — 81.58 대 82.17. 둘 다 사실상 동일한 수준입니다. 카테고리 평균에서 0.5점, 0.6점 차이입니다. 풋프린트가 9분의 1인 모델로서, 이 결과들이 바로 이 기법 전체가 논의되는 근거입니다.

• 지식과 추론 — 83.95 대 86.66. 2.7점 하락이며, 전체 평균에서 사라진 1.8점 중 상당 부분이 바로 여기에 있습니다.

• 비전 — 78.59 대 81.64. 3.05포인트 하락으로, 단일 범주 가운데 가장 큰 손실입니다. 주목할 만한 점은 비전 타워 자체가 압축된 부분이 아니라, 그 출력을 읽는 언어 모델이 압축된 부분이라는 것입니다.

• 에이전트 및 도구 호출 — 77.57 대 79.74. 카테고리 평균에는 τ 2-Bench 80.22와 BFCL v3 74.92가 포함됩니다.

개별 결과는 알아 둘 가치가 있다. 모두 같은 방향을 가리키지는 않기 때문이다. Terminal-Bench 2.1에서 이 모델은 풀 정밀도의 69.7 대비 52.8점을 기록해 대략 4분의 3 수준이며, SWE-bench Verified에서는 80.6 대비 60.8점으로 역시 약 4분의 3 수준이다. 이 모델 제품군이 Terminal-Bench에서 평가된 것은 이번이 처음이며, Prism ML은 첫 Bonsai 릴리스에서 약속했던 장기적 소프트웨어 엔지니어링 개선이 완전하지 않고 부분적이라고 분명히 밝힌다. 그와 대조적으로 τ 2-Bench는 이전 릴리스의 73.6에서 80.2로 상승했고, BFCL v3는 74.9를 유지하며, AA-LCR은 풀 정밀도와 1점 이내인 77.0에 머문다. AIME26은 95.83, LiveCodeBench는 90.07을 기록한다.

어디를 신뢰하고 어디를 신뢰하지 말아야 하는가. 수학, 코딩, 지시 수행에서 나타나는 양상은 신뢰하라 — 그 범주들은 이 기법이 주장하는 바를 입증 가능하게 수행하고 있는 분야이며, 기준선과 동일한 하네스에서 측정된다. 장기적 지평의 에이전트 작업은 주의하라: 지속적인 도구 기반 엔지니어링을 실제로 압박하는 두 벤치마크인 Terminal-Bench 2.1과 SWE-bench Verified는 종합 수치가 시사하는 것보다 실질적으로 더 큰 격차를 보이며, 공급업체도 이를 숨기지 않고 말한다. 그리고 다른 누군가가 실행하기 전까지는 전체 표를 한 연구소가 한 하네스에서 측정한 결과로 취급하라. 이 단서 조항은 여기서 형식적인 것이 아니다 — 그것은 "이 모델이 98.2%를 유지한다"와 "이 모델의 공급업체가 공급업체가 고른 모음에서 98.2%를 측정했다"의 차이다. 둘 다 사실이다; 오직 하나만이 모델에 관한 사실이다.

왜 이것이 동일한 베이스 모델의 IQ2_XXS 빌드보다 나은가

이는 단순한 한 줄이 아니라 독자적인 섹션을 차지할 만한데, 양자화 인식 삼진 훈련이 훈련 후 양자화보다 우월하다는 전체 논거를 이루기 때문이다.

Qwen3.8 27B를 작게 만드는 일반적인 방법은 훈련 후 양자화하는 것입니다. 백서의 비교 지점은 동일한 기본 모델의 IQ2_XXS GGUF 빌드입니다:

• Ternary Bonsai 2 27B — 1.76비트/가중치, 5.93GB, 20개 벤치마크 평균 83.9

• Qwen3.8 27B IQ2_XXS — 가중치당 2.2비트, 7.3GB, 20개 벤치마크 평균 75.2

훈련으로 압축된 모델은 더 작고 더 우수합니다. 기존 저비트 빌드보다 1.23배 더 작고 8.7점 더 높은 점수를 기록합니다. 이 조합은 단순히 반올림에서 비롯된 흥미로운 현상이 아닙니다. 그것은 훈련 중 선택된 표현이 이후에 적용된 동일한 명목 비트 예산보다 상당히 더 가치 있다는 주장입니다.

더 교훈적인 부분은 어떻게 기존 빌드가 실패하는지입니다. 실패가 선택적이고 놓치기 쉽기 때문입니다. IQ2_XXS는 고르게 성능이 저하되지 않습니다. 표면적 지식에서는 버팁니다 — MMLU-Redux에서 85.79 — 반면 지속적인 추론 연쇄가 필요한 작업에서는 무너집니다: AIME26에서 78.6, LiveCodeBench에서 70.05, GPQA Diamond에서 65.45입니다. Bonsai 2는 같은 세 작업에서 95.83, 90.07, 85.76을 기록합니다. 가벼운 잡담 테스트에서는 IQ2_XXS 빌드를 아주 쓸 만하다고 판단하고 그 붕괴를 결코 드러내지 않을 것입니다; 손상은 정확히 긴 추론과 코드 생성이 일어나는 곳에 있습니다. 그 비대칭성 때문에 "내가 써봤을 때는 괜찮게 느껴졌다"는 것은 양자화된 모델에 대한 증거가 아닙니다.

Prism ML은 동일한 주장을 '지능 밀도'라고 부르는 단일 파생 수치로 압축한다. 대략 기가바이트당 벤치마크 성능이다. 20개 벤치마크 스위트에서 Bonsai 2의 경우 GB당 0.444, IQ2_XXS 빌드의 경우 0.276, FP16의 경우 0.051을 보고한다. 이 지표는 벤더 자체의 구성물이며 그 가중치는 설계 선택이지 법칙이 아니다. 그러나 그것이 만들어내는 순서는 원시 표가 만들어내는 순서와 같으므로, 증거라기보다 해석을 더한다.

비교에 관해 한 가지 더 솔직히 덧붙이자면, Prism ML의 GGUF 모델 카드는 두 번째로 더 좁은 평가, 즉 14개 벤치마크 thinking-mode 스위트를 보고합니다. 여기서도 동일한 유지율 수치가 84.78 대 86.32로 다시 나타나고, IQ2_XXS는 72.59입니다. 서로 다른 두 스위트가 같은 98.2%에 도달한 것은 그 집계 주장이 하나의 벤치마크 선택에서 비롯된 인공물이 아니라는 점을 약하게 뒷받침합니다. 다만 두 평가를 모두 실행한 곳은 여전히 같은 연구소이며, 같은 하네스에서입니다. 패킹 형식 문제를 포함해 이 맞대결을 더 자세히 분석한 내용은 Qwen3.8 27B GGUF 빌드와의 비교에 있습니다.

실제로 운영하는 데 필요한 것

처리량 수치는 백서의 표준화된 tg128 측정 기준으로, 배치 크기 1에서 비전 타워를 제외한 값:

• Apple M5 Max — 46.8 tok/s 디코딩, 765 tok/s 프롬프트 처리

• Apple M5 Pro — 디코드 27.7 tok/s; PQ2_0 팩을 더 긴 윈도우로 별도 실행했을 때는 27.0 tok/s를 지속적으로 유지했으며, GPU 레일에서 27.0 W, CPU와 GPU를 합쳐 32.8 W를 소비했습니다

• Apple M4 Pro — 디코드 18.0 tok/s, 프롬프트 처리는 약 125 tok/s로, 매우 긴 컨텍스트에서는 이것이 실질적인 병목 제약이 됩니다.

• NVIDIA RTX 5090 — PQ2_0 팩에서 토큰당 0.582mWh로 142.5 tok/s 디코딩

Prism ML이 내세우는 실질적인 주장은 속도 향상 비율이 아니라 부재다. 53.8GB의 FP16 베이스라인은 16GB 노트북에 아예 들어가지 않으므로, 의미 있는 진술은 27B급 모델이 이제 일상적인 하드웨어에서 대화형으로 실행된다는 것이다. M5 Pro에서 측정된 디코드는 약 201GB/s의 가중치를 스트리밍하며, 이는 저비트 표현이 활용하도록 설계된 메모리 대역폭 지배적 프로파일을 확인해 준다.

그다음은 엣지 케이스인데, 이는 최고 수치보다 더 중요하다.

기본 llama.cpp는 사용할 수 없습니다. 3진 하이브리드 어텐션 커널은 Prism ML 자체의 llama.cpp 포크에 들어 있습니다. 기본 llama.cpp는 PTQ1_0 및 PQ2_0 유형을 알 수 없는 유형으로 거부하며, 더 위험하게도 이전 Q2_0 3진 형식을 아무 경고 없이 로드해 쓰레기 같은 출력을 생성합니다. Hadamard 활성화 런타임이 없기 때문입니다. 일치하는 회전을 적용하지 않는 바이너리에서 이 모델을 실행하면 오류가 발생하지 않고, 유창해 보이는 헛소리가 나옵니다. 이 릴리스에서 오후 한나절을 낭비하게 될 가능성이 가장 큰 방법입니다.

MLX 팩에는 CUDA 경로가 없습니다. MLX 릴리스(prism-ml/Ternary-Bonsai-2-27B-mlx-2bit)는 Apple Silicon을 대상으로 하며, 여기에는 Python 및 Swift 런타임 모두에서 하이브리드 스택을 위한 사용자 정의 커널이 있습니다. 해당 릴리스의 양자화된 matmul에는 Metal 및 CPU 커널이 있지만 CUDA 구현은 없으므로, NVIDIA 머신에서는 그 특정 팩이 GPU 가속을 전혀 받지 못합니다. CPU 추론은 작동하지만, CPU에서 27B 순전파는 몇 분이 걸릴 수 있습니다 — 이로 인해 Linux CPU 경로는 구현 테스트와 재현성에는 유용하지만 서빙에는 쓸모가 없습니다.

두 팩은 순위가 아니라 진정한 맞교환입니다. Ada 세대 카드나 L4를 사용 중이거나 메모리가 제약 조건이라면 5.93 GB의 PTQ1_0이 정답입니다. Hopper, Blackwell 또는 5090을 사용 중이라면 PQ2_0은 1.3 GB를 더 지불하고 디코드 속도를 얻는 선택입니다. Apple silicon을 사용 중이라면, 위의 M5 Pro 수치는 PQ2_0에서 측정된 것이며, 이 팩이 데모 설정이 기본으로 다운로드하는 팩이라는 점에 유의하세요.

MLX 팩 자체의 계산 방식에 관한 참고 사항입니다. 흔히 혼동을 일으키는 부분이기 때문입니다. MLX 컨테이너는 어파인 2비트 형식으로, 블록이 128개 가중치마다 FP16 스케일과 FP16 바이어스를 함께 저장합니다. Bonsai의 삼진 가중치는 스케일만 필요하므로 — 레벨은 스케일만으로 나옵니다 — 바이어스는 쓸모없는 짐이고, 블록은 128개 가중치당 34바이트가 아니라 36바이트를 차지합니다. 그로 인해 MLX 팩의 패킹 비율은 1.72도 1.76도 아닌 2.250비트/가중치가 됩니다. 동일한 삼진 값을 담는 다른 컨테이너이며, Hugging Face에서 측정된 파일 크기는 8.005 GiB입니다.

런타임 어블리터레이션 변형

9월 18일, OrcaRouter는 OrcaRouter Ternary Bonsai 2 27B Uncensored를 공개했는데, 이 모델에는 거부 방향 절제를 전적으로 런타임에서 적용한다. 이 엔지니어링 아이디어는 제품보다 더 주목할 가치가 있으므로, 먼저 그 아이디어부터 살펴보겠다.

기존의 abliteration은 가중치를 편집한다. 활성화 공간에서 거부 행동에 해당하는 방향을 찾은 다음, 잔차 스트림에 기록하는 가중치 행렬을 그 방향에 대해 직교화한다: W ← W − r(rᵀW). 일반적인 FP16 모델에서는 이게 괜찮다 — 편집된 행렬이 여전히 밀집 부동소수점 행렬이므로, 저장하고 넘어가면 된다. 삼진 팩에서는 이는 막다른 길이며, 특히 이 모델 전체가 존재하는 바로 그 이유 때문에 막다른 길이다. 삼진 행렬을 직교화하면 밀집 full-precision 행렬이 된다. 그것을 다시 삼진 팩에 저장하려면 재양자화해야 한다 — 그리고 편집된 가중치를 재양자화한다고 해서 원본을 만들어낸 양자화 인식 학습이 재현되지는 않는다. 정확히 그 대가로 얻은 것을 버리게 되는 것이다.

그래서 프로젝션은 대신 추론 시점으로 이동합니다. W를 바꾸는 대신, 그 출력을 바꾸세요:

• y ← y − α · dot(y, r) · r, float32로 계산되며, 여기서 y는 잔차 기여이고 r은 정규화된 거부 방향입니다

α = 1일 때 각 잔차 쓰기에서 거부 방향에 평행한 성분이 제거됩니다. α = 0일 때 모델은 변경되지 않습니다. α가 1보다 크면 과도하게 투영하여 품질이 저하될 수 있습니다. α는 체크포인트 속성이 아니라 런타임 매개변수이므로, 같은 팩을 동일한 프로세스에서 자기 자신과 A/B 테스트할 수 있습니다 — 이것이 바로 OrcaRouter의 평가가 하는 일입니다. 원본 Bonsai 팩은 비트 단위로 동일하게 유지됩니다: 수정된 가중치 0개, 재양자화 0회, 추가 가중치 양자화 오류 0.

이것의 순진한 버전이 실패하는 지점은 바로 두 가지 구현 세부 사항이다.

개입 지점은 16개가 아니라 129개입니다. 잔차 스트림에 기록할 수 있는 모든 모듈을 래핑해야 하며, 이 하이브리드 아키텍처에서는 64개의 mlp.down_proj 블록, 48개의 linear_attn.out_proj 레이어, 16개의 self_attn.o_proj 레이어, 그리고 model.embed_tokens — 총 129개입니다. self_attn.o_proj만 래핑하는 것은 명백한 실수이며, 그중 16개만 잡아내고 나머지 113개의 기록은 투영되지 않은 채로 남깁니다. 자체 점검 스크립트는 거부 방향을 따라 남은 성분이 잔차 노름의 약 1e-6 수준으로 억제되는지 측정하고, 129개 지점을 모두 감지하지 못하면 경고합니다.

방향을 다시 회전하지 마십시오. 삼진 팩은 투영을 해당 입력 차원에서 회전된 기저로 유지하고 활성화 측에서 보상합니다. 거부 투영은 그 투영들의 출력에서 작동하며, 이들은 이미 일반 은닉 기저로 돌아와 있습니다 — 따라서 거부 방향은 평범한 5120차원 벡터이며, 여기에 추가 하다마드 회전을 적용하면 완전히 잘못된 기저에 대해 투영하게 될 것입니다.

OrcaRouter가 측정한 것 — 독립적인 수치가 아닌, 우리 자체 수치

이것은 OrcaRouter 자체의 규칙 기반 측정치이며, 그렇게 읽어야 합니다: 규칙 기반 도입 문구 분류기이고, LLM 판정자가 아니며, 사고(thinking) 비활성화, 그리디 디코딩, 64토큰 예산을 사용했고, base와 ablated는 동일한 프로세스에서 동일한 가중치로 α = 0과 α = 1을 비교한 것입니다. 이는 참고용 지표일 뿐 출판 수준은 아니며, Prism ML이 주장한 어떤 것에 대한 검증도 아닙니다.

거부의 경우, 거부를 받은 프롬프트의 비율로 측정:

• AdvBench (n=100) — 베이스 99.0%, 어블레이션 6.0%, 56.0%는 답변했지만 면책 조항으로 감싸짐

• JailbreakBench (n=100) — 기본 96.0%, 어블레이션 4.0%, 단서 포함 52.0%

• StrongREJECT (n=150) — 기본 99.3%, 어블레이션 3.3%, 유보적 45.3%

• HarmBench(n=150) — 기본 98.7%, 어블레이션 7.3%, 조건부 48.0%

• MaliciousInstruct (n=100) — 기본 97.0%, 어블레이션 0.0%, 단서 포함 52.0%

• ForbiddenQuestions (n=150) — 기본 75.3%, 어블레이션 5.3%, 경고 문구 포함 42.7%

• SimpleSafetyTests (n=50) — 기본 96.0%, 어블레이션 18.0%, 주의 문구 포함 60.0% — 그리고 이 수치는 실제보다 낮게 잡힌 것입니다. 해당 세트는 대부분 자해 프롬프트이며, 모델은 "I am deeply sorry to hear…"로 시작하는 위기 대응 안내로 이에 답합니다. 분류기의 정확한 문구 목록은 이를 놓치고, 분류기는 이를 준수로 채점합니다. 그 세트에서 실제 잔여 거부율은 18.0%보다 높습니다. 분류기는 수치가 OrcaRouter의 다른 모델 카드와 계속 비교 가능하도록 의도적으로 그대로 두었습니다.

어떤 세트에서도 응답이 토큰 예산을 초과하지 않았으므로, 이 비율들은 잘림으로 인해 부풀려지지 않았습니다. 무해한 프롬프트에서 동일한 투영은 과잉 거부도 제거합니다: XSTest-safe는 거부율이 5.2%에서 0.4%로 떨어졌고, JailbreakBench의 무해한 하위 집합은 25.0%에서 0.0%로 떨어졌습니다. 공개된 팩은 해당 벤치마크의 무해한 프롬프트 중 4분의 1을 거부합니다; 제거하면, 전혀 거부하지 않습니다.

성능 측면에서, 가중치가 비트 단위로 동일하다는 것은 재양자화 비용을 치를 필요가 없다는 뜻이며, 측정 결과도 이와 일치합니다:

• MMLU (n=300) — 기본 76.7%, 어블레이션 77.7%, +1.0

• GSM8K (n=150) — 기준 87.3%, 제거 86.0%, −1.3

• CMMLU (n=500) — 76.2% 기준, 75.6% 제거, −0.6

이러한 표본 크기에서는 모든 변화가 노이즈 범위 안에 있습니다. GSM8K 질문 하나는 0.7점의 가치가 있습니다. MMLU-Pro는 보고하는 대신 제외했습니다. 이 프롬프트는 답변 전에 추론을 요구하는데, 양쪽 모두에서 응답의 63–64%가 토큰 예산 안에서 답변에 도달하지 못했으므로, 어떤 정확도 수치든 측정값이 아니라 예산이 정한 하한선일 뿐입니다.

가장 중요한 주의사항

거부 방향은 Bonsai 팩이 훈련된 BF16 기본 모델에서 추정되었습니다. 아키텍처와 은닉 기저는 동일하므로 기하 구조가 일치합니다. 하지만 그 방향이 양자화 인식 훈련을 얼마나 잘 견뎌내는지는 되지 않았다.완전히 측정

런타임은 모든 잔차 쓰기에서 제공된 방향을 제거한다는 것을 수학적으로, 그리고 약 1e-6 수준까지 입증할 수 있다. 하지만 그것만으로는 그 방향이 양자화된 모델에서도 밀집 모델에서 포착했던 것과 동일한 행동 특성을 여전히 포착한다는 점을 입증할 수 없다. 이 둘은 서로 다른 주장이며, 확정된 것은 첫 번째뿐이다. 위 안전성 표를 읽는 사람은 누구든, 그 개입이 방향 전이 가정이 성립하는 만큼만 정확히 효과가 있다는 점, 그리고 그 가정이 바로 열린 문제라는 점을 알고 읽어야 한다.

또한 OrcaRouter가 이번 릴리스 자체에 부여하는 실용적인 프레이밍이 있는데, 이는 다른 말로 흐리게 바꾸기보다 그대로 반복할 가치가 있습니다. 학습된 거부 방향을 제거하면 모델이 원래라면 거절했을 요청에 응답하게 될 수 있습니다. 이것은 연구 및 추론 제어 메커니즘이며, 그로 인해 나오는 어떤 출력이 안전하거나 정확하거나 적절하다는 증거가 아닙니다. 이를 사용하는 배포에서는 자체적인 접근 제어와 정책 시행을 적용해야 합니다. 거부를 제거하는 것은 공짜 개선이 아니며, 이 글은 그런 것인 양 쓰이지 않았습니다.

이를 재현하려는 분들을 위한 세 가지 추가 실용 참고 사항입니다. 이 팩은 반드시 자체 번들 런타임으로 로드해야 합니다. 일반 MLX 로더는 성공적으로 로드한 것처럼 보이면서도 조용히 잘못된 계산을 할 수 있으므로, 어블레이션이 활성화되기도 전에 출력이 잘못되어 보인다면 먼저 로딩 경로를 확인하십시오. 레이어 선택적 어블레이션이 지원되므로, 개입이 전부 아니면 전무일 필요는 없습니다. 그리고 어블레이션 평가는 팩이 자체 커널을 구동하도록 한 것이 아니라, 팩을 펼친 FP16 확장본에서 실행되었습니다. 패킹된 양자화 matmul에는 CUDA 구현이 없고 CPU 백엔드는 순전파당 몇 분이 걸리기 때문입니다. 이 확장본은 팩의 삼진 값을 정확히 담고 있으며 표본 점검에서 팩 자체의 다음 토큰 분포를 소수점 셋째 자리까지 재현하지만, 이는 컨테이너 변경이므로 알아둘 만합니다. 코드와 전체 표는 OrcaRouter Ternary Bonsai 2 27B Uncensored 리포지토리에 있습니다. 어블레이션된 MLX 빌드와 수정되지 않은 Qwen3.8 27B MLX 경로를 비교하는 별도의 비교에서는 런타임 세부 사항을 더 깊게 다룹니다.

이것이 어디로 가는지, 그리고 아직 입증되지 않은 것

약 6기가바이트에 들어가는 거의 무손실 27B 모델이 로컬 에이전트에 대해 바꾸는 것은 대부분 무엇이 상주하게 되느냐에 관한 것입니다. 16GB 노트북에서 실제 컨텍스트 윈도우와 함께 들어가는 언어 모델은, 에이전트가 파일을 읽고, 도구를 호출하고, 여러 턴에 걸쳐 계획을 유지하는 등 다른 작업을 하는 동안에도 로드된 채로 남아 있을 수 있습니다 — 요청마다 메모리로 스왑인되거나 서버로 밀려나는 대신에 말이죠. 그것이 한 번 시험해 보는 로컬 모델과 계속 실행해 두는 로컬 모델의 차이이며, 에이전트 수치인 τ 2-Bench 80.2와 BFCL v3 74.9가 뒷받침하기 위해 존재하는 바로 그 속성입니다.

입증되지 않은 것들의 목록은 그 발표가 암시하는 것보다 더 길다.

• 독립적 재현 없음. 이 글의 모든 품질 수치 — 83.9, 98.2%, 카테고리 평균 — 는 Prism ML이 자체 스위트에서 직접 측정한 값입니다. 이는 이번 릴리스의 결함이 아닙니다. 단지 출시 하루째의 모습일 뿐입니다. 또한 이것은 가장 먼저 바뀔 부분이기도 합니다.

• 장기 지평 에이전트 작업은 벤더 자체 표에서 가장 강한 부분이 아니라 가장 약한 부분이다. Terminal-Bench 2.1의 52.8 대 69.7은 실제 격차이며, 벤더는 이 기능이 부분적이라고 말한다.

• 아직 시도해 보지 않은 프롬프트. 저비트 모델의 실패 양상은 선택적이며, IQ2_XXS가 AIME26과 LiveCodeBench에서 붕괴하면서도 MMLU-Redux에서는 85.79를 유지한다는 점은 벤치마크 평균이 여러분의 워크로드에서 어떤 일이 일어나는지 알려주지 않는다는 것을 보여주는, 이용 가능한 가장 명확한 증거입니다. Bonsai 2는 그 두 벤치마크에서 그러한 붕괴를 보이지 않는데, 이는 고무적이지만 보증과 같은 것은 아닙니다.

• 위의 abliterated 변형에서의 방향 전이 문제로, 이는 설계상 미해결로 남아 있다.

• 커널이 런타임이 바뀌어도 계속 버틸 수 있는지 여부. 현재 이 모델은 포크가 필요하다. 순정 llama.cpp는 세 가지 포맷 중 두 가지를 거부하고, 세 번째는 아무 말 없이 엉망으로 만든다. 그 커널이 업스트림에 반영되기 전까지 "llama.cpp가 실행되는 곳이면 어디든 실행된다"는 말은 이 모델에는 아직 사실이 아니다.

릴리스 자체가 문제인 것은 아니다. 5.93GB의 27B급 멀티모달 모델이, 압축 원본의 9분의 1 점유 공간으로, 수학과 코딩은 원본과 동급이고 지시 수행은 약간 앞선다는 것은 로컬 추론에서 진정으로 다른 운용점이다. 2026년 9월 18일에 합리적인 자세는 파일 크기는 사실로 받아들이고, 보존 수치는 하루 전에 벤더가 선택한 스위트에서 벤더가 한 신중한 주장으로 받아들이며, 자신의 워크로드에 대해서는 그것을 실제로 돌려보기 전까지 판단을 유보하는 것이다.

런타임 어블레이션 코드와 거부 방향, 그리고 전체 평가 표는OrcaRouter가 팀이 구축한 라우팅 플랫폼과 함께 공개합니다.