# Vállalati AI a saját szerverteremben - őszinte útikalauz 2026-ra

*B sorozat - Az amnézia-probléma, 3. cikk*

A történet rendszerint nem a technológiával kezdődik, hanem egy audittal.

Képzelje el a helyzetet: egy magyar középvállalat informatikai igazgatója ül az irodájában, a monitorán két dokumentum. Az egyik az SZTFH NIS2 megfelelőségi jelentéstervezete. A másik egy belső kimutatás arról, hogy a cég havi szinten hány ezer eurót költ különféle felhőalapú AI szolgáltatások API-hívásaira - egy összeg, ami hat hónapja még nem is létezett a költségvetésben, mert az egész „kísérleti projektként" indult.

A NIS2-auditor konkrét kérdéseket tesz fel. Hol futnak az AI modellek? Ki férhet hozzá a promptokban elküldött adatokhoz? Melyik joghatóság alá tartozik az adatfeldolgozás? A GDPR-megfelelőségi nyilatkozat kiterjed-e azokra a szövegekre, amelyeket a dolgozók nap mint nap beküldenek egy tengerentúli API-végpontra?

Az informatikai igazgató tudja a választ ezekre a kérdésekre - és pontosan ez a baj. A válasz mindegyikre az, hogy „nem egészen tudjuk" vagy „a szolgáltató szerint igen, de auditálni nem tudjuk."

És ekkor merül fel az a kérdés, ami 2026 közepén egyre több magyar és európai szervezetben hangzik el: „Mennyibe kerülne, ha ezt az egészet a saját gépeinkre húznánk?"

A válasz meglepőbb, mint gondolná. Nem azért, mert olcsó lenne - nem az. Hanem azért, mert a számítás alapjaiban változott meg. A hardver erősebb lett. A modellek kisebbek. Az eszközök felnőttek. És a szabályozási környezet egyre nehezebben viseli el, hogy érzékeny munkafolyamatok „valaki más számítógépén" fussanak.

Ez a cikk az őszinte térkép. Nem gyártói marketingszöveg. Nem hobbista álmodozás. Számokkal alátámasztott, kalibrált áttekintés arról, hogy 2026 közepén mit jelent valójában a saját infrastruktúrán futó mesterséges intelligencia - mi működik, mi fáj, és hol vannak az igazi megtérülési pontok.

## Miért változott meg a számítás

Másfél éve még egy 70 milliárd paraméteres modell helyi hardveren való futtatása mutatványszám volt. Harmincezer dollárnyi GPU kellett hozzá, egy kisebb szerverteremnek megfelelő hűtés, és olyan rendszermérnöki szaktudás, amelynek birtokosai általában nem válaszolnak fejvadász-megkeresésekre. A modellek sűrűek voltak, a kvantálás veszteséges, az eszközök pedig azt feltételezték, hogy Ön rendelkezik doktori fokozattal és határozott véleménnyel a CUDA kernelfúzióról.

Három dolog változott meg.

**A modellek architekturálisan okosabbak lettek.** A Mixture-of-Experts (MoE) architektúrák elterjedése azt jelenti, hogy egy „70B-osztályú" modell 2026-ban nem feltétlenül aktivál 70 milliárd paramétert minden egyes lépésben. A Llama 4 Scout összesen 109 milliárd paraméterrel rendelkezik, de előrecsatolásonként csupán 17 milliárdat használ. A Qwen3 35B MoE változata azt a teljesítményt nyújtja, amihez tavaly még 70 milliárd paraméteres, sűrű modellre volt szükség. A teljesítményszint maradt - a hardverigény csökkent.

**A kvantálás megérett.** A Q4_K_M kvantálás lett a gyakorlati alapértelmezés: egy 70 milliárd paraméteres sűrű modellt nagyjából 140 GB-ról 35-45 GB-ra tömörít, miközben a legtöbb üzleti feladatnál a minőségromlás minimális. A Google QAT (Quantization-Aware Training) megközelítése a Gemma 3-ban továbblépett: az int4-es modellek eleve kvantálásra tervezve lettek betanítva, nem pedig utólag tömörítve. A különbség mérhető.

**A hardver elért egy inflexiós pontot.** A 2025-2026-os generáció fogyasztói és professzionális processzorai - egységes memória-architektúráikkal és megnövekedett VRAM-kapacitásaikkal - alapjaiban írták át a gazdaságossági képletet. Egy kvantált 70 milliárd paraméteres modell elfér egy olyan gépben, ami az íróasztalon áll, és kevesebb áramot fogyaszt, mint egy hősugárzó.

De a hardver önmagában nem magyarázza a váltást. A szabályozási környezet a maga módján szintén lökést ad.

## A megfelelőség gravitációs mezeje

Az EU AI Act átláthatósági kötelezettségei 2026 augusztusában lépnek hatályba. Az Omnibus egyszerűsítés a magas kockázatú, önálló rendszerek határidejét nagyjából 2027 decemberéig tolta ki, de az irány világos: aki az Európai Unióban AI-t üzemeltet, annak tudnia kell, hogy a modelljei mit csinálnak, milyen adatokkal, és képesnek kell lennie ezt bizonyítani.

Van valami, amit a megfelelőségi szakma nem mond ki elég egyértelműen: a saját infrastruktúra önmagában nem teszi Önt megfelelővé. Nem egy kipipálandó sor a listán. De kiiktat egy teljes problémakategóriát.

Amikor a modell az Ön által felügyelt hardveren fut, az Ön által választott joghatóságban, és az adatok soha nem hagyják el az Ön hálózatának határait - akkor Ön egyszerre szüntette meg a CLOUD Act kérdését, a határokon átívelő adattovábbítás kérdését, és a „mit csinál a szolgáltatóm a promptjaimmal?" kérdését. Ezzel nem oldotta meg a teljes irányítási feladatot. De lehetővé tette az irányítást - olyan módon, ami nehezebben megvalósítható, amikor az inferencia-hívások három országon és egy negyedévente változó felhasználási feltételeken keresztül közlekednek.

### Az SZTFH és a NIS2 - a magyar kontextus

Magyar szervezetek számára a NIS2 nem elvont brüsszeli irányelv, hanem az SZTFH (Szabályozott Tevékenységek Felügyeleti Hatósága) által lefolytatott, nagyon is konkrét audit. A NIS2 hatálya alá tartozó szervezeteknek - és ez a kör a korábbi NIS-irányelvhez képest jelentősen bővült - értékelniük és dokumentálniuk kell az ellátási láncuk minden elemét, beleértve a felhőalapú AI-szolgáltatókat is.

Minden egyes API-függőség, amit az AI-rendszeréhez hozzáad, egy újabb láncszem, amelyet a NIS2 keretében nyomon kell követnie, kockázatát fel kell mérnie, és az auditnak be kell mutatnia. Ha az inferencia helyben fut, a lánc rövidebb. Nem szűnik meg teljesen - Ön továbbra is függ a modellsúlyoktól, a keretrendszerektől, a szilíciumgyártóktól -, de lényegesen rövidebb és áttekinthetőbb.

Az európai szuverén AI-törekvések ezt a gravitációt tükrözik. A GAIA-X és a nemzeti AI-kezdeményezések az európai számítási szuverenitás felé tolják a szervezeteket. Azok a cégek, amelyek ma 15-30%-os felárat fizetnek szuverén felhőszolgáltatásokért, már végzik a számítást: nem lenne-e érdemesebb magát a hardvert megvenni.

Mindez nem jelenti azt, hogy Önnek feltétlenül helyi infrastruktúrára kell váltania. Azt jelenti, hogy a döntés többé nem pusztán technikai - hanem szabályozási és stratégiai is.

## A hardverkínálat - ami valóban elfér az íróasztalon

Nézzük a konkrétumokat. Így fest 2026 közepén a hardverpiac a helyi inferenciához, az Ön várható költési szintjei szerint rendezve.

### A 2000-4000 dolláros kategória - „Meglepően használható"

**AMD Strix Halo (128 GB egységes memória)** - Ez az idei év legérdekesebb fejleménye a házon belüli AI-infrastruktúra terén. Egyetlen lapkán integrált rendszer 128 GB egységes LPDDR5X memóriával, ami azt jelenti, hogy a CPU és a GPU ugyanazt a memóriakészletet használja. Egy 70 milliárd paraméteres Q4 modell teljes egészében elfér benne. Inferenciasebesség: nagyjából 5-15 token másodpercenként, a kontextushossztól és a kötegmérettől függően. Nem gyors. De működőképes, és a token-per-dollár arány a kategória legjava. Teljes rendszer piaci ára: nagyjából 2000-3000 dollár.

**NVIDIA RTX 5090 konfiguráció** - Az 5090-es 32 GB GDDR7 memóriát kínál hatalmas sávszélességgel. Egy 70 milliárd paraméteres Q4 modell 35-40 GB-os méretével technikailag túllépi a VRAM-ot, tehát részleges rendszermemóriára való kihelyezéssel kell számolnia - ami működik, de sebességet veszít rajta. A VRAM-ba teljesen beférő modellek (32B és alatta) tisztán GPU-alapú inferenciája: 30-55 token másodpercenként, ami kifejezetten gyors. Maga a videókártya 2000-2500 dollár. Mire köré épít egy rendszert: 3000-4000 dollár.

Az őszinte értékelés: ha a terhelés elsősorban 32 milliárd paraméteres osztályú modelleket igényel (ami a modern MoE architektúrákkal már sok mindent lefed), az 5090-es konfiguráció gyorsabb. Ha valódi 70 milliárd paraméteres sűrű modelleket kell kompromisszumok nélkül futtatnia, a Strix Halo egységes memóriája az egyszerűség terén nyer.

### A 4000-8000 dolláros kategória - „Az optimális sáv"

**Apple Mac Studio M4 Max (128 GB)** - A Mac Studio továbbra is az „egyszerűen működik" választás a helyi inferenciához. 128 GB egységes memória, 70 milliárd paraméteres Q4 modellek 8-25 token/másodperc sebességgel, szinte zajmentes működés, és olyan energiafogyasztás, amihez nem kell villanyszerelőt hívni. Ára: nagyjából 3500-4200 dollár konfigurációtól függően. Az ökoszisztéma érett - a `llama.cpp` és az `MLX` egyaránt kiválóan fut Apple Silicon-on. A korlát az, hogy Ön az Apple frissítési ciklusához és árszabásához van kötve.

**NVIDIA DGX Spark** - Az NVIDIA belépője az „asztali AI-berendezés" kategóriába. Kifejezetten inferencia-munkaterhelésekre tervezett készülék. Ebbe az ársávba esik, és úgy van kialakítva, hogy meglévő informatikai infrastruktúrába zökkenőmentesebben illeszkedjen, mint egy fogyasztói GPU-s összeállítás. Érdemes megvizsgálni, ha csapatnak üzemeltet, nem személyes használatra.

**Dupla RTX 5090 konfiguráció** - Két 5090-es összesen 64 GB VRAM-ot ad. Egy 70 milliárd paraméteres Q4 modell elfér a két kártyán, és marad hely a KV cache-nek is. Az NVLink összeköttetés a kártyák között gyorsan tartja a GPU-közi kommunikációt. Inferenciasebesség a 70 milliárd paraméteres modelleken: 40-60+ token másodpercenként. Teljes rendszerköltség: 6000-8000 dollár. Bonyolultabb beüzemelni, mint egy Mac Studiót - a tenzor-párhuzamosítás konfigurálása nem „bedugom és megy" -, de lényegesen gyorsabb.

### A 8000-20 000 dolláros kategória - „Kiscsoportos produkció"

**Használt NVIDIA H100 szerverek** - Az adatközponti GPU-k másodlagos piaca megérett. Használt H100-asok 15 000-30 000 dollárért kaphatók komplett szerverre, a csúcson jellemző 30 000-40 000+ dollárról lefelé. A H100 80 GB HBM3 memóriája és dedikált tenzormagjai teljesítményben referenciát jelentenek. Ha a munkaterhelés indokolja a költséget, az inferencia-átviteli sebességben semmi más nem éri utol.

**AMD MI300X** - Gyakran olcsóbb, mint a H100 a másodlagos piacon, miközben 192 GB HBM3 memóriával rendelkezik - ez elég ahhoz, hogy egy 70 milliárd paraméteres modellt magasabb kvantálási szinten futtasson, vagy egyszerre több modellt tartson a memóriában. A szoftveres ökoszisztéma (ROCm) sokat javult, de továbbra is több szaktudást igényel, mint a CUDA. Jó választás, ha Ön rendelkezik - vagy hajlandó kifejleszteni - AMD GPU-kompetenciát.

**RTX PRO 6000** - Az NVIDIA munkaállomás-kategóriájú kártyája. 96 GB GDDR7. Egy 70 milliárd paraméteres modell kényelmesen elfér egyetlen kártyán. Árban a fogyasztói 5090 és az adatközponti H100 között helyezkedik el. A professzionális illesztőprogramok és az ECC memória alkalmassabbá teszik folyamatos termelési munkaterhelésekre, mint a fogyasztói kártyákat.

### VRAM - gyors áttekintő táblázat

Tervezéshez íme, hogy a modellek ténylegesen mennyi memóriát igényelnek Q4_K_M kvantálásnál:

| Modellosztály | Szükséges VRAM | Példamodellek |
|---|---|---|
| 7-9B | 4,5-6,5 GB | Qwen3-8B, Gemma 3 9B, Llama 4 Scout |
| 27-32B | 16-22 GB | Qwen3-32B, Gemma 3 27B |
| 70B sűrű | 40-44 GB | Llama 3.3 70B, Qwen3-72B |
| MoE (35B aktív) | 20-28 GB | Qwen3-35B MoE (hatékonyan „70B-osztály") |

A lényeges mintázat: a MoE modellek 70 milliárd paraméteres osztályú teljesítményt nyújtanak 32 milliárd paraméteres osztályú VRAM-igénnyel. Ez az az architekturális váltás, amitől a 2000-4000 dolláros kategória komoly munkára is alkalmassá válik.

## A modellek közötti választás

Az önálló infrastruktúrára szánt modellválasztás más, mint API-szolgáltató választása. Ön hardverméretet, üzemeltetési eszköztárat és licencfeltételeket is vállal egyben. Az alábbiakban azt a döntési keretrendszert mutatjuk be, amelyet mi is használunk.

**Qwen3 / Qwen3.5 (Apache 2.0 licenc)** - A legtöbb házon belüli bevezetéshez ez az alapértelmezett javaslatunk. A modellcsalád 8 milliárd paramétertől 397 milliárdig terjed, sűrű és MoE változatokkal egyaránt. Az Apache 2.0 licenc semmilyen felhasználási korlátozást nem tartalmaz. A 32B sűrű és a 35B MoE változatok az optimális sávban vannak: 70 milliárd paraméteres osztályú teljesítmény 16-22 GB VRAM-mal. A többnyelvű teljesítmény erős, ami európai bevezetéseknél különösen fontos.

**Llama 4 Scout (Meta, egyedi licenc)** - A kiemelkedő tulajdonsága az 1M+ tokenes kontextusablak, ami akkor releváns, ha a felhasználási eset teljes kódbázisok vagy hosszú dokumentumok egyszeri feldolgozását igényli. A 109B/17B MoE architektúra (előrecsatolásonként 17 milliárd aktív paraméter) meglepően hatékonyan futtatható. A licenc szigorúbb az Apache 2.0-nál - kereskedelmi termék építése előtt alaposan olvassa végig.

**Gemma 3 (Google, megengedő licenc)** - A legjobb választás fogyasztói hardverre. A Google QAT megközelítésének köszönhetően az int4-es kvantált változatok eleve kvantálásra tervezve lettek, és a minőség jobban tartja magát, mint más modellek utólagos kvantálásakor. A 27 milliárd paraméteres változat kiválóan teljesít egyetlen RTX 5090-esen.

**DeepSeek V3.2 / R1 (MIT licenc)** - Ha a munkaterhelés gondolkodás-intenzív - kódgenerálás, matematikai bizonyítás, komplex elemzés -, a DeepSeek gondolkodó modelljei az élmezőnybe tartoznak. Az R1 modell a vezető API-modellek szintjén teljesít gondolkodási benchmarkokon. MIT licenc. A kompromisszum a méret: ezek nagy modellek, amelyek komoly hardverből profitálnak.

**Mistral Small 4 / Large 2** - Erős európai háttér (francia cég, EU-joghatóság). A Mistral Small 4 a méretéhez képest hatékony és képes. Érdemes megfontolni, ha az európai eredet és joghatóság fontos az Ön megfelelőségi helyzetéhez.

### Egy megjegyzés a „70B" mint teljesítményosztály fogalmáról

Ebben a cikkben a „70B" teljesítményosztályt jelöl, nem szó szerinti paraméterszámot. 2024-ben a 70 milliárd paraméteres osztályú kimeneti minőséghez 70 milliárd paraméteres sűrű modellre volt szükség. 2026-ban ezt elérheti egy jól betanított 32 milliárd paraméteres sűrű modellel vagy egy 35 milliárd paraméteres MoE modellel. Az elnevezés azért ragadt meg, mert az emberek értik, mit jelent a „70B-osztály" a kimeneti minőség szempontjából: ez az a szint, ahol a modellek megbízhatóan kezelik a komplex gondolkodást, az árnyalt szövegalkotást és a többlépéses feladatokat.

Amikor tehát azt mondjuk, hogy „vállalati szintű modell a saját szerverteremben," olyan modellekre gondolunk, amelyek 70 milliárd paraméteres osztályú kimeneti minőséget nyújtanak. A mai hardveren ez fizikailag gyakran könnyebb, mint amennyire a szám alapján gondolná.

## A pénz - mikor éri meg valóban a saját infrastruktúra

Ez az a pont, ahol a legtöbb útmutató tisztességtelen lesz: vagy figyelmen kívül hagyja a helyi üzemeltetés valós költségeit (munkaerő, villany, alternatív költség), vagy elavult API-árazást használ, amitől a felhő drágábbnak tűnik a valóságosnál. Használjunk aktuális számokat.

### API-árazás (2026 közepe, vegyes)

| Szolgáltató | Bemenet (M tokenként) | Kimenet (M tokenként) | Vegyes becslés |
|---|---|---|---|
| GPT-4o | ~2,50 $ | ~10-15 $ | ~4-6 $ |
| Claude Sonnet 4 | ~3 $ | ~15 $ | ~5-7 $ |
| Gemini Pro | ~0,25-2 $ | ~1,50-12 $ | ~2-5 $ |

A vegyes árak tipikus bemeneti-kimeneti token-arányt feltételeznek. Az Ön aránya eltérhet: kódgenerálásnál a kimenet dominál, RAG-rendszereknél a bemenet.

### Helyi üzemeltetés havi teljes költsége

Egy realisztikus havi költségszámítás Mac Studio M4 Max alapú üzemeltetésre:

| Költségelem | Havi költség |
|---|---|
| Hardver amortizáció (3 éves) | ~115 $ |
| Villamosenergia (0-24, ~200W átlag) | ~30-50 $ |
| Internet/hálózat | ~20 $ |
| Karbantartás/munkaerő (részmunkaidős) | ~200-400 $ |
| Szoftver/eszközök | ~0-50 $ |
| **Összesen** | **~365-635 $** |

*Megjegyzés magyar kontextushoz: a magyar áramárak (2026 közepén a vállalati szegmensben kb. 60-80 Ft/kWh, azaz nagyjából 0,15-0,20 EUR/kWh) az európai átlag körül mozognak. Egy 200W átlagfogyasztású rendszer havi villanyköltsége Magyarországon nagyjából 9000-12 000 Ft, ami összhangban van a fenti 30-50 dolláros tétellel.*

Dupla 5090-es konfiguráció esetén a hardveramortizáció ~200 $/hó, a villamosenergia ~80-120 $. Használt H100-nál a hardveramortizáció ~400-800 $/hó, de arányosan több átviteli sebességet kap.

A munkaerő sor az, amit az emberek rendszeresen alábecsülnek. Valakinek figyelnie kell a rendszert, frissítenie a modelleket, kezelnie a hajnali 2-kor bekövetkező memóriatúlcsordulást, és naprakészen tartania az inferencia-szoftvert. Ha Ön már üzemeltet infrastruktúrát, és ez növekményes munka, a költség alacsonyabb. Ha ez a csapat első termelési rendszere, tervezzen nagyobb munkaerő-keretet.

### A megtérülési pont

Nagyjából **havi 80-200 millió token** feldolgozásánál konvergálnak a helyi és az API-költségek. Ez alatt az API olcsóbb. E fölött a saját infrastruktúra nyer - és a különbség gyorsan nő.

- **Havi 10M token**: Az API egyértelműen nyer. API-hívásokra 40-70 dollárt költene, szemben a helyi üzemeltetés 400+ dolláros teljes költségével. Ekkora forgalomra ne építsen infrastruktúrát.
- **Havi 100M token**: A megtérülési zóna. Az API-költségek elérik a havi 400-700 dollárt. A helyi üzemeltetés költsége hasonló, de mellé kapja az adatszuverenitást és a kiszámítható árképzést.
- **Havi 1 milliárd token**: A saját infrastruktúra egyértelműen nyer. Az API-költség eléri a havi 4000-7000 dollárt. A helyi üzemeltetés teljes költsége a 600-1300 dolláros sávban marad. Ez 3-10-szeres költségelőny.
- **Havi 10 milliárd token**: Tegnap kellett volna saját infrastruktúrát építenie.

A mintázat: a helyi üzemeltetésnek magas az állandó költsége és közel nulla a változó költsége. Az API-nak alacsony az állandó költsége, de lineárisan nő a változó költség. A két egyenes valahol a százmilliós token-tartományban metszi egymást. Mielőtt elköteleződne, tudja meg, hol áll az Ön felhasználása.

## Amit tapasztaltunk - a termelési rés

Itt válik el egymástól a blogbejegyzések és YouTube-oktatóanyagok világa a valóságtól. Egy modell futásra bírása a könnyű rész. Egy modell megbízható kiszolgálásra bírása egy csapat számára - ott kezdődik az igazi mérnöki munka.

### Az Ollama-csapda

Az Ollama brilliáns eszköz. A legjobb fejlesztői élményt nyújtja az összes helyi inferencia-eszköz közül - az `ollama run qwen3:32b` paranccsal egy percen belül szöveget generál. Személyes használatra, prototipizálásra és fejlesztésre ez a megfelelő kiindulópont.

Termelési kiszolgálórendszernek nem alkalmas.

Tapasztalataink szerint az Ollama nagyjából 5 egyidejű felhasználóig kecsesen degradálódik, azután viszont kiszámíthatatlanul. 10 egyidejű kérésnél a válaszidő-kiugrások megjósolhatatlanná válnak. Ez nem hiba - architekturális döntés. Az Ollama az egyszerűségre lett tervezve, nem az egyidejűségre. Nem implementál PagedAttention-t, nem végez kifinomult kéréskötegezést. A modelleket monolitikus blokkokként tölti a memóriába.

Ez nem kritika. Ez besorolás. Az Ollama úgy viszonyul a vLLM-hez, mint az SQLite a PostgreSQL-hez - tökéletes a saját feladatára, alkalmatlan egy másikra.

### KV cache és a memóriatúlcsordulás meglepetése

A modellsúlyok csak a memóriatörténet egyik fele. Inferencia közben a KV (key-value) cache a kontextushosszal és a kötegmérettel együtt nő. Egy 70 milliárd paraméteres modell, ami betöltéskor 42 GB VRAM-ot foglal, egy hosszú beszélgetés során 48 GB-nál memóriatúlcsordulást okozhat, mert a KV cache túlnőtt a tervezetten.

Ez a leggyakoribb hibajelenség, amellyel házon belüli bevezetéseknél találkoztunk. A modell betöltődik, a benchmarkok szépek, valaki beküld egy 30 000 tokenes dokumentumot összefoglalásra, és a folyamat összeomlik.

A megoldás vagy a kontextushossz korlátozása (ami a hasznosságot korlátozza), vagy a PagedAttention használata (ami a KV cache-t a virtuális memóriához hasonlóan kezeli), vagy egyszerűen több VRAM-tartalék a modell alapigényéhez képest. Tervezzen 20-30%-os tartalékot a modell alap-VRAM-igénye fölé.

### Hidegindítások

Egy 70 milliárd paraméteres modell lemezről GPU-memóriába töltése 30-90 másodpercet vesz igénybe a háttértár sebességétől függően. Ha az inferenciakiszolgáló tétlen modelleknél felszabadítja a memóriát (az Ollama alapértelmezés szerint ezt teszi), az első kérés tétlenség után többmásodperces késleltetéssel indul, amíg a modell újratöltődik.

Személyes használatra ez elfogadható. Csapatszolgáltatásként ez egy hibajegy. Termelési munkaterheléseknél tartsa a modelleket rögzítve a memóriában.

### Megfigyelhetőségi hiányosságok

A felhő-API-k műszerfalakat, felhasználás-követést és költségattribúciót adnak alapból. A helyi üzemeltetés semmit nem ad, hacsak Ön nem építi meg. Minimálisan az alábbiakra lesz szüksége:

- Kérés-válaszidő követés (P50, P95, P99)
- Token-átvitel monitorozás
- VRAM-kihasználtság és KV cache nyomás
- Felhasználónkénti vagy alkalmazásonkénti felhasználás-attribúció
- Hibaarány és memóriatúlcsordulás-követés

A Prometheus a Grafana-val együtt mindezt nagyrészt lefedi. A vLLM natívan kínál Prometheus-metrikákat. Tervezzen időt a beüzemelésre - csapatszintű bevezetésnél ez nem opcionális.

## Ami működött - gyakorlati kiindulópont

Elég volt a problémákból. Az alábbiakban egy konkrét útvonal az „érdeklődöm" állapottól a „fut" állapotig.

### 1. lépés: Kezdje az Ollama-val (komolyan)

A fenti fenntartások ellenére az Ollama a helyes első lépés. Lehetővé teszi, hogy érvényesítse: a hardvere működik, a modellválasztása megalapozott, és a felhasználási esete valóban profitál a helyi inferenciából - mindezt azelőtt, hogy termelési eszközökbe fektetne.

```bash
# Ollama telepítése
curl -fsSL https://ollama.com/install.sh | sh

# 32B modell letöltése (70B-osztályú teljesítmény, a legtöbb hardveren elfér)
ollama pull qwen3:32b

# Interaktív munkamenet indítása
ollama run qwen3:32b

# API-kiszolgálás (OpenAI API-kompatibilis formátum)
ollama serve &
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:32b",
    "messages": [{"role": "user", "content": "Foglalja össze az EU AI Act átláthatósági követelményeit három pontban."}]
  }'
```

### 2. lépés: Mérje meg a hardverét

Mielőtt elköteleződne egy modell vagy hardverkonfiguráció mellett, mérje meg a tényleges teljesítményt:

```bash
# Gyors benchmark Ollama-val
# Futtasson egy rögzített promptot, és figyelje a tokens/second értéket
ollama run qwen3:32b --verbose <<< "Fejtse ki részletesen, hogyan működnek a transformer-architektúra figyelemmechanizmusai, beleértve a többfejű figyelmet, a skálázott belső szorzat figyelmet és a pozíciókódolás szerepét. Legyen alapos."

# A --verbose kapcsoló mutatja:
# - prompt eval rate (token/s a bemenet feldolgozásánál)
# - eval rate (token/s a generálásnál)
# - total duration
```

A lényeges számok:
- **Prompt eval rate**: milyen gyorsan dolgozza fel a modell a bemenetet. RAG és hosszú kontextusú munkaterheléseknél számít.
- **Eval rate (generálás)**: milyen gyorsan állít elő kimenetet. Ezt érzik a felhasználók.
- **Time to first token**: a generálás megkezdéséig eltelt idő. Interaktív használatnál lényeges.

Ha az eval rate 5 t/s alatt van, a modell túl nagy a hardveréhez interaktív használatra. Kötegelt feldolgozásra, ahol a válaszidő nem szempont, még működhet.

### 3. lépés: Lépjen termelési kiszolgálásra

Amikor kinövi az Ollama-t - és ha csapatot szolgál ki, ki fogja nőni -, a két komoly lehetőség a **vLLM** és az **SGLang**.

A **vLLM** a bevált választás. A PagedAttention hatékonyan kezeli a KV cache-t, a folyamatos kötegezés az egyidejű kéréseket, és az OpenAI-kompatibilis API-ja egy az egyben helyettesíti a felhővégpontokat. 100+ egyidejű felhasználót szolgál ki ott, ahol az Ollama 10-nél összeomlik.

Az **SGLang** az újabb kihívó. A benchmarkok 20-29%-kal jobb átvitelt mutatnak megosztott kontextusú munkaterheléseknél - ami pontosan az, amit a RAG-rendszerek produkálnak (sok kérés, ugyanaz a visszakeresett kontextus). Ha az elsődleges felhasználási eset RAG, az SGLang-ot érdemes kiértékelni.

Mindkettő támogatja a többkártyás tenzor-párhuzamosítást, a kvantált modellek betöltését és a Prometheus-metrikákat a megfigyelhetőség érdekében. Egyik sem olyan egyszerűen telepíthető, mint az Ollama. Ez a kompromisszum.

### 4. lépés: A modellválasztás döntési keretrendszere

Modell előírása helyett az alábbiakban a döntési fát mutatjuk be:

1. **Mekkora a VRAM-kerete?**
   - 8 GB alatt: Qwen3-8B vagy Gemma 3 9B (képes, de komplex feladatokhoz korlátozott)
   - 16-24 GB: Qwen3-32B vagy Gemma 3 27B (az optimális sáv egyetlen GPU-val)
   - 40+ GB: Teljes 70B sűrű modellek vagy nagy MoE változatok
   - 128+ GB egységes memória: bármi, amit választ

2. **Mi az elsődleges feladat?**
   - Általános tudásmunka: Qwen3 család (legjobb összteljesítmény)
   - Kódgenerálás/gondolkodás: DeepSeek R1 vagy V3.2
   - Hosszú dokumentumok feldolgozása: Llama 4 Scout (1M+ kontextus)
   - Fogyasztói hardver, minőségérzékeny: Gemma 3 QAT-tal

3. **Mik a licenckövetelmények?**
   - Maximális szabadság: Apache 2.0 (Qwen3) vagy MIT (DeepSeek)
   - Megengedő, korlátozásokkal: Gemma, Llama (olvassa el az apró betűst)
   - Az európai eredet számít: Mistral

4. **Hány egyidejű felhasználó?**
   - 1-3: Az Ollama megfelel
   - 5-20: Fontolja meg a vLLM-et vagy az SGLang-ot
   - 20+: vLLM vagy SGLang, kötelezően

## A mélyebb mintázat

Lépjünk hátra egy pillanatra a specifikációktól és az árazástól.

Aminek most szemtanúi vagyunk, az nem más, mint hogy az AI-ipar megismétli a számítástechnikai infrastruktúra elmúlt harminc évének történetét. A nagygépeket felváltották az elosztott rendszerek. Az elosztott rendszerek a felhőbe költöztek. A felhő most gravitációs ellenerőt fejleszt - nem a nagygépek felé visszafelé, hanem egy hibrid modell felé, ahol a számítás helye mérnöki döntés, nem alapértelmezett feltételezés.

A mesterséges intelligencia végigment a nagygép-fázison: néhány szolgáltatóba koncentrálva, terminálon (API-n) keresztül elérve. Az „elosztott" fázis most zajlik - nem azért, mert a technológia megköveteli, hanem azért, mert a gazdaságosság, a szabályozás és a szervezeti igények megkövetelik.

Azok a szervezetek fognak jól navigálni, amelyek a modell-üzemeltetést ugyanolyan mérnöki szigorral kezelik, mint az adatbázis-üzemeltetést. Ön sem tesz minden adatbázist a felhőbe. Nem is futtat minden adatbázist helyi szervereken. Kiértékeli a munkaterhelést, az adatok érzékenységét, a hozzáférési mintákat, a költségprofilt, és kalibrált döntést hoz.

Az AI-inferencia infrastruktúrává válik. Minél hamarabb kezelik így - kapacitástervezéssel, monitorozással, életciklus-kezeléssel és őszinte teljesköltség-elemzéssel -, annál kevesebb meglepetéssel szembesülnek.

## Nyitott kérdések

Számos valóban bizonytalan kimenetelű trend fogja átformálni a házon belüli AI-üzemeltetést a következő 12-18 hónapban. Ezek nem jóslatok - ezeket figyeljük.

**Megváltoztatja-e a MoE konszolidáció a hardver-matematikát?** Ha a MoE architektúrák a jelenlegi ütemben fejlődnek tovább, a „70B sűrű" fogalma a legtöbb munkaterhelésnél irrelevánssá válhat. Egy 2027-es MoE modell 15 milliárd aktív paraméterrel elérheti a mai 70 milliárd paraméteres sűrű modellek minőségét. Ez a 2000 dolláros kategóriát tenné alapértelmezetté, nem költségvetési opcióvá.

**Az egységes memória nyer?** Az AMD Strix Halo és az Apple M-sorozata egyaránt az egységes memóriára tesz - egyetlen, CPU és GPU által közösen használt készlet. Az NVIDIA hagyományos megközelítése elkülöníti a VRAM-ot a rendszermemóriától. Olyan inferencia-munkaterheléseknél, ahol a modellméret meghaladja bármely egyedi GPU VRAM-ját, az egységes memória egyszerűbb. De ha a modellek gyorsabban zsugorodnak (MoE, jobb kvantálás), mint ahogy a memória nő, talán sosem lesz szükség 32 GB-nál több gyors VRAM-ra. A kérdés az, hogy a modellek gyorsabban zsugorodnak-e, mint amennyire a memória bővül.

**Hogyan fest a posztkvantum plusz AI Act kombinációja?** Az EU AI Act auditálhatósági követelményei metszik a kvantumrezisztens kriptográfia iránti növekvő igényt. Ha az AI-rendszere hosszú távú bizalmasságot igénylő adatokat dolgoz fel (egészségügyi feljegyzések, jogi dokumentumok, pénzügyi adatok), a helyi inferencia és a kvantumrezisztens titkosítás kombinációja olyan megfelelőségi pozíciót teremt, amelyet többbérlős felhőkörnyezetben valóban nehéz megismételni.

**Összeomlanak-e az inferencia-szolgáltatás árai?** Az API-szolgáltatók közötti verseny már most drámaian lenyomta az árakat. Ha a Gemini Pro agresszív árazása árversenyt jelez, a megtérülési pont 100 millió tokenről 1 milliárd+ tokenre tolódhat, és a saját infrastruktúra közepesen nagy forgalomnál gazdaságilag kevésbé indokolt lesz. Nem erre fogadunk - a marzsok már most vékonyak -, de érdemes figyelni.

## Miért számít mindez az AI-memória szempontjából

Ez a cikk az Amnézia-probléma sorozat egyik csomópontja. A korábbi cikkek - [Az újrafelfedezés ára](/blog/the-rediscovery-tax/) és [Miért nem memória a RAG](/blog/why-rag-isnt-memory/) - megállapították, hogy az AI-rendszereknek memóriaproblémájuk van: felejtenek, összekeverik a visszakeresést az emlékezéssel, és ennek az amnéziának a költsége valós és mérhető.

A következő cikkek - [A bizalmi lánc problémája](/blog/the-trust-chain-problem/) és [Árnyékemlékek](/blog/shadow-memories/) - amellett fognak érvelni, hogy az AI-memória megoldásához irányítás, auditálhatóság és bizalmi infrastruktúra szükséges, amelyet a legtöbb szervezet még nem épített ki.

Ez a cikk a híd. Mert a lényeg a következő: nem irányíthatja azt, amit nem Ön felügyel.

Amikor az AI-inferencia API-n keresztül történik, a modell „memóriája" - a kontextusa, a beszélgetéselőzménye, a RAG-ból visszakeresett tudása - olyan infrastruktúrán halad keresztül, amelyet nem Ön birtokol, olyan feltételek mellett, amelyeket nem Ön tárgyalt ki, olyan joghatóságokban, amelyeket Ön talán ki sem értékelt. Építhet irányítási szabályzatokat, de a hálózatának határain túl nem érvényesítheti azokat.

A saját infrastruktúrán futó AI az, ahol a memóriaprobléma megoldhatóvá válik. Nem automatikusan megoldottá - az a tudásinfrastruktúra feladata, ami felé ez a sorozat építkezik. De megoldhatóvá. Auditálhat minden promptot. Felügyelhet minden visszakeresést. Biztosíthatja, hogy az AI „memóriája" ugyanazoknak a megőrzési, besorolási és hozzáférés-vezérlési szabályzatoknak felel meg, mint a szervezeti tudás minden más eleme.

Ez nem technikai érv a saját infrastruktúra mellett. Ez architekturális érv. És ezért a „futtassuk-e a saját modelleinket?" kérdés valójában a következő kérdés: „akarjuk-e mi magunk irányítani, hogy az AI-rendszerünk hogyan viszonyul a szervezeti tudáshoz?"

Egyre több szervezet számára 2026-ban a válasz: igen.

---

*Ez az Amnézia-probléma sorozat B.3 cikke. Következik: [B.4 - A bizalmi lánc problémája](/blog/the-trust-chain-problem/) - mi történik, amikor az AI-memóriának nem csak tárolhatónak, hanem megbízhatónak kell lennie.*

---

*A saját feltételei szerint futtatott inferencia mérnöki döntés - és olyan döntés, amely profitál a konkrét hibajelenségekkel, hardverkompromisszumokkal és üzemeltetési mintázatokkal szerzett tapasztalatból. Ha szervezete a házon belüli AI-bevezetés kiértékelésénél tart, [segíthetünk elkerülni a költséges tanulópénzeket](https://sheridan.hu/contact).*