BitNet 딥다이브
— 작은 숫자를 빠른 연산으로 바꾸는 추론 엔진

1프로젝트 한줄 요약

BitNet은 1-bit 계열 언어 모델을 위한 공식 추론 프레임워크입니다. 저장소의 제품 이름은 bitnet.cpp입니다. 이미 학습한 모델 파일을 읽어 텍스트를 생성하고, 지원되는 임베딩 모델에서는 문장을 벡터로 바꿉니다. 이 저장소의 핵심은 작은 가중치 표현을 CPU와 GPU가 빠르게 처리할 수 있는 메모리 배치와 연산으로 연결하는 것입니다.

1-1. 왜 이름은 1-bit인데 값은 세 개인가

BitNet b1.58의 가중치는 기본적으로 {−1, 0, +1}이라는 세 상태를 사용합니다. 세 상태를 표현하는 정보량이 log₂(3) ≈ 1.585비트라서 b1.58이라고 부릅니다. 하지만 일반적인 메모리에서는 정수 개수의 비트를 묶어 다루므로, CPU I2_S 경로는 가중치 하나를 2비트 코드에 담습니다. 이름의 정보량과 파일의 실제 저장량을 구분하는 것이 첫 번째 학습 포인트입니다.

# CPU I2_S에서 사용하는 값의 대응 관계
가중치 값      −1       0       +1
저장 코드       0       1        2
2비트 표현     00      01       10

# 한 바이트에는 네 개의 2비트 코드가 들어간다
[코드 0][코드 1][코드 2][코드 3] = 8비트

# 개념 설명용 내적: 가중치의 공통 배율은 1로 가정
x = [4, 7, 2, 5]
w = [1, 0, -1, 1]
x · w = 4 + 0 - 2 + 5 = 7

실제 커널은 배율, 정수 활성값, 벡터 명령을 함께 다룹니다. 위 식은 “삼진 가중치라면 계산을 단순하게 만들 수 있다”는 원리만 보여 줍니다. 전체 Transformer의 모든 계산이 덧셈과 뺄셈으로 바뀌는 것은 아닙니다. Attention, 정규화, 토큰 임베딩 등에는 다른 정밀도의 계산이 남습니다.

1-2. 모델과 엔진을 구분해서 읽기

이 자료의 중심 질문은 “어떤 답을 생성하는가”보다 “그 답을 계산하는 실행 경로가 어떻게 구성되는가”입니다. Python 문법을 조금 알고 배열·반복문을 읽을 수 있다면 시작할 수 있습니다.

2왜 주목받는가

2-1. 가중치를 읽어 오는 비용부터 줄인다

큰 모델은 매 토큰을 만들 때 많은 가중치를 읽습니다. 특히 한 문장을 한 토큰씩 생성하는 구간에서는 계산 장치보다 메모리에서 숫자를 가져오는 속도가 병목이 될 수 있습니다. 가중치를 더 작게 저장하면 전송량을 줄이고 캐시에 더 많은 데이터를 담을 여지가 생깁니다. BitNet은 이런 효과를 삼진 가중치에 맞춘 커널로 활용합니다.

낮은 비트 수 자체보다 중요한 것은 압축을 푸는 비용까지 포함한 전체 실행 시간을 줄이는 일입니다. 그래서 이 저장소는 모델 연구와 시스템 프로그래밍을 연결해서 공부하기에 좋습니다.

2-2. 트렌딩을 이해할 수 있는 세 가지 관심 요인

• CPU에서의 로컬 실행: README는 ARM·x86 최적화와 에너지 절감 결과를 제시합니다. 고가 GPU 외의 실행 환경을 고민하는 개발자가 살펴볼 이유가 있습니다.
• 연구에서 실행 코드로 이어짐: b1.58 모델, GGUF 변환, CLI, 서버 래퍼, 커널이 연결됩니다. 논문의 아이디어가 시스템의 어느 위치에 들어가는지 볼 수 있습니다.
• 적용 범위 확대: README의 2026년 7월 소식에는 0.6B·270M 임베딩 모델과 VibeASR.cpp 소개가 있습니다. 임베딩과 음성 인식으로 확장되는 흐름을 보여 주지만, VibeASR.cpp는 별도 저장소입니다.

선정 근거는 2026-10-23 기준 GitHub Trending C++ Monthly 9위입니다. 위 세 가지는 코드와 공개 설명에서 읽을 수 있는 관심 요인이며, 순위를 만든 원인을 통계적으로 증명한 분석은 아닙니다.

2-3. 비슷한 도구와 어느 지점에서 만나는가

2-4. “최대 6.17배”를 읽는 올바른 방법

README는 ARM CPU에서 1.37~5.07배, x86 CPU에서 2.37~6.17배의 속도 향상과 에너지 절감을 주장합니다. 같은 글에는 100B 모델의 단일 CPU 실행에 대한 설명도 있습니다. 모두 README와 연결된 기술 보고서의 실험 주장이며, 모든 노트북과 모델에 적용되는 보장값은 아닙니다.

docs/bitnet-embeddings-i2s-guide.md의 임베딩 실험은 조건이 더 구체적입니다. 비교 대상은 F16 교사 모델과 I2_S BitNet 모델입니다. Intel Xeon Platinum 8573C, 8스레드에서 0.6B 모델의 pp128 처리량을 F16 382.15 t/s, I2_S 870.90 t/s로 기록합니다. pp4096에서는 각각 236.76, 336.32 t/s로, 배율이 2.28배에서 1.42배로 줄어듭니다.

GPU 문서의 종단 간 비교는 BitNet 모델과 Gemma-2-2B/vLLM 조합을 비교합니다. 모델과 실행 체계가 함께 달라지므로 그 배율을 “CUDA 커널 하나의 순수한 효과”라고 해석하면 안 됩니다. 커널 단독 지연시간 표와 전체 생성 지연시간 표를 나눠 읽는 연습이 필요합니다.

3기술 스택 전체 지도

3-1. 실행 계층: CPU와 GPU가 서로 다른 길을 간다

웹 서비스의 계층 이름에 대응시키면 “백엔드”는 모델을 계산하는 엔진이고, “프론트엔드”는 우선 CLI입니다. 최상위에는 package.json과 독립적인 웹 프론트엔드 프로젝트가 없습니다. 서버 실행 파일은 CMake에서 켜지만, 서버의 HTTP 처리나 UI 구현은 의존하는 llama.cpp 쪽 영역입니다.

3-2. 버전은 선언 위치까지 함께 읽는다

루트 requirements.txt는 자체 버전 목록 대신 3rdparty/llama.cpp/requirements/requirements-convert_hf_to_gguf.txt 등을 -r로 참조합니다. 의존성 파일이 다른 파일을 가리키면 그 참조 끝까지 읽어야 실제 설치 환경을 알 수 있습니다. 루트 요구사항 파일만으로는 CPU용 전이 의존성의 정확한 버전을 확정할 수 없습니다. 별도로 기록된 서브모듈 커밋의 요구사항 파일까지 확인해야 합니다.

3-3. 인프라·빌드: 독립 배포 서비스보다 네이티브 빌드에 가깝다

CMakeLists.txt는 기본 빌드 형식을 조건부로 Release로 설정하고, 실행 파일을 build/bin에 모읍니다. find_package(Threads REQUIRED)로 스레드 라이브러리를 찾고, LLAMA_BUILD_SERVER를 ON으로 강제합니다.

# CMakeLists.txt에서 발췌한 기본 설정
option(BITNET_ARM_TL1 "bitnet.cpp: use tl1 on arm platform" OFF)
option(BITNET_X86_TL2 "bitnet.cpp: use tl2 on x86 platform" OFF)
set(CMAKE_C_STANDARD 11)
set(LLAMA_BUILD_SERVER ON CACHE BOOL "Build llama.cpp server" FORCE)
add_subdirectory(3rdparty/llama.cpp)

두 룩업 옵션은 기본값이 OFF이고, setup_env.py의 COMPILER_EXTRA_ARGS도 해당 아키텍처의 룩업 옵션을 OFF로 전달합니다. 따라서 파일이 존재한다는 사실만으로 기본 실행이 TL1·TL2라고 결론 내릴 수 없습니다.

.gitmodules의 URL은 isHuangXin/llama.cpp 포크이며, 브랜치는 release-bitnet-embedding-0.6b-270m입니다. 일반 llama.cpp 최신판과 같은 의존성이라고 가정하면 안 됩니다. 최상위 Dockerfile, .github/workflows/, pyproject.toml, Cargo.toml, go.mod는 이 커밋의 추적 파일에 없습니다. 여기서 확인되는 배포 준비의 중심은 CMake와 Python 스크립트입니다.

4아키텍처 심화 분석

도식의 llama.cpp·GGML 내부 연결은 루트 CMake, 헤더의 연산 인터페이스, 문서가 가리키는 구조를 요약한 것입니다. 서브모듈 내부의 개별 호출 순서까지 펼친 도식은 아닙니다. 바깥쪽 Python 코드와 이 저장소의 커널 구현은 아래에서 함수 단위로 살펴봅니다.

4-1. 얇은 실행 래퍼: 언어 사이의 경계를 작게 만든다

run_inference.py의 run_inference()는 신경망을 직접 계산하지 않습니다. 운영체제에 따라 실행 파일 경로를 고르고, 명령을 리스트로 만든 뒤 run_command()를 통해 subprocess.run(..., check=True)로 전달합니다.

# run_inference.py의 명령 구성 중 핵심 부분
command = [
    f'{main_path}',
    '-m', args.model,
    '-n', str(args.n_predict),
    '-t', str(args.threads),
    '-p', args.prompt,
    '-ngl', '0',
    '-c', str(args.ctx_size),
    '--temp', str(args.temperature),
]
if args.conversation:
    command.append('-cnv')

-ngl 0은 GPU로 넘기는 레이어 수를 0으로 지정합니다. 이 래퍼의 기본 실행 의도는 CPU 추론입니다. GPU 실행은 gpu/ 아래의 별도 코드로 읽어야 합니다. Windows에서는 build/bin/Release/llama-cli.exe를 먼저 찾습니다.

이 설계에서 배울 점은 준비·인자 처리와 계산 엔진의 책임 분리입니다. 명령을 문자열 하나로 합치지 않고 리스트로 전달하며, 기본 shell=False를 유지합니다. 공백이 있는 프롬프트도 하나의 인자로 전달할 수 있습니다. 다만 자식 프로세스 오류는 종료 코드 1로 단순화되므로, 더 풍부한 오류 구조를 제공하는 래퍼는 아닙니다.

서버 쪽 run_server()는 같은 방식으로 llama-server를 실행하며 -cb를 붙여 연속 배칭을 켭니다. 기본 주소는 127.0.0.1, 포트는 8080입니다. Python에 별도의 HTTP 라우터를 구현한 구조는 아닙니다.

4-2. 데이터 중심 설계: 저장 순서를 연산 순서에 맞춘다

src/ggml-bitnet-mad.cpp의 quantize_i2_s()는 거의 0인 값을 코드 1로, 양수를 2로, 음수를 0으로 바꿉니다. 0 판정의 기준은 fabs(src[i]) < 1e-6입니다. QK_I2_S는 x86 분기에서 128, ARM NEON 분기에서 64입니다.

기본 x86 ACT_PARALLEL 경로에서는 128개 값을 4×32로 나눕니다. 같은 열의 네 코드를 한 바이트에 묶어, 나중에 32바이트 SIMD 로드로 꺼내기 쉬운 배치를 만듭니다. “서로 이웃한 네 숫자를 무조건 한 바이트로 묶는다”는 설명만으로는 실제 배열 순서를 이해할 수 없습니다.

# 실제 배치를 이해하기 위한 인덱스 예시
입력 128개를 4행 × 32열로 해석한다.
첫 바이트  = 코드[0], 코드[32], 코드[64], 코드[96]
둘째 바이트 = 코드[1], 코드[33], 코드[65], 코드[97]

# quantize_i2_s()의 x86 ACT_PARALLEL 분기에서 발췌
int group_idx = j / 32;
int group_pos = j % 32;
uint8_t temp = (q8[i * QK_I2_S + j] << (6 - 2 * group_idx));
i2_weight[i * 32 + group_pos] |= temp;

이어지는 ggml_vec_dot_i2_i8_s_Nx1()는 _mm256_loadu_si256로 묶음을 읽고, 시프트와 0x03 마스크로 코드를 꺼내며, _mm256_maddubs_epi16 등으로 정수 내적을 누산합니다. 압축 코드에 대한 정수 누산과 모델의 최종 실수 출력은 같은 단계가 아닙니다. 배율과 코드의 영점 규약까지 맞아야 최종 의미가 보존됩니다.

4-3. 조건별 전략 선택: 빠른 길과 나머지 길을 둔다

ggml_vec_dot_i2_i8_s()는 nrc가 PARALLEL_SIZE로 나누어떨어질 때 병렬 묶음 함수를 선택하고, 나머지 경우 _1x1 경로를 사용합니다. 이는 입력 조건에 맞는 계산 전략을 고르는 작은 디스패처입니다.

// src/ggml-bitnet-mad.cpp의 분기를 축약한 설명용 코드
if (nrc % PARALLEL_SIZE == 0) {
#if defined(ACT_PARALLEL)
    ggml_vec_dot_i2_i8_s_Nx1(/* 인자 생략 */);
#else
    ggml_vec_dot_i2_i8_s_1xN(/* 인자 생략 */);
#endif
} else {
    ggml_vec_dot_i2_i8_s_1x1(/* 인자 생략 */);
}

include/gemm-config.h는 ACT_PARALLEL을 정의합니다. 기본 x86 설정은 ROW_BLOCK_SIZE=4, COL_BLOCK_SIZE=128, PARALLEL_SIZE=4입니다. _Nx1 내부는 가중치를 한 번 꺼낸 뒤 여러 활성값 열에 재사용합니다. 여기의 병렬 묶음 수는 운영체제 스레드 수와 다른 설정입니다.

빠른 경로를 읽을 때는 그 경로에 들어가는 조건과 조건을 만족하지 못했을 때의 동작을 함께 읽어야 합니다. 같은 질문을 LUT 경로에도 적용할 수 있습니다. ARM의 ggml_bitnet_can_mul_mat()는 지원 가중치 형식, F32 입력·출력, src1->ne[1] <= 1을 검사합니다. x86 TL2 쪽에는 마지막 조건이 없습니다.

4-4. 빌드 전 특수화: Python이 C++ 커널을 만든다

utils/codegen_tl2.py의 ModelShapeDict는 모델별 행렬 모양을 저장합니다. gen_tbl_impl(), gen_top_api(), gen_transform_code()로 코드 문자열을 구성하고 include/bitnet-lut-kernels.h와 include/kernel_config.ini에 기록합니다. 반복해서 실행할 연산의 모양을 미리 알고, 그 모양에 맞는 코드를 만드는 설계입니다.

TL2의 get_three_k_two_k(K, bk)는 three_k = (K // bk) * bk와 two_k = K - three_k로 주 처리 구간과 남는 구간을 나눕니다. 예를 들어 K=3200, bk=96이면 three_k=3168, two_k=32입니다.

생성기는 M % BM == 0, (K % BK) % 32 == 0, bm in [32]를 검사합니다. 검사는 일부 코드 문자열 생성 뒤에 위치하므로, 모든 잘못된 인자가 친절한 사전 오류로 걸러진다고 가정할 수는 없습니다. 모델 모양을 바꾸면 생성 코드·설정·변환 형식을 함께 검토해야 합니다.

LUT의 작업 순서도 중요합니다. ARM ggml_bitnet_mul_mat()는 ith == 0에서 테이블 전처리를 하고, 여러 스레드라면 ggml_barrier(params->threadpool)를 거친 뒤 계산 함수를 호출합니다. 공유 테이블을 다 만들기 전에 다른 스레드가 읽지 않도록 순서를 맞추는 것입니다.

4-5. GPU에서 확인하는 같은 원칙과 다른 제약

gpu/generate.py의 FastGen.build()는 use_kernel=False인 prefill 모델과 True인 decode 모델을 따로 만들고, model_state_fp16.pt·model_state_int2.pt를 각각 불러옵니다. 입력을 한꺼번에 처리할 때와 한 토큰을 만들 때 유리한 계산이 다르기 때문입니다.

gpu/model.py의 BitLinearKernel.quant_input()는 토큰별 최대 절댓값으로 s = 127 / max(max(abs(x)), 1e-5)를 구하고, 반올림·범위 제한 뒤 int8로 바꿉니다. bitnet_int8xint2_linear()는 CUDA 스트림과 텐서 포인터를 ctypes로 libbitnet.so에 전달합니다.

gpu/bitnet_kernels/bitnet_kernels.cu의 bitlinear_int8xint2()는 M == 1인 특정 N·K 조합만 분기 처리합니다. 미지원 모양에서는 메시지를 출력하며 범용 계산으로 대체하지 않습니다. 실제 커널 ladder_int8xint2_kernel은 헤더에 있고 __dp4a를 사용합니다. 따라서 “GPU 지원”을 임의 크기의 배치·모든 모델에 대한 범용 지원으로 확대 해석하면 안 됩니다.

5디렉토리 구조 해부

5-1. 이름이 비슷한 파일을 구분하기

utils/convert-bitnet-embedding-to-gguf.py는 임베딩용 독립 변환기이고, utils/convert-hf-to-gguf-bitnet.py는 다른 모델 경로도 다루는 변환기입니다. 파일 이름이 비슷해도 지원 모델, 배율 처리, 텐서 매핑은 각각 확인해야 합니다.

5-2. 줄 수가 알려 주는 것과 알려 주지 않는 것

커밋 0b341e5 기준의 물리적 줄 수이며, 빈 줄·주석·개행 없는 마지막 줄을 포함하고 서브모듈 본문은 제외합니다. 헤더 중 preset_kernels/가 5,813줄, include/bitnet-lut-kernels.h가 1,171줄입니다. CUDA 본체 37줄만 보면 작아 보이지만, 실제 계산 템플릿은 83줄짜리 헤더에도 있습니다. 파일 확장자별 줄 수를 곧바로 구현 난도나 사람이 직접 작성한 분량으로 해석하지 마세요.

6학습 포인트 (기술별)

6-1. Python: 옵션에서 실제 실행 인자까지 추적하기

argparse 선언은 사용자가 바꿀 수 있는 설정의 목록입니다. run_inference.py에서 --n-predict는 기본 128, --threads는 2, --ctx-size는 2048, --temperature는 0.8입니다. 이 값들이 문자열로 바뀌어 자식 프로세스에 전달되는 곳까지 연결해 보세요.

작은 실습: 옵션 이름, Python 변수명, 실행 파일에 전달하는 옵션을 세 열로 정리합니다. --conversation처럼 값 없이 켜는 옵션과 --threads처럼 값이 필요한 옵션을 비교하세요. CLI 설계와 프로그램 경계에서의 타입 변환을 배울 수 있습니다.

6-2. 수치 표현: “같은 값”의 의미를 명확하게 하기

utils/convert-bitnet-embedding-to-gguf.py의 quantize_to_i2_s()는 abs_mean = max(mean(abs(w)), 1e-5)를 계산하고, round(w / abs_mean)을 −1~1로 제한합니다. 저장되는 배율은 abs_mean이므로 복원 개념은 q * abs_mean입니다.

# 개념 확인용 숫자 예시: 실제 모델 출력이 아니다
w = [-0.6, -0.2, 0.2, 0.6]
mean(abs(w)) = 0.4
w / 0.4 = [-1.5, -0.5, 0.5, 1.5]

# 반올림 규칙까지 확인해야 한다. 단순히 소수점을 버리는 연산이 아니다.
q = clip(round(w / 0.4), -1, 1)
복원값 = q * 0.4

반면 C++ quantize_i2_s()는 최대 절댓값과 부호·0 판정을 사용합니다. 두 함수의 이름이 비슷하다고 같은 임의 실수 입력에 대해 같은 결과를 낸다고 가정하면 안 됩니다. 삼진화가 이미 적용된 가중치를 포장하는 단계인지, 학습된 실수 가중치에서 삼진값을 만드는 단계인지 확인하세요.

변환기의 정확성은 파일을 성공적으로 쓰는 데서 끝나지 않고 숫자·배율·텐서 의미를 함께 보존하는 데서 결정됩니다. 일반 변환기의 BitnetModel.write_tensors()는 이미 양자화된 모델의 weight_scale을 별도로 모아 처리합니다. 이미 삼진인 값을 다시 양자화하면 배율 규약을 망가뜨릴 수 있기 때문입니다.

6-3. 모델 호환성: 메타데이터도 실행 코드다

임베딩 변환기의 set_gguf_parameters()는 설정의 head_dim을 우선 사용하고, 없을 때만 hidden_size // num_attention_heads를 사용합니다. 문서의 0.6B 예시는 실제 head_dim=128인데 단순 나눗셈 결과는 64입니다. 배열의 차원 규약을 잘못 적으면 가중치 숫자가 맞아도 모델 계산이 달라집니다.

build_tensor_name_map()은 학습 측 이름을 GGUF 이름으로 바꿉니다. 예를 들어 layers.{i}.self_attn.q_proj.norm.weight는 blk.{i}.attn_q_norm_in.weight로 연결됩니다. 이 정규화는 선형층 앞에 있으므로 기존 모델의 비슷한 이름에 대충 합칠 수 없습니다.

Gemma3 고유 정규화는 (1+w) 규약을 맞추려고 변환 시 w+1을 적용합니다. 그러나 BitLinear의 _norm_in.weight는 이 보정에서 제외합니다. 작은 실습: “이름 매핑”, “숫자 변환”, “차원 기록”을 서로 다른 책임으로 표시해 보세요.

6-4. 시스템: 스레드 수와 데이터 재사용은 다른 축이다

스레드 수 -t를 늘리는 것은 일을 여러 작업자에게 나누는 것입니다. PARALLEL_SIZE는 한 커널 안에서 묶어서 처리하는 활성값·가중치 개수에 관여합니다. 캐시와 레지스터가 부족하면 묶음을 키워도 성능이 좋아지지 않을 수 있습니다.

작은 실습: include/gemm-config.h에서 x86, ARM DOTPROD, 일반 ARM NEON의 설정을 비교합니다. 기본 활성값 병렬 설정의 PARALLEL_SIZE는 각각 4, 8, 4입니다. 같은 소스가 전처리 매크로에 따라 다른 프로그램이 되는 과정을 익힐 수 있습니다.

6-5. 성능 평가: 측정 단위와 실험 조건을 먼저 읽기

utils/e2e_benchmark.py의 run_benchmark()는 llama-bench에 -ngl 0, -b 1, -r 5를 전달합니다. 기본 프롬프트 토큰 수는 512, 생성 토큰 수는 128입니다. 같은 “tokens/s”라도 프롬프트 처리와 토큰 생성은 서로 다른 일을 측정합니다.

또한 이 파일의 run_command()는 log_step이 없는 분기에서 성공 후에도 sys.exit(1)에 도달합니다. 벤치마크 본체의 출력과 래퍼의 종료 상태를 따로 봐야 하는 이유입니다. 소스에서 보이는 제어 흐름이며, 실제 실행 결과를 측정한 주장은 아닙니다.

작은 실습: 모델·형식·CPU·스레드·pp·tg·반복 수·평균·편차를 담는 결과 표를 설계하세요. 숫자 하나를 얻는 것보다 다른 사람이 같은 조건을 이해할 수 있게 기록하는 것이 목표입니다.

7하드웨어 / 시스템 요구사항

7-1. 2비트 모델의 메모리를 손으로 계산하기

# 모든 가중치가 같은 비트 수라는 단순화된 하한 계산
가중치 저장량 ≈ 파라미터 수 × 비트 수 / 8

2.4B × 2비트 / 8  = 0.6 GB
2.4B × 16비트 / 8 = 4.8 GB

# 실제 실행에는 다음 항목이 추가된다
전체 메모리 ≈ 가중치 + 고정밀 텐서 + 배율·정렬 공간
            + KV 캐시 + 활성값·작업 버퍼 + 실행 환경

여기서 GB는 10억 바이트입니다. README의 BitNet-b1.58-2B-4T는 실제 파라미터 수를 2.4B로 설명합니다. 모델 이름의 “2B”와 계산에 넣는 정확한 수를 구분하세요.

2비트 가중치의 이론적 저장량은 모델 파일 크기나 실제 실행 메모리의 보장값이 아닙니다. 임베딩 변환기는 I2_S 출력에서 토큰 임베딩과 정규화 텐서를 F16으로 남깁니다. 문서도 0.6B I2_S 출력 예시를 약 699 MiB로 적어, 단순한 0.6B×2비트 계산과 차이가 납니다.

CPU 최소 RAM이나 모든 장치의 VRAM 하한을 이 소스만으로 확정할 수는 없습니다. 특히 GPU 코드는 prefill·decode 모델을 따로 보유하므로 압축 가중치 하나의 크기로 VRAM을 계산하면 안 됩니다. 하드웨어를 고를 때는 모델 파일, 문맥 길이, 동시 요청, 실행 경로를 한 세트로 결정해야 합니다.

컴파일 설정도 호환성에 영향을 줍니다. 문서의 GGML_NATIVE=ON은 빌드 장비의 명령 집합을 활용하는 설정입니다. 다른 CPU에 같은 바이너리를 복사하려면 명령 집합 호환성을 별도로 검토해야 합니다. GPU의 compute_80 역시 “CUDA라면 어디서나 같은 조건”이라는 뜻은 아닙니다.

8직접 해볼 수 있는 실습 과제

아래 명령은 저장소 루트에서 파일을 읽는 예시입니다. 모델 실행이나 설치 없이, 코드 읽기와 종이 위 계산만으로 결과를 만들 수 있습니다. 실습을 마쳤다는 기준은 코드를 훑었다는 감상이 아니라 입력·분기·출력을 근거와 함께 설명할 수 있다는 것입니다.

rg -n 'add_argument|command|subprocess.run' run_inference.py

# 독립적인 비트 연산 예시. 저장소 함수를 호출하지 않는다.
packed = (0 << 6) | (1 << 4) | (2 << 2) | 1
codes = [(packed >> shift) & 3 for shift in (6, 4, 2, 0)]
weights = [c - 1 for c in codes]

rg -n 'void ggml_vec_dot_i2_i8_s\(|nrc %|ACT_PARALLEL' src/ggml-bitnet-mad.cpp
cat include/gemm-config.h

rg -n 'head_dim|pooling_type|pooling_mode|defaulting' utils/convert-bitnet-embedding-to-gguf.py

cat gpu/bitnet_kernels/bitnet_kernels.cu
rg -n 'torch.zeros|bitlinear_int8xint2|return ret' gpu/model.py

9관련 기술 심화 학습 로드맵

주당 3~5시간을 가정한 학습 제안입니다. CUDA가 처음이라면 6주차를 두 주로 나누어도 좋습니다. 먼저 같은 연산을 손으로 설명할 수 있게 된 뒤, 벡터 명령이나 GPU 스레드 배치를 공부하세요. 논문은 2주차에 b1.58의 표현을, 4~5주차에 bitnet.cpp의 시스템 설계를 연결해서 읽으면 좋습니다.

새 최적화를 배우면 먼저 무엇을 줄였는지 쓰고, 다음으로 무엇이 그대로 남는지 측정 항목으로 정리하세요. 예를 들어 압축은 가중치 전송을 줄일 수 있지만 Attention·KV 캐시·프로세스 준비 비용까지 없애지는 않습니다. 이 구분을 익히면 다른 추론 엔진의 성능 주장도 더 정확하게 읽을 수 있습니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소·문서·모델

• microsoft/BitNet 공식 저장소 · 모델 소식, 설치 안내, 지원표의 시작점입니다.
• 분석 기준 커밋의 README · 변화하는 main과 구분해서 읽을 수 있습니다.
• CPU 최적화 설명 · 활성값 병렬 처리와 임베딩 양자화 실험을 설명합니다.
• TL1·TL2 코드 생성 가이드 · 블록 분할과 모델 모양의 제약을 연결해서 보세요.
• 임베딩 I2_S 변환·최적화 가이드 · 텐서 이름·정규화·head_dim·pooling을 다룹니다.
• GPU 커널 문서 · W2A8, 데이터 재배치, 커널 단독·전체 실행 비교를 구분해서 읽으세요.
• 공식 생성 모델 · 0.6B 임베딩 모델 · 270M 임베딩 모델

11-2. 본문에서 따라간 핵심 소스와 관련 기술

• setup_env.py · run_inference.py · 준비 순서와 실행 인자
• ggml-bitnet-mad.cpp · ggml-bitnet-lut.cpp · 패킹·내적·LUT 연결
• codegen_tl2.py · 임베딩 변환기 · 특수화와 모델 의미 보존
• gpu/model.py · CUDA 모양 디스패처 · 언어 경계와 지원 조건
• 이 커밋이 가리키는 llama.cpp 포크 · llama.cpp 프로젝트 · 의존 대상을 구분하세요.
• Microsoft T-MAC · README가 명시한 룩업 기반 저비트 연산의 관련 프로젝트입니다.
• BitNet b1.58 논문 · CPU 추론 기술 보고서 · bitnet.cpp 시스템 논문 · README에서 연결한 연구 자료입니다.
• MIT 라이선스 원문 · 코드와 별도 의존성·모델의 조건은 각각 확인할 수 있습니다.

11-3. 저장소 현황 (2026-10-23 GitHub 기준)

11-4. 문서와 구현을 대조하며 남겨 둘 질문