Portkey: éles LLM-átjáró, routing, guardrailok és költség szerint

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.

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.

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á.

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.

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.

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.

Források

1. Portkey dokumentáció: AI Gateway
2. Portkey dokumentáció: első lépések az AI Gatewaayvel
3. Portkey dokumentáció: gateway config objektum
4. Portkey dokumentáció: guardrailok
5. Portkey dokumentáció: guardrail végpontok és képességek
6. Portkey dokumentáció: cache, egyszerű és szemantikus
7. Portkey dokumentáció: load balancing
8. Portkey dokumentáció: enterprise hibrid telepítés architektúrája
9. Portkey árazás
10. Portkey gateway a GitHubon, MIT-licencű
11. A Portkey saját benchmarkja: átjáró kontra közvetlen Bedrock
12. Portkey státuszoldal
13. A Palo Alto Networks lezárja a Portkey felvásárlását, 2026. május
14. Palo Alto Networks: Prisma AIRS AI Gateway
15. Cloudflare AI Gateway árazás
16. LiteLLM árazás
17. OpenRouter árazás