Functionary は非推奨、それでも読む価値のある関数呼び出しモデル

非推奨の警告を最初に読むべき理由

このリポジトリの README は、本文より先に警告ブロックを置いている。内容は「このプロジェクトは非推奨で、もはや積極的にメンテナンスされていない」「ここにあるコード、モデル、ドキュメントは大幅に古く、現在の Functionary の状態を表していない」「更新、バグ修正、サポートは提供せず、issue や pull request がレビューされない可能性がある」というものだ。参照用として残されている、という位置づけも明記されている。

ソフトウェアの評価記事としては順序が逆になるが、ここではこの警告から始めるのが正しい。ツール呼び出しモデルを選ぶ作業は、モデルの重み、プロンプトテンプレート、サーバ実装、出力パーサが噛み合って初めて成立する。そのうちサーバ実装とパーサの保守が止まっているなら、他の章で扱う機能の話はすべて「かつて動いていた構成」の記録として読むことになる。最終更新は 2026 年 6 月で、アーカイブ扱いにはなっていないが、活発に開発されている状態でもない。

JSON Schema をそのままツール定義に使う設計

Functionary が解く問題は、チャットモデルに外部関数を呼ばせる際の入出力の型をどう決めるかである。README によれば、関数定義は OpenAI の function call に似た JSON Schema オブジェクトとして与える。モデル側はその定義を読み、関数を実行すべきかどうか、実行するなら並列か直列かを判断し、返ってきた実行結果を解釈する。関数は必要と判断したときにだけ起動される、という記述になっている。

ここで効くのは、ツールのスキーマをアプリケーション側の既存定義から流用できる点だ。OpenAI 形式のツール定義を持っているコードベースなら、それをそのまま tools に渡す発想で組み立てられる。逆に言えば、スキーマの書き方やモデルが返す呼び出し形式が OpenAI と完全に同一である保証は README には書かれておらず、パーサを自作する場合は差分を実測する必要がある。

もう一点、changelog には v4r-small-preview が「ツールを使う前に推論ステップを先に生成できる最初のバージョン」だと記されている。ツール呼び出しの前に理由を出させる構成は、呼び出しの妥当性をログで追いやすくする一方、出力トークン数は増える。

vLLM と SGLang の2系統、起動コマンドの実際

配布形態は Python パッケージで、推論サーバは vLLM 版と SGLang 版の2つが用意されている。README の手順はこうだ。vLLM なら pip install -e .[vllm]、SGLang なら pip install -e .[sglang] --find-links https://flashinfer.ai/whl/cu124/torch2.5/flashinfer-python を実行する。

小さいモデルの起動は、vLLM では python3 server_vllm.py --model "meetkai/functionary-v4r-small-preview" --host 0.0.0.0 --port 8000 --max-model-len 8192、SGLang では python3 server_sglang.py --model-path "meetkai/functionary-v4r-small-preview" --host 0.0.0.0 --port 8000 --context-length 8192 となる。引数名が model と model-path、max-model-len と context-length で異なる点に注意したい。同じモデルを載せ替えるだけのつもりでコマンドを流用すると引数エラーになる。

medium 系は要求が跳ね上がる。README は 4xA6000 または 2xA100 80GB が必要と明記し、vLLM では事前に export VLLM_WORKER_MULTIPROC_METHOD=spawn を設定したうえで --tensor-parallel-size 2、SGLang では --tp 2 を付ける。単一 GPU で medium を動かす道は README には示されていない。

LoRA の動的ロードと TGI という別経路

vLLM サーバには LoRA アダプタを扱う機能があり、README は起動時と動的ロードの両方を挙げている。起動時は --enable-lora と --lora-modules {name}={path} を並べる。動的に扱う場合は --enable-lora だけ付けて起動し、/v1/load_lora_adapter に lora_name と lora_path を POST する。切り替えは /v1/unload_lora_adapter で行う。チャットリクエスト側では model フィールドにアダプタ名を指定し、tools と tool_choice: "auto" を渡す例が示されている。

ここは Functionary の使いどころとして現実味がある部分だ。ベースモデルを固定したまま、顧客ごとや用途ごとのアダプタを HTTP 経由で差し替える構成が取れる。ただし README は LoRA 対応が現時点で vLLM のみだと明記しており、SGLang 経路を選んだ時点でこの機能は使えない。

TGI を使う経路も用意されている。Docker と Docker SDK for Python を導入し、TGI 上で Functionary モデルの推論を行う、という手順が README に並んでいる。ただし提示されているのは導入の入口までで、そこから先の設定は今回の資料からは確認できない。

止まっているサーバ実装を土台にするリスク

最大の制約は、機能不足ではなく保守停止そのものである。README の警告は「更新、バグ修正、サポートを提供しない」と明言している。server_vllm.py と server_sglang.py はこのリポジトリ内のコードであり、依存先の vLLM や SGLang が新版で引数や API を変えても、追随する修正は入らない前提で読むべきだ。

medium モデルの起動例に付いている vLLM の issue 番号への参照も、当時の回避策として書かれたものだ。環境変数 VLLM_WORKER_MULTIPROC_METHOD=spawn が必要になる状況が現在も同じかどうかは、この資料からは判断できない。

もうひとつの失敗モードは、モデル側の出力形式とパーサのずれである。ツール呼び出しの形式はモデルとプロンプトテンプレートに依存する。changelog を見ると v3.1 は Meta のプロンプトテンプレート、v3.2 は独自テンプレートと明記されており、同じ Functionary でも世代によって前提が違う。パーサを固定で書いていると、モデルを差し替えた時点で静かに壊れる。

向かない用途もはっきりしている。長期的にツール呼び出しの挙動を保守する必要がある製品、依存ライブラリの更新に追随したい構成、サポート窓口を前提にする導入は、このリポジトリの対象外だ。

自前でツール呼び出しを組む場合との違い

比較対象として素直なのは、汎用の指示追従モデルを自分でツール呼び出し用に調整する経路である。プロンプトで出力形式を指定し、返ってきたテキストを正規表現や JSON パーサで切り出す。この方法はモデル選びの自由度が高く、新しいモデルが出るたびに載せ替えられる。

Functionary の違いは、ツール呼び出しの形式がモデルの学習に埋め込まれている点にある。プロンプトで形式を教え込む必要がなく、README が挙げる v3.1 の Berkeley Function-Calling Leaderboard での順位のように、関数呼び出し能力そのものを指標にした評価が存在する。ただしその順位は 2024 年 8 月時点の記録であり、現在のリーダーボードで同じ位置にあるかは分からない。

もうひとつの違いはサーバ同梱である。vLLM や SGLang を自分で立ててプロンプトを組む作業を省き、server_vllm.py を叩けば tools 付きのチャット補完が返る。この短縮が価値だったわけだが、そのサーバが保守されなくなった今、短縮分はそのまま負債になる。汎用モデル側を選ぶ判断のほうが、長い目では説明しやすい。

ライセンスと、読む側が確認すべきこと

リポジトリのライセンスは MIT である。コードを複製、改変、再配布する際の条件はこの表示に従うことになる。ただし MIT が及ぶのはこのリポジトリのコードであって、Hugging Face 上で配布されているモデルの重みではない。meetkai/functionary-medium-v3.1 は meta-llama/Meta-Llama-3.1-70B-Instruct を基にしていると changelog に書かれており、派生モデルの利用条件はベースモデル側の条件を別途確認する必要がある。ここで法的な助言はできない。ライセンス表示とモデルカードを自分で読んで判断してほしい。

保守コストの面では、このリポジトリに継続的な更新を期待できない。依存する vLLM や SGLang のバージョンを上げるたびに、server_vllm.py や server_sglang.py の互換性を自分で検証する作業が発生する。medium 系を選ぶ場合は 4xA6000 か 2xA100 80GB というハードウェア要件が固定費として先に立つ。

採用を検討するなら、最初に確かめるべきはモデルの品質ではなく、tools に JSON Schema を渡し tool_choice を auto にしたときの応答を自分のパーサが読めるかどうかである。ここが合わなければ、他の評価を進める意味はない。

編集部の結論

新規に採用する理由はほぼ見当たらない。リポジトリ冒頭の警告が「このコード、モデル、ドキュメントは大幅に古く、更新もバグ修正もサポートも行わない」と明記しており、issue や pull request がレビューされない可能性にも触れているためだ。検討対象になるのは、過去に Functionary ベースの構成を組んだことがあり、既存モデルの重みとプロンプトテンプレートの挙動を再確認したい場合くらいである。試すなら server_vllm.py を meetkai/functionary-v4r-small-preview で起動し、tools に JSON Schema を渡して tool_choice を auto にしたときの出力形式が手元のパーサと一致するかを最初に確かめる。medium 系を選ぶなら 4xA6000 か 2xA100 80GB と tensor-parallel-size 2 が必要で、この時点で多くの環境は対象外になる。

公式情報源

1. Issues
2. License: MIT
3. MeetKai/functionary on GitHub
4. README