vLLM-Community: Autarke Multi-GPU-Inference für lokale Coding-Agenten
Kurzfassung
Die vLLM-Community diskutiert aktuell vor allem Themen rund um die Optimierung der Inference auf Consumer-GPUs, die Verbesserung der Tool-Calling-Fähigkeiten und die Erweiterung der Kontextlänge. Besonders relevant für Autarkie-Setups sind Diskussionen über Quantisierung, Prefix-Caching und die Integration von Modellen wie Qwen3 und Mistral. Diese Entwicklungen können helfen, ein lokales KI-Setup auf 4x 3090 oder 2x 5090 in Richtung Claude-Sonnet/Niveau zu bringen.
Structured Generation with Reasoning Parser in offline mode. (8/10) — OpenCode-Fit: BEDINGT
Worum geht es konkret?
Die Diskussion dreht sich um die Möglichkeit, das Reasoning-Parser-Feature von Qwen 3 in offline-Modus zu verwenden. Der Nutzer möchte, dass das Modell erst über die Anfrage nachdenkt und dann eine strukturierte JSON-Antwort generiert. Derzeit funktioniert dies nicht, da das Reasoning-Parser-Feature in offline-Modus nicht verfügbar ist.
Was heisst das für ein autarkes Home-Setup (4x 3090 / 2x 5090 / Mac Studio)?
Diese Funktion wäre sehr nützlich für ein autarkes Home-Setup, da sie die Qualität der Antworten verbessern und die Tool-Calling-Fähigkeiten erhöhen würde. Allerdings ist derzeit ein Workaround notwendig, da das Feature in offline-Modus nicht unterstützt wird. Für Consumer-GPUs wie 3090 oder 5090 wäre dies ein wichtiger Schritt, um die Agent-Fähigkeiten zu verbessern.
Konsequenz für OpenCode-Nutzer:
Die Implementierung des Reasoning-Parser-Features würde die Qualität der Antworten und die Tool-Calling-Fähigkeiten verbessern. Aktuell müssen Nutzer alternative Methoden finden, um ähnliche Funktionen zu erreichen, was die Effizienz reduziert.
Handlungsempfehlung:
Beobachten, ob das Feature in zukünftigen vLLM-Versionen implementiert wird. Bis dahin können Nutzer Workarounds anwenden, wie z.B. die Verwendung von externen Tools zur Strukturierung der Antworten.
Fakten-Tabelle:
– Hardware im Post: nicht im Post belegt
– Modell: Qwen 3
– Framework-Version: nicht im Post belegt
– tok/s / Benchmark: nicht im Post belegt
– Multi-GPU-Konfiguration: nicht im Post belegt
Running Llama4 quantized on 2xH100 80GB (4/10) — OpenCode-Fit: NEIN
Worum geht es konkret?
Der Nutzer versucht, Llama4 mit fp8 oder experts_int8 Quantisierung auf 2x H100 GPUs zu laufen. Er stößt auf CUDA Out of Memory-Fehler, obwohl int8 Quantisierung normalerweise die VRAM-Anforderungen halbieren sollte.
Was heisst das für ein autarkes Home-Setup (4x 3090 / 2x 5090 / Mac Studio)?
Diese Diskussion ist nicht direkt relevant für Consumer-GPUs wie 3090 oder 5090, da sie sich auf H100 GPUs konzentriert. Die VRAM-Grenzen von 24 GB pro GPU bei 3090/5090 machen es schwierig, große Modelle wie Llama4 zu betreiben, selbst mit Quantisierung. Für Home-Setups sind kleinere Modelle oder alternative Quantisierungsmethoden wie INT4 oder FP8 für kleinere Modelle relevanter.
Konsequenz für OpenCode-Nutzer:
Für Nutzer mit 3090/5090 ist diese Diskussion weniger relevant. Es ist ratsam, sich auf kleinere Modelle oder alternative Quantisierungsmethoden zu konzentrieren, die besser mit der verfügbaren VRAM umgehen.
Handlungsempfehlung:
Fokus auf kleinere Modelle oder alternative Quantisierungsmethoden wie INT4 oder FP8. Beobachten, ob zukünftige vLLM-Versionen bessere Unterstützung für Quantisierung auf Consumer-GPUs bieten.
Fakten-Tabelle:
– Hardware im Post: 2x H100 80GB
– Modell: Llama4
– Framework-Version: nicht im Post belegt
– tok/s / Benchmark: nicht im Post belegt
– Multi-GPU-Konfiguration: nicht im Post belegt
Determining Overall Speed for One Long Prompt (7/10) — OpenCode-Fit: JA
Worum geht es konkret?
Der Nutzer möchte die Gesamtgeschwindigkeit für lange Prompts messen, aber vLLM gibt mehrere Geschwindigkeitsmessungen zurück, da es die Anfrage in mehrere Batches aufteilt. Er sucht nach einer Möglichkeit, die Gesamtgeschwindigkeit für die gesamte Anfrage zu erhalten.
Was heisst das für ein autarkes Home-Setup (4x 3090 / 2x 5090 / Mac Studio)?
Diese Funktion ist wichtig für Nutzer, die lange Prompts verarbeiten müssen, da sie eine genaue Messung der Leistung ermöglicht. Für 4x 3090 oder 2x 5090 ist es hilfreich, die Gesamtgeschwindigkeit zu kennen, um die Effizienz des Setups zu optimieren. Die Deaktivierung des Prefix-Caching sorgt dafür, dass jede Anfrage frisch verarbeitet wird, was die Messung präziser macht.
Konsequenz für OpenCode-Nutzer:
Eine genaue Messung der Gesamtgeschwindigkeit hilft, die Leistung des Setups zu optimieren und ineffiziente Konfigurationen zu identifizieren. Dies ist besonders nützlich für Agent-Workloads, bei denen die Verarbeitungslänge variieren kann.
Handlungsempfehlung:
Auf PRs warten, die die Gesamtgeschwindigkeitsmessung implementieren. Bis dahin können Nutzer die durchschnittliche Geschwindigkeit über mehrere Batches berechnen, um eine Schätzung zu erhalten.
Fakten-Tabelle:
– Hardware im Post: nicht im Post belegt
– Modell: Qwen/Qwen3-30B-A3B-FP8
– Framework-Version: v0.8.5, v0.8.2
– tok/s / Benchmark: 41.1 tokens/s, 19.8 tokens/s, 77.6 tokens/s
– Multi-GPU-Konfiguration: –tensor-parallel-size 2
I just published a performance test result of vllm vs sglang but can someone help me explain it? (6/10) — OpenCode-Fit: BEDINGT
Worum geht es konkret?
Der Nutzer hat eine Leistungstests von vLLM und SGLang durchgeführt, wobei SGLang deutlich bessere Ergebnisse erzielt hat. Er verwendet eine A10 GPU und das Modell Qwen 2.5-7B. SGLang verwendet nur 7 GB VRAM, während vLLM 21 GB VRAM benötigt, und liefert konsistente Antwortzeiten.
Was heisst das für ein autarkes Home-Setup (4x 3090 / 2x 5090 / Mac Studio)?
Diese Diskussion ist relevant, da sie zeigt, dass es Alternativen zu vLLM gibt, die effizienter mit der verfügbaren VRAM umgehen. Für Nutzer mit 3090 oder 5090 ist es wichtig, die VRAM-Verwendung zu optimieren, um größere Modelle zu betreiben. SGLang könnte eine interessante Alternative sein, die die VRAM-Effizienz verbessert.
Konsequenz für OpenCode-Nutzer:
Die VRAM-Effizienz ist entscheidend für die Betriebstauglichkeit von Modellen auf Consumer-GPUs. Nutzer sollten alternative Frameworks wie SGLang in Betracht ziehen, um die VRAM-Verwendung zu reduzieren und die Leistung zu verbessern.
Handlungsempfehlung:
Testen von SGLang auf dem eigenen Setup, um die VRAM-Verwendung und die Leistung zu vergleichen. Beobachten, ob zukünftige vLLM-Versionen die VRAM-Effizienz verbessern.
Fakten-Tabelle:
– Hardware im Post: A10 GPU
– Modell: Qwen 2.5-7B
– Framework-Version: vLLM, SGLang
– tok/s / Benchmark: nicht im Post belegt
– Multi-GPU-Konfiguration: nicht im Post belegt
How to increase context length and make things work (7/10) — OpenCode-Fit: JA
Worum geht es konkret?
Der Nutzer hat Probleme damit, die Kontextlänge in vLLM zu erhöhen. Er verwendet das Modell Qwen1.5-72B-Chat-GPTQ-Int4 auf einer H100 80GB GPU und stößt auf Fehler, wenn er die Kontextlänge auf 16384 erhöhen möchte. Die KV-Cache-Grenzen und die VRAM-Beschränkungen sind die Hauptprobleme.
Was heisst das für ein autarkes Home-Setup (4x 3090 / 2x 5090 / Mac Studio)?
Die Erhöhung der Kontextlänge ist wichtig für Agent-Workloads, bei denen lange Kontexte notwendig sind. Für 4x 3090 oder 2x 5090 ist es schwierig, die Kontextlänge auf 16384 zu erhöhen, da die VRAM-Beschränkungen von 24 GB pro GPU erreicht werden. Es ist ratsam, die Kontextlänge und den Batch-Size zu optimieren, um die VRAM-Effizienz zu verbessern.
Konsequenz für OpenCode-Nutzer:
Die Kontextlänge und der Batch-Size beeinflussen die VRAM-Verwendung und die Leistung. Nutzer sollten experimentieren, um die optimalen Einstellungen für ihr Setup zu finden, um die Kontextlänge zu erhöhen, ohne die VRAM-Grenzen zu überschreiten.
Handlungsempfehlung:
Experimentieren mit der Kontextlänge und dem Batch-Size, um die VRAM-Effizienz zu optimieren. Beobachten, ob zukünftige vLLM-Versionen bessere Unterstützung für längere Kontexte bieten.
Fakten-Tabelle:
– Hardware im Post: H100 80GB
– Modell: Qwen1.5-72B-Chat-GPTQ-Int4
– Framework-Version: v0.3.3, v0.4.0
– tok/s / Benchmark: nicht im Post belegt
– Multi-GPU-Konfiguration: nicht im Post belegt
How to benchmark vLLM a short tutorial (5/10) — OpenCode-Fit: BEDINGT
Worum geht es konkret?
Der Nutzer bietet einen kurzen Tutorial, wie man vLLM auf einem Kubernetes-Cluster benchmarkt. Er verwendet das Modell Llama 3.1 8B Instruct in FP8-Modus und zeigt, wie man die Benchmarking-Skripte von vLLM verwendet, um die Leistung zu messen.
Was heisst das für ein autarkes Home-Setup (4x 3090 / 2x 5090 / Mac Studio)?
Diese Diskussion ist weniger relevant für autarke Home-Setups, da sie sich auf Kubernetes-Cluster konzentriert. Allerdings können die Benchmarking-Methoden auch auf lokalen Setups angewendet werden, um die Leistung zu optimieren. Für 4x 3090 oder 2x 5090 ist es hilfreich, die Leistung zu messen, um ineffiziente Konfigurationen zu identifizieren.
Konsequenz für OpenCode-Nutzer:
Die Benchmarking-Methoden helfen, die Leistung des Setups zu optimieren und ineffiziente Konfigurationen zu identifizieren. Nutzer können die gleichen Skripte auf ihren lokalen Setups anwenden, um die Leistung zu messen.
Handlungsempfehlung:
Anwenden der Benchmarking-Methoden auf dem eigenen Setup, um die Leistung zu optimieren. Beobachten, ob zukünftige vLLM-Versionen bessere Benchmarking-Tools bieten.
Fakten-Tabelle:
– Hardware im Post: Kubernetes-Cluster mit 24GB GPU
– Modell: Llama 3.1 8B Instruct
– Framework-Version: v0.5.3.post1
– tok/s / Benchmark: nicht im Post belegt
– Multi-GPU-Konfiguration: –tensor-parallel-size 1
Weitere Diskussionen (kurz):
– vLLM cannot connect to existing Ray cluster — Enterprise — nicht autark-relevant
– ……lib/python3.12/site-packages/vllm/_C.abi3.so: undefined symbol: _ZN5torch3jit17parseSchemaOrNameERKSsb — Technisches Problem, relevant für Entwickler
– Any known integration with n8n? — Spezifisches Tool-Integration, relevant für Nutzer von n8n
– Why temperature=0,top_p=1,seed=42 is still not enough to fix the llm’s output!? — Probleme mit der Konsistenz der Ausgaben, relevant für Nutzer mit spezifischen Anforderungen
– How to: custom attention mask? Specifically, bidirectional attention for context. — Technisches Problem, relevant für Entwickler
– How to only download model without serving it? — Technisches Problem, relevant für Entwickler
– Why do vllm set default keep-alive timeout to 5s? — Technisches Problem, relevant für Entwickler
– How does the profile_run work? — Technisches Problem, relevant für Entwickler