저비트 LLM은 CPU와 실행 환경에 따라 정확도와 속도가 달라진다

마테우스 페이토자(Matheus Feitosa)의 저비트 대형 언어 모델(LLM) CPU 비교 보고서는 1비트·삼진·2비트 모델 파일이 실행 환경에서 올바르게 작동하는지, 얼마나 빠른지 측정했다. 2026년 10월 기준, x86-64 AVX2와 aarch64 Neoverse-N1에서 BitNet의 잘못된 출력을 바로잡는 방법과 Bonsai 모델별 실행 파일·런타임 선택을 제시한다.

보고서는 측정한 런타임 커밋, 모델 파일의 SHA-256, CPU와 실행 플래그를 기록하고 측정 스크립트도 공개했다. 속도는 파일 크기만으로 판단할 수 없으며, 파일 형식과 CPU, 런타임 경로에 따라 달랐다.

BitNet에서는 수정 방법을 확인해야 한다

BitNet b1.58 2B4T의 공식 런타임은 x86-64에서 기준 모델보다 약 6배 높은 퍼플렉서티를 보였고, aarch64에서는 ????를 출력했다. 보고서 측정에서는 모델이 사용하는 ReLU² 대신 FFN에서 SiLU를 적용한 것이 x86-64 오류의 원인이었다. aarch64에서는 별도의 레이아웃 수정도 필요했다.

보고서가 비교한 방법 가운데 #588의 한 줄 수정은 측정한 두 CPU에서 기준값에 가까운 결과를 냈다. 다만 이 수정은 같은 그래프 코드를 사용하는 다른 1bitLLM 모델에도 ReLU²를 적용해 해당 모델들을 깨뜨릴 수 있다. 다른 BitNet 모델에도 안전하게 적용하려면 #605와 함께 실행할 때 --override-kv bitnet-b1.58.hidden_activation=str:relu2를 지정하는 방법이 제시됐다. 또는 모델 파일을 llama-quantize --allow-requantize ggml-model-i2_s.gguf out.gguf iq2_bn_r4로 변환한 뒤 ik_llama.cpp에서 실행할 수 있다.

퍼플렉서티 비교에는 토크나이저 조건도 영향을 준다. 공개된 GGUF에는 tokenizer.ggml.pre가 없어 llama.cpp 기반 런타임이 기본 토크나이저를 사용하면 Hugging Face 토크나이저보다 약 16% 많은 토큰을 만들 수 있다. 보고서는 서로 다른 토큰화에서 나온 퍼플렉서티를 직접 비교할 수 없다고 설명하며, 비교표에서는 모든 런타임에 같은 토큰 ID를 사용했다.

Bonsai는 파일 형식과 CPU별 속도를 따져야 한다

Ternary-Bonsai-1.7B의 x86-64 Q2_0 g64 파일은 SIMD 커널이 없던 측정 시점에 일반 C 코드로 실행돼 PQ2_0보다 프롬프트 처리 속도가 약 13배 느렸다. 이후 llama.cpp에 AVX2 커널이 추가됐고, 같은 가상 머신에서 변경 전후를 측정한 결과 정확도를 유지하면서 약 6배 빨라졌다. ik_llama.cpp도 Q2_0 지원을 추가했다. x86-64에서는 Prism보다 프롬프트 처리 속도가 약 15배 빨랐지만, PQ2_0가 여전히 더 빠른 파일이었다.

ik_llama.cpp의 -rtr 옵션은 측정 사례 대부분에서 가장 빠른 결과를 냈지만 기본값은 꺼져 있다. 이 옵션을 끄면 ik_llama.cpp가 가장 느린 경우도 있었다. 다만 aarch64에서 PQ2_0 생성은 Prism이 더 빨랐다. 27B 모델에서는 ik_llama.cpp의 -rtr가 x86-64 PQ2_0 처리에서 Prism보다 약 1.9~2.1배 빨랐고, 옵션을 끄면 프롬프트 처리가 약 3.1~3.5배 느렸다.

측정 범위는 aarch64 Neoverse-N1과 x86-64 AVX2의 Intel Xeon·AMD EPYC다. GPU, AVX-512, Arm i8mm/SVE, Apple Silicon은 측정하지 않았다. 파일 형식별 표본은 제한적이며, 27B 모델은 퍼플렉서티와 KL 비교에 두 개의 윈도만 사용했다. 런타임은 빠르게 바뀌므로 보고서의 이슈와 수정 상태도 현재와 다를 수 있다.

재현 절차와 측정 조건은 보고서 저장소, 측정 방법, 결과 파일에서 확인할 수 있다. 브라우저에서는 Kaggle 노트북이나 Colab 노트북으로 짧은 점검을 실행할 수 있다.