Paddler 検証: ggml 前提のセルフホスト LLM バランサーを採用すべき条件
Open-source LLM/VLM load balancer and serving platform for self-hosting LLMs (and VLMs) at scale 🏓🦙 Alternative to projects like llm-d, Docker Model Runner, etc but with less moving parts and simple deployments built around ggml ecosystem. Runs on CPU and GPU.
ひと目でわかる
- これは何？
- Paddler は llama.cpp を内蔵エンジンとして使う Rust 製の LLM/VLM ロードバランサー兼サービング基盤である。構成要素は balancer と agent の 2 つだけで、Kubernetes を前提としない自己完結バイナリという点が最大の特徴だ。
- 誰に向いている？
- Paddler が向くのは、llama.cpp の GGUF モデルを社内 GPU や CPU 上で動かしており、Kubernetes の運用チームを別に抱えたくない規模の組織だ。逆に、既に Kubernetes 上で llm-d や vLLM 系のスタックを回しているチーム、あるいはモデルごとに細かいスケジューリング制御を必要とするチームには向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 58 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Paddler が埋めるのは llama.cpp とアプリケーションの間の空白
llama.cpp 単体で推論サーバーを立てるのは難しくない。難しいのは、そのサーバーを複数ホストに広げ、リクエストを振り分け、モデルを差し替え、ホストを動的に増減させる部分だ。Paddler はこの層を担当する。README は対象読者として、機能に LLM 推論と embeddings を組み込みたいプロダクトチーム、LLM をスケールさせたい DevOps/LLMOps チーム、医療や金融のような機密データを扱う組織、トークン課金ではなくコストを予測可能にしたい組織を挙げている。共通するのは、閉源のモデルプロバイダから距離を置きたいという動機である。Paddler 自体は推論エンジンを新規に実装したわけではなく、内蔵の llama.cpp を呼び出す。したがって採用判断の中心は「推論の速さ」ではなく「複数ホストの運用をどれだけ単純化できるか」に置かれる。
balancer と agent、そして slot という 3 層のデータフロー
デプロイ可能なコンポーネントは balancer と agent の 2 つだけだと README は明言している。balancer は 3 つの役割を 1 プロセスで公開する。アプリケーションが接続する inference サービス、内部管理用の management サービス、そしてブラウザから状態を確認し推論を試せる web admin panel である。agent は通常は別インスタンスに置かれ、受け取ったリクエストをさらに slot へ分配する。slot が実際にトークンと embeddings を生成する単位になる。ここで重要なのは、Paddler が llama.cpp の slot をそのまま使うのではなく独自実装を持ち、各 slot が自前のコンテキストと KV キャッシュを保持するという記述だ。つまり slot 数はメモリ消費に直結する。agent 側で 4 slot を指定すれば、コンテキスト長の分だけ KV キャッシュが 4 系統必要になる。この構造は同時実行数の上限を slot 数で決めるという設計判断でもあり、リクエストが slot を埋めると後続は待たされる。README はリクエストバッファリングに触れており、ホストが 0 台の状態からスケールさせられるのはこの仕組みによる。
起動は 2 コマンド、設定はフラグと管理画面に分かれる
バイナリは GitHub releases から取得するか、ソースからビルドする。MSRV は 1.88.0 と README に記載されている。balancer の起動例は次のとおり。
paddler balancer --inference-addr 127.0.0.1:8061 --management-addr 127.0.0.1:8060 --web-admin-panel-addr 127.0.0.1:8062
web admin panel のフラグは任意で、指定しなければブラウザからの閲覧はできない。agent 側は management アドレスを balancer に向け、slot 数を指定する。
paddler agent --management-addr 127.0.0.1:8060 --slots 4
ここで注目したいのは、モデルやチャットテンプレート、推論パラメータの設定がコマンドラインではなく web admin panel 側にあると README が示している点だ。モデルの追加と更新、チャットテンプレートのカスタマイズ、推論パラメータの調整は GUI で行う。つまり CLI はプロセスの起動と接続先の指定までが担当し、モデル運用は管理画面に寄る。宣言的な設定ファイルを Git で管理したいチームにとっては、この分担が合わない可能性がある。
Kubernetes を前提にしないことが最大の差別化であり、最大の制約でもある
README は llm-d や Docker Model Runner の代替として言及しつつ、moving parts が少なくデプロイが単純だと説明している。この違いは具体的には、コントロールプレーンの有無に現れる。llm-d は Kubernetes のスケジューラや Gateway API を前提に推論ワークロードを編成する方向の設計だが、Paddler は agent を動的に追加できるという形でスケーリングを扱う。README は autoscaling ツールとの統合を想定していると述べるが、どの autoscaler とどう連携するかの具体は README には書かれていない。ここは導入前にドキュメント側で確認する必要がある。裏を返せば、既に Kubernetes の運用が確立している組織にとって、Paddler の「moving parts の少なさ」は利点にならない。ノード管理、ヘルスチェック、ローリング更新は Kubernetes 側が既に提供しており、その上に別の管理サービスを重ねる理由が薄いからだ。Paddler が効くのは、Kubernetes を導入するほどの規模ではないが複数ホストで推論を回したい、という帯域である。
デスクトップ版は同じバイナリの別の使い方を示す
Paddler には CLI 版とデスクトップアプリ版があると README は説明している。デスクトップ版は beta と明記されている。想定されているのは、複数のノート PC やデスクトップ機をつないでローカル AI クラスタを作る、あるいはオフィス全体のセカンドブレインをコンソールなしで立ち上げるといった用途である。README はさらに混在構成を挙げ、サーバーラック上の balancer に対して、RTX 5090 を積んだ同僚が自分の計算資源を使っていない間だけ ad hoc に agent として参加する、という例を示している。この例は Paddler の設計思想をよく表している。agent は静的な登録ではなく動的に追加できるため、常時稼働しないマシンもリソースプールに参加させられる。ただし beta という位置づけは、デスクトップ版を本番の可用性要件に組み込むべきではないことを意味する。CLI 版とデスクトップ版が同一の balancer/agent プロトコルを共有しているかは README からは読み取れない。
観測性と管理画面はあるが、slot 設計の代償を意識する必要がある
web admin panel では fleet の監視、モデルの追加と更新、チャットテンプレートと推論パラメータのカスタマイズ、GUI からの推論テストができる。observability metrics も機能として挙げられている。ただし README はメトリクスの形式やエンドポイント、Prometheus 互換かどうかに触れていない。監視基盤に既存の仕組みがある組織は、この点をドキュメントで確認してから導入を決めるべきだ。もう一つの注意点は slot と KV キャッシュの関係である。slot ごとに独立したコンテキストと KV キャッシュを持つ設計は、slot 間でコンテキストを共有しないという意味であり、同じ長いシステムプロンプトを全リクエストに付けるような使い方ではメモリ効率が悪くなる。prefix caching のような最適化が効くかどうかは README からは判断できない。同時実行数を増やすほど VRAM を食うという性質は、agent を増やせば解決する類のものではなく、1 ホストあたりの slot 数をどう決めるかという設計問題になる。
Apache-2.0 とメンテナンスの見取り図
ライセンスは Apache-2.0 で、変更を加えた配布や商用利用を含む一般的な許諾が与えられる。ただし本記事は法的助言ではないため、自社のコンプライアンス要件に照らした確認は別途必要になる。リリースは v4.0.1 から v4.1.0 まで短期間で進んでおり、v4.1.0 は OpenCode 対応をうたっている。rc 版を挟んでから正式版を出している点は、リリース手順が整っていることを示唆する。バイナリ 1 つで完結する配布形態はアップグレードコストを下げる。balancer と agent を新しいバイナリに差し替えるだけで、依存パッケージの解決は不要だ。ただしモデルファイル自体の配布と配置は Paddler の守備範囲外であり、agent を増やすたびにモデルを各ホストへ置く運用は残る。dynamic model swapping が機能として挙がっているため、モデルの切り替え自体は管理画面から行えると読めるが、モデルの転送方法やキャッシュの扱いは README には書かれていない。マルチノードでモデルを配る運用を想定しているなら、ここが最初に確認すべき穴になる。
編集部の結論
Paddler が向くのは、llama.cpp の GGUF モデルを社内 GPU や CPU 上で動かしており、Kubernetes の運用チームを別に抱えたくない規模の組織だ。逆に、既に Kubernetes 上で llm-d や vLLM 系のスタックを回しているチーム、あるいはモデルごとに細かいスケジューリング制御を必要とするチームには向かない。採用前に確認すべきは、agent を追加したときに balancer 側がどのタイミングで新規ホストを検出するか、そして slot 数とコンテキスト長の積が VRAM に収まるかの 2 点である。前者は autoscaling 連携の前提になり、後者は起動時に落ちるかどうかを左右する。
コミュニティノート