tokens/sec의 물리학

토큰 생성 속도는 신비롭지 않습니다. 디코드 중 모든 단일 토큰은 활성 가중치의 사실상 전체를 메모리에서 한 번 읽기를 필요로 합니다. 그래서 디코드는 메모리 대역폭 병목이고, 나눗셈으로 당신의 tok/s를 예측할 수 있다는 뜻입니다. 사람들이 다투는 모든 것 — 양자화, MoE, 오프로딩, 배칭 — 은 이 공식이 다른 모자를 쓴 것입니다.

그 하나의 공식

tokens/sec ≈ effective memory bandwidth ÷ bytes of weights read per token

RTX 4090, 8B Q4_K_M:
  1008 GB/s ÷ 4.9 GB ≈ 205 tok/s theoretical ceiling
  observed: ~120–150 tok/s (overhead, attention, KV reads)

하나의 흔한 사례에 대한 상식 확인 표(8B Q4_K_M, 단일 스트림 — 자릿수 수준의 숫자이지 스펙이 아닙니다. 직접 측정하세요):

천장과 현실 사이의 갭은 왜인가? 커널 런치 오버헤드, 컨텍스트와 함께 자라는 어텐션 작업, 가중치 위에 얹히는 KV 캐시 읽기. 공식은 천장을 줍니다. 단일 스트림에서는 보통 그 60–75%를 실현합니다.

카드 한 장, 모델 넷

공식은 고정 하드웨어에서 모델 크기가 속도와 어떻게 트레이드되는지도 예측합니다. ~1,000 GB/s 카드의 천장, 그리고 실현되는 60–75%(예시):

교훈이 두 개 떨어집니다. 같은 카드에서 파라미터 두 배는 대략 속도 절반입니다. 그리고 24 GB 카드의 32B는 여전히 챗에 쓸 만큼 빠릅니다 — 메모리 병목이 절망은 아닙니다. 이 짝이 24 GB 카드와 32B Q4 quant가 늘 함께 등장하는 이유입니다(GPU 티어 참고).

양자화는 단순 압축이 아니라 속도 기능입니다

같은 공식, 더 적은 바이트. fp16의 8B 모델은 토큰당 ~16 GB를 읽습니다. Q4_K_M에서는 ~4.9 GB. 같은 카드에서 Q4는 대략 fp16 속도의 3배이고 덤으로 fp16이 안 들어가는 곳에 들어갑니다. 이것이 Q4급 quant가 로컬 사용의 기본 추천인 이유입니다(양자화 참고) — 품질 손실은 작고 속도 이득은 우연이 아니라 구조적입니다.

컨텍스트는 당신을 느리게 합니다

대화가 자라면서 각 새 토큰은 이전 모든 토큰의 KV 캐시도 읽어야 합니다 — 이 읽기는 컨텍스트 길이에 비례해 스케일합니다. 빈 컨텍스트 근처에서 8B Q4는 4090급 카드에서 140 tok/s를 낼 수 있습니다. 64k 토큰 세션 깊은 곳에서 같은 설정은 그 절반이나 3분의 1로 처질 수 있습니다. 어텐션 커널도 캐시 친화적 모양에 맞지 않게 됩니다. 롱 컨텍스트 워크로드가 플래시 어텐션과 KV 양자화가 제값을 하는 곳입니다(KV 캐시와 엔진 노브 참고).

흔한 혼동: "챗이 진행되며 모델이 느려졌다"는 대개 서버 열화가 아니라 KV 증가입니다(KV 캐시 참고).

MoE: 능력 대비 속도

MoE 모델은 토큰마다 전문가 블록 몇 개만 활성화하므로, 토큰당 읽는 바이트는 총량이 아니라 활성 파라미터를 따릅니다. Q4의 총 30B/활성 3B 모델은 토큰당 기가바이트 몇 개만 읽습니다 — 큰 모델의 지식을 실은 채 작은 모델처럼 디코드합니다. 이것이 로컬에서 MoE 패밀리의 매력 전부입니다(모델 패밀리 참고). 전문가를 저장하는 데는 메모리를 지불하지만, 쓰는 것에만 대역폭을 지불합니다.

집필 시점의 구체적 모양: Qwen3-30B-A3B급은 토큰당 활성 ~3B 파라미터만 읽습니다 — Q4에서 ~18 GB의 VRAM으로, 작은 모델 속도에 큰 모델 지식.

추측 디코딩

작은 초안 모델을 큰 대상 모델과 짝지으세요. 초안이 k개 토큰을 값싸게 제안하고, 대상이 k개 전부를 순전파 한 번으로 검증하며, 수락된 토큰은 대상의 품질으로 나옵니다. 준탐욕적 워크로드 — 저온도의 코드 완성, JSON, 추출 — 에서는 2–3배 디코드 가속을 기대하세요. 고온도에서는 초안이 더 자주 틀리고 이득이 줄어듭니다. llama.cpp는 --model-draft와 초안 길이 플래그로 노출합니다. 정확한 플래그 이름은 버전마다 흔들리니 --help를 확인하세요.

비용: 초안은 대상의 토크나이저를 공유해야 하고, 두 모델 모두 메모리에 앉습니다.

병렬성: 현실

GPU 두 장이 단일 스트림의 2배를 주지는 않습니다. 텐서 병렬(vLLM -tp 2)은 처리량을 위해 각 층을 카드에 걸쳐 쪼개고, 상호연결 트래픽을 치릅니다. llama.cpp의 기본 분할은 파이프라인(레이어별)이라 단일 스트림 레이턴시보다 용량에 더 도움됩니다. 좋은 두 카드 분할의 현실적 기대치: 2배가 아니라 단일 스트림의 1.2–1.6배. GPU당 선형 스케일을 약속하면 뭔가를 팔고 있는 것입니다.

반면 카드 추가는 용량은 멋지게 스케일합니다 — 그것이 동시성의 서버 스토리입니다.

CPU 오프로드 절벽

레이어가 CPU에 남으면 모든 토큰의 순전파가 PCIe(~10–25 GB/s)를 건너 시스템 RAM으로 왕복합니다. 루프는 가장 느린 상주 부분의 속도로 돌립니다. 레이어의 80%가 GPU에 있는 모델은 "GPU 속도의 80%"가 아니라 CPU 속도에 훨씬 가깝게 돌립니다. 모델이 거의 들어간다면 반쯤 오프로드하는 대신 quant 한 단계를 내리세요 — 엔진 노브 참조. 우발적 부분 오프로드의 특징적 표식은 GPU급 하드웨어에서 3–10 tok/s입니다.

프리필은 연산 병목: TTFT는 다른 측정입니다

프롬프트 처리는 토큰에 걸쳐 병렬이고 대역폭이 아니라 연산량으로 제한됩니다 — 4090급 카드는 8B Q4를 초당 수천 토큰으로 프리필합니다. 그래서 12k 토큰 붙여넣기는 첫 출력 토큰 전에 ~3–5 s를 쓰고, 그다음 디코드는 140 tok/s로 돌립니다. 첫-토큰-까지-시간과 정상상태 tok/s는 다른 병목을 재는 다른 숫자입니다. 벤치마크를 읽을 때 어느 쪽을 보여주는지 확인하세요.

직접 측정하세요

페이지 위의 숫자(이 페이지 포함)는 천장과 범위입니다. 당신 설정의 측정은 2분이면 됩니다:

1. 짧은 프롬프트에서 ~200 토큰을 생성합니다. 아주 첫 실행(콜드 로드)은 무시합니다.
2. 정상상태 디코드를 잡습니다. 첫 토큰 이후 생성된 토큰 수 ÷ 초.
3. 긴 붙여넣기에서 첫-토큰-까지-시간을 별도로 적습니다 — 다른 병목입니다.

llama-server는 요청마다 prompt-eval과 eval tok/s를 찍고, LM Studio는 디코드 tok/s를 실시간으로 보여주고, nvidia-smi는 테스트 중 GPU가 실제로 바쁜지 확인해줍니다.

얼마나 빨라야 빠른가

임계값이 놀랍도록 낮은 이유는 인간의 읽기 속도가 ~5–10 tok/s에 불과하기 때문입니다 — 하지만 5 tok/s의 완성을 기다리는 것은 비참합니다. 직접 느껴보세요. 시뮬레이터가 같은 답을 서로 다른 토큰 속도로 렌더링하고, 거기서 1분이 어떤 표보다 많은 것을 가르칩니다.

~2–3 tok/s 아래에서는 스트리밍 UI가 느린 것이 아니라 고장 난 것처럼 느껴집니다 — 사람들이 탭을 닫습니다. 인터랙티브 사용의 딱딱한 바닥으로 취급하세요.

관련: 하드웨어 개요 · VRAM 계산 · GPU 티어 · 엔진 노브