Token-költségvetés tenant szinten

Az LLM-használat költsége a Nortinia AI Asszisztensben tenant-szinten van számolva, és per-tenant napi + havi limittel védve. Ez a cikk leírja a soft / hard cap rendszert, a circuit-breaker viselkedését és az operátor-értesítések útvonalát.

Miért tenant-szintű

Egy nagy ügyfél (5000 felhasználó) napi 80 millió tokent használ. Egy kisebb (50 felhasználó) napi 200 ezret. User-szintű limit nem működik (az 5000 felhasználós tenant-nál meg kell csinálni mindegyiknek), és nem is fair (egy nagy tenant támogatja a saját power-userét). Tenant-szintű limit a természetes elszámolási egység, mert a tenant maga is így van számlázva.

A három cap

Napi soft cap

Minden tenantnak van egy napi token-büdzséje a contract szerint (pl. 5 millió token / nap a STANDARD tier-en). Amikor a használat eléri a 90%-ot, a rendszer két dolgot csinál:

1. Notify a tenant admin-nak — push és e-mail: "a mai költségvetés 90%-án vagytok".
2. Mutációs tool-ok preview-only-ra váltanak — minden write/update/delete tool csak előnézetet ad, nem hajt végre. A felhasználó látja, hogy mi történne, de a véglegesítéshez vagy várnia kell (másnapig), vagy az admin-nak kell felemelnie a cap-et.

A read-only tool-ok (keresés, KB-lookup, audit-lekérdezés) változatlanul mennek.

Napi hard cap

Amikor a használat eléri a 100%-ot:

1. Az asszisztens teljesen read-only-ra vált. Minden mutáció letiltva, csak olvasás megy.
2. Pager-szintű alert az ügyintézőnknek (Netorigo-oldali on-call).
3. A tenant admin-nak SMS (a soft-cap notify-on felül, hogy biztosan eljut).
4. A felhasználói chat-en figyelmeztetés — "a mai költségkereted elfogyott, holnap reggelig csak nézhetsz; cap-emeléshez fordulj az admin-odhoz".

A hard cap 24 órán át áll, majd a következő nap reggel 00:00 UTC-kor reset.

Havi cap

Ugyanaz a soft / hard logika, csak havi szinten. Ez véd a "napi cap-en belül maradok, de a hónap végére túllépem" forgatókönyvtől.

A circuit-breaker döntés-fa

Minden tool-hívás előtt a rendszer megnézi:

IF tenant.daily_used / tenant.daily_cap < 0.9
  → run tool normally
ELSE IF tenant.daily_used / tenant.daily_cap < 1.0
  → if tool is mutation: preview-only mode
  → if tool is read: run normally
ELSE
  → if tool is mutation: refuse, suggest admin contact
  → if tool is read: run normally

A havi cap-re ugyanez fut párhuzamosan, és a szigorúbb nyer.

Operátor-értesítés útvonala

Amikor egy tenant a hard cap-et eléri, a következő történik a Netorigo-oldalon:

1. PagerDuty alert — on-call mérnök 5 percen belül kap incident-et.
2. Auto-context — az alert tartalmazza a tenant nevét, az utolsó 24 óra használati grafikonját, és linket a billing-felületre.
3. Default action — az on-call mérnök egy gombnyomással emelheti a tenant cap-jét 20%-kal 24 órára (vészhelyzeti pótlék). Ez a csomag a hónap végén külön számlasoron jelenik meg az ügyfélnek.
4. Eskaláció — ha a tenant 3 napon belül kétszer eléri a hard cap-et, az ügyfél-menedzser kap egy auto-ticketet, hogy beszéljen az ügyféllel a tier-emelésről.

Mit lát a tenant admin

A tenant admin felületén egy /usage dashboard:

• Napi grafikon — utolsó 30 nap, óránkénti bontásban
• Per-user breakdown — ki használja a legtöbbet
• Per-tool breakdown — melyik tool-ok égetik a tokent (gyakran a long-form generálás)
• Trend-előrejelzés — "ha így megy tovább, a hó végére x%-on lesztek"
• Cap-emelés gomb — közvetlenül a tier-upgrade flow-ba viszi

A leggyakoribb cause

A hard cap találatok 80%-a egy konkrét mintázathoz köthető: egy hatalmas csoport-export, amit valaki chat-en kér ("adj exporttot az összes 2025-ös számláról"). Az LLM kontextusába betölt 50000+ rekordot, és a token-szám hirtelen ugrál.

2026 márciusban bevezettünk egy guard-ot: bizonyos méret felett (> 10MB tervezett kontextus) a tool nem fut le, hanem felajánl alternatívát ("ez az export hagyományos CSV-letöltésként megy ki, ne LLM-en keresztül"). Ezzel a hard cap találatok 60%-kal csökkentek.

Mit jelent ez az ügyfélnek

A tenant tudja, mire költ. Nem lepi meg a havi számla. A 90%-os soft cap mindig korai figyelmeztetés. A hard cap nem büntetés, hanem védőháló — és a vészhelyzeti emelés egy on-call gombnyomás. Az asszisztens nem áll le teljesen még hard cap esetén sem; csak a kockázatos műveletek várnak.

Mit fejlesztünk legközelebb

Per-user cap (tenant-szintű mellé) és per-team cap (közbenső szint), hogy egy egységen belül egyik csapat ne használja el a másik elől a kreteket. És elemzői view, ami megmondja, melyik feature kombinációból ér a tenant a legjobb költség / érték arányt.