Wie Sie 100% On-Device KI-Agenten bauen: Sub-100ms Latenz auf Qualcomm NPU, keine Cloud-Abhängigkeit
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem Studio DennisCraft AI shippe ich KI-Agentensysteme für DACH-Kunden, Stack: Claude, Supabase, n8n, Doppler, selbst gehostetes Postgres. In einem laufenden Industrieprojekt war die Vorgabe klar: Kein Byte darf die lokale Umgebung verlassen, Latenz pro Anfrage unter 100ms auf Qualcomm NPU – sonst scheitert die DSGVO-Prüfung und die Produktionsfreigabe. Warum On-Device: Compliance und Latenz – keine Theorie Für viele
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem Studio DennisCraft AI shippe ich KI-Agentensysteme für DACH-Kunden, Stack: Claude, Supabase, n8n, Doppler, selbst gehostetes Postgres. In einem laufenden Industrieprojekt war die Vorgabe klar: Kein Byte darf die lokale Umgebung verlassen, Latenz pro Anfrage unter 100ms auf Qualcomm NPU – sonst scheitert die DSGVO-Prüfung und die Produktionsfreigabe.
Warum On-Device: Compliance und Latenz – keine Theorie
Für viele Unternehmen im DACH-Raum sind Cloud-Lösungen aufgrund von DSGVO, BSI Grundschutz und EU AI Act de facto ausgeschlossen. Laut DLA Piper (2024) lagen die DSGVO-Strafzahlungen 2023 bei über 2,9 Mrd. Euro – Datenübertragung in die Cloud ist ein echtes Risiko, kein Randproblem. Im Produktionsumfeld ist On-Device-Inferenz nicht nur eine Compliance-Frage, sondern entscheidend für die Betriebsstabilität.
Latenz: Produktionsfenster statt User Experience
Agenten, die Produktionssysteme steuern, arbeiten oft mit 200–300ms Zyklen. Schon 150ms Cloud-Roundtrip machen die Automatisierung unbrauchbar. Mit Qualcomm NPU und optimiertem Stack messe ich im Betrieb 70–90ms pro Anfrage (Snapdragon 8 Gen 2, Phi-3 quantized). Das sind reale Werte, keine Labortests.
Architektur: So bauen Sie einen 100% On-Device Agenten
Klassische Agenten-Architekturen (Prompt → LLM → Action → Feedback) müssen für Edge-Einsatz neu gedacht werden. Mein Stack im produktiven Umfeld:
- Modell: Llama 3, Gemma oder Phi-3 als ONNX-Export
- Runtime: ONNX Runtime mit Qualcomm AI Engine/QNN-Backend
- RAG: FAISS, lokal auf dem Gerät
- Orchestrierung: n8n, lokal eingebettet
- Secrets: Doppler CLI, Zugriff ausschließlich lokal
Minimaler Inferenz-Loop auf dem Gerät
import onnxruntime as ort
import numpy as np
session = ort.InferenceSession(
"phi3_quantized.onnx",
providers=['QNN']
)
tokenizer = ... # passender Tokenizer laden
def run_inference(prompt):
input_ids = tokenizer.encode(prompt, return_tensors="np")
output = session.run(None, {"input_ids": input_ids})
return tokenizer.decode(output[0][0])
Der QNN-Provider ist für Hardwarebeschleunigung auf Qualcomm NPUs unerlässlich.
Latenz im Live-Betrieb messen
for i in {1..10}; do
/usr/bin/time -f "%e" python3 run_inference.py --prompt "Lieferschein prüfen"
done
Im Test auf Snapdragon 8 Gen 2: Median 87ms für Phi-3 (4B quantized), CPU-Auslastung unter 30%.
Sicherheitsaspekte: Risiken verschieben sich lokal
Ohne Cloud verschwindet das Datenabflussrisiko, aber lokale Angriffsvektoren wie Speicherzugriffe, lokale SQL-Injektionen und Side-Channel-Attacken treten in den Vordergrund. Das Sicherheitskonzept muss angepasst werden – BSI Grundschutz empfiehlt gezielte Kontrolle von Zugriffen und Speicher.
Code-Analyse mit semgrep und bandit
Ich prüfe alle von LLM generierten und produktiven Agenten-Code mit semgrep und bandit – wiederholt habe ich SQL-Injection-Muster im REST-Layer gefunden, auch bei kleineren Integrationen.
semgrep --config p/sql-injection .
bandit -r ./agent_code/
Secrets und Isolierung
Secrets bleiben ausschließlich in Doppler, niemals im Code oder Log. Storage wird per cryptsetup verschlüsselt, FAISS läuft unter dediziertem User mit Minimalrechten, Zugriff auf Modellgewichte und Indizes wird strikt getrennt.
Produktionsfehler: Wo brechen Edge-Agenten am häufigsten
| Problem | Ursache | Lösung |
|---|---|---|
| Modell lädt nicht | Falsche ONNX-Export/Quantisierung | ONNX + QNN-Kompatibilität prüfen |
| Latenz >100ms | CPU-Fallback aktiviert | QNN-Backend erzwingen, Monitoring |
| Secrets im Log | Hardcode oder Logging-Fehler | Doppler-only, Audit der Logs |
| RAG findet keine Dokumente | FAISS-Index veraltet | Regelmäßiges Re-Indexing mit n8n |
Integration in lokale Systeme: Produktionsschnittstellen sicher halten
Auch 100% On-Device-Agenten brauchen oft Anbindung an lokale ERP- oder SCADA-Systeme. Ich setze n8n als lokalen Workflow-Runner ein, alle API-Aufrufe laufen über interne Netze. Logging erfolgt in verschlüsseltem, selbst gehostetem Postgres mit Rotation und minimaler Aufbewahrungsdauer – DSGVO-konform, kein unnötiges Datenhalten.
FAQ
Welche Modelle laufen stabil auf Edge-NPUs?
Llama 3 8B (int4), Phi-3 4B, Gemma 2B – immer ONNX-Export und Kompatibilität mit Zielhardware vorab testen.
Ist vollständiges RAG On-Device möglich?
Für kleine Indizes (bis 200MB mit FAISS) ja. Bei größeren Basisdaten empfiehlt sich ein Hybridmodell: nur aktuelle Daten lokal vorhalten.
Wie erfolgt ein Modellupdate auf dem Gerät?
Ausschließlich signierte OTA-Updates, Schlüssel im TPM. Ohne Signatur kein Update – BSI-konform.
Wo ist beim Edge-Agenten der Flaschenhals?
Meist RAM. Swap nur auf schnellen SSDs, nie auf eMMC verwenden.
Wie wird Fehlerlogging gehandhabt?
Nur Stacktrace und Eingangsdaten, automatisches Purging alle 24h per n8n-Job.
Wo erleben Sie im produktiven Betrieb die meisten Probleme bei On-Device-Agenten: Modellinitialisierung, Orchestrierung oder externe API-Integration? Ich bin an echten Praxisfällen interessiert.
Ich biete DACH-Teams, die KI unter regulatorischen Vorgaben bauen, einen kostenlosen 30-min Stack-Audit. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.
Turn your process into an AI system
Fixed price. Production quality. DACH B2B focus.