Data Panda brengt je LiteLLM-proxy-data samen met de data uit de rest van je bedrijf. Vanop één plek maken we er dashboards, workflows, AI-toepassingen en apps van die je team elke dag gebruikt.
LiteLLM is een open source LLM-gateway gebouwd door BerriAI, een Y Combinator-bedrijf opgestart in 2023 door Krrish Dholakia en Ishaan Jaff. De repo staat op GitHub onder BerriAI/litellm met 44k+ sterren en meer dan duizend contributors. Stripe, Netflix, Google ADK, Greptile en OpenHands draaien het in productie, naast de lange staart van teams die één endpoint wilden in plaats van tien provider-SDK's.
Het product heeft twee vormen. De Python-SDK laat code litellm.completion() aanroepen met dezelfde call-signatuur ongeacht de provider. De Proxy is een self-hosted server (Docker, Kubernetes of de LiteLLM CLI) die één OpenAI-compatibel REST-endpoint aanbiedt en de call routeert naar OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Google Vertex AI, Cohere, Mistral, Hugging Face, Groq of eender welke van de 100+ providers waar hij mee praat. Rond die proxy zitten virtuele API-keys per team of gebruiker, budgetten per key en per team, rate limits, automatische fallback en retry over deployments, response caching en gestructureerde spend logs. De Postgres-tabellen achter de proxy (LiteLLM_VerificationToken, LiteLLM_TeamTable, LiteLLM_UserTable, LiteLLM_SpendLogs, LiteLLM_BudgetTable) bewaren elke request met api_key, user, team_id, end_user, model, model_group, prompt_tokens, completion_tokens, total_tokens, spend, request_tags en metadata erbij, en dat is wat van een stapel provider-facturen iets maakt dat een finance- en ML-team effectief kan bevragen.
Spend, tokens en modelmix per virtuele key, team en end-user over elke provider op één tijdlijn.
Duw gebruikssignalen terug naar de tools waar de beslissingen rond LLM-spend effectief vallen.
Gebruik LiteLLM-historiek om de volgende ronde van routing- en prompt-beslissingen te voeden.
Interne tools op LiteLLM-data voor teams die niet in de proxy-admin-UI leven.
Een lijst van concrete rapporten, automatisaties en AI-toepassingen die we op LiteLLM-data hebben gebouwd. Kies er een die bij je situatie past.
Welk team drijft onze LLM-factuur eigenlijk, en op welke provider?
Spend per LiteLLM-team over de laatste dertig dagen, gesplitst per onderliggende provider (OpenAI, Anthropic, Bedrock, Vertex, de rest), met de model_group- en request_tag-splitsing erbovenop. Brengt het ene team naar boven dat een agent-loop draait op GPT-4-klasse-modellen en het grootste deel van de factuur produceert terwijl de support-copilot op een goedkopere tier amper meetelt, vóór de volgende provider-factuur als één getal per provider binnenkomt.
Zijn we goedkoper op OpenAI of op Anthropic voor deze workflow?
Spend en total_tokens per request_tag gekoppeld aan model_group, met kost per call en kwaliteitssignalen uit je eval-pipeline ernaast. Laat het ML-team beantwoorden of dezelfde prompt goedkoper draait op Sonnet of op GPT-4o mini met een getal in plaats van met een buikgevoel, en laat routing-regels gezet worden op iets anders dan de luidste mening in de kamer.
Welke klanten draaien AI-features boven wat hun plan aannam?
Spend per end_user uit de LiteLLM-spend-log, gekoppeld aan CRM-klant, plan-tier en MRR. Toont de klant op een klein plan waarvan de AI-assistent tienduizenden euro's LLM-spend per maand produceert, zodat account management met een echt getal naar het hernieuwingsgesprek gaat, en customer success accounts kan markeren waarvan het verbruik richting de contractlimiet kruipt.
LLM-spend per team, per virtuele key en per end-user in plaats van één lijn op elke provider-factuur. De AI-kost verschuift van een vaste onbekende verspreid over OpenAI, Anthropic en Bedrock naar één meetwaarde die vastzit aan de teams en klanten die ze produceren, op tijd om in te grijpen vóór de volgende kwartaal-commitment-hernieuwing.
AI-gebruik per klant in hetzelfde record dat accountmanagers toch al openen, zodat een klant met zware GPT-4-traffic op een klein plan een hernieuwingsgesprek wordt in plaats van een verrassing op de jaarlijkse review.
Provider-mix, fallback-ratio, model_group-routing en cache-hitratio per template gevolgd als een curve over negentig dagen. Het gedrag van de AI-features wordt niet pas opgemerkt de ochtend dat een deploy de factuur op één provider stil verdrievoudigde.
Je houdt de rapporteringstool die je al hebt. Wij koppelen hem aan het warehouse waar je LiteLLM-data staat.
OAuth-authenticatie. Standaard read-only. Wij tekenen een DPA en je admin houdt de sleutels.
Data stroomt naar je warehouse op het schema dat jij kiest. Bijna real-time of 's nachts, aan jou. Jij bent eigenaar.
We bouwen het eerste dashboard, de eerste workflow of AI-toepassing samen met jou, en geven de sleutels over. Of we blijven erbij voor doorlopende levering.
Wij zetten de basis op. Jouw team bouwt erop verder.
Beste match Teams die al een BI-analist of data engineer in huis hebben en zelf willen bouwen.
Wij bouwen het geheel, van A tot Z.
Beste match Teams zonder BI- of dev-capaciteit in huis. Jij zegt wat je nodig hebt en wij leveren het.
Jij. Ze komt in jouw warehouse terecht, op jouw cloud-account. Wij verkopen ze niet door en aggregeren ze niet. Stop je met ons, dan blijft het warehouse van jou en blijft het draaien.
Bijna real-time voor de meeste operationele systemen. Voor zwaardere bronnen plannen we per uur of per nacht. Je kiest op basis van wat de rapporten nodig hebben.
Nee. Heb je er geen, dan helpen we je er een kiezen en zetten we het op als deel van de eerste levering. Gangbare startpunten zijn Snowflake, Microsoft Fabric of een kleine Postgres-start.
De Postgres-tabellen van de proxy zijn de primaire bron: LiteLLM_SpendLogs (één rij per call, met api_key, user, team_id, end_user, model, model_group, prompt_tokens, completion_tokens, total_tokens, spend, request_tags en metadata), LiteLLM_VerificationToken (de virtuele keys), LiteLLM_TeamTable, LiteLLM_UserTable en LiteLLM_BudgetTable. Klant-prompts en -completions worden standaard niet binnengehaald, tenzij je proxy zo geconfigureerd is dat hij ze logt; de connector beperkt zich standaard tot meterdata.
De provider-connectoren geven je wat elke provider ziet: tokens en spend per zijn eigen API-key. LiteLLM geeft je wat je organisatie ziet: dezelfde call toegewezen aan een virtuele key, een team, een end-user en een request_tag, over elke provider op één schema. De twee vullen elkaar aan. De provider-connectoren houden de factuur eerlijk, de LiteLLM-connector houdt de interne toewijzing eerlijk.
Het schema is in beide gevallen hetzelfde, dus het warehouse-model verandert niet. Self-hosted deployments stellen Postgres rechtstreeks open voor de connector, cloud-deployments stellen dezelfde data beschikbaar via de LiteLLM API. Meerdere proxy-instances (bijvoorbeeld één per environment of één per regio) kunnen in het warehouse samengevoegd worden, zodat spend over de hele groep maar één keer gerapporteerd wordt.
We bekijken je LiteLLM-opzet en de systemen eromheen. Samen kiezen we wat we als eerste bouwen.