Bramka LLM

Jedna bramka LLM do każdego modelu, który wdrażasz.

Zmień adres bazowy i kieruj wywołania do OpenAI, Anthropic, Gemini, Mistral i Groq przez jeden punkt dostępu — z zasadami routingu, limitami wydatków, księgą kosztów każdego wywołania oraz routingiem do UE lub USA.

Dwie linie, by przejść przez bramkę
import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.odnoga.com/v1",   // <- the gateway
  apiKey: process.env.ODNOGA_API_KEY,        // <- your odnoga key
});

const res = await client.chat.completions.create({
  model: "auto",                             // or "gpt-5-mini", "claude-haiku-4-5", ...
  messages: [{ role: "user", content: "Hello" }],
});
Co robi bramka

Routing z przodu, rozliczenia z tyłu.

Jeden endpoint zgodny z OpenAI

Skieruj istniejące SDK do odnogi i korzystaj z OpenAI, Anthropic, Gemini, Mistral, Groq i innych bez przepisywania kodu klienta.

Zasady routingu i modele zapasowe

Kieruj ruch według kosztu, czasu odpowiedzi lub możliwości, z automatycznym przełączeniem na sprawny model, gdy dostawca ma problemy.

Budżety, limity i współbieżność

Twarde i miękkie limity wydatków dla organizacji, obszaru roboczego, użytkownika końcowego i modelu oraz wspólna pula równoległych wywołań dla organizacji.

Wykryj, gdy proces przestaje działać

odnoga porównuje ruch każdej aplikacji i funkcji z jej własną normą. Informuje, gdy proces przestaje wysyłać wywołania lub nagle generuje ich znacznie więcej, a liczba odrzuceń pokazuje, czy najpierw sprawdzić odnogę, czy własny system.

Księga kosztów każdego wywołania

Każde wywołanie tworzy dokładny wpis w księdze: tokeny wejściowe i wyjściowe, koszt dostawcy, opłatę odnogi oraz odbiorcę rozliczenia.

Routing regionalny z dowodem

Wybierz punkty końcowe w UE lub USA i zachowaj dowód miejsca, w którym rzeczywiście obsłużono każde wywołanie.

Wersjonowane prompty i A/B

Prompty żyją w bramce, nie w repo — wersjonuj, testuj A/B, cofaj jednym kliknięciem.

Architektura

Jak działa bramka LLM — krok po kroku

Bramka jest warstwą sterowania przed dostawcami modeli. Aplikacja uwierzytelnia się raz, a bramka stosuje ustalone zasady, wybiera model, wywołuje dostawcę zapisanym kluczem i rejestruje rozliczenie przed zwróceniem odpowiedzi.

01

Uwierzytelnienie i identyfikacja

Klucz API bramki wskazuje organizację, obszar roboczy oraz — po przesłaniu nagłówka użytkownika końcowego — osobę, do której należy wywołanie.

02

Kontrola dopuszczenia

Budżet, limity i współbieżność są sprawdzane przed kontaktem z dostawcą, dlatego przekroczenie zostaje zablokowane, zamiast pojawić się dopiero na fakturze.

03

Decyzja routingu

Zasady routingu przypisują alias do konkretnego modelu na podstawie kosztu, czasu odpowiedzi, możliwości i rezydencji danych oraz zachowują ustaloną kolejność modeli zapasowych.

04

Ujednolicone wywołanie dostawcy

Jedno wywołanie w formacie OpenAI jest tłumaczone na format dostawcy — obsługa narzędzi, obrazów, rozumowania i wyszukiwania w sieci różni się między usługami.

05

Pomiar i zapis do księgi

Liczba tokenów i cennik dostawcy tworzą dokładny wpis w księdze: koszt dostawcy, opłatę odnogi i kwotę do rozliczenia, przypisane do obszaru roboczego lub użytkownika końcowego.

06

Obserwowalność i dowód

Logi wywołań zapisują użyty model, ścieżkę modeli zapasowych, region obsługi i czas odpowiedzi, zapewniając dane potrzebne podczas incydentów i audytów.

your app ──▶ gateway ──▶ auth + budget check ──▶ routing policy ──▶ vendor (EU/US endpoint)
                 │                                                        │
                 └──────────── ledger entry + request log ◀───────────────┘

Kiedy jej nie potrzebujesz: aplikacja korzystająca z jednego modelu, bez potrzeby rozliczania klientów i wymogów zgodności, zwykle może łączyć się bezpośrednio z dostawcą. Bramka zarabia na siebie, gdy pojawia się drugi model, drugi klient albo druga osoba zmieniająca prompty.

Kiedy jest potrzebna

Sygnały, że bezpośrednie wywołania dostawcy już nie wystarczają

  • Nazwy modeli i prompty są zapisane na stałe w funkcjach brzegowych, a nikt nie wie, która wersja działa na produkcji.
  • Nie potrafisz powiedzieć, ile jeden klient kosztuje Cię w AI w tym miesiącu.
  • Awaria dostawcy albo wyczerpanie środków na kluczu wyłącza funkcję bez modelu zapasowego.
  • Część klientów wymaga routingu do UE, ale nie potrafisz wykazać, gdzie obsłużono ich wywołania.
  • Dodanie nowego dostawcy oznacza kolejne SDK, kolejny magazyn kluczy i kolejną pozycję na fakturze.
FAQ

Pytania o bramkę LLM

Czym jest bramka LLM (LLM gateway)?

Bramka LLM to jeden endpoint API pomiędzy Twoją aplikacją a dostawcami modeli. Zamiast przechowywać osobno klucze OpenAI i Anthropic, korzystasz z jednego interfejsu oraz warstwy operacyjnej: routingu, ponawiania wywołań, limitów wydatków, logów i przypisywania kosztów.

Czym bramka różni się od proxy LLM?

Proxy przekazuje wywołania. Bramka dodatkowo decyduje, dokąd trafią, egzekwuje limity przed kontaktem z modelem i zapisuje koszty po odpowiedzi. odnoga łączy zasady routingu z pełną księgą rozliczeń.

Czy muszę zmieniać kod?

Wystarczy zmienić adres bazowy i klucz API. Interfejsy do czatu i embeddingów są zgodne z OpenAI, więc oficjalne SDK, LangChain, n8n i większość narzędzi działa bez zmian.

Czyje klucze dostawców są używane?

Twoje. Dodajesz własne klucze OpenAI, Anthropic lub Gemini do obszaru roboczego, a odnoga kieruje przez nie ruch — zachowujesz własne ceny i limity u dostawcy.

Czy mogę przez nią fakturować własnych klientów?

Tak. Jeden nagłówek identyfikujący użytkownika końcowego wystarczy, aby przypisać i rozliczyć każde wywołanie. Zobacz stronę o rozliczeniach wielu klientów.

Czy mój agent kodujący może tym zarządzać?

Tak. odnoga udostępnia warstwę sterowania przez MCP, więc Claude, Cursor lub własny agent mogą odczytywać użycie oraz zarządzać kluczami, promptami i zasadami routingu.

Powiązane: Bramka AI · katalog modeli i ceny · rozliczenia wielu klientów · bezpieczeństwo i rezydencja · porównanie odnogi

Połącz wszystkie modele przez jeden endpoint.