Lokale Inferenz: wenn 'wohin Ihre Daten gehen' die ganze Geschichte ist.

Lokale Inferenz bedeutet, ein Open-Weight-Sprachmodell - Llama, Mistral, Qwen, DeepSeek, Phi, Gemma und ihre Derivate - auf Hardware innerhalb des Haus-Perimeters zu betreiben. Der Perimeter ist konkret: das Rechenzentrum des Hauses, eine Souverän-Cloud-Tenancy unter einem Vertrag, den das Haus kontrolliert, oder ein GPU-Rack on-prem. Kein Prompt, kein abgerufener Chunk, keine Completion und kein Embedding überquert die Grenze nach außen. Es gibt keinen API-Aufruf an einen fremden Hyperscaler im Request-Pfad.

Zwei Schichten bestimmen die Tragfähigkeit. Die erste ist Quantisierung, die Praxis, die Gewichts-Präzision von nativem fp16 oder bf16 auf kleinere Formate zu reduzieren, damit ein Modell in den verfügbaren GPU-Speicher passt. Die heute dominanten Formate sind GGUF (ein Container um k-quant-Rezepte wie Q4_K_M und Q5_K_M, von llama.cpp verwendet, unterstützt CPU-plus-GPU-Hybridausführung), AWQ (activation-aware INT4-Quantisierung, die die kleine Menge an Gewichten erhält, die den größten Teil des Ausgangssignals tragen) und natives INT8 oder FP8 auf H100-Klasse-Hardware. Eine Q5_K_M-Quantisierung eines 70B-Modells passt in etwa 50 GB VRAM mit nutzbarem Kontext und verliert nur wenige Prozentpunkte Qualität gegenüber dem nicht quantisierten Baseline.

Die zweite Schicht ist der Inferenz-Server. Die produktionsreife Wahl ist vLLM, dessen PagedAttention-Mechanismus den Attention-Key-Value-Cache in feste Blöcke partitioniert, die über eine Block-Tabelle pro Sequenz adressiert werden - im Grunde virtueller Speicher für Attention. Das reduziert KV-Cache-Fragmentierung von 60-80 Prozent Verschwendung auf unter 4 Prozent und hebt den Durchsatz um eine Größenordnung gegenüber naivem Serving auf derselben GPU. llama.cpp ist die Alternative für Single-Machine- oder CPU-plus-GPU-Hybrid-Setups; TGI ist Hugging Faces vergleichbarer Produktions-Server.

Die Compliance-Frage, die die meisten KI-Projekte bei einem VV oder einer Boutique-Vermögensverwaltung stoppt, lautet nicht 'ist das Modell genau'. Sie lautet 'wohin gehen die Daten, wenn wir es benutzen'. Prospekte enthalten Mandatsdetails. KIIDs enthalten Produktstruktur. IC-Memos und Prüfer-Antworten enthalten das Denken des Hauses. Diese Inhalte an eine fremde Frontier-Modell-API zu schicken, stellt sie unter die Reichweite einer anderen Jurisdiktion, erhöht das IKT-Drittanbieter-Konzentrationsrisiko unter DORA und führt - in der BaFin-Lesart - KI als IKT-Risiko ein, das entsprechend gemanagt werden muss.

Lokale Inferenz beseitigt die Frage. Die Gewichte liegen auf Festplatten, die das Haus kontrolliert. Die GPU steht in einem Rack, auf das das Haus physisch zeigen kann. Prompts und Completions bleiben innerhalb der Netzwerkgrenze. Retrieval, Agenten-Loops und MCP-Server laufen neben dem Modell im selben Perimeter. Das buy-side-Ergebnis ist, dass eine KI-Fähigkeit - Entwurfsarbeit, Extraktion, Retrieval-belegte Antworten, strukturiertes Parsen - gegen das sensitivste Material des Hauses eingesetzt werden kann, ohne die Datenresidenz-Haltung des Hauses zu verändern.

Use Cases, in denen das entscheidend ist: Prospekt- und KIID-Extraktion, IC-Memo-Entwürfe, interne Compliance-Q&A über die Richtlinien des Hauses, Vorbereitung regulatorischer Meldungen und jeder Workflow, in dem die Kosten eines einzigen Inhalts-Leaks die Kosten für den Betrieb der GPUs über ein Jahr übersteigen.

DORA Art. 28-30 verlangt von Häusern, IKT-Drittanbieter-Risiken zu managen, einschließlich Konzentration. Die einfachste Antwort ist, den Dritten im Request-Pfad ganz zu vermeiden. Die BaFin-Leitlinie vom Dezember 2025 behandelt KI als ein IKT-Risiko, das im bestehenden DORA-Rahmen zu managen ist - mit ausdrücklicher Aufmerksamkeit für Datenflüsse. CSSF- und FINMA-Erwartungen zur Datenresidenz für luxemburgische und schweizerische Vehikel weisen in dieselbe Richtung. Der EU AI Act ergänzt Pflichten zur Technischen Dokumentation zu Datenherkunft und Lebenszyklus.

Ein Local-Inference-Deployment wandelt diese Pflichten in eine sichtbare Eigenschaft der Architektur. Die Aufsicht kann den Datenfluss verfolgen: rein bleibt drin, raus passiert nicht. Die Anbieterbeziehung reduziert sich auf den Hardware-Lieferanten und das Open-Weight-Modell-Release - beide ersetzbar, keiner zur Laufzeit im Request-Pfad. Die KI-Fähigkeit ist mit DORA-Konformität und einer 'Daten bleiben im Haus'-Garantie gepaart - nicht als Marketing-Anspruch, sondern als Eigenschaft des Ortes, an dem die GPUs verbaut sind.

Wir beginnen mit einer Hardware-Sizing-Übung gegen die tatsächliche Workload. Ein 7B-13B-Modell auf einer einzelnen L40S oder 4090 bewältigt die meisten Entwurfs- und Extraktionsaufgaben mit Produktionslatenz. Ein quantisiertes Modell der 70B-Klasse auf einer einzelnen H100 80GB bedient schwerere Retrieval- und Reasoning-Workloads mit 16-32k Token Kontext bei nutzbaren Batch-Größen. Wir dimensionieren für Steady-State-Batch und Peak-Concurrency, nicht für einen einzelnen Nutzer, weil die Wirtschaftlichkeit beim Batch kippt.

Modelle werden mit vLLM hinter einem internen Gateway bedient. Das Quantisierungsformat wird je Workload gewählt - Q5_K_M oder AWQ-INT4 für die 70B-Klasse auf einer einzelnen H100, natives bf16 oder FP8, wo die Workload es rechtfertigt. Gewichte liegen in einer versionierten Registry im Perimeter; ein Modell-Swap ist ein Deployment, kein Anbieterwechsel. Wir pinnen Modell- und Tokenizer-Versionen pro Release und schreiben die Versionen in jede Audit-Zeile, sodass das EU-AI-Act-Anhang-IV-Abschnitt-6-Lebenszyklus-Log von der Runtime erzeugt wird statt von Hand gepflegt.

Um den Inferenz-Server herum verdrahten wir den Rest des im Perimeter ansässigen Stacks: den Retrieval-Index, die MCP-Server, die Agenten-Runtime mit ihren Freigabe-Gates, das strukturierte Audit-Log. Die Grenze ist eine Netzwerkzone; das Sprachmodell ist ein Prozess darin. Kein ausgehender Aufruf an einen oeffentlichen Modellanbieter existiert im Request-Pfad.

Für Workloads, in denen ein Frontier-Modell wirklich erforderlich ist - selten in regulierter Entwurfsarbeit - betreiben wir einen separaten gegateten Egress mit Payload-Beschränkungen und einem expliziten Abweichungs-Log. Die Voreinstellung ist lokal. Die Abweichung ist die Ausnahme, die begründet werden muss.

Akzeptieren Sie kein 'Private-AI'-Marketing, das immer noch über ein gemanagtes Gateway routet. Ein gemanagter KI-Dienst, der von einem fremden Hyperscaler gehostet wird, ist - unabhängig von der Region - keine lokale Inferenz. Die Gewichte gehören Ihnen nicht, der Request-Pfad gehört Ihnen nicht, und das IKT-Drittanbieter-Konzentrationsrisiko unter DORA Art. 28 ist unverändert.

Verwechseln Sie Edge, Local und On-Prem nicht. Edge bedeutet Inferenz auf einem Client-Gerät. Local bedeutet innerhalb Ihres Netzwerks. On-Prem bedeutet innerhalb von Hardware, die Sie besitzen. Sie haben unterschiedliche Bedrohungsmodelle und unterschiedliche Kostenkurven. Wählen Sie diejenige, die Ihr Aufsichtsschreiben tatsächlich beschreibt.

Überspringen Sie nicht die Quantisierungswahl. Ein naives bf16-Deployment eines 70B-Modells auf Hardware, die für Q5_K_M dimensioniert ist, wird unter Last schlicht versagen, und das Team wird folgern, dass lokale Inferenz 'nicht funktioniert'. Das Quantisierungs-Rezept ist Teil des Designs, kein Nachgedanke.

Lassen Sie das GPU-Rack nicht zu einer undokumentierten Abhängigkeit werden. Es gehört in den DR-Plan, das BCM-Register und das IKT-Inventar wie jede andere kritische Infrastruktur. Der Sinn lokaler Inferenz ist, das Modell in den bestehenden Kontrollrahmen zu holen - nicht, einen parallelen zu schaffen.