Note 02 / Inferenz · Betrieb
Llama auf GPU: Speicher planen, dann messen
Modellgewichte sind nur ein Teil des Speichers. KV-Cache, Kontext und Laufzeit prüfen, bevor Sie eine Serving-Konfiguration auswählen.
Passt das Modell wirklich auf die GPU?
Ein Modellname und die Bitbreite der Quantisierung reichen nicht aus, um einen zuverlässigen Serverbetrieb zu planen. Neben Gewichten belegen Quantisierungsmetadaten, Aktivierungen, Laufzeitpuffer und der KV-Cache Speicher. Kontextlänge und gleichzeitig aktive Anfragen verändern den Bedarf. Die L40S ist dabei ein mögliches Zielgerät, keine Garantie für eine bestimmte Modellkonfiguration.
Eine Untergrenze berechnen
Die folgende Rechnung betrachtet ausschließlich idealisiert gespeicherte Gewichte. Sie hilft, unplausible Annahmen früh zu erkennen. Sie modelliert weder den tatsächlichen Checkpoint noch die Speicherbelegung von vLLM. GB und GiB dürfen bei der weiteren Planung nicht vermischt werden.
from decimal import Decimal
def weight_lower_bound_gib(parameters, bits):
if parameters <= 0 or bits <= 0:
raise ValueError("parameters and bits must be positive")
# Nur Gewichte: kein KV-Cache, keine Puffer oder Metadaten.
weight_bytes = Decimal(parameters) * Decimal(bits) / 8
return weight_bytes / (Decimal(1024) ** 3)
# Rechenbeispiel, keine Messung des GPU-Speicherverbrauchs.
estimate = weight_lower_bound_gib(70_000_000_000, 4)
assert Decimal("32") < estimate < Decimal("33")
Checkpoint und Laufzeit gemeinsam prüfen
Halten Sie Modellrevision, Tokenizer, Quantisierungsformat, vLLM-Version, GPU und Treiber fest. Prüfen Sie die Kompatibilität in der Dokumentation dieser Version. GGUF, AWQ und GPTQ sind unterschiedliche Formate; eine Bezeichnung aus llama.cpp ist keine automatisch passende vLLM-Konfiguration. Der GGUF-Support von vLLM ist laut aktueller Dokumentation experimentell und in ein separates Plugin ausgelagert.
Beginnen Sie mit einer begrenzten Kontextlänge und kontrollierter Parallelität. Erfassen Sie Speicher bei Start, während der Vorverarbeitung und während der Token-Erzeugung. Testen Sie auch lange Eingaben und Abbrüche. Ein erfolgreicher Modellstart zeigt nicht, dass Lastspitzen oder lange Kontexte stabil verarbeitet werden.
Einen reproduzierbaren Messplan anlegen
Definieren Sie die Messgrenzen: Time-to-First-Token bis zum ersten sichtbaren Token, Gesamtdauer bis zum letzten Token und Fehlerrate getrennt. Halten Sie Promptlängen, Antwortbegrenzung, Parallelität, Warm-up und Wiederholungen fest. Vergleichen Sie Quantisierungen mit demselben Eval-Set; geringerer Speicherbedarf kann die Antwortqualität verändern.
Was hier tatsächlich geprüft wurde
Der lokale Python-Test prüft die Rechenfunktion und ungültige Eingaben. Es wurde kein GPU-Benchmark durchgeführt. Diese Note enthält deshalb keine Latenz-, Durchsatz- oder Qualitätswerte und keinen behaupteten optimalen vLLM-Parameter. Auch eine zweite GPU ist keine automatische Hochverfügbarkeitslösung: Ein gemeinsamer Host bleibt ein gemeinsamer Ausfallpunkt.