Die richtige KI-Inferenzschicht für agentische Systeme wählen: Ein Entscheidungsrahmen für CTOs

Der KI-Agent, den Sie im Notebook vorgeführt haben, ist nicht der Agent, den Sie ausliefern werden. Ob er schnell, compliant, kosteneffizient und beobachtbar ist, entscheidet nicht der Modellname auf Ihrer Folie—sondern die Inferenzschicht, die Sie wählen, und das Design darum herum.

In den letzten Wochen hat Cloudflare eine Inferenzschicht „designed for agents“ vorgestellt, die Rechenlast an den Edge verlagert. OpenAI hat Desktop-Steuerfunktionen erweitert—Agenten, die Ihren Rechner im Hintergrund nutzen, fühlen sich plötzlich beunruhigend real an. Mozilla hat einen Client für selbstgehostete Infrastruktur präsentiert. Gleichzeitig werden offene Modelle wie Qwen3.6-35B agentenfähig. Übersetzung: Die Plattformentscheidung ist jetzt die Produktentscheidung.

Als CTO müssen Sie sich für eine Spur entscheiden. Hier ist ein pragmatischer Rahmen dafür.

Die eigentliche Wahl ist nicht „welches Modell?“, sondern „wo und wie führen wir es aus?“

Benchmarks und Leaderboards sind laut. In der Produktion zählen Latenzbudget, Datenkontrolle, Kostenstabilität und Operabilität. Ein Agent, der sich bei 250 ms p50 und 800 ms p95 flott anfühlt und einen sauberen Audit-Trail liefert, schlägt einen nur geringfügig „intelligenteren“ Agenten, der 2,5 s braucht und Geheimnisse in Logs verstreut.

Definieren Sie die Fähigkeitsstufe Ihres Agenten (und das implizite Risiko)

• Tier 0: Chat und RAG. Zustandsloses Q&A. Minimaler Tool-Einsatz. Geringer Blast Radius.
• Tier 1: Function Calling und API-Orchestrierung. Schreibzugriffe auf interne Systeme hinter strikt konfiguriertem IAM.
• Tier 2: Browsing, Datei-I/O und Codeausführung in einer Sandbox. Mittlerer Blast Radius.
• Tier 3: Desktop- oder Cloud-Console-Steuerung (z. B. Shell, GUI-Automatisierung). Hoher Blast Radius, erfordert Isolation und Aufzeichnung.
• Tier 4: Autonome Loops mit Hintergrundaufgaben und Scheduling. Höchster Blast Radius. Behandeln wie ein privilegiertes Servicekonto mit Bremsen.

Ihre Wahl der Inferenzschicht sollte sich an der höchsten Tier orientieren, die Sie in den nächsten zwei Quartalen unterstützen wollen—nicht an der Demo von letzter Woche.

Ein Entscheidungsrahmen in sieben Fragen

1) Wie hoch ist Ihr Latenzbudget und wo sind Ihre Nutzer?

• Edge-Inferenz (z. B. auf einem globalen Netzwerk) spart 50–150 ms, weil Long-Haul-Hops und Cold Starts für Chat+RAG entfallen.
• Regionale Inferenz (AWS, GCP, Azure) addiert je nach Peering und VPC-Setup 30–120 ms pro Call. Häufig vorzuziehen für Backoffice-Workflows.
• On-Device erreicht bei kleinen Modellen 30–80 ms, opfert aber Fähigkeit und Konsistenz; gut für stark datenschutzsensitive oder gelegentliche Tasks.

Faustregel: Muss sich ein Produktfeature sofortig anfühlen (p95 unter 1 s) und sind Nutzer global verteilt, bevorzugen Sie Edge—oder eine Split-Architektur mit Edge-Router, lokalen Embeddings/Rerankern und einem regionalen „Brain“.

2) Welche Daten berühren Sie, und wo müssen sie liegen?

• PHI, PCI oder strikte PII-Policies drängen zu VPC-gehosteter Inferenz oder Anbietern mit durchsetzbarer Datenresidenz und ohne Trainingsnutzung der Eingaben.
• Datenminimierung und Tokenisierung am Gateway reduzieren Risiko und Vendor Lock-in. Vor der Inferenz schwärzen, nicht danach.
• Für EU/LatAm-Residenz planen Sie Dual-Deployments ein. Cross-Border-Hops ruinieren sowohl Latenz- als auch Compliance-Story.

3) Welche Tools wird der Agent nutzen, und wie sandboxen Sie sie?

• Function Calling gegen interne Services erfordert signierte Requests, Allowlists pro Tool und Budgetobergrenzen pro Interaktion.
• Desktop- oder Console-Steuerung benötigt ephemere VMs/MicroVMs, Sitzungsaufzeichnung und auf die Aufgabe begrenzte Credentials mit eng gefasstem RBAC.
• Web-Browsing braucht sichere Renderer und Content-Sanitization; lassen Sie einen Agenten niemals beliebiges JavaScript in Ihrem Produktionsnetz ausführen.

4) Welches SLA und welches Anbieterrisiko können Sie tolerieren?

• Öffentliche Endpunkte geschlossener Anbieter liefern Top-Modelle, können aber drosseln oder Bedingungen ändern. Halten Sie ein Fallback-Modell und einen Routing-Layer bereit.
• Edge-Netzwerke sind robust, fügen aber eine Abhängigkeit von POP-Verfügbarkeit und Anbieter-Features hinzu. Prüfen Sie den Backlog unterstützter Modelle und die Upgrade-Kadenz.
• Self-Hosting bringt Kontrolle, verlagert aber die Uptime-Bereitschaft auf Ihr Team. Planen Sie SRE-Stunden ein. Es gibt kein Free Lunch.

5) Bekommen Sie die Unit Economics zusammen?

Arbeiten Sie rückwärts von einer Aufgabe: im Schnitt 300 Input-Tokens, 800 Output-Tokens, 2 Function Calls. Multiplizieren Sie mit Ihrem monatlichen Task-Volumen. Bauen Sie dann zwei Szenarien:

• Premium-Closed-Modell für Kognition + günstiger Open-Reranker/Embeddings am Edge.
• Vollständig offene Stack, für Ihre Domäne feinabgestimmt/mit LoRA adaptiert.

Wir sehen regelmäßig 20–40% Kostenschwankungen, abhängig davon, wie viel Sie an Reranker auslagern und wie aggressiv Sie Embeddings batchen oder cachen. Berücksichtigen Sie auch Egress aus der Vektor-DB; Reranking und Vektorsuche kolokal mit der Inferenz zu halten, verhindert unnötige Netzwerkkosten.

6) Wie beobachten, evaluieren und rollen Sie zurück?

• Jeder Agentenschritt sollte Spans mit Tool, Tokens, Latenz und Kosten emittieren. Roh-Prompts/-Completions stichprobenartig erfassen—mit Schwärzung.
• Führen Sie nächtliche synthetische Evals auf einem festen Korpus aus. Verfolgen Sie Erfolgsrate und Halluzinations-Deltas pro Modellversion.
• Machen Sie Modelle zu einem Config-Toggle. Liefern Sie mit Kill Switch aus und üben Sie Rollbacks wie Ihre Incident Response.

7) Was ist Ihr Escape Hatch?

• Halten Sie Prompts, Tool-Schemata und Guardrails anbieteragnostisch. Nutzen Sie einen Adapter-Layer, damit Modellwechsel nicht in Ihren Produktcode greifen.
• Halten Sie mindestens einen Open-Source-Model-Pfad (vLLM/Ollama) vor, um bei Anbieter-Ausfällen oder Preisänderungen handlungsfähig zu bleiben.

Ihre Plattformoptionen, ohne Hype

Cloudflare Workers AI (edge) + Vectorize + KV/Queues

Cloudflare positioniert seine AI-Plattform explizit als Inferenzschicht für Agenten—mit globalen POPs und enger Integration über Storage und Networking. Der praktische Vorteil: wenige Cold Starts, schnelle Tail-Latenzen und günstiger Intra-Plattform-Datenverkehr.

• Stärken: 300+ POPs, nutzernahe Latenz; einfache Komposition mit KV/Queues/Durable Objects; gut geeignet für Chat+RAG und leichten Tool-Einsatz.
• Einschränkungen: Tiefe des Modellkatalogs variiert; langlaufende oder GPU-intensive Jobs sind unhandlich; Fine-Tuning-Optionen sind gegenüber Hyperscalern begrenzt. Sie akzeptieren die Anbieter-Roadmap als limitierenden Faktor.
• Gute Eignung: Produktfeatures, bei denen p95 unter 1 s zählt, und Datensensitivität per Schwärzung/Tokenisierung beherrschbar ist.

Referenz: Überblick zur Cloudflare-AI-Plattform mit aktuellem Modell-Support und Architekturmustern siehe (blog.cloudflare.com/ai).

AWS Bedrock + Lambda/ECS + VPC (regional)

Bedrock bietet eine Auswahl hochwertiger Closed- und Open-Modelle innerhalb Ihrer VPC-Grenzen, mit IAM- und PrivateLink-Unterstützung. Langweilig im besten Sinne.

• Stärken: Enterprise-taugliches IAM, CloudWatch, KMS; überzeugende Compliance-Story; Kolokation mit Ihren Datenquellen; stetige Weiterentwicklung (Agents, Guardrails).
• Einschränkungen: Regionale Latenz; Kostenintransparenz beim Mix aus Managed Services; gelegentliche Modellkapazitätsgrenzen; Routing und Evals müssen Sie weiterhin selbst designen.
• Gute Eignung: Backoffice-Agenten, PII/PHI-Workloads, interne Automatisierung, bei der Auditierbarkeit wichtiger ist als absolute Latenz.

OpenAI/Anthropic Endpoints (Managed Cognition)

Erstklassige Reasoning-Modelle, starkes Function Calling, Tool-Use-Planning und zunehmend umfassende Systemfähigkeiten wie Desktop-Steuerung im Hintergrund.

• Stärken: Best-in-Class Reasoning und Coding; häufige Modellverbesserungen; leicht zu prototypen; gute Tool-Use-Semantik.
• Einschränkungen: Anbieterbedingungen und Rate Limits; Datenkontrolle hängt von Einstellungen und Enterprise-Verträgen ab; Public-Internet-Hop und Egress; Sandboxing liegt bei Ihnen.
• Gute Eignung: Wenn Reasoning-Qualität dominiert und Sie Datenrisiken via Schwärzung mindern können, oder für „Brain“-Calls hinter Edge/Router mit Open-Model-Pre-/Post-Processing.

Referenz: Anbieterblogs verkünden schnelle Fähigkeitsänderungen; planen Sie Change Control ein (openai.com/blog, anthropic.com/news).

Self-hosted Open-Modelle mit vLLM/Ollama auf Kubernetes (VPC)

Wenn Datenkontrolle und Kostenplanbarkeit wichtiger sind als rohe IQ-Punkte, dann self-hosten. vLLM liefert High-Throughput-Serving; moderne Open-Modelle (Qwen, Llama, Mistral) werden sehr leistungsfähig, besonders mit Domänen-Tuning und Reranking.

• Stärken: Volle Datenkontrolle; vorhersagbare Kosten pro GPU-Stunde; quantisierte Modelle auf kleineren GPUs/CPUs für nicht-kritische Pfade betreibbar; vermeidet Vendor Lock-in.
• Einschränkungen: SRE liegt bei Ihnen; Modelllebenszyklus und Evaluationsdisziplin ebenso; State-of-the-Art erfordert kontinuierliches Tuning.
• Gute Eignung: Regulierte Daten, Offline-/Air-Gapped-Szenarien oder kostensensitive High-Volume-RAG-Fälle, in denen 95%-Perzentil-Qualität nicht zwingend ist.

On-Device (Mobile/Desktop)

Mit kleinen, quantisierten Modellen und immer leistungsfähigeren mobilen NPUs ist On-Device-Inferenz für eng umrissene Aufgaben realistisch (Zusammenfassung, Klassifikation, clientseitige Schwärzung, Altersprüfungen).

• Stärken: Privacy, Offline-Fähigkeit, niedrigste Netzwerklatenz, potenzielle Compliance-Vorteile, wenn Inferenz nie das Gerät verlässt.
• Einschränkungen: Begrenzte Modellgröße und -kontext; Komplexität bei Verteilung und Upgrades; fragmentierte Hardware-Beschleunigung.
• Gute Eignung: Privacy-first-Features, Pre-/Post-Processing, Gating von Tasks vor der serverseitigen Kognition.

Referenzarchitekturen, die in Produktion gehen

1) Consumer-Feature: Low-Latency Chat + RAG

• Edge-Router auf Cloudflare (oder ähnlich) für Request Termination, Schwärzung, Rate Limiting und Feature Flags.
• Embeddings und Reranker am Edge für Kandidatenauswahl aus einem kolokalisierten Vector Store. Aggressiv cachen.
• Brain-Calls an ein regionales Premium-Modell (OpenAI/Anthropic oder Bedrock) nur bei Bedarf. Kurze Kontexte, durch Tools abgesichert.
• Observability: Logging auf Span-Ebene mit Token-Zählung, p50/p95 pro Stage und Stichproben-Transkripten mit maskierter PII.

Damit haben wir die Medianlatenz gegenüber „nur Region“-Designs um 25–35% gesenkt—bei 15–25% weniger LLM-Kosten dank smarter Vorfilterung.

2) Interner Backoffice-Agent mit sensiblen Daten

• Führen Sie die Inferenz in Ihrer VPC (Bedrock oder vLLM) hinter einem OIDC-Gateway aus. Alle Tools erfordern signierte JWTs und Scope-bezogene IAM-Rollen.
• Zentralisieren Sie Secrets in Ihrem Standard-Vault; niemals in Prompts. Loggen Sie alle Tool-Aufrufe in einen Append-only Store.
• Nutzen Sie eine Policy-Engine, um Aktionen oberhalb eines Risikoschwellenwerts zu genehmigen/abzulehnen (z. B. Zahlung > $1000 erfordert menschliche Bestätigung).
• Nächtliche Evals auf einem Goldstandard-Datensatz; Regressions-Gates blockieren neue Modellversionen, die über vereinbarte Margen hinaus degradieren.

Erwarten Sie etwas höhere Latenzen (p95 900–1400 ms), dafür starke Auditierbarkeit und Data Governance, die externen Prüfungen standhält.

3) Desktop-/Console-Automatisierung (hoher Blast Radius)

• Lassen Sie den Agenten niemals einen echten User-Desktop berühren. Starten Sie ephemere MicroVMs oder Container mit wegwerfbarer Identität und Run-bezogenen Credentials.
• Nutzen Sie ein zweistufiges Brain: Closed-Modell für das Planning; offenes, selbstgehostetes Modell für iterative, risikoarme Schritte, um Kosten zu steuern und Rate Limits zu vermeiden.
• Nehmen Sie die Session auf (Video + Logs), deckeln Sie Laufzeit- und Token-Budgets und verlangen Sie für destruktive Aktionen eine menschliche Freigabe.
• Leiten Sie alle Downloads durch einen sicheren Renderer und einen AV-Scan. Netzwerk-Egress auf Allowlists beschränken.

Ja, es ist schwergewichtiger. Aber genau das trennt eine kontrollierte Demo von einem produktiven System, das Sie in einem Incident Review verteidigen können.

Sicherheitskontrollen, die wichtiger sind als Ihre Modellwahl

• Schwärzung am Edge: Hash/E-Mail/SSN-Entfernung vor den Prompts. Originale in einem versiegelten Speicher aufbewahren, der über ein Token verknüpft ist—falls Sie nach der Inferenz rehydrieren müssen.
• Tool-Allowlists + Budgets: Max. N Tool-Calls pro Interaktion, Maximalbudget pro Session und Scopes pro Tool. Standardmäßig verweigern.
• Timeboxing: Harte Timeouts und Watchdogs für Agent-Loops. Keine endlosen Hintergrundjobs ohne Scheduler unter Ihrer Kontrolle.
• Datenherkunft: Jedes Artefakt mit Modellversion, Prompt-Hash und Toolchain taggen. Machen Sie es möglich, „Was hat das erzeugt?“ zu beantworten.
• Jailbreak-Tests in CI: Red-Team-Prompts im Repo versionieren. Vor jedem Modellupgrade dagegenlaufen lassen—vor dem Rollout.

Erfolg messen: KPIs für den Realitätscheck

• Latenz: p50/p95 pro Stage (Embed, Rerank, LLM, Tools), nicht nur End-to-End.
• Qualität: Task-Erfolgsrate aus nächtlichen Evals; Faktizitäts-/Halluzinationsrate auf einem gelabelten Subset.
• Economics: Kosten pro erfolgreicher Aktion (nicht pro Token), Cache-Hit-Raten und Vektorabfragen pro Task.
• Zuverlässigkeit: Übergaberate an Menschen, Auto-Retry-Rate und Vorfälle pro 10.000 Tasks.
• Changesicherheit: % zurückgerollter Modell-Upgrades, durchschnittliche Zeit bis zum Rollback.

Was wir in Projekten sehen

Über jüngste Deployments hinweg zeigen sich ein paar stabile Muster:

• Edge-Preprocessing + regionale „Brains“ ist ein Sweet Spot für Consumer-UX. Rechnen Sie mit 20–35% Latenzverbesserung und 10–25% weniger LLM-Kosten, wenn Sie Klassifikation/Reranking auf kleine Edge-Modelle auslagern.
• Selbstgehostete Open-Modelle sind für 60–80% der Backoffice-Agentenaufgaben tragfähig, kombiniert mit kuratierten Prompts, LoRA-Adaptern und strikter Tool-Policy—Premium-Modelle bleiben für die härtesten 20–40% frei.
• Agent-Sandboxes amortisieren sich. Teams, die Desktop-Automatisierung in MicroVMs verlagert haben, senkten das Incident-Risiko deutlich und reduzierten die durchschnittliche Untersuchungszeit dank deterministischem Replay und vollständigen Sitzungs-Logs um über 50%.

Nichts davon ist theoretisch. Es ist die operative Schicht, die Sie brauchen, wenn Sie von einer Demo zu einer belastbaren Fähigkeit aufsteigen wollen.

Planen Sie für Knappheit und Wandel

Eine glaubwürdige Erzählung vom „Beginn der Knappheit in der KI“ bedeutet: Kapazitätsengpässe und Preise werden schwanken. Verankern Sie Ihr Produkt nicht an ein einziges Modell oder einen Anbieter. Bauen Sie einen kleinen, langweiligen Router mit Adapter-Schnittstellen für Prompts, Tools und Guardrails. Halten Sie mindestens einen Open-Model-Pfad warm (auch wenn er nur 10% des Traffics trägt). Ihr zukünftiges Ich wird es Ihnen danken, wenn sich Rate Limits oder Preise mitten im Quartal ändern.

Fazit

Wählen Sie die Inferenzschicht passend zu Ihrem Latenz- und Datenprofil und designen Sie Guardrails und Observability, als würden Sie ein Bezahlsystem bauen. Dann kann sich das Modell unter Ihnen ändern—und Ihr Produkt funktioniert weiter.

Wichtigste Erkenntnisse

• Nach Topologie und Kontrolle entscheiden, nicht nach Modell-FOMO: Edge für Speed, VPC für sensible Daten, Hybrid für die meisten realen Produkte.
• Definieren Sie jetzt Ihre höchste Agenten-Tier (0–4); sie bestimmt Sandboxing, IAM und das Infra-Budget.
• Cloudflare Edge ist stark für Chat+RAG-UX; Bedrock/Self-Hosted gewinnen bei Compliance- und auditlastigen internen Agenten.
• Premium-Kognition sparsam routen; Embeddings/Reranker und Caches an den Edge schieben, um Latenz und Kosten zu senken.
• Modelle als Config-Flag behandeln. Einen Open-Model-Escape-Hatch warm halten, um Ausfälle und Preisschocks abzufedern.
• Spans instrumentieren, nächtliche Evals fahren und Rollbacks üben. So verhindern Sie leise Qualitätsregressionen.
• Für Desktop-/Console-Agenten: Isolation in ephemeren MicroVMs mit Aufzeichnung und strikten Budgets. Alles andere ist ein Sicherheitsvorfall in Wartestellung.