GPU, API, nebo CPU batching pro AI inference

Týmy tráví překvapivě moc času debatou o hostingu modelů ještě dřív, než si pojmenují skutečný limit. Ten je většinou jeden ze čtyř: p95 latence, cena za 1M tokenů, požadavky na práci s daty, nebo prostě kapacita týmu. Pokud si tohle neurčíte jako první, skončíte u klasické startupové chyby: koupíte GPU server, protože to zní strategicky, a za tři týdny zjistíte, že traffic máte ve špičkách, prompty jsou malé a OpenAI nebo Anthropic by pro vás dalších dvanáct měsíců vyšly levněji.

Rozhodování se výrazně zjednoduší ve chvíli, kdy inference přestanete brát jako branding a začnete ji brát jako queueing problém s nepěknou ekonomikou. Support copilot, který přes den dělá 0,2 requestu za sekundu a v noci prakticky nic, má úplně jiné parametry než pipeline na extrakci dokumentů, která ve batch okně zpracovává 80 000 PDF. Interaktivní SaaS řeší p95 a p99, offline joby řeší throughput a cenu za token, regulované systémy řeší data residency a vendor smlouvy. Každé z toho vás tlačí jinam.

Ve Steezru jsme viděli, že smysl dávají všechny tři cesty: hosted API pro rané AI workflow obchodních týmů, kde produkt potřebuje rychle testovat prompty, lokální GPU serving pro zpracování dokumentů, kde je objem tokenů předvídatelný a záleží na soukromí, a CPU-first pipeline pro interní ERP feature, kde nikdo nepotřebuje odpověď za 700 ms a disciplína v nákladech je důležitější než screenshoty z benchmarků. Špatně není vybrat API, GPU nebo CPU. Špatně je vybrat to dřív, než si sepíšete očekávané requests per second, průměrné input tokeny, průměrné output tokeny, cíl pro p95 a kdo dostane pager, když vllm začne v 02:13 házet OOM.

Nejdřív si napište matici. Pak teprve utrácejte peníze.

Hosted API jasně vyhrávají při nízkém a středním provozu, hlavně ve fázi product discovery, protože obrovský kus provozní práce zabalí do faktury a jednoho SDK callu. Zní to samozřejmě, ale lidi pořád podceňují, kolik infra práce se schovává za jednoduchým client.responses.create(...). Retries, autoscaling, model updates, tokenizer quirks, speculative decoding, capacity planning, bezpečný rollout, abuse filtering, observability, vendor peering, tohle všechno je najednou problém někoho jiného. Přesně to chcete ve chvíli, kdy teprve zjišťujete, jestli uživatelé tu feature vůbec chtějí.

Rozumné pravidlo palce je jednoduché: pokud jste zhruba pod 1 request/sec sustained, nebo pod 5 až 10 miliony tokenů za den, hosted API bývá nejlevnější full-stack rozhodnutí, když započítáte i čas inženýrů. Ten threshold se mění podle typu modelu a tvaru promptů, ale jako výchozí bod funguje dobře. Když má průměrný request 1 500 input tokenů a 300 output tokenů a děláte 100 000 requestů měsíčně, přímý účet za model už může být nepříjemný. Pořád to ale bude méně nepříjemné než senior engineer, který spálí měsíc na self-hostingu, eval driftu, load testech a ranním pohledu na CUDA out of memory. Tried to allocate 1.53 GiB.

Latence je další místo, kde API v začátku často porazí self-hosted setup. Velcí provideři agresivně optimalizovali token streaming a pro chat UX je to důležitější než hrubé tokens/sec v benchmarkové tabulce. First-token latency můžete mít dost dobrou i bez toho, abyste babysittovali vLLM 0.5.x, TensorRT-LLM nebo vlastní autoscaler. Smluvně to dává smysl taky: pokud potřebujete customer-facing uptime commitment dřív, než si v týmu vybudujete SRE návyky, provider SLA plus rozumné fallbacky bývají bezpečnější než slibovat vlastních 99,9 % na jednom A100 v jednom racku.

Past je v tom, když si namluvíte, že economics API zůstanou přijatelné navždy. Nezůstanou. Při sustained traffic se z token billu stává nájem.

Dedikovaný GPU stack začne finančně dávat smysl ve chvíli, kdy je traffic dost stabilní na to, aby karta byla dlouhé úseky opravdu vytížená, a kdy jsou prompty dost velké na to, aby vás pricing API za token už reálně bolel. U spousty startupů praktický breakpoint vychází kolem 30 až 50 milionů tokenů denně pro jednu hlavní workload. Někdy dřív, pokud jsou prompty dlouhé a předvídatelné, někdy později, pokud je traffic bursty a idle time tragický. Pod tím vám spreadsheet většinou lže, protože ignoruje ops cost. Nad tím už marže API začíná vypadat absurdně.

Vezměte konkrétní příklad. Pronájem NVIDIA L4 instance vyjde zhruba na 0,70 až 1,10 dolaru za hodinu podle regionu a committed usage, A10G zhruba na 1,20 až 1,80, H100 už je cenově mimo rozum. Když pustíte 7B nebo 8B instruct model kvantizovaný na 4 bit přes vllm serve meta-llama/Meta-Llama-3.1-8B-Instruct --tensor-parallel-size 1 --gpu-memory-utilization 0.92, můžete se dostat někam mezi 80 a 180 output tokeny za sekundu podle batch shape, délky contextu a toho, jak moc vám workload fragmentuje KV cache. Pokud je karta vytížená většinu dne, efektivní cena za 1M tokenů může hosted API porazit o hodně.

Je tu ale velké ale: tail latency se rozbije ve chvíli, kdy to přeženete s batchingem nebo když bez omezení mícháte dlouhé a krátké prompty. Kdo někdy sledoval, jak p95 vystřelí jen proto, že se jeden request na shrnutí s 12k tokeny zařadil vedle patnácti malých chat requestů, ten tuhle bolest zná. Potřebujete admission control, oddělené fronty podle velikosti promptu a pořádný monitoring. Základní dashboardy by měly mít queue depth, tlak na GPU paměť, time-to-first-token, decode tokens/sec, p95 po routách a počty chyb rozdělené na timeout, OOM a upstream cancellation. Jestli tohle neumíte změřit, self-hosting ještě nedělejte.

GPU hosting je navíc jasná volba ve chvíli, kdy vám API usage zabije práce s daty. Někteří klienti prostě inference přes třetí stranu nepovolí, ať jde o smlouvy, zdravotní poznámky, finanční záznamy nebo interní právní dokumenty. V tu chvíli se argument mění. Náklady jsou důležité, latence je důležitá, ale compliance vyhrává.

CPU batching je možnost, kterou lidi ignorují, protože není sexy. Právě proto je to často nejlepší startupová volba. Pokud je workload asynchronní, pokud odpověď může trvat pár sekund, pokud umíte joby seskupovat podle šablony promptu a pokud menší kvantizovaný model odvede práci, CPU utáhne mnohem větší část produktu, než si průměrný founder myslí. Spousta interních AI feature nepotřebuje frontier modely. Potřebuje slušnou extrakci, klasifikaci, reranking, templated drafting nebo strukturovaný JSON output bez zbytečného dramatu.

Vezměte llama.cpp, Ollama nebo text-generation-inference na pořádném EPYC serveru s AVX-512 a dostatkem RAM. Kvantizovaný 3B až 8B model v GGUF, často Q4_K_M nebo Q5_K_M, zvládne batch zpracování dokumentů, triage ticketů, lead enrichment nebo shrnování ERP poznámek s velmi rozumným cost profilem. U dlouhých generací nedostanete oslnivou interaktivní latenci. Dostanete ale infrastrukturu, která se nerozsype při první aktualizaci driveru. Vyhnete se i podivné třídě problémů, která straší CUDA stacky: libcuda.so mismatch, NCCL WARN, pinning kernelu a hosty, které po rebootu naběhnou se špatnou verzí driveru, protože někdo kliknul v cloud konzoli na upgrade.

Breakpoint, kde CPU batching vyhrává, je hlavně o toleranci k latenci. Pokud uživatelé zvládnou čekat 2 až 10 sekund, nebo pokud běží vše plně asynchronně za job queue, CPU je pragmatická volba už někde od stovek tisíc do několika milionů tokenů denně, hlavně pokud by alternativou bylo platit API sazby za úlohy, kde rozdíl v kvalitě skoro nic neřeší. Tuhle cestu jsme používali u pipeline na zpracování dokumentů, kde HTMX frontend jen polluje stav jobu a nikdo neřeší, jestli backend běží na L4 nebo na 32core EPYCu. Řeší se, jestli se správně vytáhnou položky z faktury a jestli měsíční účet nebude téma na board meetingu.

Pro real-time chat ve větším měřítku se tahle cesta rozpadá. Držte ji tam, kam patří.

Používejte jednoduchou rozhodovací matici, ne finanční model na deseti tabech, který předstírá přesnost tam, kde žádná není. Začněte sustained requests/sec a burst requests/sec, protože průměrný traffic schovává průšvihy. Přidejte průměrné input a output tokeny a pak workload zařaďte jako interaktivní nebo async. Přidejte cíl pro p95. Přidejte počet engineering hodin za měsíc, které jste ochotni do inference ops reálně dát. Tohle poslední je důležitější, než si většina CTO chce připustit.

Praktická verze v obyčejné řeči vypadá takhle. Pod 1 sustained request/sec, bursty traffic, p95 pod 2 sekundy, nejistý product fit, berte hosted API. Mezi 1 a 10 sustained requests/sec se středním počtem tokenů a přísnými požadavky na soukromí nebo vendor omezeními dává smysl vyhodnotit jednu GPU službu s vLLM a fallback API cestu. Nad 10 sustained requests/sec na úzké workload se stabilními prompty už si GPU obvykle zaslouží seriózní analýzu, protože utilization může být dost vysoká na to, aby rozdrtila cenu API. Async pipeline s volnější latencí a předvídatelnými šablonami by měly nejdřív spustit CPU experiment, hlavně pokud 3B nebo 7B model po task-specific promptingu nebo lehkém fine-tuningu splní kvalitativní laťku.

U SLA neslibujte číslo, které neumíte pozorovat. Pokud máte ve smlouvě 99,9 % měsíční dostupnosti a p95 pod 3 sekundy pro feature postavené na inference, potřebujete synthetic checks, multi-AZ nebo multi-provider failover, budget alerty a degraded mode. Degraded mode může být až trapně jednoduchý: přepnout na menší hosted model, vypnout streaming, omezit max output tokeny na 256, nebo zařadit nekritické requesty do fronty. Zákazníci mají radši pomalejší systém než mrtvý systém.

Monitoring má být nudný a nekompromisní. Prometheus, Grafana, Sentry, strukturované logy s request ID a traces, které jdou přes hranici aplikace až do inference služby. U každého requestu zaznamenávejte počty tokenů. Bez toho je cost model fikce. Ukázkový log řádek by měl říct route, model, input tokeny, output tokeny, čekání ve frontě, first-token latency, celkovou latenci a stav výsledku. Jeden řádek, jeden request, bez výmluv.

Většina startupů by měla začít s API, navrhnout produkt tak, aby šel inference provider vyměnit, a teprve potom přesunout hot path na self-hosted GPU nebo CPU, až to ospravedlní reálný traffic. To znamená postavit od prvního dne tenkou inference vrstvu s request a response schématy, která máte pod kontrolou, a s tvrdými limity na velikost promptu, velikost odpovědi, timeout a retries. Neroztahujte provider-specific volby po celém codebase. Později vás to dožene.

Čisté rozhraní v Next.js nebo Django aplikaci je nudná práce, která vám může ušetřit měsíce. Jedna service boundary, jeden metrics wrapper, jedno místo, kde hlídáte guardrails. Pokud dnes potřebujete OpenAI a zítra vLLM, aplikace by to neměla řešit. Pokud potřebujete Anthropic pro jednu routu a lokální Llama 3.1 pro jinou, platí to stejně. Týmy, které tohle přeskočí, pak přepisují všechno v panice zrovna ve chvíli, kdy traffic roste a nikdo na to nemá čas.

Moje výchozí preference je jednoduchá. Hosted API pro nejisté produkty a customer-facing chat, kde je důležitá rychlost iterace. GPU serving pro stabilní a těžké workloady, kde dominuje útrata za tokeny a utilization umíte držet vysoko. CPU batching pro async feature, které potřebují rozumnou kvalitu za rozumnou cenu. Vyhněte se ideologii. Vyhněte se uctívání benchmarků. Nekupujte hardware jen proto, že konkurence zmínila H100 v podcastu.

Potřebujete cost model, cíl pro latenci a upřímnou odpověď na jednu nepříjemnou otázku: kdo tenhle systém bude vlastnit ve 3 ráno? Pokud je odpověď vágní, kupte API. Pokud je odpovědí konkrétní inženýr s observability, runbooky a fallback cestou, self-hosting může být velmi výhodný deal.

To je celá matice.