Lesson 06 of 06 · published

남의 벤치마크 읽기

~15 min · lab, benchmarks, checklist, ceiling, evidence, measured

Level 0스펙 시트 훑는 사람

0 XP0/91 lessons0/19 achievements

0/100 XP to next level100 XP to go0% complete

"네가 돌리지 않은 벤치마크는 표가 붙은 주장이야. 실험실이 자기 숫자를 읽는 방식으로 읽어. 단계를 찾고, 바이트를 세고, 대역폭으로 나누고, 뭐가 남는지 봐."

체크리스트

남이 공개한 표의 모든 숫자는 네 카드에 올라가기 전에 질문 일곱 개가 필요해. 어느 단계? 프리필("pp", "prompt processing", "TTFT")은 연산에 따라 늘고, 디코드("tg", "eval rate", "초당 토큰")는 대역폭에 따라 늘어. 말 안 하는 표는 표가 아니야. 토큰당 바이트 몇? 모델 파라미터 곱하기 가중치당 비트, 빼기 디코드가 안 읽는 것. 그리고 "Q4"는 스케일까지 4.5비트지 4가 아니야. 어느 컨텍스트에서? 곡선 레슨은 창 하나에서 디코드가 15–39% 떨어지는 걸 보여 줬어. 컨텍스트 길이 없는 속도는 곡선 꼭대기의 속도야. 배치 얼마? 물리 트랙의 배치 레슨: 여러 스트림에 걸친 합계 초당 토큰은 같은 바이트에서 단일 스트림 숫자의 일곱 배일 수 있어. 어느 런타임, 어느 버전? 여정 트랙은 같은 바이트에서 두 경로 사이 5배 격차를 쟀어. 커밋이나 버전 없는 벤치마크는 정체 모를 프로그램의 벤치마크야. 뭔가 추측하고 있었나? Ollama 레슨: 상한 위의 속도는 패스당 토큰 하나 넘게란 뜻이고, 들여다보면 로그가 말해. 스펙 칸은 맞나? 아래 커뮤니티 표는 애플이 819라고 하는 M3 Ultra를 800 GB/s로 적고, 칩 세대에 걸쳐 커밋 둘을 섞어. 좋은 표에도 나누기 전에 고쳐야 할 행이 있어.

체커

코드 블록은 어떤 디코드 주장이든 비율 둘로 바꿔. 벤더의 대역폭 상한 대비, 그리고 이 퀘스트가 스트림한 칩이면 커널이 실제로 끌어온 대역폭 대비. 첫 것의 100% 위는 패스당 토큰 하나로는 불가능. 네가 잰 기계에서 둘째 것의 100% 위는 추측 디코딩이거나 틀린 바이트 집계. 4B보다 큰 모델에서 첫 것의 15% 아래는 바쁜 기계, 워밍업 없음, 아니면 틀린 단계. 그 사이의 전부는 런타임의 측정값이고, 같은 바이트와 컨텍스트의 다른 런타임과만 비교할 것.

표본	칩	GB/토큰	주장 tok/s	스펙 상한 대비	실측 대비	판정	증거
llama.cpp #4167, M2 Ultra 76c, 7B F16 TG	M2 Ultra	13.48	41.0	69%	75%	그럴듯. 실험실이 찾은 M2 > M3 Ultra 순서 그대로	벤더 표, 확인
llama.cpp #4167, M3 Ultra 80c, 7B F16 TG	M3 Ultra	13.48	39.8	65%	84%	그럴듯	확인
llama.cpp #4167, M3 Max 40c, 7B F16 TG	M3 Max	13.48	25.1	85%	86%	그럴듯. Max의 87% 맞춤 재현	확인
llama.cpp #4167, M3 10c, 7B Q8_0 TG	M3	7.16	12.3	88%	91%	그럴듯. Air의 89% 맞춤 재현	확인
llama.cpp #4167, M3 Ultra, 7B F16 PP	M3 Ultra	13.48	1,538	2,532%	—	디코드 숫자가 아님: 프리필	확인
이 사이트의 이웃 퀘스트, 2026-09-15에 읽힌 대로: 70B INT4	M3 Ultra	39.7	95	461%	591%	패스당 토큰 하나로 불가능. 가족에게 보고했고 그 퀘스트의 세션이 같은 날 고침	확인
이 퀘스트의 사다리, Qwen3.5-27B 4비트	M3 Ultra	14.42	32.6	57%	74%	그럴듯	실측
Ollama의 MLX 엔진, 27B NVFP4(여정 트랙)	M3 Ultra	14.45	50.6	89%	114%	실측 스트림 위: 추측 디코딩. 로그로 확인	실측

배울 만한 표본 셋

커뮤니티 표는 존재하는 최고의 공개 애플 실리콘 벤치마크고, 체크리스트로 읽으면 이 퀘스트를 재현해. 기본과 Max 칩은 스펙의 90% 근처, Ultra들은 60과 70대, M2 Ultra가 디코드에서 M3 Ultra를 앞서고 프리필에서 뒤져. 가장 새 칩들의 행은 다른 커밋을 달고 있고, M3 Ultra 대역폭은 M2 것이고, Q4_0 행들은 상한의 45%에 앉아 있어. 3.8 GB짜리 토큰이 고정 비용이 무는 자리니까. 뭘 봐야 하는지 알면 전부 읽혀. 이웃 퀘스트는 이 사이트에서 하드웨어 현실에 대한 레슨에 M3 Ultra가 4비트 70B를 초당 95토큰쯤으로 디코드한다고 썼었어. 819 GB/s에 토큰당 40기가바이트면 상한은 20 근처고, 그 주장엔 버스 4.6개가 필요했어. 틀린 모델이었어. 95는 커뮤니티 표가 Ultra 칩에서 7B에 재는 값이고, 엉뚱한 크기 아래 적힌 것. 여기서 고치는 대신 퀘스트 간 모순으로 가족에게 보고했어. 자기 파일 밖의 발견에 대한 이 퀘스트의 규칙이야. 그 퀘스트 자체의 세션이 같은 날 고쳤고, 그 레슨은 이제 날짜 붙은 메모와 함께 정정을 실어. 애플 자체의 M5 주장, 퀘스트가 벤더 주장으로 싣는 것들은 첫 질문으로 깔끔히 분류돼. "최대 4배 빠른 LLM 프롬프트 처리"는 새 GPU 가속기에 대한 프리필 주장이고, 디코드의 "19–27% 성능 향상 … 더 큰 메모리 대역폭 덕분에"는 벤더 자신의 말로 쓴 물리 트랙의 공식이야. 120 위의 153 GB/s는 1.275. 단계를 라벨하는 벤더는 어느 나눗셈을 할지 말해 주는 거야. 해.

Code

benchmark_check.py — 주장된 디코드 속도를 상한 둘의 비율로·python

#!/usr/bin/env python3
"""Read someone else's benchmark with the physics track: for a claimed decode rate,
compute bytes per token from the model and its bits, the bandwidth ceiling for the
chip, and the fraction of the ceiling the claim needs. Above 100% with one token
per pass is not a fast machine; it is a wrong number, a wrong stage, a wrong
byte count, or speculation. Standard library only."""

CHIPS = {"M3 Ultra": 819, "M2 Ultra": 800, "M3 Max": 400, "M3": 100, "M5 Max": 614, "M1 Max": 400}   # vendor GB/s; M5 Max per the discussion table
MEASURED = {"M3 Ultra": 638, "M2 Ultra": 740, "M3 Max": 391, "M3": 97}                            # this quest's stream.py, GB/s (T4)


def bytes_per_token(params_b: float, bits: float) -> float:
    return params_b * 1e9 * bits / 8


def check(label, chip, params_b, bits, claimed_tps, stage="decode", note=""):
    bpt = bytes_per_token(params_b, bits)
    ceiling = CHIPS[chip] * 1e9 / bpt                                   # first filter: the vendor number
    frac = claimed_tps / ceiling
    meas = MEASURED.get(chip)
    frac_m = claimed_tps / (meas * 1e9 / bpt) if meas else None          # second filter: what a kernel actually pulled here
    if stage != "decode":
        verdict = "not a decode number — compare against prefill, not bandwidth"
    elif frac > 1:
        verdict = "impossible at one token per pass"
    elif frac_m and frac_m > 1:
        verdict = "above what this chip streamed for us — more than one token per pass, or a wrong byte count"
    else:
        verdict = "plausible" if frac > 0.15 else "plausible, low — fixed term or a small model"
    print(f"{label:46} {chip:9} {bpt/1e9:6.2f} GB/tok  spec ceiling {ceiling:7.1f}  claimed {claimed_tps:7.1f} = {frac*100:4.0f}%"
          + (f" ({frac_m*100:4.0f}% of measured)" if frac_m else "" ) + f"  -> {verdict}{note}")


# Specimen 1: llama.cpp discussion #4167 (Llama 2 7B, 6.74B params; F16 = 16 bits, Q8_0 ≈ 8.5, Q4_0 ≈ 4.5), commit 8e672ef
check("#4167 M2 Ultra 76c, F16 TG",     "M2 Ultra", 6.74, 16,  41.02)
check("#4167 M3 Ultra 80c, F16 TG",     "M3 Ultra", 6.74, 16,  39.78)
check("#4167 M3 Max 40c, F16 TG",       "M3 Max",   6.74, 16,  25.09)
check("#4167 M3 10c, Q8_0 TG",          "M3",       6.74, 8.5, 12.27)
check("#4167 M2 Ultra 76c, Q4_0 TG",    "M2 Ultra", 6.74, 4.5, 94.27)
check("#4167 M3 Ultra 80c, F16 PP",     "M3 Ultra", 6.74, 16, 1538.34, stage="prefill")
# Specimen 2: a neighbour quest on this site — "M3 Ultra decodes a 70B INT4 around 95 tok/s"
check("neighbour quest: 70B INT4 on M3 Ultra",       "M3 Ultra", 70.6, 4.5, 95.0)
# Specimen 3: this quest's own ladder, for scale
check("this quest: Qwen3.5-27B 4-bit on M3 Ultra",   "M3 Ultra", 25.6, 4.5, 32.6, note="  (14.42 GB/tok by header, 74% of the measured-bandwidth ceiling)")
# Specimen 4: Ollama's MLX engine on office, the previous track
check("Ollama MLX engine, 27B NVFP4 on M3 Ultra",    "M3 Ultra", 25.6, 4.5, 50.6, note="  -> and it was: MTP speculation, 2.3 tokens per pass")

# #4167 M2 Ultra 76c, F16 TG      13.48 GB/tok  spec ceiling  59.3  claimed   41.0 =  69% ( 75% of measured)  -> plausible
# #4167 M3 Ultra 80c, F16 TG      13.48 GB/tok  spec ceiling  60.8  claimed   39.8 =  65% ( 84% of measured)  -> plausible
# #4167 M3 Max 40c, F16 TG        13.48 GB/tok  spec ceiling  29.7  claimed   25.1 =  85% ( 86% of measured)  -> plausible
# #4167 M3 10c, Q8_0 TG            7.16 GB/tok  spec ceiling  14.0  claimed   12.3 =  88% ( 91% of measured)  -> plausible
# #4167 M2 Ultra 76c, Q4_0 TG      3.79 GB/tok  spec ceiling 211.0  claimed   94.3 =  45% ( 48% of measured)  -> plausible
# #4167 M3 Ultra 80c, F16 PP      13.48 GB/tok  spec ceiling  60.8  claimed 1538.3 = 2532%                    -> not a decode number
# neighbour quest: 70B INT4       39.71 GB/tok  spec ceiling  20.6  claimed   95.0 = 461% (591% of measured)  -> impossible at one token per pass
# this quest: Qwen3.5-27B 4-bit   14.40 GB/tok  spec ceiling  56.9  claimed   32.6 =  57% ( 74% of measured)  -> plausible
# Ollama MLX engine, 27B NVFP4    14.40 GB/tok  spec ceiling  56.9  claimed   50.6 =  89% (114% of measured)  -> above what this chip streamed for us

External links

Exercise

맥에 대해 인용된 걸 본 디코드 숫자 셋(포럼 글, 벤더 페이지, 이 사이트의 레슨)을 가져와 네가 직접 유도한 토큰당 바이트로 각각 benchmark_check.py에 돌려. 비율 셋을 한 단어 판정과 함께 카드에 적어. 그다음 질문 일곱을 카드 뒷면에 써. 다음 달에 또 필요할 테니까.

Hint

가장 흔한 실패는 불가능한 숫자가 아니라 라벨 없는 숫자야. 컨텍스트 길이 없음, 양자화 없음, 단계 없음. 그건 '틀림'이 아니라 '라벨 없음'으로 표시하고 아무것과도 비교하지 마. 둘째로 흔한 건 Q4를 4.0비트로 센 것. 스케일까지 4.5 이상이고, 그 차이가 상한의 12%야.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousM2 Ultra 대 M3 Ultra: 같은 메모리, 더 새 GPU Next →퀴즈 · 6 questions

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.