MLOps versus LLMOps: infrastructuur voor foundation models

Viacheslav Dubrov

2025-05-06 · Bijgewerkt 2026-10-02 · 13 min · AI-infrastructuur

Automatische vertaling

Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Dit artikel is bedoeld voor ML- en platformengineers die al MLOps draaien en nu een systeem beheren dat op een foundation model is gebouwd. In zo’n systeem kan een regressie komen van een gewijzigde prompt, index, tool-permissie of route, terwijl de model weights gelijk blijven. Het artikel behandelt welke MLOps-praktijken nog gelden, wat je nog meer moet versioneren wanneer prompts, retrieval, tools en routing het gedrag kunnen veranderen, hoe je zo’n systeem evalueert en tracet, en welke tools elke taak uitvoeren.

Wat MLOps al heeft opgelost

Het diagram toont de MLOps-lus van vijf stappen; de gestippelde lijn brengt incidentbewijs terug naar de offline releasecontrole. MLOps heeft deze praktijken gevestigd, en ze gelden nog steeds wanneer het model tekst genereert:

• lineage van data, code, configuratie en model naar een release
• herhaalbare training- of build-pipelines
• offline validatie vóór promotie
• registries en onveranderlijke artifact-identiteit
• gefaseerde uitrol, service-level objectives, rollback en incidentrespons
• infrastructuurtelemetrie en capaciteitsplanning
• toegangsbeheer, bewaartermijnen en auditbeleid voor data

De meeste orchestration-tools die je al draait, passen nog steeds, maar niet op elk pad:

Foundation models halen deze behoeften niet weg. Ze maken de oude term “modelversie” te klein.

De release-eenheid werd een systeemmanifest

De bovenste groep in het diagram is wat MLOps al versioneert; de onderste groep is wat een systeem op basis van een foundation model toevoegt. Vanuit elke groep loopt een lijn naar het manifest, omdat elke component het gedrag kan veranderen.

Voor een systeem op basis van een foundation model raad ik een manifest aan dat minstens het volgende vastlegt:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

De exacte lijst hangt af van het systeem. De regel is: benoem elke component die zelfstandig verandert en het gedrag voor de gebruiker kan wijzigen.

Behandel de modelnaam van een provider als wijzigbaar, tenzij de provider een onveranderlijke revisie documenteert. Een checkpoint-hash helpt om zelf gehoste weights te identificeren, maar ik zou toch de runtime, quantization, chat template en parallelisme-configuratie vastleggen. Het modelitem komt uit een registry: gebruik MLflow Model Registry voor weights en adapters die je zelf traint, en de Hugging Face Hub voor open weights, vastgezet op een commit met het argument revision in plaats van een branchnaam.

Bewaar het manifest als bestand naast elke release. Als een release achteruitgaat, vergelijk je het met het vorige. In dit voorbeeld voor een support-assistent zijn alleen de antwoordprompt en de retrieval-snapshot veranderd:

-    answer: prompts/answer.md@v9
+    answer: prompts/answer.md@v10
-    corpus: kb-snapshot-2026-09-28
-    index: kb-idx-2026-09-28-01
+    corpus: kb-snapshot-2026-10-01
+    index: kb-idx-2026-10-01-01

De diff wijst de componenten aan die je eerst controleert: de antwoordprompt en de nieuwe index. De weights, tools en routing zijn niet veranderd.

Welke component je eerst inspecteert

De manifest-diff laat zien wat er is veranderd. Het soort fout vertelt je waar je moet zoeken wanneer de diff alleen het probleem niet verklaart:

Voor de keuze tussen de prompt aanpassen, retrieval toevoegen en fine-tuning, zie fine-tuning vs RAG vs prompting.

Vijf componenten die het gedrag kunnen veranderen

De onderstaande secties behandelen vijf componenten uit het manifestdiagram in volgorde: het model en de serving, dan prompts en schema, het retrieval-corpus en de index, tools en permissies, en veiligheids- en bedrijfsregels. Elke sectie zegt wat je vastlegt, wat je test en welke tools de taak uitvoeren. Routing en fallback krijgen samen met de gateway een eigen sectie.

1. Model en serving

De eerste beslissing is of een provider het model host of dat je het zelf serveert. Een gehoste API neemt het GPU-werk weg. Elke request gaat over het netwerk, je betaalt per token, de data die je verstuurt verlaat je netwerk, en de provider bepaalt de weights, revisies, quota en prijs. Zelf hosten geeft je controle over revisie, quantization, batching, regio en cache. Je beheert dan ook zelf de GPU-capaciteit, en je betaalt ervoor, of die nu bezig is of stilstaat.

Het diagram zet de twee modi naast elkaar: wie wat controleert, waarvoor je betaalt en wanneer elke modus past. In beide modi legt het manifest de route vast en draait dezelfde takensuite.

Als je zelf host, kies je de serving-engine op basis van de deployment-vorm:

Modellen die te groot zijn voor één GPU hebben tijdens het serveren tensor- of pipeline-parallelisme nodig; Scaling LLMs with multi-GPU and multi-node parallelism legt elke methode uit. Om een weight-formaat te kiezen voor de runtime en hardware, zie LLM quantization formats.

Neem in beide modi latency, fouten, throughput, verzadiging, kosten en kwaliteitscontroles van de taak mee in de releasebeslissing.

2. Prompts en schema

Versioneer bij een systeem dat requests tijdens runtime samenstelt de samengestelde request, niet alleen de prompttekst: de volgorde van berichten, tool-beschrijvingen, responseschema, decoding, retries, truncatie en omliggende code kunnen elk het gedrag veranderen.

Een kleine promptwijziging kan het uitvoerformaat veranderen. Hier zijn drie versies van een sentiment-prompt:

v1: "Classify this text as positive or negative: {text}"
v2: "You are a sentiment analyzer. Classify: {text}"
v3: "Analyze sentiment. Return only 'positive' or 'negative': {text}"

v1 en v2 kunnen een zin teruggeven zoals “The sentiment is positive.” v3 vraagt om één woord. De code die het antwoord verwerkt moet met de prompt meeveranderen, dus de prompt, het schema en de parser horen samen in het manifest.

Behandel parseerbare JSON als een transportcontrole en test de bedrijfsinvarianten van de taak apart.

3. Retrieval-corpus en index

Retrieval voegt een zelfstandig dataproduct toe tussen de bron van waarheid en het model:

Volg één request door het diagram: de indexversie voedt retrieval, daarna toetsen drie afzonderlijke controles de autorisatie, het opgehaalde bewijs en het antwoord.

Leg voor een systeem met retrieval-augmented generation de bronrevisie, de versies van parser en chunker, de embedding-identiteit, de index-build, de toegangsmetadata en de verwijderstatus vast. Het oorspronkelijke RAG-ontwerp scheidt retrieval van generatie; gebruik die scheiding om het ophalen van bewijs, autorisatiefiltering en het gebruik van bewijs onafhankelijk van elkaar te testen. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks beschrijft de retrieve-then-generate-architectuur. RAG evaluation metrics behandelt de metrics voor elke controle, en RAG evaluation tools vergelijkt de bibliotheken die ze berekenen.

Kies de indexopslag op basis van wie hem gebruikt. Een in-process bibliotheek zoals FAISS is genoeg wanneer één service de index beheert en die in het geheugen van die service past. Gebruik een vector database-server zoals Pinecone, Weaviate of Milvus wanneer meerdere services de index delen, wanneer je tijdens de query metadatafilters nodig hebt, of wanneer de index één machine ontgroeit. Voor het retrieval-ontwerp zelf (één ronde, iteratief zoeken of GraphRAG), zie RAG architecture.

Kies de updatemethode op basis van hoe verouderd een antwoord mag zijn. Een geplande rebuild werkt wanneer een antwoord van een dag oud acceptabel is. Moet een wijziging binnen enkele minuten zichtbaar zijn, stream dan de updates, bijvoorbeeld Kafka-events naar een embedding-job die naar de index schrijft. In beide gevallen legt het manifest vast welke index-build elk antwoord leverde.

Gebruik een vectorindex niet als vervanging van een feature store of warehouse: similarity retrieval, point-in-time features en analytische feiten hebben verschillende eisen aan queries en consistentie.

De twee panelen tonen het verschil: een feature store geeft de juiste feiten voor één entiteit op één moment terug, en een vector database geeft documenten terug, gerangschikt op similarity met de query. Houd het warehouse voor analyses.

4. Tools en permissies

Wanneer een model API’s kan aanroepen, zet je deze controles rond elke tool call: tool-authenticatie, least privilege, argumentvalidatie, timeouts, idempotentie, goedkeuringsbeleid en postconditiecontroles. Het Generative AI Profile van NIST benoemt risico’s van schadelijke inhoud, privacy en beveiliging.

Het diagram toont vier van deze controles in volgorde en waar een aanroep stopt: een afgewezen permissie of argument, een geweigerde goedkeuring, of een resultaat dat niet overeenkomt met de verwachte postconditie.

Trace welke tool is aangeboden, gekozen, aangeroepen, afgewezen, opnieuw geprobeerd en gecommit. Een vloeiend eindantwoord bewijst niet dat het actiepad correct was.

5. Veiligheids- en bedrijfsregels

Contentfilters zijn één maatregel, geen volledige guardrail-laag. Bedreigingen omvatten ook prompt injection, cross-tenant retrieval, het lekken van secrets, excessive agency (een item in de OWASP Top 10 for LLM Applications), niet-vertrouwde modelbestanden of aangepaste code die tijdens runtime wordt geladen, en onveilige tool-argumenten.

Druk deterministische bedrijfsregels waar mogelijk buiten het model uit. Definieer restrisico’s, test adversariële gevallen en wijs een eigenaar aan voor beleidswijzigingen. Het Generative AI Profile van NIST is een bruikbare risico-inventaris, geen kant-en-klare acceptatietest.

Evaluatie beslist over de release

Vertrouw voor releasebeslissingen over vrije uitvoer niet op één geaggregeerd nauwkeurigheidsgetal. Gebruik meerdere soorten bewijs en bepaal per faaltype welk bewijs doorslaggevend is.

Een evaluatiestack voor een systeem op basis van een foundation model heeft zes lagen:

1. Deterministische controles: geldigheid van het schema, aanwezige citaties, toegestane tools, argumentbeperkingen, beleidsregels, latency en budget.
2. Componentmetrics: retrieval-recall en rangschikking, nauwkeurigheid van toolselectie, juistheid van tool-argumenten en routeselectie.
3. End-to-end taken: representatieve invoer met expliciete succescriteria en slice-labels.
4. Modelgebaseerde scoring: rubricgestuurde oordelen, gekalibreerd tegen expertlabels en gemonitord op judge-drift.
5. Menselijke beoordeling: dubbelzinnige, ingrijpende, nieuwe of gesamplede gevallen waarin automatisering niet doorslaggevend is.
6. Adversariële tests: gevallen van injectie, datagrenzen, misbruik, weigering en neveneffecten, gekoppeld aan het threat model.

Bewaar resultaten per voorbeeld, niet alleen gemiddelden, zodat de releasebeoordeling regressies kan inspecteren per taal, tenant, documenttype of actieklasse.

Vergelijk voor een deploymentbeslissing een kandidaat-manifest met de huidige release op dezelfde geversioneerde suite. Stel drempels voor kwaliteit, veiligheid, latency en kosten samen vast en wijs een goedkopere route af die de takensuite niet haalt.

Valt elk resultaat binnen zijn drempel, start dan een gefaseerde uitrol. Faalt er één, wijs de kandidaat dan af. Is het resultaat van een slice onduidelijk, stuur het dan naar menselijke beoordeling.

Om een evaluatietool te kiezen voor traces, datasets en CI-controles, zie AI agent evaluation tools.

Traces verbinden productie met evaluatie

Lees het diagram vanaf stap 1: een productierequest wordt een trace, een beoordeelde fout en een gelabeld regressiegeval. Evaluatie vergelijkt een kandidaatwijziging met de huidige release, en de gestippelde lijn brengt het gemonitorde resultaat van de gefaseerde release terug naar productie.

Infrastructuurmetrics kunnen een trage modelaanroep tonen. Ze kunnen niet tonen dat retrieval een ongeautoriseerd document teruggaf of dat een tool met het verkeerde account werd aangeroepen. De tracing-documentatie van MLflow beschrijft traces die tussenstappen en metadata vastleggen die nodig zijn om dit pad te inspecteren.

Leg een trace vast over het hele beslispad:

• identiteit van het release manifest en request-correlatie
• aanroepen van model en provider, latency, gebruik en eindstatus
• retrieval-query, document-ID’s, scores en filterbeslissingen
• prompt- en templaterevisie, zonder gevoelige inhoud lukraak op te slaan
• tool-aanbiedingen, argumenten, goedkeuringen, resultaten en ID’s van neveneffecten
• beleidsbeslissingen, retries, fallbacks en eindresultaat

Traces zijn een nieuwe opslag van gevoelige data. Pas minimalisatie, redactie, tenant-isolatie, versleuteling, sampling, bewaartermijnen en toegangsreview toe voordat je volledige prompts of documenten verzamelt. De GenAI semantic conventions van OpenTelemetry kunnen helpen bij interoperabiliteit, maar ze zijn nog in ontwikkeling. Zet de versie van de conventie of het schema vast, evenals de versies van instrumentatie en collector.

Gebruikersfeedback kan onderzoek prioriteit geven, maar een duim omhoog is geen ground truth. Bewaar de omliggende trace en laat experts gevallen met gevolgen labelen. Label Studio verzamelt labels voor tekst, afbeeldingen en andere datatypen; Argilla verzamelt feedback op tekst en LLM-uitvoer en kan de datasets naar de Hugging Face Hub pushen. AI agent evaluation in production laat zien hoe je gelabelde traces omzet in een geversioneerde regressiesuite.

De serving-gateway beheert routing en beleid

In het diagram neemt elke request één route door de gateway en krijgt hetzelfde responscontract terug; de gestippelde lijn opzij toont dat de takensuite elke route offline evalueert vóór promotie.

Een gateway kan applicatieclients loskoppelen van providers of zelf gehoste engines. Verantwoordelijkheden die je er verstandig neerlegt:

• authenticatie, tenantbudgetten, quota en rate limits
• stabiele request- en responscontracten
• routeselectie op basis van capaciteit, regio, latency of geëvalueerde kwaliteit
• routing op basis van abonnementsniveau, bijvoorbeeld een groter model voor betaalde abonnementen
• een klein deel van het verkeer naar een nieuw model sturen vóór een volledige uitrol
• begrensde retries, circuit breakers en expliciete fallback-semantiek
• cachepartitionering en beleid voor gevoelige data
• gebruikstoewijzing en doorgifte van het release manifest

LiteLLM Proxy is één open-source gateway: hij ontsluit veel providers via één OpenAI-compatibele API en stelt budgetten en rate limits in per sleutel of team.

Fallback is net zozeer een gedragsverandering als een betrouwbaarheidsmechanisme. Als een kleiner model, een andere provider of een verkleinde context de taakkwaliteit verandert, evalueer en trace die tak dan als een eigen route.

Leg niet elke orchestration-beslissing in de gateway. Houd domeinregels dicht bij de applicatie en maak het eigenaarschap zichtbaar.

Fine-tuning en LoRA

De laatste rij van de fouttabel in “Welke component je eerst inspecteert” is het geval voor fine-tuning: het gedrag dat de taak nodig heeft, is niet uit de prompt of de opgehaalde context te halen. LoRA bevriest voorgetrainde weights en voegt trainbare matrices van lage rang toe, waardoor het aantal trainbare parameters voor de downstream-taak daalt. Die optimalisatie neemt de eisen aan datasetbeheer, licenties van het basismodel, evaluatie, serving-compatibiliteit en rollback niet weg.

Leg de adapterinstellingen in het manifest vast naast de revisie van het basismodel: de rang (r), de schaalfactor (lora_alpha) en welke lagen hij wijzigt (target_modules). Elk daarvan verandert wat de adapter leert. De LLM fine-tuning guide behandelt datasets, QLoRA en trainingstools, en de LoRAX serving guide behandelt het serveren van veel adapters op één basismodel.

Een praktische volgorde voor invoering

1. Definieer de gebruikerstaak, schadegrenzen, service-doelen en kostenkader.
2. Maak het release manifest voordat je een promptregister, vector database of gatewayproduct introduceert.
3. Bouw een kleine, in slices verdeelde evaluatieset en deterministische componenttests.
4. Instrumenteer één end-to-end trace met privacymaatregelen en stabiele releaseidentiteiten.
5. Promoveer via shadow-, canary- of beperkt verkeer met een expliciete rollback-trigger.
6. Zet beoordeelde fouten uit productie om in regressiegevallen en herhaal.

Voeg alleen infrastructuur toe wanneer die een taak uitvoert die het manifest benoemt of een gemeten bottleneck wegneemt.

Referenties

• MLflow: evaluating production traces - Hergebruik productietraces voor evaluatie en scoor tussentijdse trace-informatie.
• MLflow: LLM and agent tracing - Leg tussenstappen en trace-metadata vast voor onderzoek.
• OpenTelemetry GenAI semantic conventions - Huidige conventies met ontwikkelstatus voor GenAI-spans, metrics, events en providerspecifieke data.
• NIST AI 600-1: Generative AI Profile - Risicocategorieën voor prompt injection, privacy, beveiliging en aanverwante zorgen rond generatieve AI.
• OWASP Top 10 for LLM Applications - Bevat excessive agency (LLM06:2025) en prompt injection (LLM01:2025).
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - Oorspronkelijke retrieve-then-generate-architectuur.
• LoRA: Low-Rank Adaptation of Large Language Models - Bevroren voorgetrainde weights plus trainbare matrices van lage rang voor downstream-adaptatie.
• PEFT LoRA reference - LoraConfig-parameters en get_peft_model.
• vLLM documentation - Serving-engine met continuous batching, quantization, multi-LoRA en een OpenAI-compatibele server.
• NVIDIA Dynamo-Triton - Inference-server die voorheen Triton Inference Server heette, met een TensorRT-LLM backend.
• LiteLLM Proxy - Open-source gateway met één API voor alle providers, budgetten, rate limits en fallbacks.