Inference Engineering
Nutzen Sie diese Skill, um die Qualitäts-, Latenz-, Zuverlässigkeits- und Kostenanforderungen eines KI-Produkts in ein gemessenes Inferenzsystem zu übersetzen. Es handelt sich um eine unabhängige operative Synthese, die auf Philip Kielys Inference Engineering (Baseten Books, 2026) basiert und weder vom Autor noch vom Verlag unterstützt oder gebilligt wird. Anbieterfunktionen, Modellveröffentlichungen, Hardwareverfügbarkeit und Softwareverhalten ändern sich schnell; überprüfen Sie aktuelle Details anhand der offiziellen Dokumentation, bevor Sie Implementierungsentscheidungen treffen.
Beginnen Sie mit der Arbeitslast
Bevor Sie eine Engine oder Optimierung auswählen, legen Sie Folgendes fest:
- Produktvertrag: erforderliche Ausgabequalität, Modalitäten, Kontext-/Eingabegrößen, Antwortform, Streaming-Anforderungen und Fehlerverhalten.
- Verkehrsform: Anfragenrate, Parallelität, Burstiness, Ankunftsmuster, Verteilungen der Eingabe-/Ausgabelängen und Cache-fähige Präfixhäufigkeit.
- Serviceziele: End-to-End P50/P95/P99-Latenz, Time to First Token (TTFT), Inter-Token-Latenz (ITL), Durchsatz, Verfügbarkeit und Wiederherstellungsziele.
- Einschränkungen: Budget, Regionen, Datenresidenz, Datenschutz, Lizenz, Hardwarezugriff und Betriebskapazität.
- Basislinie: repräsentative Qualitätsbewertung plus End-to-End-Leistung und Kosten unter realistischer Last.
Optimieren Sie keine Proxy-Metrik isoliert. Definieren Sie die Arbeitseinheit und beziehen Sie gegebenenfalls Client-, Warteschlangen-, Netzwerk-, Vorverarbeitungs-, Modell- und Nachbearbeitungszeit mit ein. Messen Sie bei agentischen Abläufen die gesamte Aufgabe einschließlich Tool-Aufrufen und Wiederholungen.
Betrieblicher Arbeitsablauf
- Charakterisieren Sie die Arbeitslast. Trennen Sie interaktiven Online-Verkehr von Offline-/Batch-Arbeit; identifizieren Sie latenzempfindliche und durchsatzorientierte Pfade. Erfassen Sie reale Eingabe-/Ausgabeverteilungen und Parallelität.
- Wählen Sie Kandidatenmodelle aus. Grenzen Sie die Auswahl ein nach aufgabenspezifischer Qualität, Modalität, Kontext, Serving-Einschränkungen, Lizenz und betrieblicher Eignung. Verwenden Sie öffentliche Benchmarks nur, um die Kandidaten einzugrenzen; bewerten Sie anhand repräsentativer Produktdaten und Fehlerfälle.
- Legen Sie Budgets fest. Übersetzen Sie End-to-End-Ziele in Budgets für Warteschlangen, Netzwerk, Vorverarbeitung, Prefill, Dekodierung und Nachbearbeitung. Berücksichtigen Sie Spielraum für Auslastungsspitzen und Beeinträchtigungen.
- Passen Sie das Modell an die Hardware an. Schätzen Sie den Gewichtsspeicher, den Laufzeit-/Aktivierungs-Overhead, den KV-Cache-Bedarf und den nutzbaren Spielraum. Überprüfen Sie die gemessene Speicherbandbreite, Rechenleistung, Verbindung und Topologie; eine nominelle Beschleunigerspezifikation ist kein Arbeitslast-Benchmark.
- Etablieren Sie eine reproduzierbare Basislinie. Legen Sie Modellrevision, Engine/Version, Hardware, Präzision, Konfiguration, Prompt-Mix, Ausgabelimits und Lastform fest. Führen Sie ein Warm-up durch, führen Sie ausreichend viele Stichproben durch und berichten Sie Perzentile und Durchsatz zur gleichen Zeit.
- Lokalisieren Sie den Engpass. Verwenden Sie zuerst End-to-End-Messungen, dann System- und Kernel-Profiling. Unterscheiden Sie Warteschlangen, Prefill, Dekodierung, Speicherkapazität/-bandbreite, Rechenleistung, Kommunikation und Host-Overhead.
- Ändern Sie jeweils eine Variable. Wenden Sie die am wenigsten komplexe Optimierung an, die den gemessenen Engpass adressiert. Überprüfen Sie Qualität, Tail-Latenz, Durchsatz, Speicher und Kosten gemeinsam.
- Validieren Sie das Produktionsverhalten. Testen Sie Überlast, Kaltstarts, Skalierungsereignisse, Fehler, Bereitstellungen, Abbrüche, Streaming und Wiederherstellung. Instrumentieren Sie dieselben Metriken, die in den Servicezielen verwendet werden.
Metriken und Diagnose
- TTFT: Zeit von einem klar definierten Startereignis (z. B. Client-Send oder Server-Akzeptanz) bis zum ersten generierten Token. Halten Sie diese Grenze beim Vergleich von Läufen konsistent; sie ist empfindlich gegenüber Warteschlangen, Prompt-Länge, Prefill und Starteffekten.
- ITL: Zeit zwischen generierten Token; spiegelt die Dekodierungs-Reaktionsfähigkeit wider. Berichten Sie Verteilungen pro Anfrage, nicht nur die aggregierte Token-Rate.
- End-to-End-Latenz: die vom Client beobachtete Abschlusszeit; umfasst Netzwerk- und Anwendungsarbeit.
- Durchsatz: Abgeschlossene Anfragen oder Tokens pro Zeiteinheit bei einer angegebenen Arbeitslast und Latenz-/Qualitätshülle. Geben Sie an, ob Tokens/s pro Benutzer oder systemweit ist.
- Perzentile: Berichten Sie P50 plus Tail-Ziele wie P95/P99; Durchschnittswerte können langsame Anfragen verbergen.
- Goodput: Abgeschlossene Arbeit, die die relevanten Latenz- und Qualitätsziele erfüllt. Verwenden Sie dies, um Konfigurationen zu vergleichen, die Geschwindigkeit gegen Qualität oder Tail-Verhalten eintauschen.
Interpretieren Sie Symptome als Hypothesen und überprüfen Sie diese dann mit Traces/Profilen:
| Symptom | Wahrscheinlich zu messende Bereiche |
|---|---|
| Hoher TTFT, normaler ITL | Wartezeit in der Warteschlange, lange Prompts, Prefill-Berechnung, Kaltstart, Vorverarbeitung |
| Normaler TTFT, schlechter ITL | Dekodierungsbandbreite, Batch-Konkurrenz, KV-Cache-Druck, Kernel-Effizienz |
| Beide verschlechtern sich mit steigender Parallelität | Warteschlangen, Speicherkapazität, Batch-Richtlinie, Zulassungskontrolle, Sättigung |
| GPU-Auslastung niedrig, Latenz hoch | CPU/Tokenisierung, Datenübertragung, Synchronisation, Netzwerk, Planung |
| Durchsatz steigt, aber Tail-Latenz verletzt SLO | Batch-/Parallelitätsrichtlinie, Warteschlangenlimits, Arbeitslasttrennung |
Dies sind diagnostische Anhaltspunkte, keine Schlussfolgerungen. Bestätigen Sie den aktiven Engpass, bevor Sie die Konfiguration ändern.
Modell- und Hardwareentscheidungen
- Bevorzugen Sie das kleinste/kostengünstigste Modell, das die Qualitätsbewertung des Produkts mit akzeptablem Spielraum besteht. Erwägen Sie Prompting, Retrieval, Fine-Tuning oder Destillation nur, wenn die Bewertung eine spezifische Lücke identifiziert und die Lebenszykluskosten gerechtfertigt sind.
- Trennen Sie Online- und Offline-Bereitstellungen, wenn ihre Latenz-, Batch- oder Verfügbarkeitsziele in Konflikt stehen und der gemessene Verkehr den betrieblichen Aufwand rechtfertigt.
- Passen Sie das Modell und den Laufzeitzustand in den Beschleunigerspeicher ein, mit explizitem Spielraum für KV-Cache, Aktivierungen, Fragmentierung und Parallelität. Die alleinige Passung des Gewichts ist unzureichend.
- Bei autoregressiven LLMs belasten Prefill und Dekodierung die Hardware unterschiedlich: Prefill ist in der Regel rechenintensiv; Dekodierung wird oft speicherbandbreitenbegrenzt. Messen Sie beides für die tatsächliche Sequenz- und Batch-Mischung.
- Multi-GPU-Entscheidungen tauschen Speicher/Latenz/Durchsatz gegen Kommunikation und Komplexität. Tensor-Parallelität kann die Latenz pro Anfrage für ein aufgeteiltes Modell reduzieren; Expertenparallelität kann spärliche Experten skalieren. Validieren Sie Verbindungs- und Synchronisationskosten. Multi-Node-Ausführung erfordert besonders sorgfältige Kommunikationsmessung.
- Verwenden Sie für Bild-, Video-, Audio-, Embedding- und Vision-Language-Arbeitslasten modellspezifische Pipelines und Metriken. Beziehen Sie Vorverarbeitungs-, Chunking-, Encoder/Decoder- und Nachbearbeitungskosten ein; wenden Sie LLM-Token-Metriken nicht blind an.
- Überprüfen Sie Modell- und Datensatzlizenzen sowie relevante Sicherheits-, Datenschutz- und regulatorische Anforderungen vor der Bereitstellung.
Für die Begründung dieser Entscheidungen lesen Sie Modell- und Hardware-Grundlagen. Für Framework-, Format- und Serving-Engine-Kompatibilität lesen Sie Software-Stack-Auswahl. Diese Referenzen bieten Entscheidungsmethoden, keine zeitlosen Ranglisten: Überprüfen Sie die Unterstützung für das genaue Modell, den Beschleuniger, die Laufzeitversion und die Feature-Menge.
Optimierungs-Playbooks
Wenden Sie diese erst an, nachdem Sie eine Basislinie etabliert und einen kompatiblen Engpass identifiziert haben:
Batching und Planung
Batching kann die Beschleunigerauslastung verbessern und Overhead amortisieren, während es die Wartezeit und die Latenz pro Anfrage erhöht. Passen Sie Parallelität, Batch-Limits, Wartefenster und Zulassungskontrolle an realistische Ankünfte an. Schützen Sie interaktiven Verkehr vor Batch-Arbeit, wenn ihre Ziele in Konflikt stehen.
Quantisierung
Behandeln Sie Quantisierung als ein Qualitäts-/Leistungsspektrum, nicht als binäre Einstellung. Wählen Sie basierend auf gemessenen Speicher-, Bandbreiten-, Rechen- und Qualitätseinschränkungen, welche Komponenten und Präzision geändert werden sollen. Bewerten Sie repräsentative Aufgabequalität, Grenzfälle und Regressionssätze nach jeder Änderung; beobachten Sie separat Gewichts-, Aktivierungs-, Aufmerksamkeits- und KV-Cache-Effekte, wo die Engine dies erlaubt. Kehren Sie die Änderung um, wenn die Produktqualitätsuntergrenze oder das Zuverlässigkeitsziel verfehlt wird.
Spekulative Dekodierung
Verwenden Sie einen Entwurfs-/Vorschlagsmechanismus nur, wenn dessen Vorschlagskosten und Akzeptanzverhalten einen Nettogewinn für die Zielarbeitslast erbringen. Messen Sie Akzeptanzrate, Speicher-Overhead, Batch-Größenauswirkung, ITL pro Benutzer, aggregierten Durchsatz und Kosten. Der Nutzen kann bei hoher Parallelität oder schwacher Akzeptanz schrumpfen oder sich umkehren.
KV- und Präfix-Caching
Verwenden Sie zwischengespeicherten Zustand wieder, wenn Präfixe wiederkehren und Korrektheits-/Isolierungsanforderungen dies zulassen. Messen Sie Trefferquote, eingesparte Prefill-Arbeit, Speicherkosten, Räumungsverhalten und Routing-Lokalität. Definieren Sie Cache-Schlüssel und Mandanten-/Sicherheitsgrenzen, damit eine Anfrage nicht den privaten Kontext eines anderen Mandanten wiederverwenden kann. Lange Kontexte und hohe Parallelität erhöhen den KV-Druck; berücksichtigen Sie Platzierungs- und Übertragungskosten.
Parallelität und Entkopplung
Führen Sie Parallelität ein, wenn Modellfit, Latenz- oder Durchsatzmessungen den Kommunikations-Overhead rechtfertigen. Entkoppeln Sie Prefill und Dekodierung nur, wenn die Arbeitslast groß und stabil genug ist, um von unabhängiger Ressourcenzuweisung zu profitieren, und das System den KV-Transfer/das Routing verwalten kann. Beziehen Sie Netzwerkbandbreite, Übertragungslatenz, Fehlermodi und betriebliche Komplexität in den Vergleich ein.
Kernel- und Laufzeitoptimierung
Profilieren Sie, bevor Sie spezialisierte Kernel schreiben oder auswählen. Kernel-Fusion kann Speicherverkehr und Start-Overhead reduzieren, aber Kompatibilität und numerisches Verhalten sind wichtig. Vergleichen Sie Framework-/Laufzeit-/Engine-Kandidaten mit derselben Modellrevision, Hardware, Prompt-Mischung, Ausgabelängen, Last und Qualitätsprüfungen.
Für detaillierte Vergleiche von Quantisierungsmethoden, Familien spekulativer Dekodierung, Cache-Platzierung, Langkontext-Serving und verteilter Ausführung lesen Sie das Optimierungs-Playbook.
Benchmarking und Profiling
- Verwenden Sie Produktions-Traces oder eine datenschutzsichere Arbeitslast, die Anforderungsgrößen, Ankunftsmuster und Cache-Eigenschaften bewahrt. Synthetische Tests sind für kontrollierte Experimente nützlich, aber geben Sie ihre Grenzen an.
- Erfassen Sie Kalt- und Warmverhalten getrennt. Beziehen Sie Warmup, ausreichende Dauer/Stichprobenanzahl, wiederholte Läufe, Varianz und Hardware-/Softwareversionen mit ein.
- Durchlaufen Sie die Last, um sowohl die Sättigung als auch den maximalen Goodput unter SLOs zu finden. Vermeiden Sie den Vergleich eines schwach ausgelasteten Laufs mit einem überlasteten.
- Ändern Sie für die Attribution jeweils einen Faktor; führen Sie nach der Optimierung einen kombinierten End-to-End-Test durch, da Optimierungen interagieren können.
- Kombinieren Sie System-Benchmarks mit Aufgabenqualitätsbewertung. Leistungsverbesserungen, die die Ausgabe über die Produktschwelle hinaus verschlechtern, sind keine Gewinne.
- Benchmarking zeigt was langsam ist; Profiling hilft zu erklären warum. Verwenden Sie den am wenigsten intrusiven Profiler, der den aktiven Engpass isolieren und den vorgeschlagenen Fix mit einem neuen Benchmark validieren kann.
Produktionsreife
- Kapazität und automatische Skalierung: Skalieren Sie basierend auf Frühindikatoren (Warteschlangentiefe, Auslastung, Speicher-/KV-Druck, Ankunftsrate) sowie abgeschlossener Arbeit. Berücksichtigen Sie Bereitstellungs- und Modellladezeit; halten Sie ausreichend Kapazität oder degradieren Sie elegant, wenn Kaltstarts Ziele verletzen.
- Warteschlangen und Überlast: Begrenzen Sie Warteschlangen und Anforderungsgrößen, setzen Sie Timeouts/Abbrüche, verwenden Sie Zulassungskontrolle und definieren Sie explizite Überlastreaktionen. Unbegrenzte Warteschlangen verwandeln Sättigung in Tail-Latenz-Fehler.
- Zuverlässigkeit: Testen Sie Health Checks, Wiederholungen mit Limits, Idempotenz, wo nötig, Instanzverlust, regionalen/Anbieter-Ausfall, Rollout, Rollback und Kapazitätserschöpfung. Wiederholungen können Überlast verstärken.
- Bereitstellung: Fixieren Sie Modellartefakte und Abhängigkeiten, validieren Sie Start/Bereitschaft, Canary-Änderungen, vergleichen Sie Qualitäts- und Servicemetriken und behalten Sie einen getesteten Rollback-Pfad. Vermeiden Sie die Offenlegung von Geheimnissen in Images, Logs oder Benchmark-Artefakten.
- Observability: Korrelieren Sie Anfrage-Traces mit Modell-, Engine-, Hardware- und Konfigurationsversionen. Verfolgen Sie TTFT, ITL, End-to-End-Perzentile, Wartezeit, Durchsatz/Goodput, Fehler, Cache-Trefferquote, Auslastung, Speicher, Kaltstarts und Kosten.
- Kosten: Vergleichen Sie die Kosten pro erfolgreicher Anfrage oder nützlicher Ausgabe bei der erforderlichen Qualität und SLO, einschließlich Leerlaufkapazität, Replikation, Vernetzung, Speicher und Ingenieur-/Betriebsaufwand. Scale-to-Zero kann Leerlaufausgaben reduzieren, fügt aber Kaltstart-Latenz hinzu.
- Sicherheit und Compliance: Kontrollieren Sie Modell- und Datenzugriff, isolieren Sie Mandanten, schützen Sie Prompts und Ausgaben in Logs, definieren Sie Aufbewahrung, validieren Sie Abhängigkeiten und Artefakte und erfüllen Sie anwendbare Datenresidenz- und regulatorische Anforderungen.
Für Container-Reproduzierbarkeit, Kapazität und Routing, Multi-Region-Betrieb, Client-Protokolle und Rollout-Praktiken lesen Sie Produktionsbetrieb. Für modalitätsspezifische Messung lesen Sie Modell-spezifische Inferenzüberlegungen.
Referenz-Routing
| Aufgabe | Lesen Sie |
|---|---|
| Erstellen einer Arbeitslastkarte, Etablieren einer Basislinie oder Lokalisieren eines Engpasses | Diese Datei, dann Optimierungs-Playbook |
| Verstehen der Modellausführung, des Beschleuniger-Fits oder von Hardware-Kompromissen | Modell- und Hardware-Grundlagen |
| Auswählen eines Frameworks, Modellformats, Kernel-Pfads oder einer Serving-Engine | Software-Stack-Auswahl |
| Optimieren von Quantisierung, Spekulation, Caches, Parallelität oder Entkopplung | Optimierungs-Playbook |
| Bedienen von Vision, Embeddings, Audio, Bild- oder Video-Arbeitslasten | Modalitätsspezifische Überlegungen |
| Planen von Autoscaling, Bereitstellung, Zuverlässigkeit, API/Client-Verhalten und Kosten | Produktionsbetrieb |
Antwortformat für Inferenzaufgaben
Geben Sie bei der Beratung oder Implementierung Folgendes an:
- Arbeitslastannahmen und fehlende Messungen.
- Das Ziel und die Basislinienmetriken.
- Die führende Engpasshypothese und wie man sie beweist.
- Einen abgestuften Experimentierplan mit erwarteten Kompromissen.
- Qualitäts-, Tail-Latenz-, Zuverlässigkeits-, Sicherheits- und Kostenakzeptanzkriterien.
- Aktuelle Anbieter-/Modell-/Laufzeitfakten mit Links zu offiziellen Quellen, wenn sie die empfohlene …
… [für die Übersetzung gekürzt]