Fallstudie · Vertraulicher Unternehmenskunde (regulierte Branche)
Wie wir eine OpenAI-Rechnung von 4,2 Tsd. $/Monat durch einen vollständig geräteinternen LLM-Workflow mit Ollama, llama.cpp und einer FastAPI-Orchestrierungsschicht ersetzt haben – 100 % der Kundendaten bleiben auf dem Laptop des Nutzers, bei Antworten in unter einer Sekunde.
Ein Unternehmenskunde aus einer regulierten Branche nutzte über seine internen Tools ein gehostetes LLM, doch jedes Quartal meldete das Security-Review-Team dasselbe Hindernis: Personenbezogene Kundentexte wurden an einen US-Cloud-Endpunkt gesendet. Die Rechtsabteilung hatte den breiteren Rollout pausiert, die OpenAI-Rechnung war mit nur einem Bruchteil der geplanten Nutzerbasis auf über 4.200 $/Monat gestiegen, und dem Produktteam war die unmögliche Frage gestellt worden: „Können wir all diese KI-Fähigkeiten behalten, ohne dass Daten den Laptop des Nutzers verlassen?“
Sie brauchten kein Forschungsprojekt. Sie brauchten einen auslieferbaren Workflow, den ein interner Mitarbeiter an einem Nachmittag installieren konnte, der vollständig auf ihren vorhandenen MacBooks mit M-Serie und Windows-ThinkPads lief und der leistungsfähig genug war, dass sich niemand über das Datenschutz-Upgrade ärgern würde.
Wir haben einen vollständig geräteinternen LLM-Stack entworfen und ausgeliefert: Ollama als Modell-Runtime, llama.cpp im Hintergrund für quantisierte GPU-/CPU-Inferenz, eine kleine FastAPI-Orchestrierungsschicht für Tool-Nutzung und Retrieval sowie eine Next.js-Desktop-Oberfläche, ausgeliefert über einen schlanken Tauri-Wrapper. Jedes Byte Kontext bleibt auf dem Gerät. Es gibt keine entfernte Inferenz, keinen Telemetrie-Callback, keinen Proxy.
Wir haben sieben Open-Weight-Modelle (Llama 3.1 8B, Qwen 2.5 7B/14B, Phi-3, Mistral und zwei domänenspezifisch abgestimmte Varianten) mit den echten Prompts des Kunden verglichen und einen Modell-Router pro Aufgabe ausgeliefert: ein kleines, schnelles Modell für Klassifizierung und Chat, ein größeres Reasoning-Modell auf Abruf. RAG läuft gegen einen lokalen ChromaDB-Index, der aus den eigenen Dokumenten des Nutzers aufgebaut wird, wobei jedes Embedding auf dem Gerät berechnet wird.
Das Ergebnis ist ein Workflow, der beim mittleren Prompt messbar schneller ist als die Cloud-Version (keine Netzwerk-Roundtrips), das Security-Review des Kunden bereits beim ersten Einreichen besteht und ohne Inferenzkosten pro Arbeitsplatz auf jeden Laptop im Unternehmen skaliert.
Wir haben einen repräsentativen Satz von rund 400 echten Prompts aus den bestehenden OpenAI-Logs (bereinigt) gesammelt und anschließend Kandidaten unter den Open-Weight-Modellen auf der tatsächlichen Hardware-Mischung des Kunden getestet – MacBooks mit M1, M2 und M3 plus einem Windows-ThinkPad als Referenzgerät – und dabei Tokens pro Sekunde, p95-Latenz bis zum ersten Token sowie Qualität gegenüber der GPT-4-Basis anhand eines vom Kunden verantworteten Bewertungsrasters gemessen.
Wir wählten Ollama als Laufzeitumgebung (sauberer Lebenszyklus, Modellversionierung, GPU-bewusste Quantisierung) und bauten darauf eine schlanke FastAPI-Orchestrierungsschicht, die jede Aufgabe an das passende Modell leitet, die Abfrage gegen einen lokalen ChromaDB-Index übernimmt und eine stabile HTTP-API bereitstellt, die die Desktop-Oberfläche aufrufen kann. Der gesamte Stack läuft als drei lokale Prozesse, die von der Desktop-App verwaltet werden.
Die Entwicklung erfolgte in zweiwöchigen Sprints mit einem echten Evaluierungs-Harness – jede Änderung wurde an einem zurückgehaltenen Prompt-Set bewertet, sodass Qualitätsrückgänge sofort sichtbar wurden. Wir haben einen Ein-Klick-Import für die eigenen Dokumente der Nutzer ergänzt, einen Kanal für Modell-Updates, der die Netzwerkrichtlinie der Nutzer respektiert, und ein Datenschutz-Panel, das genau zeigt, worauf das Modell Zugriff hat.
Wir haben den Stack als signierten Installer paketiert (unter macOS notarisiert, unter Windows signiert), ein kurzes Bedrohungsmodell geschrieben, das das Security-Team in 20 Minuten lesen konnte, und vor dem unternehmensweiten Rollout an einen Pilot mit 25 Nutzern ausgeliefert. Das Security-Review wurde bereits bei der ersten Einreichung bestanden – das entscheidende Merkmal war eine überprüfbare Netzwerk-Allowlist, die belegt, dass kein LLM-Datenverkehr jemals das Gerät verlässt.
“Wir dachten, private KI bedeute ein schlechteres Produkt. Der UnlockLive-Build ist bei den meisten Aufgaben unseres Teams schneller als die Cloud-Version, und unsere Sicherheitsprüfung dauerte 20 Minuten statt drei Monaten.”
Für die meisten Unternehmensaufgaben – Klassifikation, Zusammenfassung, RAG über die eigenen Dokumente der Nutzer, strukturierte Extraktion – ja: Ein gut gewähltes Open-Weight-Modell im Bereich 7B bis 14B erreicht oder übertrifft GPT-3.5 und kommt in der Qualität auf 10-15 % an GPT-4 heran. Der Trick ist ehrliche Evaluation: Wir bewerten Kandidatenmodelle immer anhand der echten Prompts des Kunden, nicht anhand generischer Benchmarks.
Standardmäßig setzen wir Llama 3.1 8B für allgemeinen Chat und Qwen 2.5 14B für Aufgaben mit hohem Reasoning-Anteil ein, mit Phi-3 mini für ultraschnelle Klassifikation. Die endgültige Wahl hängt von der Hardware der Nutzer ab (M2/M3-Macs bewältigen 14B problemlos; ältere Intel-Laptops fahren besser mit quantisiertem 7B) und vom Workload-Mix.
Ollama selbst steht unter einer permissiven Lizenz und bietet einen stabilen Modell-Lebenszyklus, GPU-bewusste Quantisierung und eine saubere HTTP-API. Wir kombinieren es mit einer schlanken FastAPI-Orchestrierungsschicht in unserer Hand, einem signierten/notarisierten Installer und einer überprüfbaren Netzwerk-Allowlist – diese Kombination hat mehrere Enterprise-Sicherheitsprüfungen beim ersten Einreichen bestanden.
Wir liefern mit dem Deployment ein Evaluierungs-Harness pro Mandant aus. Jedes Modell-Upgrade wird an einem zurückgehaltenen Prompt-Set bewertet, das dem Kunden gehört, und nur freigegeben, wenn es eine Qualitätsschwelle erreicht. Modell-Updates werden über einen Canary-Kanal ausgerollt, den der Nutzer steuert.
Der typische Break-even liegt bei 6–9 Monaten. Der Aufbau ist ein einmaliger Engineering-Aufwand (8–14 Wochen für einen fokussierten Workflow), danach sinken die Inferenzkosten pro Nutzer auf null. Gehostete APIs gewinnen bei sprunghafter, geringer Nutzung; On-Device gewinnt bei täglich genutzten Unternehmenswerkzeugen.
KI / SaaS70% Der Tickets ohne menschliches Zutun gelöstEine KI-Kundenservice-Plattform, die 70 % der eingehenden Tickets ohne menschliches Eingreifen bearbeitet und den Rest mit vollständigem Kontext an den richtigen Agenten weiterleitet.
SaaS8x p95-Latenzrückgang bei stark genutzten Endpunkten (1,8 s → 220 ms)Wie wir eine stark belastete Python/FastAPI-API mit einer mehrstufigen Redis-Caching-Schicht neu aufgebaut haben, um die p95-Latenz von 1,8 s auf 220 ms zu senken und die PostgreSQL-Last für ein nordamerikanisches B2B-SaaS um 70 % zu reduzieren.
Sprechen Sie mit demselben Team, das gebaut hat Private On-Device-LLM-Bereitstellung für ein datenschutzsensibles Unternehmen (Ollama + llama.cpp). Wir grenzen Ihr Projekt ein, erstellen ein Festpreisangebot und zeigen Ihnen das passendste Beispiel aus unserem Portfolio.
Strategiegespräch buchenUnlockLive IT Limited – Hauptsitz in Toronto für Kundenkontakt und Projektmanagement; dediziertes Engineering-Center in Dhaka, Bangladesh. Im Vereinigten Königreich eingetragenes Unternehmen Nr. 15563368 (UnlockLive IT Limited, London).
Copyright© UnlockLive . Alle Rechte vorbehalten 2008 - 2026