Kiindulás
Pythonban tanulunk, Rustban fizetünk
Aki ma AI-t tanul, szinte mindent Pythonban ér el. A tananyagok, a példakódok, a modellkönyvtárak és a kísérletező füzetek mind Pythonban készülnek, és ez jól is van így, mert ebben a nyelvben a legrövidebb az út egy ötlettől a futó próbáig. Közben viszont azt látom, hogy a modelleket építő és működtető cégek a kódjuk egy részét csendben átköltöztetik Rustba. Ez a rész a teljes kódnak csak egy jól körülhatárolt szelete, de olyan szelete, amin a cég minden egyes kérésnél fizet.
Ezt a szeletet hívom forró útnak. A forró út az a kódrész, ami minden egyes kérésnél lefut. Ha egy rendszerbe másodpercenként ezer kérdés érkezik, a forró út ezerszer fut le másodpercenként, ugyanazokkal a lépésekkel, és minden lefutása processzoridőbe és memóriába kerül. A döntés erről a rétegről ezért a havi felhőszámlán dől el, és a cégek emiatt költöztetik, nem nyelvi meggyőződésből. A Rust körül van ugyan rajongás is, de ami a nagy modellszolgáltatóknál történik, az egyszerű költségdöntés, és ugyanez a döntés egy közepes magyar cégnél is ugyanúgy megállja a helyét.
Egy példa
Mi történik, mielőtt a modell egyáltalán olvasna
A modell nem szöveget olvas, hanem számokat. Ezért a beérkező kérdést előbb kis darabokra kell vágni, és a darabokat számokra kell fordítani. Ezek a darabok a tokenek, a vágást pedig tokenizálásnak hívják. Maga a lépés aprócska. Pár szabály, pár keresés egy táblában, pár összefűzés, és kész. Pythonban le lehet írni néhány tucat sorban, és aki elsőre látja, az is megérti, mi történik benne.
A gond akkor kezdődik, amikor ugyanaz a pár művelet milliószor fut le egymás után. A Python minden lépésnél futás közben dönti el, mivel is dolgozik éppen, és ez a döntés egyenként semmi, milliószor viszont már mérhető idő. Ha másodpercenként ezer kérdés érkezik, a vágás ezer kérdésen fut le, mindig ugyanazzal a pár művelettel, nagyon sokszor. Az ilyen munka a Pythonnak nem fekszik, bármilyen kényelmes is leírni benne.
Az OpenAI tokenizálója Rustban van megírva, mellé azért közzétettek egy egyszerű, tanító célú Python változatot is, úgyhogy a kettő egy laptopon összemérhető. Ezer kérdés felvágása a Python változatnak körülbelül egy tized másodpercbe telt, a Rust változatnak körülbelül öt ezred másodpercbe, ami több mint hússzoros különbség. A programozó ettől még Pythonból hívja a tokenizálót, egy sorral, ahogy eddig. A munka viszont lefordított Rust kódban fut, nagyjából C++ sebességgel. Kívülről semmi nem változott, a számla alján viszont igen.
A kézenfekvő ellenvetés
Ha a C++ ugyanilyen gyors, miért nem az a válasz
A C és a C++ évtizedek óta ott van, és sebességben nem marad el a Rusttól. A különbség a memóriabiztonságban van. Ezek a nyelvek teljes kontrollt adnak a memória fölött, és ezzel a hibázást is könnyűvé teszik. A tipikus eset az, amikor a program visszaad egy memóriaterületet, majd később tévedésből újra használja ugyanazt. Ennek a hibának use after free a neve, és két kimenetele van. Vagy összeomlik tőle a program, vagy egy támadó tud rajta keresztül saját kódot futtatni a mi gépünkön.
A Microsoft és a Chrome fejlesztőcsapata pár évvel ezelőtt egymástól függetlenül arról számolt be, hogy a súlyos biztonsági hibáik körülbelül hetven százaléka memóriakezelési hiba volt. Két, egymástól teljesen eltérő kódbázis, nagyjából ugyanaz az arány. Aki ma egy AI rendszert üzemeltet, az ugyanezekkel a nyelvekkel ugyanezt a kockázatot vállalná a forró útján, ott, ahol a legtöbb külső, ellenőrizetlen adat áramlik be a rendszerbe.
A megoldás
Takarítás szemétgyűjtő nélkül
A Java és a Go a legtöbb ilyen hibát úgy kerüli el, hogy futás közben megkeresi és felszabadítja a már nem használt memóriát. Ez a szemétgyűjtés, és jól működik, csak éppen a takarítás külön processzoridőbe kerül, ráadásul olyan pillanatokban is elindul, amikor a programnak éppen válaszolnia kellene. Egy válaszadó rendszernél ez a szünet a felhasználónak várakozásként jelenik meg, az üzemeltetőnek pedig plusz gépként, mert a forgalmi csúcsot a takarítással együtt kell kibírnia.
A Rust máshogy fogja meg a problémát. Minden adatnak egyetlen birtokosa van, és amikor a birtokos végzett, a Rust magától felszabadítja a memóriát, szemétgyűjtő nélkül. Az ellenőrzés pedig még indulás előtt zajlik. A fordító végigvizsgálja a programot, és megnézi, hogy semmi nem használ felszabadított memóriát. Ha mégis talál ilyet, nem építi meg a programot. Ezt az ellenőrzést hívják borrow checkernek, és az első hetekben mindenki szidja, aki Rustot tanul, mert olyan hibákért küldi vissza a kódot, amiket más nyelv szó nélkül átenged. Ugyanez az első hetekben idegesítő tulajdonság az, ami éles üzemben éjjel két órakor nem hívja fel az üzemeltetőt.
Ügynökök
Amikor a kódot már nem ember írja
Ennek most külön haszna van, mert egyre több kódot AI ügynökök írnak. Egy ügynök gyorsan ír, és ugyanolyan magabiztosan írja le a hibás sort, mint a jót. Ha C-ben írja meg a programot és beleír egy use after free hibát, a C fordító szó nélkül lefordítja, a hiba pedig csak futás közben jön elő, jó eséllyel éles környezetben, egy olyan bemenetnél, amire senki nem gondolt.
Rustban ugyanez máshogy zajlik. A borrow checker nem építi meg a programot, és kiírja, melyik sor melyik szabályt szegte meg. Az ügynök ezt a hibaüzenetet elolvassa, kijavítja a sort, és újra próbálja, akár többször is, emberi beavatkozás nélkül. A hibák egy egész osztálya így kiesik, mielőtt a kód egyáltalán elindulna. A Rust sem fog meg minden hibát, a logikai tévedést vagy a rossz üzleti szabályt ugyanúgy átengedi, ezt az egy osztályt viszont megbízhatóan megfogja, és ez az osztály eddig a legdrágább hibák közé tartozott.
Ez ugyanaz az elv, amiről a loop engineering kapcsán is írtam. Az ügynök annyit ér, amennyi gépi olvasható visszajelzést kap a saját munkájáról. A szigorú fordító, a tipizált séma, a futó teszt és a linter mind ilyen visszajelzés, és ezek közül a fordító szól a leghamarabb, még azelőtt, hogy bármi lefutott volna. Aki ügynökökkel akar kódot íratni, annak a nyelv választása ezért visszajelzési kérdés is, nem csak sebességkérdés.
Egy mérés
Két mérnök, egy negyedév, egy tároló szolgáltatás
Az OpenAI mérnöki blogja szerint két mérnök a Codex és a GPT-5.5 segítségével 2026 második negyedévében átírta Pythonból Rustba a ChatGPT mögötti tároló szolgáltatást, amit ők Habitatnak hívnak. A jelentés szerint a Rust változat körülbelül hatszor kevesebb processzoridőt és tizenötször kevesebb memóriát használ, és ma már ez viszi a termelési forgalom túlnyomó részét.
Két dolgot olvasok ki ebből. Az egyik, hogy az átírást két ember végezte egy negyedév alatt, ügynökökkel a kezük alatt, és a fordító ugyanúgy visszajelzést adott az ügynököknek, ahogy fent leírtam. A másik, hogy a nyereség azon a két tételen jelent meg, amiért egy felhőszolgáltatónak fizetni kell, processzoridőben és memóriában. Akkora forgalomnál, amekkora a ChatGPT mögött van, ez a két szám önmagában elmondja, miért éri meg ennek a rétegnek a költöztetése.
Ügyfélpélda
A számla nem onnan nőtt, ahonnan várták
Egy debreceni gépalkatrész nagykereskedőnél tavaly építettünk egy belső AI megoldást, ami a beérkező ajánlatkéréseket olvasta végig, kikereste belőlük a cikkszámokat, és előkészítette a választ az értékesítőknek. A pilot alatt a számla barátságos volt, a kollégák szerették, úgyhogy a cég kiterjesztette az összes bejövő csatornára. Pár hónap után a pénzügyi vezető azzal keresett meg, hogy a felhőszámla a többszörösére nőtt, és a cégnél mindenki a modellhívásra gyanakodott, mert az látszott a legdrágább tételnek.
Amikor szétszedtük a költséget, a modellhívás a növekedés kisebb részéért felelt. A nagyobb rész a modell körül futó előkészítő kódból jött. Minden ajánlatkérésnél ugyanaz a lánc futott le, a mellékletek kibontása, a szöveg tisztítása, a cikkszámok kiszűrése reguláris kifejezésekkel, a darabolás, majd az összevetés egy több százezer soros törzsadattal, végig Pythonban, és ez a lánc annyi processzoridőt és memóriát evett, hogy a nagykereskedőnek egyre nagyobb gépeket kellett bérelnie alá. Ez volt a forró út, és senki nem nézett rá, mert mindenki a modellre figyelt.
A megoldás a mérésnél kezdődött, nem a modellnél. Megnéztük, melyik lépés mennyi időt visz egy kérésen, és kiderült, hogy a lánc két lépése adja a futásidő nagy részét. Ezt a két lépést írtuk át lefordított kódra, a többi maradt Pythonban, ahogy volt. A kód túlnyomó részéhez hozzá sem nyúltunk, a gépméretet viszont vissza lehetett venni, és a számla visszaállt egy olyan szintre, amit a pénzügyi vezető már aláír. A kereskedőnél ugyanaz jött ki, mint a nagy modellszolgáltatóknál, csak kisebb léptékben. A nyelvet nem kellett lecserélni, azt a pár százalékot kellett megtalálni, ami minden kérésnél lefut.
Vezetői olvasat
Két réteg, két döntés
Ha egy vezető ebből azt szűri le, hogy át kell írni a kódbázist Rustba, akkor rossz helyen kezdi. Két réteg van, és a kettőre más szabály vonatkozik. Az egyik réteg az, ahol naponta változik a kód, ahol kísérleteznek, promptot hangolnak, új adatforrást kötnek be. Ott a Python gyorsabb munkát ad, a fejlesztő estére lát eredményt, és a nehéz matematika amúgy is a GPU-n fut, nem a Python kódban. A másik réteg az, ahol minden egyes kérésnél ugyanaz a pár művelet fut le. Ott a nyelv választása közvetlenül a számlán jelenik meg, processzoridőben és memóriában, és minden kérés annyival drágább, amennyivel a lassabb kód többet eszik.
A kettő elválasztásához mérés kell, nem vélemény. Azt tapasztalom, hogy a cégek többségénél a forró út a teljes kódbázis pár százaléka, és ezt a pár százalékot az emberek ritkán találják el ránézésre. A profilozó eszköz egy délelőtt alatt megmutatja, és utána már tényekről lehet dönteni arról, mi érdemel lefordított kódot, és mi maradjon úgy, ahogy van. Aki ezt a lépést kihagyja, az vagy feleslegesen ír át olyan kódot, ami hetente változik, vagy futtatja tovább a drága részt, és a felhőszolgáltatónak fizeti ki a különbséget hónapról hónapra.
Aki pedig AI-t tanul, annak a Python marad a válasz, ahogy eddig. A Rust az üzemeltetés egy szűk, forró szeletének a nyelve, és a két réteg közt a határ ott húzódik, ahol a kód abbahagyja a változást, és elkezdi a pénzt költeni.
Ez az írás egy Rust és AI témájú oktatóvideó feldolgozásából készült, a tokenizálási mérés, a memóriakezelési hibaarányok és a borrow checker leírása onnan származik. A tároló szolgáltatás átírásának számai az OpenAI mérnöki blogjából valók, az ügyfélpélda és a vezetői olvasat a saját tapasztalatom.