단일 GPU에 여유롭게 들어갈 수 있도록 deepreinforce-ai/Ornith-1.0-35B를 Q3_K_M으로 양자화(Quantization)했습니다.

업스트림(Upstream) BF16 GGUF에서 llama-quantize를 사용하여 로컬에서 생성했습니다. 양자화 도구는 16.01 BPW에서 3.87 BPW로 낮추었으며, 디스크 용량은 16.8 GB, 로드 시 VRAM은 약 17 GiB에 달합니다. 이는 Q4_K_M보다 약 21% 더 작습니다. 이 모델은 해당 리포지토리에서 검증된 가장 작은 양자화 버전이며, 16슬롯 서빙 프로필(serving profile)에서 14/14 동작 테스트(behavior suite)를 모두 통과했습니다.

성능이 유지될까요? 저는 32개의 코딩 프롬프트를 대상으로 수정된 top-64 next-token KL(P_bf16 || P_quant) 프로브(token-ID 매칭, temp -1, n_probs 64, 캐시 오프)를 구축하여 BF16 베이스라인과 비교 실행했습니다. 따라서 이 Q3 수치는 실제로 의미가 있습니다. 상위 양자화 모델들과의 비교 결과는 다음과 같습니다:

양자화(Quant) | 평균 KLD (Mean KLD) | Top-1 일치율 (Top-1 match) | 크기 (size)
Q3_K_M | 0.366 | 84.4% | 16.8 GB
Q4_K_M | 0.086 | 90.6% | 21.2 GB
Q5_K_M | 0.035 | 93.8% | 24.7 GB
Q6_K | 0.017 | 100.0% | 28.5 GB
Q8_0 | 0.011 | 96.9% | 36.9 GB

Q3_K_M은 Q6_K와 비교했을 때 Top-1 일치율에서 약 16포인트 차이가 나지만, Q8_0의 절반도 안 되는 VRAM(17 vs 36 GiB)에서 실행됩니다.

처리량 (Throughput) (단일 GPU, llama.cpp CUDA 서버): 단일 스트림(single-stream) 시 약 240 tok/s, 16개 동시 슬롯(concurrent slots) 확장 시 약 493 tok/s, c1 기준 p95 TTFT 약 78 ms. 전체 c1/c4/c8/c16 스윕(sweep) 결과는 리포지토리에 있습니다.

진행 과정에서 수행한 기타 작업들:
추론 모드(reasoning-mode) 서빙 버그를 발견하여 수정했습니다. llama.cpp에서 추론(reasoning)을 켜두거나 자동(auto)으로 설정하면, 짧은 코딩 요청의 경우 전체 응답 예산이 파싱된 reasoning_content에 소비되어 최종 콘텐츠가 빈 값으로 반환될 수 있습니다. 서빙 스크립트는 REASONING=off를 기본값으로 설정하며, 동작 테스트는 14/14를 기록했습니다.
모든 양자화 버전에 대해 단일 GPU 서빙 스크립트 및 OpenAI 호환 정확성 게이트(/v1/models, /v1/chat/completions, /v1/completions 모두 확인)를 구현했습니다.
업스트림의 Q4/Q5/Q6/Q8을 미러링하고 재검증하여 전체 참조 사다리(reference ladder)가 하나의 리포지토리에 존재하도록 했으며, Q3가 비교 측정할 수 있는 기준을 마련했습니다. 이 네 가지는 업스트림 결과물이며 제가 재양자화한 것이 아닙니다.
훈련 스택(training stack)과 데이터 파이프라인을 검증하기 위한 원스텝 LoRA SFT 스모크 테스트(smoke run)를 수행했습니다.

스모크 테스트(Smoke test)만 수행되었으며, 아직 미세 조정된 어댑터(fine-tuned adapter)는 사용할 수 없습니다.
참고: 제가 테스트한 vLLM 빌드에서는 GGUF 경로가 깨져 있었습니다 (Q4_K_M을 로드했으나 출력이 손상됨) — 이 파일들은 llama.cpp를 사용하세요.
🔗 https://huggingface.co/LordNeel/Ornith-1.0-35B-GGUF-llamacpp-tp1
이 정보가 사람들에게 도움이 되기를 바랍니다. 현재 397b 모델의 양자화(quants) 작업과 기존 양자화 모델의 성능 개선 작업을 진행 중입니다.

제출자: /u/Blahblahblakha
[링크] [댓글]