Fermion Research, 3진 계열 포맷으로 직접 학습한 Neutrino-1 모델군 3종 공개

9bow · 7월 30, 2026, 12:30오전

Neutrino-1 모델군 소개

Fermion Research가 2026년 7월 27일 Neutrino-1 모델군 3종을 공개했습니다. 8B급 플래그십인 Neutrino-1 8B, 초안 모델 겸 소형 모델인 Neutrino-1 0.6B, 그리고 대화용으로 마무리한 Neutrino-1 0.6B-Chat입니다. 세 모델 모두 Apache License 2.0 오픈 가중치이며 대기 명단이나 승인 절차 없이 Hugging Face에서 바로 받을 수 있습니다. 이 릴리즈에서 가장 먼저 눈에 들어오는 숫자는 하나입니다. 8B 파라미터 모델이 디스크에서 3.88GB, 다운로드로는 2.56GB이고, 그 상태로 5-shot MMLU 72.1을 받았다는 것입니다.

지난 10년간 이 분야는 저장 폭의 사다리를 한 칸씩 내려왔습니다. 8비트 추론이 2010년대 후반에 표준이 되고, 4비트 가중치가 2023년 오픈 7B 모델들과 함께 대중화됐습니다. 그 다음 칸이 오래 비어 있었습니다. 가중치를 3개 상태로 저장하는 접근은 BitNet b1.58 계열로 2024년에 트랜스포머 언어 모델까지 올라왔지만, 8B급에서 상위권 지식 점수를 유지한 사례는 나오지 않았습니다. 단일 스트림 디코딩(single-stream decode) 이 대역폭 문제라는 사실이 이 사다리를 계속 내려가게 만드는 동력입니다. 토큰 하나를 만들려면 모델의 살아 있는 가중치를 전부 한 번 읽어야 하므로, 저장 폭이 절반이 되면 토큰당 옮길 바이트도 절반이 됩니다.

Fermion Research가 내놓은 답은 포맷을 학습 중에 미리 넣어두는 것(native-format training) 입니다. 완전 정밀도로 학습한 뒤 반올림하는 것이 아니라, 학습의 모든 순전파가 이미 그 저해상 포맷 안에서 일어나게 만듭니다. 세 모델은 토크나이저, 컨테이너 레이아웃, 추론 엔진을 공유합니다. H100에서 도는 파일과 맥북에서 도는 파일이 바이트 단위로 같고, 그래서 0.6B가 8B와 같은 프로세스 안에 올라가 초안 모델(draft model) 로 동작할 수 있습니다. 별도 배포도, 변환 단계도 없습니다.

이 글은 공개된 10개 출처를 교차 확인해 정리했습니다. 세 편의 연구 글, 두 개의 제품 페이지, 세 개의 Hugging Face 모델 카드, PyPI 패키지, 그리고 llama.cpp 포크입니다. 미리 말해 둘 것이 있습니다. 마케팅 페이지의 수치와 모델 카드의 수치가 여러 축에서 어긋나며, 헤드라인 성능을 만든 구성 요소 중 일부는 공개되지 않았습니다. 기술 자체는 충분히 흥미롭고, 그래서 어느 숫자가 무엇을 재고 있는지 구분해 두는 편이 유용합니다. 각 절에서 해당 지점을 짚습니다.

세 모델과 하나의 컨테이너: 모델군의 구성

세 모델은 같은 컨테이너 포맷과 같은 바이너리를 씁니다. 8B는 36개 디코더 층을 4,096 폭의 잔차 스트림 위에 올렸고, 두 0.6B 모델은 28개 층을 1,024 폭에 올린 뒤 임베딩 테이블을 묶어(tied) 하나의 텐서가 입력 조회와 출력 헤드를 겸하게 했습니다.

항목	Neutrino-1 8B	Neutrino-1 0.6B	Neutrino-1 0.6B-Chat
기반 모델	Qwen3-8B	Qwen3-0.6B	Qwen3-0.6B
파라미터	8,190,735,360	596,049,920	596,049,920
디코더 층	36	28	28
은닉 폭	4,096	1,024	1,024
피드포워드 폭	12,288	3,072	3,072
어텐션	쿼리 32, 키값 8	쿼리 16, 키값 8	쿼리 16, 키값 8
임베딩 테이블	분리(2개 텐서)	결합(1개 텐서)	결합(1개 텐서)
KV 캐시(토큰당, fp32)	288 KiB	224 KiB	224 KiB
컨텍스트 길이	40,960	40,960	40,960
다운로드	2.56 GB	238 MB	328 MB
디스크	3.88 GB	328 MB	328 MB
Apple M5 CPU 디코드	24.9 tok/s	225~236 tok/s	170~218 tok/s(모델 카드는 미인용)
역할	범용 어시스턴트, 도구 호출	8B 디코드용 초안 모델	짧은 대화

어텐션은 그룹 쿼리 어텐션(Grouped-Query Attention, GQA) 입니다. 8B는 32개 쿼리 헤드가 8개 키값 헤드를 공유하는 4대 1 구성이고, 0.6B는 16대 8로 2대 1입니다. 헤드 폭은 양쪽 모두 128입니다. 회전 위치 임베딩(Rotary Position Embedding)이 헤드 전체 폭에 걸쳐 적용되고 base는 1,000,000이며, 쿼리와 키는 캐시에 들어가기 전에 헤드 단위 RMSNorm을 한 번 더 통과합니다. 피드포워드 블록은 SwiGLU 계열의 게이트 구조로 층마다 선형 계층 3개를 씁니다. 즉 기하 구조는 Qwen3 그대로입니다. 실제로 llama.cpp 포크의 문서도 "Neutrino 모델은 표준 Qwen3 기하 구조이고 메인라인이 이미 구현해 둔 것이라 모델 그래프는 손대지 않았다" 고 명시합니다. 바뀐 것은 그 안에 든 가중치가 무엇으로 저장되는가 하나입니다.

어휘 사전은 세 모델 모두 151,936 토큰으로 동일합니다. 이 동일성이 초안 모델 구성의 전제 조건입니다. 초안 모델이 제안한 토큰을 검증 모델로 넘길 때 재매핑이 필요 없어야 하기 때문입니다. 0.6B 폭에서는 출력 테이블을 따로 두는 비용이 그 테이블이 서비스하는 층들보다 커지므로, 작은 모델은 입출력 임베딩을 하나의 156MB 테이블로 묶었습니다.

3진 계열이라는 이름의 실체: 포맷은 정확히 무엇인가

연구 글은 이 포맷을 "독자적인 3진 계열 가중치 포맷(proprietary ternary-family weight format)" 이라 부르고, 저장된 가중치 하나가 "마이너스, 0, 플러스 중 하나를 고르는 3지 선택" 이라고 설명합니다. 그리고 한 줄을 덧붙입니다. "이 포맷은 독자적인 구조로 3진 계열을 확장하며, 그 확장은 공개하지 않습니다."

3진 가중치 하나가 담는 정보량은 \log_2 3 \approx 1.58 비트입니다. 저장 장치는 정수 비트 단위로 다루므로 단순한 컨테이너는 상태당 2비트를 쓰고 그 차이만큼을 낭비하게 됩니다. 학습된 모델은 세 상태의 빈도가 균등하지 않기 때문에 격차가 더 벌어집니다. Neutrino의 전송 포맷은 이 낭비를 되돌리는 쪽으로 설계됐고, 8B의 2.56GB 다운로드는 수신 측에서 3.88GB 컨테이너로 바이트 단위 동일하게 복원됩니다. 0.6B는 328MB 컨테이너가 238MB로 줄어드는데, 연구 글은 이 값이 해당 스트림의 0차 부호화 하한(order-0 coding bound) 에서 0.007% 안쪽이라고 밝힙니다.

3진 레인을 타지 않는 텐서가 있고, 그 예외에는 구조적인 이유가 있습니다. 선형 계층의 출력 특징 하나는 수백 개의 3상태 기여를 더한 합이므로 개별 상태 오차가 합 안에서 서로 상쇄됩니다. 그 누산이 포맷을 견딜 수 있게 만드는 장치입니다. 반면 임베딩 조회에는 그런 합이 없습니다. 한 행을 그대로 반환하므로 그 행의 오차가 곧 토큰의 표현 전체가 됩니다. 출력 헤드는 같은 문제의 반대편 끝에 있습니다. 151,936개 후보 중 다음 토큰을 작은 로짓 차이로 가려내야 하는데, 그 차이가 정확히 3상태 격자가 담지 못하는 값입니다. 정규화 이득은 모델 전체에 308,224개뿐이고 각각이 활성값 스트림 하나를 통째로 스케일하므로 평균낼 이웃이 없습니다. 그래서 임베딩과 출력 헤드는 int8, 정규화는 fp32로 남습니다.

FV5와 FV5B: llama.cpp 포크가 공개한 블록 구조

공개 페이지들이 "3진"이라고 쓰는 동안, 실제로 출하되는 산출물들은 다른 이름을 씁니다. Hugging Face의 8B 모델 카드는 이 모델을 "모든 트랜스포머 선형 계층이 5값(five-valued, 가중치당 2비트 미만)으로 저장된" 것이라 적고, PyPI 패키지 설명도 "Fermion Research의 5값 2비트 미만 언어 모델" 로 시작합니다. 가장 명확한 것은 llama.cpp 포크입니다. 이 포크는 상위 llama.cpp에 두 개의 ggml 가중치 타입을 추가하며 블록 구조를 그대로 공개합니다.

ggml 타입	id	블록 크기	블록당 바이트	가중치당 비트	적용 대상
`FV5`	43	256	104 (f32 `s_lo`, f32 `s_hi`, 32바이트 비트플레인 3장)	3.25	모든 어텐션 및 MLP 선형 계층
`FV5B`	44	256	260 (f32 `s`, int8 256개)	8.125	`token_embd`, `output`

블록당 스케일이 하나가 아니라 s_lo와 s_hi 두 개이고, 비트플레인이 3장이라는 점이 핵심입니다. 3장의 비트플레인은 256개 가중치에 각각 3비트, 즉 8개 코드를 줍니다. 이 구조는 부호와 0에 두 단계의 크기를 더한 5개 상태로 읽히며, 연구 글이 "미공개 확장"이라고만 적은 부분이 이 두 번째 크기 단계에 해당하는 것으로 보입니다. 즉 "3진 계열"의 계열 이라는 단어가 실제 작업을 하고 있습니다. 순수한 3진이 아니라 3진에 크기 단계를 하나 더한 5값 포맷입니다.

fp16의 8분의 1은 어떤 축의 이야기인가

연구 글의 제목은 "8분의 1 비트로 구현한 지능(Intelligence at one-eighth the bits)" 이고, 본문도 8B가 "fp16의 8분의 1 비트" 로 저장된다고 적습니다. fp16이 16비트이므로 8분의 1은 가중치당 2비트입니다. 그런데 같은 문서들이 다른 곳에서는 다른 배수를 씁니다. 실제로 무엇이 몇 배인지 계산해 보면 세 개의 서로 다른 축이 나옵니다.

디스크의 컨테이너: 3진 레인은 2,604,662,784바이트에 6,945,767,424개 가중치를 담습니다. 가중치당 정확히 3.0비트입니다. GGUF 팩의 FV5 타입은 3.25 bpw이므로 팩 파일(4.09GB)이 컨테이너(3.88GB)보다 조금 큽니다.

bf16 대비 산출물 비율: 같은 파라미터를 bf16으로 담으면 약 16.4GB입니다. 3.88GB 컨테이너와 비교하면 4.2배 작습니다. 연구 글도 축별 유지율을 논할 때는 "4.2배 적은 바이트" 라고 정확히 이 값을 씁니다. 엔진 글 역시 "바이트 하한이 네 배 낮아진다" 고 적습니다.

전송 포맷의 밀도: 3진 레인은 다운로드용으로 원본의 0.552 비율로 부호화되므로 가중치당 약 1.66비트입니다. 이 값이 2비트 미만이고, 그래서 "가중치당 2비트 미만"과 "8분의 1 비트"라는 표현이 성립합니다.

여기서 중요한 것은 디코드 속도를 지배하는 축이 세 번째가 아니라 두 번째 라는 점입니다. 엔진은 전송 포맷을 실행하지 않고 복원된 3.88GB 컨테이너를 실행합니다. 토큰마다 옮기는 바이트는 4.2배 줄어든 쪽이고, 따라서 대역폭 상한이 낮아지는 폭도 8배가 아니라 4배입니다. 헤드라인의 "8분의 1"은 회선 위의 밀도를 말하고, 속도를 만드는 "4배"는 메모리 위의 크기를 말합니다. 두 숫자 모두 사실이지만 같은 것을 재고 있지 않습니다.

학습 중에 포맷이 있어야 하는 이유

가장 자연스러운 접근은 부동소수점으로 학습한 뒤 반올림하는 것입니다. 3진 깊이에서는 그 경로가 무너집니다. 강한 8B급 모델을 공격적으로 사후 반올림한 공개 결과들은 4지 선다 지식 배터리에서 우연 수준, 즉 100점 기준 25점 근처에 떨어집니다.

무너지는 데는 메커니즘이 있고, 그것은 합 안에 있습니다. 선형 계층 출력 특징 하나는 수백 개의 가중치 곱 활성값 항을 누산한 값입니다.

y_j = \sum_{i=1}^{d} w_{ij} \, x_i

학습된 신경망은 이 항들이 서로 얼마나 상쇄되는지에 내용을 저장합니다. 반올림은 각 가중치를 독립적으로 가장 가까운 격자점에 사영합니다. 개별 오차는 모두 같은 작은 범위 안에 머물지만 서로 무관하므로, 행을 따라 상쇄되는 대신 무작위 보행(random walk) 처럼 누적됩니다. 계층이 내놓는 특징은 정답에 잡음이 섞인 값이 아니라 아예 다른 값이 되고, 36개 층이 그 차이를 복리로 키웁니다. 연구 글의 표현을 빌리면 "실패는 잡음이 아니라 기억 상실이고, 그 특징은 절벽이다. 점수가 우연 수준을 향해 나빠지는 것이 아니라 거기에 도착한다."

공개된 기록이 정확히 그 선에서 갈립니다. 8B를 2비트로 원샷 반올림한 두 개의 독립 결과는 5-shot MMLU에서 24.2와 24.7을 받았고, 무작위 응답이 25.0입니다. 남은 신호가 아무것도 아닌 것의 측정 오차 안에 있다는 뜻입니다. 반대로 학습이 저해상 포맷 안에서 진행된 세 모델은 같은 산출물 크기에서 47.24, 65.75, 72.1을 기록했습니다. 이 대비 자체가 이 릴리즈에서 가장 설득력 있는 부분입니다.

네이티브 학습은 제약과 지식의 순서를 뒤집습니다. 학습 중 모든 순전파가 3진 순전파이므로 손실이 포맷을 상대로 계산되고, 기울기는 이산화를 통과해 옵티마이저 안에만 존재하고 출하되지 않는 고정밀 캐리어로 전달됩니다. 그 제약 아래의 하강은 포맷이 담을 수 없는 해를 애초에 학습하지 않습니다. 가지고 있지 않은 정밀도를 감당할 수 있는 구조와 교환하면서 부호 패턴, 0의 배치, 블록 스케일을 한 묶음으로 고릅니다. 마지막에 반올림 단계가 없는 이유는 반올림할 것이 남아 있지 않기 때문입니다. 다만 이 품질을 이 깊이에서 안정적으로 유지하는 학습 방법 자체는 공개되지 않았습니다.

출하된 컨테이너를 직접 읽기: 62.63%의 침묵

이 릴리즈에서 검증 가능성이 가장 높은 부분은 출하된 컨테이너를 직접 걸어서 읽은 측정입니다. fermion inspect 명령이 같은 일을 하도록 공개돼 있어 독자가 재현할 수 있습니다. 8B의 8.19B 파라미터 중 6,945,767,424개가 3진 상태이고, 그중 62.63%가 정확히 0입니다. 남은 부분은 플러스 18.677%와 마이너스 18.694%로 갈립니다. 69억 개 가중치에 걸쳐 부호 격차가 0.017포인트인데, 학습 목표나 포맷의 어느 곳도 이 대칭을 강제하지 않았습니다.

이 격자에서 두 가지 구조가 나옵니다. 첫째, 4개 어텐션 사영은 36개 층 전체에 걸쳐 1.67포인트 폭의 띠 안에 머뭅니다. 1층 키 사영의 61.84%부터 25층 값 사영의 63.51%까지입니다. 깊이는 어텐션의 연결 밀도를 바꾸지 않습니다. 둘째, 피드포워드 행렬은 정확히 한 곳에서 벗어납니다. 2층에서 4층 구간에서 다운 사영이 72.47%, 게이트가 70.48%까지 올라가 본체보다 약 10포인트 높아지고, 5층부터 다시 가라앉습니다. 모델에서 가장 조밀한 텐서는 그보다 한 층 앞인 1층 다운 사영으로 60.59%입니다. 즉 가장 연결이 많은 피드포워드 행렬에서 가장 침묵하는 행렬로 한 층 만에 건너갑니다.

이 편차는 학습된 가중치 자체의 성질입니다. 초기 피드포워드 행들이 나머지보다 두꺼운 꼬리를 갖는데, 포맷도 학습 목표도 그것을 요구하지 않았습니다. 그리고 이 침묵은 회선 비용으로 되돌아옵니다. 층별로 3진 레인이 원본의 0.516에서 0.569 사이로 부호화되는데, 어느 층이 어디에 앉는지는 임의적이지 않습니다. 층의 0 비율이 그 층의 부호화 크기를 상관계수 마이너스 0.92로 예측합니다. 가장 조용한 2층에서 4층이 가장 작게 부호화됩니다. 사영 종류별로도 순서가 유지되어 다운 사영이 0.543으로 가장 촘촘하고 키 사영이 0.567로 가장 느슨합니다.

int8 어휘 테이블은 반대로 움직입니다. 압축이 거의 되지 않아 원본의 0.883을 유지하므로, 다운로드 산술은 촘촘한 가중치 레인과 조밀한 어휘 사전의 혼합입니다. 3.88GB가 2.56GB로, 원본의 0.661로 출하됩니다.

파라미터와 바이트는 서로 다른 회계다

포맷이 파라미터 수와 바이트 수를 분리하기 때문에 두 계정을 따로 봐야 합니다. 8B의 8,190,735,360개 파라미터 중 6,945,767,424개가 3진 상태, 1,244,659,712개가 분리된 두 어휘 테이블의 int8 임베딩 파라미터, 308,224개가 fp32 정규화 이득입니다. 같은 모델을 바이트로 재면 2.60GB의 3진 레인, 1.24GB의 어휘 사전, 26MB의 스케일과 정규화와 행 메타데이터입니다. 3진 상태는 파라미터의 84.8%인데 파일의 67.2%만 차지하고, 그 두 숫자 사이의 거리가 포맷의 전부입니다.

0.6B에서는 회계가 반대로 기웁니다. 151,936 토큰 어휘 사전은 주변 모델이 얼마나 무겁든 정해진 비용을 청구하므로, 155,582,464개 파라미터의 묶인 int8 테이블 하나가 파일의 47.5%를 차지하고 가중치 레인은 50.4%에 그칩니다. 모델이 작아질수록 다운로드에서 어휘 사전이 차지하는 비중이 커지고, 8B의 32.1%는 그 곡선의 편한 쪽 끝입니다. 0.6B 카드의 표현대로 "이 크기에서는 신경망이 아니라 토크나이저가 여러분이 내려받는 가장 큰 단일 객체" 입니다.

같은 걸음을 0.6B 컨테이너에 대해 반복하면 포맷의 성질과 특정 모델의 성질이 분리됩니다. 0과 플러스와 마이너스의 비율은 파라미터 수가 14배 차이 나는데도 8B와 0.4포인트 안쪽으로 일치합니다. 0 비율 62.26% 대 62.63%, 플러스 18.87% 대 18.68%, 마이너스 18.86% 대 18.69%입니다. 상태 통계는 한 번의 학습 실행의 특징이 아니라 포맷의 상수 입니다. 반면 그 아래의 모든 것은 움직입니다. 0.6B는 어텐션이 한 층의 40%를 차지해 8B의 21.7%와 다르고, 3진 상태가 파라미터의 73.9%로 84.8%보다 낮고, 바이트 계정에서는 어휘 사전이 가중치 레인 위로 올라섭니다.

벤치마크: 무엇이 측정됐고 어디가 어긋나는가

제품 페이지가 싣는 8B 배터리는 MMLU 72.1(5-shot, 57개 과목 14,042문항 전체), MMLU-Redux 67.8, IFEval prompt-strict 77.2, BFCL v3 68.9, GSM8K 유연 추출 53.4와 명시 형식 51.73입니다. GSM8K를 두 규칙으로 나눠 채점한 것은 좋은 판단입니다. 유연 추출은 모델이 만든 마지막 숫자를 취하고, 명시 규칙은 프롬프트가 요구한 자리에 답이 있을 때만 인정합니다. 산술 능력과 지시 준수를 따로 재는 셈이고, 두 값의 격차가 2포인트 미만이라는 것은 형식 준수가 무너지지 않았다는 신호입니다.

같은 바이트 계급의 여섯 모델을 열두 축에서 비교하면

위 기울기 차트는 다운로드 크기와 MMLU 두 축만 보여줍니다. 발표 글이 함께 싣는 여섯 모델 열두 축 비교 표를 읽어야 전체 그림이 나옵니다. 프롬프트 형식, shot 수, 추출 규칙, 생성 상한을 모든 열에 동일하게 적용했다고 밝히고 있으며, 상대 모델 중 Ternary-Bonsai-8B와 Gemma-4-E4B는 Fermion Research가 같은 설정으로 직접 돌린 값입니다.

축	Neutrino-1 8B	Gemma-4-E4B	Llama-3.1-8B	Ternary-Bonsai-8B	Gemma-3n-E4B	AQLM 2-bit Llama-3-8B
가중치를 만든 방식	3진, 포맷 안에서 학습	16비트 비압축	16비트 비압축	3진, 포맷 안에서 학습	16비트 비압축	2비트, 학습 후 변환
다운로드	2.56 GB	16.02 GB	16.06 GB	2.18 GB	15.70 GB	4.08 GB
MMLU, 5-shot	72.1	70.57	68.3	65.75	64.9(0-shot)	58.72
IFEval, prompt-strict	77.2	88.26	80.4(4회 판독 평균)	83.65(카드는 81.8)	84.41(외부 공개 실행)	미공개
BFCL v3, macro-13	68.9	미공개	76.1(버전 미기재)	71.45(카드는 73.9)	미공개	미공개
GSM8K, 명시 형식	51.73	1.00	미공개	39.67	미공개	미공개
GSM8K, 유연 추출	53.4	30.67	84.5(8-shot, 추론 포함)	35.00(카드는 91)	60.12(외부 공개 실행)	50.87(8-shot)
컨텍스트 길이	40,960	131,072	131,072	65,536	32,768	8,192
Apple 노트북 디코드	33.7 tok/s	30 tok/s(커뮤니티, 4비트)	32.0 tok/s(커뮤니티)	49.0 tok/s	미공개	런타임 없음
H100 80GB 디코드	396 tok/s	미공개	158 tok/s	미공개	미공개	미공개
초안 적용 디코드	763 tok/s	미공개	373 tok/s	8B용 경로 없음	미공개	초안 경로 없음
16GB 노트북 메모리	가능	불가	불가	가능	가능(PLE 오프로드)	런타임 없음

이 표를 그대로 읽으면 Neutrino-1 8B가 이기는 축과 지는 축이 뚜렷하게 갈립니다. 지식(MMLU)과 수학(GSM8K 두 규칙), 그리고 16GB 노트북 적합성에서는 앞섭니다. 반면 지시 준수(IFEval)에서는 수치를 공개한 다섯 모델 중 가장 낮고, 도구 호출(BFCL)에서도 공개한 세 모델 중 가장 낮으며, 컨텍스트 길이 40,960은 아래에서 두 번째입니다. Apple 노트북 디코드는 같은 3진 계열인 Ternary-Bonsai-8B의 49.0 tok/s가 Neutrino의 33.7 tok/s보다 빠르고, 다운로드 크기도 Bonsai의 2.18GB가 더 작습니다.

표를 읽을 때 조심할 셀이 두 개 있습니다. Gemma-4-E4B의 GSM8K 명시 형식 1.00은 산술 능력이 아니라 형식 준수의 실패 입니다. 발표 글도 "답을 요구된 형태로 내라는 조건이 지시 튜닝된 16비트 경쟁 모델에게서 유연 규칙으로 얻은 점수를 거의 전부 앗아간다. 이것은 형식 실패이고 산술 실패가 아니다" 라고 명시합니다. 그리고 Ternary-Bonsai-8B의 GSM8K 유연 추출은 Fermion Research 자체 실행이 35.00인데 해당 모델 카드는 91을 싣습니다. 56포인트 차이는 하네스나 프롬프트 설정의 차이일 가능성이 크므로, 이 행의 비교는 그대로 받아들이기 어렵습니다.

한편 발표 글이 이 표를 이렇게 배치한 것 자체는 평가할 만합니다. 도식 설명이 "상대 열은 우리가 출처를 찾을 수 있는 모든 축을 담았고, 그중에는 이 계급이 우리보다 앞선 행도 포함된다" 고 적고 있습니다. 다만 같은 페이지의 요약 문장과 기울기 차트는 다운로드와 지식 두 축만 강조하므로, 표를 지나치면 이 릴리즈를 실제보다 균일하게 강한 모델로 읽게 됩니다. 지시 준수와 도구 호출이 중요한 에이전트 워크로드라면 이 표의 해당 행이 판단 기준입니다.

같은 컨테이너에 두 벌의 숫자가 있다

문제는 Hugging Face 모델 카드가 같은 컨테이너에 대해 다른 배터리를 싣는다는 점입니다. 카드는 이것을 "출하 브레인의 릴리즈 배터리, 자체 하네스로 채점" 이라고 이름 붙이고, 제품 페이지는 "표준 공개 하네스로 측정" 이라고 적습니다. 겹치는 축을 나란히 놓으면 이렇습니다.

항목	제품 페이지 및 연구 글	Hugging Face 모델 카드
MMLU, 5-shot	72.1	미기재
MMLU-Redux	67.8	67.84
IFEval, prompt-strict	77.2	73.17
IFEval, instruction-strict	80.2	80.22
IFEval, prompt-loose	76.3	76.31
BFCL v3 macro-13	68.9	65.31
GSM8K, 유연 추출	53.4	51.00
GSM8K, 명시 형식	51.73	49.33

MMLU-Redux, IFEval instruction-strict, IFEval prompt-loose는 소수점까지 일치합니다. 그런데 IFEval prompt-strict는 4포인트, BFCL은 3.6포인트, GSM8K는 두 규칙 모두 2.4포인트씩 제품 페이지 쪽이 높습니다. 어긋난 방향이 한쪽으로만 쏠려 있습니다. 모델 카드는 GSM8K가 "고정된 300문항 부분집합" 에서 측정됐다는 조건도 덧붙이는데, 제품 페이지에는 그 조건이 없습니다. 그리고 카드는 상대 모델과의 비교를 이렇게 적습니다. "Ternary-Bonsai-8B는 지시 준수, 도구 호출, MMLU-Redux에서 우리를 앞서고, 우리는 GSM8K 유연 추출과 명시 형식 추출에서 앞선다." 제품 페이지의 비교 표도 같은 상대 수치를 싣지만, 전체 그림은 Neutrino가 이기는 쪽으로 읽히게 배치돼 있습니다.

정리하면 이렇습니다. 모델 카드 쪽 숫자가 더 낮고 조건이 더 촘촘하며, 카드가 자기 위치를 더 정확히 적습니다. 실제로 내려받은 가중치를 평가할 때 기준으로 삼을 값은 카드 쪽입니다. 참고로 이 글에서 비교 대상으로 등장하는 Bonsai 계열은 커뮤니티에도 노트북과 폰에서 실행되는 27B급 이진 및 삼진 저비트 LLM으로 소개된 바 있습니다.

카드가 헤드라인이 아니라 회귀 방지 가드 로 분류해 실어 둔 두 수치는 오히려 이 포맷의 품질을 더 잘 보여줍니다. C4 검증 세트 퍼플렉시티가 21.48이고 베이스 모델이 21.40으로, 사실상 평탄합니다. 8B 규모에서 3비트 저장으로 내려가면서 언어 모델링 능력 자체는 거의 손실되지 않았다는 뜻이고, 앞서 본 지식 96% 유지와 같은 방향의 증거입니다. 그리고 GSM8K 생성형 종료율이 0.51로 같은 원문 완성 계측기에서 bf16 교사 모델의 0.42 기준점보다 높습니다. 카드는 이 계측기가 모델 계열을 가리지 않고 EOS를 억제하는 프로토콜이며 대화 템플릿으로 서빙하면 정상 종료한다는 조건도 함께 적습니다. 컨테이너를 굽기 전에 종료율, IFEval 하한, Redux, 지식 델타, C4 퍼플렉시티 다섯 개 릴리스 가드를 모두 통과시켰다고 밝히고 있습니다.

도구 호출은 13개 하위 스위트로 나눠 봐야 한다

BFCL 매크로 평균은 13개 스위트를 따로 채점한 값의 평균이므로 하나의 숫자로는 무엇이 되고 무엇이 안 되는지 알 수 없습니다. Fermion Research는 13개를 개별 공개했습니다.

고정된 함수 시그니처에 대한 함수 조합이 가장 강한 블록으로 단일, 다중, 병렬, 병렬 다중에서 70.0에서 85.0 사이입니다. 관련성 판단이 그 옆에 76.9에서 81.3으로 붙습니다. 즉 호출하지 않아야 할 때 호출하지 않는 능력이 올바른 함수를 고르는 능력과 거의 같은 신뢰도 를 보입니다. 반면 실제 API에서 수집한 라이브 스위트는 눈에 띄게 떨어집니다. 라이브 단일 61.6, 라이브 다중 52.0, 라이브 병렬 56.3, 라이브 병렬 다중 37.5입니다. 인자 이름과 중첩 구조가 아무의 스타일도 아닌 환경에서 성능이 절반 가까이 깎입니다. 다른 언어는 더 낮아 JavaScript 54.0, Java 43.0입니다.

이 분해는 실무에 바로 쓰입니다. 스키마를 직접 정의하는 통제된 환경에서는 8B가 쓸 만하고, 외부 API 스키마를 그대로 받아 쓰는 에이전트 경로에서는 기대를 낮춰야 합니다.

축별 유지율: 지식은 살아남고 행동은 먼저 깎인다

Fermion Research가 유지율을 하나의 숫자로 평균내지 않고 축별로 공개한 것은 이 릴리즈에서 가장 유용한 결정입니다. 완전 정밀도 Qwen3-8B를 기준으로, 4.2배 적은 바이트에서 동일한 공개 하네스로 측정한 결과 일반 지식 96%, 재주석 집합 지식 87%, 엄격한 지시 준수 87%, 도구 호출 79%입니다. 각 값을 저장에 쓴 바이트로 나누면 같은 네 축이 기준 모델의 바이트당 능력 대비 4.03배, 3.65배, 3.65배, 3.32배로 읽힙니다.

순서 자체가 발견입니다. 지식은 가중치의 덩어리 성질(bulk property) 처럼 행동합니다. 여러 가중치에 중복 저장되고, 선형 계층을 상태 오차로부터 지키는 그 누산이 지식도 함께 지키기 때문에 하강을 거의 온전히 통과합니다. 반면 행동은 에피소드 단위로 채점되는 연쇄 성질(chain property) 입니다. 엄격한 지시 준수 실행이나 도구 호출 에피소드는 모든 단계가 성공했을 때만 점수를 받으므로, 에피소드 지표는 단계별 성능을 평균내는 대신 곱합니다. 연구 글은 이 순서가 "우리가 학습한 모든 모델에서 유지됐다" 고 적습니다.

한 축은 기준 모델보다 앞서서 돌아옵니다. 요구된 답변 형식을 지키는 규율에서 Neutrino-1 8B가 기준 모델보다 안정적이고, 기준 모델이 흐트러지는 자리에서 깔끔하게 종료합니다. 부동소수점을 떠난 모델이 더 잘 훈육된 상태로 돌아올 수 있다는 뜻이고, 규율은 가중치의 덩어리 성질이 아니라 학습이 설치하는 행동이며 포맷이 그것을 막지 않는다는 해석입니다.

행동 축의 보존 법칙

사후 학습에서 얻은 관찰 하나가 이 릴리즈의 방법론 부분에서 가장 일반화 가능한 내용입니다. 한 행동 축에 가해진 학습 압력은 모델을 균일하게 나쁘게 만들지 않습니다. 특정한 다른 축을 깎고, 어느 축이 깎이는지는 학습 식단마다 다른 경험적 성질입니다.

이 계열의 한 도구 호출 단계는 도구 사용 점수를 20포인트 올리는 동안 같은 체크포인트에서 엄격한 지시 준수를 9포인트 잃었고 종료 규율은 오히려 개선됐습니다. 수학 중심 식단은 대신 도구 호출을 붕괴시켰습니다. 손상이 축을 골라 가므로 모든 단계가 모든 축을 감시해야 합니다. 보호도 마찬가지로 축에 특이적입니다. 이미 설치된 축의 학습 신호를 해당 단계의 배치에 섞어 넣으면 그 축이 단계를 통과해 유지되는데, 유지되는 것은 그 축 하나뿐입니다. 9포인트였던 지시 준수 손실이 0.5포인트 미만으로 줄고 도구 호출 이득은 살아남았지만, 혼합에 없던 축이 우연히 보호된 사례는 없었습니다.

용량도 같은 방식으로 움직입니다. 도구 호출 이득은 촘촘히 측정한 모든 캠페인에서 약 25 최적화 스텝 안에 완결됐고, 지시 준수는 약 50 스텝이 필요했으며, 지식 중심 단계는 중간에 정점을 찍고 그 뒤로 감쇠했습니다. 한 축의 용량 계획을 다른 축에 복사하는 것은 범주 오류라는 결론입니다.

여기서 한 걸음 더 나간 관찰이 있습니다. 한 단계가 두 행동을 각자의 기준으로 동시에 검증하면 둘이 함께 오릅니다. 연구 글은 이것을 프로그램에서 처음 나온 동시 2축 이득이라고 적습니다. 보존 자체는 유지되지만, 그 교환이 검증 집합이 보지 않는 곳으로 이동 합니다. 그래서 설계 변수는 검증 집합의 폭이 됩니다. 결론은 두 방향으로 자릅니다. 어떤 행동 이득도 모델의 모든 축을 그 아래에서 측정하기 전에는 확립되지 않으며, 축은 더 세게 학습할 때가 아니라 검증될 때 오릅니다. "더 세게 학습하기에서 더 넓게 검증하기로" 의 전환입니다.

보상 기반 단계가 정체됐을 때 원인이 모델의 천장이었던 적은 한 번도 없었다는 관찰도 함께 실려 있습니다. 모델이 학습 자료를 소진해 교정 압력이 사라진 것이고, 더 어려운 자료가 주지 못하는 것을 추가 스텝이 주지는 않았습니다.

뉴트리노 엔진: 토큰 하나의 시간은 어디로 가는가

엔진은 두 개의 제약 아래 만들어졌습니다. 출력이 완전 정밀도 기준 구현과 토큰 단위로 동일해야 하고, 포맷이 벌어들인 속도가 산출물과 실리콘 사이에서 하나도 유실되지 않아야 합니다.

배치 크기 1의 디코딩에는 지배적인 불변량이 하나 있습니다. 토큰당 바이트를 메모리 대역폭으로 나눈 값이 토큰이 걸릴 수 있는 시간의 단단한 하한입니다.

\text{tok/s}_{\max} = \frac{\text{메모리 대역폭}}{\text{토큰당 바이트}}

커널은 기계가 이 하한에 얼마나 가까이 도는지를 결정하고, 하한 자체를 움직이는 것은 바이트 수뿐입니다. 그리고 그 위쪽에서 지연이 어디에 사는지를 Fermion Research가 실측했습니다. A100에서 24층 모델의 같은 런타임 레인을 분해했더니 층들의 순수 DRAM 하한은 토큰당 104마이크로초였는데, 층들이 그 위로 590마이크로초를 더 썼습니다. 약 120개 커널 경계에서 각각 1마이크로초 정도의 실행 비용과 각 작은 커널 내부의 의존성 사슬입니다. 흥미로운 것은 그 다음입니다. 전체 스텝을 하나의 메가커널로 합쳐도 590마이크로초는 돌아오지 않았습니다. 융합된 커널 내부의 소프트웨어 배리어가 그것이 대체한 그래프 실행만큼의 비용을 내기 때문이고, 그래서 그 시간은 디스패치가 아니라 의존성 사슬에 속합니다. 이 관찰이 엔진이 커널 개수 대신 바이트 하한에 노력을 쏟는 이유입니다.

한 단계만 다르게 행동합니다. 마지막 은닉 상태를 전체 어휘 사전에 사영하는 언임베딩이 DRAM 루프라인에서 돌면서 스텝 전체 DRAM 트래픽의 43%를 차지합니다.

가중치는 고정비, 컨텍스트는 증가비

가중치는 예산의 정적인 절반입니다. 어텐션은 매 스텝 KV 캐시를 읽으므로, 컨텍스트 토큰 하나가 그 뒤의 모든 토큰이 다시 옮길 바이트를 더합니다. 8B의 기하 구조에서 캐시된 위치 하나의 비용은 16비트 정밀도로 이렇게 떨어집니다.

2 \times 36 \times 8 \times 128 \times 2 = 147{,}456 \text{ 바이트}

키와 값 각각, 36개 층, 8개 KV 헤드, 128 차원, 요소당 2바이트입니다. 즉 토큰당 144 KiB가 세션이 끝날 때까지 토큰별 트래픽에 합류합니다. GQA가 여기서 예산 작업을 하고 있습니다. 32개 쿼리 헤드를 모두 캐싱하면 네 배가 들었을 것입니다.

캐시 증가는 선형이고 가중치 포맷과 무관합니다. 4,096 토큰에서 0.60GB, 16,384에서 2.42GB, 32,768에서 4.83GB, 모델의 전체 40,960 창에서 6.04GB입니다. 약 26,000 토큰을 넘기면 캐시가 3.88GB 산출물보다 무거워지고, 엔진이 매 토큰 스트리밍하는 대상이 더 이상 주로 모델이 아니게 됩니다. fp16보다 네 배 작은 포맷은 이 교차점을 앞으로 당기므로, 캐시 트래픽이 엔진 예산에서 일급 항이 됩니다. 참고로 KV 캐시 자체를 줄이는 접근으로는 커뮤니티에 Google TurboQuant를 PyTorch로 구현한 KV 캐시 양자화 라이브러리 소개 글이 있습니다.

한 가지 표기 차이를 짚어 둘 필요가 있습니다. 제품 페이지는 KV 캐시를 "현재 기본값 fp32, 토큰당 288 KiB" 로 적지만, PyPI 릴리즈 노트의 0.1.10 항목은 "fp16 KV 캐시를 기본값으로(KV 메모리 절반)" 라고 적습니다. 제품 페이지의 기본값 표기가 CLI 현재 버전보다 뒤처져 있습니다.

하나의 파일, 네 개의 백엔드

같은 파일이 네 개 백엔드를 서비스합니다. CUDA를 통한 H100급 GPU, Apple M5의 GPU, M5의 CPU 코어, 데스크톱 x86입니다. 플랫폼별 재출력도, 품질 등급도, 수치가 다른 변종도 없습니다. 로더가 그 차이를 로드 시점에 한 번 해소하는데, 8B는 데이터센터 GPU에서 1.9초, 0.6B는 0.3초가 걸리며 값은 하나도 바뀌지 않습니다. 커널과 그 타일링, 명령어 선택은 공개되지 않은 부분입니다.

여기서 반드시 구분해야 할 것이 있습니다. 헤드라인으로 쓰이는 H100의 396 tok/s와 초안 적용 763 tok/s는 Hugging Face 카드의 런타임 표에서 "리서치 스택(research stack)" 으로 표기됩니다. 즉 오늘 내려받을 수 있는 산출물이 아닙니다. 실제로 출하되는 표면의 측정값은 다음과 같습니다.

플랫폼	표면	속도	메모리
H100 80GB	리서치 스택, 초안 적용	763 tok/s	미기재
H100 80GB	리서치 스택, 평문 그리디	396 tok/s	미기재
NVIDIA L4	GGUF 팩, CUDA 포크, 전체 오프로드	30.7 tok/s	4k 컨텍스트에서 4.68 GiB
Apple M5 16GB	MLX 팩, 3회 중위값	25.0 tok/s	6 GiB 상한에서 3.67 GiB 피크
Apple M5	`bin/` 네이티브 바이너리, CPU 전용, 9스레드	24.94 tok/s	8 GiB 미만 상주

GPU에서 오늘 쓸 수 있는 빠른 경로는 llama.cpp 포크뿐이고 L4에서 30.7 tok/s입니다. 카드의 바이너리 표는 bin/fermion-run-linux-cuda를 "곧 제공(아직 준비되지 않음, 현재 CUDA 대체 경로는 pip torch 경로)" 으로 적고, PyPI 문서는 "Windows, Linux arm64, 또는 --device cuda/mps에서는 torch 경로가 되며 정확하지만 한두 자릿수 느립니다" 라고 밝힙니다. 8 GiB 카드에 들어간다는 L4 수치는 실제로 유용하지만, 396과 763은 아직 사용자가 재현할 수 없는 숫자입니다.

토큰 동일성을 릴리스 게이트로 쓴다

엔진의 릴리스 게이트는 벤치마크가 아니라 비교입니다. 후보 빌드가 고정된 프롬프트 배터리를 그리디로 디코딩하고, 그 토큰 스트림을 완전 정밀도 구현의 저장된 기준 궤적과 위치별로 대조합니다. 검사는 위치당 이진이고 게이트는 절대적입니다. 배터리 어디에서든 토큰 하나가 어긋나면, 그것이 만든 속도 향상이 얼마든 빌드가 탈락합니다. 연구 글의 표현대로 "다른 토큰을 내놓는 스택은 다른 모델을 서비스하는 것이고, 원래 모델에 대해 공개된 모든 품질 수치가 그 스택에는 적용되지 않는다. 답을 바꾸는 속도는 속도가 아니다."

게이트는 모델이 건너는 모든 경계에서 돕니다. 엔진 빌드는 완전 정밀도 기준과, 초안 경로는 같은 산출물의 비초안 경로와, 변환된 팩은 엔진 자신의 궤적과, 수입된 외부 산출물은 그 기준 구현과 대조됩니다. llama.cpp 포크도 같은 규율을 따르며 tools/fermion-greedy 게이트 도구를 함께 싣습니다. CPU 백엔드는 원본 컨테이너의 fp32 전개와 토큰 단위로 동일하고(프롬프트 8개, 그리디 128스텝, 자유 실행 8/8 동일, 교사 강제 0/1024 불일치), CUDA 백엔드는 이 포크의 인증된 CPU 경로와 토큰 단위로 동일합니다. 포크의 수치 정책도 명시돼 있습니다. 활성값을 두 백엔드 모두 f32로 그대로 소비하고(CPU는 vec_dot_type = F32, CUDA는 융합 f32 GEMV와 TF32를 끈 순수 f32 cuBLAS), 모든 스케일은 컨테이너에서 그대로 복사한 f32이므로 "f32 기준 순전파와의 유일한 차이는 누산 순서" 라고 적습니다.

토큰 동일성의 경계: 그리디, float32, 그리고 두 개의 근접 동점

이 게이트는 인상적이지만 무조건 성립하는 것은 아니고, 세 개의 경계 조건이 모델 카드와 PyPI 문서에 흩어져 적혀 있습니다. 헤드라인만 읽으면 놓치기 쉬운 부분입니다.

첫째, 동일성은 그리디에서만 인증됩니다. 8B 카드가 명시합니다. "토큰 동일 출력은 그리디 디코딩(--temperature 0)에서 인증된다. 샘플링에서는 초안 출력이 비초안 출력과 같은 분포에서 뽑히지만 개별 토큰은 달라진다." pip 경로는 transformers의 거부 샘플링 보정을 타고, 리서치 CUDA 엔진과 MLX --spec 모드는 argmax 일치 수용을 쓰므로 그리디 전용입니다. 즉 온도를 올려 쓰는 실사용 구성에서 "속도만 바꾸고 답은 바꾸지 않는다" 는 문장은 개별 토큰 수준이 아니라 분포 수준의 주장입니다.

둘째, 동일성은 float32에서 성립하고 CLI 기본값에서는 아닙니다. PyPI 문서가 네이티브 경로의 알려진 차이를 두 가지 적는데, 그중 하나가 이렇습니다. "그리디 출력은 torch 기준 구현과 float32에서 토큰 단위로 동일하며, CLI의 bfloat16 기본값에서는 아니다. 그리고 동일성은 보장이라기보다 근접 동점의 성질이다. 두 독립 구현은 상위 두 로짓이 측정 잡음 안에 있을 때 서로 다른 토큰을 고른다." CLI 활성값 기본 dtype이 bfloat16인 이유도 함께 적혀 있는데, 8B 규모에서 fp16이 NaN 오버플로를 일으킨다는 실측 때문입니다.

셋째, 0.6B의 출하된 C 런타임은 fp 기준과 완전히 일치하지 않습니다. 0.6B 카드의 제약 절에 이렇게 적혀 있습니다. 고정된 게이트 프롬프트에서 그리디 디코드 패리티가 384개 위치 중 382개이고, int8 활성값 런타임과 fp 전개가 근접 동점 argmax 위치 두 곳에서 갈립니다(상위 두 로짓 마진 0.02에서 0.20). 그 두 번의 뒤집힘 이후 그리디 연쇄가 갈라지므로 원시 위치 일치는 384개 중 221개로 떨어집니다. 커널 출력 자체는 실행과 스레드에 걸쳐 결정적이라고 밝히고 있어 재현성 문제는 아닙니다. 0.6B-Chat도 같은 메커니즘의 뒤집힘이 몇 건 있다고 적습니다. 다만 이것을 8B로 옮겨 읽어서는 안 됩니다. 8B 카드는 torch 참조 경로가 네이티브 런타임 대비 768 토큰에서 그리디 불일치 0건 이라고 적습니다. 즉 근접 동점 뒤집힘은 지금까지 소형 컨테이너에서 문서화된 현상이고, 8B에서는 보고되지 않았습니다.

세 조건을 합치면 이렇게 읽는 편이 정확합니다. 토큰 동일성 게이트는 그리디, float32, 같은 구현 계열 안에서 엄격하게 작동하는 강한 규율이고, 정밀도나 샘플러나 구현이 바뀌는 경계에서는 근접 동점만큼의 여유가 있습니다. 그 여유를 문서에 적어 둔 것 자체가 이 릴리즈의 문서 품질에서 가장 좋은 부분입니다.

검증된 추측 디코딩: 속도만 바꾸고 답은 바꾸지 않는다

추측 디코딩(speculative decoding) 은 작은 모델이 앞서 달려 토큰 몇 개를 제안하고, 큰 모델이 그 전체를 한 번의 배치 순전파로 채점한 뒤 합의한 접두부를 취하는 기법입니다. 한 번의 순전파로 최대 7개 위치를 처리하므로 토큰마다 한 번씩 순전파하는 것보다 옮기는 바이트가 줄어듭니다. Neutrino의 구현은 초안 토큰을 8B 자신의 argmax와 같을 때만 받아들이므로, 그리디 디코딩에서 이 절차는 8B가 혼자 만들지 않았을 토큰을 절대 낼 수 없습니다.

한 주기는 네 단계입니다. 0.6B가 최근 수용률에서 정한 길이로 1개에서 7개 토큰을 초안으로 만들고, 8B가 모든 초안 위치를 단일 배치 순전파로 채점하고, 두 모델이 정확히 일치한 최장 접두부를 유지하고, 첫 불일치를 8B 자신의 토큰으로 대체한 뒤 주기가 다시 시작됩니다. 경제성은 크기 비율에서 나옵니다. 초안 산출물이 8B 바이트의 12분의 1이므로, 초안 6스텝과 검증 순전파 1회는 완전한 7스텝이 옮길 바이트의 5분의 1을 옮깁니다.

조합의 비용도 구체적으로 공개돼 있습니다. 두 컨테이너가 같은 포맷이고 같은 바이너리로 실행되므로 초안이 검증 모델의 프로세스에 그대로 올라가고 두 번째 배포나 변환 단계가 없습니다. 0.6B의 328MB가 8B의 3.88GB 옆에 앉아 상주 가중치는 4.20GB, 즉 초안 추가 부담이 8.46% 입니다. 캐시는 8B가 토큰당 288 KiB, 초안이 224 KiB로 합쳐 512 KiB이므로 4,096 토큰 컨텍스트에서 두 모델이 공유하는 캐시가 2 GiB입니다. 가중치 8% 추가로 최상단 1.9배를 얻는 교환이라 비용 구조 자체는 매력적입니다.

수용 길이는 엔진의 성질이 아니라 텍스트의 성질입니다. 596M 파라미터 모델이 8B와 다르게 고르기 전까지 다음 토큰 몇 개를 정확히 맞히는가입니다. 사실 완성형 프롬프트는 초안이 얼마나 길어져도 97에서 99%의 수용률을 유지하므로 컨트롤러가 그곳에서 긴 초안을 태우고, 코드와 적대적 세기는 정확한 접두부가 1개나 2개 토큰에서 결판나므로 컨트롤러가 짧게 끊고 순전파를 넘깁니다. 512 토큰당 검증 순전파 횟수로 보면 기술 설명이 75회, 사실이 86회, 코드가 181회, 적대적 세기가 200회입니다. 하나의 규칙을 아홉 개의 서로 다른 텍스트에 적용한 결과입니다. 동적으로 초안 길이를 조절하는 접근은 커뮤니티에도 하드웨어 인식 동적 추측 디코딩(DSD) 소개 글로 다뤄진 바 있습니다.

프롬프트 종류가 배속을 결정한다

배속은 프롬프트 종류에 따라 크게 갈리므로 하나의 헤드라인 숫자로 말할 수 없습니다. H100에서 평문 395.9 tok/s를 기준으로 3회 중위값을 재면 이렇습니다.

프롬프트 종류	배속	tok/s	수용 동작
세기 및 목록	1.93배	762.6	초안 토큰 100% 수용, 검증 순전파당 약 7토큰 방출
사실 및 단답	1.55배	613.0	96.5% 생존, 순전파당 6개 중 5.8개
산문 이어쓰기	1.34배	531.9	자유 서술
대화형 설명	1.13배	446.6	컨트롤러가 초안을 끄고 소액의 재동기화 비용을 지불
코드	1.07배	426.1	초안에게 가장 어려운 종류

모델 카드는 여기에 다른 배열의 같은 데이터를 싣는데, 코드 1.10배(437 tok/s), 산문 1.06배(422), 대화형 설명 1.01배(402)로 순서가 조금 다릅니다. 수용률도 두 카드가 어긋납니다. 0.6B 카드는 사실 프롬프트에서 초안 토큰의 96.5%가 살아남는다고 적는데, 8B 카드의 2026년 7월 27일 인증 실행 기준으로는 사실이 86.9%, 사실형 대화가 90.3%, 산문이 81.4%, 기술 설명이 50.0%입니다. 서로 다른 프로브를 인용하는 것으로 보이지만 두 문서가 같은 축에 다른 값을 싣는 것은 앞서 본 벤치마크 패턴과 같습니다. 어느 쪽이든 결론은 같습니다. 세기 프롬프트의 1.9배는 최상단이고 실무에서 흔한 코드와 대화에서는 1.1배 근처 입니다. 카드가 스스로 적은 표현대로 "추측 디코딩은 정확성 인증서가 붙은 처리량 기능이고, 품질을 바꾸지 않으며, 배속은 프롬프트에 의존한다. 위의 다섯 행이 정직한 범위이고 하나의 헤드라인 숫자가 아니다."

27,648 토큰 인증서가 어떤 구성에서 나왔는가

"27,648개 연속 토큰, 불일치 0" 은 이 릴리즈에서 가장 많이 인용되는 숫자입니다. 0.6B 모델 카드의 인증서 표를 읽으면 그 숫자가 어떤 구성에서 나왔는지가 분명해집니다.

스위트	구성	비교 토큰	결과
출하 브레인 인증	동적 초안 길이, 초안은 Neutrino-0.6B + 신뢰도 헤드	27,648	불일치 0
스토리 레그, 배포된 베이스 컨테이너를 초안으로, 증류 없음, 신뢰도 헤드 없음	k는 3, 4, 5	13,824	통과, 전부 동일
레인 전체 합산	위 항목 및 강제 거부 하한 검사 포함	41,472	어디에서도 불일치 없음

헤드라인 인증서는 신뢰도 헤드(confidence head) 를 포함한 구성에서 나왔고, 카드의 초안 산출물 핀 목록은 draft_v4.bin을 "증류된 dspec 초안, 별개의 산출물, 여기에 공개되지 않음" 으로 적습니다. 여러분이 내려받는 베이스 컨테이너로 재현되는 인증서는 고정 k에서 13,824 토큰입니다. 그리고 카드는 그 차이의 크기까지 밝힙니다. "증류는 수용률을 10에서 25 퍼센트포인트 올린다(산문 93.6 대 약 70에서 77, 코드 85 대 약 50). 여기에 신뢰도 헤드와 동적 k 계층이 더해진다." 고정 k에는 초안을 끄는 장치가 없으므로 하위 종류에서는 1.0배 아래로 떨어져 k가 3일 때 0.46배, 5일 때 0.34배가 됩니다. 동적 컨트롤러와 증류된 초안의 하한이 0.75배입니다.

즉 공개된 가중치만으로도 정확성은 인증되지만, 763 tok/s를 만든 구성 전체가 공개된 것은 아닙니다. 초안 모델을 다루는 오픈소스 접근을 찾는다면 커뮤니티의 TorchSpec이나 DeepSpec 소개 글이 참고가 됩니다.

노트북에서는 이야기가 다르다

이 조합은 노트북에서도 돕니다. 16GB Apple M5에서 두 모델이 한 프로세스에 6 GiB 하드 상한 아래로 올라가 4.3 GiB를 피크로 쓰고, 프롬프트 6개 중 6개가 초안을 켜고 끈 결과가 토큰 단위로 동일했습니다. 사실 프롬프트에서 평문 22.00 tok/s가 초안 적용 25.71 tok/s가 되어 1.168배이고 수용률은 74.4%입니다.

그런데 제품 페이지에는 없고 0.6B 모델 카드에만 있는 내용이 있습니다. Apple 실리콘에서 대화와 산문은 오히려 느려집니다. 카드의 표현입니다. "Apple에서 처리량은 종류에 의존한다. 사실은 22.00에서 25.71 tok/s(1.168배)로 오르지만, 대화(0.837배)와 산문(0.680배)은 퇴행한다. 배치 검증이 단일 스텝의 약 2.8배로 연산 제약을 받아 손익 분기가 라운드당 약 2.9개 수용 토큰을 요구하는데, 베이스 초안의 해당 종류 수용률은 0.30에서 0.44다." 코드 종류는 MLX에서 측정되지 않았습니다. 결론은 카드가 직접 적어 두었습니다. "Apple에서는 사실 조회 워크로드에만 --spec을 쓰라." Apple 실리콘 추론 최적화에 관심이 있다면 커뮤니티의 cider: Apple Silicon M5의 INT8 TensorOps로 LLM prefill 속도를 끌어올리는 MLX W8A8 추론 SDK 소개 글도 함께 볼 만합니다.

남의 가중치로도 이기는가: 타 스택 대결 기록

엔진이 자기 가중치에만 최적화된 것인지 확인하려면 남의 산출물로 재는 것이 맞습니다. Fermion Research는 프로토콜을 고정해 그 대결을 공개했습니다. 두 스택이 같은 기계에서 같은 세션에 라운드를 교차로 돌려 열 상태와 클럭 드리프트가 양쪽에 똑같이 실리게 하고, 어떤 속도도 세기 전에 기준 구현 출력과의 토큰 동일성 검사를 먼저 통과시킵니다. 수입도 같은 방식으로 통제해, 외부 산출물을 자체 컨테이너로 번역한 뒤 모든 텐서를 원본 파일과 비트 단위로 검증하고 나서야 한 라운드를 돕니다.

가장 확인하기 쉬운 항목은 두 번째입니다. 공개된 BitNet b1.58-2B4T 가중치를 자체 컨테이너에 올려 16GB Apple M5에서 디코딩하면 102.4 tok/s가 나오고, 같은 기계 같은 세션에서 기준 bitnet.cpp 빌드는 89.0 tok/s입니다. 배터리와 열 조건을 공유한 3회 동시 라운드이고, Apple 실리콘에서 그 모델에 대해 이보다 빠른 단일 스트림 속도는 저자들을 포함해 누구도 공개한 바 없다고 주장합니다. 같은 모델을 A100에서는 해당 연구소 자체 GPU 커널보다 1.77배 빠르게 돌렸습니다. bitnet.cpp에 관해서는 커뮤니티에 Microsoft가 공개한 x86 및 ARM 기반 CPU에 최적화한 BitNet 추론 프레임워크 소개 글이 있습니다.

나머지 항목은 공개된 27B 3진 모델에서 105.15 tok/s 대 기준 스택 97.80 tok/s로 6라운드 중 6라운드 승리이며 자기 최저 라운드가 상대 최고 라운드보다 높고, 파일은 공개 산출물보다 19% 작았습니다. 데스크톱 x86에서는 T-MAC 같은 룩업 테이블 스택을 그 스택의 홈 명령어 집합에서 2.12배로 앞섰고, 단일 토큰 수준에서는 GEMV가 Marlin 계열 int4 GEMV 커널보다 12에서 13% 앞섭니다. 프로토콜이 잘 설계돼 있어서 이 부분은 이 릴리즈에서 가장 신뢰할 만한 주장입니다. 다만 커널 자체가 공개되지 않았으므로 외부 재현은 불가능합니다.

작은 모델 두 개: 초안과 대화

Neutrino-1 0.6B: 정직하게 낮은 지식 점수

0.6B 모델 카드는 이 릴리즈에서 가장 정직한 문서입니다. 첫 문단부터 이렇게 시작합니다. "이 모델은 한 가지 목적으로 존재한다. Neutrino-8B의 인증된 추측 디코딩 초안이다. 어시스턴트가 아니다. 채팅 튜닝도, 지시 준수도, 도구 사용도 없고, 단독 지식은 의도적으로 주장 대상이 아니다."

숫자가 그 말을 뒷받침합니다. 7개 상식 과제 평균 42.21, ARC-easy 53.45, PIQA 62.79, HellaSwag 31.64, OpenBookQA 19.60입니다. MMLU 전체 57과목은 26.66으로 우연 수준 근처이고, 카드는 이것을 "7B 미만의 지식 전환 하한" 이라는 자체 관찰로 설명합니다. GSM8K는 유연 추출 1.67, 엄격 일치 0.00입니다. BFCL v3 매크로는 15.38인데 카드가 그 정체를 명시합니다. "함수를 절대 호출하지 않는 퇴화 프로필(관련성 없음 판정 100.0, 라이브 관련성 없음 100.0, 호출 관련 10개 하위 집합 전부 0.0). 이 모델을 함수 호출에 쓰지 마시오."

여기서 8B 이야기와 반드시 함께 읽어야 할 수치가 있습니다. 카드가 참고용으로 실어 둔 이 계열의 fp32 기준 상수는 MMLU 46.9, 7개 과제 평균 53.5입니다. 즉 같은 파라미터 수의 완전 정밀도 모델이 MMLU 46.9를 받는 자리에서 3진 컨테이너는 26.66을 받았습니다. 8B에서 일반 지식 96%가 유지된 것과 대비하면 0.6B에서는 MMLU 유지율이 57% 수준으로 떨어집니다. 7개 상식 과제 평균은 42.21 대 53.5로 79% 정도가 남아 앞서 인용한 81.6%와 대체로 맞습니다. 정리하면 이 포맷의 지식 보존은 규모에 의존합니다. 8B에서 성립한 "지식은 가중치의 덩어리 성질" 이라는 설명은 파라미터가 충분히 많아 중복 저장이 가능할 때의 이야기이고, 596M에서는 그 여유가 없어 지식 축이 먼저 무너집니다. 카드가 LAMBADA 25.79를 인용하며 "장거리 마지막 단어 예측이 이 규모에서 가장 먼저 얇아지는 능력이고, 아래 GSM8K와 종료율 셀의 기계적 설명" 이라고 적은 것이 같은 현상의 다른 얼굴입니다. 같은 과제들에서 8B는 SciQ 95.90, COPA 84.00, MNLI 56.65, LAMBADA 54.57을 받아 0.6B의 80.40, 63.00, 35.45, 25.79와 뚜렷하게 갈립니다.

이 SKU의 진짜 매력은 지식이 아니라 속도와 크기입니다. 네이티브 바이너리로 Apple M5 CPU에서 225에서 236 tok/s, 같은 M5에서 MLX와 Metal 커널로 201.16 tok/s(5회 중위값)이며 이때 피크 메모리가 0.526 GiB 입니다. 모델과 작업 세트 전체가 0.5기가바이트 남짓에 들어간다는 뜻입니다. GGUF 팩은 CPU 16스레드에서 55.38 tok/s이고, 8B 프로세스 안에서 C로 서비스되는 초안 워커로는 H100에서 1,177 tok/s, 토큰당 0.85밀리초입니다. 그 여유가 8B가 한 번 검증하는 시간에 초안 여섯 개를 만들 수 있게 하는 근거입니다. 계보는 Qwen3-0.6B에서 3진 QAT 15K 스텝, 이어서 1.5K 스텝의 지식 증류 기반 감쇠를 거쳐 16500 스텝 지점을 출하한 것입니다.

카드가 밝힌 투명성 항목 하나를 덧붙일 만합니다. 8B의 행동 학습 레시피를 4분의 1에서 전체 용량까지 이 체크포인트에 적용해 보고 사전 등록한 가드 밴드를 통과하지 못해 출하하지 않았습니다. 4분의 1 용량에서 지시 준수가 8.6포인트 올랐지만 일반 능력 가드가 모든 용량에서 실패했습니다. 그래서 출하된 체크포인트는 손대지 않은 감쇠 베이스이고, "공개하지 않은 행동 학습은 없다" 고 명시합니다.

완전 정밀도 기준과의 비교도 카드 쪽이 더 정확합니다. 동일한 596,049,920 파라미터에서 7개 공통 과제 능력의 81.6%를 15.8%의 바이트로(238MB 대 1,503MB), 측정한 11개 과제 전체 평균으로는 78.0%를 유지합니다. 가장 잘 유지된 축은 Winogrande 91.5%와 PIQA 90.4%입니다. 참고로 연구 글이 인용하는 "Qwen3-0.6B의 ARC-easy의 87.9%를 6.3배 적은 바이트로" 라는 문장에 대해, 모델 카드는 그것이 "다르게 조달된 기준 수치에 대한 단일 셀 판독이었고 이 결과가 그것을 대체한다" 고 적습니다. 그리고 한 문장을 더 붙입니다. 2026년 7월 27일에 돌린 동일 하네스 1B 미만 코호트 격자(경쟁 체크포인트 7개 곱하기 11개 과제, 77개 셀)에서 이 모델은 대부분의 과제에서 코호트의 하위권 또는 최하위 라는 것입니다.

Neutrino-1 0.6B-Chat: 184개 사실과 예절

0.6B-Chat은 같은 컨테이너를 대화용으로 마무리한 것이고, 기하 구조와 묶인 임베딩 테이블과 컨테이너 크기가 베이스 SKU와 동일합니다. 바이트 레인이 텐서 모양에서 결정되고 모양이 바뀌지 않았기 때문입니다. 학습 비용도 공개됐는데, H200 한 장에서 순수 교차 엔트로피 300스텝, 벽시계 0.161시간, 약 0.87달러이고 랜 전체가 30달러 상한 중 약 4달러를 썼습니다. 스냅샷은 100, 200, 300스텝에서 떴고 100스텝 지점이 출하됐습니다.

여기서 한 가지를 바로잡아 둘 필요가 있습니다. 연구 글은 "채팅 튜닝이 모든 사영에서 상태 점유율을 0.1퍼센트포인트 미만으로 움직였고 묶인 임베딩 테이블은 바이트 단위로 동일하게 남았다" 며 이 크기에서 정렬이 사영 안의 3진 상태 재배치에 가깝다고 적습니다. 그런데 0.6B-Chat 모델 카드는 그 수치가 이 컨테이너의 것이 아니라고 명시적으로 물러섭니다. 해당 상태 점유율 델타는 sha가 다른 직전 세대 채팅 익스포트 의 것이며, "따라서 이 SKU를 설명하지 않고, 여기에는 하나도 인용하지 않는다" 고 적습니다. 출하된 컨테이너에 대한 가중치 상태 걸음은 아직 수행되지 않았고 발행 전 과제로 남아 있습니다. 즉 "정렬은 바이트에서 무료" 라는 문장 중 검증된 부분은 컨테이너 크기가 같다는 것뿐이고, 상태 재배치의 규모는 이 SKU에서 측정되지 않았습니다.

이 모델의 제품 기준은 지식이 아니라 대화 행동입니다. 그래서 지식 계측기를 의도적으로 면제 했습니다. 카드의 표현대로 "MMLU, MMLU-Redux, IFEval, BFCL, GSM8K, ARC, HellaSwag, Winogrande, C4 퍼플렉시티는 이 SKU에서 의도적으로 측정되지 않았다." 대신 세 개 런타임 각각에서 행동 배터리를 돌렸습니다.

런타임(설정)	종료율(기준 0.60 이상)	루프율(0.05 이하)	정형성(0.95 이상)	정체성 8문항
`fermion-run` C 바이너리(temp 0.01, rp 1.05)	0.885	0.045	1.000	8/8
MLX 팩(그리디, rp 1.05)	0.850	0.050	1.000	8/8
transformers 4.53.2(그리디, rp 1.05)	0.850	0.045	1.000	8/8

문장 조각 20개 전부에 답하고, 상식 질문 30개 전부에 정답 또는 정직한 불확실성으로 답하며, 터무니없는 답 0건, 채팅 템플릿 누출 0/5입니다. 다만 지식 범위가 엄선된 184개 상식 이고 그 밖에서는 모른다고 말하도록 훈련됐습니다.

이 만점들을 일반화 성능으로 읽으면 안 됩니다. 카드가 직접 그 선을 그어 둡니다. 문장 조각 20문항, 상식 30문항, 반템플릿 5문항의 표현이 "학습 코퍼스에 등장할 수 있다" 며, 이들은 설치 확인용 표면(install-check surface) 이고 주장하는 것은 "이 행동들이 고정됐다는 것이지 일반화된다는 것이 아니다" 라고 적습니다. 일반화 판독은 따로 있는데, 학습에 쓰지 않은 별도 슬라이스에서 처음 보는 속어 조각 10문항 중 10개가 자연스러웠고 바꿔 쓴 사실 질문 10문항 중 8개 였습니다. 200문항 대화 홀드아웃과 100문항 부조리 요청 프로브는 빌드 시점에 코퍼스에 섞이지 않도록 실패 시 차단 방식으로 강제하고 200개 문서를 표본 재감사했다고 밝힙니다. 즉 30/30은 앵커가 걸렸다는 확인이고, 실제 기대치는 8/10 쪽입니다.

선정 자체는 기계적으로 진행됐습니다. 세 개 용량(100, 200, 300스텝)을 학습해 채점하고, 어떤 것도 돌기 전에 얼어 둔 규칙으로 승자를 골랐습니다. 모든 기준을 통과한 arm 중 상식 점수 최대, 다음 문장 조각 점수 최대, 다음 낮은 용량입니다. 흥미로운 것은 200스텝 arm이 루프율 0.060으로 기준선 0.05를 넘겨 탈락 했다는 점입니다. 300스텝은 루프율 0.015로 적격이었지만 규칙상 낮은 용량이 이겨 100스텝이 출하됐습니다. 카드의 결론은 "대화 교정은 100스텝에서 완전히 설치되고, 용량을 세 배로 늘려도 사실 정확도는 더해지지 않는다" 입니다. 학습 코퍼스는 8개 레인에 걸친 3,000,610 토큰이고 레인마다 자체 수용 게이트가 있습니다. 조각 행은 대화에 응해야 하고 마무리 인사로 끝나면 안 되며, 사실 행은 사실별 정답 정규식과 일치해야 하고, 불확실성 행은 겸손 표지를 담고 날짜나 수치를 지어내면 안 되며, 반템플릿 행은 정체성 문장을 절대 내보내면 안 됩니다.

이 마무리가 실제로 무엇을 고쳤는지도 공개돼 있습니다. 직전 세대는 같은 판정자에서 문장 조각 20문항 중 14개, 템플릿 누출 5문항 중 2건이었고, hi에 "You're welcome! Bye for now." 라고 답하고 달을 작고 어두운 물의 덩어리 라고 설명했습니다. 300스텝 교차 엔트로피가 고친 것이 이 종류의 실패입니다. 카드가 실제 출력을 그대로 싣는데, who you에 "I'm Neutrino, a tiny language model made by Fermion Research. What's up? How can I help?", what is the moon에 "The Moon is a natural satellite that orbits Earth. It reflects sunlight, which makes it visible in the night sky." 같은 응답입니다. 구조화된 출력은 이 모델의 영역이 아닙니다. 아홉 개 설정 셀 전부에서 전체 응답 JSON 유효성이 0/8이었고, 카드는 스키마 형태의 작업을 8B로 보내라고 안내합니다.

한 가지 표기 차이가 있습니다. 모델 인덱스 페이지는 0.6B-Chat의 Apple M5 CPU 속도를 170에서 218 tok/s로 적지만, 해당 모델 카드는 "이 컨테이너에서 디코드 속도 벤치마크가 돌아간 적이 없으므로 여기에 tok/s 수치를 인용하지 않는다" 고 명시합니다. 카드가 더 보수적입니다.

실행해보기: pip부터 llama.cpp 포크까지

기준 표면은 pip 패키지입니다. 엔진, 로더, 채팅 프론트엔드가 하나의 휠에 들어 있고, 같은 저장소가 macOS arm64와 Linux x86-64용 사전 빌드 정적 바이너리를 함께 싣습니다.

pip install fermion-research
fermion chat --model fermionresearch/Neutrino-8B

첫 8B 실행에서 fermion 0.1.9 이상은 2.56GB 부호화 전송 파일을 진행 표시와 함께 내려받고 SHA-256을 검증한 뒤 로컬에 풀어 놓습니다. 이후 실행은 캐시에서 로드합니다. 0.1.11부터는 다운로드 전에 캐시 디렉터리의 여유 공간을 먼저 확인하고, 부족하면 디렉터리 경로와 필요 바이트, 여유 바이트를 출력합니다. 전송 파일은 SHA 검증된 디코드 이후 삭제되므로 8B 캐시 사용량이 약 6.4GB에서 약 3.9GB로 줄어듭니다.

OpenAI 호환 로컬 서버도 한 줄입니다. 도구 호출, 스트리밍, 턴 사이에 KV 캐시를 재사용하는 영속 세션 런타임이 기본으로 켜져 있어 Open WebUI, Continue, LangChain, LlamaIndex 같은 클라이언트에 그대로 붙습니다.

fermion serve --model fermionresearch/Neutrino-8B
# http://127.0.0.1:8000/v1 에서 서비스. API 키는 아무 문자열이나 가능

다만 이 서버는 한 번에 하나의 요청만 처리합니다. 상주 모델이 하나이고 락 뒤에서 직렬화되며, n > 1과 임베딩은 구현되지 않았다고 문서가 밝힙니다. 에이전트 하네스를 붙일 때 도움이 되는 것은 0.1.7에 들어간 영속 세션 런타임인데, 턴 사이에 KV 캐시를 재사용해 에이전트 턴이 최대 72배 빨라진다 고 적혀 있습니다. 0.1.8은 다중 대화 KV 캐시를 넣어 에이전트 프레임워크가 세션을 밀어내지 않게 했고 MCP 계열 클라이언트를 위한 도구 이름 별칭도 추가했습니다. 0.1.6의 배치 프리필은 프리필을 4에서 5배 끌어올렸습니다. 기본 샘플러는 fermion chat과 serve가 채점된 출하 설정(온도 0.01, top-p 1.0, 256 토큰 창에 반복 페널티 1.05)이고, fermion generate만 결정적 그리디입니다. 추측 디코딩을 직접 붙이려면 --draft PATH로 두 번째 컨테이너를 초안으로 지정하며, 초안은 토크나이저를 공유해야 합니다.

설치 단계에서 걸리는 실무 함정도 문서화돼 있습니다. Linux에서는 pip install이 torch의 CUDA 휠 스택을 끌어와 설치에 약 8GB를 쓰고, 그중 약 3GB를 /tmp에 임시로 쌓습니다. /tmp가 RAM 기반 tmpfs인 환경에서 자주 실패하는 지점입니다. CPU 전용 장비라면 torch를 CPU 인덱스에서 먼저 설치해 약 7.5GB 대신 약 1GB로 줄이라고 안내합니다.

pip install torch --index-url https://download.pytorch.org/whl/cpu
export HF_HOME=/big/disk/hf            # 모델 캐시
export FERMION_CACHE_DIR=/big/disk/fermion   # 이 CLI의 모델 다운로드만
export TMPDIR=/big/disk/tmp            # pip 스테이징

Apple 실리콘에서는 pip 설치는 작지만 첫 8B 페치에 캐시 볼륨의 여유 공간이 약 6.5GB 필요합니다. 2.6GB 전송 파일과 3.9GB 복원 컨테이너가 한순간 함께 디스크에 있기 때문이고, SHA-256 검증을 통과하면 전송 파일이 삭제되어 정상 상태 사용량은 약 3.9GB가 됩니다.

transformers로 직접 쓸 수도 있습니다. import fermion이 먼저 와야 trtc_v4 모델 타입이 등록되고, 로더가 컨테이너를 로컬 경로 기준으로만 해소하므로 저장소를 먼저 내려받아야 합니다.

import fermion  # registers the trtc_v4 model type -- must come first
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("Neutrino-8B")   # the downloaded directory
tokenizer = AutoTokenizer.from_pretrained("Neutrino-8B")
inputs = tokenizer.apply_chat_template([{"role": "user", "content": "hi"}],
                                       add_generation_prompt=True,
                                       enable_thinking=False,
                                       return_tensors="pt", return_dict=True)
out = model.generate(**inputs, max_new_tokens=256)  # generation_config: greedy
n = inputs["input_ids"].shape[1]
print(tokenizer.decode(out[0][n:], skip_special_tokens=True))

GGUF 팩은 포크를 통해서만 로드됩니다. FV5와 FV5B 타입을 상위 llama.cpp가 모르기 때문에 표준 llama.cpp, Ollama, LM Studio 빌드는 이 팩을 거부합니다. 포크 스스로 자기 위치를 이렇게 규정합니다. "GGUF는 호환성의 문이다. Fermion의 네이티브 런타임과 융합 커널이 여전히 속도의 문이며, 이 포크는 최고 속도가 아니라 배포된 컨테이너 함수와의 정확성 패리티를 위해 최적화한다." 팩을 직접 변환할 필요는 없고, 이미 만들어진 Neutrino GGUF 팩을 내려받아 SHA256SUMS로 검증한 뒤 포크를 빌드해 그 파일을 가리키면 됩니다.

git clone https://github.com/fermionresearch/llama.cpp && cd llama.cpp
git checkout fermion-fv5
# CPU + CUDA (full offload supported)
cmake -B build -DCMAKE_BUILD_TYPE=Release -DLLAMA_CURL=OFF -DGGML_CUDA=ON
cmake --build build -j --target llama-server llama-bench llama-completion
./build/bin/llama-server -m neutrino-8b-fv5.gguf -ngl 99 -c 4096 --host 127.0.0.1 --port 8080

여기에 실무적으로 중요한 예고가 하나 붙어 있습니다. 포크가 FV5 = 43과 FV5B = 44를 고정 베이스 커밋의 GGML_TYPE_COUNT 뒤에 덧붙였는데, 상위 저장소의 타입 공간이 그 사이 43까지 자라서 id가 충돌합니다. 포크의 계획은 현재 릴리즈는 고정 베이스에 머무르고, 리베이스 시점에 타입 id를 당시의 GGML_TYPE_COUNT로 재번호하며 GGUF 팩을 다시 내보내고 두 정확성 게이트를 재실행하는 것입니다. 팩이 모든 텐서 헤더에 타입 id를 인코딩하기 때문입니다. 상위 반영을 위한 PR은 TQ1_0과 TQ2_0이 들어간 방식을 따라 float에서 FV5로 가는 참조 양자화기를 의도적으로 생략하고 제안할 계획이라고 적혀 있습니다. 즉 지금 만든 GGUF 팩은 나중에 다시 받아야 할 가능성이 높습니다. llama.cpp를 포함한 여러 스택으로 서빙하는 실전 레시피는 커뮤니티의 Club-3090 모음에서 참고할 수 있습니다.

전체 CLI

fermion chat      an interactive streaming chat (session cache on by default)
fermion serve     a local OpenAI-compatible API with tool calling and streaming
fermion generate  one-shot completion, deterministic by default for scripts
fermion info      verify a download: container header + SHA-256 against the manifest
fermion bench     measure decode speed on your machine
fermion inspect   look inside a container: weight occupancy, per-layer bytes
fermion verify    certify a draft/target pair produces identical tokens

fermion inspect와 fermion verify가 눈에 띕니다. 이 글에서 인용한 컨테이너 걸음 측정과 초안 인증서를 사용자가 직접 재현할 수 있게 만든 명령들입니다. 검증 가능성을 도구로 내보낸 선택은 평가할 만합니다.

용도별 권장 설정: 8B는 구조화된 출력이 되고, 길이 예산을 줘야 합니다

8B 카드는 대화, 사실, 구조화, 장문 네 개 슬라이스를 온도와 반복 페널티 조합으로 훑어 용도별 설정을 정리해 뒀습니다.

용도	온도	top-p	반복 페널티	최대 신규 토큰
대화 및 어시스턴트	C 바이너리 0.01, torch 0	1.0	1.05(창 256)	512
도구 호출 및 구조화 출력	0(그리디)	조정 없음	1.0(끔)	256
장문 산문	0.7	0.95	1.05(창 256)	1024
결정적 실행 및 벤치마크	0(그리디)	조정 없음	1.0(끔)	256

여기서 실무적으로 가장 쓸모 있는 관찰이 두 개 나옵니다. 첫째, 구조화된 출력은 8B의 능력입니다. 도구 형태 프롬프트에서 코드 펜스 없이 응답 전체가 파싱 가능한 JSON으로 나온 비율이 시도한 모든 셀에서 8/8이고 온도 0.7에서도 그렇습니다. 즉 이 축은 샘플러에 민감하지 않습니다. 그럼에도 반복 페널티는 끄라고 안내하는데, JSON이 ", :, { 를 반복해야 하는 형식이라 그 구두점에 페널티가 걸리는 것이 형식을 깨뜨릴 수 있는 유일한 지점이기 때문입니다. 0.6B-Chat이 같은 프롬프트에서 0/8이었으므로 스키마 형태의 작업은 8B로 보내는 것이 맞습니다.

둘째, 512와 1024라는 토큰 예산은 취향이 아니라 측정값입니다. 150 토큰 상한에서는 대화 슬라이스가 모든 셀에서 2번 중 0번만 정상 종료했고 장문 생성은 전부 상한에 부딪혔습니다. 카드의 표현대로 "8B는 말이 많으니 여유를 주라" 는 것입니다. 반복 페널티는 보험이지 해결책이 아니라고도 적는데, 루프율이 네 개 셀 전부에서 페널티 유무와 무관하게 0.000이었기 때문입니다. 한 가지 조건은 붙습니다. 이 스윕은 직전 세대 컨테이너에서 돌린 것이고 출하 컨테이너에 대해 재실행되지 않았으며, 장문 행의 top_p 0.95는 유일하게 측정되지 않은 값으로 온도 0.7의 관례적 조합이라고 밝힙니다.

서빙 설정이 곧 산출물의 일부다

0.6B-Chat 카드가 강조하는 내용은 다른 모델에도 적용되는 교훈입니다. 행동 기준선이 런타임마다 하나의 문서화된 설정에서만 성립합니다. 반복 페널티 1.05는 장식이 아니라 하중을 받는 부품입니다. 같은 컨테이너에서 페널티 1.00이면 루프율이 0.06으로 기준선 0.05를 넘고, 1.05에서 0.045로 내려옵니다. 종료율 0.885도 그대로 받아들이면 안 됩니다. 카드가 풀어 적은 대로 응답 일곱 개 중 하나 정도는 스스로 멈추지 않고 토큰 상한에 도달 하므로, 지불할 의사가 있는 max_new_tokens를 정해 두라고 안내합니다.

C 바이너리에는 함정이 하나 있습니다. --temp 0에서 바이너리가 순수 argmax 빠른 경로를 타면서 --rep-pen과 모든 페널티 플래그를 조용히 무시하므로 짧은 턴 루프가 돌아옵니다. 그래서 문서화된 설정이 --temp 0.01입니다. argmax에 가깝고 샘플러를 실제로 켜는 값입니다. --stop-id 151645도 선택이 아닙니다. 없으면 바이너리가 고정 길이 경주 모드로 돌면서 EOS를 무시하고 요청한 토큰 수를 정확히 그만큼 내보냅니다.

페널티가 두 번 적용되는 함정도 문서화돼 있습니다. generation_config.json이 repetition_penalty: 1.05를 싣고 있으므로 직접 호출에 페널티를 또 얹으면 실측 1.1025, 즉 1.05의 제곱이 됩니다. transformers가 전체 컨텍스트 프로세서와 자체 윈도 프로세서를 병합하지 않고 쌓기 때문입니다. fermion CLI는 자기 윈도 프로세서를 설치하기 전에 repetition_penalty=1.0을 고정해 이 조합을 막습니다.

정리: 확인된 것과 유보할 것

이 릴리즈에서 확인 가능하고 설득력 있는 부분 은 다음과 같습니다. 사후 반올림과 네이티브 학습 사이의 절벽은 공개 기록으로 뒷받침되고, 8B급에서 3비트 저장으로 MMLU 72.1을 유지한 산출물이 실제로 내려받아 재현할 수 있는 형태로 존재합니다. C4 퍼플렉시티가 21.48 대 베이스 21.40으로 사실상 평탄한 것이 그 주장을 지식 배터리 밖에서 뒷받침합니다. 출하된 컨테이너를 직접 걸어 얻은 측정, 즉 252개 텐서의 0 점유율 격자와 초기 피드포워드 층의 침묵, 부호 균형, 층별 부호화 비율과 0 비율의 마이너스 0.92 상관은 fermion inspect로 재현 가능한 정직한 계측입니다. 토큰 동일성을 릴리스 게이트로 쓰는 규율과 그것을 llama.cpp 포크까지 게이트 도구와 함께 확장한 것, 축별 유지율을 평균내지 않고 공개한 것, 행동 축의 교환 관계를 정량적으로 적은 것, 그리고 8B가 온도 0.7에서도 파싱 가능한 JSON을 8/8로 내놓는다는 실용적 계측도 이 분야에 남을 관찰입니다.

유보하거나 다르게 읽어야 할 부분 도 분명합니다. 헤드라인의 "fp16의 8분의 1 비트"는 회선 위 밀도이고, 디코드 속도를 지배하는 산출물 비율은 4.2배입니다. 발표 글의 여섯 모델 비교 표를 끝까지 읽으면 이 모델은 지식과 수학에서 앞서는 대신 지시 준수와 도구 호출에서 수치를 공개한 경쟁 모델 중 가장 낮고, 컨텍스트 길이도 40,960으로 짧으며, Apple 노트북 디코드 속도는 같은 3진 계열 경쟁 모델보다 느립니다. 제품 페이지의 벤치마크는 모델 카드의 릴리즈 배터리보다 IFEval, BFCL, GSM8K에서 일관되게 높으며, 실제 가중치를 평가할 기준은 카드 쪽입니다. H100의 396과 763 tok/s는 출하되지 않은 리서치 스택 수치이고, 오늘 GPU에서 쓸 수 있는 빠른 경로는 L4에서 30.7 tok/s의 llama.cpp 포크입니다. 27,648 토큰 인증서는 공개되지 않은 증류 초안과 신뢰도 헤드를 포함한 구성의 결과이며, 공개 컨테이너로 재현되는 인증서는 13,824 토큰이고 고정 k에서는 일부 종류가 1.0배 아래로 떨어집니다. 토큰 동일성 자체도 그리디와 float32라는 경계 안에서 성립하고, 0.6B의 C 런타임은 fp 기준과 384개 위치 중 382개에서 일치합니다. Apple 실리콘의 추측 디코딩은 사실 조회에서만 이득이고 대화와 산문에서는 퇴행합니다. 그리고 빠른 경로 바이너리와 커널, 학습 방법, 양자화기 파라미터는 공개되지 않았습니다.

규모에 대한 조건도 분명히 해 둘 필요가 있습니다. 이 포맷의 지식 보존은 8B에서 일반 지식 96%로 인상적이지만 0.6B에서는 MMLU가 fp32 기준 46.9에서 26.66으로 내려가 절반 가까이 잃습니다. "지식은 가중치의 덩어리 성질이라 중복 저장되어 살아남는다" 는 설명이 성립하려면 중복을 감당할 파라미터가 있어야 하고, 596M에는 그 여유가 없습니다. 따라서 이 릴리즈를 "3진 포맷이 규모와 무관하게 지능을 보존한다" 로 일반화하면 원문이 실제로 측정한 것보다 넓게 읽는 것입니다. 상태 통계가 14배 규모 차이에서 상수라는 발견은 포맷의 성질 에 관한 것이고, 능력 보존이 규모에 의존한다는 것은 별개의 사실입니다.

로컬 및 온디바이스 추론을 따라가는 입장에서 이 릴리즈의 실용적인 가치는 이렇습니다. 16GB 노트북에서 8B급 어시스턴트를 24에서 34 tok/s로 돌릴 수 있고, 8GB VRAM 카드에 4.68 GiB로 들어가며, 세 모델이 같은 바이너리를 공유해 가중치 8% 추가만으로 초안 구성을 붙일 수 있습니다. 스키마 형태의 작업에는 8B가 쓸 만하고, 외부 API 스키마를 그대로 받는 에이전트 경로에서는 BFCL 라이브 스위트의 절반 가까운 하락을 감안해야 합니다. 그 정도는 지금 확인할 수 있는 사실입니다. 그 위의 숫자들은 어느 축을 재고 있는지 확인한 다음에 인용하는 편이 안전합니다.

라이선스

세 모델의 가중치는 모두 Apache License 2.0으로 배포되어, 연구 목적은 물론 상업적 용도로도 자유롭게 사용, 수정, 파인튜닝, 재배포가 가능합니다. 접근 요청이나 동의 양식도 없습니다. 8B는 Qwen3-8B, 두 0.6B는 Qwen3-0.6B의 파생물이며 원본도 Apache-2.0입니다. pip 패키지도 Apache-2.0이고, llama.cpp 포크는 상위 llama.cpp를 따라 MIT입니다.

한 가지 예외가 있습니다. 저장소의 bin/ 아래에 함께 실리는 fermion-run 네이티브 바이너리는 사전 빌드된 비공개 소스 이며 별도 EULA를 따릅니다. 해당 가중치와 함께 무료로 사용할 수 있지만 저장소 외부 재배포와 역공학이 금지됩니다. PyPI 문서의 표현대로 이 네이티브 런타임이 "공개된 모든 tok/s 수치가 측정된 경로" 이므로, 속도를 만드는 부분은 오픈소스가 아닙니다. MIT로 공개된 llama.cpp 포크가 유일한 예외이고, 그 경로의 L4 30.7 tok/s가 외부에서 검증 가능한 유일한 GPU 수치입니다.

Introducing the Neutrino-1 models 소개 블로그

Intelligence at one-eighth the bits 연구 글

The Neutrino Engine 연구 글

Neutrino-1 8B 모델 페이지

Neutrino-1 8B Hugging Face 모델

Neutrino-1 0.6B Hugging Face 모델

Neutrino-1 0.6B-Chat Hugging Face 모델

fermion-research PyPI 패키지

fermionresearch/llama.cpp GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~