Automatische vertaling

Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

MLOps vs LLMOps: Infrastructuur voor foundation models en LLM-systemen

Foundation models hebben de meeste aannames doorbroken waarop klassieke MLOps was gebouwd. Dit is een overzicht van wat veranderde, wat bleef, en welke patronen het gat opvulden.

Klassieke MLOps vóór foundation models

Een paar jaar geleden betekende MLOps vooral DevOps voor ML — automatiseer de levenscyclus van datapreparatie via deployment tot monitoring. Modellen waren klein genoeg om vanaf nul te trainen op domeindata, en de infrastructuur weerspiegelde dat.

1.1. End-to-end-pijplijnen

Teams bouwden pijplijnen voor data-extractie, training, validatie en deployment. Airflow verzorgde ETL en trainingsorchestratie. CI/CD draaide tests en pushte modellen naar productie. Modellen werden uitgerold als Docker-containers die REST-endpoints of batchjobs serveerden. Het doel van dit alles was reproduceerbaarheid en automatisering.

1.2. Experimenttracking en modelversionering

MLflow en Weights & Biases waren de standaard voor het loggen van runs, hyperparameters en metrics. Data scientists konden experimenten vergelijken en resultaten betrouwbaar reproduceren. Modelregisters gaven je versienummers, wat rollbacks eenvoudig maakte wanneer een nieuw model slechter presteerde.

1.3. Continue training & CI/CD

Pijplijnen waren ingericht op continue integratie van nieuwe data. Een typische setup retrainede elke nacht of week zodra data binnenkwam, draaide een testbatterij, en deployde automatisch als alles slaagde. Jenkins en GitLab CI/CD zorgden ervoor dat elke wijziging in data of code de pijplijn betrouwbaar triggerde.

1.4. Infrastructuur en serving

Serving had een relatief kleine footprint — een paar CPU-cores of één GPU voor real-time inference. Kubernetes en Docker waren de standaard voor schaalbare inference-services. Monitoring dekte drie dingen: performancemetrics (latency, throughput, geheugen), modelmetrics (accuracy, drift) en systeemgezondheid (uptime, error rates).

1.5. Feature stores en datamanagement

Voor finance en e-commerce waren engineered features net zo belangrijk als het model. Feature stores gaven je een centrale plek om die te beheren en hielden training en serving consistent. Gestructureerde data en feature engineering waren het zwaartepunt. Ongestructureerde data — tekst, afbeeldingen — werden apart afgehandeld, buiten deze stores om.

Deze setup werkte prima totdat modellen veel groter begonnen te worden.

2. De paradigmawisseling: opkomst van grootschalige foundation models

Rond 2018–2020 veranderde het beeld snel. Onderzoekers begonnen foundation models uit te brengen — zeer grote modellen die vooraf waren getraind op brede corpora en aangepast konden worden aan veel taken.

De ontwikkeling ging snel:

• 2018–2019: BERT en GPT-2 maakten transfer learning op schaal geloofwaardig.
• 2020–2021: GPT-3 en PaLM lieten zien wat pure schaal kon doen.
• 2021–2023: Beeldmodellen zoals DALL-E en Stable Diffusion brachten generatieve AI naar de mainstream.
• 2023–2024: Foundation models werden standaardinfrastructuur — beschikbaar op Hugging Face, AWS Bedrock, Vertex AI Model Garden en direct via API-providers.

Dit is wat foundation models daadwerkelijk veranderden aan ML-infrastructuur.

2.1. Pretrained wint van from scratch

In plaats van vanaf nul te trainen, begonnen teams met een pretrained model en fine-tuneden dat voor de taak. Trainingstijd daalde van weken naar uren. Databehoefte daalde van miljoenen voorbeelden naar duizenden. Kleinere teams konden serieuze AI-producten shippen zonder een onderzoeksorganisatie achter zich.

De grootste modellen (miljarden parameters) worden meestal as-is via API's gebruikt of gefine-tuned met lichte adapters. De functiebeschrijving verschoof: minder "hoe bouw ik een model?" en meer "hoe gebruik en integreer ik er een?"

2.2. Modelgrootte en computationele eisen

Op LLM-schaal moet de rest van de stack ook veranderen. Een model met 175B parameters is niet zomaar een grotere versie van een model met 50M — het past niet op dezelfde hardware, traint niet op dezelfde manier en serveert niet op dezelfde manier.

De pijnpunten:

• Training vraagt krachtige hardware (GPU's, TPU's) en gedistribueerde compute.
• Model parallelism splitst één model over meerdere GPU's.
• Data parallelism synchroniseert veel GPU-workers tijdens training.
• Inference heeft vaak meerdere GPU's of gespecialiseerde runtimes nodig om latency acceptabel te houden.

DeepSpeed en ZeRO (Zero Redundancy Optimizer) verschenen specifiek om training van enorme modellen haalbaar te maken. De infrastructuureisen stegen met ordes van grootte.

2.3. De opkomst van LLMOps

Deze modellen in productie draaien vereiste uitbreidingen op klassieke MLOps. Zo ontstond LLMOps — MLOps gespecialiseerd voor grote modellen, met dezelfde principes maar een ander probleemoppervlak:

• Compute: dure GPU-clusters beheren, niet CPU-pools.
• Prompt engineering: gedrag sturen via inputontwerp.
• Safety monitoring: bias, schadelijke content en datalekken detecteren.
• Performance management: latency, kwaliteit en kosten per token balanceren.

Issues die bij kleinere modellen nauwelijks opvielen — bevooroordeelde tekst, gelekte trainingsdata — werden reële risico's op LLM-schaal.

Het diagram van NVIDIA laat goed zien hoe deze specialisaties in elkaar genest zijn: klassieke MLOps aan de buitenkant, dan GenAI Ops (elk generatief model), dan LLMOps (specifiek grote taalmodellen), en dan RAGOps voor retrieval-augmented systemen. Het punt van die nesting is dat elke binnenste ring voortbouwt op de praktijken van de buitenste — ze vervangt die niet.

2.4. Foundation models as a service

De andere grote verschuiving: veel applicaties hosten hun eigen modellen niet meer, maar roepen die van iemand anders aan. OpenAI, Cohere en AI21 Labs bieden gehoste LLM's aan. Google Vertex AI levert een Model Garden met pretrained modellen. AWS Bedrock host proprietary foundation models. Hugging Face host duizenden open weights die je kunt ophalen of in de cloud kunt draaien.

Dit herschikt de architectuur. Productiepijplijnen roepen externe API's aan voor inference, waardoor je uit GPU-beheer stapt maar nieuwe kosten krijgt:

• Latency: netwerk round-trips voegen overhead toe.
• Cost: pay-per-token-prijzen betekenen dat gebruikspieken direct op de rekening terechtkomen.
• Data privacy: alles wat je naar een vendor stuurt, verlaat je perimeter.
• Vendor lock-in: API-gedrag, pricing en beleid liggen niet onder jouw controle.

Voor de meeste teams werkt die trade-off. Je eigen LLM-servingstack beheren is een serieuze engineeringinvestering, en niet altijd eentje die je wilt doen.

3. Nieuwe vereisten en mogelijkheden in moderne ML-infrastructuur

Moderne ML-infrastructuur moet dingen ondersteunen die een paar jaar geleden niche of niet-bestaand waren. De meest voorkomende zijn:

3.1. Gedistribueerde training en model parallelism

Een model met een miljard parameters trainen ligt buiten de capaciteit van één machine. Moderne infrastructuur orkestreert training over veel nodes:

Twee hoofdverdelingen zijn belangrijk:

• Model parallelism: split de lagen van het model over GPU's (elke GPU voert een deel van de forward pass uit).
• Data parallelism: repliceer het model over GPU's en split de trainingsdata, synchroniseer daarna de gradients.

PyTorch Lightning en Horovod ondersteunen algemene gedistribueerde training. NVIDIA's Megatron-LM is de go-to voor enorme transformers. Google's JAX/TPU-stack dekt TPU-clusters af.

Een paar jaar geleden trainden de meeste teams op één server. Nu starten ML-platforms jobs op GPU-clusters, beheren faults en aggregeren gradients van tientallen of honderden workers zonder dat de engineer daarover hoeft na te denken.

3.2. Efficiënte fine-tuningtechnieken

Zelfs fine-tuning van een model met meerdere miljarden parameters kan duur zijn. Parameter-efficiënte methoden bestaan precies om die reden:

• LoRA (Low-Rank Adaptation): train een kleine set adapterparameters; de basisgewichten blijven bevroren. Grote daling in compute en geheugen.
• Prompt tuning: optimaliseer alleen de prompt embeddings; het model zelf blijft bevroren.
• Adapter modules: voeg kleine trainbare lagen in tussen bevroren lagen.

LoRA configureren met peft:

from peft import LoraConfig, get_peft_model

# Configure LoRA
peft_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

# Apply to base model
model = get_peft_model(base_model, peft_config)
model.print_trainable_parameters()

Infrastructuur moet deze meerstapsworkflow ondersteunen: haal een basismodel uit een hub, pas fine-tuned weight deltas toe, deploy het gecombineerde geheel. Traditionele pijplijnen moesten evolueren om deze customizestap aan te kunnen.

3.3. Prompt engineering & management

Het nieuwe artefact in moderne ML-pijplijnen is de prompt. Bij LLM's stuurt de prompt een groot deel van wat het model doet — veel meer dan feature vectors ooit deden in klassieke ML.

Dat heeft praktische gevolgen. Teams onderhouden nu promptbibliotheken, versioneren die als code, doen A/B-tests met varianten, en slaan promptversies naast modelversies op in het register. Dit is echt anders dan klassieke ML, waar inputs gewoon feature vectors waren. Frameworks zoals LangChain behandelen promptoptimalisatie als een first-class feature.

Een eenvoudige evolutie ziet er zo uit:

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}"

Elke versie produceert andere resultaten. Prompts tracken en testen wordt uiteindelijk net zo belangrijk als modelgewichten tracken.

3.4. Retrieval-Augmented Generation (RAG)

Foundation models hebben een vaste knowledge cutoff en een eindig context window. Om responses actueel en grounded te houden, is Retrieval-Augmented Generation (RAG) standaardpraktijk geworden.

In plaats van een model voortdurend opnieuw te trainen op nieuwe data — wat traag en duur is — haalt RAG relevante documenten op tijdens query time en voegt die toe aan de prompt als context.

Een vereenvoudigde RAG-chain in LangChain:

from langchain.vectorstores import Pinecone
from langchain.llms import OpenAI
from langchain.chains import RetrievalQA

# 1. Load the vector database
vector_db = Pinecone.from_existing_index("my-index", embeddings)

# 2. Initialize the LLM
llm = OpenAI(temperature=0)

# 3. Create the RAG chain
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vector_db.as_retriever()
)

# 4. Ask a question
response = qa_chain.run("How does LLMOps differ from MLOps?")

De nieuwe infrastructuuronderdelen:

• Vectordatabases (Pinecone, Weaviate, FAISS, Milvus) voor snelle similarity search over embeddings.
• Embedding models om documenten en queries om te zetten in vectors.
• Index management om embeddings synchroon te houden met de source of truth.

Vectordatabases hebben de rol die traditionele feature stores speelden grotendeels overgenomen. Ongestructureerde data en semantische zoekopdrachten zijn nu waar de actie zit, niet handmatige feature engineering.

3.5. Datastreaming en real-time datafeeds

Moderne applicaties — vooral LLM-gedreven assistenten — nemen continu data op: chatgesprekken, sensordata, event streams. Die data moet modelkennis bijwerken (via RAG) of live responses triggeren.

Klassieke MLOps was batch-georiënteerd (dagelijkse of wekelijkse retraining). Moderne LLMOps is meestal stream-georiënteerd: Kafka en event-streamingplatformen, real-time databases (Redis, DynamoDB), online feature stores met continue updates, en streaming-embeddingpijplijnen die vectorindexen vers houden.

De grens tussen data engineering en MLOps is vervaagd. Datapijplijnen voeden inference nu direct, niet alleen training.

3.6. Schaalbare en gespecialiseerde servinginfrastructuur

Een enorm model serveren is op zichzelf al een engineeringproject. Drie capabilities zijn het belangrijkst.

High-throughput, low-latency serving. Interactieve applicaties hebben snelle responses nodig. Dat betekent GPU/TPU-acceleratie, modelquantisatie om weights te comprimeren en inference te versnellen, GPU-batching om meerdere requests parallel te serveren, en geoptimaliseerde engines zoals NVIDIA's TensorRT, Triton Inference Server of DeepSpeed-Inference.

Serverless en elastisch schalen. Platformen zoals Modal positioneren zichzelf als "AWS Lambda but with GPU support" — jij brengt code mee, zij regelen infrastructuur en scaling. Je betaalt niet voor idle servers, compute start on demand op, schaalt naar nul als er niets gebeurt, en groeit mee onder load. De keerzijde is cold-start-latency, statelessness en minder controle over de runtime. Het past goed bij onregelmatige workloads waar een warm GPU-cluster aanhouden geen zin heeft.

Gedistribueerde model serving. Voor modellen die te groot zijn voor één GPU, wordt inference zelf gedistribueerd. Het model wordt over machines geshard, die elk een deel van de forward pass afhandelen. Een model met 175B parameters on-prem serveren betekent in de praktijk meerdere samenwerkende GPU's. Moderne infrastructuur moet gedistribueerde inference-replica's kunnen starten en requests naar de juiste shard routeren.

3.7. Monitoring, observability en guardrails

Grote modellen kunnen foutieve of onveilige outputs produceren op manieren die kleine modellen niet konden. Monitoring heeft nu drie lagen.

Performance en betrouwbaarheid. De basis geldt nog steeds: latency, throughput, geheugen, GPU-utilization, kosten. Autoscaling is belangrijker omdat GPU-minuten duur zijn — val terug op een kleiner model onder load als het grote model de wachtrij niet waard is.

Outputkwaliteit en veiligheid. Nu monitor je wat het model zegt, niet alleen of het antwoordde. Content filtering voor hate speech, PII en schadelijke content. Moderation API's (die van OpenAI of je eigen). Continue bias-evaluatie. Guardrails die adversarial inputs onderscheppen en outputs binnen scope houden. Geen van deze dingen is optioneel in productie-LLMOps.

Feedbackloops. Continue verbetering omvat nu ook mensen. Verzamel interacties (likes, correcties, ratings), gebruik die om te fine-tunen of prompts aan te passen, en voer voor high-stakes-systemen RLHF (Reinforcement Learning from Human Feedback) uit om voorkeuren in het model te coderen. De infrastructuur moet deze feedbackdata veilig kunnen vastleggen en beheren.

4. Evoluerende systeemarchitectuur en design patterns

Dus met al deze nieuwe vereisten: hoe worden ML-systemen vandaag eigenlijk gebouwd? Een paar patronen blijven terugkomen.

4.1. Modulaire pijplijnen & orchestratie

Klassieke tools (Kubeflow Pipelines, Apache Airflow) bestaan nog steeds voor fine-tuningworkflows, batch scoring en periodieke retraining. Nieuwere tools — Metaflow, Flyte, ZenML — bieden Pythonic workflows die direct aansluiten op ML-libraries. Voor low-latency inference vervangt applicatiecode vaak volledig een zware workflow-engine.

De praktische verandering: engineers hoeven hun development environment niet meer te verlaten om het pad van data naar deployment te beheren.

4.2. Modelhubs en registers

Modelmanagement is verschoven naar gecentraliseerde hubs. Hugging Face Hub host duizenden modellen, datasets en scripts — een one-stop shop met plug-and-play-architectuur (modellen ophalen bij startup). Interne registers zoals MLflow en SageMaker Model Registry beheren maatwerkmodellen, vaak gecombineerd met externe foundation models.

De verschuiving: in plaats van alles in-house te bouwen, plannen engineers hoe ze third-party modellen kunnen fine-tunen en aanpassen. Dat is een ander mentaal model, en een veel sneller.

4.3. Feature stores vs. vectordatabases

De datalaag veranderde van vorm:

Traditionele feature stores verwerkten gestructureerde data met handmatige feature engineering. Moderne vectordatabases (Pinecone, Weaviate, Chroma, Milvus) verwerken hoog-dimensionale embeddings, snelle similarity search, semantische deduplicatie en RAG.

In echte systemen zie je beide: een vector DB voor ongestructureerde semantische lookup en een data warehouse voor gestructureerde analytics. Ze zijn geen substituten.

4.4. Geünificeerde platformen (end-to-end)

De complexiteit van moderne ML duwde teams richting end-to-end-platformen die de infrastructuurlaag abstraheren.

De grote cloudplatformen hebben daarop ingezet:

• Google Vertex AI: auto-distributed training op TPU-pods, Model Garden met LLM's, one-click deployment.
• AWS SageMaker: gedistribueerde training, model parallelism, plus Bedrock voor gehoste foundation models.
• Azure ML: geïntegreerde training, deployment en monitoring.

Deze bieden managed services zoals "fine-tune dit model met 20B parameters op jouw data" of "embed en indexeer je tekst voor retrieval." Open-source- en startuptooling vult dat daarnaast aan: MosaicML (nu Databricks) voor efficiënte training en deployment van grote modellen, Argilla en Label Studio voor datalabeling en het maken van promptdatasets, ClearML en MLflow voor experimenttracking gekoppeld aan pijplijnuitvoering.

4.5. Inference gateways en API's

Zodra je modellen van meerdere groottes hebt, heb je een manier nodig om requests intelligent te routeren. Dat is een inference gateway:

Handig voor routing op basis van latency-eisen, verschillende modellen serveren aan verschillende abonnementsniveaus, A/B-testen van nieuwe modellen op een deel van het verkeer, en terugvallen op kleinere modellen bij hoge load. De gateway koppelt de client-facing API los van de modelimplementatie, wat wissels en experimenten veel minder verstorend maakt.

4.6. Agentische systemen

Het nieuwste patroon is AI-agents — systemen die sequenties van acties dynamisch kiezen in plaats van een vaste chain uit te voeren. Een agent kan externe tools aanroepen (rekenmachines, zoekmachines, databases), zijn workflow tijdens runtime bepalen op basis van context, en verschillende modellen inzetten voor verschillende subtaken.

Frameworks zoals de agentmodus van LangChain, function calling van OpenAI en systemen in AutoGPT-stijl maken dit praktisch. De operationele praktijken die daarbij horen (soms "AgentOps" genoemd) zijn niet optioneel: monitoring om ongewenste acties te detecteren, gedetailleerde logging om beslispaden te traceren, en guardrails om te beperken wat de agent mag doen.

Agentische systemen zijn nog niet breed in productie, maar een groot deel van de LLMOps-frontlinie ligt daar.

5. Aan de slag met LLMOps

Als je hier nieuw in bent, is het LLMOps-ecosysteem veel om in je op te nemen. Dit is het pad dat ik zou aanraden:

1. Speel met API's. Begin met OpenAI of Anthropic om gevoel te krijgen voor prompt engineering.
2. Bouw een RAG-app. Gebruik LangChain of LlamaIndex om een "Chat with your PDF"-demo te shippen. Je raakt onderweg vectordatabases en retrieval aan.
3. Probeer fine-tuning. Gebruik Hugging Face om een klein model (Llama-3-8B of Mistral-7B) te fine-tunen op een custom dataset in Google Colab.
4. Deploy. Draai vLLM of Ollama eerst lokaal, en verplaats het daarna naar een cloudprovider.

6. Conclusie: van MLOps naar LLMOps en verder

De fundamenten van MLOps — automatisering, reproduceerbaarheid, betrouwbare deployment — blijven gelden. Wat veranderde is de schaal (miljarden parameters), de aanpak (foundation models aanpassen in plaats van vanaf nul trainen), de datalaag (vectordatabases die de vloer delen met feature stores), en het monitoringoppervlak (content safety, niet alleen latency). LLMOps kwam voort uit die veranderingen. De volgende golf — AgentOps en RAGOps — doet hetzelfde, één laag hoger.