Egy belső AI-asszisztens ötlete ma már szinte minden cégnél felmerül. Az első kérdés rendszerint az, hogy mennyibe kerül. A második, még ha nem is mindig hangzik el, az, hogy hová kerülnek közben a cég adatai. Futhat-e egy ChatGPT-szerű nyelvi modell (LLM) a cég saját szerverén? És ha igen, megéri?

A válasz a két kérdés együttesén múlik. A legolcsóbb megoldásokért jellemzően adatkontrollal fizetünk. Kevésbé látjuk, hol dolgozzák fel az adatot, ki férhet hozzá, és tanítanak-e rajta. Ebben a cikkben öt lehetőséget vetünk össze árban és adatbiztonságban, a felhős előfizetésektől a helyi, on-premise AI szerverig, 2026. októberi árakkal. A három fő út rövid összevetését a céges AI-ról szóló oldalunkon is megtalálod, itt a számok mögé nézünk.

Lehetőségek a céges AI bevezetésére

• Egyéni előfizetés, például ChatGPT Plus, Claude Pro, Google AI Pro vagy Microsoft 365 Premium. Személyes használatra készült, fogyasztói feltételekkel.

• Üzleti csomag, például ChatGPT Business, Claude Team, Gemini a Google Workspace-ben vagy Microsoft 365 Copilot. Ugyanezek a modellek, üzleti szerződéssel és adminisztrációval. A bevezetés itt inkább szabályozási és képzési kérdés, mint technikai.

• Menedzselt modell az EU-ban, például a Microsoft Foundry EU-s adatzónájában. A modellt API-n keresztül, saját alkalmazásba építve használjuk. Erről részletesebben a felhős AI az EU-ban oldalunkon írunk.

• Bérelt GPU-szerver EU-s adatközpontban. Óra- vagy havidíjas, dedikált GPU-val szerelt felhős gép, amelyen nyílt súlyú modellt tanítunk vagy futtatunk. Leginkább finomhangolásra ajánljuk, mert az erős gépre csak a tanítás idejére van szükség, a kész modell utána gyengébb, saját vason is elfut.

• Saját AI szerver a cég telephelyén, vagyis on-premise AI-szerver. A modell és az adat sosem hagyja el a céget.

Miért futtatna bárki helyben AI-t?

A felhős modellek okosabbak, olcsóbbak, és nem kell őket üzemeltetni. Mégis az a tapasztalatunk, hogy egyre többen érdeklődnek a lokálisan futó nyelvi modellek iránt. Ezek a leggyakoribb okok, amiért egy cég helyben futó AI-ra vált.

1. Az adat nem hagyhatja el a céget. Forráskód, termékfejlesztési információ, üzleti titok, minősített irat vagy olyan ügyféladat, amelyre a szerződés ezt kifejezetten előírja.

2. A jogi kockázat nem elfogadható. Az EU-s adatközpont még nem jelent uniós joghatóságot, és a felhős szolgáltatók feltételei menet közben is változhatnak (erről lent bővebben).

3. Tartós, nagy terhelés. Tokenalapú díjnál a költség a használattal együtt nő. Ha egy csapat vagy egy automatikus folyamat egész nap dolgoztatja a modellt, a saját hardver két-három év alatt megtérülhet. Egy ideig azonban az előfizetések is bírják a tartós használatot, és amíg a kvótakorláton belül maradunk, olcsók is.

4. Kiszámíthatóság és függetlenség. A helyi modell nem változik meg egyik napról a másikra, nincs kvóta vagy lassulás csúcsidőben, és internet nélkül is működik. Felhőben rögzített modellverzióval ez részben megoldható, a régebbi verziókat azonban a szolgáltatók idővel kivezetik.

5. Testreszabás. Saját adaton finomhangolt modellt futtatni és meglévő rendszerekbe kötni helyben gyakran egyszerűbb. A tanításhoz elég néhány napra GPU-t bérelni. A legtöbb felhős szolgáltató is enged finomhangolni, viszont a Microsoft például ilyenkor már nem garantálja, hogy az adat az EGT-n belül marad.

Ezekkel szemben visszatartó ok lehet, hogy a helyi szervert üzemeltetni kell, és folyamatos költsége is van, például az áram. A nem csillagászati árú gépeken megfelelő sebességgel futtatható modellek, pedig a legnehezebb feladatokban még elmaradnak a nagy szolgáltatók modelljeitől.

Mire használják a cégek, és mitől függ az ár?

Egy AI-rendszer ára elsősorban nem a cég méretén múlik, hanem a feladaton. Ugyanaz a 30 fős cég havi 5 ezer forintért is tud AI funkcionalitást kialakítani, de 30 millió forintos szerverre is szüksége lehet. Lássunk öt példát, és hogy mi határozza meg az árukat. A lista nem teljes, a valós igények cégenként eltérnek.

Az alábbi táblázatok számai ezekre a példákra épülnek, más felhasználásnál a méretezés is más lehet.

Mennyibe kerül egy AI szerver és a felhős AI?

A felhős megoldások havidíjasak vagy használat szerint fizetendők, a saját szerver viszont egyszeri beruházás, amelyhez üzemeltetési költség társul. Minden ár nettó, forintra átszámolva.[1]

Mikor érdemes GPU-t bérelni?

A bérelt GPU-t elsősorban finomhangolásra ajánljuk. Egy 30 milliárd paraméter körüli modell finomhangolásához egyetlen 80 GB-os H100 elég, és a tanítás óradíjjal számolva néhány tízezer forinttól pár százezer forintig terjed.[5] A kész modell utána egy DGX Sparkon vagy más, kisebb gépen fut, az erős hardverért tehát csak a tanítás idejére fizetünk. A 100 milliárd paraméter feletti modellek tanításához több GPU-s gép kell, ezt is érdemes órára bérelni.

Nagyobb tanításhoz a bérlés mellett a hazai Komondor szuperszámítógép programjait is ajánljuk. A Komondort üzemeltető HPC Kompetencia Központ cégeknek is hirdet programokat, a hardvert biztosítja, és a használatban is segít. Mi is a Komondoron tanítottuk a Racka magyar nyelvű modellt.

Folyamatos futtatásra a bérelt GPU ritkán éri meg. A havi kb. 710 ezer forint három év alatt több mint 25 millió forint, ennyiből már egy saját DGX Station is kijön.

Mennyi áramot fogyaszt egy AI szerver?

A saját hardver ára mellé az üzemeltetés költsége is hozzájön, ami nem elhanyagolható. Az áramot piaci áron, kb. 110 Ft/kWh nettó árral számoltuk.[6] A saját szerződés ettől akár jelentősen is eltérhet.

Ehhez jön még a szerverterem vagy adatközponti hely, a karbantartási szerződés, az üzemeltető munkaideje, valamint az, hogy a hardvert 3–5 évente cserélni kell. A jogosultságkezelés és a meglévő rendszerekhez kötés pedig gyakran több munka, mint maga a telepítés.

A saját hardver akkor térül meg, ha tartósan terhelve van. A DGX Station egészen friss termék, 2026 tavasza óta rendelhető, ezért az ára még mozog, és kevés vele a gyakorlati tapasztalat.

Mekkora modellt futtat egy AI szerver, és hány felhasználót bír?

Az ár önmagában keveset mond, ha nem tudjuk, mit kapunk érte. A felhőben a szolgáltatók legnagyobb modelljei érhetők el, saját hardveren viszont a gép memóriája szabja meg, mekkora modellt futtathatunk, és hány embert tud egyszerre kiszolgálni.

Ebben a cikkben csak a szöveget generáló nyelvi modellekkel foglalkozunk. Sok döntéshez nincs is rájuk szükség, a klasszikus gépi tanulási modellek (például előrejelzés, besorolás vagy anomáliaészlelés) akár CPU-n vagy kisebb GPU-n is futnak. Ezekről a Jev modellről szóló cikkünkben írunk, és ilyen modulokat is fejlesztünk meglévő rendszerekbe.

A táblázatban használható sebességgel, felhasználónként legalább kb. 20 token/s-mal számoltunk.[7]

A számok tájékoztató jellegűek, a pontos érték a modelltől, a kérdések hosszától és az elvárt válaszidőtől függ. Egy ügynök, amely egész kódtárakat vagy hosszú szerződéseket tart észben, sokkal több memóriát igényel, mint egy rövid kérdés-válasz. Fontos, hogy az egyszerre kérdezők száma számít, nem a munkatársaké. Egy 50 fős cégnél ritkán kérdez tíznél több ember ugyanabban a pillanatban.

De mire elég egy adott méretű modell?

• A kis modellek (néhány milliárd paraméter) gyorsak és olcsók, egyszerű besorolásra és adatkinyerésre valók, magyarul viszont érezhetően gyengébbek.

• A 30 milliárd paraméter körüli modellek idén nyáron és ősszel megjelent generációja már jól kezeli a dokumentumokból való kérdezést és az összefoglalást, és kódolni is tud. Az augusztusi Qwen3.8-27B a gyártó saját mérése szerint a SWE-bench Pro programozási teszten 61,7%-ot ér el, a Claude Opus 4.6 hivatalosan közölt 53,4%-ánál is többet (a két eredményt nem azonos környezetben mérték). A magyar nyelvi tesztekben egy szinten állnak a kisebb kereskedelmi modellekkel, a Magyarországgal kapcsolatos tudásban azonban még elmaradnak tőlük. Hogyan érdemes az ilyen eredményeket olvasni, azt a benchmarkokról szóló cikkünk ismerteti.

• A 100 milliárd paraméter feletti nyílt modellek több tudást hordoznak, ez a magyar vonatkozású tényeknél és az összetett, többlépéses feladatoknál látszik. A legtöbbjük takarékos (MoE) felépítésű, egy-egy válaszhoz a paramétereinek csak kis részét használja, így a méret önmagában nem minden.

• A felhős csúcsmodellek a legnehezebb érvelési feladatokban és a magyar nyelvben általában még mindig a legerősebbek.

Ha az AI-nak eszközöket is használnia kell (például adatbázisból lekérdezni vagy a CRM-ben rögzíteni), az egyszerű függvényhívásokra már a 10 milliárd paraméter körüli modellek is képesek. Az eszközhasználati ranglistán a 9 milliárdos Qwen3.5 kb. 7 ponttal marad el a 397 milliárdos változattól, a 4 milliárdosnál viszont már erősen romlik a teljesítmény (a ranglista eredményeit a gyártók maguk közlik). Megbízható, többlépéses ügynöki munkához a 30 milliárd körüli méret a belépő. A feladatokat részekre bontó, tervező szerephez pedig érdemes 100 milliárd feletti vagy felhős modellt választani, mert hosszú folyamatokban a hibák összeadódnak.

Hol marad az adat? Adatbiztonság és GDPR

Minél több kontrollt szeretnénk az adat felett, annál több felelősséget is vállalunk. Saját szerveren senki más nem látja az adatot, de a biztonságáért, mentéséért és frissítéséért is a cég felel. A GDPR szempontjából két kérdés dönt, hol dolgozzák fel a személyes adatot, és van-e adatfeldolgozói szerződés a szolgáltatóval.

Ha valaki úgy érzi, hogy a felhős modell nem elég biztonságos, érdemes megnézni, mit használ már most. Ahol Microsoft 365 vagy Copilot fut, ott a cég már elfogadta azt az adatfeldolgozói keretszerződést (Microsoft Products and Services DPA), amely a Foundryben futó Azure-modellekre is vonatkozik. Ugyanaz a szolgáltató és ugyanazok a feltételek, így ebből a szempontból nem vállal új kockázatot, és általában egy Azure-előfizetés elég az induláshoz. Kivételt az előzetes (preview) funkciók és a más gyártóktól származó modellek jelentenek, például az Anthropic Claude, ezekre külön feltételek vonatkoznak.

Példa a saját gyakorlatunkból

Egy 4 fős fejlesztőcsapatnak méreteztünk helyben futó rendszert kódrefaktoráláshoz, ahol a forráskód nem hagyhatja el a céget. A fejlesztők egy Claude Code-hoz hasonló munkafolyamatban dolgoznak. Egy nagyobb tervező modell (legfeljebb 200–300 milliárd paraméter) bontja fel a feladatot, egy kisebb, gyors végrehajtó modell írja a kódot, és háttérfeladatok (tesztek, kódellenőrzés) is futnak. A hardverkeret 30 millió forint volt.

Összehasonlításképpen ugyanez a terhelés felhőben havonta kb. 2,3–4,6 millió forintba kerülne.[12] Három év alatt ez 80–165 millió forint, vagyis a Sparkok 2–5 hónap, a DGX Station kb. 7–18 hónap alatt térül meg. Ebben az esetben a forráskód miatt eleve helyben kellett futnia a rendszernek, de ekkora terhelésnél a saját hardver pénzügyileg is megéri.

Ha a forráskód elhagyhatja a céget, és nincs EGT-s megkötés, az előfizetéses fejlesztői eszközök ennél jóval olcsóbbak lehetnek. A Claude Code-ot is tartalmazó Claude Max előfizetés fejlesztőnként havi 100–200 dollár, négy főre ez kb. 130–260 ezer forint. Ezek az előfizetések viszont kvótával működnek (ötórás és heti korlátokkal), így a folyamatosan futó háttérfeladatokhoz nem mindig elegendők. A GitHub Copilot havidíja egy kreditkeretet tartalmaz, afölött a használat szerint kell fizetni, így nagy ügynöki terhelésnél a költsége is nő.

Konklúzió

Az első kérdés tehát nem az ár, hanem az, hogy milyen adatot adunk az AI-nak, és milyen feladatra. Egyéni kísérletezéshez, céges adat nélkül elegendő egy előfizetés, kikapcsolt tanítással. A csapat napi, nem érzékeny munkájára egy üzleti csomag jó választás. Ahol Microsoft 365 fut, ott a Copilot is jó kiindulópont, ha a rendszergazda a flex routingot kikapcsolja.

Belső dokumentumokhoz és személyes adatokhoz a menedzselt, EU-ban futó modell kínálja a legjobb ár-érték arányt. Saját AI szerver akkor éri meg, ha az adat (például forráskód vagy minősített irat) nem hagyhatja el a céget, vagy ha a modellt tartósan sokan, például 20–30 ember egyszerre használja. Ha saját adaton tanított modell kell, a tanításhoz elég a Komondor vagy egy bérelt GPU a finomhangolás idejére, a kész modell már kisebb gépen is fut. A legtöbb cégnél a felhős megoldás a jó első lépés, a helyi rendszer pedig akkor következik, amikor a használat már kiszámítható. Ha nem egyértelmű melyik a jó út, azt egy rövid megvalósíthatósági tanulmány keretében fel tudjuk mérni.