Einzelentwickler: Coding-Assistant auf einem MacBook
Setup: Mac Studio M2 Ultra + Ollama + Claude Code über Tokios Modell: Qwen3-30B Q5_K_M Zeit bis zur ersten funktionierenden Einrichtung: 20 Minuten Ein einzelner Full-Stack-Entwickler wollte einen Coding-Assistenten, der den Quellcode auf seiner Maschine behält. Er betreibt Ollama auf einem Mac Studio M2 Ultra mit 64 GB Unified Memory und leitet Claude Code über Tokios darauf.
Was funktioniert hat: Die Speicherbandbreite des M2 Ultra bewältigt das 30B-Modell gut. Tokios bedeutet, dass dieselbe Einrichtung auch von einem Laptop unterwegs funktioniert — verweisen Sie einfach Claude Code auf
api.tokios.com.
Einschränkung: Die Kontextlänge liegt bei diesem Modell bei etwa 8K Token. Bei großen Codebasen mit vielen geöffneten Dateien unterteilen die Entwickler die Arbeit in kleinere Sitzungen, anstatt gesamte Repositories zu übergeben.
Wichtigste Erkenntnis: Wenn Sie bereits Apple Silicon mit 32 GB+ RAM besitzen, kostet ein lokaler Coding-Assistent $0/Monat und hält Ihren Code privat. Tokios fügt Remote-Zugriff ohne VPN hinzu.
Kleines Team: gemeinsamer Modell-Endpunkt für 5 Entwickler
Einrichtung: RTX 4090 Workstation + vLLM + Tokios Connector Modell: Qwen3-72B FP8 (AWQ-Quantisierung) Zeit bis zur ersten funktionierenden Einrichtung: 45 Minuten Ein 5-köpfiges Backend-Team teilt sich eine einzelne RTX 4090 Workstation als Team-Modellserver. Sie verwenden vLLM für den Durchsatz und Tokios, um jedem Entwickler einen eingegrenzten API-Schlüssel zu gewähren.
Was funktioniert hat: Konsolter Modellzugriff ohne Ratenbegrenzungen. Scoped Keys bedeuten, dass jeder Entwickler seinen eigenen
sk-tok-…-Schlüssel hat — das Widerrufen eines Schlüssels betrifft nicht die anderen.
Zu beachten: Das 72B AWQ-Modell passt kaum in 24 GB VRAM. Während Spitzenzeiten bei gleichzeitiger Nutzung speichert vLLM den KV-Cache in den CPU-Speicher aus, was den Durchsatz verlangsamt. Das Team hat --max-num-seqs 8 hinzugefügt, um gleichzeitige Anfragen zu begrenzen und OOM-Crashs zu verhindern.
Was sie ändern würden: Wechseln Sie zu einem 48 GB A6000 oder fügen Sie eine zweite GPU für Tensor-Parallelität hinzu. Siehe Tensor- vs. Pipeline-Parallelität.
Wesentliche Erkenntnis: Eine einzelne Consumer-GPU kann ein kleines Team bedienen, planen Sie jedoch für Spitzenlasten. Begrenzen Sie
--max-num-seqs, um OOM zu verhindern, und akzeptieren Sie eine höhere Latenz unter Last.Homelab-Enthusiast: DGX Spark als durchgehend laufender Inference-Server
Setup: DGX Spark + vLLM + Tokios + Tailscale (für LAN-Zugang) Modelle: Rotierende Sammlung — Qwen3-30B für den täglichen Gebrauch, DeepSeek-R1 für Reasoning-Aufgaben, Phi-4 für schnelle Klassifizierung Zeit bis zur ersten funktionierenden Einrichtung: 1 Stunde (inklusive Modell-Downloads) Ein Homelab-Hobbybastler betreibt einen DGX Spark 24/7 als persönlichen Inference-Server. Der 128 GB Unified Memory ermöglicht es ihm, ein großes Modell geladen zu halten und andere bei Bedarf auszutauschen. Tokios stellt Modelle für ihr Telefon, Laptop und Home-Automation-Skripte zur Verfügung.
Was funktioniert hat: Der 128 GB Unified Memory des DGX Spark passt zu Modellen, für die 2–3 Consumer-GPUs nötig wären. Das Ausführen mehrerer vLLM-Instanzen auf verschiedenen Ports ermöglicht es, 3 Modelle gleichzeitig zu bedienen. Die Modellweiterleitung von Tokios bedeutet, dass die Telefon-App einfach das
model Feld ändert, um zwischen täglichem Chat und tiefgehender Reasoning zu wechseln.
Tipp: Verwenden Sie Modellweiterleitung, um automatisch eine Deployment basierend auf dem Anfragetyp auszuwählen. Richten Sie Chat-Clients auf daily und Automatisierungsskripte auf classifier ein.
Wichtigste Erkenntnis: Ein DGX Spark als Always-on-Server kostet $8–15/Monat an Strom und bietet unbegrenzte Inferenz bei Modellen, die nicht auf Consumer-Hardware passen. Der 128 GB Unified Memory ist der eigentliche Unterschied.
Start-up: Lokale Modelle zur Verarbeitung von Kundendaten
Einrichtung: 2x A100 80 GB + vLLM + Tokios Modelle: Llama 3.1 70B für die Analyse, Phi-4 für die Klassifizierung Zeit bis zur ersten funktionierenden Einrichtung: 2 Stunden (inklusive Infrastruktur) Ein 10-köpfiges Start-up verarbeitet Kundendokumente, die sensible Finanzdaten enthalten. Compliance-Vorschriften verlangen, dass die Daten ihre Infrastruktur niemals verlassen. Sie betreiben 2 separate vLLM-Instanzen — 1 für die Analyse, 1 für die Klassifizierung — und stellen beide über Tokios zur Verfügung.
Architektur: Ihre Verarbeitungspipeline sendet Dokumente an die
analyzer-Deployment zur Zusammenfassung und Entitätsextraktion, leitet dann die extrahierten Felder an die classifier-Deployment zur Kategorisierung weiter. Beide Modelle laufen auf separaten A100s, um VRAM-Konflikte zu vermeiden.
Was gut lief: Separate Deployments für verschiedene Aufgaben bedeuten, dass sie unabhängig skaliert, neu gestartet oder Modelle ausgetauscht werden können. Die Tokios-Scoped-Keys beschränken den Verarbeitungsdienst auf nur die analyzer- und classifier-Deployments.
Was sie ändern würden: Ein 3-tes Modell für Qualitätsprüfungen hinzufügen. Die aktuelle 2-Modelle-Pipeline klassifiziert gelegentlich Grenzfälle falsch, die ein größeres Reasoning-Modell erkennen würde.
Wichtigste Erkenntnis: Wenn Compliance On-Premises-Daten erfordert, amortisieren sich lokale Modelle schnell. Separate Deployments pro Aufgabe bieten unabhängige Skalierung und Fehlerisolierung. Dieses Startup erreichte den Break-even in 3 Monaten im Vergleich zu Cloud-GPU-Kosten.
Forscher: Benchmarking über verschiedene Quantisierungen hinweg
Setup: RTX 4090 + llama.cpp + lm-evaluation-harness Testing: Dasselbe Modell (Qwen2.5-7B) bei Q4_K_M, Q5_K_M, Q8-0, FP16 Zeit für vollständige Benchmark-Suite: 3 Stunden Ein ML-Forscher musste messen, wie sich die Quantisierung auf die Bewertungswerte für eine bestimmte Aufgabe (Code-Generierung) auswirkt. Er führte dasselbe Modell bei 4 Quantisierungsstufen aus und vergleicht Perplexität und Durchlaufraten.
Finding: Q5_K_M erzielte innerhalb von 2.2 Prozentpunkten die gleiche Leistung wie FP16, lief dabei jedoch fast doppelt so schnell. Für die Codegenerierungsaufgaben dieses Forschers ist Q5_K_M die optimale Wahl.
How Tokios helped: Die Registrierung jeder Quantisierung als separate Deployment (
bench-q4km, bench-q5km, bench-q8, bench-fp16) ermöglichte es der Evaluierungs-Harness, zwischen ihnen zu wechseln, indem nur das model-Feld geändert wurde. Die Ergebnisse waren direkt vergleichbar, da die Harness für jeden Lauf dieselbe Endpunkt-Struktur aufrufte.
Key takeaway: Q5_K_M ist die optimale Wahl für die meisten 7B-Evaluierungsaufgaben — innerhalb von 2–3% der FP16-Qualität bei nahezu 2x der Geschwindigkeit. Registrieren Sie jede Quantisierung als separate Tokios-Deployment, um sie über eine konsistente API zu benchmarken.
Gemeinsame Muster in allen Fallstudien
Nächste Schritte
Rezepte
Copy-paste-Konfigurationen für 8 gängige lokale LLM-Setups.
Ihre Deployment-Leistung benchmarken
Strukturierte Benchmarks zum Vergleichen Ihrer Hardware- und Modellentscheidungen.
Modell-Routing
Registrieren Sie mehrere Deployments und wechseln Sie zwischen ihnen.
Wählen Sie ein lokales Modell
Wählen Sie das richtige Modell und die Quantisierung für Ihre Hardware.