> A Portkey egy OpenAI-kompatibilis végpont mögé szorítja a retry-t, a fallbacket, a cache-t, a guardrailokat és a költségkövetést. Ami jól működik, és mi az ára késleltetésben. > > Web page: https://balazscsorba.com/hu/blog/portkey · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/portkey.md) · [Deutsch](https://balazscsorba.com/de/blog/portkey.md) > Author: Balázs Csorba · Published: 2026-09-28 · Keywords: portkey ai gateway, portkey vs litellm, llm gateway comparison, llm gateway latency overhead, llm guardrails gateway, self-hosted llm gateway, portkey pricing [Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés # Portkey: éles LLM-átjáró, routing, guardrailok és költség szerint A Portkey egy OpenAI-kompatibilis végpont mögé szorítja a retry-t, a fallbacket, a cache-t, a guardrailokat és a költségkövetést. Ami jól működik, és mi az ára késleltetésben. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. szeptember 28.·11 perc olvasás - LLM gateway - Guardrails - Routing - Observability - Cost control ![Vastag függőleges lap, benne sávok és pajzs, egy nyíl be, három ki.](https://balazscsorba.com/images/blog/portkey/cover.webp?v=cf9110e311) ## A lényeg röviden - A Portkey routing-konfigurációja a termék legerősebb része: zárt séma, négy egymásba ágyazható stratégiamód, 100-ra normalizált súlyok, és olyan circuit breaker, amelynek cooldownja nem állítható 30 másodperc alá. - A menhelyezett átjáró egy hálózati ugrás. A Portkey saját benchmark-repójában a mért érték átlagosan plusz 93 ms a közvetlen Bedrock-híváshoz képest, és 50–150 ms-ot nevez tipikusnak a két további ugrásra. - A guardrailok mindig csak az utolsó üzenetet olvassák, képet soha; a szinkron letiltás 446-ot ad vissza, olyan státuszkódot, amelyet a legtöbb SDK újrapróbálkozásra utónak tekint. - A számlázás rögzített naplókon alapul, nem kéréseken, és az ár-oldal és a cache-dokumentáció nem ért egyet abban, hogy a 49 dolláros Production csomag tartalmazza-e a szemantikus cache-t. - A 2026. májusi felvásárlás óta a Prisma AIRS részeként szállítják, ami a szerződő felet változtatja meg, az API-t nem. Ezen az oldalon 1. [Mi ez valójában](https://balazscsorba.com/#what-it-is) 2. [Hogyan működik](https://balazscsorba.com/#how-it-works) 3. [Első lépések](https://balazscsorba.com/#getting-started) 4. [Guardrailok](https://balazscsorba.com/#guardrails) 5. [Ár és késleltetés](https://balazscsorba.com/#pricing-and-latency) 6. [Hol nem passzol](https://balazscsorba.com/#where-it-shingles) 7. [Ítélet](https://balazscsorba.com/#verdict) 8. [Források](https://balazscsorba.com/#sources) Cikk meghallgatása 0:000:00 A Portkey LLM-átjáró: proxy, amely a kliens és a hívott modellszolgáltatók közé kerül, és a szolgáltatói kulcsokat, retry-ket, fallbackeket, cache-t, guardrailokat és költség-hozzárendelést konfigurációs objektumokba szervezi alkalmazáskód helyett. A piacon elérhető átjárók közül ez az egyik legteljesebb, és mióta a Palo Alto Networks 2026 májusában lezárta a Portkey felvásárlását, a Prisma AIRS részeként is szállítják. Az álláspont: a routing réteg a legerősebb a maga kategóriájában, és megéri az operatív függést, a menhelyezett üzemeltetésnél és a guardrail-szemantikánál viszont ott vannak a buktatók. Amit lecserél, az a saját kezű retry-wrapper, amelyet minden csapat megír az LLM-termék első hónapjában: általában egy try blokk egy sleeppel, egy beégetett szolgáltatói kulccsal, és nulla nyilvántartással arról, mi került ki. A Portkey ezt egyetlen OpenAI-kompatibilis alap-URL mögé teszi, így az OpenAI SDK, az Anthropic SDK, a LangChain vagy egy nyers fetch ugyanazt a végpontot szólaltatja meg. Versenytársai a LiteLLM, amely ingyenes és saját kézben fut, az OpenRouter, amely fizetős piactér vezérlő sík helyett, és a Cloudflare AI Gateway, amely majdnem ingyenes, mert olyan infrastruktúrán fut, amért az amúgy is fizetnek. ## Mi ez valójában A Portkey valójában két termék egy repositoryban. Az átjáró maga MIT-licencű Node proxy, amely egyetlen parancsból indul, a 8787-es porton szolgál helyi konzolal; a körülötte lévő control plane fizetős szolgáltatás, amely a hitelesítő adatokat tárolja, a konfigurációs felületet hosztolja és a naplókat tartja. Ez a split magyaráz szinte mindent. Amit a proxy csinál, az jól dokumentált és ingyenes, és amit a control plane csinál, ott lakik az ár, a guardrail-katalógus és a megfelelési történet. - Egyetlen parancsból indul, `npx @portkey-ai/gateway`, a `localhost:8787` címen szolgál, konzolja a `/public/` útvonalon. - MIT-licencű, körülbelül 13 100 GitHub-csillaggal és 1 300 forkkal; a kiadott npm csomag az 1.15.2-es verziónál tart, egy 2.0 előkiadási ágon dolgoznak. - Egy OpenAI-kompatibilis végpont, plusz az Anthropic `/v1/messages` és az Open Responses formátum. Csak a modell-string változik, ha a szolgáltató. - A modell-string hordozza a szolgáltatót: az `@openai-prod/gpt-4o` egy tárolt integrációra oldódik fel, a költségkeretével és a rate limitjével együtt. - A stratégiaobjektumok ágyazhatók egymásba. Egy fallback tartalmazhat load balancert, amely egy újabb fallbackt tartalmaz, mindegyik saját súlyokkal, státuszkód-kiváltókkal és circuit breakerrel. - A guardrailok bemenetet és kimenetet is értékelnek, aszinkron, további késleltetés nélkül, vagy szinkron, dokumentált 246-os és 446-os deny kódokkal. - 2026 májusa óta a Palo Alto Networks tulajdona, Prisma AIRS AI Gateway néven értékesítve, 2026. július 16-tól általánosan elérhető. ## Hogyan működik A kérés Portkey API-kulccsal és általában egy config-csal érkezik. A config megnevez egy stratégiát és egy cél-listát. Az átjáró minden célt felold egy tárolt szolgáltatói integrációra, a config szerint cache-el és guardrailoz, továbbítja a kiválasztott szolgáltatónak, majd naplósort ír a késleltetésről, a tokenekről és a költségről. A különbség a kézzel írt proxyhoz képest nem a továbbításban van, hanem abban, hogy a döntés adat: ugyanaz a JSON fut változatlanul a menhelyezett termékben, az open source proxyban és a saját VPC-ben futó data plane-ben. ![Egy kérés a Portkey átjárón keresztül Az alkalmazás OpenAI-kompatibilis kérést küld a Portkey átjárónak. Az átjáró alkalmazza a csatolt configot, majd retry, fallback és súlyozott routing segítségével szétosztja a kérést három szolgáltató egyikére. A guardrail-ítéletet szinkron ellenőrzi, és 246-ot vagy 446-ot ad vissza. Minden hívás naplósort ír a késleltetésről, a tokenekről és a költségről.](https://balazscsorba.com/images/blog/portkey/diagram-7.webp?v=e269264ff4) Egy kérés az átjárón: a config dönt a célról, a szinkron guardrail 246-tal vagy 446-tal utasíthatja el, és minden hívás naplózódik a késleltetésével, tokenjeivel és költségével. Az érdekes ág a guardrail. Aszinkron futtatásnál, ami az alapértelmezés, az ellenőrzés párhuzamosan zajlik a modellhívással, az eredményt csak naplózzák, és a szolgáltató saját státuszkódja változatlanul visszatér. Szinkron futtatásnál az ellenőrzés blokkol: siker esetén 200, hiba esetén 246, ha a deny ki van kapcsolva, és 446, ha be. Mindkét kód azon a tartományon kívül esik, amelyre bármelyik klienskönyvtárat írták. Az a könyvtár, amely 200-tól eltérő státuszt sikernek tekint, csendben elfogad egy 246-ot, aminek meg kellett volna jelöltnek lennie; az, amely a 2xx-en kívülit kivételnek veszi, 446-nál dob, és úgy próbálja újra, mintha a hálózat hibázott volna. Ez a termék legélesebb éle. A másik fel a config objektum. A sémája zárt, négy固定的 stratégiamóddal, single, loadbalance, fallback és conditional, és rögzített kulcslistával, így egy elírás elutasításra kerül, nem pedig csendesen figyelmen kívül marad. A célok maguk is configok, és éppen ettől összeépíthetők a stratégiák. ``` { "strategy": { "mode": "fallback", "on_status_codes": [429, 500, 503] }, "retry": { "attempts": 3, "use_retry_after_headers": true }, "cb_config": { "failure_threshold": 5, "cooldown_interval": 60000 }, "targets": [ { "provider": "@openai-prod", "override_params": { "model": "gpt-4o" } }, { "strategy": { "mode": "loadbalance" }, "targets": [ { "provider": "@anthropic-prod", "weight": 0.8, "override_params": { "model": "claude-sonnet-4-5-20250929" } }, { "provider": "@bedrock-prod", "weight": 0.2, "override_params": { "model": "anthropic.claude-3-5-sonnet-20241022-v2:0" } } ] } ] } ``` Három részlet megérdemli a saját figyelmet. A súlyok 100-ra normalizálódnak, és a nulla súly úgy tartja a célt a configban, hogy nem küld rá forgalmat, így a canary állítható le Rather than törölhető. A circuit breaker `cooldown_interval` értékének 30 000 milliszekundum a padlója, így a gyors flikkeringést védő hurok nem konfigurálható szűk retry-viharba. A sticky routing a megnevezett mezők hashét számolja egyórás alapértelmezett TTL-lel, de kétlépcsős cache-re épül, memória és Redis formájában, így Redis nélkül csak egy példányon működik. ## Első lépések Telepítsd az SDK-t, vegyél fel egy szolgáltatót a Model Catalogban, és módosíts egy stringet. A Portkey SDK az OpenAI kliens szuperhalmaza, így egy meglévő integrációnak rendszerint semmi másra nincs szüksége, mint az alap-URL és a kulcs cseréjére. ``` from portkey_ai import Portkey client = Portkey(api_key="PORTKEY_API_KEY") answer = client.chat.completions.create( model="@openai-prod/gpt-4o", # @provider-slug/model-name messages=[{"role": "user", "content": "Summarise this ticket in one line."}], ) print(answer.choices[0].message.content) # Same code, different model: only the string changes answer = client.chat.completions.create( model="@anthropic-prod/claude-sonnet-4-5-20250929", max_tokens=512, messages=[{"role": "user", "content": "Summarise this ticket in one line."}], ) print(answer.choices[0].message.content) ``` Két dolog számít, mielőtt ez élesbe kerül. A szolgáltatói slug szerveroldalon oldódik fel a Model Catalogból, nem a kérésben lévő literálból, így a rossz modell-string kérésidőben, nem deployidőben hibázik. A retry-t, cache-t és guardrailokat hordozó config pedig nincs a snippetben: vagy config ID-ként csatolódik a klienshez, vagy JSON-blobként a `x-portkey-config` fejlécben, és éppen ez teszi lehetővé a routing-politika módosítását deploy nélkül. **A config módosítása termelési módosítás** A dashboardon szerkesztett config pull request nélküli termelési viselkedés. Verzionizáld a JSON-t, diffeld minden módosítás előtt, és tarts meg egy működő példányt, mert a hibás fallback-lánc attól függően, melyik mező rossz, nyíltan vagy zártan esik ki. ## Guardrailok A guardrailok olyan ellenőrzések, amelyek a kéréshez csatakoznak, és a bemenetre, a kimenetre vagy mindkettőre értékelődnek. Ők a Portkey leginkább félrekonfigurálható része, részben azért, mert a funkciólista szélesebbnek hangzik, mint a tényleges viselkedés. A dokumentáció szokatlanul nyíltan beszél a korlátokról, ami legalább megkönnyíti a megtalálásukat. - A kérésben csak az utolsó üzenet értékelődik, és annak is csak a szöveges része. A képi bemeneteket, base64-et vagy URL-t, egyáltalán nem ellenőrzi. - A guardrailok nem futnak az Assistants, Audio, Images, Files, Batch, Fine-tuning, Moderations és Models végpontokon. Futnak a chat completions, completions, embeddings (csak bemenet) végpontokon, a messages, responses és prompt completions felületen. - A streamelt válaszon futó kimeneti guardrailok tájékoztató jellegűek: az eredmény a done mark utáni utolsó chunkban érkezik, és nem indít fallbacket vagy retry-t. - Ahhoz, hogy egyáltalán lássad a hook eredményeket egy streamben, a szigorú OpenAI-kompatibilitást ki kell kapcsolni a `x-portkey-strict-open-ai-compliance` fejléccel, mert alapértelmezés szerint levágja őket. - A szintek a csomagot követik: alap ellenőrzések a Developer csomagban, alap, partner és pro ellenőrzések a Productionben, minden, sajátot is beleértve, az Enterprise-ben. A legtöbb ellenőrzés determinisztikus, regex, JSON séma, szó- és karakterdarabszámlálás, ezek fölött LLM-alapú ellenőrzések, például promptinjekciós vizsgálat. - Partner guardrailok léteznek, köztük az Aporia, a Pillar Security, a SydeLabs, a Zscaler AI Guard és az Akto, mind HTTP-n hívva, saját timeouttal: 10 000 ms a Zscalernél, 5 000 ms az Aktónál. Az Anthropic útvonalon még egy akadály van. A `/v1/messages` felületen a hook eredmények külön eseményként érkeznek, amelyet az Anthropic SDK nem parse-ol, így azok olvasásához vissza kell esni cURL-re. Épp ilyen kis inkonzisztenciák döntik el, hogy egy funkciót használnak-e vagy csendben figyelmen kívül hagyják, és érdemes ezt a saját SDK-d ellen ellenőrizni, mielőtt guardrail-alapú kontrollra építesz. ## Ár és késleltetés A késleltetésnél a marketing és a mérés szétválik. Három szám létezik ugyanarra a termékre, és nem ugyanazt írják le. Ezért az alábbi táblázat minden számnál megnevezi a forrását, ahelyett hogy a leghízelesebbet választaná. Szám Forrás Mit mér 1 ms alatt Az átjáró repository README-je A saját üzemeltetésű proxy saját feldolgozási ideje, nem a menhelyezett oda-visszaút 10 ms alatt, 99,9999%-os rendelkezésre állással Anbiateri blog, 2025 október Egy hosztolási állítás havi 10 milliárd kérésre, publikált módszertan nélkül Átlagosan plusz 93 ms, mediánban plusz 25 ms A Portkey saját benchmark-repója A felhős átjáró egy közvetlen Bedrock-híváshoz képest, két worker, iterációnként három kérés Tipikusan 50–150 ms Ugyanaz a repó, overhead szakasz Amit a gyártó maga a két további hálózati ugrás oda-vissza költségének nevez Az őszinte olvasat az, hogy a két szám két különböző terméket ír le. Az 1 ms alatti érték az open source proxy feldolgozási ideje, ez tényleg jó, és ez a fő érv a saját üzemeltetés mellett. A 10 ms alatti állítás hosztolási állítás módszertan nélkül. A plusz 93 ms az egyetlen, amely mellett futtatható tesztkörnyezet is van, és ugyanaz a repó 50–150 ms-ot nevez tipikusnak. Egy 400 ms-os első token idő mellett ez láthatatlan; egy 90 ms-os autocomplete vagy beszédúton az egész keretet viszi el. Tehát mérd a saját forgalmadon, ne az árajelzőlapról vedd át. Az árnál: a számlázás rögzített naplókon alapul, nem kéréseken. Ez szokatlalan és általában ártalmatlan, mert az ingyenes csomag a naplókorlát után is kiszolgál, csak már nem naplóz. A fizetős csomagoknál lesz fontos, mert a túlfogyás ára 100 ezer kérésenként rakódik a naplókeretre. Csomag Ár Rögzített naplók Megőrzés és tartalom Developer Ingyenes 10 000 havonta 3 nap naplóra, 30 nap metrikára; 3 prompt sablon; determinisztikus guardrailok; közösségi támogatás; a kérések a korlát után is folytatódnak Production 49 dollár havonta 100 000, utána 9 dollár minden további 100 000-re 30 nap naplóra, 90 nap metrikára; szerepkör-alapú hozzáférés, service account kulcsok, LLM- és partner guardrailok, szemantikus cache, termelési támogatás Enterprise Megkérdezés alapján 10 millió vagy több Egyedi megőrzés; privát felhő és VPC hosting, SSO, adat export, SOC 2 Type 2, GDPR és HIPAA, adatizoláció **Az árlap és a cache-dokumentáció nem fér össze** A csomag-összehasonlító táblázat az egyszerű és a szemantikus cache-t a 49 dolláros Production csomag alatt sorolja fel, míg a cache-dokumentáció szerint a szemantikus cache vektortárolót igényel, és csak kiválasztott Enterprise csomagokban érhető el. Érdemes tisztázni, mielőtt szemantikus cache-találati arányra építenél költségmodellt. Az Enterprise csomagban más termék lesz belőle: data plane a saját VPC-dben, Helm chartok Kubernetes 1.20 vagy újabb verzióval, példányonként egy-két mag és két-négy gigabyte memória, naplók S3-kompatibilis objektumtárban vagy MongoDB-ben, és egy control plane, amelyet az átjáró percenként egyszer szinkronizál, miközben hétnapos helyi cache-ben tartja a configokat és a kulcsokat. A dokumentáció volatile-lru kiszorítási stratégiát javasol, hogy az élő konfiguráció túlélje a memórianyomást. Ez egy üzemeltetendő rendszer, nem egy felejthető konténer. ## Hol nem passzol Először az őszinte gyengeségek, mert ezek csapatok egész csoportjait kizárják. A menhelyezett átjáró egyetlen meghibadási pont és egyetlen bérlős határ az alkalmazás összes kérésére, és a státuszoldalon vannak is control plane incidensek, köztük 2026 augusztusában egy 40 perces és egy kétórás. A szemantikus cache enterprise tárgyalás mögött van, így azt a költségcsökkentő funkciót, amellyel az üzleti tervek érvelnek, nem is kapják meg. A guardrail modell csak az utolsó üzenetet olvassa, tehát nem promptinjekció-védelem egy multimodális beszélgetéshez. A config pedig egy SaaS dashboardon lakik, vagyis egy rendszer routing-politikája már nem abban a repositoryban review-elhető, amelyik a rendszert birtokolja. Eszköz Licenc és költség Hol fut Amit nem tud Portkey MIT átjáró, control plane 49 dollártól Szolgáltatói felhő, vagy saját VPC az Enterprise-ben Soha nem olvas képet; a szemantikus cache a menhelyezett csomagban csak Enterprise LiteLLM MIT, saját üzemeltetés ingyenes, Enterprise kérésvolumenre árazva Csak a saját infrastruktúrád Nincs menhelyezett csomag, tehát nincs menhagyott dashboard, megosztott guardrail vagy hitelesítőtár OpenRouter Fizetés tokenenként, 5,5 százalék platformdíj a kreditvásárláson Az ő felhőjük Nincs saját üzemeltetésű átjáró; a BYOK 25 000 dollár/hó listaárú inferekencia fölött indul Cloudflare AI Gateway A alapfunkciók minden csomagban ingyenesek, a guardrailok Workers AI inferekenciaként számlázódnak Cloudflare edge, nagy forgalomnál Workers fizetős csomag kell A guardrail ellenőrzések Llama Guard 3 8B a Workers AI-on, saját logika nélkül A választás tehát kevésbé a funkciókról, mint a helyről szól: hol legyen a politika? Ha a routing szabályoknak a kód mellett, verziókövetésben kell lenniük, a LiteLLM nyer minden dimenzióban, a költséget is beleértve. Ha egy biztonsági csapatnak kell tudnia módosítania őket, ha a hitelesítő adatok soha nem kerülhetnek alkalmazáskörnyezetbe, vagy ha egy olyan szabályozott környezetben működsz, amely amúgy is a Palo Alto Networks-től vásárol, akkor a Portkey control plane az érv. A harmadik lehetőség, amit érdemes árszámolni, a Cloudflare AI Gateway: a alapfunkciók minden csomagban ingyenesek, és a költség inferekencia, nem platform, ami kis forgalomnál megfordítja a számítást. ## Ítélet A Portkey a legteljesebb menhelyezett LLM-átjáró, ami elérhető, és már önmagában a config objektum jobb tervezés, mint a kézzel írt megfelelőinek többsége: ágyazható stratégiák, zárt séma, kemény padló a circuit breaker cooldownján. Akkor érdemes, ha a routing politika kormányzási probléma, nem pedig programozási, és ilyenkor elfogadod a hálózati ugrást, és azt is, hogy a routing konfigurációd már nem a saját repositorydban lakik. A véleményes rész: ez nagyvállalatoknak a jó alapértelmezettje, kis csapatnak rossz, akiknek inkább az open source proxy ingyenes csomagja vagy a LiteLLM és egy hétvégi bekötés szolgál. 1. Vedd a Portkey-t, ha több csapat osztozik a modell-hitelesítő adatokon, és valakinek központilag kell felelnie a keretekért, az allow listákért és a rate limitekért. Ez a termék valódi feladata. 2. Vedd, ha egy biztonsági csapatnak deploy nélkül kell tudnia módosítania a guardrailokat és megnéznie a teljes kérésnaplókat. 3. Ne vegyél késleltetésérzékeny completion vagy beszédútra, amíg nem mérted a saját forgalmodon az ugrást, mert a publikált többletidő kétjegyű ezredmásodperc, a marketing szám nem az. 4. Ne építs guardrailokra promptinjekció kontrollként multimodális forgalomhoz. Nem olvasnak képet, és csak az utolsó üzenetet. 5. Kerüld, ha a routing-politikát kódellenőrzésen kell átverni. Azt a configot a repositoryban kell tartani, és ehhez a LiteLLM vagy az open source átjáró a jobb eszköz. 6. Gondold át újra, amikor a control plane szűk keresztmetszetté válik: ekkora forgalomnál egy Cloudflare-on futó átjáró vagy egy saját VPC-beli proxy olcsóbb és egyszerűbb, mint az enterprise csomag. **A szám, amit vásárlás előtt ellenőrizni kell** Kérd a többletidőt a te régiód és a tényleg használt szolgáltatói régió között mérve, olyan kérésformával, amely illik a saját első token idődre. A Portkey saját repója pontosan erre publikál tesztkörnyezetet, és az jóval rosszabb számot ad, mint a főoldal. ## Források 1. [Portkey dokumentáció: AI Gateway](https://portkey.ai/docs/product/ai-gateway) 2. [Portkey dokumentáció: első lépések az AI Gatewaayvel](https://docs.portkey.ai/docs/guides/getting-started/getting-started-with-ai-gateway) 3. [Portkey dokumentáció: gateway config objektum](https://portkey.ai/docs/api-reference/config-object) 4. [Portkey dokumentáció: guardrailok](https://portkey.ai/docs/product/guardrails) 5. [Portkey dokumentáció: guardrail végpontok és képességek](https://portkey.ai/docs/product/guardrails/capabilities) 6. [Portkey dokumentáció: cache, egyszerű és szemantikus](https://portkey.ai/docs/product/ai-gateway/cache-simple-and-semantic) 7. [Portkey dokumentáció: load balancing](https://portkey.ai/docs/product/ai-gateway/load-balancing) 8. [Portkey dokumentáció: enterprise hibrid telepítés architektúrája](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture) 9. [Portkey árazás](https://portkey.ai/pricing) 10. [Portkey gateway a GitHubon, MIT-licencű](https://github.com/Portkey-AI/gateway) 11. [A Portkey saját benchmarkja: átjáró kontra közvetlen Bedrock](https://github.com/Portkey-AI/benchmark-test) 12. [Portkey státuszoldal](https://status.portkey.ai/) 13. [A Palo Alto Networks lezárja a Portkey felvásárlását, 2026. május](https://www.paloaltonetworks.com/company/press/2026/palo-alto-networks-completes-acquisition-of-portkey-to-secure-ai-agents) 14. [Palo Alto Networks: Prisma AIRS AI Gateway](https://www.paloaltonetworks.com/ai-security/ai-gateway) 15. [Cloudflare AI Gateway árazás](https://developers.cloudflare.com/ai-gateway/reference/pricing/) 16. [LiteLLM árazás](https://www.litellm.ai/pricing) 17. [OpenRouter árazás](https://openrouter.ai/pricing) ## Gyakori kérdések Mi a Portkey, és mit csinál valójában egy LLM-átjáró? Az LLM-átjáró proxy, amely a kliens és a hívott modellszolgáltatók közé kerül. A Portkey átjárója a szolgáltatói kulcsokat, retry-ket, fallbackeket, súlyozott routingot, cache-t, guardrailokat és költség-hozzárendelést JSON-konfigurációba szervezi, ami a kéréshez csatolódik. Így az OpenAI-kompatibilis kliens változatlanul működik, miközben a routing-politika a dashboardon, nem pedig egy deployban változik. Ad-e késleltetést a Portkey a modellhívásokhoz? A menhelyezett változat igen. A Portkey saját benchmark-repója átlagosan plusz 93 ms-t, mediánban plusz 25 ms-t mér a felhős átjáró és a közvetlen Bedrock-hívás között, a README pedig 50–150 ms-ot nevez tipikusnak a két további ugrásra. Saját üzemeltetésnél más a szám: az átjáró repója 1 ms alatti feldolgozási időt említ. Nyílt forrású-e a Portkey? Az átjáró MIT-licencű, és egyetlen npm paranccsal indul el; a kiadott csomag jelenleg az 1.15.2-es verziónál tart, egy 2.0 előkiadási ág készül. A control plane, a dashboard, a Model Catalog és az enterprise telepítési lehetőségek kereskedelmi termékek. Az átjáró saját futtatása nem adja meg a menhelyezett terméket. Portkey vagy LiteLLM? A LiteLLM MIT-licencű, menhelyezett szint nélkül, ezért nyer a költségen és az adatokon is, ahol a hálózaton belül maradnak; a dashboardokat magad építed. A Portkey akkor nyer, ha a routing-politika, a guardrailok és a tárolt hitelesítő adatok egy másval által üzemeltetett termékben akarnak élni, és elfogadod a havi 49 dollárt 100 ezer naplóért, plusz 9 dollárt minden további 100 ezerért. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [DeepSeek V4.1 Flash 1017: 890 bájt KV-cache tokenenként, és mit nyer ezzel egy ágens](https://balazscsorba.com/hu/blog/deepseek-v4-1-flash-1017) - [LLM rate limitek élesben: újrapróbálás, backoff és szolgáltatóváltás](https://balazscsorba.com/hu/blog/llm-rate-limits-retries-provider-fallback) - [Promptverziózás élesben: git, registry, címkék és visszaállítás](https://balazscsorba.com/hu/blog/prompt-versioning-management) - [LLM batch API-k: félárú inferencia olyan munkára, amely várhat](https://balazscsorba.com/hu/blog/llm-batch-api-offline-workloads) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)