Pexon Consulting | 12 Min. Lesezeit | 17.04.2026
TL;DR
DSPy Production bedeutet: Prompts als typisierte Signatures, Optimizer statt Handtuning, MLflow statt Copy-Paste. Stanfords Framework ersetzt manuelles Prompt-Engineering durch kompilierte Pipelines mit messbarer Metrik. Pexon Consulting, 80 Mitarbeiter in Deutschland, deployed DSPy-Services auf Azure AI Foundry und Ollama. JetBlue berichtet mit DSPy zweifach schnellere Deployments als mit LangChain — auf harten Benchmarks legen GPT-3.5-Programme um 25%, Llama-2-13b um 65% zu.
Warum scheitert der Weg vom Notebook zum Service bei KI-Teams reihenweise?
Der häufigste Satz in Discovery-Workshops bei Neukunden: „Der Prototyp funktioniert, aber wir kriegen das nicht stabil in Produktion.“ Was folgt, ist fast immer das gleiche Bild. Ein Jupyter-Notebook mit f-String-Prompts, Copy-Paste zwischen OpenAI und Anthropic, ein Excel-Sheet mit „funktioniert gut/schlecht“-Einschätzungen. Keine Versionierung der Prompts, keine Metrik, kein Regressions-Test.
Laut McKinsey State of AI 2025 messen nur 39% der Unternehmen überhaupt einen EBIT-Effekt aus ihren GenAI-Initiativen — und davon typischerweise unter 5% des EBIT. Die Ursache ist selten die Model-Qualität. Sie liegt in der Übergabe: Zwischen „läuft im Notebook“ und „läuft in einer FastAPI hinter einem Load Balancer mit Azure Monitor“ liegen sechs Monate Engineering-Arbeit, die niemand eingeplant hat.
DSPy kürzt diesen Weg ab. Nicht, weil es magisch Code produziert — sondern weil es Prompts als Code behandelt.
Was DSPy tatsächlich macht
DSPy ist Stanfords Framework für — so das Original-Paper — „Programming, not Prompting“ von Language Models. Das Projekt wurde von Omar Khattab (Co-Autor von ColBERT) gestartet, ist aktuell bei über 33.600 GitHub-Stars und Version 3.1.3 (Februar 2026). Monatlich 160.000 PyPI-Downloads. In Produktion bei JetBlue, Databricks, Walmart, Moody’s, Sephora, Replit.
Drei Bausteine, mit denen Sie arbeiten:
import dspy
# 1. Signature — der Typed Contract zwischen Code und LLM
class ExtractInvoice(dspy.Signature):
"""Extrahiere Rechnungsdaten aus Freitext."""
text: str = dspy.InputField()
invoice_number: str = dspy.OutputField()
total_eur: float = dspy.OutputField()
due_date: str = dspy.OutputField(desc="ISO-8601 Format")
# 2. Module — die Strategie (direkt, mit Reasoning, mit Tools, mit Refine)
extract = dspy.ChainOfThought(ExtractInvoice)
# 3. LM — austauschbar zwischen Providern
dspy.configure(lm=dspy.LM("azure/gpt-4o", api_base=..., api_version="2025-02-01"))
result = extract(text="Rechnung R-2026-0815 über 4.250 EUR, fällig 15.05.2026.")
# result.invoice_number, result.total_eur — typisierte FelderStatt einen Prompt zu formulieren, beschreibt die Signature was rein und was raus soll. Das Module entscheidet wie der Call läuft (direkt mit Predict, mit Chain-of-Thought-Reasoning, mit Tool-Aufrufen via ReAct). Der Prompt wird daraus generiert — und kann, das ist der eigentliche Hebel, von einem Optimizer verbessert werden.
Der Optimizer — warum DSPy in Benchmarks dominiert
Das DSPy-Paper (ICLR 2024) zeigt, was Optimizer leisten: GSM8K-Mathematik-Accuracy mit GPT-3.5 springt von 33% auf 82%. HotPotQA Multi-Hop-Q&A von 32% auf 46%. Llama-2-13b verbessert sich um bis zu 65% gegenüber Few-Shot-Prompting.
Diese Zahlen kommen nicht aus besseren Modellen, sondern aus besseren Prompts — automatisch generiert.
from dspy.teleprompt import MIPROv2
# Eine Metrik — ohne die gibt es keine Optimierung
def answer_exact_match(example, pred, trace=None):
return example.answer.strip().lower() == pred.answer.strip().lower()
optimizer = MIPROv2(metric=answer_exact_match, auto="medium")
optimized_extract = optimizer.compile(
extract,
trainset=train_examples, # 30-200 gelabelte Beispiele reichen
valset=val_examples,
)
# Das Ergebnis als versionierbares Artifact persistieren
optimized_extract.save("invoice_extract_v1.3.json")Was hier passiert: MIPROv2 probiert in einem Bayesian-Search-Loop verschiedene Instructions und Few-Shot-Examples und misst gegen die Metrik. Der beste Lauf gewinnt. Der kompilierte Zustand — Prompts plus Demonstrationen — landet in einer JSON-Datei. Damit ist die Prompt-Version plötzlich genau das, was Software-Engineers erwarten: ein Artifact mit Hash, das man deployen, zurückrollen und in Git-Diffs sehen kann.
In DSPy 3.0 kam zusätzlich GEPA dazu — ein Genetic-Pareto-Optimizer, der kürzere Prompts bei gleicher oder besserer Qualität findet. Für Teams mit knappem Token-Budget ist das relevanter als es klingt. Im RAG-Framework-Benchmark 2026 (Iternal.ai) liegt DSPy bei 3,53ms Overhead und 2,03k Token pro Query — LangChain bei 10ms und 2,40k Token.
Der Produktions-Sprung: Was kaputt geht, wenn das Notebook in einen Container wandert
Wir haben in den letzten 18 Monaten über zehn DSPy-Services in Produktion gebracht. Die Bugs, die in der Übergabe auftreten, sind bemerkenswert wiederholbar:
State verschwindet im Container-Neustart. Das Optimizer-Result lebt im Notebook-Kernel. In Produktion muss es in einen versionierten Blob-Store. Unsere Empfehlung: Optimizer-Output als JSON ins Container-Image backen oder beim Startup aus Azure Blob Storage laden. Kein Re-Compile zur Laufzeit — das kostet Tokens und ist nicht reproduzierbar.
Async-Throughput bricht unter Last ein. dspy.asyncify(program) mit async_max_workers=4 ist der richtige Default für CPU-gebundene Nachbearbeitung. Bei reinen LLM-Calls reicht async_max_workers=8-16. Messen, nicht raten — wir haben in einem Projekt 3× Durchsatz durch die richtige Einstellung gewonnen.
Tracing ist ohne MLflow unsichtbar. Ein ReAct-Modul macht innerhalb einer Anfrage mehrere LM-Calls. Ohne OpenTelemetry-Tracing sieht das Monitoring eine Anfrage — in Wirklichkeit sind es sieben. mlflow.dspy.autolog() ist ein Einzeiler, der das komplette Tracing-Setup aktiviert. Azure ML Workspaces unterstützen das nativ.
Optimizer-Runs fressen das Budget. MIPROv2 mit num_trials=30 auf einem 200-Beispiel-Validation-Set gegen GPT-4o kostet schnell 200-500 EUR pro Run. Bei uns ist das fester Teil der CI-Kosten-Grenzen — jeder Optimizer-Run wird als separater Azure-DevOps-Pipeline-Schritt mit Budget-Cap versehen.
Der Deployment-Stack, den wir bei Kunden aufsetzen
# service.py
from contextlib import asynccontextmanager
from fastapi import FastAPI
import dspy, mlflow
mlflow.dspy.autolog() # Tracing → Azure ML
dspy.configure(
lm=dspy.LM("azure/gpt-4o", api_base=AZURE_ENDPOINT,
api_version="2025-02-01", api_key=AZURE_KEY),
async_max_workers=8,
)
@asynccontextmanager
async def lifespan(app: FastAPI):
# Kompilierten Optimizer-State aus Blob laden (nicht re-compilen!)
app.state.extract = dspy.ChainOfThought(ExtractInvoice)
app.state.extract.load("models/invoice_extract_v1.3.json")
yield
app = FastAPI(lifespan=lifespan)
@app.post("/invoices/extract")
async def extract_invoice(payload: dict):
prog = dspy.asyncify(app.state.extract)
result = await prog(text=payload["text"])
return {"invoice_number": result.invoice_number,
"total_eur": result.total_eur,
"due_date": result.due_date}Das ist die Blaupause, die wir für Enterprise-Deployments verwenden. Ergänzt um: Redis statt On-Disk-LM-Cache, Azure-OpenAI-Rate-Limit-Handling via DSPy’s eingebaute Retries, und Azure Monitor Alerts auf die MLflow-Traces.
Wer vollständig On-Prem bleiben muss — Versicherungen, Banken, Behörden — tauscht azure/gpt-4o gegen openai/llama-3.3-70b mit api_base='http://vllm:8000/v1'. DSPy ist infrastruktur-agnostisch. Der einzige Code-Change ist die LM-Konfiguration.
JetBlue als Blaupause
Die Fluggesellschaft hat ihren RAG-Chatbot und eine Customer-Feedback-Klassifikation mit DSPy auf Databricks Mosaic AI deployed. Ergebnis laut Databricks-Blog: zweifach schnellere Deployment-Zeit gegenüber der vorherigen LangChain-Architektur. Vor allem: „manuelles Prompt-Engineering eliminiert“ — ein LLM-as-a-Judge optimiert die Prompts gegen eine gelabelte Customer-Feedback-Kollektion. Das passt exakt auf deutschen Versicherungs- und Maschinenbau-Kontext, wo Fach-SME-Zeit die knappste Ressource im Projekt ist.
Unsere Empfehlung an Kunden: Der Wert von DSPy zeigt sich ab 500 gelabelten Beispielen. Darunter reicht auch ein gut gemachter manueller Prompt. Darüber — und spätestens ab 2.000 Beispielen — ist der Optimizer jede Stunde Setup-Zeit wert.
DSGVO-Pfad für DACH-Kunden
DSPy selbst ist ein Python-Paket ohne Telemetrie. Die Compliance hängt, wie bei PydanticAI, am LLM-Provider und am Observability-Stack.
Azure OpenAI mit Data Zone Standard (Germany West Central oder Sweden Central) ist der Standard-Pfad für 80% unserer Kunden. Wichtig: Der Azure-Region-Parameter in der DSPy-LM-Konfiguration muss zur Data Zone passen, sonst leakt der Call in US-Regionen. Wir haben ein CI-Linting, das das prüft.
MLflow auf Azure ML Workspace hält Traces in der EU. Wer Logfire oder Phoenix bevorzugt: beide lassen sich mit self-hosted OpenTelemetry-Collectoren DSGVO-konform betreiben.
Optimizer-Training mit Produktionsdaten ist der subtile Punkt. Wenn der Trainingsdatensatz personenbezogene Daten enthält, muss der Optimizer-Run in der gleichen Region laufen wie die Produktion. Wir dokumentieren das in jedem DSPy-Kundenprojekt als separaten DSGVO-Trittstein.
Typische Projekt-Größe und Timeline
In den letzten 14 Monaten haben wir DSPy-Services in drei Typ-Größen deployed:
Die konservative Einstiegs-Variante — der Optimierungs-Pilot — ist das, was wir Teams empfehlen, die DSPy prüfen wollen ohne Stack-Commitment. Wir nehmen einen produktiv laufenden Prompt, definieren eine Metrik, lassen den Optimizer laufen und berichten den Accuracy-Gain. Typischerweise 10-40% absoluter Uplift.
Wann wir aktuell von DSPy abraten
DSPy ist nicht die richtige Antwort für jeden KI-Service. Drei Fälle, in denen wir andere Stacks empfehlen:
- Single-Shot Classification ohne Optimierungs-Potenzial. Wenn Sie genau einen einfachen Call brauchen (z.B. Sentiment), ist PydanticAI mit typisiertem Output schlanker.
- Teams ohne Evaluations-Disziplin. DSPy zwingt zu einer Metrik. Ohne gelabelten Validation-Datensatz ist der Optimizer nutzlos — und das Team frustriert. Wir empfehlen in dem Fall zuerst drei Wochen Eval-Setup.
- Reine Orchestration-Szenarien. Wenn der Kern des Service das Koordinieren von APIs und MCP-Servern ist, nicht das LLM-Reasoning, dann passt PydanticAI oder sogar das nackte OpenAI-SDK besser.
Häufig gestellte Fragen
Warum ist ein DSPy-Notebook nicht bereits ein Service?
Weil das Notebook keinen persistenten State hat, kein Async-Handling, kein Tracing, keine Versionierung und keine Kosten-Grenzen. Der kompilierte Optimizer-Output muss als JSON persistiert, versioniert und im Container-Startup geladen werden. Tracing braucht MLflow oder Logfire. Async-Throughput braucht dspy.asyncify mit richtiger Worker-Zahl. Das sind keine Edge Cases — das ist der Grundaufbau jedes produktiven DSPy-Service.
Wie deploye ich DSPy DSGVO-konform in Deutschland?
Azure OpenAI mit Data Zone Standard in Germany West Central oder Sweden Central, LM-Konfiguration in DSPy auf den Azure-Endpoint pointen, MLflow auf Azure ML Workspace. Für vollständige On-Prem: vLLM oder Ollama auf eigenen GPU-Nodes, DSPy-LM auf openai/ mit api_base=http://vllm.internal. Kein Code-Change, nur Konfiguration.
Was kostet ein MIPROv2-Optimizer-Run?
Grob: num_trials × validation_size × LM-Call-Kosten. Typischer Run mit 30 Trials, 200 Validation-Examples, GPT-4o-mini liegt bei 50-150 EUR. Gegen GPT-4o bei 300-800 EUR. Wir setzen in jedem Kundenprojekt Azure-OpenAI-Budget-Limits pro DSPy-Pipeline — das verhindert, dass ein unbedachter Optimizer-Run die Monatskosten sprengt.
Kann ich DSPy mit self-hosted LLMs kombinieren?
Ja, das ist einer der häufigsten DACH-Anwendungsfälle. dspy.LM("openai/meta-llama-3.3-70b", api_base="http://vllm:8000/v1") mit einem vLLM-Server auf Azure Kubernetes oder On-Prem-GPUs funktioniert direkt. Wir setzen diese Kombination bei zwei Versicherungs-Kunden und einem Maschinenbauer aktiv ein — für die DSGVO-Abnahme war das der entscheidende Punkt.
DSPy oder LangChain für RAG?
Für neue RAG-Projekte empfehlen wir DSPy, wenn eine Evaluations-Pipeline vorhanden oder geplant ist. DSPy gibt messbar bessere Antworten (siehe Stanford-Benchmarks und JetBlue-Case) und ist weniger anfällig für Embedding-Drift und Chunk-Overlap-Probleme. LangChain bleibt die richtige Wahl, wenn Sie das Ökosystem der Vektor-DB-Konnektoren intensiv nutzen oder ein Team haben, das schon tief drinsteckt. Den direkten Vergleich haben wir in RAG Pipelines mit DSPy statt LangChain ausgearbeitet.
Nächster Schritt
Wenn Sie einen produktiv laufenden KI-Prompt haben, der zu oft falsche Antworten gibt, starten wir typischerweise mit einem Optimizer-Pilot: Drei bis fünf Wochen, messbares Accuracy-Delta, Empfehlung für oder gegen den Stack-Wechsel.
Verwandte Themen
→RAG-Qualität: 5 Stufen von Prototyp bis Produktion
→PydanticAI FastAPI Production-Ready KI-Services
→Private KI Infrastruktur auf Azure
