Fine-Tuning, Retrieval oder Prompt? Die Entscheidung ist wirtschaftlich

„Sollten wir fine-tunen?“ wird gestellt, als ginge es um ein Modell. Es geht um ein Budget, mit einer Form, die kein Benchmark beantwortet: was einmal bezahlt wird, was pro Frage bezahlt wird und was jedes Mal erneut bezahlt wird, wenn sich die Welt bewegt.

Die drei Routen sind auch nicht drei Wege, dasselbe zu tun, und die Anbieter sagen das klarer als die meisten Blogposts. OpenAIs eigene Tabelle dazu, wofür supervised fine-tuning am besten geeignet ist, listet vier Einsatzfälle: Klassifikation, nuancierte Übersetzung, Inhalte in einem bestimmten Format erzeugen und Fehler beim Befolgen von Anweisungen korrigieren.¹ Keiner davon lautet: „dem Modell etwas beibringen, das es nicht weiß“. Die Zusammenfassung des Nutzens lautet, dass „du kürzere prompts mit weniger Beispielen und context data verwenden kannst, was token-Kosten in großem Maßstab spart und die Latenz senken kann“ — ein Argument über die Rechnung, von dem Unternehmen, das die Funktion verkauft.

Also:

• Fine-tuning lehrt Form und Verhalten. Ton, Format, die Gestalt einer Antwort, eine Grenze, die du demonstrieren, aber nicht beschreiben kannst. Die stärkste veröffentlichte Version ist LIMAs Superficial Alignment Hypothesis: Wissen kommt aus dem Pretraining, Alignment lehrt vor allem, in welcher Subverteilung von Formaten gesprochen werden soll — weshalb dort tausend kuratierte Beispiele genügten.²
• Retrieval liefert Fakten, die sich ändern. Es ist die einzige der drei Optionen, bei der eine Änderung an deiner Dokumentation die Antwort erreicht, ohne das Modell anzufassen.
• Prompting deckt die meisten echten Fälle ab und ist die ehrliche Baseline. In-context learning ist seit Language Models are Few-Shot Learners der Standard: Die Aufgabe wird im prompt demonstriert und kein Gewicht bewegt sich.³

Zwei gemessene Papers schließen die Tür zum Fehler in der Mitte. Ovadia und Kolleginnen verglichen das Einspeisen von Wissen durch unsupervised fine-tuning mit dem Einspeisen durch Retrieval, und Retrieval gewann konsistent, auch bei Fakten, die das Basismodell schon im Pretraining gesehen hatte.⁴ Gekhman und Kolleginnen maßen den Schaden: Beispiele, die neues Wissen einführen, werden langsam gefittet, und wenn das Modell sie schließlich fitten kann, steigt seine Halluzinationsrate bei anderen Fragen.⁵ Fakten durch fine-tuning zu lehren scheitert nicht nur; es verschlechtert Antworten, auf die du gar nicht trainiert hast.

Diese Hälfte ist geklärt. Die wirtschaftliche Hälfte nicht, und sie ist der Rest des Kapitels.

Ein Fall, auf drei Arten ausgeführt: technischer Support über deine eigene Dokumentation, die sich jede Woche ändert.

Der Korpus ist echt und liegt auf dieser Festplatte: die 23 Markdown-Dokumente, die ein aktiv genutztes Software-Repository als interne Dokumentation führt — der Build-Guide, die Markenregeln, der Übersetzungsbrief, zehn Servicehandbücher, die Performance- und Sicherheitsnotizen. Gemessen mit o200k_base, dem Encoding aus Kapitel 7:

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

Dreiundvierzigtausend tokens sind eine komfortable Größe für diese Entscheidung: Sie passt in jedes moderne context window, also stehen alle drei Routen wirklich zur Verfügung. Bei zehn Millionen ist die Entscheidung schon für dich gefallen, und sie heißt Retrieval.

Jetzt die Arbeit, die das Wort „wöchentlich“ leistet. Dokumentations-Churn wird meistens behauptet; hier wird er gezählt, aus der Versionshistorie dieses Repositorys:

Die Dokumente bewegen sich etwa alle zwei Wochen. Die sichtbaren Strings für Nutzer — und danach fragt ein Supportdesk tatsächlich — bewegten sich in jeder Woche, in der es sie gab, mit etwa zwanzig Commits pro Woche. Welche Route wir auch wählen, sie muss das überleben, und „wie oft ändert sich das, worauf du trainiert hast?“ hat am Ende eine Zahl in deinem eigenen Repository statt einer Meinung.

Zwanzig realistische Supportfragen wurden zu diesem Korpus geschrieben, eine pro Thema, und jede Zahl unten wird über diese zwanzig berechnet.

Das Einfachste, das funktioniert: den gesamten Korpus in den system prompt legen, die Frage ans Ende stellen und das Modell suchen lassen.

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

Jede Zahl dort wurde gezählt, außer der letzten: 150 output tokens sind eine Annahme, gewählt innerhalb der Spanne von assistant-Turns, die Kapitel 16 abgerechnet hat. Es ist die einzige Zahl hier, die nicht ausgeführt wurde, sie wird identisch auf alle drei Routen angewandt, und der Break-even-Abschnitt zeigt genau, wie stark sich die Schlussfolgerung verschiebt, wenn du sie änderst.

Bei den Raten, die am 7. September 2026 von der Anbieterseite gelesen wurden — $1.50 pro Million input tokens, $9.00 pro Million output⁶ — sind das $0.066317 pro Frage. Du bezahlst dafür, dreiundvierzigtausend tokens erneut zu lesen, um dreizehn zu beantworten.

Die Korrektur aus Kapitel 16 greift direkt: Der Korpus ist stabil und steht am Anfang, also ist er ein perfekter Cache-Prefix, und ihn zurückzulesen kostet ein Zehntel — $0.007864 pro Frage, eine Senkung um 88 %. Die Warnung aus Kapitel 16 gilt ebenfalls, in der Form, die dieses Kapitel markiert und nicht bepreist hatte. Dieser Anbieter berechnet keinen Schreibaufschlag; er berechnet Miete. Ein expliziter Cache kostet $0.000001 pro gespeichertem token pro Stunde,⁶ also kostet es, 43.298 tokens warm zu halten,

ob jemand etwas fragt oder nicht. Das sind $189.78 über sechs Monate, für einen leeren Raum. Teile die Miete durch die Ersparnis pro Frage, und die Bedingung kommt in einer Zeile heraus: Dieses Corpus-Caching lohnt sich ab 0,74 Fragen pro Stunde — 546 pro Monat, sobald auch der wöchentliche Cache-Neuaufbau eingerechnet ist. Darunter verliert die Funktion, die du zum Sparen aktiviert hast, Geld.

Dieselbe Route, derselbe Code, ein Flag, die fünffache Rechnung. Kapitel 16 fand eine Version davon, verursacht durch einen Zeitstempel an der falschen Stelle; hier ist nichts falsch außer dem Traffic. Ein Cache ist eine Wette auf Volumen, und bei diesem Anbieter platzierst du sie stündlich.

Der Retriever aus Kapitel 19, unverändert: an Abschnittsgrenzen mit kontextuellem Header schneiden, indexieren, die vier besten Auszüge in den prompt legen. Über die zwanzig Fragen gemessen:

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

Zweiundvierzigmal weniger prompt tokens als Route eins, bei $0.002906 pro Frage. Der Index kostet $0.0070 zum Bauen bei $0.15 pro Million embedding tokens⁶ — weniger als drei Fragen — und erneut $0.0070, um ihn jedes Mal von Grund auf neu zu bauen, wenn sich die Dokumentation ändert. Den gesamten Index sechs Monate lang jede Woche neu zu bauen kostet achtzehn Cent.

An einer Sache lohnt sich der Stopp. Retrieval zerstört prompt caching. Der stabile Prefix ist jetzt die 140-token-Systemanweisung; ab token 141 unterscheidet sich der prompt bei jedem Aufruf, weil die Auszüge pro Frage gewählt werden. Und 140 tokens liegen unter jedem Cache-Minimum, das Kapitel 16 zitiert hat. Route zwei kann also überhaupt nicht gecacht werden, was schlecht klingt und es nicht ist: 1.037 tokens nicht zu cachen ist billiger als 43.298 zu cachen.

Das ist eine allgemeine Regel, die du mitnehmen solltest: Die zwei großen token-sparenden Techniken schließen sich auf demselben Inhalt gegenseitig aus, und es gewinnt diejenige, die mehr tokens entfernt. Retrieval entfernt 97,6 % davon.

Trainiere mit zweihundert Beispielen im Hausstil und stelle dann Fragen ganz ohne angehängte Dokumentation.

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

Training kostet 24.389 × 3 × $10.00 pro Million = $0.7317. Das ist der gesamte Baupreis, weniger als eine Tasse Kaffee, und genau deshalb bezahlen so viele Teams ihn, bevor sie prüfen, ob es hilft.

Jetzt die Falle, und sie ist der Grund, warum dieses Kapitel existiert. Ein fine-tuned Modell kostet im Betrieb nicht dasselbe wie sein Basismodell. Die Preisseite sagt es in einem Satz: „for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.“⁶ Nicht das Training. Die Inferenz, auf jedem token, solange das Modell lebt.

Also in eine Formel. Sei $p_i$ und $p_o$ die Basispreise für Input und Output, $m$ der tuned Multiplikator, $L_R$ die prompt-Länge der Route, die du ersetzt, $L_F$ die prompt-Länge nach fine-tuning und $O$ die Antwortlänge. Fine-tuning ist pro Frage nur dann günstiger, wenn

Der erste Term ist offensichtlich: dein neuer kurzer prompt, mit Aufschlag. Der zweite ist es nicht, und dort landet das Geld — der Zuschlag auf die Antwort, der nichts mit deinem prompt zu tun hat und den Training nicht kürzen kann. Mit den gemessenen Zahlen — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — liegt der Schwellenwert bei

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

Bei der gemessenen Antwortlänge: 492 tokens — davon 450 der Antwortzuschlag, nicht der prompt. Einen kürzeren prompt als diesen zu ersetzen ist pro Frage teurer, für immer, bei jedem Volumen; und der Schwellenwert wächst linear damit, wie viel dein assistant sagt. Ein assistant, der lange Antworten schreibt, kann sich also nie durch fine-tuning zu einem günstigeren token bringen, egal wie viel prompt er löscht.

Dieselbe Tatsache von der anderen Seite ist der Satz, den du behalten solltest. Von den $0.002088 pro Frage der fine-tuned Route sind 97,0 % die Antwort. Fine-tuning optimiert die verbleibenden drei Prozent.

Vier Zahlen beschreiben jede dieser Routen: was du einmal bezahlst, was du bezahlst, wenn sich die Dokumentation ändert, was du stündlich unabhängig von allem bezahlst und was du pro Frage bezahlst. Das erweitert computeCost aus Kapitel 16, ohne es zu verändern.

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

Das tuned Modell ist keine andere Preisliste, sondern dieselbe multipliziert:

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

Diese eine hervorgehobene Zeile ist das gesamte Argument des vorherigen Abschnitts als Code: Der Multiplikator landet auch auf output.

Sechs Monate, mit wöchentlich aktualisierter Dokumentation:

Und die Crossovers, also die vier Zahlen, die ein Budget tatsächlich braucht:

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

Lies die ersten beiden zusammen, denn sie sind der Punkt des Kapitels. Ein stationärer Korpus lässt fine-tuning sich nach hundertfünfzig Fragen amortisieren; ein Korpus, der sich wöchentlich ändert, verschiebt denselben Crossover um den Faktor siebenundzwanzig, und am Modell hat sich nichts geändert — nur daran, wie oft du erneut dafür bezahlst. Baukosten sind eine Fußnote; Wartungskosten sind die Entscheidung.

Wenn du jetzt schließt, dass ein beschäftigter Supportdesk fine-tunen sollte, stimmt die Arithmetik dir zu. Es ist trotzdem falsch, und der nächste Abschnitt erklärt warum.

Das Kostenblatt hat eine Spalte, die es nicht berechnen kann, also führt dieser Abschnitt das fine-tune aus: lokal, auf einem kleinen offenen Modell, mit einem von Hand geschriebenen Adapter statt aus einer Bibliothek gezogen. Kapitel 11 hat LoRA gebaut; hier ist es, auf q_proj und v_proj aller 24 Layer von Qwen2.5-0.5B-Instruct bei Rank 8:

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

Die zweihundert Trainingsbeispiele kommen mechanisch aus dem Korpus und reproduzieren sich daher: Die Frage ist eine Abschnittsüberschrift, die in eine Frage verwandelt wurde; die Antwort ist der eigene Text dieses Abschnitts in einem starren Hausstil — eine Zeile beginnend mit Short answer:, eine Zeile beginnend mit Source: mit dem Dateipfad. Das Format ist die Form, die gelehrt wird; der Pfad ist der Fakt. Dann zwei Zahlen über zwanzig zurückgehaltene Fragen: Kommt die Antwort im Hausstil heraus, und nennt sie die Datei, die die Frage wirklich beantwortet?

Zwei Baselines machen die Tabelle lesbar, und beide sind Kapitel 4s Beharren, nicht ein nachträglicher Einfall. Zehn der zwanzig richtigen Antworten sind dieselbe Datei, also erzielt ein Modell, das die Frage ignoriert und immer CLAUDE.md antwortet, 10/20. Und der Retriever hat seine eigene Obergrenze: Über diese zwanzig Fragen enthalten seine vier Auszüge 14-mal die richtige Datei und ranken sie 7-mal auf Platz eins, also ist 14/20 das Maximum, das irgendein Reader mit ihm erreichen könnte.

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

Die Form wurde gelernt, vollständig und schnell. Von null auf neunzehn von zwanzig, mit einem Adapter von 540.672 Parametern — 0,109 % des Modells — in fünf Minuten Training auf einem Prozessor, ohne Grafikkarte in Sicht.

Die Fakten wurden nicht gelernt. Acht von zwanzig ist nicht unterscheidbar von den zehn, die du bekommst, wenn du die Frage vollständig ignorierst, und Kapitel 4s Intervall auf zwanzig Stichproben sagt das laut. Diese Dateipfade waren dreimal in den Trainingsdaten; heraus kam die Gewohnheit, mit einer plausibel aussehenden Source:-Zeile zu enden. Auf die Frage am Anfang dieses Kapitels antwortete das fine-tuned Modell Short answer: 10.x . . . und zitierte CLAUDE.md. Die richtige Antwort, die in CLAUDE.md steht, ist 18.17.0.

Und dann brach die Form, und das ist die Zeile, die das Experiment rechtfertigt. Gib dem fine-tuned Modell tausend tokens abgerufener Auszüge — eine prompt-Form, die es nie gesehen hat, da jeder Trainings-prompt achtundzwanzig tokens lang war — und der Hausstil fällt von 19/20 auf 1/20. Auf die Frage am Anfang dieses Kapitels antwortet es 18.17.0 — korrekt und ohne irgendetwas von dem Format, für das es trainiert wurde. Fine-tuning hat also kein Format gelehrt; es hat ein Format gelehrt, bedingt auf die prompts im Trainingsset, und der erste prompt, der anders aussah, nahm das Format mit. Worauf du fine-tuned, wird zur einen Input-Verteilung, in der dein Modell gut ist, und niemand schreibt das in die Tabelle.

Eine letzte Notiz zur Metrik, direkt auf Kapitel 29 zeigend: „korrekte Quelle“ bewertet Form und Fakt zusammen, weshalb beide Retrieval-Zeilen schrecklich aussehen, obwohl beide Modelle den Fakt dieser Frage richtig hatten. Eine End-to-end-Zahl versteckte drei Dinge — einen Retriever mit 14/20 Recall, einen 0.5B-Reader und ein Zitationsformat — und zu entscheiden, was repariert werden soll, heißt, sie vor dem Messen zu trennen, nicht danach.

Jetzt die Spalte, die die Anbieter für dich ausfüllen. Ein fine-tuned Modell ist kein Vermögenswert, den du besitzt; es ist ein Mietvertrag auf das Basismodell eines anderen, mit aufgedrucktem Enddatum. Am 7. September 2026 enthielt der fine-tuning-Abschnitt der OpenAI-Preisseite diesen Hinweis vollständig:

OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months. All fine-tuned models will remain available for inference until their base models are deprecated.⁷

Die Zeitleiste ist auf den Tag datiert: 7. Mai 2026, geschlossen für Organisationen, die nie fine-tuned hatten; 2. Juli 2026, geschlossen für jene, die in sechzig Tagen keine Inferenz auf einem fine-tuned Modell ausgeführt hatten; 6. Januar 2027, überhaupt keine neuen Jobs mehr.⁸ Dieselbe Seite plant die Abschaltung der fine-tuned Modelle selbst — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — am 23. Oktober 2026, jeweils mit einem empfohlenen Ersatz-Basismodell, was die höfliche Art ist zu sagen: Trainiere es noch einmal.

Der andere Frontier-Anbieter hat dir den Mietvertrag nie verkauft. Anthropics Dokumentationsindex listet 699 Seiten und keine einzige handelt von fine-tuning; die Modellanpassungsabschnitte der Bedrock-Preisseite decken Amazon Nova, Amazon Titan, Cohere, Meta und OpenAI-Open-Weight-Modelle ab, aber kein Claude.⁹¹⁰ Wenn deine Architektur von einem fine-tune abhängt, ist eine der drei Frontier-Familien für dich bei jedem Budget schlicht nicht verfügbar.

Self-hosting ersetzt den Mietvertrag auf ein Modell durch einen Mietvertrag auf eine Maschine, und AWS rechnet das auf der eigenen Seite vor: eine Model Unit provisionierter Durchsatz für ein angepasstes Modell, ein Monat Verpflichtung, lautet „1 model unit × $21.18 × 24 hours × 31 days = $15,757.92“ pro Monat.¹⁰ Die Hardware direkt zu mieten ist billiger und nicht kostenlos — $3.99 pro GPU-Stunde on demand für eine H100, $1.99 preemptible¹¹ — ungefähr $2,900 pro Monat für eine Karte, die laufen muss, ob jemand etwas fragt oder nicht. Die gesamte Retrieval-Route bei zehntausend Fragen pro Monat kostet $174.52 für sechs Monate.

Hier verdient LoRA seinen Platz, als Budgetargument statt als technisches. Auf demselben Modell gemessen hat ein Rank-16-Adapter über attention und Feed-forward-Layer 8.798.208 Parameter — 1,781 % des Modells, 17,6 MB in bfloat16 — gegenüber 0,988 GB Basisgewichten, und sein Optimizer- und gradient-Zustand beträgt 140,77 MB, wo full fine-tuning 7,90 GB braucht, ein Faktor von 56. Die Konsequenz ist nicht billigeres Training, sondern dass ein geladenes Basismodell viele Adapter bedienen kann, was die einzige Art ist, die Fixkosten einer GPU durch irgendetwas zu teilen. Managed Training spiegelt das wider: $0.48 pro Million tokens low-rank bis 16B gegenüber $0.54 full, mit einem Minimum von $4.00 pro Job.¹¹ Diese Untergrenze ist das Detail. Bei 24.389 tokens über drei Epochen wird jedes Retraining auf diesem Korpus mit $4.00 berechnet statt mit den errechneten $0.04 — $104 Mindestbeträge über sechsundzwanzig wöchentliche Läufe, für einundneunzig Cent Arithmetik.

Zwei weitere Spalten, die nur auf der Rechnung erscheinen.

Data residency kostet etwa zehn Prozent, und zwei Anbieter stimmen bei der Zahl überein. OpenAI berechnet „a 10 % uplift“ auf Data-residency-Endpunkte für Modelle, die am oder nach dem 5. März 2026 veröffentlicht wurden;⁷ Vertex bepreist seine nicht globalen Endpunkte mit $1.65 statt $1.50, dieselben zehn Prozent.⁶ Stelle das den fünfzig Prozent gegenüber, die ein tuned Endpunkt kostet, und die Folklore kehrt sich um: Residency ist billig und fine-tuning ist es nicht — und fine-tuning ist ohnehin nicht die private Option, denn der Korpus erreicht den Anbieter in jedem Fall, einmal zur Trainingszeit statt einmal pro Aufruf.

Der ausdrücklichste Preis, der je auf deine Daten geklebt wurde, steht auf derselben Seite, die ein fine-tuned Modell zweimal listet: mit aktivierter Datenfreigabe kostet Inferenz genau die Hälfte — $2.00 statt $4.00 Input, $8.00 statt $16.00 Output.⁷ Dem Anbieter zu erlauben, zu behalten, was du gesendet hast, ist einen Rabatt von 50 % wert, was dir sagt, was es ihm wert ist.

Distillation — ein eigenes kleines Modell auf den Antworten eines großen zu trainieren — wird meist als Ausweg aus beidem angeboten. Bepreist ist sie keiner, denn der Teacher ist das System, das du ersetzen wolltest: Zweihundert Trainingsbeispiele zu erzeugen, indem du der Retrieval-Route zweihundert Fragen stellst, kostet 200 × $0.002906 = $0.58, zusätzlich zu den $0.73, um darauf zu trainieren. Distillation machst du nachdem die Retrieval-Pipeline funktioniert, um sie günstiger zu machen, und sie erbt jeden Fakt, den der Retriever falsch hatte.

Geld ist die sichtbare Hälfte. Die andere kommt als Warten, mit derselben Ursache wie die Rechnung: Das Modell liest den gesamten prompt, bevor es ein Wort sagt. Kapitel 13 hat Prefill gegen Decode auf einem Modell gemessen, das du anfassen konntest; hier ist dieselbe Messung, ein Lauf, eine Maschine, gegen prompt-Länge:

Die absoluten Zahlen gehören zu einem 0.5B-Modell auf sechzehn CPU-Threads und sagen nichts über ein gehostetes Frontier-Modell. Die Form überträgt sich exakt: Prefill wächst mit der prompt-Länge, und die Kosten pro token steigen langsam, wenn der quadratische Term aus Kapitel 9 sichtbar wird — 4,79 ms bei tausend tokens gegenüber 6,04 ms bei achttausend, eine Strafe von 26 % allein dafür, länger zu sein.

Die Konsequenz für die drei Routen ist direkt. Route eins prefills dreiundvierzigtausend tokens pro Frage, und ein Cache-Hit macht das erträglich — Kapitel 16 erklärte warum: Ein Cache-Read ersetzt Prefill-Arbeit, kauft also Latenz und Geld in einer Transaktion. Route zwei prefills tausend und fügt vorher einen Roundtrip zum Index hinzu. Route drei prefills achtundzwanzig und fügt nichts hinzu, was sie beim Antworten messbar zur schnellsten der drei macht. Sie beantwortet nur das Falsche.

Drei Fehler, die wie Modellprobleme aussehen und keine sind — zehn Minuten hier sparen später einen Monat:

Und die Anforderung über allem: Diese Entscheidung kann nicht ohne Evaluationsset getroffen werden, und der Anbieter, der das fine-tune verkauft, sagt es selbst. OpenAIs Guide beginnt mit „Only invest in fine-tuning after setting up evals. You need a reliable way to determine whether your fine-tuned model is performing better than a base model“ und ergänzt: Wenn fünfzig gute Beispiele nichts ändern, liegt das Problem an der Aufgabe oder am prompt, nicht an der Datenmenge.¹ Zwanzig Fragen, wie dieses Kapitel sie verwendet hat, zeigen einen Mechanismus und können keinen Anbieter auswählen — Kapitel 4 hat gemessen, warum; und was zu tun ist, wenn zwanzig Fälle alles sind, was du hast — wiederholen, paaren und die Streuung zwischen Läufen messen — ist Kapitel 29.

Vier Spalten, und nur die letzte entscheidet:

Die Regel, die daraus fällt, ist kurz genug, um sie zu behalten: Starte mit dem prompt; füge Retrieval hinzu, wenn sich die Fakten bewegen; fine-tune nur, wenn du gemessen hast, dass das, was dir noch fehlt, eine Form ist, kein Fakt — und bepreise die Antwort, nicht den prompt, bevor du es tust.

Die unbequeme Version, für alle, die mit bereits gefällter Entscheidung gekommen sind: Im gemessenen Fall dieses Kapitels ist fine-tuning oberhalb von viertausend Fragen pro Monat die günstigste Route, und bei den Fakten schlägt es trotzdem nicht, auf alles CLAUDE.md zu antworten.

Jeder Preis hier war pro token, und jede Route eine andere Art, tokens anzuordnen. Das wird gleich nicht mehr stimmen.

Kapitel 21 verlässt Text. Ein Bild, das in ein Modell geht, ist kein String, sondern ein Raster aus Patches mit einer token-Zahl, die du nicht gewählt hast; eine gesprochene Minute wird bei einem Anbieter sekündlich abgerechnet und bei einem anderen per audio token; synthetische Sprache wird pro Zeichen verkauft, Transkription pro Minute, rohe Rechenleistung pro GPU-Sekunde. Die Frage, die dieses Kapitel mit einer Kostenfunktion beantwortet hat — was ist günstiger? — kann nicht einmal gestellt werden, bis die Einheiten zusammenpassen, und kein Rechner im Internet normalisiert sie.

Dort taucht auch wieder Training auf: ein Bildadapter mit einem trigger word und eine aus einem Sample geklonte Stimme. Das wirft die Frage auf, mit der das nächste Kapitel beginnt, und sie ist nicht rhetorisch: Wenn fine-tuning eines Sprachmodells fast immer der falsche Kauf ist, warum ist fine-tuning eines Bildmodells fast immer der richtige?

Jeder Preis, Schwellenwert und Multiplikator in diesem Kapitel wurde am 7. September 2026 von der eigenen Seite des Anbieters gelesen und mit diesem Datum zitiert, weil sich alles davon bewegen wird. Die gemessenen Zahlen — token-Zahlen, chunk-Größen, Retrieval-Größen, Trainingsverlust, Scores, Latenzen und Versionshistorien-Zählungen — wurden am selben Tag auf einer Maschine erzeugt und sind aus dem oben beschriebenen Korpus reproduzierbar.

Die lokalen Experimente verwendeten Qwen/Qwen2.5-0.5B-Instruct mit greedy decoding, sodass sie exakt reproduzierbar sind; der Adapter ist die oben abgedruckte zwölfzeilige Klasse, bei Rank 8 über q_proj und v_proj. Der Korpus ist die versionierte Markdown-Dokumentation eines aktiv genutzten Software-Repositorys, ohne zwei append-only Logs, und seine Änderungsrate wurde aus der Versionshistorie dieses Repositorys gezählt.