Intel squeezed a 1.58-bit LLM down to 1.485 bits without changing a single weight
Intel 연구진이 모델의 가중치나 출력값을 바꾸지 않고 저장 형식만 개선하는 BITCOS를 제안했습니다. 0 가중치의 비율을 별도로 활용해 한 체크포인트를 1.485비트로 저장했으며, 하드웨어에 따라 디코딩 처리량이 CPU에서 최대 18%, GPU에서 최대 27% 향상됐습니다.
AI 요약
Intel 연구진은 -1, 0, +1 세 값만 사용하는 ternary language model의 저장 형식을 바꾸는 방식으로, 흔히 1.58비트라고 부르는 이론적 한계보다 더 작은 1.485비트 per weight를 구현했습니다. 이 방법은 모델을 재학습하거나 가중치 자체를 변경하지 않고, 이미 존재하는 가중치를 더 효율적으로 표현합니다. 따라서 압축을 해제하면 원래의 -1, 0, +1 값이 그대로 복원되며 정확도에도 영향을 주지 않습니다.
■ 1.58비트가 실제 저장 크기와 다른 이유
Ternary model은 각 가중치에 -1, 0, +1 중 하나를 사용합니다. 세 값이 완전히 균등하게 나타난다고 가정하면 세 가지 선택지를 표현하는 데 필요한 이론적 최소치가 log2(3), 즉 약 1.58비트입니다. 그러나 실제 저장 방식에서는 이 수치보다 커집니다. 일반적인 방식은 8비트 바이트 하나에 5개의 ternary value를 넣어 평균 1.6비트를 사용합니다. 또한 모델 가중치를 보통 128개 단위의 블록으로 저장하기 때문에 마지막 바이트 일부가 비어 실제 저장률이 1.625비트 per weight까지 올라갑니다.
Intel 연구진은 7개 ternary model 계열에서 나온 29개 체크포인트의 가중치 분포를 조사했습니다. 그 결과 0인 가중치의 비율은 29.7%에서 51.5% 사이였습니다. 29개 중 26개 체크포인트에서는 0이 충분히 많아 기존의 5-trit packing보다 BITCOS가 더 작은 저장 공간을 사용했습니다. 가장 희소한 모델은 CAT-Q post-training quantization으로 생성한 Qwen3-1.7B의 ternary 버전이었으며, 전체 가중치의 51.48%가 0이었습니다. 이 체크포인트에서 BITCOS는 1.485비트 per weight를 기록했습니다.
■ BITCOS가 0 가중치를 활용하는 방식
BITCOS는 “BITmap and COmpacted Signs”의 약자입니다. 이 형식은 가중치를 두 개의 스트림으로 나눕니다. 첫 번째 스트림은 모든 가중치마다 1비트를 배정해 해당 값이 0인지, 0이 아닌지를 기록하는 presence bitmap입니다. 두 번째 스트림은 0이 아닌 가중치에 대해서만 부호 비트를 저장합니다.
따라서 +1 또는 -1은 presence bit와 sign bit를 합쳐 2비트를 사용하지만, 0은 부호가 없으므로 presence bit 하나만 필요합니다. 0인 가중치의 비율을 z라고 하면 BITCOS의 평균 저장 비용은 2-z비트 per weight가 됩니다. 0의 비율이 40%이면 1.6비트가 되고, 0의 비율이 51.5%이면 약 1.485비트가 됩니다. 기존 5-trit packing과 비교할 때는 가중치의 0 비율이 37.5%를 넘으면 BITCOS가 더 작아집니다. Intel이 조사한 29개 체크포인트 중 26개가 이 기준을 충족했습니다.
■ CPU와 GPU에서의 디코딩 구현
BITCOS는 작은 batch size로 토큰을 한 개씩 생성하는 token-by-token decoding을 겨냥합니다. 저장된 가중치 데이터가 작아지면 메모리에서 이동해야 하는 데이터도 줄어들 수 있습니다. Intel은 AVX-512 CPU, AVX2 CPU, Xe2 GPU를 위한 별도의 unpacking kernel을 구현했습니다.
AVX-512에서는 presence bitmap을 마스크로 사용하고 pdep 명령어를 이용해 압축된 sign bit를 0이 아닌 가중치 위치에 분산시킵니다. Xe2 GPU에는 이에 대응하는 명령어가 없기 때문에 Intel은 같은 동작을 2KB lookup table로 구현했습니다. 이 과정은 모델을 메모리에 로드하는 시간과는 별개이며, 이미 로드된 모델의 디코딩 성능을 측정한 결과입니다. 최근의 GPU inference cold start를 수분에서 수초로 줄이는 작업과는 다른 최적화입니다.
■ 다섯 시스템에서 측정한 성능
2비트 kernel과 비교했을 때 BITCOS는 64코어 Xeon 서버에서 10~18% 더 빨랐고, 24코어 Core Ultra 9에서는 2~15% 더 빨랐습니다. 통합형 Arc 140V GPU에서는 9~22%, 외장형 Arc Pro B70 GPU에서는 2~27%의 성능 향상이 나타났습니다. 즉, 저장 형식이 작아진 효과가 하드웨어와 실행 조건에 따라 디코딩 처리량 증가로 이어졌습니다.
다만 모든 시스템에서 BITCOS가 우세했던 것은 아닙니다. 8코어 Lunar Lake CPU에서는 모든 모델에서 고정형 2비트 kernel이 BITCOS보다 빨랐습니다. 이 시스템에서는 메모리 대역폭이 충분해져 저장 데이터 이동보다 압축을 해제하는 작업이 병목이 됐기 때문입니다. 반면 GPU에서는 BITCOS가 계속 더 빨랐지만, unpacking overhead 때문에 개선 폭이 제한됐습니다. 따라서 이 결과는 압축률만으로 성능을 판단할 수 없고, 실제 병목이 연산인지 메모리인지 대역폭인지에 따라 최적 형식이 달라진다는 점을 보여줍니다.
■ 적용 범위와 남은 검증
이 연구의 논문은 아직 peer review를 거치지 않았습니다. 다섯 가지 테스트 시스템이 모두 Intel 하드웨어였고, end-to-end benchmark는 batch size 1에서 7개 모델을 대상으로 진행됐습니다. Intel은 아직 Nvidia, AMD, Arm 하드웨어에서 BITCOS를 테스트하지 않았습니다. 따라서 현재 수치는 Intel CPU와 GPU에서의 디코딩 kernel 결과로 이해해야 하며, 다른 제조사의 하드웨어에서도 동일한 이득이 나타나는지는 추가 검증이 필요합니다.
■ Reddit 반응
• @u/SarahSplatz — 비트의 일부가 어떻게 가능한지 누가 설명해 주실 수 있나요? 수정: 설명해 주셔서 감사합니다 ^-^
원문: The New Stack / 번역·요약: Trawling