"비트는 모델을 저장소의 선반에서 맥의 풀로 옮기는 유일한 손잡이야. 돌리고 뭘 치르는지 재. 실험실이 작은 파일에, 한 번 돌리는 데 3초로, 그렇게 했어."
실측한 사다리
양자화는 물리 트랙의 바이트 세기를 일부러 적용한 거야. 가중치당 비트 적게, 토큰당 바이트 적게, 더 높은 상한과 더 작은 파일. MLX에서 그걸 하는 명령 하나는 비트 폭과 그룹 크기를 준 mlx_lm convert야. 실험실은 여정 트랙의 bf16 Llama-3.2-1B에 대고 office에서 네 번 돌렸고, 변환마다 3초를 쟀어. 결과가 한 행에 레슨 전체야. bf16 2.47 GB는 초당 188토큰으로 디코드해. 8비트, 1.2 GB, 292. 6비트, 974 MB, 330. 4비트, 680 MB, 429. 3비트, 532 MB, 462. 사다리를 한 단 내려갈 때마다 토큰당 바이트를 덜 읽고 디코드가 그만큼 올라. 대역폭 레슨의 고정 비용이 바닥에서 넘겨받을 때까진 거의 선형으로. 거기선 3비트가 4보다 8%만 사 줘. 변환기 자체의 로그가 진짜 가중치당 비트를 명시해. 명목 4에 4.501, 명목 8에 8.500. 그게 스케일과 바이어스 오버헤드야. 파라미터당 0.5625바이트, GLM-5.3에 424 GB. 들어감 레슨의 더 둥근 0.6(452 GB)은 변환기가 양자화 안 하고 남기는 텐서까지 덮는 값이고, 둘 다 498 안에 들어가. 그리고 그게 만든 4비트 파일은 같은 모델의 커뮤니티 4비트 빌드의 428.0에 대해 초당 428.6토큰으로 디코드했어. 실험실이 그 명령이 같은 명령이라고 말하는 방식이야.
| office의 Llama-3.2-1B | 가중치당 비트(변환기 집계) | 파일 | 디코드 | bf16 대비 | 증거 |
|---|---|---|---|---|---|
| 출하 그대로 bf16 | 16 | 2.47 GB | 187.8 tok/s | 1.0× | 실측 2026-09-15 |
| 8비트, 그룹 64 | 8.500 | 1.2 GB | 292.2 | 1.6× | 실측 |
| 6비트 | 6.501 | 974 MB | 330.1 | 1.8× | 실측 |
| 4비트 | 4.501 | 680 MB | 428.6 | 2.3× | 실측 |
| 3비트 | 3.501 | 532 MB | 461.7 | 2.5× | 실측 |
저장소의 파일에 같은 사다리
코드 블록은 변환기 자체의 가중치당 비트를 저장소의 체크포인트들에 적용해. GLM-5.3은 8비트에 800 GB, 6에 612. 어느 쪽도 512 GB Studio에 안 들어가. 4비트에 424고, 들어감 레슨의 캐시를 얹어도 들어가. GLM-5.3-Flash는 8비트 340 GB로 들어가고 정밀도 대부분을 지킬 수 있어. Qwen3.8-Flash-Next는 8비트 191 GB로 들어가고 4비트면 노트북에. Kimi K3는 어떤 것으로도 안 들어가. 3비트도 아직 1.2 TB. 그러니 저장소의 선반은 각 파일이 작업 집합 선을 넘는 첫 비트 폭으로 스스로 정렬되고, 각각에 대한 이 집의 결정은 이 표의 행 하나에 표가 할 수 없는 품질 판단을 더한 거야.
퀘스트가 재지 않은 것
둘이고, 카드는 둘 다 말해야 해. 품질: 비트가 적으면 정확도를 치르고, 얼마나인지는 모델, 작업, 방법에 달렸어. 실험실은 3비트에서 더 빨리 디코드했고 답 하나도 평가하지 않았어. 퀘스트는 칩에 대한 거니까. mlx 퀘스트의 양자화 레슨과 모델 자체의 커뮤니티 평가가 그 판단이 사는 곳이야. 그리고 큰 변환 자체: 2.5 GB에 3초는 종이 위에선 1.5 TB에 변환기 시간 30분쯤으로 늘고(그중 원본을 Air의 실측 SSD 속도로 한 번 읽는 건 9분이야), 변환기가 512 GB 맥에서 bf16 세트 전체를 한 번에 상주시켜야 하는지는 1.5 TB 입력에서 시험되지 않았어. 저장소의 GLM-5.3과 Studio를 가진 독자는 오후 하나에 알아낼 거야. 실험 선 레슨은 그 오후의 결과로 뭘 할지에 대한 거야.