最近のLLM開発では、「ただ文章を返す」よりも、ツールを呼び出しながら段階的に仕事を進める使い方が主流になってきました。たとえば、
みたいな流れです。
このとき必要になるのが tool-calling、つまり「LLMが関数や外部ツールを呼ぶ仕組み」です。
ただ、ここが意外と面倒です。モデルは平気で:
みたいなことをします。
forge は、まさにその “壊れやすさ”を補正するための層 だと考えるとわかりやすいです。
個人的には、ここがかなり重要だと思います。LLMアプリって「モデルが賢ければ終わり」ではなく、実際には周辺の制御がほぼ本体 なんですよね。forge はその現実に真正面から向き合っている印象です。
README には、forge は次のようなものだと書かれています。
A reliability layer for self-hosted LLM tool-calling.
つまり、自前運用LLMの tool-calling を安定させる reliability layer です。
特に目立つのは次の2つです。
guardrails は、日本語で言えば 「暴走防止の補助輪」 みたいなものです。
forge では、以下のような工夫が入っています。
これ、地味に見えてかなり大事です。LLMは“それっぽい”返答をするのが上手いので、アプリ側が気を抜くと簡単に事故ります。forge はそこに、かなり実用的な防波堤を置こうとしているわけです。
LLMは一度に覚えておける量に限界があります。
そこで forge は、VRAM-aware budgets や tiered compaction といった仕組みで文脈を整理します。
ざっくり言うと:
ということです。
これは地味ですが、長時間動くエージェントでは本当に大事です。
会話が長くなると、モデルはすぐに「今何の話だっけ？」状態になるので、文脈整理はエージェントの生命線 と言ってもいいと思います。
forge は、用途に応じて3通りの使い方ができます。
これは forge を 正面から使う 方式です。
forge がやってくれることはかなり多くて、README では次のように説明されています。
つまり、エージェントの面倒ごとをまとめて引き受ける実行基盤 です。
さらに、SlotWorker という仕組みもあります。これは、共有GPUスロットへのアクセスをpriority queueで制御し、必要ならauto-preemptionするもの。
日本語で無理やり言うと、「重要な仕事を優先して、混雑していたら途中で差し替える」 仕組みです。
複数エージェントが1枚のGPUを取り合うような構成では、かなり便利そうです。
これは、自分でオーケストレーションループを書いている人向けです。
つまり、ループ全体は自分で管理するけれど、forge の信頼性機能だけ借りたい という使い方ですね。
この設計はかなり好みです。
「全部入りの魔法フレームワーク」ではなく、必要な部分だけ差し込める のは、現場では強いんですよね。
これはいちばん手軽そうです。
forge を OpenAI-compatible proxy として使い、既存のクライアントとローカルモデルサーバーの間に挟みます。
たとえば:
のようなクライアントが、forge 経由でローカルLLMにアクセスできます。
つまりクライアント側から見ると、賢いモデルに繋いだように見える わけです。
ここはかなり面白いです。既存ツールをそのまま使いながら、裏で reliability layer を足せるのは実用性が高いと思います。
forge が対応している backend は以下です。
README では、特に llama-server が推奨されていて、トップの評価構成もそこ上だとされています。
一方で、Ollama はセットアップが簡単で、Llamafile は単一バイナリで依存が少ない。
Anthropic は API を使うのでローカルGPUが不要です。
ここでおもしろいのは、forge が「ローカルだけ」に閉じていない点です。
自前運用を軸にしつつ、必要なら API モデルも使える。これはかなり現実的な設計だと思います。理想論だけじゃなく、実運用をちゃんと見ている感じがあります。
README の例は、天気を答える workflow です。
get_weather という関数を作るWorkflow に tool として登録するWorkflowRunner で実行するここで大事なのは、ツール定義がきちんと構造化されていることです。
ただ関数を渡すだけでなく、
を明示します。
これによって LLM は「何をどう呼べばいいか」を理解しやすくなります。
特に Pydantic を使っているのは、Python らしくていいですね。型とスキーマが揃うので、実装者のストレスが減りそうです。
README で特に印象的だったのが、proxy server の考え方です。
forge は、ツールがあるリクエストに対して synthetic respond tool を自動注入します。
これは要するに、モデルに「普通の文章で返して」と言う代わりに、respond(message="...") という tool call をさせる 仕組みです。
なぜそんな回りくどいことをするのかというと、小さめのローカルモデルは、テキスト出力と tool call のどちらを選ぶべきかを安定して判断できない からです。
これはかなり納得感があります。
8Bクラスのモデルに「自由に考えて出力していいよ」と渡すと、出力形式がぶれやすいんですよね。だったら最初から tool-calling モードに誘導する。
この発想は、かなり実戦的だと思います。
しかも、最終的には client には普通のテキストレスポンスに見える。
裏側で tool call を使っていても、外からは透けない。こういう 見えない補助線 は、ユーザー体験をかなり良くするはずです。
forge には、26シナリオの eval suite があると書かれています。
しかも、
という2層構造になっていて、単純なケースと難しいケースを分けて測っているようです。
README では、トップの self-hosted config として:
が挙げられています。
もちろん、ベンチマークは万能ではありません。
でも、こういうプロジェクトで評価系をちゃんと持っているのはかなり好印象です。
「動きます」だけでなく「どれくらい信頼できるか」を数値で追っているのは、まさにこの種のフレームワークに必要な姿勢だと思います。
forge は、次のような人に向いていそうです。
逆に言うと、「LLMにちょっと質問したいだけ」 なら、ここまでの仕組みは少し大げさかもしれません。
でも、実際に業務やプロダクトで使うなら、このくらいの補助輪がある方が安心です。
個人的には、forge はかなり“わかっている”プロジェクトだと思いました。
理由は、単に「LLMでツールを呼べます」ではなく、その先にある失敗しやすさまで含めて設計しているからです。
特に好きなのは、
この3点です。
LLM界隈って、ともすると「モデルが賢くなれば全部解決」という雰囲気になりがちですが、実際には信頼性の工学が大事です。
forge はその現実をかなり真面目に扱っていて、しかも自前運用の文脈に寄せている。ここは地味に貴重だと思います。
一方で、こういうフレームワークは便利な反面、内部の挙動を追わないと「なぜうまくいったのか」が見えにくくなることもあります。なので、導入するなら、ブラックボックスにしすぎず、評価とログをしっかり見る運用が重要ではないでしょうか。
forge は、self-hosted LLM を実用的な agent として扱うための reliability layer です。
単なる補助ライブラリではなく、失敗しがちな tool-calling を補正し、長いワークフローを破綻しにくくすることに重点を置いています。
「ローカルLLMは面白いけど、実運用では不安」という人にとって、かなり有望な選択肢になりそうです。
少なくとも私は、こういう“モデルそのもの”ではなく“モデルを支える層”に真剣なプロジェクトが増えるのは、すごく良い流れだと思います。