적합성 계산기(fit calculator)는 한 가지 질문에 답합니다: 이 가중치(weights)들이 당신의 메모리에 로드될 것인가? 리더보드(leaderboard)는 다른 질문에 답합니다: 이 모델이 전반적인 테스트에 뛰어난가? 당신이 실제로 무엇을 실행할지를 결정하는 질문은 이 둘 중 어느 것도 아닙니다. 그것은 바로 "Q4_K_M이 내 기기에서 송장 추출(invoice extraction) 정확도를 떨어뜨릴 것인가?"이며, 이에 답할 수 있는 유일하고 신뢰할 수 있는 방법은 Q4_K_M에서 추출을 직접 실행하고 측정하는 것입니다.

QuantProof는 이를 자동화합니다. 당신의 작업에서 가져온 실제 예시들이 담긴 폴더를 지정하세요. 이 도구는 이미 Ollama(또는 Rapid-MLX 서버가 서빙 중인 무엇이든)에 있는 모든 모델을 훑으며, 결정론적 스코어러(deterministic scorers)로 모든 출력을 점수화하고, 첫 번째 토큰 생성 시간(time to first token), 초당 토큰 수(tokens per second), 그리고 피크 메모리(peak memory)를 측정합니다. 그런 다음 측정된 최상의 결과값의 2% 이내 품질을 유지하는 가장 작은 양자화(quant) 모델을 추천합니다.

npm install -g quantproof
quantproof ingest my-tasks.md   # 로컬 모델이 당신의 노트로부터 작업 팩(task pack) 초안을 작성합니다
# 또는: quantproof init my-task   # 직접 스캐폴딩(scaffold)합니다
...

추정 대신 측정해야 하는 이유

M5 Max에서 세 가지 작업 팩을 실행했습니다: 티켓 분류(ticket classification), 송장 추출(invoice extraction), 설정 생성(config generation). 세 가지 모델, 540개의 점수화된 생성물(generations). 어떤 모델도 세 가지 모두에서 승리하지 못했습니다.

Q8_0 버전의 8B 모델은 분류 작업에서 0.950을 기록하며, 메모리의 45%만 사용하는 30B 모델을 이겼습니다. 30B 모델은 추출 작업에서 1.000을 기록한 유일한 모델이었습니다. 설정 생성 작업에서는 두 모델 모두 1.000으로 동점을 기록했으나, 8B 모델은 약 17 GiB의 메모리를 덜 사용했습니다.

8B 모델이 추출 작업에서 0점을 받은 것은 품질 실패가 아니라 토큰 예산 절단(token-budget truncation) 문제였습니다. 60개의 생성물 중 57개에서 모델이 512-토큰 예산을 추론(reasoning)에 모두 소비하여 콘텐츠를 전혀 내보내지 못했습니다. 모든 원시 출력(raw output)은 저널링(journaled)되므로, 보고서는 이 0점을 trunc!로 표시하고 "이 모델은 추출할 수 없다"라고 읽히게 두는 대신 해결 방법(max_tokens 상향)을 명시합니다.

어떤 모델이 "최고"인지는 작업마다 달라졌습니다. 이것이 리더보드 문제의 핵심을 한 문장으로 요약한 것입니다: 순위는 모델과 워크로드(workload)가 결합된 속성인데, 리더보드는 모델만을 알고 있습니다.

결정론(Determinism)은 모델의 속성이 아니라 백엔드 버전의 속성입니다

모든 예시는 고정된 시드(seed)와 temperature 0에서 3번씩 실행되며, 반복된 결과는 바이트 단위(byte for byte)로 비교됩니다. Apple Metal 환경에서는 240개 이상의 점수가 매겨진 유닛(scored units) 전체에서 모든 후보가 정확히 반복되었습니다. 그 다음 동일한 체크를 RTX 5070에서 실행했습니다. 동일한 패키지, 동일한 시드, 동일한 드라이버, 그리고 두 가지 Ollama 버전입니다:

두 가지 8B 양자화(quant) 모델은 업그레이드 이후 결정론적으로 변했습니다. 1B 모델은 반대의 결과가 나왔습니다.

백엔드(backend) 업그레이드 과정에서 효과의 방향성조차 유지되지 않았으며, 이것이 바로 체크를 한 번만 믿고 넘어가는 대신 모든 스윕(sweep)마다 실행하는 이유입니다. 한 예시에서는 시드가 있는 temperature 0 조건에서 1회차 반복에서는 "필요에 따라(As needed)"라고 답했으나, 2회차와 3회차 반복에서는 "매주(Weekly)"라고 답했습니다. 동일한 조건에서 서로 다른 출력이 나온 것입니다.

예측값은 측정값 옆에 출력됩니다

적합도 예측(fit prediction)은 의도적으로 단순하게 설계되었습니다: 디스크 상의 가중치(weights), 컨텍스트(context)를 위한 f16 KV 캐시(KV cache), 그리고 고정된 1 GiB의 연산 허용량(compute allowance)을 합산합니다. 5070에서 네 가지 후보 중 세 가지가 예측값의 15% 이내에서 측정되었습니다. 1B 모델은 의도적으로 보수적으로 잡은 추정치보다 20% 이상 적게 실행되었습니다. 모든 보고서에는 두 수치가 모두 표시됩니다. 계획을 세울 때는 예측값을 사용하십시오. 실제 제약 사항은 측정된 피크(measured peak)입니다.

피크 메모리는 각 머신이 가진 가장 정직한 소스에서 가져옵니다:

• NVIDIA GPU의 경우 nvidia-smi
• Apple Silicon의 경우 백엔드 프로세스 RSS (Backend process RSS) (Ollama 자체 계측값과 대조하여 검증됨)
• Rapid-MLX의 경우 Metal 계측 (Metal accounting)
• 그 외 모든 환경의 경우 /proc/meminfo 기반 RSS

작동하는 소스가 없는 머신은 "측정되지 않음(not measured)"이라고 보고합니다. 그 어떤 것도 추정(estimate)하지 않습니다.

누구나 점수를 재확인할 수 있습니다

quantproof report --bundle 명령은 모든 원시 출력(raw output), 모든 점수, 모델 다이제스트(model digests), 샘플러 파라미터(sampler params), 그리고 백엔드 버전을 포함한 zip 파일을 내보냅니다. 번들 내용만으로 5070 스윕을 재점수화(re-scoring)했을 때, 두 Ollama 버전 모두에서 264개 중 264개의 점수가 정확히 재현되었습니다. 재확인할 수 없는 수치는 마케팅일 뿐입니다.

세부 사항 (이 수치들을 인용하기 전에 읽어보십시오)

• 메모리는 약 200ms 간격으로 샘플링됩니다. 기록된 피크(peak)는 가장 높은 샘플 값이며, 이는 할당자 추적(allocator trace)이 아닌 실제 피크의 하한선입니다.
• TTFT(Time To First Token)는 HTTP 요청부터 첫 번째 스트리밍 청크(chunk)까지의 시간을 측정하며, 여기에는 연결 오버헤드(connection overhead)와 프롬프트 평가(prompt evaluation)가 포함됩니다. 이는 순수한 디코딩(decode) 지표가 아니라 사용자가 실제로 경험하는 실제 지연 시간(latency)입니다.
• 스코어러(Scorers)는 결정론적(deterministic)인 경우에만 작동합니다: 스키마 준수(schema conformance), 필드 비교(field comparison), 레이블 일치(label match), 패턴 존재 여부(pattern presence), 수치 허용 오차(numeric tolerance). 판단이 필요한 작업(요약, 오픈 QA)은 범위에서 제외되며, 판사 모델(judge model)로 근사화하지 않습니다.
• 부분적인 GPU 오프로드(offload)는 측정되는 것이 아니라 그 이유와 함께 플래그(flag)로 표시됩니다. 오프로드 여부는 테스트 프레임워크(harness)가 아닌 Ollama가 결정합니다.
• quantproof ingest가 작성한 팩(pack)은 인간의 검토 전까지 해당 작성 모델과의 일치도를 측정합니다. 한 번의 실행 결과: 작성 모델이 예상되는 22개의 값 중 1개를 틀렸습니다. 출처(provenance) 레이블이 존재하는 이유는 바로 이 때문입니다.

당신의 작업에서 실행해 보세요

Node 22+ 이상, Ollama 또는 Rapid-MLX가 필요합니다. 메모리 부족(Out-of-memory) 오류는 충돌(crash)이 아닌 결과로 기록되며, 동일한 팩을 사용하여 GPU가 없는 환경에서도 Anthropic API를 통해 Claude 모델들을 전수 조사(sweep)할 수 있습니다.

GitHub logo moonrunnerkc / quantproof

양자화된 모델(quantized models)에서 실제 작업을 실행하고 측정된 품질, 지연 시간(latency), 피크 VRAM을 확인하세요. 또한 품질을 유지하는 가장 작은 양자화(quant) 크기도 찾아낼 수 있습니다.

측정 이유 · 작동 방식 · 사례 연구 · 당신의 작업에서 실행하기 · API 실행 · 문서

QuantProof

QuantProof를 당신의 작업에서 추출한 실제 사례들이 담긴 폴더로 지정하면, 당신의 하드웨어에서 어떤 양자화 모델 (quantized model)이 가장 잘 작동하는지 알려줍니다.

QuantProof는 추정하는 것이 아니라, 다음 항목들을 직접 측정합니다:

• 품질 (Quality)
• 지연 시간 (Latency)
• 최대 VRAM 사용량 (Peak VRAM usage)

그 후, 가장 성능이 좋은 모델의 품질과 2% 이내의 차이를 보이는 가장 작은 양자화 모델을 추천합니다.

왜 측정해야 하는가

적합성 계산기 (Fit calculators)는 모델의 가중치 (weights)가 메모리에 들어갈 수 있는지 여부만 알려줍니다. 벤치마크 리더보드 (Benchmark leaderboards)는 일반적인 테스트를 기준으로 모델의 순위를 매기며, 당신의 특정 워크로드 (workload)를 기준으로 하지 않습니다.

만약 당신의 진짜 질문이 다음과 같다면:

"Q4_K_M을 사용하면 송장 추출 (invoice extraction) 정확도가 떨어질까요?"

이에 답할 수 있는 유일하고 신뢰할 수 있는 방법은 단 하나뿐입니다: Q4_K_M에서 송장 추출을 실제로 실행하고 그 결과를 측정하는 것입니다.

작동 방식

QuantProof는 이 과정을 자동화합니다. QuantProof는 다음과 같은 작업을 수행합니다:

1. 후보 모델들을 하나씩 테스트합니다.
2. 모든 출력값을 결정론적 (deterministically)으로 점수화합니다.
3. 지연 시간 (latency)과 최대 VRAM을 측정합니다.
4. 결과를 보고합니다…

View on GitHub

Run your own 20 examples