[분석] BitNet.cpp 1.58비트 모델의 모바일 환경 추론 실패 원인 분석

예전 Microsoft가 공개한 1비트 대규모 언어 모델 추론 프레임워크인 BitNet.cpp를 안드로이드 모바일 환경에 구축 및 테스트를 진행했다.

의존성 패키지 설치와 CMake를 통한 C++ 커널 컴파일, 1.19GB 규모의 1.58비트 GGUF 모델 로드까지는 정상적으로 완료되었다.

그러나 실제 추론 단계에서 정확한 LLaMA 3 대화 템플릿을 적용하고 Temperature 값을 0.0으로 설정하여 무작위성을 통제했음에도 불구하고, 모델이 정상적인 문장을 출력하지 못하고 의미 없는 단어들을 무작위로 나열하는 문제(Word Salad)가 발생했다.

이 현상의 근본적인 원인을 하드웨어 연산 아키텍처 관점에서 분석해본다.

0. 갤럭시 A35 스펙...

1. 메인 프로세서 : 삼성 엑시노스(Exynos) 1380

CPU 코어 구조 (옥타코어): 

• 고성능 코어 (4개): ARM Cortex-A78 (2.4GHz) - 복잡한 수학적 연산, C++ 커널 실행, AI 모델의 추론 등 무거운 작업을 전담합니다.
• 고효율 코어 (4개): ARM Cortex-A55 (2.0GHz) - 백그라운드 프로세스 및 전력 소모가 적은 가벼운 연산을 담당합니다.

2. 인공지능 처리 장치 (NPU): 엑시노스 1380 내장 NPU

• 연산 성능: 최대 4.9 TOPS (Tera Operations Per Second, 초당 4조 9천억 번의 연산 연산)
• 주요 역할: 스마트폰 내부에서 자체적으로 처리되는 온디바이스 AI(사진 보정, 노이즈 제거, 피사체 분리, 가벼운 음성 인식 등)를 하드웨어 수준에서 고속으로 처리합니다.
• 한계점: 4.9 TOPS는 일상적인 스마트폰 AI 기능에는 충분하지만, 로컬 거대 언어 모델(LLM)을 NPU만으로 구동하기에는 연산력이 부족하여 결국 CPU(Cortex-A78)에 크게 의존하게 됩니다.

3. 그래픽 및 병렬 처리 장치 (GPU): ARM Mali-G68 MP5

• 클럭 속도: 950MHz
• 연산 구조: 5개의 그래픽 코어로 구성되어 있습니다.
• 주요 역할: 본래 그래픽 렌더링을 담당하지만, 병렬 연산(Parallel Computing) 구조를 띠고 있어 특정 딥러닝 프레임워크에서는 CPU를 도와 행렬 곱셈 등의 AI 연산을 보조 가속하는 데 활용될 수 있습니다.

4. 메모리 (RAM): 6GB / 8GB LPDDR4x

• AI 모델을 기기에서 직접 구동할 때 가장 치명적인 병목 현상을 결정하는 부품입니다.
• 규격: LPDDR4x (데이터 전송 대역폭이 연산 데이터 병목에 영향을 줍니다.)
• 주요 역할: AI 모델 파일(가중치)과 연산 중인 컨텍스트 데이터가 올라가는 공간입니다. 안드로이드 시스템 기본 사용량을 제외하면, 8GB 모델 기준 실질적으로 로드할 수 있는 AI 모델의 크기는 약 4~5GB 내외로 제한됩니다.

1. 현상

환경	Android Proot 기반 Ubuntu 환경, Python 3.10 (Miniforge), CMake
모델	microsoft/BitNet-b1.58-2B-4T (GGUF 포맷, i2_s 양자화)
실행명령	python run_inference.py -m [모델경로] -temp 0.0 -n 10 -p "The capital of France is"
기대 결과	Paris. 또는 Paris, located in... 심지어 뭐 seoul 이렇게 할루시네이션이라도...
실제 출력	Freedom reduce Dispatch linear Dahl tent corps industrialadvert consum ...
결과	모델 컴파일 및 메모리 적재는 정상 처리되나, 기초적인 프롬프트("The capital of France is")에 대해 논리적 답변 대신 무작위 토큰(예: "Freedom reduce Dispatch linear...")을 초당 약 2.5 토큰의 속도로 출력함.

2. 근본 원인 분석

출력 오류는 프롬프트 템플릿의 문법 오류나 애플리케이션 레벨의 버그가 아닌, CPU의 물리적 연산 과정에서 발생하는 '텐서 손상(Tensor Corruption)'에서 기인한다.

<<<텐서손상에 대해서도 심층 분석을 진행해보고 포스팅하겠습니다...

A. 1.58비트 양자화와 LUT 연산의 특성

BitNet은 모델의 가중치를 -1, 0, 1이라는 세 가지 값(Ternary)으로 극단적으로 압축한다. 이를 CPU에서 고속으로 처리하기 위해 BitNet.cpp는 Look-Up Table (LUT) 기반의 특수 C++ 커널을 사용하여 행렬 연산을 수행한다. 이 커널은 연산 효율을 극대화하기 위해 CPU의 SIMD(단일 명령어 다중 데이터 처리) 명령어를 한계까지 활용하도록 하드웨어 종속적으로 설계되었다.

B. ARM 아키텍처의 파편화와 최적화 편향

Microsoft의 BitNet.cpp 공식 문서 및 벤치마크는 ARM CPU 환경에서의 뛰어난 성능 향상을 명시하고 있으나, 이는 철저히 Apple Silicon (M1, M2 등) 생태계를 타겟으로 최적화된 결과다.

Apple의 ARM 칩셋과 Samsung Exynos(Cortex-A 계열 코어 기반)는 넓은 의미에서 동일한 ARM 명령어 집합을 공유하지만, 내부적인 파이프라인 처리 방식이나 NEON (Advanced SIMD) 명령어의 세부 동작에서 마이크로아키텍처 수준의 차이가 존재한다.

C. 연산 불일치 (Calculation Mismatch) -> 텐서손상 연쇄 반

Exynos 1380 환경에서 BitNet의 C++ 커널이 NEON 명령어를 호출하여 1.58비트 행렬 곱셈을 수행할 때, 소스 코드가 의도한 수학적 결과와 실제 Exynos 하드웨어의 산술 결과 사이에 불일치가 발생한다.

초기 레이어에서 발생한 미세한 연산 오류가 모델의 깊은 신경망 층을 통과하며 증폭되고, 최종적으로 단어장(Vocabulary)에서 확률이 가장 높은 정상 토큰이 아닌 완전히 엉뚱한 난수성 토큰을 추출하게 만드는 것이다.

D. 하드웨어 차이

Microsoft의 BitNet.cpp 공식 문서 및 벤치마크는 ARM CPU 환경에서의 성능 향상을 명시하고 있다. 그러나 여기서 지칭하는 ARM 환경은 철저히 Apple Silicon 생태계에 편향되어 있다. 다음 표는 지원되는 ARM 환경과 현재 테스트를 진행한 모바일 ARM 환경의 차이를 보여준다.

비교 항목	Apple Silicon (M1/M2/M3 등)	Android ARM (Exynos 1380 등)
명령어 집합 (ISA)	ARMv8 / ARMv9	ARMv8
SIMD 최적화 대상	Apple NEON 커스텀 마이크로아키텍처	Cortex-A 코어 범용 NEON
BitNet 커널 테스트	Microsoft 개발진에 의해 검증 및 최적화 완료	공식 테스트 및 최적화 사례 부재
1.58비트 행렬 연산	Look-Up Table (LUT) 연산 정상 호환	특정 SIMD 명령어 처리 불일치 (Tensor Corruption)
추론 결과	정상적인 문장 생성 (초당 5~7 토큰)	연산 오류 증폭에 의한 무작위 토큰 생성 (Word Salad)

3. 우회 방법이 통하지 않는 이유

문제의 원인이 하드웨어 수준의 수학적 연산 오류에 있으므로, 일반적인 소프트웨어 트러블슈팅 방식은 적용되지 않는다.

• 프롬프트 엔지니어링: 모델의 '이해력' 문제가 아니라 연산 결과값이 도출되는 과정 자체가 붕괴된 것이므로, LLaMA 기반의 정확한 시스템 프롬프트를 입력해도 결과는 교정되지 않는다.
• 디바이스 스푸핑(Spoofing): 리눅스 시스템 정보를 변조하여 기기를 Mac이나 Raspberry Pi로 위장하더라도, 물리적인 연산 명령어 체계는 변하지 않으므로 문제 해결에 도움이 되지 않는다.
• 에뮬레이션: QEMU 등을 통해 타 아키텍처를 소프트웨어적으로 에뮬레이션할 경우, 1.58비트 모델의 핵심 존재 의의인 '빠른 로컬 추론 속도와 낮은 전력 소모'가 완전히 상쇄된다.

4. 결론 및 향후 방향

BitNet.cpp는 1.58비트 LLM의 가능성을 보여주는 혁신적인 프레임워크이나, 현시점에서는 매우 실험적인 초기 단계의 프로젝트다.

Apple Silicon 및 x86 환경에서는 설계된 성능을 발휘하지만, 안드로이드 진영의 모바일 ARM 프로세서(Exynos, Snapdragon 등)에 대한 수학적 연산 호환성 패치는 아직 구현되지 않았다.

따라서 현시점에서 안드로이드 모바일 기기를 활용해 온디바이스로컬 LLM을 안정적으로 구축하기 위해서는, BitNet.cpp의 업데이트를 대기하거나, 광범위한 CPU 마이크로아키텍처에 대한 최적화가 수년간 검증된 llama.cpp 프레임워크를 대안으로 채택하는 것이 기술적으로 타당하다.

---

하지만 여기서 끝내면 연봉 2천따리 하청의 하청의 하청의 하청 갑을병정의 노예이며 Si 똥퍼 코딩시설관리직이아니다!!! 

텐서손상에 대해서 한번 더 분석해볼 가치가 있다고 파악되었다. 

왜냐하면 우선 학술적으로, 논문, 연구적으로 "텐서손상!" 이라고 써있었지 정말 텐서 손상인지 그 실체가 정말 데이터의 파멸인지 아니면 단순한 엄살인지 직접 찍먹해봐야 직성이 풀리겠다.

이러면서 실제 AI 돈존내쓸어담는 네카라쿠베 연구원나으리들이 어떻게 테스트하는지...

또 똥같은 모델이 나온경우 실제 딥러닝 컴파일러 엔지니어들이 새로운 CPU 아키텍처에 대한 추악한 호환성 버그를 어떤 식으로 잡아내는지 그 밑바닥 기술의 심연이 궁금해 미칠 지경이기 때문이다.

물론 이런 짓거리를 한다고 해서 내 연봉이 1원이라도 오르거나, 고결한 면접관들의 서류 심사 문턱을 넘는 기적 따위는 일어나지 않을 것이다. 어차피 나는 '정'의 노예일 뿐이고, 이 기록은 누구도 알아주지 않을 똥퍼의 처절한 자위질로 끝날 것이 뻔하니까.