Egy nyílt súlyú LLM saját üzemeltetése vs. egy API: a valós költségmatek

A terméked kikerül, meghív egy LLM API-t, és a számla hónapról hónapra kúszik felfelé. Így megteszed azt, amit végül minden fejlesztő megtesz: nyitsz egy új lapot, és eltűnődsz, vajon olcsóbb lenne-e egy GPU-t bérelni és magad futtatni a Llamát.

A saját LLM-üzemeltetés költségének kérdésére van válasz, de az nem az az egyetlen szám, amelyet a legjobb keresési találatok és az AI Overview-k folyton ismételgetnek. Három dologtól függ, amelyeket azok a cikkek elsimítanak: melyik API-hoz hasonlítasz, mennyire foglalt a GPU-d, és az az üzemeltetési költség, amit senki sem tesz bele a táblázatba.

Íme a rövid változat a részletek előtt: a legtöbb egyszemélyes fejlesztő számára a saját üzemeltetés jelenleg nem nyer költségen. De van egy konkrét vonal, ahol ez megfordul, és ezt körülbelül két perc alatt kiszámolhatod a saját számládon. Alább a 2026-os matek (aktuális árak, VRAM-számok modellenként, és egy képlet, amit lefuttathatsz).

A rövid verzió

• A megtérülési pont nem egyetlen szám. Három, attól függően, melyik API-hoz hasonlítasz. Egy frontier API-val szemben (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro) a saját üzemeltetés térül meg a leghamarabb. Egy olcsó, nyílt súlyú API-val szemben (DeepSeek, DeepInfra, Together, nagyjából $0.14–$0.50 millió tokenenként) szinte soha nem nyer pusztán költségen.
• A kihasználtság az a szorzó, amely megöli az egyszemélyes esetet. Egy bérelt GPU ugyanannyiba kerül üresjáratban, mint teljes terhelésen, így egy 10%-os kihasználtságon futó GPU tokenenként nagyjából 10×-esébe kerül annak, mint teljes terhelésen. A hullámzó egyszemélyes munkaterhelések alapból alacsony kihasználtságon ülnek.
• A megtérülési pont alatt a költségnyereség általában egy olcsó, nyílt súlyú API-ra váltás, nem a saját üzemeltetés. A saját üzemeltetés akkor téríti meg magát, amikor a frontier árazással szembeni tartós volumen átlépi a vonalat 60%+ kihasználtságnál, vagy amikor van egy nem költségalapú okod (adatvédelem, késleltetés, finomhangolási kontroll).
• Futtasd le a képletet a saját számaidon, mielőtt bármit bérelnél. Megtérülési tokenek ≈ GPU VPS havi költsége ÷ a kevert API-árad tokenenként.

Amit ez nem fed le

• Több csomópontos vagy adatközpont-léptékű GPU-fürtök. Ez egy egyszemélyes költségdöntés, nem egy flotta.
• A finomhangolás gazdaságtana mélyebben (külön számítás, saját kompromisszumokkal).
• Egy lépésről lépésre Ollama-vs-vLLM beállítási oktatóanyag. A hatókör itt a pénzkérdés, nem a telepítés.
• A saját tulajdonú hardver mint elsődleges eszköz. A feltételezés végig egy bérelt GPU, mivel ez a reális út egy olyan fejlesztő számára, akinek nincs már egy GPU az asztalán.

Mi hajtja a költséget (és hol tévednek a népszerű számok)

Keress rá a „self host LLM vs API cost” kifejezésre, és egy takaros megtérülési adatnál kötsz ki: valami olyasmi, mint havi 11 milliárd token, vagy körülbelül $4200 havi API-költés, amelyet a braincuber költségelemzése idéz, és szinte szó szerint visszhangoz az oldal tetején lévő AI Overview. Tiszta szám. Önmagában viszont közel haszontalan, mert elrejti azt a két változót, amely eldönti a válaszodat.

Ez azért csúszós, mert a hasonlítás két oldalának eltérő a költségszerkezete. Egy API-számla változó költség: tokenenként fizetsz, tehát a számla fel-le skálázódik azzal, mennyit használod. Egy bérelt GPU fix költség: ugyanazt a havi díjat fizeted, akár egymilliárd tokent tolsz át rajta, akár üresjáratban hagyod. Egy változó költség egy fix költséggel való összehasonlítása egyetlen számmal azt kívánja, hogy úgy tégy, mintha pontosan tudnád, hány token fog átfolyni, és egyszemélyes léptékben ezt általában nem tudod.

Ez három kart hagy, amely mozgatja a megtérülési pontot:

• Melyik API-hoz hasonlítasz. Egy frontier API-t és egy olcsó, nyílt súlyú API-t nagyjából két nagyságrend választ el árban. A megtérülési pont mindegyikkel szemben vadul eltérő.
• A GPU-kihasználtságod. A fix költség csak akkor térül meg, ha a GPU foglalt. Az üresjárat elköltött pénz a semmiért.
• A rejtett üzemeltetési költség. A te óráid, a modellfrissítési hullámzás, és a VRAM-meglepetések, amelyek addig nem jelennek meg, amíg éles üzembe nem kerülsz.

Áraz mindegyiket, és felszakad a köd. Ez a cikk többi része.

Szakasz tanulsága: a megtérülési pont nem egyetlen szám. Három szám, egy API-szintenként, és a rossz szint kiválasztása az összehasonlításhoz az, ahol a legtöbb költségbecslés elrontja.

A háromirányú megtérülés: frontier vs. középszint vs. olcsó API

Egy nyílt súlyú LLM saját üzemeltetése egy GPU VPS-en legyőz egy frontier API-t (GPT-5-osztály, Claude Sonnet 5 / Opus 4.8, Gemini Pro) nagyjából napi néhány millió tokennél, feltéve, hogy a GPU-t egészséges kihasználtságon tartod (mondjuk 60% vagy afölött). Egy olcsó, nyílt súlyú API-val szemben nagyjából $0.14–$0.50 millió tokenenként, ritkán nyer egyáltalán költségen. Ez a különbség az egész történet, és ezért nem lehet helyes egyetlen megtérülési szám.

Íme a lényege a három szinten át. Kezeld ezeket a küszöböket irányadó tartományként, ne kemény vonalakként. Közösségi becslésekből és a 2026-os árazásból származnak, amelyek mindegyike gyorsan mozog.

Az árak a OpenAI, Anthropic, Google, DeepInfra, Together, és DeepSeek árazási oldalairól, 2026. júliusi állapot szerint. Mindegyik szám szavatossági ideje hónapokban mérhető, ezért ellenőrizd az aktuális oldalakat, mielőtt elköteleződsz.

Most a kontrár pont, mert ez az, amely megváltoztatja a döntéseket. Van egy hangos és helytálló érv, amely szerint az olcsó API-k megölték a saját üzemeltetés megtérülési pontját. Az olyan nyílt súlyú API-k, mint a DeepInfra és Together most a frontier árak töredékéért szolgálják ki a Llama- és Qwen-modelleket, és maguk a frontier árak is meredeken estek 2025 óta. Azokkal az olcsó díjakkal szemben a tokenenkénti megtérülési pont havi milliárdos tokenekbe fut. Egy egyszemélyes vállalkozó nem tol havi milliárdos tokeneket. Tehát ha az egyetlen célod egy alacsonyabb számla, az első lépés általában nem a „bérelj egy GPU-t”, hanem a „válts egy olcsó, nyílt súlyú API-ra, és tartsd nullán az üzemeltetést”.

A saját üzemeltetés költséges esete két helyen marad életben: a drága frontier árazással szembeni összehasonlításban valóban magas, tartós volumennél, és a nem költségalapú okok (adatvédelem, késleltetés, finomhangolási kontroll) esetében, amelyeket lejjebb tárgyalunk. Mindenhol máshol az olcsó API nyeri meg a pénzvitát.

A megtérülési képlet

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

Kidolgozott példa, egyszemélyes vállalkozói lépték: mondjuk egy magas kategóriás GPU VPS körülbelül $1000/hó-ba kerül (2026-os katalógustartomány egy csúcskategóriás egy-GPU-s szinthez), és egy frontier API-n vagy egy kevert díjjal, körülbelül $6 millió tokenenként (nagyjából $0.000006 tokenenként). Ez ~$1000 ÷ $0.000006 ≈ 167 millió token/hó, mielőtt a GPU papíron megtérülne. Most csináld újra egy olcsó, nyílt súlyú API-val szemben $0.40 milliónként ($0.0000004/token): ~$1000 ÷ $0.0000004 = 2.5 milliárd token/hó. Ugyanaz a GPU, ugyanaz a fix költség, és a megtérülési pont több mint 10×-esével mozdul el, pusztán attól függően, melyik API-t teszed a nevezőbe. Ez még a kihasználtság előtt van, amely tovább rontja a számot.

Szakasz tanulsága: az API, amivel összehasonlítasz, 10×-esével vagy annál is jobban mozgathatja a megtérülési pontodat, tehát a „futtasd le a számokat” azt jelenti, hogy azzal a konkrét API-val futtatod le őket, amelyet ténylegesen leváltanál.

Mit tesz a kihasználtság a tokenenkénti költséggel

Vedd azt a ~167 millió tokenes frontier megtérülési pontot, és add hozzá a változót, amelyet a képlet csendben elfeltételez: hogy a GPU-d végig foglalt. Nem az. Egy bérelt GPU ugyanannyit számláz, akár telített, akár üresjáratban van, így a tényleges GPU VPS LLM tokenenkénti költséged fordítottan skálázódik a kihasználtsággal. Futtasd 10%-os terhelésen, és minden kiszolgált token nagyjából 10×-esét viseli annak a költségnek, amennyibe teljes terhelésen kerülne, mert azért a 90% kapacitásért fizetsz, amelyet nem használtál. A közösségi becslések és gyakorlati beszámolók a gyakorlati padlót körülbelül 50–60% tartós kihasználtságnál húzzák meg, mielőtt a számok megszűnnének kínosnak lenni (irányadó adatok, nem laborállandók).

Egy hullámzó egyszemélyes munkaterheléshez (forgalom, amely nappal megugrik és éjszaka ellaposodik) a tartós 60% kihasználtságot nehéz elérni. Ez a csapda. Íme, mit tesz ez a millió tokenenkénti költséggel néhány konkrét ponton át, a 2026-os katalógus GPU-árait elosztva a durva havi átbocsátással az egyes kihasználtsági szinteken:

Az abszolút tokenenkénti cent a modelledtől, a kvantálástól és attól függ, hány párhuzamos kérést tudsz a kártyára pakolni, ezért kezeld az oszlopokat úgy, hogy a büntetés alakját mutatják, nem egy árajánlatot. A lényeg a szorzó: essél teljes terhelésről negyed terhelésre, és a tokenenkénti költséged nagyjából megnégyszereződik. Ez az, ami általában megöli az egyszemélyes saját üzemeltetés esetét, nem a GPU listaára.

Van egy strukturális vészkijárat, és ez az oka annak, hogy a bérlés legyőzheti a birtoklást a hullámzó kereslet esetén: le tudsz állítani egy bérelt példányt, amikor üresjáratban van. Birtokold a hardvert, és az értékcsökken és áramot fogyaszt, akár használod, akár nem. Óradíjas vagy on-demand bérlésnél leállíthatod vagy lebonthatod a példányt, amikor a munka kész, és elkerülheted, hogy üresjárati órákért fizess. Fix havi csomagoknál a számla a számlázási időszakra fix marad, tehát a kihasználtság továbbra is a fő költségprobléma. Ez nem old meg egy olyan munkaterhelést, amely egész nap valóban alacsony kihasználtságú, de az olyan kereslethez, amely hullámokban foglalt és közte halott, a mérő kikapcsolásának képessége az egyetlen kar, amely a bérlés-vs-birtoklás mérlegét a bérlés felé billenti.

Szakasz tanulsága: a kihasználtság, nem a GPU havi ára, az általában, ami eldönti, hogy a saját üzemeltetés kijön-e a matekból, és ez az a változó, amelyet a népszerű megtérülési számok teljesen kihagynak.

Melyik modell fér melyik GPU-ra: a VRAM valósága

A terv, amely elsőként törik meg, az „csak lefuttatok egy 70B-t egy 4090-en”. Nem lehet. Egy 70B-s modell Q4_K_M kvantálással nagyjából 40–46 GB VRAM-ot igényel, és egy 24 GB-os RTX 4090-nek vagy egy 32 GB-os RTX 5090-nek egyszerűen nincs meg a helye hozzá. Erőltesd rá egy 24 GB-os kártyára, és leesel Q2_K kvantálásra (körülbelül 21 GB) látható minőségromlással, vagy a modell átcsordul a rendszer-RAM-ba, és a generálási sebesség összeomlik. A VRAM az a kemény fal, amely eldönti, mely modellek egyáltalán szóba jöhetnek egy adott GPU-hoz.

Íme, mi fér hová. A VRAM-számok hozzávetőlegesek: a szabványos byte-per-paraméter aritmetikából származnak (FP16 ≈ paraméterek × 2 ~15% többletköltséggel; Q4_K_M ≈ paraméterek × ~0.55 többletköltséggel), ezért kezeld őket méretezési iránymutatásként, nem garanciaként.

A VRAM-számokat az NVIDIA hivatalos GPU-specifikációs oldalaival ellenőriztük kártyánként. Az A100 kényelmesebb mozgásteret ad egy kvantált 70B-nek; az RTX 6000 Ada működhet szorosabb Q4-beállításokhoz, míg a 24 GB-os és 32 GB-os fogyasztói kártyáknak nincs elég VRAM-juk egy normál 70B Q4-telepítéshez. Ha a teljes lebontását szeretnéd annak, hogyan fogyasztanak memóriát a GGUF-, GPTQ-, AWQ- és EXL2-formátumok, az egy külön olvasásra méltó nyúlüreg: GGUF, GPTQ, AWQ, EXL2: hogyan használják valójában a memóriát az LLM-kvantálási formátumok.

A közösségi optimum egy egyetlen 24 GB-os kártyához egy 24B-től 32B-ig terjedő modell (Mistral Small 3.1 vagy Qwen 3 32B Q4-en). Ez az a méret, amely egy egyszemélyes fejlesztőnek hasznos modellt ad a legolcsóbb GPU-szinten anélkül, hogy végig a VRAM-mal harcolna. Ha azt mérlegeled, melyik kártyát béreld egyáltalán, a mi H100 vs RTX 4090 benchmarkunk AI-munkaterhelésekhez összehasonlítja a szinteket átbocsátás szerint.

Profi tipp: költségvetezz a KV cache-re, ne csak a súlyokra. A legelterjedtebb első telepítési meglepetés: a GPU-t a modellsúlyokhoz méretezed, betöltöd, és ráfér. Aztán jönnek a kérések, a KV cache nő a kontextushosszal és a párhuzamossággal, és kifogysz a VRAM-ból az első pár felhasználód kiszolgálásakor. Amikor a VRAM túlcsordul, és a modell átcsordul a CPU-ra, a generálási sebesség 10–100×-esével esik. Hagyj mozgásteret a táblázatbeli súlyszámok fölött a cache-nek, különösen, ha hosszú kontextusokat vagy több felhasználót szolgálsz ki egyszerre.

A rejtett költségek, amelyek eltörlik a naiv megtakarítást

A táblázat, amely azt mondja, hogy a saját üzemeltetés olcsóbb, szinte mindig egy sorral rendelkezik: a GPU havi árával. A számlán, amit fizetsz, több sor van. Ott az időd (minden óra, amit foltozással, egy beragadt következtetőszerver újraindításával vagy egy memóriakifogyási összeomlás üldözésével töltesz, egy óra, amit nem a terméken töltöttél). Ott a modellfrissítési hullámzás: a nyílt súlyú modell, amelyet telepítettél, elavul, az újra-benchmarkolás és újratelepítés pedig visszatérő munka, nem egyszeri beállítás. Ott a VRAM- és KV-cache-meglepetés az előző szakaszból. És ott az üresjárati pazarlás, azok az órák, amikor a GPU számláz, miközben semmi sem fut.

Azok a gyakorlati szakemberek, akik ezeket megszámolták, a valós költséget nagyjából 1.3–2×-esére teszik a nyers GPU-árnak, ha az üzemeltetési idő be van hajtva, és néhányan feljebb mennek, 3–5×-esig, a rendezetlenebb beállításoknál. Ezek irányadó szorzók közösségi beszámolókból, nem auditált számok, de az irány a lényeg. Ahogy egy széles körben idézett megfogalmazás mondja, egy üresjáratban lévő GPU nem eszköz, hanem óradíjjal számlázott kötelezettség. Egy egyszemélyes fejlesztő számára ennek helyes árazása nem egy MLOps-fizetési sor, hanem a saját óráid, amelyek a legszűkösebb dolgok, amivel rendelkezel. Ha a saját üzemeltetés papíron havi $200-t spórol neked, de hat óra üzemeltetésbe kerül, amit egyébként szállítással töltenél, az nem egyértelműen nyereség.

Amikor a saját üzemeltetés mégis nyer: adatvédelem, késleltetés és finomhangolás

A költség nem az egyetlen ok, hogy a saját modelledet futtasd, és néhány fejlesztő számára nem is a fő ok. A költség-megtérülési pont alatt, ahol a pénz azt mondja, „maradj az API-n”, három ok van a saját üzemeltetésre mégis. Adatszuverenitás: a felhasználóid promptjainak és adatainak kívül tartása egy külső AI-szolgáltató folyamatán, ami néhány termék számára számít, függetlenül attól, mit mondanak a számok. Kiszámítható késleltetés: nincs megosztott bérlős sor, nincsenek olyan sebességkorlátok, amelyeket nem te állítottál be, nincsenek meglepetéslassulások valaki más forgalmi csúcsa alatt. És teljes kontroll: a szabadság a finomhangolásra, kvantálásra, modellcserére és verziórögzítésre anélkül, hogy egy szállítóra kellene várnod.

Van egy kikötés az adatvédelmi ponton, és kihagyása tisztességtelen lenne. Egy bérelt GPU VPS még mindig valaki más hardverén fut, valaki más adatközpontjában. Ez érdemi szuverenitás az AI-szolgáltató tanítási és naplózási folyamatától (a promptjaid nem folynak át egy modellszállító rendszerein), de nem ugyanaz, mint egy helyszíni berendezés, amelyet fizikailag te irányítasz. Ha a követelményed valódi helyszíni izoláció, egy bérelt VPS nem juttat oda. Ha a követelményed az, hogy „tartsd az adatainkat egy harmadik fél modellszállítójának kezén kívül”, akkor igen. Tudd, melyikre van szükséged.

Az olyan munkaterhelésekhez, amelyek korlátozó hálózati környezetben futnak, egy általad irányított infrastruktúrán futó, saját üzemeltetésű modell ki is kerülheti a külső végpontoktól való függőségeket, amelyek elérhetetlenek lehetnek, ez egy olyan képesség, amely attól függetlenül számít, hol telepíted.

Tehát üzemeltesd-e magad? Egyenes válasz helyzetenként

Minden fenti egy rövid döntéssé rendeződik. Van egy számlád, egy durva érzésed a havi tokenvolumenedről, és most a három megtérülési szint, a kihasználtsági büntetés és a rejtett költség szorzója. Térképezd a helyzetedet ezek egyikére:

• A frontier megtérülési pont alatt vagy, és a költség az egyetlen aggodalmad. Maradj egy API-n, és komolyan árazz egy olcsó, nyílt súlyú API-t (DeepSeek, DeepInfra, Together) minden más előtt. Ez általában a költségnyereség, nem a saját üzemeltetés. Az API-váltás egy konfigurációs változás, a saját üzemeltetés egy második állás.
• Tartós, magas volumened van a frontier árazással szemben, és 60%+ kihasználtságon tudsz tartani egy GPU-t. Ez az, ahol a saját üzemeltetés megtérül. Futtasd le a képletet a frontier díjaddal szemben, erősítsd meg, hogy tartós kihasználtsággal átléped a küszöböt (nem csúcson), és egy bérelt GPU VPS kezd nyerni.
• Van egy nem költségalapú hajtóerőd: adatvédelem, késleltetés vagy finomhangolási kontroll. Üzemeltesd magad a megtérülési pont alatt tudatosan, nyitott szemmel arra, hogy a kontrollért fizetsz. Csak ne mondd magadnak, hogy olcsóbb, ha nem az.
• Valahol a kettő között vagy. Nézd meg a hibrid mintát, amelynél a legtöbb gyakorlati szakember köt ki 2026-ban: egy kis, saját üzemeltetésű modell nagy volumenű, egyszerű feladatokhoz, plusz egy frontier API a nehéz gondolkodáshoz, amelyre a helyi modelled 85–90%-osan eljut (közösségi benchmarkok, nem laborellenőrzöttek, és az utolsó szakasz gyakran ott van, ahol a minőségre a legjobban szükséged van).

A „hogyan szerezzem meg a GPU-t” kérdésre a válasz egy egyszemélyes fejlesztő számára szinte mindig a bérlés, nem a vétel. Az adatközpont-osztályú hardver birtoklása egy tőkekiadási fogadás, amelynek csak olyan léptéknél van értelme, amivel még nem rendelkezel. A serverless következtetés csökkentheti az üresjárati pazarlást azzal, hogy nullára skálázódik, és csak az aktív számításért számláz, de ezt gyakran egy magasabb per-GPU-óra díjra és hidegindítási késleltetésre cseréli. Egy bérelt GPU VPS a középen ül: nincs tőkekiadás, kiszámítható havi számla, root-hozzáférés, és a képesség, hogy leállítsd a példányt, amikor üresjáratban van.

Ha lefuttattad a képletet, átlépted a megtérülési pontot, és egy dedikált, privát, root-hozzáférésű következtetőszervert szeretnél kártya vétele nélkül, pontosan erre való egy bérelt GPU-gép. A Cloudzy GPU VPS csomagjai lefedik a tartományt egy 8B-s modelltől egyetlen kártyán egészen egy kvantált 70B-ig, az egykattintásos Ollama alkalmazás a marketplace-en pedig körülbelül egy perc alatt telepít egy REST API-val, amely kompatibilis az OpenAI-kliensekkel, így a váltás egy fizetős API-ról a saját szerveredre közel drop-in változás lehet a kódodban, tokenenkénti költség nélkül a fix havi díj után. Ellenőrizd az oldalon az aktuális árakat, a GPU-díjak mozognak.

Az egyetlen tett, amit érdemes megtenni, mielőtt bármit bérelnél: futtasd le a megtérülési képletet a saját számládon. Két percbe telik, és megmondja, a fenti négy helyzet közül melyikben vagy.

Gyakran ismételt kérdések

Olcsóbb saját LLM-et üzemeltetni, vagy egy API-t használni?

Attól függ, melyik API-t. Egy nyílt súlyú modell saját üzemeltetése egy GPU VPS-en legyőzhet egy frontier API-t (GPT-5-osztály, Claude Sonnet 5 / Opus 4.8) magas, tartós volumennél, jó GPU-kihasználtsággal. Ritkán győz le egy olcsó, nyílt súlyú API-t (DeepSeek, DeepInfra, Together, nagyjából $0.14–$0.50 millió tokenenként 2026. júliusi állapot szerint) pusztán költségen: az a megtérülési pont havi milliárdos tokenekbe fut, amit a legtöbb egyszemélyes fejlesztő soha nem ér el.

Milyen GPU kell egy 70B-s modell futtatásához?

Egy 70B-s modell Q4_K_M kvantálással nagyjából 40–46 GB VRAM-ot igényel pusztán a kvantált súlyokhoz. Egy 80 GB-os A100 a biztonságosabb egy-GPU-s opció, mert helyet hagy a KV cache-nek, a futásidejű többletköltségnek és a hosszabb promptoknak. Egy 48 GB-os RTX 6000 Ada működhet szorosabb Q4-beállításokhoz, de a kontextushosszt és a párhuzamosságot gondosan kell kezelni.

Hogyan befolyásolja a GPU-kihasználtság a tokenenkénti költséget?

Egy bérelt GPU ugyanannyiba kerül, akár üresjáratban, akár teljesen terhelten van, így a tényleges tokenenkénti költséged fordítottan skálázódik a kihasználtsággal. 10%-os terhelésen minden kiszolgált token nagyjából 10×-esébe kerül annak, mint teljes terhelésen, mert a nem használt kapacitásért fizetsz. A gyakorlati padló ahhoz, hogy a saját üzemeltetésnek értelme legyen, körülbelül 50–60% tartós kihasználtság.

Hány token/hó kell, mielőtt a saját üzemeltetés megérné?

Egy frontier API-val szemben nagyjából havi 160–256 millió token egészséges kihasználtságon az irányadó küszöb (2026. júliusi állapot szerint). Egy olcsó, nyílt súlyú API-val szemben havi milliárdok, egyszemélyesen gyakorlatilag elérhetetlen. A pontos szám a GPU-költségedtől és a kevert API-díjadtól függ, ezért futtasd le a képletet: megtérülési tokenek ≈ GPU VPS havi költsége ÷ az API-árad tokenenként, majd diszkontáld a tartós kihasználtságra.

Futtathatok nyílt súlyú LLM-et egy VPS-en?

Igen, egy GPU VPS-en, amely a modell VRAM-jához van méretezve. Egy olyan eszköz, mint az Ollama, nyílt súlyú modelleket futtat (Llama, Qwen, Mistral és mások) egykattintásos telepítéssel és egy OpenAI-compatible REST API-val, így a meglévő, API-t hívó kódod minimális változtatással a saját szerveredre mutathat. Illeszd a GPU-szintet a modelledhez: egy 8B kényelmesen ráfér egy 24 GB-os kártyára, egy kvantált 70B-nek 48–80 GB kell.