Functionary：已停止維護的開源函式呼叫模型，還剩下什麼可用

一個模型同時決定「要不要呼叫」與「怎麼解讀回傳」

多數人接工具到 LLM 時，習慣自己寫一層調度：先讓模型輸出 JSON，解析後執行程式，再把結果塞回下一輪 prompt。Functionary 想省掉的就是這層手工調度。README 的說法是，模型自己判斷何時該執行函式、要平行還是依序執行，並且能理解函式的輸出。它只會在需要時觸發函式。

工具定義的格式沿用 JSON Schema Object，寫法接近 OpenAI 的 function call，所以既有的工具描述通常不需要重寫。目標讀者很明確：想把工具呼叫整段下放到模型推論層、不想在應用層維護狀態機的人。另一個線索是 code interpreter：changelog 記載 v2.4 是第一批具備 code-interpreter 能力的版本，做法是在 tools 裡傳入 {type: "code_interpreter"}。這代表 Functionary 把「執行程式碼」也當成一種內建工具型別，而不是要你自己接一個沙箱。

推論交給 vLLM 或 SGLang，repo 只負責協定轉換

這個 repo 本身不是推論引擎，而是兩支伺服器腳本加上模型端 prompt 模板的組合。安裝時用 extras 選擇後端：pip install -e .[vllm] 或 pip install -e .[sglang]，SGLang 那條還需要加上 --find-links https://flashinfer.ai/whl/cu124/torch2.5/flashinfer-python 來取得 flashinfer。

啟動方式兩邊對稱但參數名稱不同。vLLM 走 python3 server_vllm.py --model ... --host 0.0.0.0 --port 8000 --max-model-len 8192；SGLang 走 python3 server_sglang.py --model-path ... --host 0.0.0.0 --port 8000 --context-length 8192。同一個概念在兩邊叫不同名字（--model 對 --model-path、--max-model-len 對 --context-length），這種不對稱在切換後端時很容易漏改。

資料流大致是：客戶端送出 messages 加 tools 與 tool_choice，伺服器套用該模型對應的 prompt 模板，交給底層引擎生成，再把模型輸出解析回工具呼叫或一般回覆。changelog 也提到 v2 到 v2.4 的串流支援是由 llama-cpp-python 這個外部專案提供的，而不是這個 repo 自己實作。

medium 模型的硬體門檻與 tensor parallel 設定

README 直接寫明 medium 系列需要 4xA6000 或 2xA100 80GB，並且必須開啟 tensor parallel。vLLM 用 --tensor-parallel-size 2，SGLang 用 --tp 2。這是採用與否的分水嶺：小模型可以在單張消費級卡上跑，medium 則直接進入多卡伺服器的預算範圍。

vLLM 路徑還有一個容易踩到的前置條件。README 要求在跑 medium 模型前先 export VLLM_WORKER_MULTIPROC_METHOD=spawn，並連到 vllm-project/vllm 的 issue 6152 作為原因說明。這代表在當時的 vLLM 版本下，多進程啟動方式與模型載入有衝突，得靠環境變數繞開。這一項是環境相依的，換版本後是否仍需要，文件沒有交代。

LoRA 支援目前只在 vLLM 路徑提供，SGLang 沒有。啟動時可用 --enable-lora 搭配 --lora-modules {name}={path}，執行期則透過 /v1/load_lora_adapter 與 /v1/unload_lora_adapter 兩個端點動態掛載與卸載，請求時把 model 欄位填成 LoRA 名稱即可。對於要為不同客戶掛不同 adapter 的場景，這是少數在文件裡寫得比較完整的部分。

棄用公告改變了這個專案的性質

README 最上方是一段警告，內容是這個專案已棄用、不再積極維護，repo 反映的是非常舊的快照，程式碼、模型與文件都明顯過時，僅供參考，不再提供更新、錯誤修補或支援，issue 與 PR 可能不會被審閱。

這段話必須當成硬約束來讀。它意味著 changelog 裡那些日期（2024 年 5 月到 12 月）是活動的終點而不是起點；Hugging Face 上的 meetkai/functionary-* 權重是否仍在、是否還能下載，不在這個 repo 的保證範圍內。文件指向的 functionary.meetkai.com 是否仍在線，同樣無法從這份材料確認。

還有一個更隱蔽的風險：伺服器腳本是薄薄一層協定轉換，真正的行為取決於底層 vLLM 或 SGLang 的版本。當這兩個引擎持續演進，而 server_vllm.py 與 server_sglang.py 不再更新時，這種耦合會先斷在參數與 API 上，而不是斷在模型品質上。這也是為什麼在評估這個專案時，重點不該放在模型能力，而該放在它與你現有推論堆疊的相容性。

什麼情況下它會是錯的工具

第一種情況是你要的是雲端 API 的替代品。Functionary 的定位是自架推論，README 從頭到尾沒有提到任何託管服務，你必須自己準備 GPU、自己處理權重下載與版本對齊。如果團隊沒有維運推論伺服器的能力，這個專案不會幫你省下這部分。

第二種情況是你在意長脈絡下的工具呼叫穩定性。changelog 顯示 v3.1 與 v3.2 才有 128k context，而這些版本全部落在棄用公告涵蓋的時間範圍內。文件沒有提供任何關於長脈絡下工具選擇準確率的說明，也沒有失敗案例的討論。你不能從這份材料推論它在你的長對話場景中表現如何。

第三種情況是你需要官方支援。README 明說不提供支援、issue 可能不被審閱，這對需要 SLA 或需要有人回應 bug 的團隊是決定性的排除條件。

還有一個實際的判斷點：medium 系列的硬體需求是 4xA6000 或 2xA100 80GB。如果這個門檻對你來說太高，你只剩下 small 系列可選，而 small 系列的能力上限在文件裡同樣沒有量化的說明。

與 vLLM 內建 tool calling 的差別在哪

最直接的替代方案是直接用 vLLM 或 SGLang 本身。這兩個引擎都已經提供 OpenAI 相容的 chat completions 端點，而 Functionary 的伺服器腳本正是在這之上再加一層：把模型特定的 prompt 模板與輸出解析綁進去。差別在於責任歸屬。用原生引擎，工具定義的解析與模板由引擎與模型卡決定；用 Functionary，這一層由 server_vllm.py 與 server_sglang.py 決定，好處是你可以直接讀這兩支腳本理解模型期待什麼格式，壞處是它們不再更新。

另一個方向是改用仍在維護的函式呼叫模型，搭配原生引擎部署。這樣做會失去 Functionary 那套已經寫好的 prompt 模板，但換來的是引擎與模型兩邊都有人跟進版本。對照點很具體：Functionary 的價值集中在模板與解析這層薄程式碼，而這層正是棄用後最快失效的部分。

如果你的場景需要 code interpreter，Functionary 把它做成 tools 裡的一個型別，這是相對少見的設計。要複製這個能力，你得自己在引擎外掛一個執行沙箱，並自行處理輸出回填。這部分的工程量不該被低估。

授權與維護成本的實際算法

授權是 MIT，這是寬鬆授權，允許修改與商用，條款本身對採用沒有阻礙。要注意的是這只涵蓋這個 repo 的程式碼。模型權重另外有授權，而 changelog 顯示多個版本是基於 meta-llama 的 Llama 3 與 Llama 3.1 系列（例如 Meta-Llama-3.1-70B-Instruct、Meta-Llama-3.1-8B-Instruct），這些底層模型的授權條件與 MIT 不同，採用前需要另外確認。本文不構成法律意見。

維護成本方面，README 已經把答案寫死：不再有更新、修補與支援。所以真實成本不是「升級到新版要改多少」，而是「底層引擎改版後你要自己修」。具體要盯的檔案就是 server_vllm.py 與 server_sglang.py，因為所有引擎介面的耦合都集中在這裡；一旦 vLLM 或 SGLang 調整了模型載入或多進程行為，這兩個檔案就是唯一需要動手的地方。

如果只是為了重現某篇論文或做內部實驗，這個成本是可接受的。如果要放進會長期運行的服務，把這兩個檔案納入自己的 fork 並自行承擔修補，是唯一誠實的做法。

編輯結論

如果你手上已經有 Functionary 的權重與推論環境，而且需要的是離線、可自架的函式呼叫模型，這個 repo 仍可作為參考實作；但 README 已明講不再提供更新、修補與支援，issue 與 PR 可能不會被審閱，任何新生產專案都不該從這裡起步。要先確認的是：你打算用的模型權重是否仍可從 Hugging Face 取得、你選的伺服器（server_vllm.py 或 server_sglang.py）是否還對得上你環境中的 vLLM 或 SGLang 版本，以及 medium 系列所需的 4xA6000 或 2xA100 80GB 是否真的拿得到。這三項只要有一項不成立，就該改看仍在維護的替代方案。

官方來源

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