Goのプロセス内推論とAPI提供を一つにするKronk

Kronkが隠す推論エンジンの境界

Kronkはハードウェアアクセラレーションを使うローカル推論のGo SDK兼モデルサーバーです。Pythonや別のモデル提供スタックを必須にせず、Go APIからネイティブ推論エンジンを扱う構成を取ります。Kronk本体はllama.cppとyzmaを通じてテキスト、画像、embedding、rerankingモデルを扱い、Buckyはwhisper.cppとbuckyを通じて音声から文字へ変換します。Malinaはstable-diffusion.cppとmalinaを使う実験的な画像生成SDKですが、モデルサーバーには統合されていません。

SDKとモデルサーバーの選び分け

SDKはGoプロセス内で推論を実行し、モデルのロードと寿命を直接制御したい場合の経路です。サーバーは一つまたは複数のクライアントへHTTP APIを出し、ブラウザからモデルを管理して試せます。サーバーはChat Completions、Responses、embeddings、reranking、音声転写についてOpenAI互換の形を掲げ、Anthropic互換のMessages APIも含みます。互換性はエンドポイントと入力形式の範囲を示すもので、各モデルの出力品質や全SDK機能まで同一という意味ではありません。

Homebrewからlocalhostまで

macOSとLinuxではHomebrewが推奨され、brew install ardanlabs/kronk/kronkの後にkronk server startを実行します。Goが使える対応プラットフォームではgo install github.com/ardanlabs/kronk/cmd/kronk@latestでもCLIを入れられます。起動後はlocalhost:11435でモデル管理とBrowser UIを開きます。最初のモデルやSDK例を動かす際、互換性のあるネイティブライブラリとモデルファイルを自動取得する場合があります。取得先、保存場所、ネットワーク遮断時の挙動は、実行前に運用環境で確かめるべきです。

ローカル実行で変動する要素

Kronkの実際の速度は、内蔵エンジン、CPUやGPU、モデルの量子化、コンテキスト長、同時実行数に左右されます。READMEは対応プラットフォームと上流エンジンの変更がプロジェクト状態に影響し得ると説明しています。よってSDKとサーバーの選択だけで性能を予測できません。テストでは同じモデルファイルと入力を使い、初回ロード時間、常駐メモリ、生成速度、長文入力時の失敗を別々に記録します。音声転写と画像生成はKronk本体と違う部品を通るため、個別の測定が必要です。

運用前に見るマニュアルと接続先

コンテナ配置、永続ストレージ、本番設定はmanualのContainer Quick Startへ分けられています。Go APIの詳細はpkg.go.dev、例はexamples、モデル管理はマニュアルのモデルサーバー章にあります。OpenWebUI、OpenCode、Claude Codeとの統合も説明されていますが、接続時にどのAPI互換層を使うかを確認してください。Apache-2.0のコード利用条件と、取得するモデルや上流エンジンのライセンスは別に確認します。導入判定は、選んだモデルでAPIのエラー、ログ、停止時のプロセス終了を確認した結果に基づけるべきです。

API互換性をモデル単位で測る

Kronkをサーバーとして採用する場合、互換APIの名前だけで既存クライアントが動くと判断しないことが重要です。Chat CompletionsとResponsesで同じモデルを呼び、streaming、tool call、画像入力、embedding、reranking、音声転写を機能ごとに分けて確認します。モデル管理画面でダウンロードしたファイルの保存先とサイズを記録し、server stop後にネイティブ推論プロセスが残らないかを調べます。SDK利用では同じ入力をプロセス内で実行し、サーバー経由との出力、初回ロード、常駐メモリを比較します。OpenAI互換とAnthropic互換の認証やエラー形式もクライアントの想定に合わせて確認し、APIキー、localhost以外への公開、ログに入力を残す設定を運用前に決めます。

モデル取得後の停止まで確認する

Kronkを初めて起動した環境では、kronk server startの直後にlocalhost:11435へ接続し、Browser UIでモデルの一覧と保存先を確認します。小さなテキストモデルで初回ロードと二回目の応答を分けて測り、streamingを途中で切断したときにプロセスと一時ファイルが残るかを調べます。Buckyでは短い音声、MalinaではSDKの最小例を使い、サーバーに存在しない機能を呼ばないようにします。brew版とgo install版を混在させず、llama.cpp、whisper.cppなど上流の版も保存します。コンテナ運用へ移す場合はmanualの永続ストレージ手順に沿い、入力ログとモデルファイルの公開範囲を確認します。

ローカルサーバーの資源を記録する

kronk server startでlocalhost:11435を開き、モデルの保存先、初回ロード時間、常駐メモリ、停止後のプロセスを確認します。Chat Completions、Responses、embedding、reranking、音声転写を別テストにし、SDKとHTTPの出力を比較します。Homebrew版とGo版を混在させず、モデルと上流エンジンの版を保存します。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。 Kronk本体、Bucky、Malinaは別の上流エンジンを通るため、同じ性能指標でまとめません。サーバーをネットワークへ公開する場合は、Browser UI、モデル管理、OpenWebUI連携のアクセス範囲とログの扱いを個別に確認します。

編集部の結論

Goアプリケーション内でモデルの読み込みと寿命を管理したい人、または複数クライアントへHTTPで推論を公開したい人に向きます。導入前には対象OSのネイティブライブラリ、モデル形式、GPU経路、localhostの認証設定を確認し、実モデルでメモリと応答時間を測ってください。

公式情報源

1. Official README
2. Project repository
3. Release notes