Cost-Governed RAG: contabilizare per-tenant pentru workload-uri LLM
Întreabă orice echipă de platformă care rulează RAG pentru mai mult de trei clienți: cine a plătit pentru răspunsul ăla de 4k tokeni? Nimeni nu știe.
Cost-Governed RAG: contabilizare per-tenant pentru workload-uri LLM
Întreabă orice echipă de platformă care rulează RAG pentru mai mult de trei clienți: cine a plătit pentru răspunsul ăla de 4k tokeni? Nimeni nu știe. Apelul de embedding a ajuns pe un contor, căutarea vectorială pe altul, generarea pe un al treilea — iar factura de la sfârșitul lunii e o singură linie opacă.
Un articol din iulie 2026, Cost-Governed RAG, propune un răspuns neobișnuit de concret pentru gen: unifică contoarele. Autorii combină un index vectorial independent de codebook, numit TurboVec, cu un gateway de guvernanță care etichetează fiecare apel de embedding, retrieval și generare cu un tenant ID înainte ca apelul să părăsească pod-ul. Implementat pe Snowpark Container Services, raportează o acuratețe de 99,96% în atribuirea costurilor pe 100 de tenanți simulați, overhead de telemetrie sub 0,04% și reducere a costurilor de infrastructură de 3,1–9,0× față de bazele de date vectoriale managed.
De ce gateway-ul stă înaintea indexului
Majoritatea stivelor RAG multi-tenant atașează urmărirea costurilor doar la proxy-ul LLM. Asta ratează două din cele trei centre de cost. Costul de embedding crește cu volumul de ingestie de documente per tenant, iar costul căutării vectoriale crește cu QPS × dimensiunea indexului — niciunul nu apare într-un line item gpt-4o-mini. Gateway-ul stă upstream față de toate cele trei, singurul punct unde identitatea tenantului este încă de încredere.
2026-07-14T09:12:03Z governance.gw tenant=t_884 op=embed tokens=1024 cost_usd=0.00013
2026-07-14T09:12:03Z governance.gw tenant=t_884 op=search index=turbovec ms=7 cost_usd=0.00002
2026-07-14T09:12:04Z governance.gw tenant=t_884 op=generate model=claude-sonnet in=1892 out=412 cost_usd=0.00891
Trei linii, un tenant, un request — reconciliabil cu un billing view din Snowflake, fără join-uri între patru vendori.
Ce schimbă de fapt TurboVec
Reducerea de cost de 3,1–9,0× față de bazele de date vectoriale managed nu e un truc de compresie. Vine din decuplarea indexului de codebook-ul de cuantizare proprietar al vendorului, ceea ce permite echipei să ruleze indexul pe containere general-purpose în loc de un SKU specific per vector DB. Pentru un SaaS mid-market cu 40M vectori distribuiți pe 200 de tenanți, asta e diferența dintre o linie lunară de $12k și una de $2k — și diferența dintre un slide de unit economics defensibil și o groapă la Series B.
Arhitectura se aliniază cu obligațiile de logare din Articolul 12 al EU AI Act pentru sistemele cu risc ridicat, care cer înregistrări trasabile per interacțiune. Rezistă și sub ghidul de securitate cloud al ENISA privind izolarea tenanților în infrastructură de inferență partajată. Reglementatorilor nu le pasă de modelul tău de cost. Le pasă că înregistrările per-tenant există — iar atribuirea costurilor per-tenant este un efect secundar al provenienței per-tenant.
Unde plasează CAI pariuri
Construim sistemele noastre RAG cu pattern-ul gateway-first ca standard. Atribuirea costurilor este semnalul de suprafață; câștigul mai profund este că aceeași structură transportă rate limits, audit logs și apărări contra prompt injection — vezi nota noastră despre amenințări de-a lungul retrieval-ului și generării. Pentru echipele care retrofitează asta într-un stack existent, munca mai grea nu este gateway-ul în sine, ci layerul de routing care decide ce request al cărui tenant ajunge la ce model sub ce SLA. Începe cu contorul, nu cu modelul. Vorbește cu noi despre un discovery de două săptămâni pe suprafața de cost a RAG-ului tău actual.