RAG vs Fine-Tuning vs Long-Context: Der Kosten-Crossover 2026

Der 2024er-Default war "nimm RAG für alles". 2026 hat sich die Mathematik verschoben. LLM-API-Preise sind in 24 Monaten grob 10x am günstigen Ende gefallen. Kontextfenster trafen 1M bis 2M Tokens. Fine-Tuning reifte und wurde günstiger. Die Architekturentscheidung ist nicht mehr "RAG ja/nein", sondern ein Drei-Wege-Crossover. Dieser Post legt dar, wo jede Option Stand Mitte 2026 gewinnt, mit einem konkreten Kostenbeispiel, in das du deine Zahlen einsetzen kannst.

Engineering-Perspektive, kein Vendor-Pitch. Referenzpunkte aus Wavects KI-Arbeit, darunter PromptID, Twinsoft AI und Quivr.

Was hat sich zwischen 2024 und 2026 geändert?

Drei strukturelle Verschiebungen:

• Token-Preise kollabierten. Mid-Tier-Modell-Input-Preise fielen von grob EUR 2,50 pro 1M Input-Tokens (2024) auf unter EUR 0,30 auf wettbewerbsfähigen Tiers 2026. Output-Token-Preise folgten.
• Kontextfenster wuchsen. 1M Input-Kontext ist jetzt Mid-Tier-Standard, mit 2M verfügbar. Prompt-Caching reduziert die effektiven Kosten, denselben Kontext über eine Session erneut zu lesen, um 80 bis 90 Prozent.
• Fine-Tuning reifte. LoRA-Adapter und kleine Open-Weight-Modelle im 7B-bis-30B-Bereich machten Domain-Adaption günstig. Self-Hosting auf EU-Infrastruktur aus Datenresidenz-Gründen ist jetzt für viele SaaS-Teams wirtschaftlich tragfähig.

Die Implikation. Der 2024er-Entscheidungsbaum ist falsch. Lass ihn in 2026er-Preisen neu laufen und die Crossover-Punkte haben sich verschoben.

Wann schlägt Long-Context 2026 RAG?

Long-Context gewinnt, wenn der Korpus in den Prompt passt und die Workload Ad-hoc ist:

• Korpus unter ~10 MB Text (grob 2M Tokens). Passt in einen Frontier-Modell-Prompt.
• Ad-hoc- oder Niedrigvolumen-Queries, bei denen Retrieval-Engineering-Overhead nicht amortisiert wird.
• Tasks, bei denen Cross-Dokument-Reasoning zählt und Chunking den Kontext brechen würde.
• Sessions mit hohen Prompt-Cache-Hit-Raten (Multi-Turn-Assistenten über dem gleichen Doc-Set).

Die Falle. Long-Context-Kosten skalieren linear mit der Korpusgröße bei jeder Query, sofern Caching nicht greift. Bei 100k Queries/Monat ist der Unterschied zwischen Caching und Nicht-Caching der Unterschied zwischen einem profitablen Feature und einer Margenkatastrophe.

Wann schlägt Fine-Tuning beide?

Fine-Tuning gewinnt bei drei Signaturen:

• Stil oder Persona. Das Modell soll konsistent wie deine Marke klingen oder einem präzisen Format folgen. Prompt-Engineering trifft abnehmenden Ertrag; ein Fine-Tune zementiert es.
• Domain-Idiom. Das Vokabular ist spezialisiert (Recht, Medizin, Nischen-Industrie) und das Basismodell behandelt deine Begriffe als mehrdeutig. Fine-Tuning richtet die Embeddings neu aus.
• Latenz-sensitive enge Tasks. Ein 7B-Fine-Tuned-Modell auf einer einzelnen Workload schlägt ein 70B-Modell bei Kosten und Latenz für diese Workload, oft bei vergleichbarer Qualität.

Die Falle. Fine-Tuning backt die Daten ein. Wenn dein Wissen täglich updated, ist ein Fine-Tune bis Mittwoch veraltet. Kombiniere mit RAG für die wechselnden Teile.

Wann gewinnt RAG noch?

RAG bleibt der richtige Ruf, wenn:

• Große oder aktualisierende Korpora. Über ~10 MB relevantem Text oder bei täglichem/wöchentlichem Refresh begünstigt die Mathematik Retrieval.
• Zitations-Anforderungen. Compliance, Recht, Medizin oder jedes Produkt, bei dem Nutzer die Quelle für die Antwort sehen müssen.
• Multi-Tenant-Datenisolation. Jeder Kunde hat seinen eigenen Korpus, und du darfst nicht querbestäuben. RAG separiert sauber pro Tenant; Long-Context und Fine-Tuning nicht.
• Sparse-Retrieval-Muster. Die meisten Queries berühren einen kleinen Bruchteil des Korpus. Den ganzen Korpus in den Kontext zu laden verschwendet Tokens.

Wie sieht der Kosten-pro-Query-Crossover bei gängigen Korpusgrößen aus?

Indikative Kosten pro Query für ein EU-basiertes Deployment zu Mitte-2026-Token-Preisen, unter Annahme repräsentativer Mid-Tier-Modell-Pricing (EUR 0,30 pro 1M Input, EUR 1,20 pro 1M Output) und einem 1k-Token-Output. Zahlen zur Klarheit gerundet; setze die exakte Preisgestaltung deines Providers in dein eigenes Modell ein.

Crossover-Lesart. Unter 10 MB und mit hoher Cache-Hit-Rate wird Long-Context wirtschaftlich vertretbar. Über 10 MB ist RAG die einzige Option, die ihre Kostenform hält. Die interessante Mitte ist das 1-bis-10-MB-Band, in dem der richtige Ruf mehr von den Query-Mustern als von der reinen Korpusgröße abhängt.

Wie sieht ein konkretes EU-Deployment aus?

Durchgerechnetes Beispiel. 100 MB technischer Dokumentations-Korpus, 10.000 Queries pro Monat, EU-Residenz-Anforderung, Zitation in jeder Antwort nötig:

1. Architektur. RAG mit EU-gehostetem Vector Store, EU-API-Endpoint für den LLM-Provider oder selbst gehostetes Open-Weight-Modell auf EU-Infrastruktur.
2. Kosten pro Query. Retrieval (~3k Tokens Input + 1k Output) zu Mid-Tier-2026-Preisen landet bei EUR 0,0024 pro Query. Bei 10k Queries/Monat grob EUR 24 pro Monat LLM-Kosten.
3. Plus Infra. Vector Store, Embedding-Refresh, Observability, Eval-Harness. Realistische Infra-Hülle EUR 200 bis 800 pro Monat in dieser Größenordnung.
4. Plus Build. Initiale Implementierung mit Daten-Ingestion, Eval-Harness, Zitations-UI, Monitoring landet im 4- bis 10-Wochen-Bereich aus Wavects Engagement-Historie auf ähnlichen Scopes.

Selbe Workload als Long-Context, vergiss es, sie passt nicht mal rein. Selbe Workload als Fine-Tune, du opferst Zitate und brauchst sowieso einen separaten Retrieval-Pfad für frische Daten, also endest du mit RAG plus Fine-Tune, nicht statt.

"Architekturentscheidungen tracken die Preiskurve, nicht die Hype-Kurve. Das richtige Modell 2024 ist 2026 das falsche, auch wenn sich sonst nichts ändert."

Was ist mit Hybrid-Architekturen?

In Produktion sind die saubersten Antworten meist Hybride:

• RAG plus Fine-Tune. Retrieval handhabt den wechselnden Korpus; der Fine-Tune handhabt Tone, Format und Domain-Vokabular. Das ist der Default, zu dem wir bei kundenorientierten Assistenten greifen, bei denen Brand Voice zählt.
• RAG plus Long-Context. Hole ein breiteres Candidate-Set, dann lass das Long-Context-Fenster Cross-Dokument-Reasoning machen. Nützlich für Legal-Review- und Synthese-Tasks.
• Kleines Modell plus Router. Ein kleines schnelles Modell klassifiziert die Query und routet ans richtige Backend (RAG, Fine-Tune oder ein Frontier-Modell). Schneidet Kosten in unserer Erfahrung um 3- bis 5-fach.

Was heißt das für einen EU-Gründer 2026?

Drei Operating-Regeln aus dem Feld:

1. Lass das Kostenmodell vor dem Architektur-Meeting laufen. Setz dein echtes Query-Volumen, deine echte Korpusgröße und das echte Provider-Pricing in die Tabelle oben. Die richtige Architektur fällt aus den Zahlen, nicht aus Konferenztalks.
2. Bau das Eval-Harness zuerst, unabhängig von der Architektur. Ohne Evals kannst du nicht sagen, welche Architektur tatsächlich gewinnt. Wir haben darüber im Agent-Post geschrieben, und es gilt hier doppelt.
3. Lass die Analyse alle sechs Monate neu laufen. Token-Preise und Kontextfenster bewegen sich schneller als dein Architektur-Review-Rhythmus. Der Default von 2025 wird der falsche Default 2027.