Čtení specifikace modelu

Závěrečná praktická kapitola: dostaneš specifikaci modelu a máš rozhodnout, jestli se ti vejde do železa, jak bude rychlý a kolik bude stát. Tohle je práce, kterou AI inženýr dělá pořád, a jde to spočítat na ubrousek, bez zkoušení.

Ukázková specifikace

name: priklad-8b-instruct
architecture: decoder-only transformer
parameters: 8.03B
n_layers: 32
d_model: 4096
n_heads: 32
n_kv_heads: 8            # GQA
head_dim: 128
d_ff: 14336              # SwiGLU
vocab_size: 128256
context_length: 131072
position: RoPE (theta 500000)
norm: RMSNorm (pre-norm)
training_tokens: 15T

Z toho se dá odvodit prakticky všechno.

1. Vejde se mi to do karty?

váhy = parametry × bajty na parametr
  FP16:  8,03 × 2   = 16,1 GB
  INT8:  8,03 × 1   =  8,0 GB
  INT4:  8,03 × 0,5 =  4,0 GB

K tomu KV cache (viz attention do hloubky):

KV = 2 × n_layers × n_kv_heads × head_dim × délka × bajty
   = 2 × 32 × 8 × 128 × 8192 × 2 B ≈ 1,07 GB   (na jednoho uživatele, 8k kontext)

Kdyby model neměl GQA (32 KV hlav místo 8), byla by cache 4,3 GB, čtyřikrát víc. Proto se n_kv_heads čte pozorně.

karta 24 GB, model INT4 (4 GB) → zbývá ~19 GB
                                → ~17 souběžných konverzací na 8k kontextu
                                → nebo 1 konverzace se 130k kontextem

2. Jak rychlý bude?

Generování je omezené propustností paměti, takže:

strop tokenů/s ≈ propustnost paměti / velikost modelu v paměti

karta 1 TB/s, model INT4 4 GB  →  ~250 tok/s teoreticky
                                → reálně 40–60 % → ~100–150 tok/s

A latence celé odpovědi:

čas ≈ prefill(délka promptu) + počet výstupních tokenů / rychlost

Praktický závěr: výstup určuje čas. Zkrácení odpovědi z 800 na 200 tokenů zrychlí odezvu čtyřikrát, zatímco zkrácení promptu skoro nic neudělá.

3. Kolik to bude stát přes API

denní objem = počet dotazů × (vstupní + výstupní tokeny)

10 000 dotazů × (2 000 vstup + 300 výstup)
= 20 M vstupních + 3 M výstupních tokenů denně
→ vynásob sazbami (výstup bývá 3–5× dražší)
→ odečti prompt caching, když máš stabilní prefix

4. Na co se ptát kromě čísel

• Kolik tokenů viděl v tréninku? 15 bilionů u 8B modelu znamená daleko za Chinchilla optimem, tedy „přetrénovaný“ ve smyslu, který ti vyhovuje.
• Znalostní uzávěrka. Určuje, co model ví bez podkladů.
• Kontext: nativní, nebo roztažený? Deklarovaných 131 k je něco jiného než 131 k, na kterých proběhlo dotrénování (poziční kódování).
• Instruct, nebo base? Base model neposlouchá zadání; na aplikaci chceš instrukčně laděnou verzi.
• Podpora nástrojů a strukturovaného výstupu. Jestli umí function calling a JSON schema.
• Licence. Zvlášť u otevřených modelů: komerční použití, limity, povinnost uvádět původ.
• Kvantizované varianty. Existují ověřené 4bit verze, nebo si je musíš vyrobit sám?

Rychlá rozvaha: API, nebo vlastní železo

API se vyplatí:      malý a nepravidelný provoz, potřeba špičkové kvality, žádný provozní tým
vlastní železo:      citlivá data, velký stálý objem jednoduchých úloh, potřeba stability
                     a předvídatelné ceny

Zlomový bod si spočítej: cena karty a provozu proti měsíční útratě za API při tvém objemu. Typicky vychází vlastní železo od nižších jednotek milionů tokenů denně, ale záleží na tom, jestli ti stačí menší model.

Cvičení

1. Spočítej velikost vah a KV cache pro model: 40 vrstev, d_model 5120, 40 hlav, 8 KV hlav, head_dim 128, kontext 16 k, kvantizace INT4, cache ve fp16.
2. Karta má propustnost 900 GB/s. Jaký je teoretický strop tokenů za sekundu pro model z bodu 1?
3. Aplikace dělá 50 000 dotazů denně po 1 200 vstupních a 250 výstupních tokenech. Kolik tokenů měsíčně? Kolik z toho ušetří prompt caching, když je 900 tokenů promptu vždy stejných?

Shrnutí

• Váhy = parametry × bajty; KV cache = 2 × vrstvy × kv_hlavy × head_dim × délka × bajty.
• n_kv_heads řídí paměť víc než n_heads; GQA je důvod, proč se vejdeš.
• Rychlost generování ≈ propustnost paměti / velikost modelu; délku odpovědi řeš dřív než prompt.
• Kromě čísel se ptej na tréninkové tokeny, uzávěrku, nativní kontext, instruct verzi a licenci.