Az anyanyelv ára: miért drágább magyarul az AI?

Ugyanaz az AI. Ugyanaz az API. Ugyanaz a feladat. Mégis előfordulhat, hogy ugyanannak a tartalomnak a feldolgozása magyarul 50–100%-kal, egyes mérésekben pedig akár 123%-kal több tokent igényel, mint angolul.

Ez nem azt jelenti, hogy az OpenAI, az Anthropic vagy a Google drágábban számlázna egy magyar felhasználónak.

Egy token ára ugyanannyi. Csakhogy ugyanazt az információt magyarul gyakran több tokenből lehet reprezentálni.

És ez nem csak az API-számlán jelenhet meg.

Kevesebb dokumentum fér ugyanabba a kontextusablakba. Egy RAG-rendszer kevesebb bizonyítékot tud egyszerre átadni a modellnek. Az AI-agentek közötti kommunikáció nagyobb lehet. Hosszú dokumentumoknál hamarabb érhetjük el a modell tokenlimitjét – sőt bizonyos szolgáltatóknál a magasabb long-context díjsávot is.

De pontosan mekkora ez a különbség?

Most már erre is vannak mérési eredmények.

Az első fontos dolog: nincs egyetlen univerzális „magyar tokenadó”.

A különbség függ:

• a használt tokenizálótól,
• a modelltől,
• a szöveg típusától,
• a fordítás megfogalmazásától,
• a szakterülettől,
• valamint attól is, hogy szavakat, karaktereket vagy azonos jelentésű teljes szövegeket hasonlítunk össze.

A különböző mérések azonban ugyanabba az irányba mutatnak.

A mérések módszertana eltér, ezért ezeket nem szabad egyetlen átlagba összemosni.

De egy vállalati költségtervezéshez már adnak egy nagyon használható nagyságrendet:

Azonos tartalom feldolgozásánál érdemes nagyjából 1,6–2,0× magyar input-tokenigénnyel számolni az angolhoz képest, majd ezt a saját modellünkön és saját dokumentumainkon lemérni.

Vagy még egyszerűbben:

ugyanaz a tartalom magyarul gyakran 60–100%-kal több token.

A kiindulópontként vizsgált magyar mérés öt különböző szövegtípust hasonlított össze Claude Sonnet 4.5 tokenizációjával.

Az eredmények:

A teljes mérésben tehát:

465 / 260 = 1,79×

Vagyis ugyanannak a jelentésnek a kifejezéséhez ebben a mintában a magyar változat 79%-kal több tokent használt.

Ez már nem néhány százalékos eltérés.

Ha az angol változat 1 millió tokent fogyasztana, ugyanez a szorzó magyarul körülbelül:

1 790 000 tokent jelentene.

Egy 2026. augusztus 14-én publikált mérés ugyanazt az üzleti-műszaki szöveget futtatta végig 12 aktuális modellen.

A magyar szöveg 1183 Unicode karakterből és 151 szóból állt, az angol 1213 karakterből és 194 szóból. Vagyis karakterben szinte ugyanakkora tartalmat hasonlítottak össze.

Az eredmények közül néhány:

A teljes mezőny:

minimum: 1,50×
medián: 1,63×
átlag: 1,71×
maximum: 2,23×.

Ez azt jelenti, hogy a mérés mediánjánál ugyanaz a tartalom magyarul 63%-kal több input tokent igényelt.

A GPT-5.6 Sol esetében pedig:

390 / 225 = 1,733×

vagyis körülbelül:

+73% input token ugyanazért a tartalomért.

Fontos: ez egy konkrét üzleti szövegpáron végzett mérés, nem univerzális GPT-5.6 konstans. Maga a mérés szerzője is kiemeli, hogy más fordítás, más domain vagy más szövegtípus néhány százalékkal módosíthatja az eredményt.

Az iOPTERA 2026-ban 25 európai és más nyelven öt különböző szövegtípust vizsgált:

• üzleti e-mailt,
• support választ,
• termékleírást,
• instrukciót,
• hétköznapi beszélgetést.

Az OpenAI újabb o200k_base tokenizálóján a magyar szövegek átlagosan:

2,02× annyi tokent

használtak, mint az azonos tartalmú angol változatok.

Ez +102%.

A régebbi cl100k_base tokenizerrel ugyanez a mérés 2,40× értéket adott.

Vagyis az újabb tokenizer jelentősen javult – de a magyar és az angol közötti különbség nem tűnt el.

Mindegyik lehet helyes.

Más modell.
Más tokenizer.
Más szövegminta.
Más mérési módszer.

Ezért félrevezető lenne azt írni, hogy:

„A magyar pontosan 79%-kal drágább.”

A sokkal korrektebb állítás:

A jelenlegi mérések alapján ugyanaz a természetes nyelvi tartalom magyarul tipikusan körülbelül 1,6–2,0× annyi tokenből állhat, mint angolul. Konkrét modelleken és szövegeken ennél kisebb és nagyobb eltérést is mértek: egy 12 modelles 2026-os tesztben 1,50–2,23× volt a tartomány.

Ez az a mondat, amelyet vállalati költségtervezésnél is vállalható használni.

Nézzünk egy teljesen konkrét példát.

Az AppForge mérésében a GPT-5.6 Sol ugyanarra a tartalomra:

225 angol token → 390 magyar token

értéket adott.

Ez 1,733×, vagyis 73,3%-kal több input token.

A GPT-5.6 Sol hivatalos API-ára jelenleg 4 dollár / 1 millió input token és 20 dollár / 1 millió output token.

Tegyük fel, hogy egy vállalati rendszer havonta olyan mennyiségű dokumentumot, RAG-kontextust és promptot dolgoz fel, amely angol reprezentációban:

100 millió input token lenne.

Angolul:

100 M × 4 USD = 400 USD

Ugyanez a tartalom a mért 1,733× magyar szorzóval:

173,3 M × 4 USD ≈ 693 USD

Különbség:

≈293 dollár havonta csak az input oldalon.

A 2026. szeptember 21-i 315,85 Ft/USD MNB árfolyammal ez nagyjából:

92 600 Ft havonta

vagy:

1,11 millió Ft évente.

És ebben még nincs benne az output, nincs benne az esetleges long-context árszorzó, valamint nem számoltunk cache-eléssel sem. Az árfolyam csak a nagyságrend érzékeltetésére szolgál.

Fontos azonban a matematikai különbség:

A rendszer nem „73%-kal drágább magyarul” mindenestül.

Ugyanaz a vizsgált input 73%-kal több token.

A teljes rendszerköltséget a válaszok hossza, cache, tool callok, reasoning tokenek, modellválasztás és számos más tényező is befolyásolja.

A tokenkülönbségnek van egy sokkal érdekesebb következménye.

A kontextusablak nem karakterben, hanem tokenben van

Tegyük fel, hogy két szöveg pontosan ugyanazt az információt tartalmazza.

Az angol változat:

100 000 token

A magyar változat pedig 1,73× szorzóval:

173 000 token.

Ez azt jelenti, hogy egy fix tokenablakban nem ugyanannyi információ fér el.

A matematikája:

1 / 1,73 = 0,578

Vagyis ugyanolyan tokenlimit mellett a magyar változatból körülbelül:

42%-kal kevesebb azonos tartalmú információ férhet el.

A 12 modelles mérés mediánjánál, 1,63× szorzóval:

1 / 1,63 = 61,3%

tehát körülbelül:

39%-kal kisebb az effektív, azonos tartalomra vetített kontextuskapacitás.

A 2,02× mérésnél pedig már közel pontosan megfeleződik:

1 / 2,02 = 49,5%

vagyis körülbelül:

50%-kal kevesebb azonos tartalom fér ugyanabba a tokenkeretbe.

Ezért félrevezető kizárólag az API-számláról beszélni.

Egy RAG-rendszernél ez azt jelentheti, hogy kevesebb dokumentumrészlet fér a modell elé.

Egy hosszú szerződésnél hamarabb kell darabolni.

Egy agentnél kevesebb előzményt lehet megtartani.

Egy nagy dokumentumhalmaznál több modellhívásra lehet szükség.

Ez különösen érdekes a mai nagy kontextusú modelleknél.

A GPT-5.6 Sol 1,05 millió tokenes kontextusablakkal rendelkezik, viszont az OpenAI dokumentációja szerint 272 000 input token felett a teljes kérés inputára megduplázódik, az output ára pedig 1,5× szorzót kap.

Ha csak szemléltetésként alkalmazzuk az előbbi 1,733× magyar/angol arányt:

272 000 / 1,733 ≈ 157 000

Vagyis egy olyan tartalommennyiség, amely angolul körülbelül 157 ezer token, magyarul már megközelítheti a 272 ezres határt.

Ez egy extrém fontos vállalati részlet:

a tokenizációs különbség bizonyos workloadoknál nemcsak lineárisan emelheti a tokenszámot, hanem korábban tolhatja át a kérést egy másik árazási sávba is.

A nagy nyelvi modellek valójában nem szavakat olvasnak.

A szöveget kisebb egységekre, úgynevezett tokenekre bontják.

Az angol gyakori szavak és szórészek sok tokenizer szótárában egyetlen tokenként szerepelnek.

A magyar azonban agglutináló nyelv.

Ugyanahhoz a szótőhöz rengeteg rag, jel és képző kapcsolódhat:

• ház,
• házban,
• házunkban,
• házainkban,
• házainkból,
• házaitokból…

Egy nem magyarra optimalizált tokenizer ezeket gyakran több kisebb egységre bontja.

Fontos ugyanakkor egy érdekes ellensúly:

magyarul gyakran kevesebb szóval mondjuk el ugyanazt.

A 12 modelles vizsgálat szövegpárjában például:

• magyar: 151 szó
• angol: 194 szó

miközben a két változat karakterhossza szinte azonos volt.

Ezért kell különválasztani két mérőszámot:

token/szó

és

token/azonos tartalom.

Egy magyar szó akár több mint kétszer annyi tokenből állhat, miközben egy teljes magyar mondat nem feltétlenül lesz kétszer olyan drága, mert magyarul kevesebb különálló szóra lehet szükség.

Erre az egyik legjobb bizonyíték a magyar Racka modell fejlesztése.

Az ELTE kutatói Qwen3-4B alapmodellből indultak ki, és többek között a tokenizálót is magyar nyelvre optimalizálták.

Az eredeti Qwen3-4B tokenizer subword fertility értékei:

• magyar: 3,1269 token/szó
• angol: 1,5705 token/szó
• német: 2,0502 token/szó

Vagyis szavanként a magyar majdnem:

1,99× annyi tokent

igényelt, mint az angol.

A magyarra optimalizált Racka tokenizer után:

• magyar: 1,6584
• angol: 1,9387
• német: 2,3090

A magyar tokenigény:

46,96%-kal csökkent.

Ez nagyon fontos eredmény.

A magas magyar tokenszám tehát nem egyszerűen azért létezik, mert „ilyen a magyar nyelv”.

Nagyon sok múlik azon, hogyan építették meg a tokenizálót és mennyi szótári kapacitást kapott a magyar.

A Racka esetében 32 000 új, magyarra optimalizált token került a szótárba.

Elsőre kézenfekvő:

magyar input → angol fordítás → LLM → magyar fordítás

De ez önmagában nem feltétlenül jó megoldás.

A fordításnak is van:

• költsége,
• késleltetése,
• hibaaránya,
• terminológiai kockázata.

Egy hárommondatos ügyfélszolgálati kérdést külön translation API-n átküldeni azért, hogy megtakarítsunk 30 tokent, könnyen értelmetlen optimalizáció.

Egy 200 oldalas dokumentumtárat vagy többmillió tokenes agent-kommunikációt viszont már egészen más gazdaságosság jellemez.

Ezért hibrid nyelvi architektúrában érdemes gondolkodni.

Ha egy AI-agent olyan üzenetet készít, amelyet kizárólag egy másik AI fog elolvasni, nincs különösebb értéke annak, hogy a köztes kommunikáció magyar legyen.

A folyamat például:

magyar felhasználó
↓
magyar eredeti input
↓
angol belső instrukciók és agent-kommunikáció
↓
AI-feldolgozás
↓
magyar végső válasz

A felhasználó ebből semmit nem érzékel.

A rendszer belső nyelve és a felhasználó nyelve nem feltétlenül kell, hogy azonos legyen.

Egy vállalati RAG-rendszernél jobb megoldás lehet az egyszeri előfeldolgozás:

eredeti magyar dokumentum
↓
darabolás
↓
angol normalizált reprezentáció
↓
embedding / indexelés
↓
eredeti magyar és angol chunk összekapcsolása

A fordítás költsége egyszer jelentkezik.

Utána ugyanaz a reprezentáció akár több ezer kérdésnél újra felhasználható.

Az eredeti magyar dokumentum közben végig megmarad forrásként.

Minden lefordított szövegrészlethez létrehozható egy hash.

Ha a rendszer ismét ugyanazzal a tartalommal találkozik:

nem kér új fordítást.

A korábban elkészített és akár ember által jóváhagyott fordítást használja.

Nagy dokumentumtáraknál és ismétlődő vállalati sablonoknál ez komoly megtakarítást jelenthet.

Egy általános fordító nem tudja automatikusan, hogy egy adott vállalatnál:

• mi terméknév,
• mi jogi fogalom,
• mi belső rövidítés,
• mely kifejezést tilos lefordítani,
• mely szakmai terminológiának van rögzített megfelelője.

Ezért vállalati AI-rendszernél egy translation layer mellé érdemes:

glossaryt, terminológiai adatbázist és verziózott fordítási szabályokat építeni.

A DeepL és a Google Cloud Translation is támogat ilyen glosszáriumalapú folyamatokat.

Ez az egyik legérdekesebb eredmény.

Ugyanazon magyar szöveg az AppForge mérésében:

• a leghatékonyabb vizsgált modellen 336 token,
• a legmagasabb értéket adó modellen 543 token

volt.

Ez 62%-os eltérés ugyanazon magyar szövegnél, pusztán a modell/tokenizer megválasztása miatt. Ha a speciális Anthropic-esetet kivesszük, a maradék modellek között is 49%-os volt a tartomány.

Vagyis egy magyar vállalati rendszer modellválasztásánál nem csak ezt kell nézni:

„mennyi az API ára 1 millió tokenre?”

Hanem ezt is:

„hány token lesz a mi magyar dokumentumunkból ezen a modellen?”

Egy olcsóbb tokenárú modell rosszabb tokenizációval akár kevésbé gazdaságos is lehet, mint egy drágább, de magyarul hatékonyabb alternatíva.

A rendelkezésre álló mérések alapján első költségbecsléshez:

1,6–2,0× HU/EN tokenaránnyal érdemes kalkulálni természetes nyelvi tartalom esetén.

De ezt csak kiindulópontként.

A production rendszer előtt érdemes fogni például:

• 100 valódi ügyfélüzenetet,
• 20 hosszabb dokumentumot,
• néhány szerződést,
• a rendszerpromptokat,
• a tipikus RAG chunkokat,
• az agent-to-agent üzeneteket,

és pontosan megszámolni a tokeneket minden szóba jöhető modellen.

Ezután már nem azt mondjuk, hogy:

„a magyar körülbelül drágább”.

Hanem például azt:

„A saját dokumentumállományunk GPT-5.6 Solon átlagosan 1,68×, Gemini modellen 1,55×, egy harmadik modellen pedig 1,91× annyi input tokent használ magyarul, mint az azonos angol reprezentáció.”

Ez már olyan adat, amelyre infrastruktúrát és költségtervet lehet építeni.

A megoldás nem az, hogy egy magyar cég kezdjen angolul kommunikálni.

A felhasználó továbbra is írhat magyarul.
A vállalati dokumentumok maradhatnak magyarul.
A végső válasz lehet magyar.
A hiteles jogi forrás maradhat az eredeti magyar dokumentum.

Csak a háttérben kell eldönteni, melyik feldolgozási lépésnek van valódi oka magyarul történni.

Egy jól tervezett rendszer kombinálhatja:

• az eredeti magyar forrást,
• angol belső reprezentációt,
• translation cache-t,
• vállalati terminológiai adatbázist,
• RAG-ot,
• prompt cachinget,
• és a magyar workload alapján kiválasztott modellt.

Az anyanyelvnek nem kell szükségszerűen technológiai versenyhátránnyá válnia.

De ehhez először mérni kell.

Az AI Hungáriánál vállalati AI-rendszereknél nem csak azt vizsgáljuk meg, hogy melyik modell adja a legjobb választ.

Megnézzük azt is, hogyan működik a teljes AI-infrastruktúra a vállalat saját magyar adatain.

Egy AI költség- és architektúra-audit során megvizsgálható:

• mennyi a magyar nyelv tényleges tokenigénye a saját dokumentumokon,
• melyik modell tokenizálja hatékonyabban a vállalati tartalmat,
• hol éri meg angol belső reprezentációt használni,
• hol veszélyes vagy felesleges a fordítás,
• hogyan optimalizálható a RAG-kontextus,
• hol használható translation cache,
• mennyi felesleges tokenforgalmat generálnak az agentek,
• és mennyivel csökkenthető az AI-rendszer teljes üzemeltetési költsége.

Ne becsülje meg, mennyibe kerül a magyar AI. Mérjük meg a saját adatain.