Ez a cikk az LLM Modellválasztás Üzleti Döntései tanulmány 3. része. További részek: A 2026-os LLM piac térképe, Feladatalapú modellválasztás és benchmark-ok, Biztonság, lokális modellek és döntési mátrix.
Költségelemzés és optimalizáció
Forgatókönyv: AI asszisztens szolgáltató cégnek
Vegyünk egy valós, gyakorlati példát. Egy szolgáltató cég AI asszisztenst üzemeltet ügyfélkommunikációra, belső feladatkezelésre és elemzésekre. A használati minta a következő:
- Napi 100 interakció, amelyből 30% egyszerű (FAQ, emlékeztetők), 50% közepes (CRM-műveletek, email-generálás, naptárkezelés), és 20% komplex (elemzések, előrejelzések, javaslatok).
- Átlagos token-felhasználás interakciónként: egyszerű feladatoknál 1 500 input + 800 output token, közepes feladatoknál 3 000 + 2 000, komplex feladatoknál 5 000 + 4 000 token.
- Havi összesen: ~3 000 interakció.
A kérdés: melyik modellt (vagy modelleket) használjuk, és hogyan befolyásolja ez a költséget és a minőséget?
A. Egységes modell megközelítés
Az egyszerűbb út: egyetlen modellt használunk mindenre. Nézzük meg, mit jelent ez költségben és minőségben:
Jól látható a dilemma: a csúcsmodellek drágák, az olcsó modellek pedig a komplex feladatoknál gyengélkednek. Mi lenne, ha nem kellene választani?
B. Feladatalapú routing (optimalizált)
A megoldás: minden feladattípushoz a legalkalmasabb modellt rendeljük. Ez a feladatalapú routing lényege.
Az összehasonlítás
Most tegyük egymás mellé az összes megközelítést, hogy kristálytisztán lássuk a különbséget:
A routing 60%-kal olcsóbb, mint az egységes GPT-4o, és jobb minőségű a komplex feladatoknál. A $41/hó routingolt költség a GPT-4o-s $105-nek mindössze 39%-a, miközben a komplex elemzéseket a Claude 3.7 Sonnet kezeli — ami az összehasonlító benchmarkok szerint erősebb reasoning képességekkel rendelkezik. Két legyet ütünk egy csapásra: spórolunk és jobb minőséget kapunk.
Token-optimalizációs technikák
A modellválasztáson túl a token-felhasználás optimalizálása is drámai megtakarítást hozhat. Az alábbi technikák akár 50-90%-os költségcsökkentést eredményezhetnek:
Ezek közül érdemes kiemelni a prompt caching-et, amely az egyik legegyszerűbben alkalmazható és legnagyobb hatású technika. A működése a következő: amikor egy AI ügynök (agent) rendszeresen ugyanazt a hosszú system promptot küldi — például egy 2 000 tokenes utasításkészletet, amely tartalmazza a cég szabályait, a válaszadási stílust és az elérhető eszközök leírását — a szolgáltató (OpenAI vagy Anthropic) a szerver oldalon gyorsítótárazza (cache-eli) ezt a prefix-et. Az ezt követő kéréseknél, amelyek ugyanezzel a prefixszel kezdődnek, a cached tokenek jelentős kedvezménnyel kerülnek elszámolásra. Az OpenAI 50%-os kedvezményt ad a cache-elt input tokenekre, az Anthropic pedig akár 90%-os kedvezményt biztosít. Egy olyan AI ügynöknél, amely napi 100 interakciót kezel hosszú system prompttal, ez havonta akár 40-70%-os megtakarítást jelent csak az input token költségeken. A prompt caching különösen értékes agent-alapú rendszereknél, ahol a system prompt gyakran tartalmaz részletes tool-leírásokat, few-shot példákat és viselkedési szabályokat — ezek mind cache-elhetők.
Multi-modell architektúra — A routing stratégia
Hogyan működik a modell-routing?
A routing lényege egyszerű: ahelyett, hogy egyetlen modellre bíznánk minden feladatot, egy köztes réteg — a classifier — megvizsgálja a beérkező kérdést, meghatározza annak komplexitását, és a megfelelő modellhez irányítja.
Felhasználói kérdés
│
┌──────▼──────┐
│ Classifier │
│ (milyen │
│ feladat?) │
└──────┬──────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Egyszerű │ │ Közepes │ │ Komplex │
│ │ │ │ │ │
│ GPT-4o- │ │ GPT-4o- │ │ Claude │
│ mini │ │ mini │ │ 3.7 │
│ │ │ + tools │ │ Sonnet │
└──────────┘ └──────────┘ └──────────┘
A classifier feladata az, hogy gyorsan és olcsón megállapítsa, milyen típusú feladattal állunk szemben. Az egyszerű, tényszerű kérdések (FAQ, nyitvatartás, árlista) a legolcsóbb modellhez kerülnek. A közepes komplexitású feladatok — amelyek eszközhasználatot igényelnek, például CRM-lekérdezés vagy email-küldés — szintén egy költséghatékony, de tool calling-ban megbízható modellhez irányulnak. A komplex, többlépéses elemzések és javaslatok pedig a legerősebb reasoning képességű modellhez jutnak el. Az eredmény: minden feladat pontosan azt a „szintű" modellt kapja, amelyre szüksége van — sem többet, sem kevesebbet.
A 3 routing stratégia
1. Szabályalapú routing (legegyszerűbb)
A legkézenfekvőbb megoldás: egyszerű szabályok alapján irányítjuk a kérdéseket. Nincs szükség AI-ra a routing-hoz, elég néhány kulcsszó és feltétel:
Ha a kérdés tartalmazza: "mikor" / "hol" / "árlista" / "nyitvatartás"
→ GPT-4o-mini (egyszerű FAQ)
Ha tool calling szükséges (CRM, email, naptár)
→ GPT-4o-mini (jó tool calling, alacsony költség)
Ha elemzés / javaslat / forecast kell
→ Claude 3.7 Sonnet (legjobb reasoning)
Előnyök: egyszerű implementáció, gyors (nulla extra latency), determinisztikus és kiszámítható működés. Pontosan tudjuk, melyik modell fog válaszolni, nincs meglepetés.
Hátrányok: merev, nem kezeli jól a határeseteket. Ha egy kérdés egyszerre tartalmaz FAQ-jellegű és elemzési elemeket, a szabályok könnyen félreosztályozhatják. Karbantartás-igényes: minden új feladattípushoz új szabályt kell felvenni.
2. LLM-alapú routing (kifinomultabb)
Egy kis, gyors modell (például GPT-4o-mini vagy Claude 3.5 Haiku) végzi az osztályozást. A classifier maga is egy LLM, amelyet egy rövid system prompttal utasítunk az osztályozásra:
System prompt a classifier-nek:
"Osztályozd a felhasználó kérdését: SIMPLE, MEDIUM, COMPLEX.
SIMPLE: tényszerű, rövid válasz, FAQ.
MEDIUM: eszközhasználatot igényel, CRM/email/naptár.
COMPLEX: elemzés, javaslat, összehasonlítás, több lépés."
A classifier költsége elhanyagolható: ~$0.0001 kérésenként (egy rövid input, egyetlen szavas output). 3 000 havi interakciónál ez összesen ~$0.30 — gyakorlatilag nulla.
Előnyök: rugalmasabb, mint a szabályalapú routing, képes a természetes nyelv árnyalatait is értelmezni. Adaptív: ha változik a feladatok jellege, nem kell kódot módosítani, elég a classifier promptját finomhangolni.
Hátrányok: extra latency (~200ms a classifier válaszára), és a classifier is tévedhet. Előfordulhat, hogy egy komplex kérdést SIMPLE-nek osztályoz, ami gyengébb válaszhoz vezet. Érdemes logolni az osztályozásokat és rendszeresen ellenőrizni a pontosságot.
3. Fallback-alapú routing (legrobusztusabb)
Ez a stratégia a rendelkezésre állásra (availability) fókuszál: ha az elsődleges modell nem válaszol időben, automatikusan átvált egy tartalék modellre:
1. GPT-4o-mini (elsődleges, legjobb ár/érték)
↓ ha nem válaszol 10mp-en belül
2. Claude 3.5 Haiku (tartalék)
↓ ha nem válaszol 10mp-en belül
3. Hiba → emberi eszkaláció
Előnyök: magas rendelkezésre állás, egyetlen szolgáltató kiesése sem okoz rendszerleállást. Ez különösen fontos üzletkritikus alkalmazásoknál, ahol az AI asszisztens válaszképessége közvetlenül befolyásolja az üzleti folyamatokat.
Hátrányok: a tartalék modell eltérő stílusban vagy minőségben válaszolhat, ami konzisztencia-problémát okozhat. Ha a felhasználó kétszer teszi fel ugyanazt a kérdést, és egyszer az elsődleges, egyszer a tartalék modell válaszol, az eltérő válaszok bizalomvesztéshez vezethetnek. Ezt részben orvosolhatjuk egységesített system prompt-okkal.
A javasolt megoldás: hibrid routing
A gyakorlatban nem kell egyetlen stratégia mellett dönteni — a három megközelítés kombinálható:
- Szabályalapú routing az egyértelmű esetekre: FAQ-kérdések → GPT-4o-mini, elemzési kérések → Claude 3.7 Sonnet. Ezek gyorsak, olcsók és megbízhatóak.
- LLM classifier a nem egyértelmű esetekre: ha a szabályok nem tudják egyértelműen besorolni a kérdést, egy gyors classifier modell dönt a routing-ról.
- Fallback mechanizmus a szolgáltató-kiesések kezelésére: ha az elsődleges modell nem válaszol, automatikus átváltás a tartalékra, végső esetben emberi eszkaláció.
Ez a hibrid megközelítés a legtöbb vállalati felhasználás esetében a legjobb ár-érték arányt biztosítja. A gyakorlati implementáció meglepően egyszerű: a legtöbb keretrendszerben (LangChain, Semantic Kernel, egyedi Node.js/Python megoldás) egy router megvalósítása 50-100 sor kód. A szabályalapú routing egy egyszerű switch/case vagy if-else lánc, az LLM classifier egy extra API-hívás a beérkező kérdéssel, a fallback pedig egy try/catch időkorláttal. A megtérülés azonnali — a routing logika futtatási költsége gyakorlatilag nulla a modellhasználati megtakarításhoz képest, és már az első hónapban jelentős összeget spórol.
A sorozat záró részében a biztonságot, az adatrezidenciát és a lokális modelleket vizsgáljuk meg, valamint egy összefoglaló döntési mátrixot adunk. Olvassa el: Biztonság, lokális modellek és döntési mátrix. Vagy tekintse meg a teljes tanulmányt: LLM Modellválasztás Üzleti Döntései.