Lokale Inferenz · Multimodal · Rust
Werk1112 bringt Text-, Bild-, Video- und Audiomodelle in eine gemeinsame CLI und einen HTTP-Dienst. Modelle entdecken, ein passendes Backend wählen und Inferenz auf eigener Infrastruktur betreiben.
Installationsanleitung und technische Dokumentation auf Englisch.
Runtime
Typisierte Anfragen werden passend zu Modell, Aufgabe, installierter Runtime und den Fähigkeiten des Rechners weitergeleitet. Optionale Adapter binden externe Anbieter ein; deren Zugangsvoraussetzungen und Kosten gelten weiterhin.
Kompatible Modelle, Hardware und Runtimes selbst wählen, digitale Souveränität stärken und die Abhängigkeit von bezahlter, extern betriebener Inferenz verringern. Geeignete lokale Abläufe funktionieren offline, sobald Modelle, Runtimes und Abhängigkeiten eingerichtet sind. Downloads und externe APIs benötigen eine Netzwerkverbindung.
Vorhandene Dateien importieren, externe Modellgewichte verknüpfen oder kompatible Hugging-Face-Repositories in einen gemeinsamen Modellspeicher laden. Typisierte Befehle für Chat, Vision, Bild, Video und Audio nutzen die jeweils benötigten Runtimes.
Backends automatisch oder gezielt auswählen und mit werk inspect und
werk doctor Voraussetzungen und Routing-Hindernisse prüfen.
Planungsschätzungen garantieren nicht, dass ein Modell in den Speicher passt oder ausführbar ist.
Unterstützte Worker durch Vorabladen beim Start
im Speicher halten, Aktivitäten mit werk top prüfen und
Prometheus und Grafana
anbinden. Kapazität und Parallelität hängen vom Backend und den verfügbaren Ressourcen ab.
Backend-spezifisches CPU/GPU-Offloading sowie Platzierungs- und Cache-Einstellungen nutzen, soweit implementiert. Residente Modellgewichte, Prefix-/KV-Wiederverwendung und SSD-Expert-Caches erfüllen unterschiedliche Aufgaben. KV-Zustände sind nicht zwischen beliebigen Runtimes übertragbar.
Embedding-, Reranking- und Klassifikations-Endpunkte mit kompatiblen Modellen und installierten Pooling-Runtimes nutzen. Die Embedding-API akzeptiert Text und liefert Float-Ausgaben; Reranking und Klassifikation folgen ihren dokumentierten Schnittstellenverträgen.
Schnellstart
Werk für Linux, macOS oder Windows installieren und passende Treiber, Runtime und Modell separat einrichten. Für ein lokales GGUF-Chatmodell einen llama.cpp-Build wählen, der dessen Architektur unterstützt. Details stehen im Backend-Leitfaden.
werk backend list
werk import /absolute/path/to/model.gguf --name local-model
werk doctor --model local-model
werk chat local-model --max-tokens 128Den Pfad durch die eigene Modelldatei ersetzen. Modell, Runtime und Hardware müssen zusammenpassen.
Einen Schlüssel erzeugen und vor dem Start des Dienstes den Platzhalter damit ersetzen
(Beispiel für eine POSIX-Shell). Kompatible OpenAI-Clients mit
http://127.0.0.1:11434/v1 und demselben Schlüssel konfigurieren.
werk auth api-key generate
export WERK_API_KEY="replace-with-generated-key"
werk serve --model local-model
Für mehrere installierte Textmodelle lädt werk serve --preload model-a model-b
die Modelle der Reihe nach und führt nach Möglichkeit ein Warmup durch. Erfolgreich geladene
Worker bleiben bis zum Beenden im Speicher; nicht unterstützte Pfade und Ressourcenfehler
werden protokolliert und übersprungen. Bild-, Video- und Audiogenerierung werden dadurch
nicht generell vorgewärmt.
Hardware & Backends
Dies sind dokumentierte Integrationspfade. Die Ausführung hängt weiterhin von Architektur, Checkpoint, Plattform und installierter Runtime ab. Die Modellerkennung deckt mehr Modelle ab als die ausführbaren Adapter.
Kompatible CPU-Pfade über llama.cpp, Candle oder ONNX sowie llama.cpp CUDA und geeignete vLLM/Python-Runtimes nutzen. Linux ist der primäre CUDA-Pfad; Windows benötigt eine passende Toolchain, WSL2 wird nach Möglichkeit unterstützt und lokales vLLM setzt natives Linux voraus. Details in der Plattformmatrix.
Kompatible Adapter für llama.cpp Metal, MLX/MLX-VLM oder oMLX unter macOS wählen. Verwaltetes oMLX benötigt macOS 15 oder neuer. Unified Memory ist gemeinsam genutzter physischer Speicher; Budgets und Offload-Einstellungen garantieren nicht, dass ein Modell hineinpasst. Siehe Runtime-Anforderungen.
AMD Strix Halo bietet native Linux-Pfade über ROCm/HIP und Vulkan, jedoch keinen NPU-Adapter. DGX Spark / GB10 verwendet ein Spark-spezifisches Linux-aarch64-Profil ohne native TensorRT-LLM- oder NIM-Adapter. Für beide Integrationen stehen die grundlegenden Tests auf echter Hardware noch aus.
Deployment-Profile für einzelne Rechner konfigurieren unterstützte lokale CUDA-GPU-Gruppen, Aliasse und Replikate. Läufe auf Multi-GPU-Hardware sind weiterhin unbestätigt. Diese Profile bieten weder Cluster über mehrere Rechner noch gemischtes NVIDIA/AMD-Sharding.
Schnittstellen
Für Vorhaben zur digitalen Souveränität ermöglichen die dokumentierten API-Teilmengen, vorhandene kompatible Clients an einen selbst betriebenen Werk-Dienst anzubinden. Agentenschleifen und Workflow-Ausführung liegen bei den Client-Anwendungen; Werk bleibt eine Inferenz-Runtime und ein Router.
Chat Completions unter /v1/chat/completions und Messages unter
/v1/messages für die dokumentierten Text-, Vision-, Streaming- und
clientseitigen Tool-Abläufe nutzen. Es handelt sich um
kompatible Teilmengen;
die OpenAI Responses API ist nicht implementiert.
OpenAI-inspirierte und Werk-eigene Routen für Medien, Jobs und Dateien nutzen, ergänzt um kleine Kompatibilitätsbereiche für ComfyUI/AUTOMATIC1111. Separate Routen des Werk Protocol 1.0 bieten Zugriff auf Fähigkeiten, Zustände und Speichersteuerung. Vor optionalen Operationen die Unterstützung prüfen.
Optionale ComfyUI-Nodes (Beta) oder manuell installierte n8n-Nodes (Beta) für native Medien- und Runtime-Steuerung anbinden. Bei Dokument- und Dateieingaben gelten weiterhin die jeweiligen Format- und Runtime-Grenzen.
Dokumentation
Die Projekt-README ist bewusst kurz. Die englischsprachige, versionierte Dokumentation beschreibt API-Verträge, Backend- und Betriebssystemunterstützung, Fallback-Verhalten, Medienaufgaben und bekannte Einschränkungen im Detail.
Alle Routen, Felder, Antworten, unterstützten Aufgaben, Authentifizierung, Jobs, Aufbewahrung und Kompatibilitätslücken.
Versionierte Runtime-Steuerung, tatsächliche Backend-Fähigkeiten, opake Zustände, Speicherdruck und Grenzen zwischen Prefill und Decode.
Routing, Fallback-Regeln, verwaltete Installation, Plattformunterstützung, Qwen-TTS und Bereinigung.
Kanonische Bild-, Video- und Audioaufgaben, Modellstrukturen, Parameter, Planung und Beispiele.
Werk1112 installieren, ein Modell hinzufügen, lokale Inferenz ausführen und den authentifizierten HTTP-Dienst starten.
Globale Optionen, Befehle, Modellverwaltung, Wartung, Diagnosen, Inferenz und Serverbetrieb.
Importe, Verknüpfungen externer Modellgewichte, Downloads, Manifeste, Modellauswahl, verwalteter Speicher und optimierte Artefakte.
Lokale CUDA-GPU-Gruppen, Aliasse, Replikate, Zulassungs- und Parallelitätsgrenzen sowie Stand der Hardwarevalidierung.
Genaue Modellidentitäten, lokale und gehostete Pfade, Abhängigkeiten, Zugangsvoraussetzungen und Inferenzprüfung.
Ökosystem
Werk1112 konzentriert sich auf lokale KI-Infrastruktur und Backend-Routing, ohne selbst eine Workflow-Engine zu werden.
Werk1112 wird von Philip Bodenbach im GitHub-Repository philipbodenbach/werk1112 entwickelt.