Hogyan használd az LLM API-kat: tokenek, költségek, kulcsok és az első AI-funkció

Az LLM API egy webes szolgáltatás, amely lehetővé teszi, hogy az appod szöveget küldjön egy nagy nyelvi modellnek, például az OpenAI GPT-modelljeinek, az Anthropic Claude-jának vagy a Google Gemini-jének, és a választ kódból visszakapja. Regisztrálsz a szolgáltatónál, létrehozol egy API-kulcsot, az appod szervere pedig ezzel a kulccsal küld kéréseket. Minden kérésért a tokenek (szövegdarabok) száma szerint fizetsz, a bemenetért és a kimenetért egyaránt. Az „AI hozzáadása egy appba” általában ennyit jelent: egy jól megírt kérést küldesz valaki más modelljének, biztonságosan, a saját szerveredről.

Miért fontos ez AI-val építve

Az AI-val épített appban két különböző AI van, és könnyű összekeverni őket:

1. Az AI, amely az appodat építi – az app-építő saját ágense, amely megírja a kódot.
2. Az AI az appodon belül – egy funkció, amelyet a felhasználóid használnak, például egy chatasszisztens, egy „összefoglalás” gomb vagy automatikus címkézés.

A második egy LLM API-t hív a te kulcsoddal, és a te szolgáltatói fiókodat terheli. A tokenek, a kontextus és az árazás megértése segít abban, hogy olyan funkciót tervezz, amely működik, nem szivárogtatja ki a kulcsodat, és nem ér meglepetés a számlán.

Egy mindennapi hasonlat: nagyon ügyes szabadúszó, szavanként fizetve

Gondolj az LLM API-ra úgy, mint egy zseniális szabadúszó íróra, akit e-mailben érsz el, és szavanként fizetsz – mind azokért a szavakért, amiket küldesz neki, mind azokért, amiket visszaír (a visszaírt szavak pedig drágábbak).

• Nincs emlékezete az e-mailek között. Ha azt szeretnéd, hogy folytassa a beszélgetést, minden új e-mailbe bemásolod a korábbi üzeneteket.
• Egyszerre csak ennyit tud elolvasni. Ezt a határt hívjuk kontextusablaknak.
• Minél világosabb a megbízás, annál jobb és rövidebb a válasz – ami olcsóbb is.

Az alapfogalmak

Tokenek

A modellek tokenekben olvasnak és írnak. Az Anthropic árazási dokumentációja 2026 szeptemberében tokenenként nagyjából 4 karaktert, vagyis körülbelül 0,75 angol szót becsül. A különböző modellek és nyelvek eltérően bontják tokenekre, ezt tehát durva iránymutatásnak tekintsd. Minden beleszámít: az utasításaid, a felhasználó üzenete, a mellékelt dokumentumok, a korábbi beszélgetés és a válasz.

Bemenet és kimenet

A bemeneti tokenek azok, amiket elküldesz. A kimeneti tokenek azok, amiket a modell ír. Az OpenAI, az Anthropic és a Google árazási oldalain 2026 szeptemberében ugyanannál a modellnél a kimeneti tokenek többszörösébe kerülnek, mint a bemeneti tokenek. A Google Gemini árazása azt is megjegyzi, hogy a modell belső „gondolkodása” kimenetnek számít.

Kontextusablak

A maximális tokenszám, amelyet egy modell egyetlen kérésben befogadhat, a válasszal együtt. A mai modellek nagyon hosszú bemenetet is elfogadnak – az Anthropic jelenlegi modelljei például akár egymillió tokent is. A hosszú bemenet azonban többe kerül és lassabb, ezért csak azt küldd, amire a feladatnak szüksége van.

Állapot nélküli kérések

A legtöbb csevegő jellegű API-nál alapértelmezés szerint minden kérés önálló. Ahhoz, hogy a csevegés „emlékezzen”, az appodnak minden új üzenettel újra el kell küldenie a korábbi üzeneteket. Ezért kerül egy hosszú beszélgetés üzenetenként többe, mint egy rövid.

A rendszerprompt

Az utasítások, amelyek minden kérésnél meghatározzák a modell szerepét és szabályait: „Három felsorolásszerű pontban foglalod össze a támogatási jegyeket. Soha ne szerepeltess ügyfél e-mail-címeket.” A felhasználók nem látják, de minden válaszra hat.

Streamelés

A teljes válasz megvárása helyett az API a szöveget már a generálás közben küldheti, így a felhasználók azonnal látják a szavakat megjelenni. Ettől a csevegőfelületek sokkal gyorsabbnak tűnnek.

Hogyan működik az árazás

2026 szeptemberében, a szolgáltatók saját árazási oldalán ellenőrizve:

Néhány szolgáltató azt is lehetővé teszi, hogy fizetés előtt kipróbáld: az Anthropic kis összegű ingyenes kreditet ad az új felhasználóknak, a Google Gemini API-jában pedig egyes modelleknél van ingyenes szint, azzal a kitétellel, hogy az ezen küldött tartalom felhasználható a Google termékeinek fejlesztésére.

A kis, gyors modellek és a legnagyobbak ára között nagy a különbség, az árak pedig gyakran változnak, ezért itt nem adunk meg konkrét számokat. Bármely funkció egyszerű becslése így néz ki: (bemeneti tokenek × bemeneti ár + kimeneti tokenek × kimeneti ár) × kérések száma havonta. Ehhez adj hozzá egy tartalékot, és állíts be havi költési limitet a szolgáltató irányítópultján.

Példa: egy „jegy összefoglalása” gomb

Egy kis ügyfélszolgálati csapat szeretne egy gombot, amely a hosszú ügyfél-e-mailfolyamot három felsorolásszerű pontba és egy javasolt válaszba foglalja.

1. Szerezz kulcsot. Hozz létre fiókot az egyik szolgáltatónál, és generálj egy API-kulcsot. Állíts be alacsony havi költési limitet.
2. Tárold a kulcsot titokként a szerveren, például ANTHROPIC_API_KEY vagy OPENAI_API_KEY néven – soha ne az oldal kódjában. Lásd: környezeti változók és titkok.
3. Adj hozzá egy szerveroldali útvonalat, POST /api/summarise néven, amely:
   • ellenőrzi, hogy a személy be van-e jelentkezve, és a támogatási csapat tagja-e;
   • betölti a jegyet az adatbázisból;
   • elküldi a szolgáltatónak a rendszerpromptot („Foglald össze három pontban, majd fogalmazz meg egy udvarias választ; ne találj ki rendelésszámokat”) a jegy szövegével együtt;
   • korlátozza a válasz hosszát a maximális kimeneti tokenek beállításával;
   • visszaadja az eredményt, és naplózza, hány tokent használt.
4. A gomb a saját útvonaladat hívja, nem a szolgáltatót, és a választ streamelve mutatja.
5. Kezeld a hibákat. Ha a szolgáltató lassú, vagy hibát ad, jelenítsd meg, hogy „Most nem sikerült összefoglalni”, és a jegy továbbra is használható maradjon.
6. Mérj. Egy hét után nézd meg a tokennaplókat. Ha a költség nagy részét a hosszú e-mailfolyamok adják, küldés előtt vágd le az idézett előzményeket.

Figyelj arra, mi hiányzik: nincs modelltanítás, nincs különleges infrastruktúra. Egy kulcs, egy szerveroldali útvonal, egy jól megírt prompt.

Kulcsfogalmak

• API-kulcs: a titok, amely azonosítja a fiókodat a szolgáltatónál. Aki birtokolja, az a te pénzedet költheti.
• Modell: az a konkrét LLM, amelyet hívsz. A szolgáltatók több méretet kínálnak, eltérő áron és sebességgel.
• Hőmérséklet: a válaszok változatosságát szabályozó beállítás. Alacsonyabb értéknél kiszámíthatóbbak a válaszok.
• Maximális tokenszám: a válasz hosszának korlátja, amely a költséget is korlátozza.
• Sebességkorlát: hány kérést vagy tokent használhat a fiókod percenként.
• Beágyazások (embeddings): a szöveg jelentését kifejező számok, amelyeket a saját dokumentumaidban való kereséshez használnak.
• RAG (lekérésen alapuló generálás): a saját adataidból releváns részletek megkeresése, és azok beillesztése a promptba, hogy a modell a te tartalmadból válaszoljon.
• Eszközhasználat / függvényhívás: hagyod, hogy a modell megkérje az appodat egy adott függvény futtatására, például „nézd meg a rendelés állapotát”.

Gyakori hibák és tévhitek

• A kulcs a frontend kódba kerül. A legdrágább hiba. A böngészőben futó kód nyilvános. Mindig a szerverről hívj. Az AI-val épített appok biztonsági ellenőrzőlistája más indítás előtti ellenőrzésekkel együtt ezt is lefedi.
• Nincs költési limit vagy felhasználónkénti korlát. Egy hiba, egy végtelen ciklus vagy egy visszaélő felhasználó gyorsan felhúzhatja a költségeket. Állíts be szolgáltatói limitet, és az appodban korlátozd a kéréseket felhasználónként.
• Mindent minden alkalommal elküldeni. A teljes dokumentumok és a teljes csevegési előzmények megsokszorozzák a bemeneti tokeneket. Vágd le, foglald össze a régebbi üzeneteket, vagy csak a releváns részeket keresd elő.
• A kimenetnek vakon hinni. A modellek magabiztosan mondhatnak hamis dolgokat. Tényeknél, áraknál vagy jogi és egészségügyi kérdéseknél alapozd a válaszokat a saját adataidra, mutass forrásokat, vagy legyen emberi ellenőrzés.
• A felhasználói bemenet felülírhatja a szabályaidat. A felhasználók beírhatják, hogy „hagyd figyelmen kívül az utasításaidat”. A jogosultságokat és az érzékeny műveleteket a szerveroldali kódban tartsd, ne csak a promptban.
• A legnagyobb modellel kezdeni. Először próbálj ki egy kisebb, olcsóbb modellt, és csak akkor lépj feljebb, ha a minőség megköveteli.
• Személyes adatok gondolatlan küldése. Nézd meg a szolgáltató adathasználati feltételeit, különösen az ingyenes szinteken, és csak azt küldd, amire a funkciónak szüksége van.

Mit kérj az AI-építődtől

Adj egy „Összefoglalás” gombot a jegy oldalra. Egy szerveroldali útvonalat hív, amely a OPENAI_API_KEY titkot használja (soha nem kerül a böngészőbe), ellenőrzi, hogy a felhasználó be van-e jelentkezve, elküldi a jegy szövegét ezzel a rendszerprompttal: […], a választ 300 tokenre korlátozza, a választ streamelve jeleníti meg az oldalon, és barátságos hibaüzenetet ad, ha a hívás nem sikerül. Naplózd a kérésenként használt tokeneket, és felhasználónként óránként legfeljebb 30 összefoglalást engedélyezz.

Teljes csevegési élményért lásd: hogyan építs AI-chatbot appot; további ötletekért: hogyan adj AI-funkciókat az appodhoz. Ha az API-k általában újdonságot jelentenek neked, kezdd ezzel: mi az API.

LLM API-k a Mythexszel épített appokban

A Mythexszel építve az appodon belüli AI a saját szolgáltatói kulcsodat használja. Projekt-titokként adod hozzá, vagy a titkok kártyán keresztül, amelyet a Mythex a csevegésben mutat, amikor szükséges, és megkéred az ágenst, hogy a hívást a szerveren végezze el. A szolgáltatói használatot a te szolgáltatói fiókodra számlázzák, nem a Mythex építési kreditjeire. A Mythex nem ad tokeneket az appod felhasználóinak, és nem tartalmaz beépített tudásbázis-terméket; a sebességkorlátokat és a költségkontrollt neked kell megtervezned és tesztelned. A dokumentációs recept, AI-funkciók hozzáadása saját API-kulcsokkal, tartalmaz kiindulási promptot, a AI app builder oldal pedig megmutatja, hol érdemes kezdeni.

Kérdések