De auteur betoogt dat de standaard dashboards van LLM-providers onvoldoende technische data en statistieken bieden voor engineers. Hij adviseert daarom om een eigen LLM-proxy te implementeren op een door jou beheerde omgeving. De belangrijkste voordelen hiervan zijn:
- Centraal beheer: Meerdere providers en modellen via één enkel endpoint.
- Gedetailleerde logging: Inzicht in welke sleutel, client en model op welk tijdstip is aangeroepen.
- Beveiliging: Gebruik van virtuele API-sleutels om de hoofdsleutel te beschermen.
- Flexibiliteit: Snel kunnen wisselen tussen verschillende modellen en providers.
De kernboodschap is dat men eigenaar moet zijn van de eigen infrastructuur en instrumentatie om LLM-inference effectief te kunnen temmen en analyseren.
Als je geen eigen LLM-proxy gebruikt, hoe weet je dan in godsnaam wat er aan de hand is?
Je werkt aan een idee, een stuk code, of een SaaS-app van miljarden per jaar die waarschijnlijk de wereld redt. Misschien automatiseer je het kloonproces van het ophalen van nieuwe Labubu-afbeeldingen, waarbij je een 2D-afbeelding via ComfyUI vertaalt naar een 3D-CAD om de productie van replica's sneller op gang te krijgen, omdat het Chinees Nieuwjaar (CNY) voor de deur staat en de wereldwijde productie rond die tijd stilvalt. Misschien gebruik je je tokens om in de krachtigste computersoftware ooit ontwikkeld te zoeken naar macronutriënteninformatie voor een McRib of iets dergelijks.
Je chat waarschijnlijk via een frontend die gekoppeld is aan een betaald abonnement van de provider naar keuze. TUI, GUI, spraakoproep, wat dan ook. Het is jouw data die erin gaat en hun data die terugkomt. Dat is wat ze verkopen, en ik koop dat op dit moment graag. Ze laten je iets zien als bewijs dat er werk wordt verricht:
Oei.
Dat is een afleiding. Dat zijn geen statistieken over tokengebruik met tijdreeksgegevens bedoeld voor engineers. Ik kan geen beslissing nemen met deze onzin. Je zou denken dat de grote labs waardevolle inzichten hebben om te delen met de nieuwsgierige gebruiker die in het analysepaneel duikt.
Ik kan geen beslissing nemen met deze onzin. Ik hoor je al: "er zijn OTel-exportopties!!1!". Leuk, denk ik. Dat is één reden; hier zijn er nog vijf die nu in me opkomen:
- Meerdere providers en modellen via één endpoint dat jij beheert.
- Logs van welke sleutel welk model heeft aangeroepen, met welke client, op welk tijdstip en wat de status was.
- Gebruik van virtuele API-sleutels om te voorkomen dat je je enige hoofdsleutel overal verspreidt over je werk, agents en harnesses.
- Het is infrastructuur die jij beheert.
- Je kunt extreem snel wisselen van model en provider zonder alles opnieuw in te stellen (waarschijnlijk voor de derde keer).
Ik ga geen specifieke proxy-provider aanbevelen, alleen dat je er zelf een draait op een plek die jij beheert. Wanneer je er een kiest, vergeet dan niet dat je deze kunt aanpassen aan je eigen behoeften. Ik heb die van mij aangepast voor beter inzicht, voor aangepaste MCP-server endpoints en extra functies. Wat je ook kiest, je zou data moeten krijgen in de trant van dit.
Wanneer ik een cache miss zie tijdens een coderingssessie, kan ik binnen 20 seconden handmatig pinpointen waarom dat is gebeurd. Ik heb het nog niet geautomatiseerd, maar de proxy die ik gebruik heeft een API, dus automatisering is mogelijk.
Wees eigenaar van je infrastructuur, je applicatie-zichtbaarheid, datapaden en opslag. Ik doe dit thuis omdat het leuk is en omdat ik zo graag leer. Ik doe dit op het werk omdat ik mijn baan niet goed doe als ik het niet doe. Misschien zal ik nooit volledig begrijpen hoe een large language model precies werkt, goed genoeg om het tijdens een interview op een whiteboard uit te tekenen. Maar ik kan het temmen en ervoor zorgen dat het geïnstrumenteerd is terwijl het inference serveert.
Als je geen eigen LLM-proxy gebruikt, hoe weet je dan in godsnaam wat er aan de hand is?
Je werkt aan een idee, een stuk code, of een SaaS-app van miljarden per jaar die waarschijnlijk de wereld redt. Misschien automatiseer je het kloonproces van het ophalen van nieuwe Labubu-afbeeldingen, waarbij je een 2D-afbeelding via ComfyUI vertaalt naar een 3D-CAD om de productie van replica's sneller op gang te krijgen, omdat het Chinees Nieuwjaar (CNY) voor de deur staat en de wereldwijde productie rond die tijd stilvalt. Misschien gebruik je je tokens om in de krachtigste computersoftware ooit ontwikkeld te zoeken naar macronutriënteninformatie voor een McRib of iets dergelijks.
Je chat waarschijnlijk via een frontend die gekoppeld is aan een betaald abonnement van de provider naar keuze. TUI, GUI, spraakoproep, wat dan ook. Het is jouw data die erin gaat en hun data die terugkomt. Dat is wat ze verkopen, en ik koop dat op dit moment graag. Ze laten je iets zien als bewijs dat er werk wordt verricht:
Oei.
Dat is een afleiding. Dat zijn geen statistieken over tokengebruik met tijdreeksgegevens bedoeld voor engineers. Ik kan geen beslissing nemen met deze onzin. Je zou denken dat de grote labs waardevolle inzichten hebben om te delen met de nieuwsgierige gebruiker die in het analysepaneel duikt.
Ik kan geen beslissing nemen met deze onzin. Ik hoor je al: "er zijn OTel-exportopties!!1!". Leuk, denk ik. Dat is één reden; hier zijn er nog vijf die nu in me opkomen:
- Meerdere providers en modellen via één endpoint dat jij beheert.
- Logs van welke sleutel welk model heeft aangeroepen, met welke client, op welk tijdstip en wat de status was.
- Gebruik van virtuele API-sleutels om te voorkomen dat je je enige hoofdsleutel overal verspreidt over je werk, agents en harnesses.
- Het is infrastructuur die jij beheert.
- Je kunt extreem snel wisselen van model en provider zonder alles opnieuw in te stellen (waarschijnlijk voor de derde keer).
Ik ga geen specifieke proxy-provider aanbevelen, alleen dat je er zelf een draait op een plek die jij beheert. Wanneer je er een kiest, vergeet dan niet dat je deze kunt aanpassen aan je eigen behoeften. Ik heb die van mij aangepast voor beter inzicht, voor aangepaste MCP-server endpoints en extra functies. Wat je ook kiest, je zou data moeten krijgen in de trant van dit.
Wanneer ik een cache miss zie tijdens een coderingssessie, kan ik binnen 20 seconden handmatig pinpointen waarom dat is gebeurd. Ik heb het nog niet geautomatiseerd, maar de proxy die ik gebruik heeft een API, dus automatisering is mogelijk.
Wees eigenaar van je infrastructuur, je applicatie-zichtbaarheid, datapaden en opslag. Ik doe dit thuis omdat het leuk is en omdat ik zo graag leer. Ik doe dit op het werk omdat ik mijn baan niet goed doe als ik het niet doe. Misschien zal ik nooit volledig begrijpen hoe een large language model precies werkt, goed genoeg om het tijdens een interview op een whiteboard uit te tekenen. Maar ik kan het temmen en ervoor zorgen dat het geïnstrumenteerd is terwijl het inference serveert.
Groetjes,