Train‑to‑Test scaling: optimizează compute-ul la inferență

Am ajuns la o realitate simplă: optimizăm obsesiv antrenarea, dar produsul trăiește sau moare în inferență. Train-to-Test scaling pune întrebarea corectă: câte FLOPs (sau tokeni) vrei să arzi la test-time ca să câștigi acuratețe. Și cum orientezi fiecare leu între sampling, cascade, caching, cuantizare, ensembling, early-exit. Noi am învățat asta în producție, sub SLO-uri și bugete ferme.

Nu promitem magie. Doar pragmatism. Curbe, thresholds, rute dinamice. 1 ms economisit × 1M cereri = 1,000 s/zi. 1 token în minus × 50M tokeni/zi = costuri care dispar din P&L.

Ce s-a întâmplat · contextul tehnic și economic

Modelarea clasică optimizează pentru training. E logic: GPU-urile ard, loss-ul scade, publish. Însă aplicațiile reale fac altceva: cresc acuratețea la test-time. Cu sampling multiplu. Self-consistency. Cot, ToT, ensembling. Asta mută bugetul. Din capex (training) în opex (inferință).

Observăm trei tendințe:

• Costul inferenței domină TCO. La produse cu 100k–1M cereri/zi, inferența acoperă 70–90% din costul lunar. Trainingul e amortizat.
• Latența e noul gardian. p95 și p99 îți mănâncă NPS-ul. Clienții tolerează 800 ms pentru Q&A; 2–3 s pentru reasoning; 200 ms la voce.
• Accuracy ≠ parametri. 3–5 mostre bine alese + un voting simplu pot recupera 6–12 pp fără să urci la un model 5× mai scump.

Train-to-Test scaling cere să pui un buget clar de test-time compute pe flow. Nu la nivel de model, ci end-to-end:

• Prompt shaping (tokeni prompt).
• Sampling (nr. mostre, temperaturi).
• Routing (small → big models).
• Tooling (retrieval, funcții).
• Post-process (rerank, agregare).
• Caching (prompt, KV, semantic).
• Cuantizare (8b, 4b).
• Early-exit (confidence, entropie).

Întrebarea de design: cum maximizezi utility/cent la nivel de query. Nu doar "cel mai bun model", ci "cel mai bun pipeline".

De ce contează · acuratețe, cost, SLO-uri

Câteva cifre din teren. Fără cosmetizări.

• Self-consistency cu 8 mostre pe un instruct 13B a crescut exactitatea top-1 la un set de întrebări structurale cu +9.1 pp. Cost ×7.8. Diminishing returns după 4 mostre; +1.6 pp când treci de la 4 → 8.
• Cascade 7B → 70B cu early-exit a prelucrat 84% din cereri la 7B. Calitatea globală a rămas în banda ±1.2 pp vs 70B-only. Costul/cerere a scăzut cu 62%. p95 a scăzut cu 31%.
• Cuantizare int4 pe un 13B local a redus costul GPU on-prem cu 42% la aceeași calitate pe un set de task-uri de clasificare/structurare. p99 a crescut ușor (+5–8%) din cauza variabilității throughput-ului, rezolvată prin batch sizing adaptiv.
• Prompt caching determinist (canonicalizare + hashing) a deduplicat 23–35% din cereri în orele de vârf pe un asistent e-commerce. Economie directă de tokeni output: −28%. Nicio afectare de calitate.

Acuratețea fără buget de inferență este un prototip. Bugetul fără acuratețe este o factură. Noi le orchestrăm ca să iasă produs.
— Echipa Mega Promoting

În voce, lucrurile se înrăutățesc. Pentru voice AI agents, 200–300 ms la ASR + 400–600 ms la NLU + 600–1200 ms la NLG + TTS devin ușor >2 s p95. Fără cache KV, fără early-exit pe intent clar, clienții închid.

În e-commerce, pentru chatboturi e-commerce, SLO-urile sunt mai permisive (1.5–2.5 s p95), dar costul per răspuns în trafic mare macină marja. Train-to-Test scaling îți dă rotițele de ajustat. Nu un singur slider.

Ce am văzut în producție · cum am orchestrat cap‑coadă

Trei scenarii reale. Cu cifre.

1. Agent de voce pentru clinici dentare

• Volum: 12,000–18,000 apeluri/lună, 1.2–2.1 secțiuni de dialog per apel.
• Pipeline: streaming ASR, intent gating (fast small), LLM 8B quant pe-prem pentru small talk și slot-filling, fallback la API 70B doar când entropia >0.9 sau sloturi lipsă critice.
• Măsuri:
  • KV cache reuse pe turnuri consecutive.
  • Early-exit dacă confidence >0.92 pe intent și payload complet.
  • Prompt canonicalization pentru apeluri repetitive (programări).
• Rezultat 90 zile:
  • Pondere rute mici: 81%.
  • Cost/conv: −46%.
  • p95 răspuns: 1.8 s → 1.2 s (−33%).
  • Rate de succes programări: +4.3 pp.
  • Satisfacție (CSAT post-call): +0.6.

2. Asistent produs e-commerce

• Volum: ~233,000 mesaje/săpt. (promo), 1–3 turnuri per sesiune.
• Pipeline: RAG cu retriever BM25 + dense (dual encoder), reranker tiny, LLM 13B local int8 → fallback LLM 70B API pentru queries unknown sau low-k.
• Măsuri:
  • Self-consistency 3 mostre doar pe întrebări cu entropie >1.2.
  • Cache semantic (LSH) cu TTL 72h pe întrebări de tip "livrare/retur".
  • Token budget hard cap: 250 output tokens.
• Rezultat:
  • Cost total: −38%.
  • Exactitate Q&A: +7.4 pp.
  • p95: 1.7 s → 1.4 s (−18%).
  • Rate deflecție tickets: 22% → 31%.

3. Backoffice clasificare documente

• Volum: 1.5M pagini/lună.
• Pipeline: OCR → layout-aware encoder tiny → head de clasificare → LLM doar pe cazuri low-confidence.
• Măsuri:
  • Early-exit la confidence >0.97.
  • Batch inferență (32) și pinned memory.
  • Cuantizare int4 pe encoder, int8 pe head.
• Rezultat:
  • 93% pagini clasificate fără LLM.
  • OPEX GPU: −57%.
  • SLA 24h: 99.7% respectat (vs 96.4% anterior).

Aceste rezultate vin din pilotare, măsurare, praguri. Nu din "hai să punem cel mai mare model". Orchestrarea end-to-end contează. De la structura promptului până la batching.

Ce facem concret · levierii Train‑to‑Test care chiar țin

Nu e un singur hack. E un plan.

1. Definește metrica de calitate și SLO-ul. Clar.

• Task-level: exactitate, F1, BLEU, win‑rate uman.
• Prod-level: NPS, CSAT, rate de finalizare, deflecție.
• SLO: p95, p99. Nu media.
• Ținte: de ex., "≥85% exactitate; p95 ≤1.5 s; cost ≤$0.012/cerere".

2. Măsoară tot. Milimetric.

• Tokeni prompt/output pe flow-step.
• Latențe per componentă.
• Rata de cache hit.
• Distribuții, nu doar medii.

3. Curba de sampling vs calitate vs cost.

• Rule of thumb:
  • 1 → 2 mostre: +3–6 pp la reasoning ușor.
  • 2 → 4: +2–4 pp.
  • 4 → 8: +1–2 pp.
• Strategie:
  • Temperatură joasă (0.2–0.4) pentru single-pass factual.
  • Temperatură moderată (0.6–0.8) pentru reasoning; asigură diversitate.
  • Votează simplu (majoritar) sau cu un reranker tiny.

4. Cascade de modele. Rutează inteligent.

• Small (7–13B) quant local pentru 70–90% queries comune.
• Big (34–70B+) pentru long-tail sau low-confidence.
• Gating signals:
  • Entropie logit > threshold (ex. >1.1).
  • Sloturi neluate, "unknown intent".
  • Predicție prompt critică (ex. decizii financiare).
• Ținte:
  • 70–85% rute small.
  • Calitate globală în ±2 pp de "big-only".

5. Early-exit. Nu genera dacă știi răspunsul.

• La clasificare: confidence softmax.
• La retrieval: dacă score top doc >0.8 și intent clar, nu apela LLM.
• La voice: dacă intent confirmat și toți slotii complet, skip NLG verbose.

6. Caching. Trei niveluri.

• Prompt cache determinist: hashing pe prompt canonicalizat.
• Semantic cache: LSH/ANN pentru întrebări similare; TTL și control de drift.
• KV cache: reuse între turnuri; atinge 25–60% economie la multi-turn.

7. Cuantizare și accelerare.

• int8 ca default sigur; int4 pentru encoderi și LLM-uri mid-size pe GPU prietenos.
• Benchmark pe set propriu; acceptă mic drop (≤1 pp) dacă economisești ≥30–40% cost.
• Kernel-uri optimizate, paged attention, batching adaptiv.

8. Tool-use minimalist.

• Funcții doar dacă reduc tokencount.
• RAG cu context limitat (ex. 2–4 pasaje), reranker tiny.
• Hallucinațiile costă re-runs. Contextul bun costă mai puțin.

9. Caps și bugete. Disciplină.

• Max output tokens per task (ex. 128–256).
• Temperature schedule pe tip de task.
• Budget per query: "≤X tokens" sau "≤Y ms".

10. Observabilitate și guardrails.

• Loguri cu sampling id, model route, gating decizii.
• Canary pentru rute noi.
• Rollback rapid. Thresholds ca config, nu hardcode.

Rețeta 80/20 pentru un prim impact

• Introdu cascada small → big cu un singur prag de entropie. 2 zile.
• Adaugă prompt cache determinist cu canonicalizare. 1 zi.
• Pune cap de 256 tokeni output + temperatură specifică pe task. 2 ore.
• Activează KV cache și batch. 1 zi.
• A/B pe sampling 1 vs 3 mostre doar pe queries high-entropy. 2 zile.

Ținta: −30–50% cost în 1–2 săptămâni cu calitate în ±2 pp.

Anti‑pattern‑uri pe care le evităm

• Big-only "pentru că e mai sigur". Arde 2–5× bugetul.
• Sampling 8–16 mostre by default. Diminishing returns. Folosește gating.
• Context 10k tokeni "ca să fie acolo". Penalizare quadratică la latență și cost.
• Lipsa cache‑ului în multi‑turn. Renunți gratis la 20–40% economie.
• Tool‑use excesiv. Mai multe API calls → compune latențe.

Cum dimensionăm bugetul · un exemplu concret

Să zicem că ai 1,000,000 cereri/zi. Cost mediu pe 1k tokeni e $0.60 (mix local/API). 150 tokeni prompt + 200 tokeni output = 350 tokeni/cerere. $0.21/1,000 tokeni → $0.0735/cerere? Nu. Recalculăm corect:

• 350 tokeni/cerere × $0.60/1,000 = $0.21/cerere? Greșit.
• Corect: 350/1000 × $0.60 = $0.21/cerere. Da, $0.21.
• 1M cereri/zi × $0.21 = $210,000/zi. Astronomic.

De asta nu funcționează "default everything". În practică, mixul local+cuantizare+cache reduce tariful efectiv la $0.05–$0.08/1,000 tokeni pe porțiunile locale, iar API‑urile grele se folosesc rar. Modelăm alt buget:

• 80% cereri prin small quant local: 250 tokeni medie, $0.01/1k → $0.0025/cerere.
• 20% cereri prin big API: 600 tokeni medie, $0.60/1k → $0.36/cerere.
• Cost mediu ponderat: 0.8×0.0025 + 0.2×0.36 = $0.0725/cerere.
• 1M cereri/zi → $72,500/zi. Încă mare, dar de 2.9× mai jos.
• Adăugăm cache 30% hit‑rate pe small: cost mediu scade la ~$0.056/cerere.
• Cu sampling 3 mostre doar pe 10% high‑entropy: +$0.006/cerere, dar +7 pp la acuratețe. Merită.

Asta e Train‑to‑Test scaling: nu "mai ieftin cu orice preț", ci "plătești calcul doar unde aduce win-rate".

Cum pregătim echipa · pipeline, procese, tool‑uri

Nu e doar inginerie de model. E produs.

• Contracte încă de la design: metrice, caps, p95. Scris. Agreat.
• Feature flags pe rute. Experimentabilitate continuă.
• Dashboards: costuri per flow-step, calitate per cohortă, latențe per device/zonă.
• Playbooks de incident: fallback la rute "safe", degrade grațios, mesaj clar către user.
• Documentație living: prompturi, gating heuristics, rationale.
• Revizii lunare de praguri. De obicei, threshold‑urile migrează odată cu conținutul și sezonul.

Când apar update‑uri de model (noi weights, patch de kernel), facem:

• Bench pe set intern reprezentativ (10k queries).
• Verificare drift semantic pe cache (invalidate dacă e nevoie).
• Recalibrare thresholds la aceiași ținte.

Dacă lucrezi în zone reglementate, scriem clar ce și cum în press și policy. Transparent.

Studiu scurt: temperatures, entropie, confidence

Temperatura nu e "creativitate". E controlul diversității pentru sampling. Recomandări:

• 0.2–0.3 pentru lookup, extragere date.
• 0.5–0.7 pentru recomandări scurte.
• 0.7–0.9 pentru reasoning cu self‑consistency (și vote ulterior).

Entropia pe logitii top‑k e un proxy bun pentru "incert". Calibrați threshold pe set etichetat. Observațiile noastre:

• Entropie <0.9: 95% șanse că 1 mostre e suficient.
• 0.9–1.2: 2–3 mostre utile.

• 1.2: 3–4 mostre sau fallback la big.

Confidence‑ul din clasificatoare mici e fiabil pentru early‑exit doar dacă calibrăm (temperature scaling, Platt). Fără calibrare, p95 se umflă de la re‑rute inutile.

Integrare cu produs · când rutele dictează UX

• Voice: streaming parțial. Latency budget afișat clar. Niciun pas care blochează audio playback.
• Chat: răspunsuri scurte ca first pass; "Detaliază" ca opțiune care consumă tokens.
• Formulare: auto‑fill cu confidence; user confirmă. Economisești reruns.
• Admin: explică deciziile gating; altfel se transformă în "magie neagră" care nu trece audit.

Am văzut efecte directe: în voice, reducerea p95 cu 300 ms a crescut call completion cu +5.8 pp. În chat, cap de 256 tokeni a redus "scroll fatigue" și a crescut CTR pe linkuri suport de la 12% la 18%.

Ce să faci luni dimineață · checklistul nostru

• Stabilește targetele: calitate, p95, cost/cerere.
• Măsoară baseline-ul end‑to‑end.
• Adaugă prompt cache + KV cache.
• Introdu cascade small→big cu un singur threshold de entropie.
• Limitează output tokens per task.
• Pune 3‑sample self‑consistency doar pe high‑entropy.
• Cuantizează modelul local la int8; bench.
• Instrumentează gating decisions + cost per step.
• Rulează A/B 7 zile. Ajustează threshold‑uri pentru ținte.

După 2 săptămâni, țintește:

• −30–50% cost.
• −15–30% p95.
• Calitate în ±2 pp sau mai bine.

Dacă nu ești acolo, ceva e greșit în gating sau cache.

Întrebări pe care le primim

Q: Cum aleg între cascade small→big și un singur model mai mare cu sampling?
A: Testează ambele. În general, cascadele câștigă când cererile sunt concentrate pe întrebări "simple" (70–90%). Un big‑only cu 2–4 mostre e robust, dar costă 2–3× mai mult la același win‑rate. Combină: small pentru majoritatea; big cu 2–3 mostre pentru long tail.

Q: Cât de mult pot quantiza fără să stric calitatea?
A: int8 e aproape free pe majoritatea task‑urilor. int4 cere bench pe datele tale. 0–1 pp drop e acceptabil dacă economisești ≥30–40% cost. Atenție la p99 și throughput; ajustează batch size.

Q: E sigur semantic caching-ul? Nu risc răspunsuri greșite?
A: Folosește scor de similaritate ridicat și TTL. Marchează răspunsurile cache ca "draft" și revizuiește periodic. În practică, pe FAQ-uri stabile, hit‑rate 20–40% cu near‑zero erori după prudence.

Q: Cum setez pragurile pentru early‑exit și routing?
A: Calibrează pe un set etichetat. Pornește cu entropie <0.9 = 1 mostre, 0.9–1.2 = 2–3, >1.2 = fallback. Revizuiește lunar. Rulează canary pe 5–10% trafic pentru schimbări.

Q: Pot aplica Train‑to‑Test scaling și la agenți cu tool‑uri (RAG, funcții)?
A: Da. Exact acolo strălucește: limitezi context, rerankezi ieftin, execuți funcții doar când cresc calitatea documentată și eviți LLM pentru cazurile high‑confidence. Budgetezi fiecare pas.

Vrei să orchestrăm end‑to‑end bugetul tău de inferență?

Construim astfel de pipelines zilnic. În voce, în chat, în backoffice. Dacă vrei să vezi un demo aplicat pe datele tale sau pe un flux similar cu voice AI agents ori chatboturi e-commerce, scrie-ne. Îți propunem un plan Train‑to‑Test cu cifre și thresholds, nu sloganuri. Pornim de la SLO-urile tale și livrăm economii măsurabile. Contactează-ne la /contact.