BitNet 프레임워크 리뷰: 1-Bit LLM은 정말 CPU 추론의 게임 체인저가 될까?

로컬 환경에서 70B 이상의 대규모 언어 모델(LLM)을 돌려본 엔지니어라면 누구나 공감할 것이다. 우리의 가장 큰 적은 컴퓨팅 파워가 아니라 Memory Bandwidth다. M2 Max 96GB 같은 고가의 장비를 세팅하고 llama.cpp를 돌려봐도 결국 메모리 병목 현상에 부딪히게 된다.

최근 Microsoft가 공개한 bitnet.cpp 레포지토리가 Hacker News를 뜨겁게 달궜다. “단일 CPU에서 100B 파라미터 1-Bit 모델을 구동한다”는 도발적인 타이틀과 함께 말이다. ARM CPU에서 최대 5배의 속도 향상, 70% 이상의 전력 소비 감소를 주장한다. 과연 이 기술은 우리가 기다려온 CPU 추론의 구원자일까? 아니면 그저 연구실 수준의 장난감일까?

100B 모델은 어디에 있는가?

솔직히 말하자면, 나는 이 레포지토리를 처음 보고 약간의 배신감을 느꼈다. 타이틀은 마치 100B 모델이 이미 존재하고 이를 돌릴 수 있는 것처럼 묘사하지만, 실제로 학습된 100B 1.58-bit 모델은 아직 공개되지 않았다. 현재 데모로 제공되는 것은 2B에서 3B 규모의 모델뿐이다.

Hacker News 커뮤니티에서도 이 점을 날카롭게 지적하고 있다. 프레임워크는 준비되었지만 정작 이를 증명할 플래그십 모델이 없다는 것이다. Microsoft가 2년이 넘는 시간 동안 100B 모델을 학습시키지 않은 이유는 무엇일까?

개인적인 생각으로는 두 가지 시나리오가 있다. 첫째, 모델의 파라미터가 커질수록 1.58-bit 양자화의 성능 저하가 기하급수적으로 커져서 실용성을 잃었을 가능성이다. 둘째, Microsoft가 파트너사인 OpenAI나 막대한 투자를 단행한 Nvidia의 생태계를 위협할 수 있는 파괴적인 기술을 굳이 최전선에 내세우고 싶지 않았을 수도 있다. 어느 쪽이든 엔지니어 입장에서는 아쉬운 대목이다.

1.58-Bit 모델의 기술적 우아함

그럼에도 불구하고 bitnet.cpp가 보여준 엔지니어링적 성취는 박수받을 만하다. 이 프레임워크의 핵심은 가중치를 -1, 0, 1의 세 가지 상태(Ternary)로 양자화하는 것이다. 왜 1-bit가 아니라 1.58-bit일까? 3개의 상태를 표현하기 위해 $\log_2(3) \approx 1.58$ 비트가 필요하기 때문이다.

이 접근 방식이 매력적인 이유는 기존의 행렬 곱셈(Matmul) 연산 프로필을 근본적으로 뒤바꾸기 때문이다. 부동소수점 곱셈 연산이 완전히 사라지고, 오직 덧셈과 뺄셈만 남는다.

HN의 한 유저가 공유한 1.58-bit Dot Product의 개념적인 접근 방식을 보자.

# 2비트 패킹을 가정한 개념적 의사 코드 (첫 번째 비트는 부호, 두 번째 비트는 활성화 여부)
actv = A[_:1] & B[_:1]
sign = A[_:0] ^ B[_:0]
dot = pop_count(actv & ~sign) - pop_count(actv & sign)

이 코드가 시사하는 바는 명확하다. 무거운 FMA(Fused Multiply-Add) 명령어 대신, CPU에서 매우 빠르게 처리할 수 있는 비트 논리 연산(XOR, AND)과 pop_count 명령어만으로 연산을 수행할 수 있다는 것이다.

  • Throughput: 기존 FMA 기반 연산과 달리 병렬 비트 연산을 통해 사이클당 처리량을 극대화할 수 있다.
  • Memory Bandwidth: 가중치가 1.58비트로 압축되어 메모리에서 캐시로 데이터를 끌어오는 비용이 획기적으로 줄어든다.
  • Hardware Design: 부동소수점 연산기가 필요 없으므로, 향후 이를 위한 전용 추론 칩(ASIC)을 만든다면 설계가 믿을 수 없을 정도로 단순해지고 저렴해질 것이다.

5-7 Tok/s는 정말 충분한가?

Microsoft는 100B 모델을 단일 CPU에서 구동할 때 5-7 tok/s가 나오며, 이는 “인간이 읽는 속도”와 비슷하다고 주장한다.

하지만 매일 로컬 LLM과 씨름하는 실무자로서 이 주장에는 동의하기 어렵다. 5-7 tok/s는 체감상 답답하다. 마치 내 앞을 천천히 걸어가는 사람을 뒤따라가는 기분이다. 쾌적한 UX를 위해서는 최소 10 tok/s 이상이 보장되어야 한다. 물론 CPU 단일로 100B 모델을 이 정도 속도로 돌린다는 것 자체가 과거에는 상상도 못 할 일이긴 하지만, 여전히 실사용을 위해서는 약간의 타협이 필요해 보인다.

결론: 그래서 프로덕션에 쓸 수 있는가?

현재 시점에서 bitnet.cpp는 당장 프로덕션에 투입할 수 있는 솔루션은 아니다. 검증된 대규모 모델의 부재가 가장 큰 걸림돌이다.

하지만 이 기술이 제시하는 방향성은 매우 중요하다. 우리는 그동안 모델의 크기를 키우고 GPU를 더 많이 꽂는 무식한(?) 스케일링에 의존해왔다. BitNet은 폰 노이만 구조의 근본적인 한계인 메모리 병목을 소프트웨어와 수학적 트릭으로 우회하는 훌륭한 사례를 보여주었다.

만약 오픈소스 커뮤니티나 제3의 스타트업이 이 프레임워크를 기반으로 쓸만한 70B 이상의 1.58-bit 모델을 학습해 낸다면, 그때는 정말로 로컬 AI 생태계의 지각변동이 일어날 것이다. 그때까지는 이 흥미로운 레포지토리에 별을 박아두고 지켜볼 가치가 충분하다.