Functionary 已标记弃用：一个函数调用模型的现状与接手判断

它解决的是模型与外部函数之间的调度问题

普通对话模型只会生成文本。Functionary 要处理的是另一件事：给定一组以 JSON Schema Object 描述的函数定义，让模型自己判断是否需要调用、调用哪一个、多个调用是并行还是串行，并且能读懂函数返回的结果再继续往下生成。README 的表述是，模型只在需要时触发函数，函数定义的格式与 OpenAI GPT 的 function calls 类似。

目标读者是那些不想把工具调用逻辑写死在应用层的人。传统做法是在提示词里塞入工具清单，再用正则或 JSON 解析器从模型输出里抠出调用意图，解析失败就重试。Functionary 把这个环节收进模型本身，调用意图由权重决定，而不是由外挂解析器决定。这带来的直接后果是：工具调用的可靠性取决于模型，而不取决于你写的那段解析代码是否够健壮。

工具定义走 JSON Schema，推理服务由 vLLM 或 SGLang 承担

从 README 给出的请求示例看，客户端发往 /v1/chat/completions 的负载里包含 tools 和 tool_choice 两个字段，tool_choice 取值 auto。这与 OpenAI 兼容接口的形状一致，意味着已有按该协议写的客户端代码在字段层面不需要重写。

仓库本身不实现推理内核。安装命令是 pip install -e .[vllm] 或 pip install -e .[sglang]，项目提供的是两个服务入口脚本 server_vllm.py 和 server_sglang.py，实际的批处理、显存管理和张量并行交给 vLLM 或 SGLang。README 提到 2024/10/21 新增了由 SGLang 驱动的服务端，说明两条部署路径是被并行维护的。

需要留意的是模型版本与提示模板的绑定关系。changelog 里 functionary-small-v3.1 使用 Meta 原始提示模板，v3.2 使用项目自己的模板，README 直接写明 v3.2 更好。也就是说，换模型版本不只是换权重路径，提示格式也在变。如果你在应用层缓存了某种模板，升级时需要同步检查。

部署命令与显存门槛写在 README 里，没有隐藏步骤

小模型的启动方式两条路径各一行。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。注意参数名不同：vLLM 用 --model 和 --max-model-len，SGLang 用 --model-path 和 --context-length。

中等模型的资源要求被明确写出：需要 4xA6000 或 2xA100 80GB，并且必须启用张量并行。vLLM 路径下要先 export VLLM_WORKER_MULTIPROC_METHOD=spawn，README 指向 vLLM 的一个 issue 作为原因，然后加 --tensor-parallel-size 2；SGLang 路径对应参数是 --tp 2。这类环境变量和参数是硬性前置条件，不是可选优化。

LoRA 支持目前只在 vLLM 路径存在。启动时通过 --enable-lora 配合 --lora-modules {name}={path} 挂载；运行时可以 POST /v1/load_lora_adapter 动态加载，请求体里给 lora_name 和 lora_path；卸载走 /v1/unload_lora_adapter。加载之后，把 chat 请求的 model 字段填成 LoRA 名字即可路由到适配器。

弃用状态是这份材料里最需要正视的事实

README 顶部的警告块用加粗文字写明：项目已弃用，不再主动维护，仓库反映的是 Functionary 的一个很旧的快照，不代表项目当前状态，代码、模型和文档都显著过时，仅作参考保留，不再提供更新、缺陷修复或支持，issue 和 PR 可能不会被审查。

这不是一句免责声明，而是会传导到具体操作上的约束。第一，模型权重托管在 Hugging Face 上，权重是否长期可用不由这个仓库控制。第二，文档站点 functionary.meetkai.com 与仓库同步停滞，遇到问题时没有上游可以追问。第三，vLLM 和 SGLang 都在持续演进，README 里那条 VLLM_WORKER_MULTIPROC_METHOD=spawn 的说明本身就指向一个外部 issue，说明服务脚本与推理框架的版本兼容性依赖外部项目，而这个仓库不会再跟进修复。

如果只是本地跑通一个函数调用流程做验证，这些风险可以接受。如果是要放进有 SLA 的服务里，弃用意味着所有后续兼容性工作都要由使用方承担。

什么时候它反而是错的工具

最明显的一种情况是：你的工具调用需求本身很轻。如果只有一两个函数、参数结构固定、调用时机由业务状态机决定，那么把模型拉进来判断调用意图，等于把一个确定性的分支判断换成一次概率推理。这种情况下用普通模型加显式路由更省事，也更可测。

第二种情况是上下文长度吃紧。README 给出的启动示例里 max-model-len 和 context-length 都设成 8192，而 changelog 提到 v3.1 系列支持 128k 上下文。两者并不矛盾：长上下文是模型能力，实际服务窗口取决于你启动时传的参数。如果工具定义本身就很长，加上多轮工具返回结果，8192 会很快成为瓶颈，需要自己调整这个参数并确认显存是否够。

第三种情况是部署环境没有对应硬件。中等模型的 4xA6000 或 2xA100 80GB 是 README 写明的门槛，达不到就只能用小模型，而小模型的函数调用能力与中等模型不在同一档。这不是调参能弥补的差距。

与原生工具调用模型相比，差别在控制权归属

Functionary 的定位是自托管。权重在你自己的机器上，推理服务在你自己的进程里，工具定义通过请求体传给模型，整条链路不经过第三方 API。代价是硬件、显存、张量并行配置、推理框架版本兼容全部由你负责。

与之相对的是托管式 API 提供的工具调用能力。那类方案把模型和调度都放在服务端，你只发请求，硬件和版本问题由提供方处理。差别不在功能清单上，而在故障发生时谁来解决。Functionary 弃用之后，这个差别被放大：托管 API 会持续更新模型和接口，而 Functionary 的仓库不会再有任何变更。

另一条路是直接用底层模型配合自建解析层。Functionary 的价值在于把提示模板和输出解析固化进权重，省掉这层手写代码。如果你本来就有一套稳定的解析逻辑，或者需要精确控制每一步的失败重试，那么这层封装带来的收益会小于它带来的调试难度，因为出错时你面对的是模型输出而不是自己写的分支。

维护成本与许可证边界

采用 Functionary 之后，维护成本主要不在这个仓库本身，而在它依赖的两个推理框架上。仓库提供的是 server_vllm.py 和 server_sglang.py 两个入口，vLLM 和 SGLang 升级后这两个脚本是否还能正常工作，需要自己验证。README 里为中等模型专门写了一条 VLLM_WORKER_MULTIPROC_METHOD=spawn 的环境变量，并链接到 vLLM 的一个 issue，这类外部依赖的变动不会有人替你跟进。

许可证方面，仓库标注为 MIT。MIT 允许修改和再分发，也允许闭源使用，但需要保留版权声明和许可声明。需要单独确认的是模型权重的许可条款：权重托管在 Hugging Face 上，部分模型基于 meta-llama 系列衍生，其使用条款由模型页面单独规定，与代码仓库的 MIT 不是同一份文件。README 没有在同一处汇总这些条款，采用前需要逐项核对。这里只说明许可证的分布情况，不构成法律意见。

编辑结论

Functionary 适合两类人：需要研究早期函数调用提示模板与结果解析流程的工程人员，以及已经持有旧版本权重、只想把推理服务继续跑起来的团队。它不适合新项目，README 顶部的弃用声明写明代码、模型和文档均已显著过时，不再提供更新、缺陷修复或支持，issue 和 PR 也可能不被审查。决定接手前先确认三件事：仓库里 server_vllm.py 与 server_sglang.py 对应的模型权重是否仍可下载；你需要的 GPU 配置是否匹配文档给出的 4xA6000 或 2xA100 80GB 门槛；以及 MIT 许可证下你自行维护分支的边界。如果这三项里任何一项无法确认，就不该把它放进生产路径。

官方来源

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