당신의 80달러짜리 Tesla P100이 llama.cpp에서 수년 동안 조용히 소음 섞인 연산을 수행해 왔습니다. 세 줄의 코드로 무료로
요약
llama.cpp에서 NVIDIA Tesla P100 GPU의 fp16 연산 정밀도 문제를 해결하는 3줄의 패치를 소개합니다. 이 패치를 통해 P100 아키텍처에서 모델의 추론 정확도를 획기적으로 높이면서도 디코딩 속도를 약 1.4% 향상시킬 수 있습니다.
핵심 포인트
- P100(sm_60)의 fp16 연산 버그로 인한 정밀도 저하 문제 해결
- KLD(KL Divergence) 수치를 약 2300배 개선하여 수학적 정확도 확보
- Top-token 일치율을 96.5%에서 99.9%로 대폭 향상
- 추가 연산 비용 없이 디코딩 성능이 약 1.4% 개선됨
- 단 3줄의 코드로 구현 가능한 효율적인 패치 방식
요약 (TLDR); 출시됨 — turboquant v0.3.0에서 지금 다운로드 가능합니다. https://github.com/TheTom/llama-cpp-turboquant/releases/tag/tqp-v0.3.0 llama.cpp의 CUDA 코드는 "이 GPU는 fp16에 빠르므로, 연산을 fp16으로 수행하라"는 의미의 플래그를 가지고 있습니다. GTX 10-series와 P40(sm_61)은 오래전에 이 플래그에서 제외되었습니다. 아이러니하게도 P100(sm_60)은 제외되지 않았는데, 왜냐하면 P100은 빠른 fp16 하드웨어를 갖춘 유일한 Pascal 카드이기 때문입니다. Nvidia는 P100에 빠른 FP16 실리콘을 탑재했으므로, 그 추가 성능을 활용하고 싶어 하는 것은 전적으로 타당합니다. 하지만 그들이 확인하지 않은 것은 분명히 그 대가(price)였습니다. PR 상태: TheTom (병합됨) https://github.com/TheTom/llama-cpp-turboquant/pull/212 spiritbuun (수정: 병합됨) https://github.com/spiritbuun/buun-llama-cpp/pull/80 GGML: AI 지원 코드 기여에 대한 엄격한 정책. 제가 직접 그들을 위해 이슈(issue)를 작성해 보도록 하겠습니다. 위의 포크(fork) 중 하나를 대안으로 강력히 추천합니다. 26년 7월 12일 수정: GGML을 위한 이슈를 작성하기로 결정했습니다. 이것은 반드시 수정되어야 합니다. https://github.com/ggml-org/llama.cpp/issues/25593 패치는 3줄입니다. ## 본문
며칠 전, 저는 4개의 P100이 장착된 제 시스템에서 buun의 새로운 KV-cache 코덱을 벤치마킹하며 buun이 그의 3090에서 얻은 수치와 비교하고 있었습니다. 동일한 모델임에도 불구하고 우리 기기 사이에서 체계적으로 다른 품질 하한선(quality floors)이 계속 나타났습니다. 저는 모든 것이 동일하다고 생각했습니다. 보통이라면, 이 모든 코드 사이에 변수가 너무 많아서 단 하나의 원인으로 돌리기에는 무리가 있다고 생각했을 것입니다... 하지만 저는 추적해 볼 가치가 있다고 결정했습니다. 그리고 그럴 만했습니다. 그것은 llama.cpp에 수년 동안 자리 잡고 있던 심각한 버그로 저를 인도했습니다. 그래서 저는 그것을 측정했습니다.
fp32-참조 로짓 (full distribution에 대한 KL divergence, Qwen3.6-27B, wikitext-2) 대비 결과: 헤드라인: - 중앙값 KLD: 0.0023 → 0.000001 (~2300배 더 정밀해짐) - Top-token 일치율: 96.5% → 99.9% — 기존에는 모델의 다음 토큰 선택 중 약 29개 중 1개가 수학적으로 나와야 하는 값과 달랐습니다. 추가적인 연산 비용이 성능에 미치는 영향은? 저는 세 가지 모델 클래스(27B hybrid, 4B dense, 36B MoE)에 대해 8k 깊이에서 prefill(프리필)과 decode(디코딩)를 벤치마킹했습니다. prefill은 세 모델 모두 노이즈 범위 내에서 동일했으며, decode는 패치 적용 후 실제로 약 1.4% 더 빨라졌습니다. "빠른" 경로를 위해 추가 비용을 들일 필요는 없었습니다. P100에서의 실제 워크로드는 fp16 벡터 경로가 아니라 GEMM과 메모리 대역폭(memory bandwidth)에 의해 제한되기 때문입니다. 이 패치는 단 3줄이며, 기존 sm_61이 이미 가지고 있던 것과 정확히 동일한 예외 처리를 확장하는 방식입니다. 모두가 당황하여 자신의 4090이 고장 났다고 가정하기 전에, 이 결과는 sm_60에서만 측정된 것임을 명시합니다. 귀하의 GTX 1080/P40은 항상 괜찮았습니다 (이미 예외 처리되어 있음). Volta 및 그 이후 세대 아키텍처는 이 패치의 영향을 받지 않으며 완전히 다른 커널(kernel)을 실행합니다. 다른 아키텍처들이 측정되지 않은 자체적인 정밀도 문제를 가지고 있는지는 제가 여전히 파헤치고 있는 별개의 연구 과제입니다. 이것을 "모든 GPU가 고장 났다"로 읽지 마시고, "특정 GPU 하나가 고장 나 있었는데, 이제는 아니다"로 읽어주세요. 제작 후 편집 #1: TheTom: "병합 전 제 쪽에서 검증했습니다: 이 세 가지 게이트(gates)는 CUDA 트리 전체에서 600 대 610을 구분하는 유일한 차이점입니다. 따라서 분리된 sm_60 경로는 이미 오랫동안 검증된 sm_61 경로와 전처리기(preprocessor) 상으로 동일하며, Blackwell 빌드에서도 디코딩 변화 없이 비트 단위로 동일한 PPL을 보여주어 다른 아키텍처에 영향이 없음을 확인했습니다." #2: buun이 3090에서 동일한 프로토콜을 실행했습니다 — 패치된 P100은 기하학적 구조(geometry)가 일치할 때 44배 더 깨끗한 수치를 보여주었습니다. 2026년에 이것이 왜 중요한가: DRAM 위기로 인해 다른 모든 부품의 가격이 치솟는 동안, P100은 현재 배송비 포함 약 80달러에 거래되고 있습니다. 732 GB/s 속도의 16GB HBM2를 탑재하고 있습니다. 시장에서 P40의 가격이 약 300달러로 책정된 이유 중 일부는 그것이 "더 잘 작동하기" 때문이었는데, 그 격차의 일부는 바로 이 버그 때문이었습니다.
- 방법론과 증거를 포함한 전체 기술 문서: https://gist.github.com/apollo-mg/9218d50a209d70a85f033bf182657818 저의 커스텀 P/ReAct/R 에이전트 루프(agent loop)를 통해 Fable 5를 실행하여 발견 및 격리되었습니다. 에이전트가 스크립트를 작성했고, 하드웨어가 증거를 제공했습니다. 지난주 turboquant에 병합된 저의 KV-체크포인트 사이드카 패치(https://www.reddit.com/r/LocalLLaMA/s/VTIwEFpYgc)와 동일한 워크플로우입니다. /u/apollo_mg가 r/LocalLLaMA에 제출함 [link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/OpenAI Codex (search)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기