Informationen über diDie vier Hauptursachen
1. Hardware-Klasse
┌─────────────────────┬────────────────────────────────────────────────────┬────────────────────────────┐
│ │ Anthropic (Claude) │ Heimetli (Qwen2.5-neo 14B) │
├─────────────────────┼────────────────────────────────────────────────────┼────────────────────────────┤
│ Compute │ Tausende H100/H200 GPUs + custom Inferenz-Hardware │ 8 vCPU AMD EPYC, keine GPU │
├─────────────────────┼────────────────────────────────────────────────────┼────────────────────────────┤
│ Speicher-Bandbreite │ ~3 TB/s HBM │ ~50 GB/s DDR4 │
├─────────────────────┼────────────────────────────────────────────────────┼────────────────────────────┤
│ Faktor │ Baseline │ ~60× langsamer │
└─────────────────────┴────────────────────────────────────────────────────┴────────────────────────────┘
Bei LLM-Inferenz limitiert primär die Memory-Bandbreite — das Modell muss für jedes Token komplett aus dem RAM gelesen werden. GPUs haben HBM (High Bandwidth Memory), CPUs nur normalen
DDR. Allein das ist ein Faktor 30-60×.
2. Modellgröße + Architektur
- Claude Sonnet/Opus: vermutlich 200B-500B Parameter, voll-präzise (FP16/FP8) auf spezialisierter Hardware
- Qwen2.5-neo: 14B Parameter, Q4_K_M quantisiert (4-Bit, lossy) — also ~30× kleiner UND qualitätsreduziert
Kleiner heisst zwar potenziell schneller, aber: ein 14B-Modell ist viel weniger fähig, es "denkt" mehr bei komplexen Tool-Wahlen, macht Fehlentscheidungen, braucht mehr Iterationen.
3. Prompt-Eval vs Generation
Das ist der entscheidende Punkt für diesen Fall.
┌─────────────────────────────────────────────────────────────────────────┬──────────────┬────────────┬────────┐
│ Phase │ Heimetli CPU │ Claude API │ Faktor │
├─────────────────────────────────────────────────────────────────────────┼──────────────┼────────────┼────────┤
│ Prompt-Eval (3000 input tokens, also dein System-Prompt + 24 Tool-Defs) │ ~75s │ ~0.5s │ 150× │
├─────────────────────────────────────────────────────────────────────────┼──────────────┼────────────┼────────┤
│ Generation (50 output tokens Antwort) │ ~8s │ ~1s │ 8× │
├─────────────────────────────────────────────────────────────────────────┼──────────────┼────────────┼────────┤
│ Total │ ~83s │ ~1.5s │ 55× │
└─────────────────────────────────────────────────────────────────────────┴──────────────┴────────────┴────────┘
Bei den 10s-Anthropic-Calls verbringt das System die meiste Zeit mit Netzwerk + Anthropic's Batching-Warteschlange, nicht mit Compute. Das echte Compute ist <2s. Bei einem lokalen Beispiel auf CPU sind die
75s reines Rechnen — und das Problem skaliert linear mit der Input-Länge.
4. Wie Anthropic den Prompt-Eval kostengünstig hält
Anthropic batched deinen Request mit Hunderten anderen gleichzeitig auf derselben GPU. Die Tool-Definitionen + System-Prompt sind oft auch gecacht (Prompt Caching) — der gleiche
System-Prompt wird nicht jedes Mal neu evaluiert, sondern aus dem KV-Cache geholt. Effektive Kosten: ein paar Cents. Effektive Zeit: Millisekunden.
Ollama Lokal macht das nicht — jeder Request startet bei 0, jeder Token wird neu berechnet, kein Sharing.
Warum unser Intent-Router trotzdem das richtige tut:
Wir können Anthropic nicht schlagen, aber wir können das Problem umgehen, indem wir das LLM aus dem heissen Pfad nehmen:
- Heute: 3000 Input-Tokens × CPU-Eval = 75s Prompt-Eval, dann Generation
- Mit Intent-Router:
- Embedding der Frage: 50ms (mxbai-embed-large ist klein und schnell)
- pgvector Lookup: ~10ms
- Tool-Ausführung (account_find_moves, direkter Postgres-Read): ~100ms
- LLM-Call nur für Antwort-Formulierung mit 200 Input-Tokens (Tool-Output + Kurzer Prompt): ~5s
- Gesamt: ~5-6s statt 75s+
Das ist immer noch nicht Anthropic-schnell, aber 12× schneller als heute. Und unter den 10s die man beim Anthropic-Call gewohnt ist.
Was Anthropic-Niveau lokal kosten würde
Realistisch:
- GPU-Server mit RTX 4090 (24 GB VRAM): ~3000-4000 CHF, würde Qwen2.5-14B in ~10-20 Tokens/s laufen lassen statt ~5-8. Faktor 3×.
- H100 in der Cloud: ~3-5 USD/Stunde. Wird Qwen 14B in ~80 Tokens/s laufen lassen, Prompt-Eval ~10× schneller. Aber dann zahlst du Cloud-Kosten, und der "lokal/privat"-Vorteil ist weg.
- Spezialisiertes kleineres Modell + Fine-Tuning: Qwen 3B mit Domäne-Fine-Tuning kann auf CPU ~15-20 t/s erreichen, vergleichbar gut für OpenBiz-Use-Cases. Aber Training braucht GPU-Stunden
extern.
Die unbequeme Wahrheit
Lokales LLM auf CPU ist immer ein Kompromiss. Es ist gut für:
- Datenschutz (nichts verlässt den Server)
- Cost (kein API-Tarif)
- Offline-Fähigkeit
- Spezielle Anpassbarkeit
Es ist schlecht für:
- Latenz bei komplexen Prompts (genau dein Fall)
- Tool-Wahl-Zuverlässigkeit bei vielen Tools
Anthropic ist hier nicht "besser konfiguriert" — Anthropic hat einfach Infrastruktur im Wert eines mittleren Rechenzentrums hinter sich. Das macht jeden Vergleich asymmetrisch.