On-Premise KI-Infrastruktur | Einzelbinär-Deployment | Lexiane
On-Premise KI im einzelnen statischen Rust-Binär. Kein Python, kein Docker. Air-Gapped, Cloud oder Hybrid-Deployment. Kubernetes-kompatibel.
Ein KI-System in der Produktion einzusetzen ist nicht nur eine Frage des Modells. Es ist eine Frage der Infrastruktur: Wie das Binär installiert wird, welche Abhängigkeiten es einführt, welche Angriffsfläche es schafft, welche Ressourcen es verbraucht, wie es sich unter Last verhält und wie es in Ihre bestehende Umgebung integriert wird.
Die meisten KI-Frameworks beantworten diese Fragen nachträglich — Leistung, Sicherheit und Betreibbarkeit sind Einschränkungen, die nach der Werkzeugauswahl zu managen sind. Lexiane geht vom umgekehrten Prinzip aus: Infrastruktureigenschaften sind Architekturentscheidungen, die im Vorfeld getroffen und in der Produktion nicht verhandelbar sind.
Das Infrastrukturproblem, das Python strukturell aufzwingt
Die dominierenden RAG-Frameworks — LangChain, LlamaIndex, Haystack — sind in Python geschrieben. Ihr funktionaler Reichtum ist real. Aber die Infrastrukturwahl, die sie aufzwingen, sind strukturelle Einschränkungen, die weder Versionen noch Optimierungen noch Best Practices beseitigen können.
Der Interpreter und seine Umgebung. Python benötigt einen Interpreter, einen Paketmanager, eine virtuelle Umgebung und eine Reihe von Systemabhängigkeiten. Ein minimales Docker-Image für einen Python-RAG-Stack liegt zwischen 500 MB und 1 GB. Der Kaltstart eines Python-Dienstes mit seinen Abhängigkeiten dauert mehrere Sekunden. In einer Air-Gapped-Umgebung ist die Installation von pip ein operationelles Sicherheitsproblem — keine Entwicklungsunannehmlichkeit.
Der GIL und die Nebenläufigkeit. Der Global Interpreter Lock von Python serialisiert parallele Operationen auf der Interpreterebene. Ein Python-RAG-Dienst, der mehrere gleichzeitige Anfragen verarbeitet, führt eine Kontention ein, die weder Threads noch Prozesse ordentlich lösen — Threads blockieren sich gegenseitig, Prozesse multiplizieren den Speicherverbrauch.
Pipeline-Latenz. Veröffentlichte Messungen zeigen den Overhead einer Python-RAG-Pipeline zwischen 10 und 22 ms pro Aufruf, ohne Inferenzzeit. Bei hohem Volumen akkumuliert sich diese Reibung und wird zu einem architektonischen Engpass.
Abwesenheit von zeitlichem Determinismus. Python delegiert die Speicherverwaltung an einen Garbage Collector. In der Produktion treten unter Last unvorhersehbare GC-Pausen — einige Dutzend bis einige Hundert Millisekunden — auf. In einem eingebetteten System, einem Echtzeitsystem oder jedem System mit SLA-Latenzanforderungen ist dieses Verhalten inakzeptabel.
Rust eliminiert jede dieser Einschränkungen durch Konstruktion. Lexiane erbt sie als fundamentale Eigenschaften — nicht als hinzugefügte Optimierungen.
Ein einziges Binär: Was das konkret bedeutet
Lexiane kompiliert zu einem autonomen statischen Binär. Eine einzige ausführbare Datei enthält das gesamte System: die Pipeline-Engine, den HTTP-Server, die SSE-Streaming-Schnittstelle, den Dokumentparser, die lokale Embedding-Engine (Candle), die lokale LLM-Inferenz-Engine (Mistral.rs), die In-Memory-Vektordatenbank und die Konfigurationsschnittstelle.
Diese Wahl ist keine Implementierungseinschränkung. Es ist eine Architekturentscheidung mit direkten operationellen Konsequenzen.
Triviales Deployment. Ein Binär und eine Konfigurationsdatei kopieren: Das ist alles, was ein Lexiane-Deployment erfordert. Kein Paketmanager, keine virtuelle Maschine, kein zu orchestrierender Nebenprozess. Das System ist in wenigen Sekunden betriebsbereit.
Minimale Angriffsfläche. Jede externe Abhängigkeit ist ein potenzieller Angriffsvektor. Ein statisches Binär ohne dynamische Abhängigkeiten exponiert keine Fläche, die mit gemeinsamen Systembibliotheken, versionierten Paketen oder Nebenprozessen verbunden ist. Die Angriffsfläche wird durch das Binär selbst begrenzt — auditierbar, fixiert, reproduzierbar.
Reproduzierbarkeit der Deployments. Dasselbe Binär, kompiliert aus demselben Quellcode mit demselben Compiler, produziert dasselbe Verhalten unabhängig von der Zielumgebung. Es gibt keine Drift durch unterschiedliche Abhängigkeitsversionen zwischen Entwicklungs-, Test- und Produktionsumgebungen.
Minimaler Footprint. Ohne Python-Laufzeit, ohne virtuelle Maschine, ohne Ausführungsumgebung ist der Speicher-Footprint beim Start ein Bruchteil eines äquivalenten Python-Stacks. Docker-Images, die um das Lexiane-Binär herum aufgebaut werden, liegen in der Größenordnung von einigen Dutzend Megabyte — nicht einigen Hundert.
Drei Deployment-Modi, eine einzige Architektur
Die À-la-carte-Architektur von Lexiane passt sich Ihrer bestehenden Infrastruktur an — nicht umgekehrt. Drei Konfigurationen decken die Gesamtheit der in Produktionsumgebungen anzutreffenden operationellen Einschränkungen ab.
Air-Gapped — totale Souveränität, null Netzwerkabhängigkeit
In seiner Air-Gapped-Konfiguration führt Lexiane keine ausgehenden Netzwerkaufrufe durch. Die gesamte Pipeline wird lokal ausgeführt: Dokumentenparse durch den nativen Rust-Parser, Embedding-Berechnung durch Candle, LLM-Inferenz durch Mistral.rs, Vektorspeicherung in der lokalen Infrastruktur.
Dieser Modus ist für Umgebungen konzipiert, in denen Netzwerkkonnektivität durch Architektur fehlt — klassifizierte Netzwerke, SCIFs, souveräne Rechenzentren, isolierte Industriestandorte, eingebettete Systeme. Es handelt sich nicht um einen Degraded-Modus: Es ist der Referenzmodus, für den Lexiane in erster Linie konzipiert wurde — und die Grundlage des souveränen privaten RAG.
Infrastruktur-Anforderungen:
- Einen Linux-Server (x86_64 oder ARM64) mit dem dem Dokumentvolumen angepassten Ressourcen
- Eine optionale GPU für die Beschleunigung der lokalen Inferenz (signifikant für den Durchsatz, nicht blockierend in ihrer Abwesenheit)
- Die zum Deployment-Zeitpunkt vorher heruntergeladenen Modelle — kein Download zur Laufzeit
Was Sie deployen: ein Binär + eine TOML-Konfigurationsdatei + Modelldateien. Nichts anderes.
Cloud — Integration der besten Marktmodelle
In der Cloud-Konfiguration aktiviert Lexiane seine externen Adapter über Umgebungsvariablen: OpenAI oder Anthropic für die Generierung, OpenAI für die Embeddings, Qdrant oder pgvector für den Vektorspeicher, Cohere für das Reranking.
Die Verarbeitungs-Pipeline bleibt identisch mit der Air-Gapped-Konfiguration. Nur die Adapter ändern sich. Wenn Sie OpenAI durch Anthropic ersetzen oder von pgvector zu Qdrant migrieren, ändert sich die Pipeline nicht um eine Zeile — die Konfiguration ändert sich, nicht der Code.
Diese Eigenschaft ist fundamental für die operative Resilienz: Die Abhängigkeit von einem spezifischen Anbieter ist in einem Adapter lokalisiert, nicht diffus im gesamten System. Ein Anbieter, der seine Preise ändert, ein Modell abkündigt oder einen Dienstausfall erleidet, ist ohne Refactoring ersetzbar.
Unterstützte Integrationen:
| Rolle | Anbieter |
|---|---|
| Generierung (LLM) | OpenAI (GPT-4o, GPT-4) · Anthropic (Claude) |
| Embeddings | OpenAI (text-embedding-3) |
| Vector Store | Qdrant · pgvector (PostgreSQL) |
| Reranking | Cohere |
| Sparse-Suche | Tantivy (BM25, lokal) |
Hybrid — Datensouveränität, Cloud-Leistung
Die Hybrid-Konfiguration ist die häufigste in Umgebungen, die Datenschutzanforderungen mit Generierungsqualitätsanforderungen kombinieren.
Das Prinzip: Die sensiblen Operationen — Parsing, Embedding-Berechnung, Vektorspeicherung — werden lokal ausgeführt. Die Texterzeugung wird an ein Cloud-Modell delegiert, aber nur für die extrahierten Kontextfragmente — nie für die Quelldokumente. Ihre Dateien verlassen Ihren Perimeter nicht. Das Cloud-LLM erhält Auszüge, anonymisierbar, nicht Ihre Dokumentenbasis.
Diese Aufteilung ist durch die Stage-Architektur von Lexiane möglich: Jede Stufe ist eine unabhängige Komponente, deren Ausführung unterschiedlich lokalisiert werden kann. Die Grenze zwischen lokal und Cloud ist eine Konfigurationszeile — keine Code-Grenze.
Die interne Infrastruktur: Was Lexiane nativ integriert
HTTP-Server und SSE-Streaming
Lexiane integriert einen nativen HTTP-Server, der auf Axum aufgebaut ist, dem von Tokio entwickelten Rust-Web-Framework. Dieser Server exponiert eine Standard-REST-API für die Dokumentenaufnahme und -anfrage sowie eine SSE-Streaming-Schnittstelle (Server-Sent Events) für die Echtzeit-Restitution der token-für-token erzeugten Antworten.
Es ist kein externer Webserver erforderlich. Lexiane kann direkt hinter einem Reverse Proxy (Nginx, Caddy, Traefik) ohne zusätzliche Konfiguration platziert werden. Es funktioniert auch im Bibliotheksmodus — in ein bestehendes Rust-Programm integriert, ohne HTTP-Server.
Speicherschicht
Vektorspeicherung. Drei Optionen je nach Deployment-Einschränkungen:
- SQLite in-memory — für eingebettete Deployments oder Prototypen. Null Infrastruktur, null Netzwerklatenz.
- pgvector — PostgreSQL-Erweiterung für Umgebungen, die bereits über eine PostgreSQL-Infrastruktur verfügen. Der Vektorindex koexistiert mit Ihren relationalen Daten im selben Cluster.
- Qdrant — Dedizierte Vektordatenbank für umfangreiche Korpora, die optimierte Indexierungs- und Abrufleistung erfordern.
MetadataStore. Ein persistentes SQLite-Register zeichnet alle aufgenommenen Dokumente, ihre Sammlungen, ihre Metadaten und die Operationshistorie auf. Schema-Migrationen sind versioniert und werden beim Start automatisch angewendet — ohne manuelle Eingriffe, ohne Dienstunterbrechung.
GraphStore. Für Deployments mit aktiviertem GraphRAG-Modus gewährleistet Oxigraph die Persistenz des RDF-Triplestores. Der aus Dokumenten extrahierte Wissensgraph wird dauerhaft gespeichert, per SPARQL-Anfragen abfragbar und bei jeder neuen Aufnahme inkrementell angereichert.
Cache und Leistung
Der LRU-Cache-Decorator (CachedEmbeddingModel, CachedLLMEngine) kann auf jeden Embedding- oder Generierungsadapter aktiviert werden. Er pflegt einen In-Memory-Cache der letzten Anfragen — besonders effektiv für Embeddings häufiger Anfragen und Antworten auf wiederkehrende Fragen.
Dieser Decorator ist nicht an einen spezifischen Adapter gekoppelt: Er umhüllt jede kompatible Komponente, lokal oder in der Cloud. Die Aktivierung oder Deaktivierung des Caches berührt nicht den Rest der Pipeline.
Hybride Suche und Reranking
Der Tantivy-Sparse-Index (BM25) ist nativ im Binär integriert. Die hybride Suche — dense vektoriell und sparse lexikalisch — wird lokal ohne zusätzliche Infrastruktur ausgeführt. Die Ergebnisse der beiden Such-Modalitäten werden durch Reciprocal Rank Fusion vor dem Reranking fusioniert.
Der Reranking-Cross-Encoder (Cohere in der Cloud-Konfiguration oder ein lokales Modell in der Air-Gapped-Konfiguration) reklassifiziert die Ergebnisse nach echter semantischer Relevanz — jenseits der rohen Vektorsimilarität.
Beobachtbarkeit und Betrieb
Instrumentierung ohne Kopplung
Das Lifecycle-Hook-System (PipelineHooks) ermöglicht die Instrumentierung jeder Pipeline-Stufe ohne Code-Änderung. Vier Beobachtungspunkte werden exponiert: on_stage_start, on_stage_complete, on_stage_error, on_pipeline_complete. Jeder Callback empfängt den Stufennamen, ihren Status, ihre Dauer und strukturierte Metadaten.
Diese Hooks können jedes externe Monitoring-System speisen: Prometheus, Datadog, OpenTelemetry, Grafana oder ein internes Überwachungssystem. Beobachtbarkeit ist eine Pipeline-Eigenschaft, keine Abhängigkeit von einer spezifischen Monitoring-Infrastruktur.
Ausführungsmetriken
PipelineMetrics und StageMetrics exponieren aggregierte Timing-Daten nach jeder Ausführung: Dauer jeder Stufe, Gesamtdauer der Pipeline, Identifizierung fehlerhafter Stufen. Diese Daten ermöglichen die Erkennung von Leistungsregressionen, die Identifizierung von Engpässen und die Verfolgung der Systemverhaltensänderung im Laufe der Zeit.
Das Token-Verbrauchs-Tracking (UsageStats) wird im Pipeline-Kontext akkumuliert. In der Cloud-Konfiguration ermöglichen diese Daten die Überwachung und Budgetierung des API-Verbrauchs in Echtzeit — pro Anfrage, pro Dokumentensammlung oder über definierte Zeitfenster.
Healthcheck
Der HealthCheck-Port exponiert einen Systemzustandsverifizierungs-Endpunkt — interoperabel mit Container-Orchestratoren (Kubernetes, Nomad) und Load Balancern. Der Endpunkt gibt den Zustand jeder aktiven Komponente zurück: Vector Store, LLM, Embedding-Modell. Eine degradierte Komponente ist erkennbar, bevor sie die Benutzer beeinträchtigt.
Leistungsmerkmale
Die Leistungseigenschaften von Lexiane sind direkte Konsequenzen der Rust-Wahl — keine punktuellen Optimierungen.
Abwesenheit eines Garbage Collectors. Rust verwaltet den Speicher statisch. Es gibt keine GC-Pausen, keine unvorhersehbaren Latenz-Spitzen unter Last, kein nicht deterministisches zeitliches Verhalten. Was beim Last-Test gemessen wird, ist das, was in der Produktion auftritt.
Native Nebenläufigkeit. Das Nebenläufigkeitsmodell von Rust, basierend auf async/await mit der Tokio-Laufzeit, ermöglicht die Verarbeitung einer großen Anzahl gleichzeitiger Anfragen ohne Kontention auf der Interpreterebene. Jede Anfrage wird in einer unabhängigen asynchronen Aufgabe verarbeitet — ohne GIL, ohne Thread-Overhead.
Vorhersehbarer Speicher-Footprint. Ohne Laufzeit oder Ausführungsumgebung ist der Speicherverbrauch von Lexiane deterministisch und stabil. Er wächst unter prolongierter Last nicht unvorhersehbar.
Veröffentlichte Messungen zu Python-→-Rust-Migrationen in der Produktion illustrieren die Größenordnung der typisch beobachteten Gewinne: Discord reduzierte seinen CPU-Verbrauch um 80 % bei der Migration eines Dienstes von Python zu Rust. Cloudflare erzielte 25 % zusätzlichen Durchsatz bei halber CPU-Last. Dropbox viertelte die Last seiner Server auf seinen kritischen Pfaden. Diese Zahlen sind spezifisch für ihre Systeme — sie illustrieren jedoch eine Größenordnung, die mit den strukturellen Eigenschaften der Sprache konsistent ist.
Integration in Ihre bestehende Infrastruktur
Standard-REST-API
Lexiane exponiert eine dokumentierte REST-API für die Dokumentenaufnahme und -anfrage. Sie ist mit jedem HTTP-Client interoperabel — Webanwendungen, interne Tools, Integrationssysteme, Automatisierungsskripte. Es ist kein proprietäres SDK erforderlich.
Bibliotheksmodus
Lexiane kann direkt als Bibliothek in ein bestehendes Rust-Programm integriert werden. In diesem Modus gibt es keinen HTTP-Server: Die Pipeline wird programmatisch im selben Prozess instanziiert und aufgerufen. Dieser Modus eignet sich für tiefe Integrationen in bestehende Systeme, bei denen die REST-API eine unnötige Indirektion einführen würde.
Konversationelle Sitzungen
Der Lexiane-Server pflegt persistente konversationelle Sitzungen mit Verlauf. Jede Sitzung bewahrt den Kontext der vorherigen Austausche — spätere Antworten können frühere Fragen berücksichtigen, ohne dass der Client die vollständige Geschichte neu übermitteln muss. Im Agentischen RAG-Modus integrieren diese Sitzungen auch die Erinnerung an aufeinanderfolgende Reasoning-Iterationen.
Vier einsatzbereite Referenzkonfigurationen
Zur Beschleunigung der Integration wird Lexiane mit vier operationellen Referenzkonfigurationen geliefert. Jede ist ein vollständig kompilierbares Projekt — kein Dokumentationsbeispiel.
| Konfiguration | Anwendungsfall |
|---|---|
| Air-Gapped | Isoliertes Netzwerk, keine externe Konnektivität, 100% lokale Inferenz |
| Cloud | Maximale Leistung, OpenAI/Anthropic/Cohere-Integration, pgvector oder Qdrant-Speicherung |
| Hybrid | Lokale Embeddings, Cloud-Generierung, lokale Speicherung — Souveränität der Quelldaten |
| Generalist | Flexibler Ausgangspunkt, an jeden Kontext anpassbar |
Jede Konfiguration enthält die TOML-Referenzdatei, die dokumentierten Umgebungsvariablen und die explizit aufgelisteten Abhängigkeiten.
Häufige Fragen von Infrastruktur- und DevOps-Teams
Kann Lexiane in einem Docker-Container deployed werden? Ja. Das statische Lexiane-Binär erzeugt ein Docker-Image von einigen Dutzend Megabyte — im Vergleich zu den typischen 500 MB bis 1 GB eines äquivalenten Python-Stacks. Das Image enthält nur das Binär und die Konfigurationsdateien. Es ist mit allen Standard-Container-Orchestratoren kompatibel.
Unterstützt Lexiane Kubernetes? Ja. Der Healthcheck-Endpunkt ist mit den Readiness- und Liveness-Probes von Kubernetes interoperabel. Das Deployment als Deployment oder StatefulSet (je nach Speichermodus) ist Standard. Die Konfiguration über Umgebungsvariablen ist nativ kompatibel mit Kubernetes ConfigMaps und Secrets.
Was ist die minimale Hardware-Konfiguration für ein Produktions-Deployment? Im Cloud-Modus (Embeddings und Inferenz ausgelagert) unterstützt ein Server mit 4 Kernen und 8 GB RAM signifikante Dokumentenvolumina. Im Air-Gapped-Modus mit lokaler Inferenz hängen die Anforderungen vom gewählten LLM-Modell ab — quantifizierte 7B-Modelle laufen auf CPU mit 16 GB RAM, mit einer GPU für zufriedenstellende Generierungsleistungen.
Wie werden Updates ohne Dienstunterbrechung verwaltet? Datenbank-Schema-Migrationen sind versioniert und werden beim Start angewendet — ohne manuelle Eingriffe. Für Binär-Updates ist das Blue-Green- oder Canary-Deployment standardmäßig anwendbar: Das neue Binär initialisiert sich, wendet eventuelle Migrationen an und geht in Betrieb. Die Kompatibilität zwischen aufeinanderfolgenden Versionen wird aufrechterhalten.
Kann Lexiane auf ARM deployed werden? Ja. Das Lexiane-Binär kompiliert nativ für x86_64 und ARM64. Deployments auf ARM-Infrastruktur — Graviton-Server (AWS), Ampere, eingebettete Hardware — werden ohne Modifikation unterstützt.
Kann die TOML-Konfiguration von einem IaC-Tool verwaltet werden? Ja. Die Lexiane-Konfiguration ist eine statische TOML-Datei, in Git versionierbar und von jedem Infrastructure-as-Code-Tool manipulierbar — Terraform, Ansible, Helm oder hausgemachte Deployment-Skripte. Es gibt keine verteilte Konfiguration in einer externen Datenbank.
Sprechen wir über Ihre Infrastruktur.
Jedes Deployment hat seine eigenen Einschränkungen: Netzwerksicherheitsrichtlinie, Container-Orchestrator, Secret-Management-Richtlinie, Hochverfügbarkeitsanforderungen, Integration mit bestehenden Systemen. Wir bieten keine generische Konfiguration für Anforderungen an, die es nicht sind.
Wir bieten einen technischen Austausch über Ihre Umgebung, Ihre operationellen Einschränkungen und die entsprechende Lexiane-Konfiguration an.
Was Sie erwarten können:
- Eine Antwort innerhalb von 48 Geschäftsstunden
- Einen technischen Ansprechpartner, der die Deployment-Einschränkungen in regulierten Umgebungen und Produktionsarchitekturen kennt
- Eine ehrliche Bewertung der Übereinstimmung — einschließlich wenn die Entwicklung spezifischer Adapter erforderlich ist
→ Kontakt aufnehmen
Zugang zum Auditable Core anfragen
Melden Sie sich an, um benachrichtigt zu werden, wenn unser Core-Auditprogramm öffnet. Gemäß unserer Datenschutzrichtlinie wird Ihre geschäftliche E-Mail-Adresse ausschließlich für diese technische Kommunikation verwendet, ohne nachfolgende Marketingnutzung. Zugang über sicheres privates Register verteilt.
Kontakt aufnehmen