AI Platform és LLMOps

Miért érdekel ez téged?

Az AI Platform az a réteg, amely az egyszeri, „a laptopomon működik" prototípusból megismételhető, auditálható, több csapat által biztonságosan használható rendszert csinál. Ez tiszta platform engineering — csak a szállítandó artefaktumok mások: modellek, promptok, eval-készletek és trace-ek a bináris helyett.

A jó hír, hogy a mentális modelled nagyrészt átvihető. Amit CI/CD-ről, artifact registryről, secret managementről, Infrastructure-as-Code-ról és multi-tenancyről tudsz, az mind érvényes marad — csak ki kell egészítened azzal, ami az LLM-eket különlegessé teszi: hogy a kimenet nemdeterminisztikus, a minőséget nem unit teszt, hanem eval méri (lásd 11. Evals), és a legdrágább erőforrásod nem a CPU, hanem a GPU-memória. Ebben a fejezetben ezt a két világot kötjük össze.

Konkrétan miért éri meg ezt a réteget felépíteni? Mert a különbség egy „demo" és egy „termék" között szinte teljes egészében itt dől el. Egy demónál elég, ha egy fejlesztő beírja a saját API-kulcsát a kódba, és a prompt egy Python-stringben lóg. Egy terméknél viszont húsz csapat hív ugyanarra a modellre, a havi számla öt- vagy hatszámjegyű, egy rossz prompt-módosítás percek alatt ronthatja el több ezer ügyfél élményét, és egy szabályozó bármikor kérheti, hogy bizonyítsd: hat hónapja pontosan milyen modell milyen adaton milyen választ adott. Ezekre a kérdésekre a platform réteg ad választ — vagy a hiánya okoz belőlük válságot.

Tudnivalók

A platform réteg fogalmait négy csoportba rendeztem: mit tárolsz és verziózol, hogyan éred el a modelleket, hogyan szállítod ki a változást, és hogyan tartod kordában a hozzáférést és a költséget. Mindegyikhez ott a DevOps-megfelelője, hogy legyen mihez kötnöd. A négy csoport együtt adja ki azt, amit az iparág LLMOps néven emleget: a klasszikus MLOps kiterjesztése a nyelvi modellek és a prompt-alapú fejlesztés sajátosságaira.

Registry-k és verziózás

Az AI-rendszernek sokféle „artefaktuma" van, és mindet ugyanolyan fegyelemmel kell verziózni, mint a kódot. Ezek a nyilvántartások adják a rendszer megismételhetőségét. A vezérelv egyszerű: ha egy éles válasz létrejöttéhez valami hozzájárult, annak verziózott, visszakereshető artefaktumnak kell lennie — nem egy fejlesztő fejében élő „azt hiszem, azt a promptot használtuk".

• Model registry Központi nyilvántartás arról, milyen modellek (provider modellverziók vagy saját fine-tune-olt súlyok) érhetők el, milyen metaadatokkal, stage-ekkel (staging, production) és jóváhagyással. Pontosan úgy viszonyul az AI-hoz, mint a container registry a mikroszolgáltatásokhoz: nem a laptopodon buildelt „valamit" deployolsz, hanem egy címkézett, visszakereshető, előléptethető artefaktumot. A gyakorlatban itt tárolod azt is, hogy a gpt-4.1-2025-04-14 pontos snapshot-verziót használod, nem a lebegő gpt-4.1 aliast — mert az alias mögött a provider csendben lecserélheti a modellt, és a viselkedésed egyik napról a másikra megváltozik.
• Prompt registry A promptok verziózott tárolása kódon kívül, hogy a szöveg módosításához ne kelljen újradeployolni az egész alkalmazást, és minden változás nyomon követhető legyen. Gondolj rá úgy, mint a feature flag / config szolgáltatásra: a prompt viselkedést befolyásoló konfiguráció, amit önállóan kell verzióznod, tesztelned és visszagörgetned. Egy tipikus setupban a prompt customer-support-summary@v7 névvel és verzióval hivatkozható, és egy termékmenedzser is szerkesztheti egy felületen — de az élesítés akkor is végigmegy az eval gate-en, nem csúszik ki review nélkül.
• Evaluation registry Az eval-készletek (teszthalmazok, scorer-ek, elvárt küszöbök) verziózott nyilvántartása. Ez az AI megfelelője a teszt-suite-nak: ahogy a kódot sem engeded élesbe zöld tesztek nélkül, úgy egy prompt- vagy modellváltozást sem, amíg a hozzá tartozó eval-készleten nem teljesíti a küszöböt. Egy tipikus eval-készlet 50–500 esetből áll, mindegyikhez tartozik egy scorer (pl. „tartalmazza-e a helyes tényt", „megfelelő-e a JSON-séma"), és egy aggregált küszöb, pl. 0.90 pass-rate. A készletet ugyanúgy verziózod, mint a kódot, mert ha a teszt változik, a régi és új futás nem összehasonlítható.
• Dataset versioning Az eval- és tanítóadatok verziózása, hogy egy eredmény reprodukálható legyen. Ha az adathalmaz csendben változik, két „azonos" futás eltérő számot ad — és onnantól nem tudod, a modell vagy az adat mozdult-e. Ugyanaz a probléma, mint amikor egy build nem pinnelt függőségtől lesz nemdeterminisztikus; a megoldás is ugyanaz: pinnelés és tartalom-hash. A gyakorlatban vagy egy dedikált eszköz (pl. DVC, LakeFS) tartja a verziókat, vagy object storage-ban immutable, tartalom-hashelt fájlokként tárolod, és a hash-t rögzíted az eval-futás mellé.
• Trace storage Az LLM-hívások teljes nyomvonalának tárolása: prompt, kontextus, tool-hívások, tokenszám, latency, kimenet. Ez a distributed tracing (Jaeger, Tempo) AI-változata, és egyben az eval-adatok forrása is — az éles trace-ekből építesz új teszteseteket. A tárolásról és a hasznosításról részletesen a 14. Observability fejezet szól. Fontos méretezési szempont: egy trace nem néhány száz bájt, mint egy klasszikus log-sor, hanem gyakran több tíz kilobájt (a teljes kontextus és kimenet miatt), így nagy forgalomnál napi több gigabájt trace-adattal és sampling-döntésekkel is kell számolnod.
• Experiment tracking Kísérletek (prompt-variánsok, modellek, paraméterek) és a hozzájuk tartozó eval-eredmények strukturált naplózása, hogy össze tudd hasonlítani őket és tudd, melyik verzió miért nyert. Ez a build-history és a metrika-dashboard keveréke: nélküle a „melyik prompt volt jobb?" kérdésre csak emlékezetből tippelnél. Egy tipikus eszköz (pl. MLflow GenAI, Langfuse, Weights & Biases) minden futáshoz eltárolja a bemenő paramétereket, a git commit hash-t, az eval-pontszámot és a költséget, így hetekkel később is pontosan látod, hogy a v7 prompt azért nyert, mert a hallucination-ráta 4%-ról 1%-ra esett, cserébe a latency 200ms-mal nőtt.
• Feature és configuration management A viselkedést vezérlő beállítások — modellválasztás, temperature, retrieval-paraméterek, feature flag-ek — kódon kívüli, környezetenként eltérő kezelése. Így ugyanaz az artefaktum viselkedhet másképp stagingen és productionben, és egy kapcsoló átbillentésével kísérletezhetsz újradeploy nélkül. Ez teszi lehetővé az A/B tesztet is: a felhasználók 10%-a kapja az új retrieval-beállítást, a többi a régit, és az eredményt eval- és üzleti metrikákon méred, mielőtt mindenkire kigörgeted.

from platform_sdk import PromptRegistry, ModelRegistry

prompts = PromptRegistry()
models = ModelRegistry()

# Nem a kódba égetve, hanem verziózva, névvel hivatkozva:
prompt = prompts.get("customer-support-summary", stage="production")
model = models.resolve("summary-model", stage="production")

# A trace automatikusan rögzíti a prompt- és modellverziót:
response = client.responses.create(
    model=model.snapshot_id,      # pl. "gpt-4.1-2025-04-14"
    input=prompt.render(ticket=ticket_text),
    metadata={"prompt_version": prompt.version, "tenant": tenant_id},
)

Mit tanulj belőle: a lényeg nem a konkrét SDK, hanem az elv — se a modell, se a prompt nincs a kódba égetve. Mindkettő névvel és stage-gel feloldott, verziózott artefaktum, és a hívás metaadatában ott a pontos verzió, hogy egy trace-ből visszafejthesd, mi termelte a választ.

Model gateway és routing

A gateway az a belépési pont, amelyen keresztül az egész szervezet eléri a modelleket — ez az AI-forgalom API gateway / reverse proxy rétege. Ha egyetlen dolgot építesz meg elsőként a platformból, ez legyen az: minden más kontroll (költségmérés, rate limit, policy, routing) rá épül, mert csak akkor tudsz központilag szabályt érvényesíteni, ha minden hívás egy helyen megy át.

• Model gateway Egyetlen belső végpont, amely az összes modellhívást közvetíti a providerek felé, és egy helyen intézi a hitelesítést, a rate limitelést, a költségmérést, a naplózást és a cache-elést. Pontosan az a szerepe, mint egy API gateway-nek: az alkalmazások nem közvetlenül a providerrel beszélnek, hanem a gateway mögött vannak, ezért a szabályokat központilag tudod érvényesíteni. Architektúrális szerepéről lásd a 13. Production architektúra fejezetet. A gyakorlatban ezt megveheted készen (pl. LiteLLM proxy, Portkey, Cloudflare AI Gateway), vagy építhetsz sajátot; a döntést az szabja meg, mennyi egyedi policy- és tenant-logika kell bele.
• Multi-provider routing A kérések elosztása több provider vagy modell között — költség, sebesség, elérhetőség vagy képesség alapján. Ez a load balancing és a failover AI-változata: ha az egyik provider kiesik vagy rate limitel, a gateway átirányít egy másikra, az egyszerű feladatokat pedig olcsóbb modellre terelheti. Bónusz, hogy így nem ragadsz egyetlen szállítóhoz. Konkrét számpélda: ha az egyszerű osztályozási kéréseidet egy kis, olcsó modellre tereled (nagyságrendileg tizede-huszada egy csúcsmodell tokenköltségének), és ez a forgalom 60%-a, a havi számlád akár a felére eshet érdemi minőségromlás nélkül.

def route(request):
    # 1) Feladat-nehézség szerint: olcsó modell az egyszerűre
    if request.task_type == "classification":
        candidates = ["small-cheap", "mid-model"]
    else:
        candidates = ["frontier-model", "mid-model"]

    # 2) Failover: az első elérhető, nem rate-limitelt providert választjuk
    for name in candidates:
        provider = registry.resolve(name)
        if provider.is_healthy() and not provider.is_rate_limited():
            return provider
    raise NoHealthyProviderError("minden candidate kiesett")

Mit tanulj belőle: a routing két, egymástól független döntés — a feladat nehézsége (melyik modellosztály elég jó) és a rendelkezésre állás (melyik provider ér most rá). A gateway ezt a két szempontot egy helyen, minden hívásra egységesen alkalmazza, az alkalmazásfejlesztőnek nem kell tudnia róla.

Deployment és CI/CD

Itt válik a platform igazán DevOps-szá: a promptot, a modellt és a konfigurációt ugyanazon a fegyelmezett, automatizált úton kell élesbe juttatnod, mint a kódot.

• Deployment environments Elkülönített környezetek (dev, staging, production) külön kulcsokkal, kvótákkal, adatokkal és jogosultságokkal. Ugyanaz a promóciós lánc, mint a klasszikus szoftvernél: a változás előbb egy alacsony kockázatú környezetben bizonyít, mielőtt éles forgalmat kapna. AI-specifikus csavar: a stagingen ideális esetben ugyanazt a modell-snapshotot használod, mint productionben, különben a stagingen mért eval-eredmény nem sokat ér — a modellváltozás önmagában is viselkedésváltozás.
• CI/CD eval gate-ekkel A szállítási pipeline, amelyben a prompt- vagy modellváltozás csak akkor mehet tovább, ha az eval-készleten átment. Ez pontosan az a hely, ahol a hagyományos CI teszt gate helyére eval gate kerül: a merge/deploy feltétele nem a zöld unit teszt, hanem a küszöböt elérő eval-pontszám. Ez a fejezet legfontosabb kapcsa a 11. Evals fejezethez. Fontos különbség a unit teszthez képest: az eval nemdeterminisztikus és pénzbe kerül (minden eset egy vagy több modellhívás), ezért a gate futása lehet perces nagyságrendű és mérhető költségű — ezt be kell tervezned a pipeline-ba.
• Canary és rollback Az új verzió fokozatos kigörgetése a forgalom kis részére (canary), az éles metrikák figyelése, és gyors visszaállás a korábbi verzióra, ha romlanak. Szó szerint ugyanaz a technika, mint a mikroszolgáltatásoknál — csak amit a canaryn figyelsz, az nem csak hibaarány és latency, hanem eval- és minőségi jelzések is. Például: az új prompt a forgalom 5%-át kapja, és ha a felhasználói „hasznos volt?" arány 3 százalékponttal esik vagy a hallucination-flag megugrik, automatikus rollback.
• Artifact lineage A teljes láncolat visszakövethetősége: melyik éles válasz melyik prompt-, modell- és dataset-verzióból, milyen kóddal és konfigurációval született. Ez a build-provenance AI-változata — nélküle egy incidensnél nem tudod rekonstruálni, pontosan mi termelte a hibás kimenetet. A lineage gyakorlati teszt: ha egy ügyfél panaszt tesz egy három héttel ezelőtti válaszra, öt percen belül meg tudod-e mondani, melyik prompt- és modellverzió, milyen retrieval-találatokkal állította elő? Ha nem, a lineage hiányos.
• Infrastructure-as-Code A platform teljes leírása verziózott kódként (Terraform, Pulumi, Helm): gateway-k, kvóták, kulcsok, jogosultságok, indexek. Ugyanaz az elv, amit már ismersz — a környezet ne kézzel összekattintott állapot legyen, hanem reprodukálható, review-zható, verziózott definíció. AI-kontextusban ide tartozik a vektoradatbázis-index, a provider-kvóták, a gateway-routing-szabályok és a GPU-node-poolok deklaratív leírása is.

eval-gate:
  script:
    - python run_evals.py --suite qa-core --model $CANDIDATE
  rules:
    # csak akkor megy tovább a deploy, ha a pontszám a küszöb felett van
    - if: '$EVAL_SCORE >= 0.85'
      when: on_success
    - when: manual   # küszöb alatt: emberi jóváhagyás kell

Mit tanulj belőle: a gate nem bináris „megy / nem megy", hanem három állapotú. Küszöb felett automatikusan tovább; küszöb alatt nem tiltás, hanem emberi jóváhagyás — mert egy eval-esés lehet valós regresszió, de lehet flaky eset vagy elavult teszt is, amit egy embernek kell megítélnie.

Egy AI-változás útja élesig

Rakjuk össze a fenti fogalmakat egyetlen konkrét történetbe, mert így látszik, hogyan kapcsolódnak. Tegyük fel, egy termékmenedzser azt kéri, hogy az ügyfélszolgálati összefoglaló legyen rövidebb és empatikusabb.

1. A promptot a prompt registry felületén szerkeszti valaki, létrejön a customer-support-summary@v8 verzió — a v7 érintetlen marad.
2. A pull request elindítja a CI eval gate-et: a v8 lefut a verziózott eval-készleten (mondjuk 120 eseten), és mér empátia-scorert, hosszkorlátot és tény-megtartást.
3. Az eval-pontszám 0.88, a küszöb 0.85 — a gate zöld, a change mergelhető. Az eredmény bekerül az experiment trackingbe, összehasonlíthatóan a v7-tel.
4. Deploy után a canary a forgalom 5%-át tereli a v8-ra; a gateway méri a latencyt, a költséget és a felhasználói visszajelzést.
5. 24 óra után a metrikák jók, a kigörgetés 100%. A lineage minden válaszhoz rögzíti: prompt v8, model snapshot X, retrieval index Y — így ha később panasz jön, visszakövethető.

Vedd észre: egyetlen sor alkalmazáskódot sem kellett módosítani, mégis fegyelmezett, visszagörgethető, auditálható maradt a folyamat. Ez a platform réteg értéke egy mondatban.

Governance, biztonság és multi-tenancy

A platformnak nem csak működnie kell, hanem elszámoltathatónak és biztonságosnak is — több csapat, több ügyfél, több régió mellett is. A biztonsági támadási felületről és a védekezésről a 15. AI security fejezet szól részletesen; itt a platform-oldali kontrollokra koncentrálunk.

• Secrets A provider-API-kulcsok és egyéb titkok központi, titkosított kezelése (Vault, KMS, cloud secret manager), rotációval és auditálással. Semmi új a DevOps-hoz képest — de itt különösen fájdalmas a szivárgás, mert egy kiszivárgott kulccsal valaki a te költségeden hívogatja a modelleket. Egy nyilvános repóba véletlenül commitolt provider-kulcs órák alatt több ezer dolláros számlát generálhat, mielőtt észreveszed; ezért kell a kulcsokat a gateway mögé rejteni, ahol per-alkalmazás kvóta és riasztás védi őket.
• Identity Ki (melyik felhasználó, csapat vagy szolgáltatás) mit hívhat: hitelesítés és jogosultságkezelés a gateway szintjén. Ez a szokásos IAM/RBAC, kiterjesztve arra is, hogy melyik tenant melyik modellhez, adathoz és kvótához férhet hozzá. A gyakorlatban minden alkalmazás saját service-identityt kap a gateway felé, nem egy közös „mindenki ezt használja" kulcsot — így a fogyasztás és a jogosultság is elkülöníthető.
• Policy-as-code A szabályok — kik használhatnak mely modellt, milyen adat mehet ki, milyen régió engedélyezett — verziózott, gépileg kikényszerített kódként (pl. OPA/Rego), nem PDF-ben rejtőző házirendként. Így a megfelelőség automatikusan érvényesül minden hívásnál, és a szabályváltozás is review-n megy át. Példa: egy policy megtilthatja, hogy PII-t tartalmazó kérés egy adott, EU-n kívüli providerhez menjen — és ezt a gateway a hívás pillanatában kényszeríti ki, nem utólagos auditból derül ki.
• Cost allocation A tokenköltség hozzárendelése csapathoz, termékhez vagy ügyfélhez, hogy lásd, ki mennyit fogyaszt, és tudj kvótázni. Ez a cloud cost tagging / showback–chargeback AI-változata; a model gateway az a hely, ahol a fogyasztás egyáltalán mérhető, mert minden hívás rajta megy át. A gyakorlatban minden hívás metaadatában ott a tenant, a team és a feature címke, a gateway pedig token- és költségösszesítőt tart hozzájuk — így hónap végén nem egy összesített számlát látsz, hanem lebontva, hogy melyik funkció mennyit evett.
• Tenant isolation Több ügyfél vagy csapat adatainak és forgalmának szigorú elkülönítése, hogy egyik se lásson bele a másikéba, és egyik terhelése ne fojtsa meg a másikat (noisy neighbor). A multi-tenant SaaS-ból ismert elv, kiegészítve azzal, hogy a kontextus és a retrieval-index se keveredhessen tenantek között. Ez utóbbi AI-specifikus és alattomos hiba: ha a vektorkeresés nincs tenantre szűrve, az egyik ügyfél kérdésére a másik ügyfél dokumentumából jöhet találat — súlyos adatszivárgás.
• Regional deployment és data residency A feldolgozás és a tárolás földrajzi helyének szabályozása, hogy az adat ott maradjon, ahol jogilag maradnia kell (pl. EU-adat EU-ban). Ez a multi-region deployment megszokott feladata, itt azzal a csavarral, hogy a provider-régiót és a modell elérhetőségét is figyelembe kell venned, nem csak a saját szolgáltatásaidét. Fájdalmas felismerés lehet, hogy egy adott csúcsmodell csak bizonyos régiókban érhető el — így a data residency követelmény korlátozhatja, milyen modellt használhatsz egyáltalán.
• Auditability Utólag bizonyíthatóan visszakereshető, ki mit kért, milyen modellel, milyen adaton, milyen eredménnyel. Ez az audit log a szabályozott iparágakban (pénzügy, egészségügy, biztosítás) nem opció, hanem követelmény — és épp a trace storage plusz az artifact lineage adja hozzá az alapanyagot. Az EU AI Act és hasonló szabályozások kifejezetten megkövetelik a nyomon követhetőséget bizonyos kockázati kategóriákban, így ez üzletileg is kötelezővé válhat, nem csak jó gyakorlat.

Gyakori hibák a platform építésekor

Ezek a hibák annyira tipikusak, hogy szinte minden csapat átesik legalább egyiken. Érdemes előre ismerni őket.

• A prompt a kódba égetve Ha a prompt egy Python-stringben lóg, minden szövegmódosításhoz teljes deploy kell, és nincs önálló verziótörténete. Az első tünet: valaki „gyorsan javít" egy promptot közvetlenül productionben, és senki nem tudja rekonstruálni, mi változott. Megoldás: prompt registry a nulladik naptól.
• Nincs eval gate, csak „ránézésre jó" A csapat kézzel próbál ki néhány esetet minden változás előtt. Ez 5 esetnél működik, 500-nál nem, és a regressziók észrevétlenül csúsznak be. A kézi tesztelés nem skálázódik és nem reprodukálható — ezt csak automatizált eval gate oldja meg.
• Lebegő modell-alias productionben A gpt-4.1-re hivatkozol a pinnelt snapshot helyett, és amikor a provider frissíti a modellt, a viselkedésed egyik napról a másikra megváltozik — reprodukálhatatlan „miért lett hirtelen rosszabb?" incidens. Mindig pinnelt snapshot-verziót használj productionben.
• Közvetlen provider-hívások gateway nélkül Ha az alkalmazások közvetlenül a providert hívják, nincs központi költségmérés, rate limit, policy vagy failover — és minden csapat újra megírja ugyanazt a retry-logikát. A gateway kihagyása rövid távon gyorsabb, hosszú távon minden kontrollt lehetetlenné tesz.
• Nincs tenant-szűrés a retrievalen A vektorkeresés az összes tenant dokumentumán fut, mert „majd később megoldjuk az izolációt". Ez a leggyakoribb súlyos AI-adatszivárgás forrása — a tenant-szűrésnek az index-lekérdezés részének kell lennie, nem utólagos gondolatnak.

Self-hosted inference

Előbb-utóbb felmerül, hogy saját GPU-n futtass modellt — adatvédelmi, költség- vagy testreszabási okból. Itt nem kell a mélyére menned a GPU-programozásnak, de a fogalmakat érdemes érteni, mert ezek határozzák meg, hogy a self-hosting megéri-e, és mennyi vasat kell alá tenned. A menedzselt API kényelmét cseréled el az irányításra és a magasabb üzemeltetési komplexitásra.

Mikor éri meg self-hostolni?

Mielőtt a technikai fogalmakba merülnénk, a legfontosabb kérdés a döntés maga. A self-hosting ritkán az alapértelmezett választás — a legtöbb csapatnak sokáig a menedzselt API a helyes út.

Serving és átbocsátás

• vLLM / TGI-szerű serving Erre a célra épített inference szerverek (vLLM, Text Generation Inference), amelyek egyetlen modell mögé sok párhuzamos kérést szolgálnak ki hatékonyan. Ezek az AI megfelelői egy jól hangolt alkalmazásszervernek: nem te írod meg a kérés-ütemezést és a memória­kezelést, hanem egy kiforrott réteg intézi. Fontos: soha ne futtass éles forgalmat egy modellt a nyers transformers-hívogatásával — az egy kérést szolgál ki egyszerre, a dedikált serving réteg viszont tízszeres-százszoros átbocsátást hozhat ugyanazon a kártyán.
• Continuous batching A beérkező kéréseket menet közben, dinamikusan vonja össze kötegekbe a GPU jobb kihasználásáért, ahelyett hogy megvárná egy fix köteg megtelését. Olyan, mint egy lift, amely nem indul félig üresen, de nem is várat mindenkit a végtelenségig — folyamatosan veszi fel és teszi le az utasokat. Ez a self-hosted throughput egyik legnagyobb nyeresége: a naiv, kérésenkénti feldolgozáshoz képest a GPU-kihasználtság drámaian nő, mert amint egy kérés befejeződik a kötegben, a helyére azonnal belép egy új.
• KV-cache management A generálás közbeni Key-Value cache (lásd 1. LLM alapok) tárolása és felszabadítása a GPU-memóriában. Mivel ez a cache foglalja a memória nagy részét, a hatékony kezelése dönti el, hány kérést tudsz párhuzamosan kiszolgálni egy kártyán. Nagyságrend: a KV-cache mérete a kontextushossztól és a párhuzamos kérések számától függ, és hosszú kontextusnál könnyen több gigabájtot ehet — sokszor ez, nem a modellsúly a szűk keresztmetszet.
• Paged attention A KV-cache lapokra (page) bontott kezelése, az operációs rendszer virtuálismemória-lapozásának mintájára. Így nem kell összefüggő memóriablokkot előre lefoglalni, csökken a töredezettség, és jóval több párhuzamos kérés fér el ugyanazon a GPU-n — a vLLM ezért gyors. Az analógia pontos: ahogy az OS sem foglal egy folytonos fizikai memóriatartományt minden processznek, úgy a paged attention sem foglal folytonos KV-blokkot minden kérésnek, hanem lapokban gazdálkodik.
• Prefix caching Ha sok kérés ugyanazzal az előtaggal indul (pl. közös rendszerprompt), annak a számítását egyszer végzi el és újrahasznosítja. Ez a memoizáció klasszikus trükkje: a közös munkát ne csináld meg minden kérésre újra — nagy rendszerpromptoknál látványosan csökkenti a latencyt és a költséget. Konkrét eset: ha minden kérésed elé ugyanaz a 2000 tokenes rendszerprompt kerül, prefix caching nélkül minden kérésre újra feldolgozod; cache-sel a közös rész számítása egyszer történik meg.

Párhuzamosítás és GPU-memória

• Tensor parallelism Egyetlen réteg számítását osztja szét több GPU között, amikor a modell túl nagy egy kártyához, vagy gyorsítani kell. A GPU-k szorosan együtt dolgoznak minden lépésen, ezért gyors összeköttetés (NVLink) kell közéjük. Mikor NE: ha a modell elfér egyetlen kártyán, ne bontsd fel — a GPU-k közti kommunikáció overheadje ilyenkor csak lassít.
• Pipeline parallelism A modell rétegeit szakaszokra vágja, és az egyes szakaszokat külön GPU-kra teszi, futószalagszerűen. Mint egy gyártósor: minden állomás a modell egy szeletét végzi, és a kérések végigfolynak rajta. Gyakran a tensor parallelismmel kombinálva használják nagyon nagy modelleknél, amelyek több node-nyi GPU-t igényelnek, mert egyetlen gépbe már nem férnek be.
• Quantization A modell súlyainak kisebb pontosságra kerekítése (pl. 16 bitről 8-ra vagy 4-re), hogy kevesebb GPU-memóriát foglaljon és gyorsabban fusson, cserébe kis minőségromlásért. Gyakran ez dönti el, hogy egy modell egyáltalán elfér-e a rendelkezésre álló kártyán. Nagyságrend: a 16-ról 8 bitre kvantálás durván feleannyi memóriát igényel, a 4 bites még kevesebbet — de a minőségromlás modell- és feladatfüggő, ezért kvantálás után mindig futtasd le az eval-készletet, hogy lásd, mennyit veszítettél.
• GPU memory sizing Annak megtervezése, mennyi GPU-memória kell: a modell súlyai plusz a KV-cache plusz a batch mérete együtt adja ki az igényt. Ez a capacity planning AI-változata — ha alábecslöd, out-of-memory hibába futsz éles forgalomban, ha túl, fölöslegesen égeted a pénzt. Ökölszabály a súlyokra: a paraméterszám szorozva a byte/paraméter értékkel (16 bitnél 2 byte), plusz jelentős ráhagyás a KV-cache-re — egy néhány milliárd paraméteres modell így könnyen tíz gigabájt nagyságrendet foglal el pusztán a súlyokkal.
• MIG és GPU sharing Egy nagy GPU felosztása több, egymástól izolált kisebb példányra (NVIDIA Multi-Instance GPU), vagy megosztása több munkafolyamat között. Olyan, mint egy nagy szervergép particionálása több VM-re: kisebb modelleknél így nem pazarolsz el egy teljes kártyát egyetlen alulhasznált szolgáltatásra. Mikor NE: nagy, egy kártyát teljesen kitöltő modellnél nincs mit particionálni — a MIG a kis modellek és a fejlesztői/teszt-terhelések eszköze.

Skálázás és ütemezés

• Model warmup A modell betöltése a GPU-ra és néhány próbahívás lefuttatása, mielőtt éles forgalmat kapna, hogy az első valódi kérés ne legyen indokolatlanul lassú. A klasszikus „bemelegítő" hívás, csak itt a betöltendő súlyok több tíz gigabájtnyiak lehetnek, és a warmup nem másodpercekben, hanem tíz-egynéhány másodpercben vagy percekben mérhető.
• Cold start Az az idő, amíg egy új GPU-példány felpörög és betölti a modellt — ez sokkal hosszabb, mint egy szokásos konténeré, mert nagy súlyfájlokat kell letölteni és a memóriába emelni. Ugyanaz a serverless cold start probléma, felnagyítva; ezért nem lehet nulláról másodpercek alatt skálázni. Egy több tíz gigabájtos modell letöltése és betöltése könnyen perces nagyságrend, ami éles forgalmi csúcsnál elfogadhatatlan — ezért tartasz meleg tartalékot.
• Autoscaling A GPU-példányok számának igazítása a terheléshez. A cold start és a GPU-k szűkössége és ára miatt ez trükkösebb, mint CPU-nál: gyakran metrikaként a várakozó kérések számát vagy a batch-telítettséget figyeled, és tartasz meleg tartalék kapacitást a csúcsokra. A klasszikus CPU-autoscaling metrikák (CPU%, RPS) itt félrevezetők — egy GPU 100% „kihasználtságnál" is lehet, hogy a KV-cache miatt nem tud több kérést felvenni.
• Request scheduling A beérkező kérések sorrendezése és kötegelése a szerveren belül: melyik kérés melyik batchbe kerüljön, hogyan előzzenek a rövidebbek. Ez az ütemező dönti el, hogyan oszlik el a GPU véges kapacitása a kérések között — és itt jelenik meg a méltányosság kérdése is, hogy egy hosszú generálás ne éheztesse ki a rövideket.
• Model-aware routing A kérések irányítása annak tudatában, melyik példányon melyik modell van már betöltve, hogy elkerüld a fölösleges modellcserét és cache-kihasználást nyerj. A hagyományos, állapotmentes HTTP load balancing itt nem elég jó, mert a „hova irányítsak" válasza a betöltött modelltől és a meleg cache-től függ. Egy round-robin load balancer szétszórná a kéréseket, feleslegesen kiürítve a prefix-cache-eket — a model-aware router viszont a már meleg példányra terel.
• Throughput kontra latency Az alapvető kompromisszum: a nagyobb batch több kérést szolgál ki időegység alatt (throughput), de az egyes kérés tovább vár (latency). Egy chat UI-nál a gyors első token (time-to-first-token) a fontos, egy éjszakai tömeges feldolgozásnál az összteljesítmény — a serving hangolásod ezen a tengelyen csúszkál. Ezért érdemes külön serving-profilt tartani az interaktív és a batch-terhelésnek: nem ugyanaz a beállítás optimális a kettőre.

# A vLLM OpenAI-kompatibilis szervert ad, így a gateway-d
# ugyanúgy tudja hívni, mint egy menedzselt providert:
#   python -m vllm.entrypoints.openai.api_server \
#       --model my-org/finetuned-summary-7b \
#       --tensor-parallel-size 2 \
#       --gpu-memory-utilization 0.90 \
#       --enable-prefix-caching

from openai import OpenAI

# Csak a base_url változik — az alkalmazáskód nem tud róla,
# hogy self-hosted modellt hív:
client = OpenAI(base_url="http://vllm-internal:8000/v1", api_key="local")
resp = client.chat.completions.create(
    model="my-org/finetuned-summary-7b",
    messages=[{"role": "user", "content": ticket_text}],
)

Mit tanulj belőle: a jól megtervezett platformban a self-hosted és a menedzselt modell ugyanazon a gateway-interfészen keresztül érhető el (OpenAI-kompatibilis API), így a routing, a költségmérés és a policy egységes marad — az alkalmazáskódnak nem kell tudnia, hol fut valójában a modell.

Összefoglalás

Az AI Platform nem új diszciplína, hanem a platform engineering ráterjesztése egy nemdeterminisztikus, GPU-igényes világra. A registry-k (model, prompt, eval, dataset) és a lineage adják a megismételhetőséget; a model gateway és a multi-provider routing az egységes, mérhető, kontrollálható belépési pontot; a CI/CD eval gate pedig azt a kaput, amelyen minden prompt- és modellváltozásnak át kell jutnia — ez köti össze a 11. fejezet evaljait a valódi üzemeltetéssel. Ha megjegyzel egyetlen sorrendet, az legyen ez: előbb gateway (hogy egyáltalán mérhess és kontrollálhass), aztán registry-k és lineage (hogy reprodukálható legyen), végül eval gate (hogy ne csússzon ki regresszió).

A governance rétegben minden ismerős — secrets, identity, policy-as-code, tenant isolation, data residency, auditability —, csak a tét nagyobb, mert egy kiszivárgott kulcs vagy egy visszakövethetetlen válasz azonnal pénzbe vagy megfelelőségi kockázatba kerül. A self-hosted inference-t elég fogalmi szinten értened: tudd, mit jelent a continuous batching, a paged attention, a GPU memory sizing és a throughput–latency kompromisszum, és főleg tudd megítélni, mikor éri meg a menedzselt API kényelmét irányításra cserélni — a válasz szinte mindig a forgalom mérete, stabilitása és az adatvédelmi kényszer függvénye. Ha ezt a réteget felépíted, a csapatod nem prototípusokat futtat, hanem valódi, elszámoltatható AI-terméket üzemeltet.