A magyarországi vállalati finomhangolás tipikus induló költségsávja 1,5–4 millió forint egy pilot projektnél, közepes komplexitású termelési bevezetésnél 8–20 millió forint, míg szabályozott, nagy volumenű vállalati rendszereknél 25 millió forint felett is lehet a végösszeg. A pontos szám három dologtól mozog leginkább: a modell méretétől és a szükséges GPU‑óráktól, az adatok minőségétől és mennyiségétől, valamint attól, hogy a rendszer az EU AI Act szerint magas kockázatú kategóriába esik‑e.

A sávokat alapvetően ez a négy feltétel mozgatja:

  • A modell mérete és a választott módszer: teljes finomhangolás vagy LoRA/PEFT‑alapú adaptáció.
  • Az adatelőkészítés és annotáció mennyisége, illetve az emberi validálás igénye.
  • A megfelelőségi és auditálási követelmények szintje (különösen jogi, pénzügyi, egészségügyi felhasználásnál).
  • Az üzemeltetés és a folyamatos monitoring terjedelme az élesítés után.

Profi tipp: Mielőtt bármilyen árajánlatot elfogadna, kérjen egy külön tételezett bontást compute‑, adatmunka‑ és megfelelőségi költségekre. Ha egy szállító csak egy kerek összeget ad, az általában azt jelenti, hogy nem végzett részletes felmérést.

Ha nem biztos abban, hogy a cégének valóban finomhangolásra van szüksége, vagy egy egyszerűbb megoldás is elég lenne, egy rövid Stratify audit tisztán megmutatja a reális költségstruktúrát, mielőtt bármilyen szerződést aláírna.

Fő tanulságok

A finomhangolás költségét Magyarországon nem a modell mérete önmagában, hanem az adatminőség, a compliance‑igény és a fenntartási terhelés együttese határozza meg.

Pont Részletek
Költségsávok Pilot 1,5–4 millió, mid‑tier 8–20 millió, vállalati projekt 25 millió forint felett várható.
Adatmunka dominál Az adatelőkészítés és annotáció a teljes büdzsé 35–50%-át teheti ki, ne becsülje alá.
LoRA olcsóbb út A LoRA/PEFT jelentősen csökkenti a compute‑költséget teljes finomhangoláshoz képest.
Fenntartás a valódi TCO Éves karbantartásra érdemes az építési költség 15–30%-át tartalékolni compliance és monitoring miatt.
Stratify szerepe A Stratify discovery workshopon méri fel, megéri‑e finomhangolás vagy elég egy RAG‑alapú hibrid megoldás.

Tartalomjegyzék

Mi a finomhangolás, és miben más, mint a RAG?

A finomhangolás egy nyelvi modell belső súlyainak módosítása saját céladatokkal, hogy a modell konzisztensen a kívánt stílusban, szakterminológiával és formátumban válaszoljon. Ez alapvetően különbözik a prompt engineeringtől, ahol a modell változatlan marad, csak az utasítást finomítják, valamint a RAG‑tól is, ahol a modell külső tudásbázisból kérdez le friss információt válaszadás előtt.

Három fő technikai megközelítés létezik, és ezek költsége jelentősen eltér egymástól:

  • Teljes finomhangolás: a modell összes vagy nagy részének súlyait módosítja, ez a legdrágább és leginkább compute‑igényes megoldás.
  • LoRA/PEFT (Low‑Rank Adaptation): csak kis, hozzáadott paramétercsoportokat tanít, drasztikusan csökkentve a GPU‑szükségletet és a tréning idejét.
  • Soft prompt tuning: tanulható bevezető tokeneket illeszt a bemenethez a modell súlyainak érintése nélkül, a legolcsóbb és leggyorsabb opció.

A finomhangolás és a RAG a gyakorlatban nem versenytársak, hanem kiegészítik egymást: a RAG a naprakész, ellenőrizhető tudásért felel, a finomhangolás pedig a modell stílusát és rögzített kimeneteit rögzíti. Sok projekt éppen ezért RAG‑gal kezdődik, és csak később egészül ki finomhangolással, amikor a stílus vagy a formátum konzisztenciája már üzletileg kritikus.

Tipikus üzleti helyzetek, ahol a finomhangolás önmagában is megtérülhet: erősen szaknyelvi terület (jogi szerződések, orvosi dokumentáció), szigorú kimeneti formátum (strukturált jelentések, számlaadat‑kinyerés), vagy olyan pontossági igény, ahol a promptolás önmagában nem elég stabil.

Mely tényezők határozzák meg a finomhangolás árát?

A végösszeg valójában hat‑nyolc különálló költségtételből áll össze, és ezek aránya projektenként nagyon eltérő lehet.

A finomhangolás költségeit bemutató ábra

Compute és modellválasztás

A GPU‑órák ára a legkézzelfoghatóbb tétel, de nem feltétlenül a legnagyobb. Egy kisebb, nyílt forráskódú modell finomhangolása töredéke annak, mint egy nagy, zárt modell teljes retrainingje. A LoRA/PEFT módszerek itt hozzák a legnagyobb megtakarítást, mert a tanítandó paraméterek száma akár tizedére csökkenhet a teljes finomhangoláshoz képest.

Adatelőkészítés és annotáció

Ez az a tétel, amit a legtöbb büdzsé alábecsül. Iparági referenciák szerint az adatelőkészítés és adatminőség a teljes projektköltség 35–50%-át teheti ki, beleértve a tisztítást, deduplikációt, címkézést és a peremhelyzetek lefedését. Az adatminőség önmagában is meghatározza az eredmény nagy részét: az adatminőség a modell teljesítményének akár 80%-át befolyásolja, ezért egy olcsó, gyenge adatkészlettel végzett finomhangolás sokszor rosszabb eredményt hoz, mint egy jól megtervezett RAG‑rendszer.

Kezek, amelyek adatjelölési feladatokat végeznek különböző eszközökön

Az emberi validálás (human‑in‑the‑loop) külön tétel: egy szakértő annotátor óradíja és a szükséges mintaszám gyorsan felfuthat, különösen jogi vagy orvosi szövegeknél, ahol nem elég egy általános felhasználó jóváhagyása.

Tárolás, index és üzemeltetés

Ha a rendszer RAG‑összetevőt is tartalmaz, a vektorindexek tárolása és a rendszeres újra‑embedding komoly, folyamatos tétel. A modell élesítése után jön a monitoring, a naplózás és a regressziós tesztelés, amelyek nélkül nem lehet észrevenni, ha a modell teljesítménye idővel romlik.

Egy kéz éppen AI szerverek hardverét karbantartja a rack szekrényben.

Compliance és jogi audit

Az EU AI Act 2026‑os szabályozási fejleményei miatt a magas kockázatú felhasználási területeken a dokumentáció és a megfelelőségi audit már nem opcionális kiegészítő, hanem beépített költségtétel. Ez különösen igaz olyan szektorokban, mint a pénzügy, az egészségügy vagy a HR‑döntéstámogatás.

Profi tipp: A LoRA/PEFT általában akkor éri meg jobban, ha a feladat viszonylag szűk (egy dokumentumtípus, egy hangnem), és a modellnek nem kell alapvetően új képességeket tanulnia. A teljes finomhangolás csak akkor indokolt, ha a feladat komplexitása vagy a pontossági küszöb ezt egyértelműen megköveteli, és a projekt élettartama hosszú, mert az extra compute‑költség csak sok iteráción keresztül térül meg.

Mennyibe kerül egy pilot, egy termelési és egy vállalati projekt?

A finomhangolási projektek költsége nem egy szám, hanem egy sáv, amely a projekt méretével és kockázati szintjével nő. Íme egy reális bontás magyar vállalati kontextusban:

  1. Pilot / prototípus (1,5–4 millió forint): egy szűk feladatra optimalizált LoRA‑alapú finomhangolás, korlátozott adatkészlettel, néhány hetes discovery és tréning fázissal.
  2. Termelésbe lépő mid‑tier projekt (8–20 millió forint): nagyobb adatkészlet, alaposabb annotáció, integráció meglévő rendszerekkel, folyamatos monitoring beépítve.
  3. Vállalati / magas kockázatú projekt (25 millió forint felett): teljes megfelelőségi dokumentáció, auditálhatóság, rollback‑mechanizmusok, és gyakran több iteráció párhuzamos validálással.

Az idővonal jellemzően négy fázisra bomlik: discovery és igényfelmérés (1–2 hét), adatmunka (2–6 hét, a mennyiségtől függően), tréning és validálás (1–3 hét iterációnként), majd élesítés és stabilizálás (2–4 hét). Egy közepes projektnél két‑három iterációra kell számítani, mielőtt a modell eléri a kívánt pontossági szintet.

Ez összesen 3,3–5,2 millió forintos végösszeget ad egy realisztikus mid‑tier projektre.

Az árazási modell is befolyásolja, mit fizet ki valójában:

  • Fix áras pilot: kiszámítható, jó kezdő projektekhez, de kevésbé rugalmas, ha közben változik a scope.
  • Óradíjas (time & materials): rugalmasabb, komplex vagy iteratív projekteknél gyakori, de nehezebb előre tervezni a végösszeget.
  • Output‑alapú: a szolgáltató a leszállított teljesítményhez (pl. pontossági küszöb eléréséhez) köti a díjat, ritkább, de erősen ösztönzi a minőséget.

Hogyan csökkentheti a költségeket teljesítményvesztés nélkül?

A legtöbb megtakarítás nem a minőség feláldozásából jön, hanem abból, hogy a megfelelő architektúrát választja a feladathoz.

A LoRA/PEFT alkalmazása az első és legkézenfekvőbb lépés: kisebb paraméterhalmazt tanít, így kevesebb GPU‑órát igényel, és gyorsabban iterálható. Nem ajánlott viszont, ha a feladat alapvetően új tudást vagy komplex viselkedésváltozást igényel a modelltől, mert ilyenkor a korlátozott paraméterszám gátat szab a tanulásnak.

A RAG és a finomhangolás hibrid használata sokszor a legjobb költség‑érték arányt adja. Kezdje RAG‑gal, ha a fő probléma a naprakész vagy vállalat‑specifikus tudás hiánya, ez olcsóbban validálja az üzleti értéket, mielőtt drágább finomhangolásba invesztálna. Csak akkor forduljon finomhangoláshoz, ha a RAG‑rendszer már működik, de a kimenet stílusa, formátuma vagy tónusa nem konzisztens.

Prompt caching és intelligens routing további réteget adhat: a gyakran ismétlődő rendszerkérdéseket gyorsítótárazza, a egyszerűbb kéréseket pedig kisebb, olcsóbb modellekre irányítja, csak a valóban komplex eseteket küldve a nagy modellhez.

A modellválasztás maga is költségtényező: egy kisebb modell elsődleges forrásként, és egy nagy modell csak a legspeciálisabb esetekre fenntartva, jelentősen csökkentheti a havi futtatási költséget anélkül, hogy a felhasználói élmény romlana.

Automatizált értékelési hurkok beépítése (mérőszámok, regressziós tesztek minden iteráció után) segít kiszűrni a rossz irányba induló tréningeket, mielőtt azok drága GPU‑órákat égetnének el feleslegesen.

Profi tipp: Építsen validációvezérelt iterációs ciklust: minden tréningkör előtt definiáljon konkrét, mérhető sikerkritériumot, és csak akkor engedje tovább a következő, drágább lépésre a projektet, ha az előző kör elérte a küszöböt. Ez megakadályozza, hogy feleslegesen sok GPU‑órát öljön egy rossz irányba tartó modellverzióba.

Miért nő meg a hosszú távú fenntartás költsége?

A finomhangolás valódi költsége ritkán ér véget az élesítéssel. A teljes birtoklási költség (TCO) jelentős részét a folyamatos fenntartás teszi ki, nem a kezdeti build.

Az AI förordningen – TrustView által vázolt EU AI Act magas kockázatú rendszerekre vonatkozó előírásai dokumentációt, nyomon követhetőséget és rendszeres auditot követelnek, ez magyar vállalatoknál különösen érinti a pénzügyi, jogi és HR‑döntéstámogató alkalmazásokat. A GDPR és az adathelyzeti (data residency) követelmények is befolyásolják a tárolási és üzemeltetési árat, mert az EU‑n belüli, auditálható infrastruktúra jellemzően drágább, mint egy általános felhőmegoldás.

Egy mesterséges intelligenciával működő létesítményben éppen a megfelelőségi audit beállításait végzik kézzel.

Az observability, a rendszeres regressziós tesztelés és a folyamatos teljesítményértékelés önálló, visszatérő tétel. Iparági referenciák szerint az éves karbantartás jellemzően az eredeti építési költség 15–30%-a, ezért a büdzsében érdemes évente legalább 15–20%-os karbantartási tartalékot elkülöníteni a kezdeti build költségéből.

Szabályozott területeken az emberi felügyelet (HITL) sem opció, hanem gyakran kötelező elem: jogi, pénzügyi vagy egészségügyi döntéstámogató rendszereknél a modell kimenetét ember hagyja jóvá, mielőtt az ténylegesen hatással lenne egy ügyfélre vagy döntésre. Ez állandó, futó költség, nem egyszeri kiadás.

Ha a rendszer RAG‑komponenst is használ dinamikusan bővülő tudásbázissal, a vektorindex karbantartása és az időszakos újra‑embedding külön, rendszeresen visszatérő tétel, amelyet sok kezdeti büdzsé egyáltalán nem tartalmaz.

Hogyan tervezze meg a finomhangolási büdzséjét?

A jó költségvetés nem egy szám, hanem egy tételezett lista, amit vendorral szemben is meg lehet védeni.

Az alap checklist ezekre a sorokra bomlik:

  • Discovery és igényfelmérési díj (jellemzően külön tétel, nem a fő projektben elrejtve).
  • Adatelőkészítésre és annotációra elkülönített, önálló sor, nem beolvasztva a “fejlesztés” tételbe.
  • Tréning és compute költség, modellméret és módszer (LoRA vs teljes finomhangolás) szerint bontva.
  • Integrációs és tesztelési díj, beleértve a meglévő rendszerekhez való kapcsolódást.
  • Üzemeltetési és monitoring díj havi vagy éves szinten.
  • Compliance és auditálási tartalék, különösen magas kockázatú felhasználásnál.

Mielőtt aláír egy szerződést, tegyen fel konkrét kérdéseket a szállítónak:

  1. Reprodukálható‑e az eredmény, vagyis ugyanaz az adat és paraméterezés újra lefuttatva hasonló teljesítményt ad‑e?
  2. Van‑e verziókezelés a modellekhez, és milyen a rollback folyamat, ha egy új verzió rosszabbul teljesít?
  3. Milyen audit trail készül minden tréning körről, és ki fér hozzá?
  4. Milyen SLA‑k vonatkoznak az üzemeltetésre, és mi történik, ha a teljesítmény romlik idővel?

Piros zászlók, amikre érdemes figyelni: ha a szállító nem tud konkrét mérőszámokat mutatni a korábbi projektjeiből, ha a költségtételek átláthatatlanok egy kerek összeg mögött, vagy ha nincs semmilyen megfelelőségi dokumentáció felkínálva magas kockázatú felhasználásnál. A rejtett integrációs és változásmenedzsment költségek gyakran pont ezeknél a hiányosan tervezett projekteknél ütik be a legnagyobbat.

A szerződéses modell választása is stratégiai döntés: fix áras pilot akkor jó, ha a scope jól körülhatárolt és rövid az időtáv, míg time & materials modell akkor előnyösebb, ha a projekt komplexitása vagy az adatminőség még bizonytalan a kezdéskor.

Hogyan számoltuk a becsléseket?

A számítás nem egyetlen szállító árlistáján alapul, hanem több nyilvános iparági referencia összevetésén.

A finomhangolás valódi költsége ott derül ki, ahol a legtöbb büdzsé nem néz: az adatmunkában és a fenntartásban, nem a tréning egyszeri díjában.

A Stratify ezt a fajta strukturált, tételezett tervezést kínálja minden AI‑projekt discovery fázisában, a módszertana átláthatóan bemutatja, mely paraméterekre épül egy‑egy becslés.

Miért éri meg üzletileg megfontoltan közelíteni a finomhangolást?

A legnagyobb hiba, amit magyar cégek elkövetnek, hogy a finomhangolást választják első lépésnek, mielőtt validálták volna, hogy a probléma tényleg ezt igényli. Stratify tapasztalata szerint a legjobb út: MVP egyszerű prompttal, majd RAG a naprakész tudásért, csak ezután validálás valós használati adatokkal, és finomhangolás csak akkor, ha a stílus vagy formátum konzisztenciája bizonyítottan üzleti értéket ad.

Az első 30 napban a döntéshozónak egy dolgot kell tisztáznia: mi az a konkrét, mérhető probléma, amit a jelenlegi megoldás nem old meg jól? a következő hónapban pedig egy olcsó, gyors pilotot kell futtatni, mielőtt bármilyen nagyobb finomhangolási büdzsét jóváhagyna.

Hogyan segít a Stratify a költségbecslésben?

A Stratify pontosan azért létezik, hogy magyar KKV‑k és középvállalatok ne találgatással, hanem tételezett, ellenőrizhető számokkal tervezzék meg az AI‑projektjeiket. Ahelyett, hogy egy technológiát próbálna rájuk erőltetni, a cég a business problémából indul ki, és onnan bontja le, hogy finomhangolás, RAG vagy egy egyszerűbb workflow automatizáció adja‑e a legjobb megtérülést.

Stratify

Egy discovery workshop keretében a Stratify feltérképezi a konkrét use case‑t, megbecsüli a compute, adatmunka és compliance tételeket, és megmutatja, hol lehet reálisan spórolni anélkül, hogy a projekt kockázata megnőne. Ha most tervezi az első AI‑finomhangolási projektjét, vagy csak ellenőrizni szeretné egy meglévő ajánlat reálisságát, kérjen egy személyre szabott árajánlatot a Stratify AI‑tanácsadási szolgáltatásainak áttekintése után.

Források

Gyakran ismételt kérdések

Mennyi idő alatt térül meg egy finomhangolási projekt?
A megtérülés a use case‑től függ, de egy jól validált, szűk feladatra optimalizált pilot projekt 3–6 hónapon belül mérhető hatékonyságnövekedést hozhat, ha a kiindulási probléma valóban jelentős, ismétlődő munkaterhet jelentett.

Mindig szükség van finomhangolásra, ha RAG‑ot már bevezettünk?
Nem feltétlenül. Ha a RAG‑rendszer már jól válaszol tartalmilag, de a stílus vagy formátum nem konzisztens, akkor éri meg finomhangolást hozzáadni. Ha a fő probléma a tudás hiánya, elég egy jobban megtervezett RAG‑index.

Mekkora kockázatot jelent az EU AI Act a költségekre?
Alacsony kockázatú felhasználásnál minimális a hatás, de magas kockázatú területeken (pénzügy, egészségügy, HR‑döntések) a dokumentáció és audit jelentős, folyamatos költségtétel, amit már a tervezés elején be kell kalkulálni.

Mi a legnagyobb rejtett költség a finomhangolásnál?
Az adatelőkészítés és annotáció, valamint az élesítés utáni monitoring és karbantartás. Ezeket a tételeket a legtöbb kezdeti árajánlat alábecsüli vagy egyáltalán nem tartalmazza.

Mennyivel olcsóbb a LoRA a teljes finomhangolásnál?
A pontos arány modellenként változik, de a LoRA/PEFT jellemzően jelentősen kevesebb GPU‑órát igényel, mert csak egy kis paraméterhalmazt tanít a modell teljes súlykészlete helyett.

Ajánlott

Tags: