Bedeutung von KI-Inferenz: Architektur, Performance und Leitfaden für Cloud-Bereitstellung

KI-Inferenz bedeutet, ein trainiertes KI-Modell auf neue Eingaben anzuwenden, um eine Ausgabe zu erzeugen: eine Klassifizierung, Vorhersage, Einbettung, ein Bild, einen Token-Stream oder eine Entscheidung. Das Training verändert die gelernten Parameter eines Modells; die Inferenz nutzt diese Parameter, um nützliche Arbeit zu leisten. Bei einem LLM besteht die praktische Aufgabe darin, einen Prompt schnell, zuverlässig und zu Kosten, die zum Workload passen, in generierte Tokens umzuwandeln.

Diese Definition ist einfach. Inferenz in der Produktion zu betreiben, ist es nicht. Eine Anfrage muss authentifiziert, weitergeleitet, in eine Warteschlange gestellt, tokenisiert, auf Hardware geplant, durch das Modell ausgeführt, zurückgestreamt, gemessen und bei einem Fehler wiederhergestellt werden. Dieser Leitfaden erklärt die Bedeutung von KI-Inferenz in diesem operativen Sinn: was zwischen einer Anwendungsanfrage und einer nützlichen Antwort geschieht, welche Messwerte tatsächlich wichtig sind und wie der Workload auf Cloud-GPUs bereitgestellt wird, ohne eine Demo als Produktionssystem zu behandeln.

Bedeutung von KI-Inferenz in einem Satz

KI-Inferenz ist die Ausführungsphase des maschinellen Lernens: Ein trainiertes Modell wendet gelernte Parameter auf neue Daten an und gibt ein Ergebnis zurück. NVIDIA beschreibt Inferenz als den Punkt, an dem ein trainiertes Modell aus neuen Daten Ausgaben erzeugt, während Training der iterative Prozess der Anpassung von Modellgewichten anhand von Trainingsdaten ist. NVIDIAs Überblick zur KI-Inferenz ist eine nützliche Primärreferenz für diese Unterscheidung.

Wenn Sie nach der Bedeutung von KI-Inferenz gesucht haben, behalten Sie dieses mentale Modell im Hinterkopf:

Training lehrt ein Modell. Inferenz setzt das trainierte Modell ein.

Bei einer Chat-Anwendung ist diese Arbeit generativ: den Prompt verarbeiten, jeweils das nächste Token vorhersagen und einen Stream zurückgeben, bis eine Stoppbedingung erreicht ist. Bei einem Klassifikator kann es ein einzelner Score sein. Bei einem Embedding-Modell kann es ein Vektor sein. Die Kernidee ändert sich nicht: Neue Eingaben gehen hinein; ein Ergebnis kommt heraus; die gelernten Gewichte bleiben für diese Anfrage unverändert.

KI-Inferenz vs. Training vs. Fine-Tuning vs. Serving

Diese Begriffe sind miteinander verbunden, lösen jedoch unterschiedliche Aufgaben. Werden sie verwechselt, kaufen Teams die falsche Infrastruktur oder messen das Falsche.

Anders ausgedrückt: Die Bedeutung von KI-Inferenz ist nicht „die gesamte Plattform“. Sie ist der Schritt der Modellausführung. Inference Serving ist das umgebende Produktionssystem, das diesen Schritt für andere Software nutzbar macht.

Diese Einordnung macht aus der Bedeutung von KI-Inferenz eine Betriebsentscheidung statt einer Vokabelfrage: Identifizieren Sie zuerst den Schritt der Modellausführung und weisen Sie dann Verantwortlichkeiten für alles zu, was ihn zuverlässig macht.

So funktioniert KI-Inferenz für ein LLM

Die genaue Implementierung unterscheidet sich je nach Modellfamilie, aber eine LLM-Anfrage in Produktion folgt in der Regel diesem Pfad:

1. Die Anwendung sendet eine Anfrage. Der Client liefert Nachrichten oder einen Prompt, Generierungslimits sowie Identitäts- oder Mandantenkontext.
2. Eine Edge- oder API-Schicht validiert und leitet sie weiter. Hier befinden sich üblicherweise Authentifizierung, Kontingente, Modellauswahl, Sicherheitsprüfungen und Anfragenprotokollierung.
3. Der Server tokenisiert die Eingabe. Text wird in für das Modell lesbare Token-IDs umgewandelt. Bild-, Audio- oder strukturierte Eingaben benötigen ihre modalspezifische Vorverarbeitung.
4. Prefill verarbeitet den Prompt. Das Modell berechnet den Prompt-Kontext in einem großen ersten Durchlauf. NVIDIAs Überblick zur LLM-Inferenz trennt dies von Decode und behandelt beides als Bestandteile der Ende-zu-Ende-Anfragelatenz. Siehe die Beschreibung von Prefill/Decode.
5. Der Server behält nutzbaren Attention-Zustand bei. Transformer-Serving-Systeme halten üblicherweise den Key/Value-(KV)-Zustand für aktive Sequenzen vor, damit nicht für jedes nächste Token der gesamte vorherige Kontext neu berechnet werden muss. TensorRT dokumentiert den KV-Cache als eine von Anwendung oder Framework verwaltete Speicherressource und nicht als bloßen Nachgedanken. Lesen Sie die TensorRT-Referenz zum KV-Cache.
6. Decode erzeugt die Ausgabe Token für Token. Das Modell sagt wiederholt das nächste Token voraus, aktualisiert den Zustand und streamt entweder die Teilantwort oder wartet auf die Fertigstellung.
7. Die Plattform erfasst Nutzung und beobachtet das Ergebnis. Eine Produktionsantwort sollte genügend Nachweise hinterlassen, um Latenz, Fehler, Sättigung und Nutzung zu untersuchen, ohne mehr Kundeninhalte zu speichern, als das System benötigt.

Das ist die Architektur, die sich hinter der kurzen Definition der Bedeutung von KI-Inferenz verbirgt. Ein Modell allein ist kein Service mit niedriger Latenz; es benötigt einen Pfad für Anfragen, Rechenleistung, Zustand und Feedback.

Die Cloud-Inferenzarchitektur, die Sie vor der Bereitstellung zeichnen sollten

Bevor Sie einen GPU-Typ oder eine Serving-Engine auswählen, skizzieren Sie den Anfragepfad. Die folgende Referenzarchitektur gilt für einen selbst gehosteten LLM- oder multimodalen Modellendpunkt auf Cloud-GPUs.

Client / Anwendung
        │
        ▼
API-Edge: Authentifizierung · Limits · Anfrage-IDs · Routing
        │
        ▼
Warteschlange / Scheduler ──► Zulassungssteuerung und Timeouts
        │
        ▼
Inferenzserver: Tokenizer → Prefill → KV-Cache → Dekodieren / Streamen
        │                         │
        ▼                         ▼
GPU-Worker-Pool              Signale zur Cache-Kapazität
        │
        ▼
Metriken, Traces, Logs, Warnungen und Bereitstellungssteuerung

Jede Schicht hat einen eigenen Fehlermodus:

• API-Edge: ungültige Anmeldedaten, ausgeschöpfte Kontingente, falsche Modellparameter, Mandantenisolation und Anfragekorrelation.
• Warteschlangen- und Zulassungsschicht: Backpressure, Priorisierungsentscheidungen, Timeout-Richtlinien und Schutz vor Überlastungskaskaden.
• Inferenzserver: Modellladen, Tokenisierung, Batching, Speicherzuweisung, Prompt-Ausführung, Tokengenerierung und Streaming.
• GPU-Worker-Pool: Hardwareverfügbarkeit, Treiber-/Runtime-Kompatibilität, GPU-Speicherreserve, Netzwerktopologie und Replika-Zustand.
• Observability: ob eine langsame Anfrage wartete, Prefill ausführte, dekodierte, erneut versucht wurde oder fehlschlug, bevor sie überhaupt eine GPU erreichte.

Bei groß angelegten Bereitstellungen kann diese Struktur um eine Modellregistrierung, Artefaktspeicher, eine separate Prefill-Schicht, eine separate Decode-Schicht oder einen cachebewussten Router ergänzt werden. Beginnen Sie nicht damit. Starten Sie mit einem beobachtbaren, wiederholbaren Pfad und führen Sie eine Trennung erst ein, wenn Messungen zeigen, dass die einfachere Topologie ihr Serviceziel verfehlt.

Die vier wichtigen Leistungsdimensionen

Teams fragen oft: „Wie schnell ist das Modell?“ Das ist zu vage, um eine Inferenzbereitstellung zu steuern. Eine hilfreiche Leistungsbewertung trennt vier Dimensionen.

Die aktuelle vLLM-Dokumentation stellt über ihren Metrik-Endpunkt Histogramme für Warteschlangenzeit, Prefill-Zeit, Decode-Zeit, TTFT, Anfragelatenz und Zeit pro Ausgabe-Token bereit. Nutzen Sie die Liste der Produktionsmetriken als konkrete Checkliste für die Instrumentierung.

Der wichtige Zusammenhang lautet: Die Performance von KI-Inferenz ist keine einzelne Zahl. Eine Bereitstellung kann beeindruckende aggregierte Tokens pro Sekunde erzeugen und interaktiven Nutzern dennoch eine schlechte TTFT bieten. Sie kann auch schnell das erste Token liefern, bei langen Ausgaben jedoch deutlich langsamer werden. Messen Sie den Anfragepfad in Phasen, bevor Sie Hardware oder Tuning-Flags ändern.

Warum Batching den Durchsatz verbessert – und das falsche Latenzziel beeinträchtigen kann

Cloud-GPUs sind teuer, wenn sie ungenutzt bleiben, daher fassen Inferenzserver kompatible Anfragen häufig zu Batches zusammen. Der dynamische Batcher von NVIDIA Triton kombiniert Anfragen und ermöglicht es Betreibern, zu begrenzen, wie lange der Scheduler auf einen größeren Batch wartet. Dadurch wird der Zielkonflikt explizit: Ein längeres Wartefenster kann Auslastung und Durchsatz verbessern, fügt jedoch Warteschlangenverzögerung hinzu. Die Dokumentation zu Tritons Batcher erläutert die Steuerungsmöglichkeiten.

Für LLMs kann „Continuous“, „Inflight“ oder „Iteration-Level“-Batching diese Planung flexibler machen. Anstatt zu warten, bis jede Sequenz in einem alten Batch abgeschlossen ist, kann ein Server bei aufeinanderfolgenden Generierungsschritten frei gewordene Slots mit neuer oder fortlaufender Arbeit füllen. NVIDIA dokumentiert diesen Ansatz als Möglichkeit, neue und bereits laufende Anfragen während der iterativen Verarbeitung zu mischen. Lesen Sie die Erläuterung zum Continuous Batching in Triton.

Betrachten Sie Batching nicht als Kontrollkästchen. Testen Sie es anhand eines schriftlich festgehaltenen Latenzbudgets:

• Interaktiver Chat und IDE-Unterstützung legen in der Regel großen Wert auf TTFT und die Ausgabetaktung.
• Batch-Zusammenfassungen, Embedding-Generierung und Offline-Anreicherung können eine längere Warteschlange im Austausch für einen höheren Durchsatz abgeschlossener Arbeit akzeptieren.
• Arbeit mit langem Kontext verlagert mehr Druck auf Prefill- und Cache-Kapazität.
• Arbeit mit langen Ausgaben belegt Decode-Ressourcen länger, was das Verhalten von Fair Queuing und Abbrüchen verändert.

Dieser Zielkonflikt ist in der Praxis zentral für die Bedeutung von KI-Inferenz: Der Dienst muss entscheiden, wie begrenzte Rechenkapazität geteilt wird, und nicht lediglich einen Forward Pass ausführen.

Cloud-GPU-Bereitstellung: Managed API oder selbst gehostete Inferenz?

Es gibt kein universell „richtiges“ Bereitstellungsmodell. Wählen Sie anhand der Steuerungsmöglichkeiten, die Ihr Workload tatsächlich benötigt.

Die meisten ausgereiften Systeme sind hybrid. Ein Team kann ein stabiles Modell mit hohem Volumen selbst hosten und zugleich verwaltete APIs für Long-Tail-Modelle, experimentelle Modalitäten, Spitzenkapazität oder einen Fallback-Pfad verwenden. Die nützliche Frage lautet nicht „Cloud-GPU oder API?“, sondern „Welche Teile des Anfragepfads müssen wir selbst verantworten?“

Ein ausführlicheres Entscheidungsframework für Kosten und Betrieb finden Sie unter GPU-Cloud vs. Modell-API. Wenn Sie sich dafür entscheiden, einen Serving-Endpunkt selbst zu betreiben, behandelt der Leitfaden für einen OpenAI-kompatiblen Inferenzserver einen praktischen, auf vLLM ausgerichteten Implementierungspfad.

Ein praxisorientiertes Playbook für die Cloud-GPU-Bereitstellung

Für ein Bereitstellungsteam wird die Bedeutung von KI-Inferenz zu einer Verantwortlichkeitskarte: Identifizieren Sie jede Phase der Anfrage, definieren Sie das Ziel, das sie erfüllen muss, und machen Sie Verantwortliche sowie das Signal für Fehler sichtbar.

1. Erstellen Sie vor der Bereitstellung einen Abnahmevertrag

Dokumentieren Sie den Workload in testbaren Begriffen:

• Modell und Version, einschließlich Lizenz und Artefaktquelle.
• Eingabemodalität, Verteilung der Prompt-Längen und erwartete Ausgabelängen.
• Gleichzeitige Anfragen bei Spitzenlast und unter Dauerlast.
• Ziele für TTFT, TPOT, Ende-zu-Ende-Latenz, Fehlerrate und Verfügbarkeit.
• Anforderungen an Streaming, Abbruch, Datenaufbewahrung und Regionen.
• Ein repräsentativer Evaluierungssatz für die Ausgabequalität – nicht nur ein Lastgenerator.

Ohne diesen Vertrag ist „wir brauchen eine schnellere GPU“ keine Entscheidung. Es ist eine Vermutung.

2. Erstellen Sie eine Baseline mit einer einzelnen Replik

Führen Sie eine Modellreplik in einer Nicht-Produktionsumgebung aus und erfassen Sie Metriken auf Phasenebene unter einer repräsentativen Mischung aus kurzen und langen Eingaben. Dokumentieren Sie die Modellserverversion, Treiber-/Laufzeitversion, Modellrevision, Tokenizer-Revision, Batch-Richtlinie und Parallelität. Eine reproduzierbare Baseline ermöglicht spätere Kapazitäts- und Incident-Analysen.

Für Teams, die eine Serving-Engine auswählen, bietet vLLM vs. SGLang einen workloadorientierten Vergleich statt der pauschalen Behauptung eines Gewinners.

3. Planen Sie Speicher als Gewichte plus Laufzeitzustand, nicht nur als Modellgröße

Der GPU-Speicher muss mehr als den Checkpoint aufnehmen. Er benötigt außerdem Platz für Laufzeitpuffer und aktiven Sequenzzustand wie den KV-Cache. Die TensorRT-Dokumentation macht die Zuweisungsgrenze sichtbar: Die Cache-Kapazität wird außerhalb der Transformer-Schicht selbst verwaltet. Das bedeutet, dass das Laden des Modells erfolgreich sein kann, während echter gleichzeitiger Datenverkehr dennoch Cache-Druck erzeugt.

Verwenden Sie einen empirischen Kapazitätstest mit Ihren tatsächlichen Kontextlängen und Ausgabelimits. Verfolgen Sie die Cache-Belegung, Preemptions oder Evictions, sofern Ihr Server diese bereitstellt, sowie das Fehlerverhalten an der Zulassungsgrenze. Ein verwandtes Framework zur Planung von GPU-Speicher finden Sie unter LLM-GPU-Speicheranforderungen.

4. Machen Sie GPU-Scheduling explizit

Kubernetes unterstützt Geräte-Plugins von Anbietern für GPUs und stellt sie als planbare Ressourcen bereit. Die Anleitung zur GPU-Planung legt fest, dass benutzerdefinierte GPU-Ressourcen in den limits eines Containers gehören, wobei requests entweder weggelassen werden oder dem Limit entsprechen. Lesen Sie die Kubernetes-Dokumentation zur GPU-Planung, bevor Sie das folgende Manifest anpassen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inference-server
  template:
    metadata:
      labels:
        app: inference-server
    spec:
      containers:
        - name: server
          image: registry.example.com/inference-server:immutable-tag
          resources:
            limits:
              nvidia.com/gpu: 1
              cpu: "4"
              memory: 32Gi

Betrachten Sie nvidia.com/gpu als Beispielressourcennamen für eine NVIDIA-Device-Plugin-Installation. Bestätigen Sie vor der Bereitstellung den Ressourcennamen, die Node-Labels, die Laufzeit und die Platzierungsrichtlinie in Ihrem eigenen Cluster. Verwenden Sie dieses minimale Manifest nicht als vollständige Produktionskonfiguration; es lässt bewusst Secrets, Probes, Netzwerkrichtlinien, Speicher, Autoscaling und Rollout-Kontrollen aus.

5. Stimmen Sie Warteschlangen und Batching auf das SLO ab

Beginnen Sie mit einem konservativen Warteschlangenlimit und einem expliziten Timeout. Erhöhen Sie die Batch-Größe oder die Batching-Verzögerung nur, solange die relevanten Perzentile innerhalb des Abnahmevertrags bleiben. Verwenden Sie separate Lasttests für:

• Kleine Prompts und kurze Ausgaben.
• Lange Prompts und kurze Ausgaben.
• Kurze Prompts und lange Ausgaben.
• Gemischte Mandanten mit unterschiedlichen Prioritäten.
• Langsame Clients, die einen Stream nicht mehr lesen.
• Pfade für Abbruch, Wiederholung und Worker-Ausfälle.

Wenn eine Änderung ein Profil verbessert, während sie ein anderes verschlechtert, mitteln Sie diese Unterschiede nicht einfach weg. Teilen Sie die Workloads auf, überarbeiten Sie die Zulassungsrichtlinie oder benennen Sie die Serviceklasse ehrlich.

6. Instrumentieren Sie die Schichten, nicht nur das Modell

Erfassen Sie mindestens Anfrage-IDs, Statuscodes, Modell/Version, Warteschlangendauer, Prefill-Dauer, Zeit bis zum ersten Token, Decode-Dauer, Zeit pro Ausgabetoken, Anzahlen generierter Tokens, Abbruchrate sowie GPU-/Serverzustand. Korrelieren Sie die für Clients sichtbare Latenz mit Serverphasenmetriken. So kann ein Bereitschaftsingenieur eine grundlegende, aber entscheidende Frage beantworten: Hat diese Anfrage gewartet, gerechnet, ist sie fehlgeschlagen oder wurde die Verbindung getrennt?

7. Schrittweise ausrollen und Ausfälle proben

Verwenden Sie unveränderliche Artefakte, Zustandsprüfungen, die die Modellbereitschaft testen, einen Canary-Traffic-Anteil und einen einfachen Rollback-Pfad. Testen Sie anschließend die Ausfälle, von denen Sie hoffen, dass sie nie eintreten: Fehler beim Laden des Modells, nicht verfügbarer GPU-Worker, gesättigte Warteschlange, Zeitüberschreitung einer Abhängigkeit, ungültige Modellkonfiguration und Client-Verbindungsabbruch während des Streamings.

Wenn ein einzelnes Modell das Zuverlässigkeitsziel des Workloads nicht allein erfüllen kann, entscheiden Sie im Voraus, ob der Fallback eine weitere selbst gehostete Replik, ein anderes Modell oder eine verwaltete API-Route sein soll. Dieser Leitfaden zur Modell-Fallback-Strategie kann helfen, diese Entscheidung einzuordnen.

Häufige Fehler bei der ersten Bereitstellung von KI-Inferenz durch Teams

Eine erfolgreiche Demo als Kapazitätsplan behandeln

Ein Prompt eines einzelnen Nutzers beweist, dass das Modell starten kann. Er beweist nicht, dass der Endpunkt sein Latenzziel unter Produktionsparallelität, variablen Prompt-Längen, Streaming-Clients oder bei einem ausgefallenen Worker erfüllt.

Durchsatz optimieren, bevor ein Latenzversprechen definiert ist

Größere Batches können die Hardwareauslastung verbessern, aber ein interaktives Produkt wird danach beurteilt, wie lange Nutzer warten. Definieren Sie zuerst das Perzentilziel und optimieren Sie dann das System, das es bereitstellt.

Nur die durchschnittliche Latenz messen

Ein Durchschnitt verschleiert Warteschlangenspitzen, Prompts mit langem Schwanz, Kaltstarts und Interferenzen zwischen Mandanten. Verwenden Sie Perzentile und phasenspezifische Metriken. Ein schneller Mittelwert ist kein Beleg dafür, dass die langsamste Nutzererfahrung akzeptabel ist.

KV-Cache-Verhalten ignorieren

Die Tokengenerierung ist innerhalb einer Sequenz zustandsbehaftet. Cache-Belegung, Kontextlänge, Parallelität, Wiederverwendungsrichtlinie und Eviction-Verhalten können die reale Last entscheidend beeinflussen, selbst wenn eine reine Gewichts-Speicherschätzung komfortabel erschien.

Hardware zur ersten Entscheidung machen

Hardware ist wichtig, aber Modellformat, Serving-Engine, Anfrageverteilung, Batching-Richtlinie, Topologie und Beobachtbarkeit verändern das Ergebnis. Messen Sie den Workload, bevor Sie eine GPU-Konfiguration als „schnell genug“ bezeichnen.

FAQ zur KI-Inferenz

Ist KI-Inferenz dasselbe wie eine KI-Modell-API?

Nein. KI-Inferenz bedeutet, dass das Modell auf neuen Eingaben ausgeführt wird. Eine KI-Modell-API ist eine Möglichkeit, auf Inferenz zuzugreifen. Der API-Anbieter kann die Serving-Infrastruktur für Sie betreiben, oder Sie stellen Ihren eigenen Inferenzserver hinter einer API bereit.

Verändert Inferenz das Modell?

Gewöhnliche Inferenz aktualisiert keine Modellgewichte. Training und Fine-Tuning tun dies. Ein System kann Inferenzergebnisse zur späteren Bewertung oder zum Training protokollieren, aber das ist ein separater Workflow mit eigenen Daten- und Governance-Entscheidungen.

Warum wird LLM-Inferenz in Prefill und Decode aufgeteilt?

Prefill verarbeitet den Prompt-Kontext, während Decode Ausgabetokens sequenziell erzeugt. Die Phasen belasten ein Serving-System unterschiedlich, weshalb TTFT und die Taktung der Ausgabetokens getrennt gemessen werden sollten.

Benötige ich Cloud-GPUs für KI-Inferenz?

Nicht immer. Einige Workloads laufen auf CPUs, Edge-Beschleunigern oder über eine verwaltete Modell-API. Cloud-GPUs sind relevant, wenn Ihr Modell, Latenzziel, Durchsatzbedarf oder Ihre Serving-Konfiguration GPU-Beschleunigung erfordert und Sie diese Infrastruktur betreiben möchten.

Was sollte ich zuerst überwachen?

Beginnen Sie mit erfolgreichen Anfragen, Fehlern, Wartezeit, TTFT, Zeit pro Ausgabetoken, End-to-End-Latenz, Anzahlen generierter Tokens sowie GPU-/Serverzustand. Ergänzen Sie modellspezifische Cache- und Scheduler-Metriken, sobald Ihre Serving-Engine diese bereitstellt.

Setzen Sie die Definition in die Praxis um

Die praktische Bedeutung von KI-Inferenz ist einfach: Ein trainiertes Modell wird auf neuen Eingaben ausgeführt und erzeugt eine Ausgabe. Die technische Arbeit besteht darin, diese Ausgabe unter realem Traffic zeitnah, beobachtbar, wirtschaftlich und robust bereitzustellen.

Beginnen Sie damit, das Anfrageprofil und die Abnahmemetriken zu dokumentieren. Wählen Sie eine verwaltete API, wenn sie das Maß an Kontrolle bietet, das Ihr Workload benötigt; wählen Sie Cloud-GPU-Inferenz, wenn Sie einen gemessenen Grund haben, den Serving-Pfad selbst zu verantworten. Machen Sie dann Prefill, Decode, Warteschlangenbildung, Cache-Zustand und Fehlerbehandlung sichtbar, bevor Sie optimieren.

Wenn einige Workloads besser über eine API als über selbst gehostete GPUs bedient werden, erkunden Sie den Modellkatalog von Flatkey oder vergleichen Sie die Architekturoptionen im Leitfaden zu GPU-Cloud vs. Modell-API.

Weiterführende Literatur

• NVIDIA: Was ist KI-Inferenz?
• NVIDIA Triton: Batcher
• vLLM: Produktionsmetriken
• Kubernetes: GPUs einplanen
• NVIDIA TensorRT: KV-Cache