Türkei (Türkisch)
Germany (German)
Worldwide (English)
Fokus auf einfache lokale Modellausführung und Developer Experience.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Ein einzelner tokens/s-Screenshot vergleicht keine drei Engines. Ollama fokussiert einfache lokale Nutzung, vLLM High-Throughput OpenAI-kompatibles Serving, SGLang fortgeschrittene Runtime-/Cache-Optimierungen. Keine Performance-Zahlen ohne identisches Modell, Quantization und GPU.
Der Generator erzeugt ein Testprotokoll, keine Performance-Ergebnisse. Resultate nur mit identischem Modell, Quantization, Kontext, GPU, Treiber und Thermik eintragen.
Ollama kann bei einfachem lokalem Developer-Workflow überzeugen. vLLM ist stark für Multi-User OpenAI-kompatibles Serving. SGLang lohnt bei prefix-lastigen Agent/RAG-Workloads und fortgeschrittener Serving-Optimierung. Mit eigener Prompt-Verteilung benchmarken.
Ollama kann bei einfachem lokalem Developer-Workflow überzeugen. vLLM ist stark für Multi-User OpenAI-kompatibles Serving. SGLang lohnt bei prefix-lastigen Agent/RAG-Workloads und fortgeschrittener Serving-Optimierung. Mit eigener Prompt-Verteilung benchmarken.
Ollama, vLLM und SGLang fair auf derselben GPU/demselben Modell vergleichen: Bedienung, OpenAI API, Batching, Prefix Cache, Multi-GPU und reproduzierbarer Benchmark.
Fokus auf einfache lokale Modellausführung und Developer Experience.
Fokus auf Continuous Batching und OpenAI-kompatibles Serving.
Bietet fortgeschrittene Serving-Optimierungen inkl. Prefix-orientiertem Caching.
Hardware, Modell und Quantization müssen über Engines konstant bleiben.
Local Chat, ein API-Client, 100 parallele Nutzer und agentisches RAG stellen unterschiedliche Anforderungen an Serving Engines.
| Profil | Priorität | Erster Kandidat |
|---|---|---|
| Local Developer | Setup-Einfachheit | Ollama |
| OpenAI API / Multi-User | Throughput + Batching | vLLM |
| Agent/RAG repeated prefix | Prefix-/Cache-Effizienz | SGLang / vLLM |
| Model Lab | Schneller Modellwechsel | Ollama / vLLM |
„OpenAI-kompatibel“ bedeutet nicht identische Vendor-Funktionen. Chat, Responses, Embeddings, Tool Calling und Structured Outputs separat testen.
KV-Cache-Allokation, CUDA Graphs, Kernels und Runtime-Overhead unterscheiden sich. Peak-VRAM + OOM-Marge statt nur „passt“ messen.
watch -n 0.5 nvidia-sminvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csvWiederholte System-Prompts, Tool-Schemas und RAG-Kontext können Prefix-Cache-Verhalten produktiv entscheidend machen.
| Test | Input Pattern |
|---|---|
| Cold | Jeder Request andere 4k |
| Warm Prefix | Gleicher 4k-Prefix + 256 unique |
| RAG | 8k gemeinsame Docs + Frage |
Ergebnisse sind ungültig bei unterschiedlicher Prompt-Verteilung. Prompt-Corpus fixieren und SHA256 protokollieren.
sha256sum benchmark-prompts.jsonlnvidia-smi --query-gpu=name,driver_version,memory.total,temperature.gpu,power.draw --format=csv2×GPU-Throughput / 1×GPU-Throughput zusammen mit Latenzänderung berichten. Gesamt-tok/s allein kann Interconnect-Overhead verbergen.
| Engine | 1 GPU tok/s | 2 GPU tok/s | Skalierung |
|---|---|---|---|
| Ollama | — | — | — |
| vLLM | — | — | — |
| SGLang | — | — | — |
Deployment-Einfachheit, API-Kompatibilität, p95-Latenz, Throughput, VRAM-Headroom, Observability und Upgrade-Risiko workloadbezogen gewichten.
Concurrency und Prompt-Profil wählen, um reproduzierbare Testmatrix zu erzeugen.
Auf Eka Sunucu GPU-Server Ollama, vLLM und SGLang unter identischen Modell-/Treiberbedingungen benchmarken.
Primärdokumentation und technische Referenzen dieses Leitfadens.
Mit passenden Infrastruktur- und Implementierungsleitfäden fortfahren.
LLM-Serving-Vergleich
Ohne fixes Modell, Quantization, GPU, Prompts und Concurrency keine allgemeingültige Antwort. vLLM zielt auf High-Throughput, trotzdem eigenen Workload messen.
Bei Agent/RAG-Workloads mit wiederholten Prefixes und fortgeschrittenen Serving-Optimierungen lohnt ein Test.
Format-Support unterscheidet sich. Möglichst äquivalente Weights/Quantization nutzen und Formatunterschiede offenlegen.
Nein. Er erzeugt reproduzierbare Testbedingungen; echte Resultate müssen auf GPU-Server gemessen werden.