# Ökonomie & Modellwahl — die Ressourcen-Entscheidungen > Token-Ökonomie, Latenz-Budget und Modellwahl: gemessene Kostenanteile optimieren, interaktive und asynchrone Last trennen sowie Modelle, Routing und Adaptions-Hebel am eigenen Qualitätsziel evaluieren. Track: [AI-Grundlagen](https://physar.tech/learn/ai-foundations) Kanonische Fassung: https://physar.tech/learn/ai-foundations/economics-model-choice Stand: 2026-07-25 Interaktiver Teil: 8 Checks (nur im Browser) ## Ökonomie & Modellwahl — die Ressourcen-Entscheidungen ### Warum die Ressourcen-Sicht? In Produktion optimierst du drei Ziele: **Kosten**, **Latenz** und **Qualität**. Welcher Hebel trägt, entscheidet nicht eine allgemeine Rangliste, sondern eure gemessene Last, das Qualitätsziel und die konkrete Anbieter- oder Deployment-Konfiguration. Technisch verarbeitet der **Prefill** viele Positionen der Eingabe weitgehend parallel; der autoregressive **Decode** erzeugt Ausgabepositionen nacheinander. Das prägt Rechen- und Latenzprofile, legt aber weder Preise noch Modellrangfolgen fest. > **Merksatz:** Erst den Engpass und das Ziel messen, dann Kosten-, Latenz- oder Modellhebel wählen. ### Token-Ökonomie: Input ist nicht Output Eine Kostenrechnung multipliziert **gemessene Mengen** mit den Sätzen des gewählten Anbieters, Modells oder eigenen Deployments. Input, Output, Cache-Nutzung und weitere Rechenanteile können unterschiedlich abgerechnet werden; aus Prefill und Decode folgt keine universelle Preisrelation. Wenn die Abrechnung zeigt, dass lange Antworten den größten Kostenanteil verursachen, ist Output-Kürzung der erste Kandidat. Dominiert dagegen ein großer Kontext, setzt du dort an. Die sequenzielle Ausgabe macht die Antwortlänge zusätzlich zu einem Latenzhebel — wie stark, muss die Ende-zu-Ende-Messung zeigen. | | | | --- | --- | | Input (Prompt, Kontext, Historie) | Menge × anbieter-/deploymentabhängiger Satz; Prefill weitgehend parallel | | Output (erzeugte Antwort) | Menge × anbieter-/deploymentabhängiger Satz; Decode autoregressiv und sequenziell | > **Merksatz:** Optimiere den **gemessenen Kostenanteil**, der die Rechnung dominiert — nicht die Seite, die pauschal teuer wirken soll. ### Multi-Turn: der Verlauf wächst mit Bei einer **stateless Integration**, die bei jedem Aufruf die vollständige Historie mitsendet und keinen serverseitigen Gesprächszustand nutzt, wächst der Input pro Zug mit dem Verlauf. Das ist eine Eigenschaft dieser Integration — nicht aller APIs oder Betriebsformen. Sind die Züge ungefähr gleich lang, wird die Historie immer vollständig erneut gesendet und greift kein Cache, summiert sich der wiederholte Input grob quadratisch mit der Zugzahl. Fenster und Summary ändern die Menge; unterstütztes Caching kann Wiederverarbeitung oder Abrechnung des stabilen Präfixes verändern. - **Verlauf kürzen** — nur aufgabenrelevante Züge oder ein begrenztes Fenster mitsenden. - **Zusammenfassen** — ältere Züge verdichten und den Informationsverlust im Eval prüfen. - **Prefix-/Prompt-Caching** — wiederholte Präfixe nur dann wiederverwenden, wenn Anbieter oder eigenes Deployment dies unterstützt; Wirkung und Abrechnung messen. > **Merksatz:** Die Kostenkurve folgt dem Kontext, den **deine Integration pro Aufruf erneut verarbeitet**. ### Latenz: TTFT, Gesamtzeit und Streaming **Time-to-First-Token (TTFT)** misst aus Sicht des gewählten Messpunkts bis zum ersten Token. Clientseitig können darin Netzwerk, Queueing, Vorverarbeitung, Retrieval oder Tool-Schritte und Prefill stecken. Die **Gesamtzeit** umfasst zusätzlich Decode und spätere Pipeline-Schritte. Deshalb beide Größen am relevanten Systemrand instrumentieren. Client sendet Request → Netzwerk, Queue und Vorverarbeitung → **Prefill → erstes Token** → Decode und weitere Schritte → vollständige Antwort **Streaming** kann den ersten sichtbaren Fortschritt vor die vollständige Antwort ziehen. Ob Nutzer das als schneller oder hilfreicher erleben, ist eine testbare UX-Hypothese. Streaming verkürzt weder automatisch die Gesamtzeit noch erhöht es automatisch den Durchsatz. > **Merksatz:** Trenne **erste sichtbare Reaktion**, **vollständige Antwort** und **Durchsatz** — ein Hebel verbessert nicht automatisch alle drei. ### Interaktiv vs. Batch: der richtige Pfad **Interaktive** Last hat ein Nutzer-Latenzbudget; **nicht-interaktive** Massenarbeit hat meist ein Fertigstellungsfenster. Teilt beides denselben synchronen Pfad, konkurrieren Requests um Threads, Queues, Quoten und Serving-Kapazität. Eine Queue, ein Worker-Pool oder eine unterstützte Batch-Schnittstelle entkoppelt die Lasten. Batching kann Auslastung verbessern und je nach Anbieter oder eigenem Deployment eine andere Kostenstruktur haben; ein Preisvorteil ist aber keine Universalität. Auch Modellgröße allein sagt weder Tempo noch Kosten voraus. > **Merksatz:** Wartet niemand live, optimiere einen **isolierten asynchronen Pfad** auf Fertigstellungsziel und Durchsatz. ### Right-Sizing und Routing: Qualität ist die Schranke Beim **Right-Sizing** gewinnt das kleinste Kandidatenmodell, das definierte Qualitäts- und Zuverlässigkeitsschwellen in einem **repräsentativen, gelabelten Eval** erfüllt. Ein kleines Modell kann genügen; Größe allein beweist weder Qualität noch Latenz oder Kosten. Bei heterogener Last kann **Capability-Routing** einfache Fälle an einen ressourcenärmeren Kandidaten und schwierige Fälle an einen stärkeren Kandidaten geben. Das lohnt nur, wenn eine extern gelabelte, kalibrierte Qualitätsprognose die Zielqualität im Eval hält. Rohe Selbstconfidence des antwortenden Modells ist kein unabhängiges Routing-Signal. | | | | --- | --- | | Ein Modell für alles | Einfacher Betrieb; akzeptabel, wenn es die Schwelle zu tragbaren Kosten erfüllt | | Routing | Zusätzlicher Router und Fallback; nur bei validiertem Qualitäts-/Kostenvorteil | | Mittelgroßer Kompromiss | Faire Option, wenn er selbst die Schwelle erfüllt — sonst keine automatische Lösung | > **Merksatz:** Erst die Qualitätsschranke im eigenen Eval halten; dann unter den bestandenen Varianten Kosten und Betrieb vergleichen. ### Adaption: Ursache statt Universal-Leiter Prompting, Retrieval und Fine-Tuning sind keine universell sortierte Kostenleiter. Zuerst diagnostizierst du die Eval-Lücke; dann vergleichst du Kandidaten am Qualitätsziel sowie an Einführungs- und Betriebskosten. Beginne mit dem kleinsten **reversiblen Experiment**, das die vermutete Ursache prüft. | | | | --- | --- | | Prompt, Beispiele, Schema | Kandidat bei unklarer Anweisung, fehlenden Demonstrationen oder Ausgabegrenzen | | RAG / Retrieval | Kandidat für dynamisches Wissen oder einen großen, variablen Bestand an Fakten und Beispielen | | Fine-Tuning | Kandidat für wiederkehrendes Zielverhalten, wenn Nutzen, Trainingsdaten, Eval und Modell-Lifecycle den Zusatzaufwand rechtfertigen | Veränderliche Fakten gehören nicht als alleinige Aktualisierungsstrategie ins Fine-Tuning. Bleibt eine gemessene Verhaltenslücke nach kleineren Experimenten bestehen, kann Fine-Tuning sinnvoll sein — mit eigenem Daten-, Evaluations- und Betriebszyklus. > **Merksatz:** Jeder Adaptions-Hebel ist eine Hypothese über **Ursache, Qualitätsziel und Lifecycle** — prüfe sie reversibel und eskaliere nur bei verbleibender Eval-Lücke. ### Modell-Migration: nicht blind tauschen Öffentliche Benchmarks und Kostenprognosen sind Kandidatensignale, keine Freigabe. Für die **Basismodell- und Pipeline-Wahl** vergleichst du Alt und Neu auf einem repräsentativen, gelabelten Eval mit euren Qualitäts-, Zuverlässigkeits-, Latenz- und Kostenzielen. Diese Achse endet bei der Entscheidung über Basismodell und Pipeline. Fällt sie positiv aus, prüft der Prompt-Track anschließend Portabilität und gezieltes Re-Tuning des Prompts. So vermischst du die Modellwahl nicht vorab mit einer zweiten Änderung. > **Merksatz:** Erst Basismodell und Pipeline im eigenen Eval vergleichen; danach Prompt-Portabilität separat prüfen. ### Gleich im Check Du entscheidest gleich alle acht Achsen: **gemessener Input-/Output-Kostenanteil**, **vollständig mitgesendete Chat-Historie**, **TTFT und Streaming**, **Batch vs. interaktiv**, **Right-Sizing**, **validiertes Capability-Routing**, **ursachengerechte Adaption** und **Basismodell-/Pipeline-Migration**. > **Gleich im Check:** In den nächsten acht Entscheidungen liest du reale Ops-Symptome und wählst den Hebel, der die knappe Ressource trifft — und siehst pro Option, **warum** sie trägt oder Geld, Zeit oder Qualität am falschen Ende verbrennt. ## Quellen - Pope et al. — Efficiently Scaling Transformer Inference, MLSys 2023 (Prefill-/Decode-Asymmetrie) - Agrawal et al. — Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, OSDI 2024 (Prefill, Decode, Batching) - Yao et al. — ScaleLLM: A Resource-Frugal LLM Serving Framework by Optimizing End-to-End Efficiency, EMNLP Industry 2024 - Zheng et al. — SGLang: Efficient Execution of Structured Language Model Programs, NeurIPS 2024 (KV-/Prefix-Wiederverwendung) - Liang et al. — Holistic Evaluation of Language Models, TMLR 2023 - Ding et al. — Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing, ICLR 2024 - Xiong et al. — Can LLMs Express Their Uncertainty? An Empirical Evaluation of Confidence Elicitation in LLMs, ICLR 2024 - Brown et al. — Language Models are Few-Shot Learners, NeurIPS 2020 - Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 - Gekhman et al. — Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?, EMNLP 2024 - Raji et al. — AI and the Everything in the Whole Wide World Benchmark, NeurIPS Datasets and Benchmarks Track 2021 - Pope et al. — Efficiently Scaling Transformer Inference, MLSys 2023 (Prefill- vs. Decode-Phase) - Agrawal et al. — Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, OSDI 2024 (Prefill-/Decode-Asymmetrie) - Zheng et al. — SGLang: Efficient Execution of Structured Language Model Programs (RadixAttention/Prefix-Caching), NeurIPS 2024 - Agrawal et al. — Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, OSDI 2024 (TTFT, Prefill, Decode) - Kleppmann — Designing Data-Intensive Applications, 2017 (Batch- vs. Online-Verarbeitung) - Nygard — Release It!, 2. Auflage 2018 (Bulkhead: Ressourcen-Isolierung) - Agrawal et al. — Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, OSDI 2024 (Batching und Durchsatz-/Latenz-Trade-off) - Chen et al. — FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance, TMLR 2024 - Liang et al. — Holistic Evaluation of Language Models (HELM), TMLR 2023 (aufgabenabhängige, mehrdimensionale Bewertung) - Brown et al. — Language Models are Few-Shot Learners, NeurIPS 2020 (In-Context/Few-Shot als prüfbarer Kandidat) - Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 (nicht-parametrischer Wissenszugriff) - Google Cloud Vertex AI — Introduction to tuning, Abschnitt `Tuning compared to prompt design` — https://cloud.google.com/vertex-ai/generative-ai/docs/models/tune-models - Liang et al. — Holistic Evaluation of Language Models (HELM), TMLR 2023 (aufgabenabhängige Bewertung)