Melyik LLM tud igazán magyarul? Saját mérés, nyers eredményekkel

Mit mértünk, és mi jött ki belőle?

Ugyanazt az üzleti szöveget mértük magyarul és angolul, tizenkét modell natív tokenizálójával. A magyar változat modelltől függően 1,50 és 2,23 közötti szorzóval fogyaszt több input tokent, a medián 1,63. A modellválasztás önmagában 62 százalékos különbséget okoz a magyar szöveg tokenszámában. Nyelvi minőséget nem mértünk, csak azt, hány tokenbe kerül ugyanaz a tartalom. A mérés napja 2026. augusztus 14.

A magyar AI-piac szereplői sorra ígérnek natív magyar nyelvi feldolgozást. Egyikük sem közöl mérést arról, hogy ez mennyibe kerül. Ez a cikk egyetlen, szűk kérdésre ad számot: hány input tokent fogyaszt ugyanaz a tartalom magyarul, illetve angolul, különböző modellcsaládok tokenizálóival.

Miért éppen ezt? Mert a token az egyetlen dolog, amiről a számla szól, és mert a méréshez nem kell sem annotátor-csapat, sem korpusz. Bárki megismételheti egy délután alatt. A módszertant és a nyers számokat végig kiírjuk, éppen azért, hogy megismételhető legyen.

A cikk egy korábbi, ugyanezen a napon készült mérési körre épül, amely az előző modellgenerációt (Llama 3.3, Llama 4 Maverick, Gemma 4, Mistral Small 3.2, Gemini 2.5 Flash-Lite, Claude Haiku 4.5, DeepSeek V3.2) mérte. Azt a kört a jelenlegi generációval újrafuttattuk, változatlan szövegpárral és változatlan harness-szel. A két kör összevetése önmagában is hozott egy eredményt, amit külön szakaszban írunk le.

Miért drágítja a tokenizálás a magyar nyelvű chatbotot?

A nyelvi modellek nem karaktereket vagy szavakat dolgoznak fel, hanem tokeneket: szódarabokat, amelyeket egy angol szövegtúlsúlyú korpuszon tanított szótár határoz meg. A számlázás is tokenben történik. A mérésünkben tizenegy modellnél egy tokenre angolul 5,30 és 5,49 karakter jutott, magyarul ugyanezeknél 2,36 és 3,52 között. A tizenkettedik, a Claude Opus 5 mindkét nyelven kilóg, 3,63 és 2,18 karakterrel. Ha a szöveg több darabra esik szét, ugyanaz a tartalom többe kerül, lassabban dolgozódik fel, és kevesebb fér belőle a kontextusablakba.

A mért szövegpáron a magyar 1 183, az angol 1 213 Unicode karakter, tehát gyakorlatilag azonos hosszúak. Ehhez képest a magyar 151 szóból áll, az angol 194-ből. Magyarul kevesebb szó kell ugyanahhoz a tartalomhoz, mert az agglutináció ragokba sűríti azt, amit az angol külön elöljárókkal és segédszavakkal fejez ki. UTF-8-ban viszont a magyar 11 százalékkal több bájt, mert az ékezetes karakterek két bájtot foglalnak. A tokenizáló szempontjából ez a második szempont a súlyosabb.

Egy konkrét chatbot költsége, végigszámolva

Vegyünk egy ügyfélszolgálati chatbotot RAG-alapú tudásbázissal, havi 500 beszélgetéssel. Beszélgetésenként hat kör, halmozódó előzménnyel, körönként újraküldött rendszerprompttal és visszakeresett dokumentum-részletekkel. Angolul ez beszélgetésenként nagyjából 8 000 input és 900 output token, tehát havonta 4 000 000 input és 450 000 output token.

A Gemini 3.7 Flash ára 0,75 dollár millió input tokenenként és 3,75 dollár millió output tokenenként. Az angol változat így havi 3,00 plusz 1,69, összesen 4,69 dollár. A magyar változat a mért 1,64-szeres aránnyal 6 542 000 input és 736 000 output token, azaz 7,67 dollár. A különbség havi 2,98 dollár, ami a 2026-08-14-i MNB-középárfolyamon (314,36 Ft/USD, lásd mnb.hu) 937 forint.

Ugyanez a Claude Opus 5-tel, amelynek listaára 5 dollár input és 25 dollár output millió tokenenként (platform.claude.com): angolul 31,25 dollár, magyarul 50,80 dollár, a különbség 19,55 dollár, vagyis 6 147 forint havonta.

Négy mért modell hiányzik ebből a táblából, mert nem találtunk hozzájuk hivatalos, nyilvános per-token árlistát: a Qwen3.8-Max, a Muse Spark 1.2, a Nemotron 3.5 Lightning és a Seed 2.1 Turbo. A tokenizáló-mérésük érvényes, csak a forintosításuk nem lenne hiteles. Viszonteladói ár mindegyikhez létezik, de arra nem érdemes költséget alapozni.

Őszintén: ezen a méreten a nyelvi többletköltség nem érdekes. Havi 379 és 7 723 forint közötti tétel kevesebb, mint egy-két órányi fejlesztői munka. Aki a magyar nyelv drágaságával indokolja a havidíját, az rosszul érvel.

A szám ott válik komollyá, ahol a volumen nő, vagy ahol drága modell fut a háttérben.

A valódi hatás nem a számlán van

Három helyen érezhető a token-többlet, és a számla ezek közül a legkevésbé fájdalmas.

• Egy 32 ezer tokenes kontextusablakba magyarul 1,5-2,2-szer kevesebb tartalom fér. Egy hosszabb szerződés vagy egy negyven körös beszélgetés angolul még belefér, magyarul már nem. A rendszer elfelejt, vagy nagyobb kontextusú, drágább modellre kell váltani. Ez nem költség, hanem funkcionális korlát.
• Az input tokenek feldolgozása nagyjából lineáris, tehát 1,5-2,2-szer több input körülbelül ennyivel hosszabb time-to-first-tokent jelent. Chatbotnál ezt a felhasználó megérzi.
• A tokenszám-alapú percenkénti kvótákat a magyar szöveg gyorsabban meríti ki, tehát ugyanaz a rate limit kevesebb magyar felhasználót szolgál ki.

Hogyan mértünk? A teljes módszertan

Az OpenRouter API a modell natív tokenizálójával számolt értéket adja vissza a usage.prompt_tokens mezőben, és a számlázás is ez alapján történik. A dokumentáció ezt kifejezetten rögzíti (openrouter.ai/docs). Amit tehát mérünk, az pontosan az, amit fizetünk. Tizenkét modellt hívtunk meg azonos paraméterezéssel, ugyanazzal a két szöveggel, majd modellenként kivontuk a chat-sablon fix ráfordítását. Az alábbi szakaszok ezt a három lépést írják le, olyan részletességgel, hogy bárki megismételhesse.

A hívások paraméterezése

Két modellnél a max_tokens: 1 nem működött. A Gemini 3.7 Flash üres választ és usage-adat nélküli rekordot adott vissza, a Muse Spark 1.2 pedig HTTP 400-zal elutasította a hívást azzal, hogy a minimum 16. Mindkettőnél mind a három mérés (alapmérés, magyar, angol) max_tokens: 16-tal futott, tehát önmagukon belül konzisztensek. A max_tokens az output felső korlátja, az input tokenszámát definíció szerint nem érinti.

A prompt-overhead kivonása

Ez a mérés legfontosabb korrekciója, és enélkül az egész szám használhatatlan volna. A hívások nem a nyers szöveget küldik: minden modell köré chat-sablon és harness-oldali rendszerelőzmény kerül. Ez modellenként eltérő méretű, és nem kicsi. A mostani körben 222 és 647 token közötti fix ráfordítást találtunk, vagyis a legrosszabb esetben másfélszer annyit, mint amennyibe maga az angol szöveg kerül.

Minden modellnél lefutott egy alapmérés azonos paraméterezéssel, de egyetlen x karakter payloaddal. A tiszta szöveghossz ebből:

net_tokens = total_tokens − baseline_tokens + 1

A plusz egy azért kell, mert az alapmérés maga is tartalmaz egy token payloadot. A korrekciót három, egymástól független módon ellenőriztük, mert a 647-es Grok-alapmérés mellett a puszta kivonás önmagában nem lett volna hihető.

• Linearitás. Tíz darab x payloaddal négy modellt hívtunk meg. A Gemini 222-ről 231-re, a Claude Opus 5 319-ről 328-ra, a Grok 647-ről 656-ra, a Kimi K3 311-ről 320-ra ment. Mind a négynél pontosan a várt plusz kilenc jött ki, a nagy overhead ellenére is.
• Marginális költség. A Claude Opus 5 feltűnően magas angol értéket adott, ezért lefuttattunk egy olyan ellenőrzést, amely egyáltalán nem használja az alapmérést: elküldtük az angol szöveget kétszer, ugyanabban az üzenetben. Egyszer 652, kétszer 987 token, tehát egy további példány marginális ára 335. Az alapmérés-kivonással kapott nettó érték 334 volt. A különbség a bekezdéselválasztó.
• Kontroll a korábbi körből. Újramértük a Claude Haiku 4.5-öt ugyanazon a napon, ugyanazzal a harness-szel: alapmérés 233, angol 465. Bitre azonos a korábbi körben mért értékkel, tehát a két kör számai közvetlenül összehasonlíthatók.

A két mért szöveg, szó szerint

Négy bekezdés, azonos tartalom, üzleti-technikai regiszter. A magyar az eredeti, az angol ennek hű fordítása. Ugyanaz a két blokk futott a korábbi körben is, ezért összevethetők a mérések. Aki meg akarja ismételni a mérést, ezt a kettőt másolja.

Az ügyfélszolgálati folyamatok automatizálása a legtöbb középvállalatnál a beérkező megkeresések osztályozásával kezdődik. A rendszer beolvassa az e-mailt, azonosítja a küldő ügyfelet a vállalatirányítási rendszerben, majd eldönti, hogy árajánlatkérésről, reklamációról vagy technikai hibabejelentésről van-e szó. Az osztályozás eredményét a munkatársak felülvizsgálhatják, és a javításokból a modell folyamatosan tanul.

A bevezetés első szakaszában érdemes szűk területen indulni. Válasszunk egyetlen ügytípust, amelyből havonta legalább néhány száz eset érkezik, és mérjük meg a jelenlegi átfutási időt, valamint az egy megkeresésre jutó munkaráfordítást. Ezek nélkül a későbbi megtérülés nem igazolható.

A második szakaszban következik az integráció: a vállalatirányítási rendszer, a számlázó program és a levelezés összekötése. Itt derül ki, hogy a meglévő adatok mennyire tiszták. Tapasztalatunk szerint a projektek csúszásának háromnegyede nem a modell pontosságán, hanem a hiányos törzsadatokon múlik.

Végül az üzemeltetés kérdése marad. Meg kell határozni, ki felel a hibás döntésekért, milyen naplózás készül, és hogyan lehet a rendszert visszavonni, ha a minőség romlik.

For most mid-sized companies, automating customer service processes begins with classifying incoming requests. The system reads the email, identifies the sending customer in the enterprise resource planning system, and then decides whether it is a quote request, a complaint, or a technical fault report. Staff can review the result of the classification, and the model learns continuously from the corrections.

In the first phase of the rollout it is worth starting on a narrow scope. Pick a single case type that generates at least a few hundred cases per month, and measure the current turnaround time as well as the work effort per request. Without these, the later return on investment cannot be proven.

The second phase brings integration: connecting the enterprise resource planning system, the invoicing software, and the mail server. This is where it becomes clear how clean the existing data is. In our experience, three quarters of project delays are not caused by model accuracy but by incomplete master data.

Finally, the question of operations remains. It must be defined who is accountable for wrong decisions, what logging is produced, and how the system can be rolled back if quality degrades.

A mért modellek

Tizenkét modell, tizenkét különböző tokenizáló-implementációból. A sluggokat előzetesen ellenőriztük a modell-listázó végponton, egyik sem tippelt név.

Egy modell kiesett a mérésből. Az openai/gpt-5.6-luna-pro az egykarakteres alapmérésre 2 396 input tokent adott vissza, ami nagyságrenddel több a mezőny 222-647-es sávjánál, és arra utal, hogy a pro reasoning mód belső meneteket összegez a prompt-tokenekbe. Ez érvényteleníti a lineáris overhead-kivonást. Hosszú payloaddal ráadásul négy egymást követő hívásból egyszer sem adott vissza usage-adatot. Helyette ugyanabból a családból és tokenizálóból a zászlóshajó Sol került be, amelynek alapmérése bitre azonos a korábbi körben mért Luna-értékkel.

Mik a nyers eredmények modellenként?

Minden szám az OpenRouter által visszaadott input token érték, a nettó oszlopok pedig az overhead-korrekciót tartalmazzák. A magyar nettó tokenszám 336 és 543 között szór, az angol 221 és 229 között, egyetlen kivétellel.

A két arány nem ugyanaz, és ezt sokan összekeverik

A táblázat két, könnyen összetéveszthető számot tartalmaz. A HU/EN token-arány azt mondja meg, hányszor több tokenbe kerül ugyanaz a tartalom magyarul. Ez a költséghatás, és 1,50 és 2,23 között van. A fertility-arány azt mondja meg, hány token kell egy magyar szóra az angolhoz képest; ez a nyelvészeti irodalom szokásos metrikája, és 1,93 és 2,86 között van.

A kettő azért tér el, mert magyarul ugyanaz a tartalom 22 százalékkal kevesebb szóból áll. Az agglutináció egyszerre büntet és jutalmaz: több token kell egy szóra, viszont kevesebb szó kell a mondathoz. Nettó eredmény, hogy a valós költségtöbblet nagyjából 25 százalékkal kisebb annál, mint amit a puszta fertility-szám sugallna. Aki a szakirodalom 1,9-2,9-szeres fertility-számát idézi költségérvként, az túlbecsüli a magyar hátrányt.

A modellválasztás 62 százalékot mozgat

A két szélső eset a Muse Spark 1.2 a maga 336 tokenjével és a Claude Opus 5 az 543-mal, ugyanazon a magyar szövegen. Ez 62 százalékos különbség a magyar input költségében, anélkül, hogy az alkalmazáson bármit változtatnánk. Ha az Opus 5-öt kivesszük a mezőnyből, mert nála az angol is romlott, a maradék tizenegynél a szélsőértékek 336 és 501, vagyis 49 százalék. A korábbi körben ugyanez a szám 46 százalék volt.

Ebből következik a cikk legkonkrétabb tanulsága: magyar nyelvű LLM-alkalmazásnál a tokenizáló-hatékonyság önálló modellválasztási szempont, a képesség és a listaár mellett. A gyakorlatban erről egyik modellkártyán sem szerepel egyetlen adat sem.

Egy apró megfigyelés a táblázatból: három, egymástól teljesen független gyártó modellje, a Qwen3.8-Max, a Nemotron 3.5 Lightning és a Mistral Medium 3.5, pontosan ugyanazt a 366-os magyar értéket adta. Ez vagy közös szótár-leszármazásra utal, vagy arra, hogy a nagy BPE-szótárak a magyarra hasonló optimumhoz konvergálnak. A mérés ezt nem tudja eldönteni.

Generációk közti változás: javulnak a tokenizálók magyarul?

Ez a szakasz a két mérési kör összevetése. Ugyanaz a szövegpár, ugyanaz a harness, ugyanaz a nap, csak a modellgeneráció más. A kontroll-mérések (a Qwen3.8-Max mindkét körben, a Claude Haiku 4.5 újrafuttatva) bitre azonos értéket adtak, tehát a két kör számai összehasonlíthatók.

A tokenizálók nem javulnak generációról generációra a magyaron. Hat gyártóból ötnél a magyar tokenszám a századik tokenig azonos a régi és az új modellgeneráció között, pedig közben teljes architektúraváltások, kontextusablak-bővítések és képességugrások történtek. A gyártók új modellt adnak ki, a szótárat viszont viszik tovább változatlanul. Aki arra vár, hogy majd a következő modellgeneráció megoldja a magyar token-hátrányt, rosszul tervez.

A mezőny egésze sem lett kiegyenlítettebb. A szórás nőtt (46-ról 62 százalékra), a medián gyakorlatilag változatlan (1,64-ről 1,63-ra), és az öt új tokenizáló-család közül az egyik, a Kimi K3, a mezőny leggyengébbje lett 501 tokennel. A Kimi angolul teljesen átlagos, 5,39 karakter/token, magyarul viszont 2,36; ez a legerősebben magyar-specifikus hátrány, amit mértünk.

Az Anthropic tokenizálót cserélt, és rontott

Az egyetlen gyártó, amelyik hozzányúlt a szótárhoz, az Anthropic. A saját árazási dokumentációjuk ezt szó szerint kimondja: a Claude 4.7 és az újabb modellek új tokenizálót használnak, amely ugyanarra a szövegre nagyjából 30 százalékkal több tokent termel. A mi mérésünk ezt számszerűsíti, és hozzátesz egy részletet, amit a gyártó nem bont ki: a többlet nem oszlik el egyenletesen a nyelvek között.

Az új Anthropic-tokenizáló az angolt bünteti jobban. Ennek van egy csapdája, amit érdemes kimondani: a Claude Opus 5 HU/EN aránya (1,63) jobbnak látszik, mint a Claude Haiku 4.5-é (1,86). Ebből könnyű arra jutni, hogy az Opus 5 olcsóbb magyarul. Nem az: a magyar szöveg 25 százalékkal több tokenbe kerül rajta. Az arány csak azért javult, mert az angol viszonyítási alap romlott jobban.

Az Opus 5 magas értékét három, egymástól független módon ellenőriztük, mert egy ilyen kiugró szám elsőre mérési hibának látszik. A marginális teszt 335 tokent adott a kivonással kapott 334 helyett. A szolgáltató rögzítése nem változtatott semmit: az Anthropic first-party és az Amazon Bedrock bitre ugyanazt a 861-es magyar értéket adta. A Claude Haiku 4.5 kontroll-mérése pedig pontosan a korábbi köri számot hozta. A tokenizálóváltás valós.

Mit nem mér ez a szám?

A mérés egy pontbecslés, nem eloszlás, és több ponton törékeny: egy szövegpáron, egyetlen regiszterben, egyetlen napon készült, és csak az inputot nézi. Ezeket a korlátokat végig kell mondani, különben a cikk félrevezető. Ha valaki csak egy dolgot visz el innen, az legyen ez: a tokenizáló-hatékonyság nem azonos a nyelvi minőséggel.

Egyetlen szövegpár, egyetlen regiszter

A mérés egy 1 183 karakteres magyar és egy 1 213 karakteres angol szövegen alapul, üzleti-technikai regiszterben. Nem tudjuk, hogyan viselkedne jogi vagy orvosi szaknyelven, ahol több a ritka, hosszú összetett szó, és ahol az arány valószínűleg romlik. Rövid, beszélt nyelvi chat-üzeneteknél feltehetően javul. Kódot vagy strukturált adatot tartalmazó promptoknál a nyelvfüggetlen részek hígítják az arányt. Egy komolyabb mérés 10-20 szövegpárt használna több regiszterből, és szórást is közölne.

Szolgáltatói variancia, egy megtalált hiba

A Kimi K3-nál két azonos hívás eltérő tokenszámot adott: az egykarakteres alapmérésre előbb 349, majd 311 tokent. A generation-rekordok szerint az OpenRouter routolása különböző szolgáltatókhoz irányította a hívásokat, a Chutes 349-et, a Modal 311-et adott. Nyílt súlyú modellnél ez tipikusan eltérő chat-sablonból vagy Unicode-normalizálásból ered, és ékezetes karaktereknél különösen érzékeny. A modellt ezért a Modal szolgáltatóra rögzítettük, és minden Kimi-mérés ezzel a rögzítéssel futott. A többi tizenegy modellnél az ismételt mérés bitre azonos eredményt adott, a Claude Opus 5-nél két különböző szolgáltatón is.

A fordítás nem semleges

Az angol szöveg fordítás. Egy másik, ugyanolyan hű fordítás lehetne 5-8 százalékkal rövidebb vagy hosszabb, ami közvetlenül eltolja az arányt. Objektív fordítás nem létezik, tehát a mérés már a tokenizáló előtt hordoz nagyjából öt százalék bizonytalanságot.

Amit egyáltalán nem mértünk

• Az outputot nem mértük. A költségpélda azt feltételezi, hogy a magyar output ugyanazzal az aránnyal drágább, mint az input. Ez plauzibilis, hiszen ugyanaz a tokenizáló dolgozik, de nem mért adat.
• A nyelvi minőségről semmit nem mondunk. Lehet, hogy egy modell olcsón tokenizálja a magyart, és közben rosszul beszéli.
• A prompt-cache hatását sem mértük. Cache-elt rendszerprompt mellett a valós költségkülönbség kisebb, mint amit a táblázat mutat.
• Az overhead-kivonás közelítés. Két feltevésen nyugszik: hogy az x payload egy token, és hogy a fix ráfordítás nem függ a payload méretétől. Az elsőt négy modellen validáltuk, a másodikat a Claude Opus 5-nél a marginális teszttel közvetlenül is, a többinél viszont csak közvetve.
• Négy modellnél nem találtunk hivatalos árat, ezért kimaradtak a költségtáblából. A Qwen esetében az Alibaba Cloud dokumentációja listázza a modellt, de token-árat nem közöl; a Meta nem publikál per-token API-árlistát; az NVIDIA modelloldala nem volt lekérhető; a Volcengine árlistája pedig csak bejelentkezés után látszik.

Milyen magyar LLM-benchmarkok léteznek ma?

Három komoly munka van: a HuLU nyelvértési benchmark, az OpenHuEval magyar-specifikus tudásmérése, és a Racka, amely egy magyarra adaptált modellt ír le. Mindhárom pontosságot mér. Egyik sem foglalkozik azzal, hogy a magyar nyelv mennyibe kerül kereskedelmi modelleken, és a kontextusablak-hatással sem.

HuLU

A HUN-REN Nyelvtudományi Kutatóközpont GLUE/SuperGLUE mintájára épült magyar nyelvértési benchmarkja, hat annotált korpusszal (hulu.nytud.hu).

Ez a legalaposabban dokumentált magyar nyelvértési készlet, saját webes kiértékelő szolgáltatással. A gyengesége viszont látszik a táblázatból: hat feladatból öt fordítás, egyedül a HuCoLA eredeti magyar. A fordított benchmarkok jellemzően angolul gondolkodó feladatokat mérnek magyar felszínnel, nem magyar nyelvspecifikus jelenségeket.

A nyilvános eredménylistát nem tudtuk kinyerni: a lap kliensoldalon renderel, a lekérés csak a navigációt adta vissza. Konkrét HuLU-pontszámot ezért csak közvetve, a Racka-cikk táblázatából idézünk lentebb.

OpenHuEval

Magyar nyelvspecifikus és kulturális tudást mérő benchmark, öt feladattal és 3 953 kérdéssel, nyolc dimenzió mentén (arXiv:2503.21500, ACL 2025 Findings).

A legfontosabb eredménye számomra nem a rangsor, hanem egy mellékmondat: a kiértékelt modellek 70 százalékánál megváltozott a sorrend az angol benchmarkokhoz képest. Az angol ranglista tehát nem jósolja meg a magyar teljesítményt. Ez elég erős érv amellett, hogy magyar használatra magyarul kell tesztelni. A szerzők maguk is kezdeti lépésnek nevezik a munkát.

Racka

Az ELTE Digitális Bölcsészet és Mesterséges Intelligencia tanszékeinek munkája, MSZNY 2026 Best Paper (arXiv:2601.01244, a modell: huggingface.co/elte-nlp/Racka-4B). Qwen3-4B backbone, LoRA-alapú folytatólagos előtanítás 160 milliárd subword tokenen, a debreceni Komondor HPC-n, 64 darab A100 GPU-n, 287 órán át. A tokenizálót lecserélték: új BPE-tokenizálót tanítottak magyar korpuszon, majd 32 000 magyar-optimalizált tokent fésültek be az eredeti Qwen3-szótárba.

Ez az egyetlen forrás a háromból, amely a tokenizáló-hatékonyságot közvetlenül méri és számmal közli.

A Qwen3-4B eredeti tokenizálójánál a magyar fertility az angol 1,99-szerese. A magyar-optimalizált szótárral a magyar az angol alá kerül, 1,66 a 1,94-hez, cserébe az angol 23 százalékkal romlik. A modell HuLU-n 0,751 összesítettet ért el a Qwen3-4B 0,711-e ellenében, OpenHuEval-en 33,93-at a 33,44 ellenében.

Ami hiányzik belőle: a fertility-mérés egyetlen modellcsaládra vonatkozik, és a cikk célja a saját adaptáció igazolása, nem a piacon elérhető modellek összevetése. Nincs benne GPT, Claude, Gemini vagy Grok tokenizáló-összehasonlítás, és nincs benne költség. A fertility ott futásidő-argumentum, nem számla.

Hol a rés

A rés tehát elég pontosan körülírható: senki nem méri a magyar nyelv költségét kereskedelmi modelleken, több tokenizáló-családon, összehasonlítható módon. Ez a cikk ezt tölti be, szűken, egyetlen szövegpárral, de valódi méréssel.

Mit kezdj ezzel, ha magyar nyelvű AI-rendszert építesz?

Négy döntésre van közvetlen hatása. A modellválasztásra, a promptok méretére, a gyorsítótárazásra, és arra a ritkább kérdésre, hogy megéri-e magyarra hangolt open-source modellt üzemeltetni. A sorrend nem véletlen: az első kettő ingyen van, a harmadik olcsó, a negyedik drága.

Vedd fel a tokenizáló-hatékonyságot a modellválasztási szempontok közé

Ne a listaárat nézd önmagában, hanem a listaár és a magyar abszolút tokenszám szorzatát. A mérés szerint két modell között 62 százalékos különbség lehet a magyar inputon. Ha a rendszer túlnyomórészt magyar szöveget dolgoz fel, ez a szorzó a valódi ár. Az összehasonlítás egyszerű: küldd át a saját tipikus promptodat két-három modellen, és nézd meg az usage.prompt_tokens értéket.

Fontos fenntartás: ez a szempont a harmadik, nem az első. Ha egy modell olcsón tokenizál, de a feladatodon rosszabbul teljesít, akkor a megtakarítás fedezetlen. A képességet mérd külön, a saját adathalmazodon. Erről bővebben a monitorozásról és debugolásról szóló cikkünkben írtunk.

Tömörítsd a promptot, mert magyarul minden szó drágább

Egy magyar rendszerprompt tokenben másfélszer-kétszer annyiba kerül, mint az angol megfelelője, és körönként újraküldöd. Két gyakorlati fogás segít. Az egyik, hogy a rendszerpromptot angolul írod, a válaszadás nyelvét pedig utasításban kéred magyarul; a modellek ezt megbízhatóan követik, és a fix költség lemegy. A másik, hogy a RAG-ból visszakeresett részleteket keményebben vágod: nyolc helyett négy chunk, rövidebb ablakkal.

Ez a második pont nem ingyen van. A visszakeresett kontextus csökkentése rontja a pontosságot, ha a chunkolás rossz. Erről a RAG-rendszerekről szóló cikkben van részletes leírás.

Cache-eld a fix részt

A rendszerprompt és az állandó példák minden körben ugyanazok. A nagy szolgáltatók prompt-cache-e ezt a részt töredékáron számolja, és magyar szövegnél éppen ezért nagyobb az abszolút megtakarítás: a drágább rész az, ami ismétlődik. A cache hatását nem mértük, tehát számot nem írok ide, de a mechanizmus egyértelmű.

Mikor éri meg magyarra hangolt open-source modell?

A Racka-adat alapján a magyar tokenszám közel felére csökkenthető magyar-optimalizált szótárral. Ez arányos prefill-gyorsulást és kontextus-nyereséget hoz. Ugyanakkor elveszíted a frontier modellek képességeit, az angol romlik, és be kell vállalni a GPU-üzemeltetést.

A saját tapasztalatunk szerint ez akkor jön ki, ha a feladat szűk (egy osztályozás, egy kivonatolás, nem általános asszisztens), a forgalom nagy és túlnyomórészt magyar, és van adatrezidencia-kényszer, ami amúgy is saját vasat indokol. Ha a három közül csak egy teljesül, maradj API-n. A lokális futtatás gyakorlati oldaláról a lokális AI futtatásról szóló cikkünk szól, a három megvalósítási réteg költségösszevetése pedig az AI chatbot, n8n és egyedi ügynök összehasonlításban van.

Összegzés és gyakori kérdések

Források

• Saját mérés, AppForge, 2026-08-14, OpenRouter API-n keresztül. A natív tokenizálóval számolt token-értékekről: openrouter.ai/docs/api_reference/overview.
• Anthropic árazás és a tokenizálóváltás megerősítése: platform.claude.com/docs/en/about-claude/pricing. További hivatalos árlisták: OpenAI, Google, xAI, DeepSeek, Moonshot, Mistral, Upstage.
• Forintárfolyam, 2026-08-14, 314,36 Ft/USD: mnb.hu/en/arfolyamok.
• HuLU benchmark és feladatleírások: hulu.nytud.hu és hulu.nytud.hu/tasks.
• OpenHuEval, ACL 2025 Findings: arxiv.org/html/2503.21500v1.
• Racka, MSZNY 2026 Best Paper: arxiv.org/abs/2601.01244; a modell: huggingface.co/elte-nlp/Racka-4B.

Ha magyar nyelvű AI-rendszert terveztek, és a modellválasztásnál a költség is szempont, nézd meg a magyar MI-fejlesztési árakról szóló cikket, vagy a folyamatautomatizálás szolgáltatásunkat. A mérés nyers naplóját és a generation ID-ket megőriztük; ha valaki reprodukálni akarja és eltérő számot kap, szívesen összevetjük.