Kako planirati budžet za LLM inference u produkciji: Token obračun, caching i fallback lanci

Stvarni model troškova: Što vaš cloud račun ne pokazuje

Očita stavka je cijena po tokenu — ulazni i izlazni tokeni po objavljenoj cijeni pružatelja modela. Ali stvarni trošak produkcijske inference dolazi od tri čimbenika koja cijena po tokenu skriva.

Inflacija kontekstnog prozora. Svaki krug u konverzacijskom agentu dodaje novu poruku korisnika, rezultate poziva alata i asistentov odgovor u povijest. Početni upit od 500 tokena postaje kontekst od 5.000 tokena do desetog kruga i 15.000 tokena do tridesetog. Plaćate svaki token u prozoru u svakom krugu, ne samo nove. Korisnička sesija koja djeluje konverzacijski može lako generirati 50.000–100.000 tokena samo u ulaznom trošku.

Re-encoding overhead. Većina pružatelja ponovno kodira cijeli kontekst pri svakom zahtjevu osim ako izričito ne upravljate KV-cache stanjem. To znači da pružatelj ponovno obrađuje svaki token povijesti razgovora svaki put kada korisnik pošalje poruku — bez predmemoriranja već izračunate pažnje iz prethodnih krugova. Ovo umnožava trošak linearno s duljinom sesije.

Napuhavanje sistemskog predloška. Sistemski predložak koji je započeo s 300 tokena tijekom prototipiranja raste kako dodajete zaštitne ograde, upute za format izlaza, primjere i definicije alata. Svakih sto tokena sistemskog predloška plaća se pri svakom pojedinačnom pozivu inference kroz sve korisničke sesije.

Da biste to ispravno modelirali, koristite formulu:

Mjesečni trošak = Σ (TokeniPredloška × CijenaUlaza + TokeniDovršetka × CijenaIzlaza)

Varijabla TokeniPredloška uključuje cijeli kontekstni prozor pri svakom pozivu, ne samo razliku. Napravite malu tablicu s očekivanim dnevnim sesijama, prosječnim krugovima po sesiji, prosječnom veličinom dovršetka i cijenama modela — broj će obično biti 3–5× veći od naivne procjene.

Prompt Caching: Prva poluga koju treba povući

Prompt caching — također poznat kao KV-cache reuse — je mjera kontrole troškova s najvećim utjecajem za produkcijske implementacije: kada pružatelj predmemorira KV izračun za ponavljajuće prefikse predložaka, naknadni zahtjevi koji dijele taj prefiks plaćaju samo za nove tokene sufiksa.

Gdje caching radi dobro. Svaka aplikacija sa stabilnim sistemskim predloškom i definicijama alata odmah ima koristi. Višekružni razgovori također imaju koristi nakon prvih nekoliko krugova jer se prefiks povijesti razgovora dijeli između uzastopnih zahtjeva iz iste sesije. Semantički caching za činjenične upite — “što kaže naša politika podrške o povratima” — može poslužiti identične odgovore iz predmemorije bez poziva modela.

Gdje caching ne uspijeva. Visoko dinamični predlošci koji se mijenjaju po zahtjevu (personalizirane upute agenta, upiti koji uključuju podatke u stvarnom vremenu), predlošci s randomizacijom ili temperaturnim uzorkovanjem koji trebaju svježi izlaz svaki put, i aplikacije gdje svaki odgovor mora biti jedinstven (generiranje sadržaja, kreativno pisanje). Za ove, uložite u fallback lance modela.

Određivanje veličine predmemorije. Za konverzacijskog agenta sa stabilnim sistemskim predloškom od 800 tokena i prosječnom sesijom od 10 krugova, predmemoriranje sistemskog predloška kroz sve korisnike eliminira otprilike 40 % potrošnje ulaznih tokena. Dodavanje cachinga prefiksa povijesti razgovora između uzastopnih krugova u istoj sesiji podiže to na 60–70 %. Izmjerite svoje stvarne obrasce instrumentiranjem omjera pogodaka predmemorije na svom proxy sloju prije odluke o kapacitetu predmemorije.

Model Tiering i Fallback Lanci: Platite manje za jednostavna pitanja

Ne treba svaka inference frontier model. Velik dio produkcijskih upita — činjenične provjere, strukturirana klasifikacija, jednostavne prerade — može savršeno obraditi mali, brzi model po desetini cijene. Fallback lanac usmjerava svaki zahtjev kroz progresivno veće modele, eskalirajući samo kada jeftiniji model ne može proizvesti dovoljno pouzdan odgovor.

Arhitektura s tri razine izgleda ovako:

Razina 1: Brzi mali model (0,15 $/M ulaznih tokena). Rješava klasifikaciju, ekstrakciju, jednostavne upite i provjere zaštitnih ograda. 60–70 % zahtjeva trebalo bi se riješiti ovdje.

Razina 2: Srednji model (1,50 $/M ulaznih tokena). Rješava višestepeno rezoniranje, sažimanje, planiranje poziva alata i dvosmislene upite koje je mali model označio kao nisko-pouzdane. 20–25 % zahtjeva.

Razina 3: Frontier model (10–15 $/M ulaznih tokena). Rješava složene agentske odluke, nove zadatke rezoniranja, generiranje koda i sve zahtjeve koji su preživjeli Razinu 2 s ispod-pragovnom pouzdanošću. 5–15 % zahtjeva.

Signal pouzdanosti može doći iz modelovih vlastitih logproba, laganog klasifikatora koji ocjenjuje kvalitetu odgovora ili heurističkog pravila (duljina upita, potrebna složenost alata, detektirana dvosmislenost). Ključ je da Razina 1 rješava većinu jeftino, a skupi model vidi samo najteži dio.

Batch vs Real-Time Inference

Za svako opterećenje koje ne treba sinkroni odgovor, batch reže trošak za red veličine. Generiranje embeddinga za RAG pipeline je klasičan primjer: slanje 10.000 dokumenata u jednoj batch grupi naspram 10.000 pojedinačnih zahtjeva eliminira overhead po zahtjevu i omogućuje pružatelju optimizaciju korištenja GPU-a.

Kandidati za batch obradu:

• Generiranje embeddinga i reintegracija
• Masovna klasifikacija i označavanje sadržaja
• Planirano sažimanje tiketa podrške ili logova
• Noćna batch obrada korisnički uploadanog sadržaja za moderaciju

Real-time inference je, nasuprot tome, potreban za chat, interaktivne pomoćnike za kodiranje i sve korisničke značajke gdje je latencija ispod sekunde važna. Razlika u trošku je toliko velika da batch obrada treba biti vaš zadani način — odlučujete se za real-time samo kada je latencija uvjet proizvoda.

Što pratiti prije nego stigne račun

Reaktivno planiranje budžeta ne uspijeva jer dok mjesečni račun stigne, obrazac potrošnje je star tjednima. Pratite ove metrike po pokretanju na svom proxy ili gateway sloju:

• Potrošnja tokena po korisničkoj sesiji — jedna sesija koja odskače može koštati više od stotinu normalnih
• Omjer pogodaka predmemorije — pad ispod 40 % bez objašnjenja znači da se struktura predloška promijenila
• Stopa eskalacije — koji udio zahtjeva doseže Razinu 3. Trend iznad 20–30 % znači da vaši jeftiniji modeli ne rade svoj posao
• Trošak po akciji — podijelite ukupni trošak inference s korisnim korisničkim akcijama. Rastući trend signalizira napuhavanje kontekstnog prozora ili širenje predloška
• Klase pogrešaka pružatelja — ograničenja brzine, timeouti i odbijanja filtera sadržaja svi imaju implikacije na trošak (ponavljanja troše tokene)

Postavite blage alerte na ove pragove: ako stopa eskalacije prijeđe 25 % dulje od sat vremena, istražite je li se performanse vašeg jeftinog modela pogoršale ili je promjena predloška pomaknula distribuciju zahtjeva.

Predložak kalkulatora troškova inference

Da bi model troškova bio konkretan, evo Python predloška koji možete prilagoditi svojim očekivanim obrascima prometa. Implementira punu formulu iz ovog posta, uključujući inflaciju kontekstnog prozora i višeslojno fallback usmjeravanje.

def estimate_monthly_inference_cost(
    daily_active_users: int = 1000,
    avg_sessions_per_user: float = 1.5,
    avg_turns_per_session: int = 8,
    avg_input_tokens_per_turn: int = 500,
    context_window_initial: int = 2000,
    system_prompt_tokens: int = 800,
    avg_output_tokens_per_turn: int = 300,
    cache_hit_ratio: float = 0.60,
    tier1_fraction: float = 0.65,
    tier2_fraction: float = 0.25,
    tier3_fraction: float = 0.10,
    tier1_input_price: float = 0.15,   # $/M tokens
    tier1_output_price: float = 0.60,
    tier2_input_price: float = 1.50,
    tier2_output_price: float = 3.00,
    tier3_input_price: float = 10.00,
    tier3_output_price: float = 30.00,
    batch_savings_fraction: float = 0.0,
) -> dict:
    monthly_sessions = daily_active_users * avg_sessions_per_user * 30
    monthly_turns = monthly_sessions * avg_turns_per_session
    avg_context_per_turn = context_window_initial + system_prompt_tokens + (
        avg_input_tokens_per_turn * avg_turns_per_session / 2
    )
    cached_fraction = cache_hit_ratio
    paid_input_tokens_per_turn = avg_context_per_turn * (1 - cached_fraction)
    total_input_tokens = monthly_turns * paid_input_tokens_per_turn
    total_output_tokens = monthly_turns * avg_output_tokens_per_turn

    tiers = {
        "Razina 1 (brzi-mali)": (tier1_fraction, tier1_input_price, tier1_output_price),
        "Razina 2 (srednji)":   (tier2_fraction, tier2_input_price, tier2_output_price),
        "Razina 3 (frontier)":  (tier3_fraction, tier3_input_price, tier3_output_price),
    }
    breakdown = {}
    total = 0.0
    for name, (frac, in_price, out_price) in tiers.items():
        in_tokens = total_input_tokens * frac
        out_tokens = total_output_tokens * frac
        in_cost = in_tokens / 1_000_000 * in_price
        out_cost = out_tokens / 1_000_000 * out_price
        subtotal = in_cost + out_cost
        breakdown[name] = {
            "input_tokens_m": round(in_tokens / 1_000_000, 1),
            "output_tokens_m": round(out_tokens / 1_000_000, 1),
            "input_cost": round(in_cost, 2),
            "output_cost": round(out_cost, 2),
            "subtotal": round(subtotal, 2),
        }
        total += subtotal
    total *= (1 - batch_savings_fraction)
    return {
        "monthly_sessions": monthly_sessions,
        "monthly_turns": monthly_turns,
        "avg_context_per_turn": avg_context_per_turn,
        "cache_hit_ratio": cache_hit_ratio,
        "breakdown": breakdown,
        "total_monthly_cost": round(total, 2),
    }

## Primjer za mid-market implementaciju:
result = estimate_monthly_inference_cost(
    daily_active_users=5000,
    avg_turns_per_session=6,
    cache_hit_ratio=0.55,
    tier1_fraction=0.70,
    tier3_fraction=0.08,
    batch_savings_fraction=0.20,
)
print(f"Procijenjeni mjesečni trošak: ${result['total_monthly_cost']}")
print(f"Detalji: {result['breakdown']}")

Kopirajte ovaj predložak, unesite svoj očekivani promet i cijene modela i dobit ćete procjenu troška prije nego napišete redak agentskog koda. Prilagodite parametre kako se vaši obrasci prometa stabiliziraju — model vam pomaže odgovoriti na pitanja poput “što ako udvostručimo broj korisnika” u sekundama.

Zaključak

Produkcijski troškovi LLM-a su upravljivi — ali samo kada modelirate puni multiplikator kontekstnog prozora, uložite u caching prije nego optimizirate predloške i usmjerite jeftine upite dalje od skupih modela. Trostepeni fallback lanac s omjerom pogodaka predmemorije od 60 %+ obično smanjuje mjesečni račun za polovicu u usporedbi s arhitekturom s jednim modelom.

Započnite s proračunskom tablicom modela troškova. Ucrtajte svoj očekivani promet, cijene modela po razinama i procijenjeni omjer pogodaka predmemorije. Model će vam reći koja poluga — caching, fallback usmjeravanje ili batch konverzija — daje najveći povrat za vaše specifično opterećenje. Povucite tu polugu prvu.

Koristite predložak kalkulatora troškova inference iznad kako biste modelirali svoje specifične brojke. Pokrenite ga sa svojim očekivanim prometom, cijenama po razinama i procjenama pogodaka predmemorije prije nego se obvežete na arhitekturu modela.