Jak przestać pisać adaptery do sieci neuronowych i przejąć kontrolę nad kosztami tokenów

Ostatnio przepisywałem integrację z Claude na zaktualizowanego klienta i złapałem się na myśli. Jednego dnia klienci proszą o połączenie GPT-4o, następnego domagają się Anthropic, a tydzień później dział finansowy pyta skąd wzięła się kilkusetdolarowa faktura za testy. Za każdym razem muszę dodawać logikę obsługi błędów, zarządzać kluczami i ręcznie obliczać wydatki na tokeny.

Tej rutynie zaradza LLM Gateway od zespołu The Open Co. Projekt pełni rolę ujednoliconej bramki API, która przyjmuje wywołania w standardowym formacie OpenAI i kieruje je do odpowiednich dostawców.

Jedno żądanie dla dowolnego modelu

Główna koncepcja jest prosta. Zamiast integrować wiele zestawów SDK, wysyłasz pojedyncze żądanie HTTP do lokalnej lub chmurowej bramki. Kontroler automatycznie identyfikuje docelowego dostawcę, przekształca format i zwraca odpowiedź.

Obecnie wspierani są główni dostawcy:

• OpenAI
• Anthropic
• Google Vertex AI
• Inne usługi z kompatybilnymi API

Oto jak wygląda standardowe żądanie do bramki:

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -d '{
  "model": "gpt-4o",
  "messages": [
    {"role": "user", "content": "Hello, how are you?"}
  ]
}'

Jeśli chcesz przełączyć się na Claude 3.5 Sonnet, struktura JSON w Twojej aplikacji pozostaje bez zmian. Zmienia się tylko nazwa modelu w ciele żądania.

Śledzenie kosztów i metryki opóźnień

Gdy wiele usług lub programistów pracuje z sieciami neuronowymi, kontrolowanie limitów staje się trudne. Czasami ktoś uruchamia skrypt z nieprawidłowym promptem w nieskończonej pętli i zużywa miesięczny budżet w ciągu godziny.

Bramka zajmuje się śledzeniem. Każda transakcja jest zapisywana w bazie danych, a system automatycznie oblicza:

• Liczbę tokenów wejściowych i wyjściowych
• Całkowity koszt każdego wywołania
• Czas odpowiedzi modelu
• Ogólne statystyki według kluczy i projektów

Przez panel internetowy można przeglądać gotowe wykresy i natychmiast zobaczyć, który konkretny model pochłania większość budżetu.

Struktura projektu i uruchomienie w Dockerze

Autorzy zbudowali monorepo w TypeScripcie. Pod maską wykorzystano sprawdzone technologie:

• Hono obsługuje proxyowanie żądań API
• Next.js zarządza interfejsem webowym i placem zabaw
• Drizzle ORM pracuje z bazami danych PostgreSQL i Redis
• TypeScript zapewnia typowanie end-to-end komponentów

Możesz wdrożyć własną usługę w kilka minut za pomocą Docker. Autorzy złożyli gotowy obraz łączący główne komponenty.

docker volume create llmgateway_postgres
docker volume create llmgateway_redis

docker run -d \
  --name llmgateway \
  --restart unless-stopped \
  -p 3002:3002 \
  -p 3003:3003 \
  -p 3005:3005 \
  -p 3006:3006 \
  -p 4001:4001 \
  -p 4002:4002 \
  -v llmgateway_postgres:/var/lib/postgresql/data \
  -v llmgateway_redis:/var/lib/redis \
  -e AUTH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  -e GATEWAY_API_KEY_HASH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  ghcr.io/theopenco/llmgateway-unified:latest

Mały szczegół z dokumentacji: nie montuj folderu z maszyny hosta bezpośrednio do /var/lib/postgresql/data. Ze względu na specyfikę inicjalizacji uprawnień PostgreSQL w kontenerze, proces może się zawiesić. Nazwane woluminy w powyższym poleceniu eliminują ten problem.

Jeśli chcesz najpierw wypróbować system bez wdrażania, deweloperzy mają wersję chmurową na llmgateway. io.

Ograniczenia wersji darmowej

Repozytorium używa podwójnego licencjonowania. Główny kod jest rozpowszechniany na licencji AGPLv3, jednak niektóre foldery w kodzie źródłowym należą do wersji Enterprise.

W bezpłatnej wersji open source historia wywołań jest przechowywana przez 30 dni. Jeśli potrzebujesz nieograniczonego przechowywania logów, zaawansowanego rozliczania użytkowników lub podziału zespołów w ramach organizacji, musisz zakupić licencję komercyjną.

Kto skorzysta na tym narzędziu

Jeśli Twoja aplikacja wykonuje trzy żądania dziennie do jednego modelu, nie ma sensu konfigurować osobnego proxy. Po prostu dodasz dodatkowy punkt awarii i pomijalne opóźnienie sieciowe.

Bramka sprawdzi się w następujących sytuacjach:

• Projekt korzysta z modeli różnych dostawców
• Wymagane jest przejrzyste śledzenie kosztów tokenów w różnych usługach
• Potrzebne jest wdrożenie proxy we własnym środowisku
• Planowane jest szybkie przełączanie awaryjne na zapasowy model w przypadku awarii

Możesz wypróbować projekt na GitHub. README jest tam dość minimalistyczne, ale projekt jest zrozumiały nawet bez rozbudowanych instrukcji.