Wróć do katalogu
LiteLLM: The Universal LLM Gateway (v1.82 - 2026 Edition)
Kompleksowa seria podcastów o LiteLLM, obejmująca wszystko od Python SDK i ujednoliconej obsługi wyjątków, przez Proxy Server, load balancing, Virtual Keys i obserwowalność, aż po funkcje korporacyjne takie jak RBAC i MCP Gateway.
Teraz odtwarzane
Click play to start
0:00
0:00
1
Kamień z Rosetty dla LLM: Python SDK
Odkryj główną tożsamość LiteLLM: ujednolicony interfejs Python dla ponad 100 modeli LLM. Dowiedz się, jak wdrożyć LiteLLM do istniejącej bazy kodu, aby odpytywać modele Anthropic, Vertex czy Ollama bez zmiany logiki parsowania kompatybilnej z OpenAI.
2
Magia tłumaczenia parametrów
Przestań się martwić, który dostawca obsługuje dany hiperparametr. Dowiedz się, jak SDK LiteLLM automatycznie tłumaczy standardowe wejścia OpenAI, takie jak temperature, tools i max_tokens, dla wszystkich modeli upstreamowych.
3
Ujednolicona obsługa wyjątków
Napisz swoje bloki try-except tylko raz. Odkryj, jak LiteLLM przechwytuje niestandardowe błędy z AWS, Google i Azure, idealnie mapując je na standardowe wyjątki OpenAI, takie jak RateLimitError.
4
Brama LLM: Konfiguracja Proxy Server
Przenieś LiteLLM ze swojego lokalnego kodu na scentralizowaną platformę. Dowiedz się, jak uruchomić LiteLLM Proxy Server za pomocą Dockera i skonfigurować pierwsze endpointy przy użyciu pliku config.yaml.
5
Scentralizowane zarządzanie sekretami
Trzymaj swoje klucze API z dala od konfiguracji w postaci zwykłego tekstu. Dowiedz się, jak połączyć LiteLLM z korporacyjnymi menedżerami sekretów, takimi jak AWS Secrets Manager czy Azure Key Vault, aby dynamicznie pobierać poświadczenia.
6
Model Aliases: Cicha aktualizacja
Migruj użytkowników do nowych modeli w sposób niezauważalny. Odkryj, jak używać Model Aliases w LiteLLM, aby mapować żądania dla jednego modelu na zupełnie inny endpoint bez modyfikowania kodu po stronie klienta.
7
Load Balancing dla wysokiej przepustowości
Unikaj limitów zapytań i przestojów dzięki inteligentnemu kierowaniu ruchem. Sprawdź, dlaczego simple-shuffle jest rekomendowaną strategią dla produkcyjnego load balancingu pomiędzy wieloma wdrożeniami.
8
Awarie API i mechanizmy Fallback
Nigdy więcej nie doświadczaj przestojów AI. Dowiedz się, jak skonfigurować mechanizmy fallback dla modeli w LiteLLM, aby w przypadku awarii głównego dostawcy ruch był automatycznie przekierowywany do dostawcy zapasowego.
9
Fallbacki dla okna kontekstowego
Przestań przepłacać za ogromne okna kontekstowe przy krótkich promptach. Dowiedz się, jak używać weryfikacji pre-call oraz mechanizmów fallback dla okna kontekstowego, aby kierować zbyt duże dokumenty do wyspecjalizowanych modeli.
10
Okiełznanie zawieszonych żądań za pomocą Timeoutów
Nie pozwól, aby wolne API zamroziły Twoją aplikację. Odkryj, jak skonfigurować global timeouts i stream timeouts w LiteLLM, aby przerywać zawieszone żądania i uruchamiać szybkie mechanizmy fallback.
11
Virtual Keys dla FinOps
Precyzyjnie zabezpiecz użycie swojego API. Dowiedz się, jak generować Virtual Keys za pomocą LiteLLM, ustawiając rygorystyczne limity RPM, TPM i budżetowe, aby chronić organizację przed niekontrolowanymi kosztami AI.
12
Śledzenie wydatków i niestandardowe tagi
Dokładnie przypisuj każdego centa wydanego na LLM. Dowiedz się, jak przekazywać tagi metadanych w swoich żądaniach i generować kompleksowe raporty wydatków za pomocą LiteLLM.
13
Cache'owanie dla szybkości i oszczędności
Przestań płacić za te same odpowiedzi LLM w kółko. Dowiedz się, jak skonfigurować exact caching z Redis i semantic caching z Qdrant, aby drastycznie zmniejszyć opóźnienia i koszty API.
14
RBAC: Wzmacnianie pozycji Team Admins
Bezpiecznie rozdzielaj zarządzanie platformą. Zrozum Role-Based Access Control (RBAC) w LiteLLM, delegując uprawnienia do Org Admins i Team Admins bez narażania globalnego bezpieczeństwa.
15
Security Guardrails
Dodaj niewidoczną warstwę bezpieczeństwa do swoich żądań LLM. Dowiedz się, jak skonfigurować pre-call i post-call guardrails w LiteLLM, aby blokować prompt injections i maskować dane osobowe (PII), zanim dotrą do zewnętrznych dostawców.
16
Dynamiczne zarządzanie callbackami
Daj mikrousługom siłę prywatności. Dowiedz się, jak używać nagłówka x-litellm-disable-callbacks, aby wrażliwe żądania API mogły zrezygnować z centralnego logowania obserwowalności.
17
Obserwowalność typu drop-in
Zyskaj natychmiastowy wgląd w swój ruch LLM. Dowiedz się, jak przesyłać telemetrię, ślady (traces) i wyjątki do narzędzi takich jak Langfuse i Sentry, używając prostych callbacków dla sukcesów i błędów.
18
Metryki Prometheus i kondycja Podów
Trzymaj rękę na pulsie swojego proxy. Odkryj, jak wystawić endpoint /metrics dla Prometheus, śledzić żądania in-flight i używać niestandardowych tagów do analizy danych w Grafana.
19
Uniwersalne Text-to-Speech
Ustandaryzuj generowanie głosu. Odkryj, jak odpytywać modele Text-to-Speech z Gemini, Vertex i AWS Polly, używając dokładnie tego samego formatu endpointu audio kompatybilnego z OpenAI.
20
Mostek Assistants API
Zarządzaj stanem konwersacji bez wysiłku u różnych dostawców. Dowiedz się, jak LiteLLM opakowuje nienatywne modele w standardowy interfejs OpenAI Assistants API, pozwalając Ci używać Threads i Messages wszędzie.
21
MCP Gateway
Centralnie wzmocnij swoje modele za pomocą narzędzi. Odkryj, jak skonfigurować serwery Model Context Protocol (MCP) oparte na HTTP, SSE lub STDIO w LiteLLM, dając każdemu LLM dostęp do zewnętrznych możliwości.
22
A2A: Śledzenie autonomicznych agentów
Przejmij kontrolę nad autonomicznymi agentami. Dowiedz się, jak wywoływać złożonych agentów LangGraph lub Bedrock przez proxy za pomocą protokołu A2A, co umożliwia grupowanie śladów (trace grouping) i ujednolicone śledzenie wydatków.
23
Rotacja kluczy bez przestojów (Zero-Downtime)
Osiągnij bezprzestojowe przełączenia bezpieczeństwa. Dowiedz się, jak skonfigurować automatyczne, zaplanowane rotacje kluczy i okresy karencji dla korporacyjnych Virtual Keys w LiteLLM.
24
Admin UI oraz AI Hub
Spraw, by Twoja platforma AI była dostępna dla każdego. Dowiedz się, jak zarządzać Admin UI, dostosowywać poświadczenia interfejsu i używać AI Hub, aby pozwolić programistom na bezpieczne odkrywanie dozwolonych modeli i agentów.
Odcinki
1
Kamień z Rosetty dla LLM: Python SDK
4m 13sOdkryj główną tożsamość LiteLLM: ujednolicony interfejs Python dla ponad 100 modeli LLM. Dowiedz się, jak wdrożyć LiteLLM do istniejącej bazy kodu, aby odpytywać modele Anthropic, Vertex czy Ollama bez zmiany logiki parsowania kompatybilnej z OpenAI.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny gateway LLM, odcinek 1 z 24. Podmieniasz swój klucz API OpenAI na klucz Anthropic i nagle cała twoja aplikacja się wysypuje. Każdy provider inaczej formatuje swoje inputy i outputy, zmuszając cię do pisania i utrzymywania customowej logiki parsowania dla każdego nowego modelu. Kamień z Rosetty dla LLM-ów, czyli LiteLLM Python SDK, całkowicie rozwiązuje ten problem.
Panuje błędne przekonanie, że LiteLLM konkuruje z LangChainem. Wcale tak nie jest. LiteLLM nie jest frameworkiem agentowym. Nie orkiestruje tooli, nie zarządza pamięcią ani nie łączy tasków w chainy. Jest po prostu drop-in replacementem dla klienta OpenAI.
LiteLLM Python SDK tłumaczy API ponad stu różnych providerów na dokładny format chat completion z OpenAI. Nie musisz uczyć się specyficznych niuansów API od Vertex AI, Anthropic czy Hugging Face. Piszesz swój kod raz, używając standardu OpenAI, a LiteLLM ogarnia warstwę translacji w tle.
Rdzeniem tego SDK jest pojedynczy, zunifikowany interfejs, czyli funkcja completion. Kiedy używasz tej funkcji, podajesz string z nazwą modelu. Ten string mówi LiteLLM, z którym providerem się skontaktować. Przekazujesz też standardowe parametry OpenAI, takie jak temperature, max tokens i listę messages. LiteLLM bierze te standardowe parametry i mapuje je na odpowiednie pola dla docelowego providera.
Wyobraź sobie scenariusz, w którym chcesz wywołać model Claude 3.5 Sonnet. Używając standardowego SDK od Anthropic, musiałbyś ustrukturyzować bloki promptów zgodnie z ich specyficznymi wymaganiami dla messages API. Z LiteLLM po prostu wywołujesz funkcję completion. Przekazujesz nazwę modelu dla Claude'a. Przekazujesz standardową tablicę messages, używając słowników z rolami user i system. Na koniec podajesz swój klucz API do Anthropic, jako parametr albo zmienną środowiskową.
I tu jest kluczowa sprawa. Obiekt response zwracany przez tę funkcję ma dokładnie taką samą strukturę, jak obiekt chat completion z OpenAI.
Kiedy chcesz wyciągnąć tekst wygenerowany przez Claude'a, przechodzisz dokładnie tę samą ścieżkę, co w przypadku modelu GPT. Patrzysz na tablicę choices. Bierzesz pierwszy element. Wchodzisz w obiekt message. Odczytujesz właściwość content. Logika twojej aplikacji nie ma pojęcia, że to Anthropic wygenerował ten tekst. Pod spodem request sieciowy został przetłumaczony, wysłany do providera, a response zmapowany z powrotem do schematu OpenAI, zanim w ogóle trafił do twoich zmiennych.
Ta abstrakcja dotyczy całej interakcji. Obejmuje błędy, statystyki zużycia tokenów, a nawet streaming responses. Jeśli Anthropic zwróci błąd rate limit, LiteLLM zmapuje go na standardowy exception rate limit z OpenAI. Twój obecny kod do error handlingu łapie go bez żadnych modyfikacji. Jeśli zażądasz streaming response, LiteLLM zwraca chunki, które wyglądają dokładnie tak samo jak streaming chunki z OpenAI.
Możesz iterować po różnych modelach, po prostu zmieniając wartość stringa w parametrze model i podmieniając zmienną środowiskową z kluczem API. Reszta twojego kodu w Pythonie pozostaje całkowicie statyczna. Nie jesteś już zamknięty w jednym ekosystemie tylko dlatego, że napisałeś kod integracyjny pod jednego konkretnego providera.
Prawdziwą wartością zunifikowanego interfejsu completion jest decoupling logiki twojej aplikacji od nieskończonych wariacji w API providerów modeli, co zamienia skomplikowane zmiany w infrastrukturze w proste podmiany stringów.
Dzięki za wysłuchanie, happy coding wszystkim!
2
Magia tłumaczenia parametrów
3m 48sPrzestań się martwić, który dostawca obsługuje dany hiperparametr. Dowiedz się, jak SDK LiteLLM automatycznie tłumaczy standardowe wejścia OpenAI, takie jak temperature, tools i max_tokens, dla wszystkich modeli upstreamowych.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 2 z 24. Czy Claude oczekuje max tokens, max tokens to sample, czy czegoś zupełnie innego? Za każdym razem, gdy zmieniasz providera modelu, zazwyczaj musisz przepisać cały payload żądania API, aby dopasować go do ich specyficznych konwencji nazewnictwa. Parameter Translation Magic to funkcja, która sprawia, że ten problem znika.
Kiedy wywołujesz funkcję completion w LiteLLM, zawsze piszesz swoje żądanie używając standardowego formatu parametrów OpenAI. Nie musisz szukać konkretnych kluczy słownikowych dla Anthropic, Vertex AI ani Cohere. Biblioteka przechwytuje twoje inputy w formacie OpenAI i automatycznie tłumaczy je na dokładną strukturę, jakiej wymaga docelowy provider.
Spójrzmy na konkretny scenariusz. Chcesz odpytać model Vertex AI Gemini. Potrzebujesz użyć function calling i chcesz, aby odpowiedzi były wysoce deterministyczne, więc ustawiasz temperature na zero przecinek dwa. Gdybyś pisał bezpośrednią integrację, Vertex ma swój własny, unikalny, głęboko zagnieżdżony sposób definiowania toolsów i ustawiania konfiguracji generowania modelu. Z LiteLLM całkowicie to ignorujesz. Budujesz swój array toolsów używając standardowej składni JSON od OpenAI. Przekazujesz ten array, razem z wartością temperature, bezpośrednio do wywołania completion. LiteLLM bierze te argumenty OpenAI, rozkłada je i buduje poprawny payload API Vertex AI przed wysłaniem requestu sieciowego.
To automatyczne mapowanie jest niesamowicie wydajne, ale wprowadza pewien edge case. Co się stanie, jeśli przekażesz parametr OpenAI, którego docelowy model po prostu w ogóle nie obsługuje? Być może określisz presence penalty, ale provider nie ma odpowiedniego konceptu. Domyślnie LiteLLM jest strict. Rzuci exception i wywołanie completion zakończy się błędem. To celowa decyzja projektowa. Zapobiega to cichej utracie konfiguracji, która może być kluczowa dla zachowania twojej aplikacji.
Strict failing jest bezpieczne, ale może być frustrujące, jeśli na produkcji dynamicznie routujesz prompty użytkowników do dziesiątek różnych modeli. Jeśli chcesz, aby wywołanie się powiodło niezależnie od drobnych niezgodności parametrów, dodajesz flagę drop params ustawioną na true wewnątrz swojego wywołania completion. Kiedy to włączysz, LiteLLM nadal tłumaczy wszystko, co potrafi poprawnie zmapować. Ale jeśli napotka parametr OpenAI, którego docelowy provider nie rozpoznaje, po prostu usuwa ten nieobsługiwany parametr z payloadu i wysyła resztę requestu. Wywołanie kończy się sukcesem, a nieobsługiwany parametr jest bezpiecznie ignorowany.
Jeśli wolisz elegancko obsługiwać te możliwości we własnym kodzie, zamiast polegać na cichym odrzucaniu, masz do dyspozycji wbudowane narzędzie do introspekcji. Możesz wywołać funkcję pomocniczą o nazwie get supported openai params. Podajesz nazwę modelu jako argument, a ona zwraca listę wszystkich standardowych parametrów OpenAI, które poprawnie mapują się na ten konkretny model. Pozwala to sprawdzić, co model faktycznie obsługuje w runtime, zanim wykonasz wywołanie completion.
Oto kluczowy wniosek. Prawdziwą wartością translacji parametrów jest to, że podnosi specyfikację API OpenAI ze specyficznego dla vendora schema do rangi uniwersalnego języka interfejsu dla całego twojego stacku aplikacji.
Dzięki za wysłuchanie, happy coding wszystkim!
3
Ujednolicona obsługa wyjątków
3m 53sNapisz swoje bloki try-except tylko raz. Odkryj, jak LiteLLM przechwytuje niestandardowe błędy z AWS, Google i Azure, idealnie mapując je na standardowe wyjątki OpenAI, takie jak RateLimitError.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 3 z 24. Pisanie własnej logiki obsługi błędów dla piętnastu różnych API AI to świetny sposób na zmarnowanie weekendu. Każde API ma swój własny, unikalny sposób, by powiedzieć ci, że wysyłasz zbyt wiele requestów albo że twój token jest nieważny. Żebyś nie musiał pisać w nieskończoność instrukcji warunkowych, LiteLLM używa Unified Exception Handling.
Zamiast uczyć się, jak Anthropic, Cohere czy Google zwracają swoje błędy, musisz obsłużyć tylko jeden standard. LiteLLM mapuje wszystkie exceptiony providerów bezpośrednio na standardowe typy exceptionów OpenAI. Jeśli request sfailuje, gateway przechwytuje surowy błąd, tłumaczy go na podstawie kodu statusu HTTP i odpowiedzi providera, a następnie rzuca odpowiedni błąd OpenAI.
Wyobraź sobie scenariusz, w którym używasz inference endpointu od Hugging Face. W godzinach szczytu endpoint jest przeciążony ruchem. Hugging Face odrzuci request. Gdybyś uderzał do ich API bezpośrednio, musiałbyś parsować ich specyficzny błąd HTTP pięć zero trzy service unavailable albo customowy komunikat o throttlingu. Dzięki ujednoliconemu mapowaniu exceptionów, nie potrzebujesz specyficznego exception handlera dla Hugging Face.
Strukturyzujesz swój kod używając standardowego bloku try wokół wywołania generacji. Tuż pod nim dodajesz blok except, zaprojektowany, by złapać OpenAI Rate Limit Error. Wewnątrz tego bloku odpalasz swoją standardową funkcję exponential backoff. Twoja aplikacja pauzuje, czeka i ponawia request. Jeśli później podmienisz Hugging Face na Vertex AI, twoja logika backoffu pozostanie dokładnie taka sama. OpenAI Rate Limit Error łapie zdarzenie throttlingu z Vertex równie niezawodnie.
To mapowanie pokrywa cały standardowy zestaw błędów. Możesz złapać OpenAI API Timeout Error, gdy zdalny serwer się zawiesi. Możesz złapać Authentication Error, gdy klucz API rotuje lub wygaśnie. Możesz obsłużyć API Connection Error w przypadku zerwania sieci, albo Bad Request Error, jeśli twój payload jest zniekształcony. Kod twojej aplikacji traktuje cały ekosystem AI tak, jakby komunikował się wyłącznie z jednym, przewidywalnym providerem.
Oto kluczowa rzecz. Czasami czysta abstrakcja ukrywa zbyt wiele kontekstu. Generyczny błąd bad request z OpenAI mówi ci, że wywołanie sfailowało, ale często musisz wiedzieć dokładnie dlaczego. Azure, na przykład, stosuje rygorystyczne filtry content policy. Jeśli Azure odrzuci prompt z powodu naruszenia wytycznych bezpieczeństwa, zmapowanie tego na generyczny błąd OpenAI grozi utratą konkretnej flagi bezpieczeństwa, którą musisz zalogować lub pokazać użytkownikowi.
Aby to rozwiązać, LiteLLM dołącza atrybut o nazwie provider specific fields do obiektu exception. Kiedy złapiesz exception OpenAI w swoim kodzie, możesz sprawdzić ten atrybut. Zawiera on słownik trzymający oryginalne, niezamapowane dane o błędzie prosto od providera. Dostajesz ujednolicony flow try i except do routingu i retry'ów, ale zachowujesz szczegółowe dane do debugowania i audytu.
Budujesz swoje odporne systemy, retry i circuit breakery w całości wokół klas exceptionów OpenAI. Standaryzacja granic błędów zapobiega przenikaniu specyficznych dla providera trybów awarii do core'owej logiki twojej aplikacji.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
4
Brama LLM: Konfiguracja Proxy Server
4m 19sPrzenieś LiteLLM ze swojego lokalnego kodu na scentralizowaną platformę. Dowiedz się, jak uruchomić LiteLLM Proxy Server za pomocą Dockera i skonfigurować pierwsze endpointy przy użyciu pliku config.yaml.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 4 z 24. Co by było, gdyby cała twoja firma mogła współdzielić jeden endpoint LLM bez ujawniania surowych kluczy API dostawcy? Przejście z lokalnej integracji SDK na scentralizowaną architekturę zmienia sposób, w jaki zarządzasz dostępem. To LLM Gateway: Konfiguracja serwera proxy.
Wielu developerów zakłada, że wprowadzenie customowego proxy middleware wymaga napisania customowego kodu klienta do komunikacji z nim. To nieprawda. Proxy LiteLLM obsługuje natywny format API OpenAI. Każda biblioteka, aplikacja czy skrypt, który potrafi komunikować się z OpenAI, wymaga jedynie aktualizacji swojego base URL, aby wskazywał na twój nowy serwer proxy.
Aby uruchomić serwer proxy, potrzebujesz pliku konfiguracyjnego. To plik YAML, który definiuje twoją logikę routingu. Sercem tego pliku jest sekcja o nazwie model list. Ta lista mapuje nazwy modeli, o które będą pytać twoje wewnętrzne aplikacje, na rzeczywiste modele backendowego dostawcy.
Wewnątrz model list, każdy wpis wymaga dwóch głównych elementów. Pierwszy to model name. To alias, który wystawiasz swoim użytkownikom. Możesz go nazwać internal-chat-model. Drugi element to blok o nazwie LiteLLM parameters. To tutaj konfigurujesz docelowy endpoint. To rozróżnienie jest ważne. Nazwa modelu to to, o co prosi twój klient, ale blok LiteLLM parameters definiuje, co faktycznie przetwarza ten request.
Jeśli robisz routing do deployu Azure OpenAI, twój blok LiteLLM parameters będzie zawierał konkretny string modelu Azure, twój base URL dla Azure API oraz wersję API. Mówisz też LiteLLM, która zmienna środowiskowa trzyma klucz API. Nie hardcodujesz klucza w samym pliku YAML.
Mając gotowy plik konfiguracyjny, robisz deploy proxy używając Dockera. Używasz oficjalnego obrazu LiteLLM z GitHub Container Registry. Uruchamiając kontener Dockera, wykonujesz trzy konkretne kroki. Mapujesz swój lokalny port 4000 na port 4000 w kontenerze. Montujesz swój plik konfiguracyjny YAML w kontenerze, żeby proxy mogło odczytać twoją model list. Na koniec przekazujesz do kontenera swoje faktyczne credentials dostawcy jako zmienne środowiskowe.
Kiedy kontener już działa, proxy jest live i nasłuchuje na localhost na porcie 4000. Testujesz je dokładnie tak, jak testowałbyś oficjalne API OpenAI. Robisz standardowy request HTTP POST używając narzędzia takiego jak cURL. Uderzasz na localhost port 4000, a następnie na ścieżkę slash chat slash completions. W body requestu podajesz alias, który zdefiniowałeś wcześniej jako model, i przekazujesz swoją tablicę messages.
Proxy odbiera ten standardowy payload. Odczytuje zażądany alias, szuka go w twoim pliku konfiguracyjnym i wyciąga parametry Azure. Następnie podpisuje request twoim kluczem API Azure, przekazuje go do Microsoftu i tłumaczy response z powrotem na dokładnie taki format, jakiego oczekuje twój klient.
Oto najważniejsza rzecz. Proxy całkowicie abstrahuje backendowego dostawcę od warstwy aplikacji. Jeśli w przyszłym miesiącu zdecydujesz się podmienić swój deploy Azure na zupełnie innego dostawcę, nie dotykasz ani jednej linijki kodu swojej aplikacji. Aktualizujesz tylko LiteLLM parameters w swoim pliku konfiguracyjnym YAML i restartujesz kontener.
Główną wartością serwera proxy jest to, że twoje aplikacje klienckie nigdy nie wiedzą i nigdy nie muszą wiedzieć, który dostawca chmurowy tak naprawdę generuje tokeny.
Dzięki za wysłuchanie, happy coding wszystkim!
5
Scentralizowane zarządzanie sekretami
3m 59sTrzymaj swoje klucze API z dala od konfiguracji w postaci zwykłego tekstu. Dowiedz się, jak połączyć LiteLLM z korporacyjnymi menedżerami sekretów, takimi jak AWS Secrets Manager czy Azure Key Vault, aby dynamicznie pobierać poświadczenia.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 5 z 24. Jeśli główny API key twojej firmy leży w pliku YAML jako plaintext na serwerze produkcyjnym, twój zespół security będzie miał zły dzień. Hardcodowane credentials to incydent, który tylko czeka, żeby się wydarzyć. Rozwiązaniem jest Centralized Secret Management.
Kiedy odpalasz gateway, potrzebuje on dostępu do API keys twojego upstream providera, żeby poprawnie routować ruch. Domyślnym podejściem jest często wrzucenie ich do lokalnej zmiennej środowiskowej albo bezpośrednio do głównego pliku konfiguracyjnego. Centralized Secret Management całkowicie zmienia ten pattern. Pozwala to gatewayowi dynamicznie czytać credentials z zewnętrznego enterprise vaulta, takiego jak AWS Secrets Manager, Azure Key Vault, Google Secret Manager czy HashiCorp Vault.
Żeby włączyć to połączenie, konfigurujesz dwa konkretne pola w bloku general settings twojego pliku konfiguracyjnego. Pierwsze pole to key management system. Tutaj definiujesz identyfikator twojego vault providera. Jeśli używasz AWS, ustawiasz to na aws_kms. Drugie pole to key management settings. To zagnieżdżona struktura, w której podajesz dokładne parametry połączenia wymagane przez twój konkretny vault, takie jak docelowy region AWS albo inne wymagane detale autentykacji.
Kiedy połączenie z vaultem jest już nawiązane, musisz powiedzieć swoim indywidualnym konfiguracjom routingu modeli, żeby ciągnęły swoje klucze z tego vaulta. Robisz to, używając specyficznego prefixu typu string zamiast właściwego klucza.
I tu jest kluczowa sprawa. Zamiast wpisywać właściwy string klucza, wpisujesz frazę os kropka environ ukośnik, a zaraz po niej dokładną nazwę twojego secreta, dokładnie taką, jaka istnieje w vaulcie.
Prześledźmy konkretny scenariusz. Chcesz routować ruch do modelu Azure, a prawdziwy API key jest bezpiecznie przechowywany w AWS Secrets Manager pod nazwą azure api key production. W swoim pliku konfiguracyjnym ustawiasz blok routingu modelu. Ale dla pola api key, ustawiasz wartość na os kropka environ ukośnik azure api key production.
Kiedy gateway przetwarza request dla tego modelu, widzi ten prefix. Wie, żeby nie używać tego stringa jako dosłownego klucza. Zamiast tego robi bezpieczny call do AWS Secrets Manager, requestuje wartość dla tej konkretnej nazwy secreta i pobiera prawdziwy klucz, żeby zautentykować request. Klucz w plaintext nigdy nie dotyka twojego dysku. Twój plik konfiguracyjny pozostaje całkowicie czysty i bezpieczny do zacommitowania do version control.
To pokrywa zaciąganie upstreamowych credentials do gatewaya. Ale integracja z secret managerem działa w obu kierunkach. Może też zapisywać dane. Kiedy używasz gatewaya do generowania nowych wirtualnych proxy keys dla twoich wewnętrznych zespołów inżynieryjnych, możesz skonfigurować system tak, żeby automatycznie zapisywał te nowo wygenerowane klucze bezpośrednio w twoim secret managerze. To gwarantuje, że wewnętrzne credentials, które wydajesz, są przechowywane i zarządzane z dokładnie takimi samymi security controls jak provider credentials, które konsumujesz.
Twoje pliki konfiguracyjne definiują strukturę twojej infrastruktury routingu, ale nigdy nie powinny trzymać jej secretów. Najbezpieczniejszym miejscem do przechowywania API key w twojej konfiguracji gatewaya jest nigdzie.
Dzięki za wysłuchanie, happy coding wszystkim!
6
Model Aliases: Cicha aktualizacja
4m 14sMigruj użytkowników do nowych modeli w sposób niezauważalny. Odkryj, jak używać Model Aliases w LiteLLM, aby mapować żądania dla jednego modelu na zupełnie inny endpoint bez modyfikowania kodu po stronie klienta.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny gateway LLM, odcinek 6 z 24. Co by było, gdybyś mógł zmigrować całą swoją bazę użytkowników z OpenAI do Anthropic bez proszenia ich o aktualizację choćby jednej linijki kodu integracji? Albo po cichu przełączyć użytkownika z free tieru na alternatywę open source bez psucia istniejącej logiki aplikacji? Mechanizm, który umożliwia to ciche przejście, nazywa się aliasami modeli.
Łatwo pomylić aliasy z routingiem, więc rozróżnijmy te dwa pojęcia. Routing odpowiada za load balancing pomiędzy wieloma deploymentami dokładnie tego samego modelu. Jeśli masz trzy oddzielne instancje Azure OpenAI z odpaloną tą samą wersją GPT-4, routing rozdziela ruch przychodzący równomiernie między nie, aby zapobiec rate limitom. Aliasy robią coś zupełnie innego. Alias przechwytuje żądaną nazwę modelu i mapuje ją na zupełnie inny model za proxy.
To mapowanie aplikujesz w momencie tworzenia wirtualnego klucza dla klienta. Kiedy wysyłasz request do endpointu generowania kluczy w LiteLLM, dołączasz obiekt aliases w swoim payloadzie. Ten obiekt to po prostu słownik, który paruje nazwę modelu, o którą poprosi klient, z nazwą modelu, który faktycznie zamierzasz zaserwować.
Spójrzmy na konkretny scenariusz. Masz segment użytkowników z free tieru. Pierwotnie zbudowali swoje narzędzia wokół GPT-4 i dokładnie ten string jest obecnie zahardcodowany w ich requestach sieciowych. Serwowanie GPT-4 niepłacącym użytkownikom jest drogie, więc decydujesz się przekierować ich prompty do wewnętrznego, mocno zoptymalizowanego endpointu Mistral 7B.
Aby to osiągnąć, generujesz nowy wirtualny klucz specjalnie dla tej grupy użytkowników. W payloadzie przy generowaniu definiujesz alias, który mapuje string GPT-4 bezpośrednio na nazwę twojego deploymentu Mistral 7B. Przekazujesz ten nowy wirtualny klucz użytkownikom. Oni nie modyfikują kodu swojej aplikacji. Nadal wysyłają standardowe requesty chat completion do twojego proxy, jawnie prosząc o GPT-4.
Oto kluczowa kwestia. Proxy LiteLLM odbiera przychodzący request i uwierzytelnia wirtualny klucz. Odczytuje konfigurację przypisaną do tego konkretnego klucza i zauważa twoją regułę aliasu. Zanim zroutuje payload do zewnętrznego providera, proxy nadpisuje parametr modelu w pamięci. Usuwa GPT-4 i podstawia Mistral 7B. Request trafia do twojego wewnętrznego deploymentu Mistral, generuje tekst i routuje odpowiedź z powrotem przez proxy do klienta.
Aplikacja kliencka otrzymuje standardowy format odpowiedzi, którego oczekuje. Jej parsery działają idealnie, a aplikacja nadal funkcjonuje normalnie. Developerzy utrzymujący tę aplikację kliencką są całkowicie nieświadomi, że pod spodem podmieniono model językowy.
Ponieważ aliasy są przypisane bezpośrednio do poszczególnych wirtualnych kluczy, a nie do globalnej konfiguracji serwera, zachowujesz absolutną kontrolę nad różnymi segmentami użytkowników. Jeden klucz może aliasować ruch do tańszego modelu dla darmowych użytkowników, podczas gdy inny klucz pozwala na przepływ ruchu premium bez modyfikacji. Możesz też użyć dokładnie tej samej logiki do obsługi deprecjacji modeli. Kiedy provider wycofuje starszy model, po prostu aliasujesz starą nazwę na nową wersję, oszczędzając wszystkim swoim klientom konieczności wypuszczania awaryjnych update'ów kodu. Najpotężniejszym aspektem gatewaya modeli nie jest tylko zarządzanie ruchem sieciowym, ale decoupling oczekiwań klienta od fizycznej rzeczywistości twojej architektury backendu.
Dzięki za wysłuchanie, happy coding wszystkim!
7
Load Balancing dla wysokiej przepustowości
3m 28sUnikaj limitów zapytań i przestojów dzięki inteligentnemu kierowaniu ruchem. Sprawdź, dlaczego simple-shuffle jest rekomendowaną strategią dla produkcyjnego load balancingu pomiędzy wieloma wdrożeniami.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: uniwersalny gateway LLM, odcinek 7 z 24. W końcu dostałeś dostęp produkcyjny do Azure OpenAI, odpaliłeś aplikację i przy pierwszym dużym skoku ruchu od razu uderzyłeś w potężny błąd rate limit. Masz odpowiednią quotę, ale wąskim gardłem okazuje się pojedynczy region. Rozwiązaniem tego problemu jest Load Balancing dla wysokiego throughputu. Żeby obsłużyć duże wolumeny requestów bez uderzania w limity, musisz rozrzucić ruch na wiele identycznych deployów. W LiteLLM robisz to, konfigurując router. Grupujesz wiele backendowych endpointów pod jedną logiczną nazwą modelu. Załóżmy, że masz aplikację opartą na pięciu deployach Azure, rozrzuconych po pięciu różnych regionach geograficznych. Kiedy twoja aplikacja prosi o completion, router decyduje, który z tych pięciu regionów dostanie ten request. Kontrolujesz tę logikę, ustawiając routing strategy w ustawieniach routera. Intuicyjnym podejściem jest usage-based routing, gdzie system wysyła request do tego deployu, który ma w danej chwili najmniejszy ruch. Ale to wymaga śledzenia dokładnego zużycia tokenów w czasie rzeczywistym. Śledzenie stanu w czasie rzeczywistym oznacza robienie strzału sieciowego do cache'a takiego jak Redis dla każdego pojedynczego requestu, zanim prompt w ogóle wyjdzie w świat. To dodaje stały narzut na latency do twojej aplikacji. W środowiskach produkcyjnych o wysokim throughputcie chcesz uniknąć tego dodatkowego hopa. Rekomendowanym podejściem jest strategia o nazwie simple-shuffle. Simple-shuffle nie śledzi stanu na żywo. Losowo wybiera endpoint z twojej puli na podstawie zdefiniowanych wcześniej wag. Kiedy dodajesz swoje pięć deployów Azure do pliku konfiguracyjnego, przypisujesz każdemu z nich limit, zazwyczaj Requests Per Minute, czyli RPM. Możesz też użyć Tokens Per Minute, czyli TPM. Jeśli twój główny region ma limit RPM na poziomie dziesięciu tysięcy, a zapasowy region ma limit RPM równy pięć tysięcy, simple-shuffle odczytuje te liczby i traktuje je jako wagi. Automatycznie przekieruje dwa razy więcej ruchu do głównego regionu. Pod spodem router bierze listę dostępnych deployów dla tego modelu, uwzględnia ich wagi RPM i tasuje je, tworząc zrandomizowaną listę dla tego konkretnego requestu. Następnie próbuje uderzyć do pierwszego deployu z listy. Ponieważ randomizacja ściśle przestrzega skonfigurowanych przez ciebie limitów RPM, twój ruch z czasem idealnie rozkłada się na wszystkie pięć regionów, omijając rate limity bez narzutu na monitorowanie w czasie rzeczywistym. Żeby to skonfigurować, otwierasz plik konfiguracyjny i ustawiasz parametr routing strategy na simple-shuffle. Następnie na liście modeli definiujesz swoje pięć endpointów Azure. Nadajesz im wszystkim dokładnie tę samą nazwę modelu. Na koniec dołączasz parametr RPM do definicji każdego endpointu z pożądaną wagą. Kiedy twoja aplikacja wywołuje router używając tej nazwy modelu, router automatycznie ogarnia matematykę i randomizację. Dostajesz korzyści z rozproszonej architektury bez konieczności dodawania zależności od Redisa. Najlepszym sposobem na ogarnięcie ogromnej skali jest często zamiana idealnego śledzenia w czasie rzeczywistym na bezstanową, statystycznie przewidywalną randomizację. Dzięki za wysłuchanie, happy coding wszystkim!
8
Awarie API i mechanizmy Fallback
3m 57sNigdy więcej nie doświadczaj przestojów AI. Dowiedz się, jak skonfigurować mechanizmy fallback dla modeli w LiteLLM, aby w przypadku awarii głównego dostawcy ruch był automatycznie przekierowywany do dostawcy zapasowego.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 8 z 24. Kiedy twój główny dostawca modelu językowego ma awarię, czy twoja aplikacja pada razem z nim, czy po cichu przełącza się na backup? Dzisiaj omówimy awarie API i fallbacki, czyli dokładnie ten mechanizm, który utrzymuje twój system online, gdy zewnętrzne endpointy zawodzą.
Najpierw warto odróżnić to od pokrewnego konceptu. Fallbacki to nie load balancing. Load balancing proaktywnie rozdziela twój ruch na wiele aktywnych deploymentów, aby zapobiec przeciążeniu pojedynczego endpointu. Fallbacki z kolei to ściśle reaktywne koła ratunkowe. Siedzą bezczynnie podczas normalnego działania i odpalają się dopiero, gdy wystąpi definitywna awaria.
Głównym celem jest utrzymanie wysokiego uptime'u, idealnie dobijając do tych 99,9%, nawet jeśli twoi dostawcy upstreamowi tego nie robią. Zewnętrzne API nieuchronnie będą rzucać błędami 500 internal server error albo wyjątkami 429 rate limit. Kiedy to się stanie, konfiguracja fallbacku mówi proxy, żeby przechwyciło błąd w locie i przekierowało request do alternatywnego dostawcy, całkowicie chroniąc kod twojej aplikacji przed awarią.
Ustawiasz to w swoim pliku konfiguracyjnym YAML dla proxy, używając arraya fallbacks. Rozważmy konkretny scenariusz. Twoim głównym deploymentem jest gpt-4. Chcesz mieć pewność, że jeśli gpt-4 będzie offline, proxy automatycznie spróbuje zamiast niego claude-3-opus.
W swoim pliku konfiguracyjnym definiujesz setup modelu gpt-4 jak zwykle. Wewnątrz tej konkretnej definicji modelu dodajesz key fallbacks. Wartością tego keya jest po prostu array stringów, gdzie każdy string to nazwa innego modelu zdefiniowanego w twojej konfiguracji. Dodajesz claude-3-opus do tego arraya.
Kiedy twoja aplikacja wysyła prompt do proxy z żądaniem gpt-4, LiteLLM routuje go do głównego endpointu. Jeśli ten endpoint zwróci błąd, logika proxy go przechwytuje. Jeśli masz skonfigurowane retries, może spróbować odpytać główny endpoint jeszcze kilka razy. Ale kiedy główny definitywnie zawiedzie, proxy odpala sekwencję fallbacku.
I tu robi się ciekawie. Proxy bierze dokładnie oryginalny prompt i parametry. Ponieważ LiteLLM normalizuje format API, płynnie tłumaczy request w formacie OpenAI na format Anthropic wymagany przez Claude. Natychmiast wysyła przetłumaczony request do endpointu backupowego. Kod twojej aplikacji nie musi obsługiwać żadnej logiki błędów, przepisywać promptu ani zarządzać kluczami API dla drugiego dostawcy. Proxy ogarnia całe to przełączenie wewnętrznie.
Nie jesteś ograniczony do pojedynczego backupu. Array fallbacks przyjmuje listę modeli. Jeśli twój główny gpt-4 padnie, a potem twój pierwszy fallback claude-3-opus też zawiedzie, proxy przechodzi do kolejnej nazwy w arrayu. Przechodzi przez listę sekwencyjnie. Jeśli dotrze do końca arraya i każdy kolejny model backupowy zawiedzie, dopiero wtedy proxy zwraca błąd z powrotem do twojej aplikacji klienckiej.
I to jest kluczowa sprawa. Układając warstwowo różne modele fallbackowe w swojej konfiguracji, skutecznie izolujesz kod swojej aplikacji od zewnętrznej niestabilności, zamieniając twarde awarie dostawców w nic innego jak niewidoczne skoki latency dla twoich użytkowników końcowych.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
9
Fallbacki dla okna kontekstowego
3m 30sPrzestań przepłacać za ogromne okna kontekstowe przy krótkich promptach. Dowiedz się, jak używać weryfikacji pre-call oraz mechanizmów fallback dla okna kontekstowego, aby kierować zbyt duże dokumenty do wyspecjalizowanych modeli.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 9 z 24. Używanie drogiego modelu z kontekstem 128k do każdego zapytania użytkownika to ogromne marnotrawstwo pieniędzy. Ale jeśli zamiast tego domyślnie ustawisz tańszy, mniejszy model, użytkownik wrzucający ogromnego PDF-a natychmiast wysypie twoją aplikację. Mechanizm, który rozwiązuje ten problem, nazywa się Context Window Fallbacks.
Możesz zakładać, że fallback routing dzieje się dopiero, gdy API providera zwróci kod błędu. To prawda w przypadku ogólnych fallbacków związanych z niezawodnością, ale limity kontekstu działają inaczej. LiteLLM potrafi proaktywnie obsługiwać rozmiary promptów, używając ustawienia o nazwie enable pre-call checks. Kiedy ustawisz ten boolean na true w konfiguracji swojego routera, proxy zatrzymuje request i oblicza dokładną liczbę tokenów promptu, zanim provider w ogóle go zobaczy.
Oto w czym rzecz. Konfigurujesz główny model, na przykład jakiś bardzo opłacalny, i w tym samym bloku konfiguracji definiujesz listę context window fallbacks, wskazującą na znacznie większy model. Kiedy przychodzi nowy request, wykonuje się pre-call check. Jeśli obliczona liczba tokenów mieści się w limicie głównego modelu, request przechodzi normalnie. Jeśli prompt jest za duży, LiteLLM całkowicie porzuca główny route. Natychmiast przekazuje request do większego modelu fallbackowego.
Oznacza to, że nigdy nie dostaniesz błędu długości kontekstu z upstream API. Oznacza to również, że unikasz narzutu latency związanego z czekaniem, aż provider odrzuci początkowy payload. Aplikacja wysyłająca request nie ma pojęcia, że routing zmienił się pod spodem.
LiteLLM polega na swoim wewnętrznym rejestrze modeli, żeby znać dokładne limity kontekstu dla różnych providerów. Możesz jednak chcieć wymusić bardziej rygorystyczne limity. Być może chcesz odpalić fallback wcześniej, żeby zostawić więcej miejsca na wygenerowane output tokeny, albo kierujesz ruch do customowego deploymentu z niestandardową alokacją pamięci. Robisz to, nadpisując parametr max input tokens bezpośrednio w konfiguracji swojego modelu. Podanie tej wartości wymusza na proxy użycie twojego customowego limitu podczas ewaluacji pre-call checku.
Pomyśl o standardowym ruchu w aplikacji. Użytkownik zadaje proste pytanie tekstowe. Proxy zlicza pięćdziesiąt tokenów, waliduje, że się mieszczą, i kieruje je do GPT-3.5. Kilka minut później ten sam użytkownik uploaduje ogromnego PDF-a zawierającego osiemdziesiąt tysięcy tokenów. Proxy oblicza nowy rozmiar, widzi, że przekracza limit GPT-3.5, i automatycznie przekierowuje go prosto do GPT-4-128k. Logika twojej aplikacji pozostaje całkowicie statyczna. Płacisz za model premium tylko wtedy, gdy payload faktycznie tego wymaga.
Przeniesienie walidacji tokenów z kodu twojej aplikacji do warstwy proxy przekształca twoją strategię fallbackową z pasywnej siatki bezpieczeństwa w aktywny silnik optymalizacji kosztów.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
10
Okiełznanie zawieszonych żądań za pomocą Timeoutów
4m 05sNie pozwól, aby wolne API zamroziły Twoją aplikację. Odkryj, jak skonfigurować global timeouts i stream timeouts w LiteLLM, aby przerywać zawieszone żądania i uruchamiać szybkie mechanizmy fallback.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny Gateway LLM, odcinek 10 z 24. Nie ma nic gorszego dla user experience niż chatbot wyświetlający loading spinner przez czterdzieści pięć sekund tylko dlatego, że upstream API po cichu się zawiesiło. Potrzebujesz niezawodnego sposobu na natychmiastowe zrywanie martwych połączeń, aby twój system mógł się zregenerować. Rozwiązujemy ten problem, okiełznując zawieszone requesty za pomocą timeoutów.
Kiedy routujesz ruch do zewnętrznych modeli językowych, opóźnienia sieciowe i awarie providerów są nieuniknione. Jeśli provider przestanie odpowiadać, domyślnym zachowaniem wielu klientów HTTP jest utrzymywanie otwartego połączenia przez długi czas. LiteLLM radzi sobie z tym problemem za pomocą dwóch różnych mechanizmów timeoutu. Pierwszym z nich jest standardowy parametr timeout. To ustawienie określa maksymalny całkowity czas, przez jaki LiteLLM będzie czekać na zakończenie całego requestu, od momentu jego wysłania aż do wygenerowania ostatniego znaku.
Jeśli ustawisz standardowy timeout na trzydzieści sekund, a model potrzebuje trzydziestu jeden sekund na wygenerowanie długiej odpowiedzi, LiteLLM przerwie request. Działa to świetnie w przypadku background tasków lub krótkich generacji bez streamingu. Jednak zastosowanie całkowitego timeoutu do aplikacji ze streamingiem stwarza problem strukturalny. Wyczerpująca odpowiedź może całkowicie naturalnie zająć sześćdziesiąt sekund, zanim w całości zestreamuje się do użytkownika. Jeśli ustawisz krótki całkowity timeout, żeby wyłapać zawieszone requesty, przypadkowo ubijesz w pełni zdrowe, długo działające generacje.
I tu robi się ciekawie. LiteLLM udostępnia drugi parametr o nazwie stream timeout. To ustawienie mierzy konkretnie czas do pierwszego tokena. Kontroluje ono dokładnie, jak długo gateway będzie czekać na otrzymanie początkowego chunku danych od providera. Kiedy ten pierwszy kawałek danych dotrze, zegar stream timeoutu się zatrzymuje, a połączenie pozostaje otwarte przez resztę generacji.
Rozważmy konkretny scenariusz. Routujesz ruch do głównego endpointu Azure OpenAI. W swoim pliku konfiguracyjnym definiujesz blok modelu i dodajesz parametr stream timeout, ustawiając go na dwie sekundy. Użytkownik wysyła skomplikowany prompt. LiteLLM przekazuje ten request do Azure. Zazwyczaj serwer upstream przetwarza prompt i zwraca pierwszy chunk w ułamku sekundy. Ale w tym przypadku konkretny node Azure się zawiesza.
Gateway zaczyna odliczanie. Mija sekunda. Mijają dwie sekundy. Pierwszy chunk nie dociera. Ponieważ zdefiniowałeś dwusekundowy stream timeout, LiteLLM odmawia czekania na odpalenie standardowego timeoutu HTTP. Wymusza przerwanie połączenia dokładnie po upływie dwóch sekund.
Przerwanie martwego requestu to tylko połowa korzyści architektonicznych. Wymuszając szybki fail, LiteLLM natychmiast aktywuje twoją logikę fallbacku. W momencie, gdy request do Azure łapie timeout, gateway reroutuje dokładnie ten sam prompt użytkownika do kolejnego dostępnego, zdrowego node'a na twojej liście deploymentów. Użytkownik doświadcza ledwo zauważalnego, dwusekundowego opóźnienia, zanim tekst zacznie się streamować, całkowicie unikając zamrożonego interfejsu.
Masz elastyczność, by egzekwować te reguły na różnych poziomach. Możesz zastosować globalny timeout dla wszystkich routowanych requestów albo dostosować je per model. Ciężki model do logicznego wnioskowania może wymagać łagodnego stream timeoutu rzędu pięciu lub dziesięciu sekund, podczas gdy szybki model klasyfikacyjny powinien zrobić failover już po jednej sekundzie.
Responsywność twojej aplikacji zależy nie tylko od tego, jak szybko twój główny provider zwróci wynik, ale także od tego, jak agresywnie wymusisz fail na zawieszonym połączeniu. Dzięki za wysłuchanie, udanego kodowania wszystkim!
11
Virtual Keys dla FinOps
4m 28sPrecyzyjnie zabezpiecz użycie swojego API. Dowiedz się, jak generować Virtual Keys za pomocą LiteLLM, ustawiając rygorystyczne limity RPM, TPM i budżetowe, aby chronić organizację przed niekontrolowanymi kosztami AI.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny Gateway LLM, odcinek 11 z 24. Wadliwy skrypt napisany przez juniora może z łatwością nabić rachunek w OpenAI na dziesięć tysięcy dolarów przez jedną noc. Platforma providera pod spodem akceptuje requesty tak szybko, jak pętla jest w stanie je wysyłać. Wirtualne klucze dla FinOps to sposób, w jaki możesz temu zapobiec, zanim to się stanie.
Często myli się master keys z wirtualnymi kluczami. Nigdy nie powinieneś dawać swojego master keya developerowi. Master key to twoje administracyjne credentials. Jego głównym celem jest uwierzytelnienie twojej platformy, żeby tworzyć wirtualne klucze. Wirtualne klucze to ograniczone credentials, które faktycznie rozdajesz developerom lub aplikacjom do użycia w ich kodzie.
Nowe credentials tworzysz, robiąc request HTTP POST do endpointu key generate na twoim proxy LiteLLM. Autoryzujesz ten request, używając swojego master keya jako bearer tokena. W body tego requestu definiujesz finansowe limity.
Wyobraź sobie scenariusz, w którym przydzielasz dostęp letniemu stażyście. Chcesz mieć pewność, że ma wystarczający dostęp, żeby zbudować prototyp, ale potrzebujesz absolutnej gwarancji, że nie przepali twojego budżetu na infrastrukturę. Żeby to wymusić, przekazujesz dwa konkretne parametry w swoim payloadzie JSON.
Po pierwsze, definiujesz limit finansowy, ustawiając parametr max budget. Jeśli ustawisz tę wartość na dziesięć, przypisujesz dokładnie dziesięć dolarów do tego konkretnego klucza. To jest twardy limit na cały cykl życia klucza. Kiedy całkowity koszt wszystkich promptów i completions powiązanych z tym kluczem osiągnie dziesięć dolarów, klucz zostanie automatycznie wyłączony i odrzuci wszystkie dalsze requesty.
Po drugie, kontrolujesz tempo tych requestów, ustawiając parametr RPM limit. RPM oznacza requests per minute. Jeśli ustawisz RPM limit na jeden, proxy będzie ściśle egzekwować jeden request na sześćdziesięciosekundowe okno. Jeśli przypadkowa nieskończona pętla w kodzie stażysty spróbuje natychmiast wysłać sto requestów, proxy przetworzy pierwszy z nich i natychmiast odrzuci pozostałe dziewięćdziesiąt dziewięć ze standardowym błędem rate limit.
Kiedy wyślesz ten payload do endpointu generate, LiteLLM przetworzy reguły i zwróci odpowiedź zawierającą nowo wygenerowany wirtualny klucz. Ten klucz wygląda identycznie jak standardowe credentials od providera, zazwyczaj zaczynając się od prefiksu sk. Przekazujesz ten string stażyście.
Oto kluczowa sprawa. Developer używa tego wirtualnego klucza dokładnie tak samo, jak klucza OpenAI lub Anthropic, kierując swoją standardową bibliotekę klienta na twój URL proxy LiteLLM zamiast do publicznego internetu. Kiedy przychodzi request, proxy go przechwytuje. Odpytuje swoją wewnętrzną bazę danych, żeby zweryfikować, czy wirtualny klucz istnieje. Następnie sprawdza, czy klucz nie przekroczył swojego budżetu dziesięciu dolarów albo limitu tempa jednego requestu na minutę.
Jeśli request przejdzie oba te testy, proxy podmienia wirtualny klucz na twój prawdziwy firmowy klucz API i przekazuje payload do providera. Kiedy provider odpowie, proxy oblicza dokładny koszt tokenów promptu i completion na podstawie oficjalnego cennika tego konkretnego modelu. Odejmuje ten ułamek centa od dziesięciodolarowego budżetu wirtualnego klucza, zapisuje transakcję i odsyła odpowiedź z powrotem do developera. Developer jest całkowicie nieświadomy podmiany credentials pod spodem ani wewnętrznego księgowania.
Wymuszając limity na warstwie proxy, wirtualne klucze przechwytują nieautoryzowane lub wymykające się spod kontroli requesty, zanim w ogóle dotrą do providera rozliczeń, matematycznie gwarantując, że skompromitowany lub źle napisany skrypt nigdy nie przekroczy przypisanego mu budżetu.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
12
Śledzenie wydatków i niestandardowe tagi
3m 44sDokładnie przypisuj każdego centa wydanego na LLM. Dowiedz się, jak przekazywać tagi metadanych w swoich żądaniach i generować kompleksowe raporty wydatków za pomocą LiteLLM.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny Gateway LLM, odcinek 12 z 24. Właśnie wszedł twój dyrektor finansowy i zapytał, która dokładnie nowa funkcja produktu przepala miesięczny budżet na AI. Otwierasz dashboard dostawcy, ale widzisz tylko jeden ogromny, zbiorczy rachunek dla całej firmy. Nie masz odpowiedzi. Śledzenie wydatków i customowe tagi w LiteLLM rozwiązują ten problem.
Kiedy routujesz requesty przez LiteLLM, proxy automatycznie oblicza koszt każdego completion na podstawie konkretnego modelu i liczby tokenów. Całkowita kwota w dolarach jest bezużyteczna, jeśli nie można jej przypisać do konkretnego źródła. Najprostszym sposobem na pogrupowanie tych wydatków jest użycie standardowego parametru user w twoim wywołaniu chat completion. Przekazujesz unikalny string reprezentujący twojego klienta końcowego. LiteLLM przechwytuje to, oblicza koszt i loguje go do tego konkretnego user ID.
Śledzenie po użytkowniku rozwiązuje jeden problem, ale często pojedynczy użytkownik triggeruje wiele procesów na backendzie. Załóżmy, że masz workload związany z klasyfikacją dokumentów, a dział księgowości potrzebuje raportu grupującego wydatki po konkretnych background jobach. User ID tutaj nie pomoże. I tu wkraczają customowe tagi. LiteLLM pozwala ci dołączyć tablicę stringów do dowolnego requestu i będzie śledzić wydatki przypisane dokładnie do tych stringów.
Oto kluczowa sprawa. Standardowe biblioteki, takie jak oficjalne OpenAI SDK czy LangChain, nie wiedzą natywnie o metadata z LiteLLM. Jeśli spróbujesz przekazać nierozpoznany parametr o nazwie metadata, SDK go wytnie albo rzuci błędem, zanim request w ogóle dotrze do proxy. Aby to obejść, używasz parametru o nazwie extra body. To standardowy escape hatch wbudowany w nowoczesne SDK, specjalnie do wstrzykiwania customowych pól.
Przejdźmy przez to na przykładzie requestu w LangChain. Konfigurujesz swój standardowy obiekt chat model. Kiedy wywołujesz metodę invoke, przekazujesz swój prompt tak jak zwykle. Razem z promptem przekazujesz parametr o nazwie extra body. Ustawiasz go jako słownik. Wewnątrz tego słownika tworzysz klucz o nazwie metadata. Wewnątrz metadata dodajesz klucz o nazwie tags, wskazujący na tablicę stringów. Możesz przekazać string taki jak job ID cztery zero dwa. LangChain pakuje to extra body dokładnie w takiej postaci i wysyła przez sieć. LiteLLM odbiera payload, wyciąga twoje tagi z bloku metadata i przypisuje dokładny koszt tego wywołania LLM do job ID cztery zero dwa.
To tyle, jeśli chodzi o inputy. A co z outputami? Kiedy twój ruch już płynie z tymi tagami, musisz wyciągnąć dane. Robisz to, odpytując endpoint global spend report na twoim proxy LiteLLM. Robisz standardowy request HTTP GET do tego endpointu. Proxy zwraca payload JSON ze szczegółami, gdzie dokładnie poszły pieniądze. Grupuje twoje całkowite wydatki po API key, po userze i, co najważniejsze, po każdym customowym tagu, który podałeś. Możesz przekazać to bezpośrednio do działu księgowości. Od razu widzą, że background job klasyfikacji dokumentów kosztował dokładnie cztery dolary i dwadzieścia centów, niezależnie od tego, który model pod spodem obsłużył faktyczny routing.
Tagowanie ruchu na poziomie proxy oznacza, że szczegółowość rozliczeń nie jest już dyktowana przez to, jak twój cloud provider strukturyzuje swoje faktury; jest ona w całości definiowana przez kontekst twojej własnej aplikacji.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
13
Cache'owanie dla szybkości i oszczędności
3m 44sPrzestań płacić za te same odpowiedzi LLM w kółko. Dowiedz się, jak skonfigurować exact caching z Redis i semantic caching z Qdrant, aby drastycznie zmniejszyć opóźnienia i koszty API.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, odcinek 13 z 24. Po co płacić zewnętrznemu API za generowanie tysiąc razy dokładnie tego samego podstawowego wyjaśnienia? Marnujesz kredyty i zmuszasz użytkowników do czekania na obliczenia, które już zostały wykonane. Rozwiązanie tej nieefektywności to sedno cachingu dla szybkości i oszczędności.
LiteLLM obsługuje caching całkowicie na poziomie proxy. Kiedy przychodzi request, proxy sprawdza, czy widziało już wcześniej dokładnie ten sam prompt. Jeśli tak, natychmiast zwraca zapisany response. Latency spada z sekund do milisekund, a koszt API spada do zera. Aby to skonfigurować, używasz swojego pliku config kropka yaml. Włączasz caching w bloku globalnych ustawień, ustawiając cache na true, i określasz swój typ cache'a. Redis to standardowy backend dla cachingu typu exact match. Podajesz host, port i hasło do Redisa, a proxy zajmuje się przechowywaniem par input-output.
Ale exact caching jest kruchy. Szuka idealnego dopasowania stringa. Jeśli jeden użytkownik poprosi, napisz wiersz o LiteLLM, a inny użytkownik poprosi, stwórz wiersz o LiteLLM, exact cache widzi dwa zupełnie różne requesty. Przekazuje drugi request do ciężkiego modelu językowego, marnując czas i pieniądze na nadmiarowe zadanie tylko dlatego, że sformułowanie nieznacznie się zmieniło.
I tu wkracza semantic caching. Zamiast porównywać surowe stringi tekstowe, semantic caching porównuje ukryte znaczenie promptów. LiteLLM wspiera Qdrant, wektorową bazę danych, aby to obsłużyć. Kiedy konfigurujesz semantic caching, musisz określić model embeddingu obok swojego głównego modelu generatywnego. Kiedy przychodzi request, proxy najpierw przekazuje prompt do modelu embeddingu. Ten model konwertuje tekst na wektor, który jest matematyczną reprezentacją znaczenia promptu.
Następnie proxy odpytuje Qdrant, aby sprawdzić, czy podobny wektor istnieje już w cache'u. Ponieważ napisz wiersz i stwórz wiersz mają tę samą intencję semantyczną, ich wektory mapują się blisko siebie w przestrzeni. Qdrant wykrywa to podobieństwo. Jeśli dopasowanie jest wystarczająco bliskie, proxy wyciąga z cache'a response od pierwszego użytkownika i dostarcza go drugiemu. Całkowicie pomijasz ciężki krok generowania tekstu, płacąc jedynie ułamek centa za szybki lookup embeddingu.
Skonfigurowanie tego wymaga kilku dodatkowych linijek w twoim config kropka yaml. Zmieniasz typ cache'a na qdrant semantic. Definiujesz parametry specyficzne dla Qdrant, takie jak URL endpointu Qdrant i twój klucz API. Co najważniejsze, definiujesz próg podobieństwa. To wartość dziesiętna między zerem a jedynką. Wysoki próg, taki jak zero przecinek dziewięć dziewięć, wymaga niemal identycznego sformułowania. Niższy próg, taki jak zero przecinek osiem, wychwytuje szersze wariacje, ale zwiększa ryzyko zwrócenia nieaktualnej lub lekko off-topicowej odpowiedzi, jeśli dwa prompty brzmią podobnie, ale mają różne intencje.
Oto kluczowy wniosek. Semantic caching to nie tylko mechanizm przechowywania, to aktywny filtr intencji użytkownika. Tuning twojego progu podobieństwa to jedyna rzecz, która stoi między potężną redukcją kosztów a zwracaniem użytkownikom nietrafionych odpowiedzi.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
14
RBAC: Wzmacnianie pozycji Team Admins
3m 41sBezpiecznie rozdzielaj zarządzanie platformą. Zrozum Role-Based Access Control (RBAC) w LiteLLM, delegując uprawnienia do Org Admins i Team Admins bez narażania globalnego bezpieczeństwa.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 14 z 24. Jesteś platform engineerem i połowę dnia spędzasz na odpowiadaniu na wiadomości z prośbami o nowe klucze API lub zwiększenie budżetu. Każdy onboarding developera kończy się ticketem IT, który blokuje jego pracę i marnuje twój czas. Rozwiązaniem jest delegowanie kontroli bez utraty nadzoru, wykorzystując Role-Based Access Control.
LiteLLM wspiera cztery konkretne role userów do zarządzania tą delegacją. Są to: proxy admin, org admin, team admin oraz internal user. Proxy admin znajduje się na samym szczycie. Jeśli robisz deploy LiteLLM, jesteś proxy adminem. Konfigurujesz modele, stawiasz bazę danych i ustalasz globalne reguły. Ale nie powinieneś zarządzać codziennymi requestami o klucze. I tu właśnie wkracza hierarchia.
Możesz pogrupować swoją firmę w organizacje, które reprezentują wielkie działy, oraz teamy, które są konkretnymi grupami roboczymi w ramach tych działów. Org admin może zarządzać teamami w ramach swojej konkretnej organizacji. Ale prawdziwa władza operacyjna leży w rękach team admina.
Oto kluczowa sprawa. Możesz przekazać wszystkie lokalne zadania administracyjne liderowi działu, robiąc z niego team admina. Jako proxy admin, tylko raz konfigurujesz początkową strukturę. Tworzysz team, nakładasz hard limit budżetu w wysokości pięciuset dolarów miesięcznie i przypisujesz lead developera jako team admina. Potem całkowicie wyłączasz się z procesu.
Team admin ma teraz autonomię w zarządzaniu swoimi inżynierami. Może zalogować się do UI lub użyć API, aby dodać nowych userów do swojego teamu. Może generować nowe klucze API dla tych developerów i monitorować łączne wydatki swojej grupy. Co najważniejsze, każdy klucz utworzony przez team admina lub jego inżynierów jest automatycznie przypisany do tego pięciosetdolarowego budżetu teamu. Team admin ma pełną lokalną kontrolę, ale nie może wydać ani centa ponad limit narzucony przez proxy admina.
Poniżej team admina znajduje się internal user. To rola przypisywana standardowym developerom piszącym kod. Internal user ma ograniczony dostęp. Może podglądać własne zużycie tokenów i, jeśli team admin na to pozwoli, generować swoje osobiste klucze API. Jego wgląd w system jest ściśle ograniczony do niego samego. Nie widzi budżetu całego teamu, nie może przeglądać kluczy należących do kolegów, a już na pewno nie może modyfikować ustawień teamu.
Aby ustawić to programatycznie, proxy admin wysyła pojedynczy request API do endpointu tworzenia teamu. Przekazujesz nazwę teamu, parametr max budget oraz tablicę ID userów otagowanych rolą team admina. System zwraca team ID. Od tego momentu lider działu używa tego team ID do routowania własnych requestów do zarządzania, całkowicie pomijając team platform engineerów.
Role-Based Access Control w LiteLLM to nie tylko ukrywanie przycisków w UI, to fizyczne ograniczanie wydatków na tokeny na poziomie grupy, przy jednoczesnym przeniesieniu zarządzania kluczami w dół, do osób faktycznie prowadzących projekty.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
15
Security Guardrails
4m 08sDodaj niewidoczną warstwę bezpieczeństwa do swoich żądań LLM. Dowiedz się, jak skonfigurować pre-call i post-call guardrails w LiteLLM, aby blokować prompt injections i maskować dane osobowe (PII), zanim dotrą do zewnętrznych dostawców.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, odcinek 15 z 24. Poleganie na tym, że model językowy będzie się grzecznie zachowywał, to żadna strategia bezpieczeństwa. Jeśli użytkownik przypadkowo wklei poufne dane klienta do promptu, proszenie modelu, żeby uprzejmie je zignorował, to już za późno. Potrzebujesz bramkarza na bramce, i dokładnie to zapewniają Security Guardrails.
Security Guardrails w LiteLLM działają jak niewidzialna warstwa bezpieczeństwa między klientami twojej aplikacji a dostawcami modeli językowych. Przechwytują ruch API w dwóch odrębnych fazach. Pierwsza faza nazywa się pre call. Wykonuje się ona po tym, jak LiteLLM otrzyma przychodzący request z twojej aplikacji, ale tuż przed przekazaniem tego payloadu do zewnętrznego dostawcy. Druga faza to post call, która odpala się po wygenerowaniu odpowiedzi przez model, ale przed odesłaniem jej przez LiteLLM z powrotem do oryginalnego klienta.
Tę logikę routingu definiujesz w całości w swoim pliku config kropka yaml. W bloku ustawień proxy definiujesz swoje guardrails, podając endpoint lub wspieraną integrację, a następnie przypisując im tryb pre call albo post call.
Spójrzmy na konkretny scenariusz z użyciem guardraila typu pre call. Załóżmy, że pracownik prosi model hostowany w chmurze o podsumowanie ticketu z supportu, ale ten ticket zawiera amerykańskie numery ubezpieczenia społecznego. Absolutnie nie chcesz, żeby te numery opuściły twoją sieć wewnętrzną. Możesz skonfigurować Microsoft Presidio jako swój guardrail pre call. Kiedy aplikacja wysyła prompt, LiteLLM przechwytuje request i przekazuje tekst do Presidio. Presidio skanuje tekst, lokalizuje numer ubezpieczenia społecznego i zastępuje go generyczną maską. Następnie LiteLLM bierze ten oczyszczony prompt i wysyła go przez internet do cloud providera. Zewnętrzny model generuje podsumowanie na podstawie zamaskowanego tekstu, a kod twojej aplikacji działa tak, jakby nie wydarzyło się nic nadzwyczajnego.
A oto kluczowa kwestia. Nie musisz aplikować tych reguł globalnie dla całego swojego ruchu. LiteLLM pozwala ci podpiąć guardrails na poziomie konkretnego modelu. To kluczowe, gdy operujesz na architekturze hybrydowej. Możesz skonfigurować swój routing tak, żeby każdy prompt wysyłany do modelu w chmurze publicznej przechodził przez restrykcyjny guardrail maskujący PII. Jeśli jednak zrobisz routing tego samego promptu do modelu open source działającego na twoim własnym sprzęcie on premises, po prostu pomijasz guardrail w bloku konfiguracji tego modelu. Lokalny model przetwarza surowe, niezamaskowane dane, ponieważ te informacje nigdy nie przekraczają granic twojej sieci. Unikasz niepotrzebnego narzutu na przetwarzanie i zachowujesz dokładny kontekst.
Tryb post call działa w oparciu o dokładnie ten sam flow, tylko w drodze powrotnej. Kiedy zewnętrzny model odpowiada, LiteLLM przepuszcza output przez twoje guardrails typu post call. Pozwala ci to ocenić tekst pod kątem toksycznego języka, wyhalucynowanych wewnętrznych adresów URL czy nieautoryzowanych wzmianek o konkurencji, zanim użytkownik w ogóle go zobaczy. Jeśli guardrail post call oflaguje treść, LiteLLM przechwytuje tę drogę powrotną. Blokuje tekst i zwraca do klienta błąd bezpieczeństwa zamiast dostarczać szkodliwy output.
Dzięki obsłudze tego bezpośrednio na poziomie proxy, architektura twojej aplikacji pozostaje całkowicie niezmieniona. Twoi developerzy wysyłają po prostu standardowe completion requests, a proxy egzekwuje twoje zasady compliance. Najbardziej niezawodne warstwy bezpieczeństwa to te, o których kod twojej aplikacji nigdy nie musi myśleć. Dzięki za wysłuchanie, udanego kodowania wszystkim!
16
Dynamiczne zarządzanie callbackami
3m 56sDaj mikrousługom siłę prywatności. Dowiedz się, jak używać nagłówka x-litellm-disable-callbacks, aby wrażliwe żądania API mogły zrezygnować z centralnego logowania obserwowalności.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny Gateway LLM, odcinek 16 z 24.
Chcesz logować cały ruch LLM do debugowania, ale co się stanie, gdy mikroserwis prześle bardzo wrażliwe dane objęte compliance, których absolutnie nie można zapisać? Możesz założyć, że musisz globalnie wyłączyć observability, oślepiając cały system tylko po to, by chronić kilka konkretnych route'ów API. Dynamic Callback Management rozwiązuje ten problem, pozwalając ci kontrolować logowanie na poziomie pojedynczego requestu.
W standardowej konfiguracji LiteLLM, callbacki obsługują wysyłanie payloadów twojego requestu i response'u do zewnętrznych platform observability. Konfigurujesz platformy takie jak Langfuse czy Datadog na poziomie proxy, a domyślnie przechwytują one wszystko, co przez nie przechodzi. Częstym błędem jest myślenie, że to logowanie działa na zasadzie wszystko albo nic. Ludzie często myślą, że do obsługi wrażliwych danych muszą zdeployować całkowicie oddzielne proxy z wyłączonym logowaniem. Dynamic Callback Management eliminuje tę dodatkową pracę.
Wyobraź sobie mikroserwis obsługujący dokumentację medyczną. Aplikacja musi przetworzyć objawy pacjenta przez model językowy, ale wysłanie tych wrażliwych danych do zewnętrznego logging stacku narusza zasady compliance. Aby zapobiec temu wyciekowi, mikroserwis po prostu dodaje określony nagłówek HTTP do swojego wychodzącego requestu. Ten nagłówek nazywa się x-litellm-disable-callbacks. Ustawiasz jego wartość na oddzieloną przecinkami listę konkretnych platform, które chcesz pominąć.
W przypadku serwisu dokumentacji medycznej, mikroserwis przekazuje nagłówek z wartością langfuse przecinek datadog. Gdy proxy LiteLLM otrzyma ten request, analizuje nagłówek przed wywołaniem modelu językowego. Prompt jest wysyłany do providera, a response wraca do klienta tak jak zwykle. Interwencja ma miejsce w fazie telemetrii. Proxy odczytuje nagłówek disable i aktywnie blokuje przekazanie payloadu do określonych endpointów observability dla tej jednej transakcji. W tym samym czasie wszystkie inne aplikacje, które równolegle uderzają do tego samego proxy, kontynuują logowanie swojego ruchu bez żadnych przerw.
Tutaj robi się ciekawie. Danie klientom możliwości wyłączania ich własnych logów audytowych wprowadza potencjalne ryzyko bezpieczeństwa. W mocno regulowanych środowiskach, developerzy nie zawsze powinni mieć prawo do ukrywania swojego ruchu. Jeśli twoja infrastruktura wymaga ścisłego, niezmiennego audit trailu dla każdego pojedynczego promptu, musisz to wymusić centralnie.
Robisz to za pomocą compliance locking. W pliku konfiguracyjnym proxy, w bloku ustawień ogólnych, ustawiasz parametr o nazwie allow dynamic callback disabling na false. To jedno ustawienie wprowadza surową, globalną politykę, która nadpisuje wszelkie instrukcje client-side.
Jeśli mikroserwis spróbuje przekazać nagłówek disable callbacks, gdy ta blokada jest aktywna, proxy nie zignoruje go po cichu. Zamiast tego całkowicie odrzuca transakcję i zwraca błąd HTTP 403 Forbidden. Ten mechanizm gwarantuje, że ruch albo jest zgodny z obowiązkową globalną polityką logowania, albo zostaje odrzucony przed dotarciem do modelu językowego.
Prawdziwą zaletą Dynamic Callback Management jest to, że przenosi prywatność danych ze sztywnego deploymentu infrastruktury na zwinny parametr na poziomie requestu, jednocześnie dając inżynierom platformy ostateczne zdanie w kwestiach compliance.
Dzięki za wysłuchanie, udanego kodowania wszystkim!
17
Obserwowalność typu drop-in
3m 49sZyskaj natychmiastowy wgląd w swój ruch LLM. Dowiedz się, jak przesyłać telemetrię, ślady (traces) i wyjątki do narzędzi takich jak Langfuse i Sentry, używając prostych callbacków dla sukcesów i błędów.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny Gateway LLM, odcinek 17 z 24. Kiedy użytkownik skarży się, że AI zwróciło mu dziwną odpowiedź trzy dni temu, jak wyciągnąć dokładny prompt, który to spowodował? Parsowanie logów aplikacji w poszukiwaniu wielolinijkowych payloadów JSON to koszmar. Potrzebujesz ustrukturyzowanych trace'ów, ale budowanie customowych integracji dla każdego narzędzia do monitoringu pożera godziny pracy inżynierów. Ten właśnie problem rozwiązuje Drop-in Observability.
Zamiast pisać customowe wrappery do mierzenia czasu wywołań API, liczenia tokenów i łapania timeoutów, LiteLLM natywnie przechwytuje cały ruch. Wystawia dwa główne hooki w ustawieniach: success callback i failure callback. Te callbacki działają jak automatyczne mechanizmy routingu dla twojej telemetrii. Przyjmują tablicę stringów reprezentujących wspieranych zewnętrznych dostawców observability. Po prostu podajesz nazwę narzędzia, którego chcesz użyć, a LiteLLM tłumaczy swoje wewnętrzne dane requestu na dokładny format, jakiego oczekuje to konkretne narzędzie.
Weźmy na przykład success callback. Odpala się on w momencie, gdy model językowy zwróci prawidłową odpowiedź. Kiedy to nastąpi, LiteLLM automatycznie robi snapshot transakcji. Zawiera on dokładny input prompt wysłany do modelu, wygenerowany output, czas generowania oraz dokładne zużycie tokenów. Aby wysłać te dane do zewnętrznego narzędzia, otwierasz ustawienia LiteLLM i ustawiasz zmienną success callback na listę zawierającą string "langfuse". Dopóki twoje klucze uwierzytelniające Langfuse znajdują się w zmiennych środowiskowych, system zajmie się resztą. Oto kluczowa kwestia. Proces logowania odbywa się asynchronicznie w tle. Główny wątek twojej aplikacji nigdy się nie blokuje w oczekiwaniu, aż dostawca observability potwierdzi trace'a. Twoi użytkownicy nie odczuwają żadnego dodatkowego latency.
To załatwia nam happy path. Do błędów używasz failure callback. Odpala się on, gdy wywołanie API zaliczy timeout, uderzy w rate limit dostawcy lub całkowicie zawiedzie. Bez odpowiedniego tracingu, błąd LLM często wypływa jako niejasny status code. Ustawiając zmienną failure callback na listę zawierającą string "sentry", mapujesz wyjątki LLM bezpośrednio na twój obecny workflow śledzenia błędów. Kiedy request się nie powiedzie, LiteLLM pakuje typ wyjątku, nazwę modelu i przekazany input, a następnie wypycha ten kontekst bezpośrednio do Sentry.
Aby skonfigurować to w kodzie, nie musisz modyfikować faktycznych wywołań API. Dotykasz tylko globalnej konfiguracji. Przypisujesz wybrane narzędzia do tablic callbacków tylko raz, podczas startu aplikacji. Od tego momentu każde twoje wywołanie completion jest monitorowane. Twoja główna logika pozostaje całkowicie odseparowana od infrastruktury logowania. Jeśli w przyszłym miesiącu zdecydujesz się zamienić Langfuse na innego dostawcę, zmieniasz tylko jeden string w tablicy.
Prawdziwa siła drop-in callbacków to nie tylko unikanie boilerplate'u. To standaryzacja kształtu twojej telemetrii u dziesiątek różnych dostawców LLM, dzięki czemu twoja platforma do monitoringu widzi dokładnie jeden spójny format, niezależnie od tego, który model pod spodem odpowiedział na prompt.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
18
Metryki Prometheus i kondycja Podów
3m 54sTrzymaj rękę na pulsie swojego proxy. Odkryj, jak wystawić endpoint /metrics dla Prometheus, śledzić żądania in-flight i używać niestandardowych tagów do analizy danych w Grafana.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, odcinek 18 z 24. Jeśli request LLM trwa dziesięć sekund, to czy dostawca AI jest wolny, czy może event loop twojego proxy jest całkowicie zapchany? Nie naprawisz wąskiego gardła, dopóki nie dowiesz się dokładnie, gdzie ono się znajduje. Prometheus Metrics i Pod Health w LiteLLM dają ci dokładnie taki wgląd.
LiteLLM wystawia standardowy endpoint metryk pod ścieżką slash metrics. Częstym błędem podczas monitorowania gatewayów AI jest traktowanie wszystkich opóźnień w odpowiedziach jako latency dostawcy LLM. To nieścisłe. Są dwa odrębne okresy oczekiwania. Po pierwsze, latency kolejki pre-ASGI. To czas, jaki request spędza czekając w twojej infrastrukturze, zanim proxy w ogóle zacznie go przetwarzać. Po drugie, właściwe latency LLM, czyli czas oczekiwania, aż OpenAI, Anthropic lub inny dostawca zwróci tokeny. Endpoint metryk rozdziela te liczby, dzięki czemu dokładnie wiesz, kogo winić za wolny response.
Aby monitorować health swojego poda, polegasz na konkretnym gauge'u o nazwie litellm in flight requests. Ta metryka śledzi dokładną liczbę współbieżnych requestów aktywnie przetwarzanych przez pod w dowolnej milisekundzie. To miara głębokości kolejki w czasie rzeczywistym. Kiedy ruch skacze, ta liczba rośnie.
Weźmy pod uwagę konkretny scenariusz. Twój dashboard monitoringu pokazuje ogromny skok całkowitego czasu trwania requestów. Użytkownicy narzekają na wolne odpowiedzi. Jeśli spojrzysz tylko na całkowity czas, możesz założyć, że OpenAI ma awarię. Ale kiedy sprawdzasz endpoint metryk, latency dostawcy jest stabilne i wynosi dwie sekundy. Oto kluczowy wniosek. Patrzysz na litellm in flight requests i widzisz, że ta wartość wystrzeliła z dwudziestu do dwustu. To dowodzi, że opóźnienie to nie wina OpenAI. Kolejka twojego poda jest całkowicie przeciążona. Uzbrojony w ten konkretny gauge, możesz skonfigurować swoją infrastrukturę tak, aby triggerowała event auto-scale w momencie, gdy in-flight requests przekroczą określony próg, stawiając nowe pody proxy, zanim event loop się zapcha.
Musisz również wiedzieć, kto generuje ten ruch. LiteLLM wspiera customowe tagi Prometheusa. Kiedy request uderza do gatewaya, możesz przekazać customowe metadane w payloadzie requestu, takie jak ID projektu, dział czy nazwa aplikacji. LiteLLM wyciąga te customowe tagi i dołącza je jako labele do metryk Prometheusa. Zamiast tylko widzieć, że gateway przetworzył dziesięć tysięcy tokenów, widzisz, że aplikacja marketingowa przetworzyła siedem tysięcy, a dashboard analityczny trzy tysiące. To daje DevOpsom możliwość grupowania zużycia tokenów, głębokości kolejki i latency po konkretnych tenantach.
Najważniejszy wniosek dotyczący wydajności gatewaya jest taki: nigdy nie auto-skaluj swojego proxy AI na podstawie całkowitego latency response'u, ponieważ zmarnujesz pieniądze na skalowanie w górę, gdy zewnętrzny dostawca po prostu działa wolno; skaluj na podstawie gauge'a in-flight requests, aby reagować tylko wtedy, gdy kolejka w twojej własnej infrastrukturze jest faktycznie pełna.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
19
Uniwersalne Text-to-Speech
3m 58sUstandaryzuj generowanie głosu. Odkryj, jak odpytywać modele Text-to-Speech z Gemini, Vertex i AWS Polly, używając dokładnie tego samego formatu endpointu audio kompatybilnego z OpenAI.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny gateway LLM, odcinek 19 z 24. Chcesz dodać generowanie głosu do swojej aplikacji, ale pisanie customowego kodu integracyjnego dla formatu audio każdego dostawcy wymaga ciągłego utrzymania. Za każdym razem, gdy przełączasz się z modelu głosowego OpenAI na model głosowy Google, wymagane pola JSON, ścieżki API i zwracane typy audio całkowicie się zmieniają. Mechanizmem, który rozwiązuje ten problem, jest Universal Text-to-Speech wykorzystujący bridge audio-speech w LiteLLM.
Zamiast utrzymywać osobne klienty API dla OpenAI, Vertex AI i Gemini, standaryzujesz swoją aplikację na jednym formacie. LiteLLM wystawia zunifikowany endpoint, który dokładnie naśladuje standardowy route audio-speech z OpenAI. Konstruujesz request zawierający twój tekst, wybraną nazwę modelu i preferencje głosu, wysyłając go do LiteLLM tak, jakbyś komunikował się bezpośrednio z OpenAI. Gateway następnie tłumaczy ten ustandaryzowany payload na specyficzny format wymagany przez docelowego dostawcę.
I tu jest kluczowa sprawa. Wielu dostawców AI nie oferuje prostego, dedykowanego API text-to-speech, które streamuje pliki audio out of the box. W zależności od dostawcy, natywny dostęp do modelu głosowego często wymaga przepuszczenia requestu przez generyczny endpoint text completion. Możesz musieć przekazać bardzo specyficzne flagi konfiguracyjne, wysłać złożony system prompt, a następnie wyciągnąć zakodowane w base64 stringi audio, głęboko zagnieżdżone w odpowiedzi JSON. LiteLLM abstrahuje całą tę warstwę translacji. Obsługuje negocjację API, rozpakowuje proprietarną strukturę odpowiedzi i izoluje właściwe dane audio.
Rozważmy konkretny scenariusz. Decydujesz się na wygenerowanie audio za pomocą modelu w wersji preview Gemini Flash TTS od Google. W kodzie aplikacji kierujesz swojego standardowego klienta HTTP na URL proxy LiteLLM pod ścieżką audio-speech. Ustawiasz parametr modelu tak, aby wskazywał na model Gemini Flash TTS. Przypisujesz swój plain text do parametru input i podajesz prawidłowy identyfikator głosu.
Kiedy wykonujesz request, LiteLLM przechwytuje payload. Bezpiecznie uwierzytelnia się w Google Cloud lub Vertex AI, w zależności od twojego setupu. Przepakowuje twój plain text i wybór głosu w specyficzny schemat JSON, którego wymaga API Google. Kiedy model Google przetworzy tekst i zwróci wynik, LiteLLM przechwytuje proprietarną odpowiedź. Zamiast zmuszać twoją aplikację kliencką do parsowania customowego payloadu Google Cloud, LiteLLM wyciąga surowe bajty audio. Płynnie spina warstwę transportową, natychmiast streamując standardowy plik MP3 z powrotem do twojego klienta. Twoja aplikacja frontendowa lub backendowa odbiera standardowy stream audio, całkowicie nieświadoma faktu, że generowanie pod spodem zostało wykonane przez Google, a nie OpenAI.
Ta logika bridge'a oznacza, że integrację klienta text-to-speech piszesz dokładnie raz. Jeśli jutro Vertex wyda nowy, szybszy model audio, musisz tylko zmienić string modelu w swoim requeście. Kod aplikacji obsługujący stream MP3 pozostaje całkowicie nietknięty. Traktowanie generowania audio dokładnie tak samo, jak generowania tekstu, pozwala ci ustandaryzować logikę aplikacji. Przepuszczając wszystkie requesty text-to-speech przez jeden zunifikowany interfejs, możesz routować, robić load-balancing i ustawiać failovery dla generowania audio pomiędzy zupełnie różnymi dostawcami, bez pisania ani jednej linijki kodu fallbackowego specyficznego dla danego dostawcy. Dzięki za wysłuchanie, udanego kodowania wszystkim!
20
Mostek Assistants API
3m 51sZarządzaj stanem konwersacji bez wysiłku u różnych dostawców. Dowiedz się, jak LiteLLM opakowuje nienatywne modele w standardowy interfejs OpenAI Assistants API, pozwalając Ci używać Threads i Messages wszędzie.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Universal LLM Gateway, odcinek 20 z 24. OpenAI doskonale obsługuje stan konwersacji, sprawiając, że twój kod klienta pozostaje całkowicie stateless. Ale uzależnienie swojej architektury od jednego dostawcy tylko po to, żeby zachować to zarządzanie stanem, to wysoka cena. Assistants API Bridge w LiteLLM rozwiązuje ten problem.
Ten bridge to funkcja proxy LiteLLM, która wystawia dokładnie te same endpointy co Assistants API od OpenAI. Uderzasz w standardowe ścieżki, takie jak endpointy v1 assistants i v1 threads, ale kierujesz samo generowanie tekstu do dowolnego modelu, jaki tylko chcesz.
Standardowe interfejsy chat completion są stateless. Za każdym razem, gdy zadajesz pytanie, twój klient musi wysłać całą historię konwersacji z powrotem na serwer. To zużywa transfer i komplikuje twój kod client-side. Assistants API rozwiązuje ten problem, trzymając historię konwersacji na serwerze wewnątrz obiektu Thread. Po prostu dodajesz nowe wiadomości do threada i mówisz serwerowi, żeby uruchomił asystenta. Problem w tym, że większość innych providerów, od lokalnych setupów po enterprise'owe alternatywy w chmurze, nie oferuje natywnie takiego stateful interfejsu.
Bridge w LiteLLM dostarcza polyfill dla tej brakującej funkcjonalności. Żeby to zadziałało, konfigurujesz proxy LiteLLM tak, aby łączyło się z bazą danych. Ta baza danych będzie działać jako storage layer dla twojego stanu konwersacji. Następnie kierujesz swój istniejący klient OpenAI na URL proxy LiteLLM zamiast na domyślne serwery OpenAI.
Logic flow zaczyna się od utworzenia asystenta. Wysyłasz request do proxy, definiując instrukcje asystenta i określając model docelowy. Może to być deployment Azure OpenAI albo kompatybilny z OpenAI model Astra. Proxy zapisuje tę konfigurację w swojej bazie danych.
Następnie tworzysz thread. Thread to po prostu pusty kontener przechowywany przez proxy. Kiedy użytkownik coś powie, wysyłasz request, żeby dodać wiadomość do tego konkretnego threada. Proxy zapisuje wiadomość. Do tego momentu w ogóle nie było kontaktu z podległym large language model.
I tu jest kluczowa sprawa. Bridge komunikuje się z twoim modelem docelowym tylko wtedy, gdy wyzwalasz run. Kiedy mówisz proxy, żeby wykonało run asystenta na konkretnym threadzie, LiteLLM pobiera całą historię wiadomości ze swojej bazy danych. Formatuje tę historię w standardowy, stateless payload dla chat completion. Następnie wysyła ten płaski payload do modelu pod spodem, który skonfigurowałeś wcześniej.
Model ewaluuje konwersację i zwraca odpowiedź do proxy. LiteLLM bierze ten tekst, pakuje go jako nową wiadomość asystenta, zapisuje w bazie danych dla tego threada i aktualizuje status runa na completed. Twój klient odpytuje proxy, widzi status completed i pobiera najnowszą wiadomość dokładnie tak, jak robiłby to normalnie.
Kod twojej aplikacji pozostaje całkowicie niezmieniony. Nadal myśli, że gada z natywnym, stateful systemem. Proxy obsługuje to tłumaczenie transparentnie, biorąc stateful request od klienta, wykonując stateless call do modelu i utrzymując persistence layer pomiędzy nimi.
To separation of concerns oznacza, że twoja architektura klienta może polegać na nowoczesnym, zarządzającym stanem interfejsie API, podczas gdy twoja infrastruktura ma pełną swobodę w podmienianiu modeli pod spodem w zależności od kosztów, prywatności czy wymagań wydajnościowych.
Dzięki za wysłuchanie, happy coding wszystkim!
21
MCP Gateway
4m 23sCentralnie wzmocnij swoje modele za pomocą narzędzi. Odkryj, jak skonfigurować serwery Model Context Protocol (MCP) oparte na HTTP, SSE lub STDIO w LiteLLM, dając każdemu LLM dostęp do zewnętrznych możliwości.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny Gateway LLM, odcinek 21 z 24. Masz lokalnie odpalony open-source'owy model Llama, ale chcesz, żeby triggerował akcje albo czytał pliki używając dokładnie tych samych integracji GitHub, z których korzysta twój agent Claude Code. Nie chcesz przepisywać logiki aplikacji, żeby supportować nowy toolset dla każdego nowego modelu. MCP Gateway rozwiązuje ten problem.
Po pierwsze, oddzielmy MCP od A2A, czyli routingu Agent-to-Agent. Częstym błędem jest traktowanie ich jako tego samego. A2A jest wtedy, gdy routujesz prompt użytkownika do wyspecjalizowanego zewnętrznego agenta, żeby wygenerować odpowiedź tekstową. MCP to zupełnie inna sprawa. MCP to skrót od Model Context Protocol. Chodzi w nim o dostarczenie modelowi ustandaryzowanego zestawu narzędzi, pozwalając mu decydować, kiedy i jak je wywołać, żeby wykonać taska.
Funkcja MCP Gateway pozwala proxy LiteLLM działać jako pomost między dowolnym modelem językowym a twoimi serwerami MCP. Zamiast pisać kod rejestrujący narzędzia w każdej budowanej aplikacji klienckiej, definiujesz je centralnie w proxy. Od tego momentu każdy model uderzający do proxy może korzystać z tych narzędzi.
LiteLLM łączy się z serwerami MCP za pomocą dwóch głównych metod. Pierwsza to STDIO, czyli Standard Input and Output. Używa się jej do lokalnych narzędzi. Konfigurujesz proxy, żeby wykonało konkretne lokalne polecenie, jak odpalenie skryptu w Node albo pliku w Pythonie, bezpośrednio na maszynie hosta. Druga metoda to HTTP z Server-Sent Events, czyli SSE. Służy ona do łączenia się ze zdalnymi serwerami MCP przez sieć.
Przyjrzyjmy się konkretnemu scenariuszowi. Chcesz dodać zdalny serwer MCP Zapier, żeby twoje modele mogły wchodzić w interakcje z zewnętrznymi aplikacjami webowymi. Robisz to w całości w pliku konfiguracyjnym YAML dla proxy. W głównym bloku konfiguracyjnym dodajesz sekcję MCP servers. Nazywasz integrację, na przykład zapier-integration. Definiujesz typ transportu jako SSE. Następnie podajesz URL endpointu twojego serwera MCP Zapier. Ponieważ jest to połączenie zdalne, musisz też określić wymagane nagłówki autoryzacyjne, takie jak bearer token, bezpośrednio w tej definicji YAML.
Teraz proxy wie, jak gadać z Zapier. Kolejny krok to wykonanie. Gdy twoja aplikacja kliencka wysyła standardowy request o chat completion do LiteLLM, musi tylko dołączyć konkretny nagłówek wskazujący, które narzędzia MCP chce załadować.
Oto kluczowa kwestia. Aplikacja kliencka nie musi wiedzieć, jakie narzędzia tak naprawdę oferuje Zapier. Proxy przechwytuje request klienta, uderza do serwera MCP Zapier przez połączenie SSE i dynamicznie pobiera aktualną listę dostępnych narzędzi. Następnie proxy wstrzykuje te definicje narzędzi do payloadu i przekazuje cały pakiet do modelu językowego.
Jeśli model językowy zdecyduje się wywołać narzędzie Zapier, wysyła tool call z powrotem do proxy. Proxy go przechwytuje, wykonuje akcję na serwerze MCP Zapier, pobiera wynik i zwraca go do modelu. Twoja aplikacja kliencka jest całkowicie odizolowana od tej wymiany komunikatów. Otrzymuje po prostu standardowe tool responses kompatybilne z OpenAI.
Prawdziwą siłą MCP Gateway jest oddzielenie implementacji narzędzi od wyboru modelu, co oznacza, że integracja zbudowana dla jednego ekosystemu działa natychmiast z dziesiątkami różnych modeli, bez pisania customowego kodu adaptera.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
22
A2A: Śledzenie autonomicznych agentów
3m 56sPrzejmij kontrolę nad autonomicznymi agentami. Dowiedz się, jak wywoływać złożonych agentów LangGraph lub Bedrock przez proxy za pomocą protokołu A2A, co umożliwia grupowanie śladów (trace grouping) i ujednolicone śledzenie wydatków.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Universal LLM Gateway, odcinek 22 z 24.
Kiedy twój autonomiczny agent wchodzi w pięćdziesięciokrokowy reasoning loop, jak przypisać koszty do pierwotnego requestu? Jeśli agent robi dziesiątki izolowanych calli do różnych modeli językowych, twoje logi bilingowe stają się nieczytelnym bałaganem niepowiązanych requestów. Rozwiązaniem tego problemu jest LiteLLM Agent Gateway, znany również jako A2A Protocol.
Zanim przejdziemy do mechaniki, wyjaśnijmy pewne częste nieporozumienie. Słuchacze często mylą to z Model Context Protocol, czyli MCP. MCP służy do dostarczania zewnętrznych toolsów do modelu językowego. A2A działa dokładnie odwrotnie. Traktuje zewnętrznego, autonomicznego agenta tak, jakby był standardowym modelem językowym, pozwalając ci go wywołać i śledzić przez scentralizowany gateway.
Aby to skonfigurować, definiujesz swojego agenta w pliku konfiguracyjnym LiteLLM dokładnie tak samo, jak standardowy model językowy. Nadajesz modelowi nazwę, ustawiasz base URL wskazujący na endpoint API twojego agenta i określasz providera jako customowy endpoint OpenAI. Teraz LiteLLM wie, jak routować przychodzące requesty od klienta bezpośrednio do twojego agenta.
Gdy klient wysyła request z prośbą o tego agenta, LiteLLM działa jako pass through dla headerów kontekstowych. Pobiera metadane powiązane z requestem, takie jak identyfikatory użytkowników, tagi team routingu i limity budżetowe, a następnie pakuje je w konkretne headery HTTP. Najważniejszym z nich jest header X-LiteLLM-Trace-Id. LiteLLM przekazuje te headery wraz z promptem do twojego agenta.
Oto kluczowa kwestia. Twój agent odbiera ten request, uruchamia swoją autonomiczną pętlę i zaczyna robić własne wewnętrzne calle, żeby przetworzyć zadanie. Jeśli agent robi te calle bezpośrednio do publicznego providera, tracisz kontekst śledzenia. Zamiast tego, agent musi routować swoje wewnętrzne calle z powrotem przez LiteLLM. Kiedy to robi, musi dołączyć trace ID, które otrzymał w pierwotnym requeście.
Wyobraź sobie konkretny scenariusz. Wywołujesz lokalnego agenta LangGraph. Klient wysyła prompt przez LiteLLM, aby rozpocząć proces. LiteLLM przypisuje unikalne trace ID i przekazuje payload do endpointu LangGraph. Twoja aplikacja LangGraph odczytuje przychodzące headery HTTP i wyciąga X-LiteLLM-Trace-Id. Kiedy LangGraph musi ewaluować krok lub podsumować dane, używa swojego wewnętrznego klienta, żeby wysłać completion call z powrotem do LiteLLM. Co kluczowe, dołącza dokładnie ten sam header trace ID do swojego wychodzącego requestu.
Ponieważ każdy wewnętrzny call niesie ze sobą to samo trace ID, LiteLLM grupuje je automatycznie. Kiedy patrzysz na swoją platformę observability albo logi budżetowe, nie widzisz pięćdziesięciu losowych requestów z nieznanych źródeł. Widzisz jeden zunifikowany trace. Wiesz dokładnie, który użytkownik ztriggerował agenta, ile kosztował cały reasoning loop i które konkretne autonomiczne kroki zjadły najwięcej budżetu.
Traktowanie agentów jako standardowych endpointów modelu przekształca złożone, wieloetapowe workflowy agentów w łatwe do śledzenia i rozliczania jednostki compute'u.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
23
Rotacja kluczy bez przestojów (Zero-Downtime)
3m 40sOsiągnij bezprzestojowe przełączenia bezpieczeństwa. Dowiedz się, jak skonfigurować automatyczne, zaplanowane rotacje kluczy i okresy karencji dla korporacyjnych Virtual Keys w LiteLLM.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny Gateway LLM, odcinek 23 z 24. Rotacja produkcyjnych kluczy API zazwyczaj oznacza zaplanowany downtime, gorączkową koordynację i nadzieję, że żaden backend nie zostanie w tyle z martwym credentialem. Hard cutover to rygorystyczny środek bezpieczeństwa, ale to także bardzo niezawodny sposób na przerwanie inflight requestów. Rozwiązaniem tego problemu jest rotacja kluczy typu zero-downtime.
W setupie enterprise proxy, trzymanie statycznych wirtualnych kluczy w nieskończoność to niedopuszczalne ryzyko bezpieczeństwa. LiteLLM radzi sobie z tym, pozwalając ci zaplanować automatyczną rotację kluczy. Zamiast ręcznie generować nowe credentiale i koordynować dokładny moment ich podmiany, pozwalasz, by to proxy zarządzało ich cyklem życia. Ale samo zautomatyzowanie tworzenia nowego klucza nie rozwiązuje podstawowego problemu z niezawodnością. Jeśli gateway odrzuci stary klucz w sekundę po utworzeniu nowego, każdy serwis, który jeszcze nie zsynchronizował nowego credentiala, natychmiast przestanie działać.
Aby to naprawić, LiteLLM używa grace period. Kiedy tworzysz lub aktualizujesz wirtualny klucz, konfigurujesz dwa konkretne parametry. Po pierwsze, ustawiasz interwał auto rotate, który dokładnie określa, jak często ma powstawać nowy klucz. Po drugie, definiujesz grace period, który mówi systemowi, jak długo stary klucz ma pozostać ważny po wykonaniu rotacji.
Wyobraź sobie standardową architekturę mikroserwisów, w której polityka bezpieczeństwa wymaga rotacji kluczy dostępu do LLM co trzydzieści dni. Wysyłasz request na endpoint generowania kluczy w LiteLLM. W tym requeście ustawiasz parametr auto rotate na 30 dni. W dokładnie tym samym requeście ustawiasz parametr grace period na 24 godziny. Proxy zapisuje tę politykę i uruchamia zegar.
Równo po trzydziestu dniach odpala się rotacja. LiteLLM automatycznie generuje zupełnie nowy wirtualny klucz. I to jest najważniejsza część. Przez następne 24 godziny masz dwa w pełni ważne klucze wskazujące na dokładnie tę samą konfigurację, budżet i logikę trackingu.
Podczas tego okna nakładania się, twój secrets manager pobiera nowy klucz i powoli wstrzykuje go do środowiska produkcyjnego. W miarę jak kontenery się restartują, a config mapy aktualizują, serwisy niezależnie przełączają się na nowy credential. Jeśli jakiś background worker nadal używa starego klucza w dwunastej godzinie trwania grace period, LiteLLM akceptuje request bez zająknięcia. Gateway routuje ruch do modelu LLM i normalnie loguje transakcję.
Gdy minie dokładnie 24-godzinny grace period, LiteLLM automatycznie unieważnia oryginalny klucz. Każdy system, który nadal będzie próbował użyć starego credentiala, otrzyma błąd autentykacji. Migracja jest zakończona.
Całkowicie oddzieliłeś tworzenie nowego secretu od niszczenia starego. Rozdzielenie tych dwóch zdarzeń zmienia rotację kluczy z kruchej, mocno skoordynowanej paniki w infrastrukturze w cichą, niezawodną rutynę w tle.
Dzięki za wysłuchanie, miłego kodowania wszystkim!
24
Admin UI oraz AI Hub
3m 57sSpraw, by Twoja platforma AI była dostępna dla każdego. Dowiedz się, jak zarządzać Admin UI, dostosowywać poświadczenia interfejsu i używać AI Hub, aby pozwolić programistom na bezpieczne odkrywanie dozwolonych modeli i agentów.
Cześć, tu Alex z DEV STORIES DOT EU. LiteLLM: Uniwersalny LLM Gateway, odcinek 24 z 24. Twój zespół platformowy zbudował wysoce bezpieczny, idealnie routowany LLM gateway. Ale kiedy wewnętrzni developerzy faktycznie muszą coś zbudować, skąd mają wiedzieć, z których modeli i agentów wolno im korzystać? Bez mechanizmu discovery, twój gateway to niewidzialna czarna skrzynka. Tę widoczność zapewniają Admin UI oraz AI Hub.
Admin UI to wizualny dashboard wbudowany bezpośrednio w proxy LiteLLM. Zarządzanie LLM gatewayem wyłącznie przez pliki konfiguracyjne i zapytania do bazy danych słabo się skaluje, gdy wiele zespołów zaczyna prosić o dostęp. Admin UI daje operatorom platformy scentralizowane miejsce do zarządzania proxy. Przez ten interfejs możesz generować nowe klucze API, śledzić zużycie tokenów w różnych zespołach, monitorować logi requestów na żywo i konfigurować reguły routingu modeli.
Kiedy po raz pierwszy odpalasz proxy LiteLLM, ten dashboard jest domyślnie włączony i zabezpieczony domyślnymi danymi logowania. Do testów lokalnych to wygodne rozwiązanie. Ale na produkcji to luka w zabezpieczeniach. Musisz natychmiast zmienić te domyślne dane logowania. Robisz to, ustawiając odpowiednie zmienne środowiskowe dla nazwy użytkownika i hasła administratora przed uruchomieniem kontenera.
I tu pojawia się kluczowa kwestia. Możesz w ogóle nie chcieć wystawiać graficznego dashboardu na swoim produkcyjnym gatewayu. Wiele zespołów platformowych stawia infrastrukturę wyłącznie za pomocą zautomatyzowanych skryptów i nie chce, żeby interaktywny control plane był dostępny przez sieć. Jeśli to pasuje do twojego modelu bezpieczeństwa, możesz całkowicie wyłączyć ten dashboard. Ustawiając zmienną środowiskową o nazwie disable admin ui na true, całkowicie usuwasz ten interfejs. Proxy będzie nadal routować ruch i egzekwować reguły, ale serwer webowy nie będzie serwować ekranów administracyjnych.
To załatwia sprawę operatorów platformy, ale inżynierowie konsumujący API potrzebują innej perspektywy. I tutaj wkracza AI Hub. O ile Admin UI służy do kontroli, AI Hub służy do discovery. Działa jako wewnętrzny developer portal dla twojej organizacji.
Zamiast pisać do zespołu platformowego z pytaniem, które modele są aktualnie zatwierdzone albo gdzie leży dokumentacja wewnętrznego agenta, developerzy wchodzą na AI Hub. Autentykują się, zazwyczaj przez organizacyjnego providera single sign-on, i dostają dostęp do katalogu. Mogą dokładnie zobaczyć, do których modeli mają uprawnienia, sprawdzić rate limity nałożone na te modele i odkryć prekonfigurowane agenty zbudowane przez inne zespoły.
Co ważniejsze, AI Hub pozwala developerom na self-serve. Mogą generować własne klucze API powiązane z budżetem ich konkretnego zespołu, bez czekania, aż inżynier platformy wyprovisionuje je ręcznie. To fundamentalnie zmienia sposób, w jaki twoja organizacja wchodzi w interakcję z generatywnym AI. Zasypuje to przepaść między inżynierami infrastruktury zabezpieczającymi gateway, a inżynierami produktu budującymi aplikacje.
Gateway jest użyteczny tylko wtedy, gdy jest dostępny, a AI Hub zamienia zablokowane proxy w platformę self-serve, pozwalając twoim zespołom inżynierskim na szybkie działanie bez przekraczania budżetu. I to by było na tyle w naszej serii o LiteLLM. Zachęcam cię do przejrzenia oficjalnej dokumentacji, wypróbowania tych konfiguracji hands-on i odwiedzenia dev stories dot eu, żeby zasugerować tematy na przyszłe serie. Dzięki za wysłuchanie i happy coding wszystkim!