Kronk: Go-SDK und Modellserver für lokale Inferenz mit llama.cpp
Ihre persönliche Engine zum lokalen Ausführen von Open-Source-Modellen. Verwenden Sie Go für hardwarebeschleunigte lokale Inferenz mit llama.cpp und whisper.cpp, die direkt in Ihre Go-Anwendungen integriert sind. Kronk bietet eine High-Level-API und einen Modellserver.
Auf einen Blick
- Was ist das?
- ardanlabs/kronk bündelt Kronk, Bucky und Malina zu einem Go-SDK samt Modellserver mit OpenAI- und Anthropic-kompatiblen Endpunkten. Einordnung von Installation, GPU-Backends und Versionsbindung v1.32.3.
- Für wen ist es gedacht?
- Kronk passt zu Go-Teams, die Text-, Bild- oder Audioinferenz ohne Python und ohne separaten Serving-Stack in die eigene Anwendung holen wollen, sowie zu Betrieben, die einen lokalen Server mit OpenAI- und Anthropic-kompatiblen Endpunkten für OpenWebUI oder Claude Code suchen. Weniger geeignet ist es für Umgebungen, die über lange Zeit stabile Schnittstellen brauchen, weil die README Versionsbrüche in den ggml-Bibliotheken ausdrücklich einräumt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Kronk, Bucky und Malina über llama.cpp und whisper.cpp
Kronk ist ein Go-SDK samt Modellserver für hardwarebeschleunigte Inferenz auf dem eigenen Rechner. Laut README bringt das Projekt drei Teile mit. Kronk selbst bedient Text-, Vision-, Embedding- und Reranking-Modelle über llama.cpp und das Modul yzma. Bucky übernimmt Spracherkennung über whisper.cpp. Malina ist ein experimentelles SDK für Bilderzeugung, aufgesetzt auf stable-diffusion.cpp.
Eine Python-Installation oder ein separater Serving-Stack ist nach Auskunft des README nicht erforderlich.
Das Repository ardanlabs/kronk steht unter Apache-2.0, erreicht 764 Sterne und 55 Forks bei 8 offenen Issues. Release v1.32.3 erschien am 27. August 2026, v1.32.2 und v1.32.1 am Tag davor.
brew install ardanlabs/kronk/kronk und kronk server start
Für die Installation empfiehlt das README unter macOS und Linux Homebrew mit dem vollqualifizierten Formelnamen brew install ardanlabs/kronk/kronk. Diese Schreibweise ist bewusst gewählt: Sie vertraut ausschließlich der Kronk-Formel und nicht allen Paketen im Tap ardanlabs/kronk. Danach startet kronk server start den Modellserver.
Auf jeder unterstützten Plattform führt der Weg auch über go install github.com/ardanlabs/kronk/cmd/kronk@latest.
Unter http://localhost:11435 erreicht man nach dem Start die Browser-Oberfläche zum Verwalten der Modelle. Beim ersten Modell oder Beispiel lädt Kronk laut README die passenden nativen Bibliotheken und die Modelldateien von selbst.
localhost:11435 mit Chat Completions, Responses und Messages API
Der Modellserver stellt laut README OpenAI-kompatible Schnittstellen für Chat Completions, Responses, Embeddings, Reranking und Audiotranskription bereit, ergänzt um eine Anthropic-kompatible Messages API. Damit lassen sich Werkzeuge anbinden, die eines dieser Formate sprechen; genannt werden OpenWebUI, OpenCode und Claude Code.
Hinzu kommen eine Browser-Oberfläche, Modellverwaltung, Sicherheitsfunktionen sowie Beobachtbarkeit mit Metriken und Tracing. Authentifizierung und Ratenbegrenzung ordnet das README dem Server zu, nicht dem SDK.
Eine Ausnahme gilt für Malina: Das Bilderzeugungs-SDK ist im Modellserver nicht eingebunden und bleibt experimentell, seine öffentliche API kann sich ändern.
Entscheidungshilfe im README: Go-SDK oder Kronk-Modellserver
Das README stellt beide Betriebsarten gegenüber. Für das SDK sprechen Inferenz innerhalb eines Go-Prozesses, unmittelbare Kontrolle über Laden und Lebensdauer eines Modells, kein zusätzlicher Serverprozess sowie anwendungsspezifische Pufferung und Nebenläufigkeit. Für den Modellserver sprechen HTTP-Schnittstellen für mehrere Clients, die kompatiblen APIs, die Verwaltung im Browser sowie Authentifizierung, Ratenbegrenzung, Metriken und Tracing.
Weil der Server aus denselben öffentlichen SDKs gebaut ist, die auch Go-Anwendungen nutzen, bedeutet ein späterer Wechsel keine zweite API.
Zum Funktionsumfang des SDK zählen laut README Textgenerierung, Streaming, Reasoning, Werkzeugaufrufe, Vision, Embeddings, Reranking, parallele Verarbeitung und inkrementelles Zwischenspeichern von Nachrichten.
CUDA, Vulkan, HIP, ROCm, SYCL und Metal je Betriebssystem
Welche Hardwarebeschleunigung verfügbar ist, hängt laut README von Betriebssystem, Architektur, Inferenz-Engine und Bibliotheksbündel ab; Kronk lädt die zum installierten Release passenden nativen Bibliotheken. Unter Linux stehen amd64 und arm64 bereit, als GPU-Backends CUDA, Vulkan, HIP, ROCm und SYCL. macOS ist auf arm64 mit Metal begrenzt. Windows läuft auf amd64 mit CUDA, Vulkan, HIP, SYCL oder OpenCL.
Nicht jedes Backend ist für jedes SDK und jede Architektur verfügbar. Als verbindliche Quelle nennt das README ausdrücklich die Bibliotheksverwaltung von CLI oder SDK in der installierten Version, nicht diese Übersicht.
Wie eng die Bindung ist, zeigt ein Eintrag der Kompatibilitätstabelle: Zu llama.cpp v0.3.0-b10646 gehört yzma v1.25.0 ab Kronk 1.32.3.
Versionsbindung: yzma v1.25.0, bucky v1.1.0 und malina v1.0.5
Der Projektstatus ist der heikelste Punkt des Konzepts. Kronk folgt den eingebundenen nativen Engines, und Änderungen dort können abgestimmte Releases von yzma, bucky, malina und Kronk erzwingen. Das README rät deshalb, für jedes Teilsystem dessen eigenen Downloader zu nutzen und keine nativen Bibliotheken aus unterschiedlichen Releases zu mischen, weil jedes Kronk-Release an bekannte kompatible Bibliotheksversionen gebunden ist.
Die Tabellen führen diese Paare auf: whisper.cpp v1.9.3 mit bucky v1.1.0 ab Kronk 1.31.8, sowie stable-diffusion.cpp master-830-50d6405 mit malina v1.0.5 ab Kronk v1.32.2, letzteres mit dem Vermerk experimentell.
Wer Versionen von Hand zusammensetzt, verlässt den geprüften Pfad. Die Brüche sammelt eine Datei BREAKING_CHANGES.md im Repository.
make example-question, example-bucky-stream-vad und example-malina
Für den Einstieg hält das Repository ein Beispielverzeichnis mit passenden Make-Zielen bereit. make example-question stellt einem lokalen Sprachmodell eine Frage, make example-agent startet einen kleinen Programmier-Agenten, make example-vision befragt ein Vision-Modell mit einem Bild.
Auf der Audiospur transkribiert make example-bucky eine Datei, make example-bucky-stream-vad streamt die Erkennung mit Silero-VAD-Grenzen. make example-malina erzeugt ein Bild.
Beim ersten Lauf laden die Beispiele kompatible Bibliotheken und Modelle nach, was je nach Modellgröße dauern kann. Bucky beherrscht laut README neben der Transkription auch Übersetzung, kanalgetrennte Sprechertrennung und Live-Streaming. Malina bietet Text-zu-Bild, Bild-zu-Bild, Einzel- und Mehrdatei-Pipelines sowie Motion-JPEG-Kodierung.
llama.cpp direkt als Alternative zu Kronk und die Apache-2.0-Lizenz
Die naheliegende Alternative ist der Server von llama.cpp selbst. Er deckt den OpenAI-kompatiblen Textpfad ab und verlangt keine Abstimmung über yzma, bucky und malina. Kronk setzt dem ein Go-SDK für Inferenz im eigenen Prozess, eine Anthropic-kompatible Messages API, die Spracherkennung über Bucky und die Bilderzeugung über Malina entgegen, bezahlt das aber mit der Kopplung an vier Repositories und deren Release-Takt.
Für ein einzelnes Modell auf einem Server ist der direkt betriebene llama.cpp-Server der kürzere Weg; für eine Go-Anwendung oder für Audio und Bild ist Kronk die breitere Grundlage.
Die Lizenz ist Apache-2.0 mit Patentregelung, Gewährleistung und Support ausgeschlossen. Offen bleiben Durchsatzangaben, Speicherlast bei parallelen Anfragen und die Stabilität von Malina.
Redaktionelles Fazit
Kronk passt zu Go-Teams, die Text-, Bild- oder Audioinferenz ohne Python und ohne separaten Serving-Stack in die eigene Anwendung holen wollen, sowie zu Betrieben, die einen lokalen Server mit OpenAI- und Anthropic-kompatiblen Endpunkten für OpenWebUI oder Claude Code suchen. Weniger geeignet ist es für Umgebungen, die über lange Zeit stabile Schnittstellen brauchen, weil die README Versionsbrüche in den ggml-Bibliotheken ausdrücklich einräumt. Vor dem Einsatz lohnt der Blick auf localhost:11435 nach kronk server start: prüfen, ob das eigene GPU-Backend erkannt wird, und mit make example-question kontrollieren, welche llama.cpp-Bibliothek zu v1.32.3 geladen wurde.
Community-Notizen