来自 GDP（@bookwormengr）的推文线程

聊天模板里藏着魔鬼 ========================= 土豆和马铃薯不是一回事，这与菲比·布菲让你相信的说法相反。 如果你正为通用人工智能（AGI）而辗转难眠，或者你只是在从事开源人工智能模型的实现工作，那么这篇博客你一定要读。 如果你是一位研究“人工智能安全”的公共知识分子，却看不懂这篇博客，那么你就没有资格评论这个话题。正如人们常说的，去读读书吧。 现在我的抱怨已经结束了，我想告诉你们，这篇博客将告诉你们所有可能出错的事情，这些事情最终可能会使你的前沿模型变得“愚蠢”。 LLM的推理非常脆弱。推理引擎必须以严格的格式（聊天模板）将输入呈现给LLM。如果稍有偏差，输出结果就会很糟糕。不过，这至少可以减轻你对通用人工智能（AGI）的焦虑——技术不会变成天网。 感谢 @vllm_project 和 Lilian Weng。他们在此讲述了如何根据 Kimi 团队的反馈，将运行在 vLLM 上的 Kimi k2 模型的工具调用成功率提高到接近 100%。 他们收到反馈后很快就行动了，做得好！非常感谢你们的社区服务🧡💕 关键教训（引用） 魔鬼藏在聊天模板里：聊天模板是模型与其服务框架之间至关重要的交互环节。集成新模型时，务必仔细验证其模板逻辑的每一部分，确保它们符合框架的特定行为和假设。 剥离抽象层：像 `/chat/completions` 这样的高级 API 虽然方便，但可能会掩盖根本原因。调试时，不要犹豫，直接访问像 `/completions` 这样的底层接口。手动构建输入是隔离问题的一种有效方法。 专业提示：令牌 ID 是最终的真相：对于最细微的问题，检查发送给模型的最终令牌 ID 序列是唯一确定问题所在的方法。虽然我在上述问题中并不需要用到这种方法，但它仍然是工具箱中至关重要的工具。诸如使用 OpenAI 兼容的 API 返回令牌 ID 之类的技术可能在关键时刻救你一命。感兴趣的朋友可以参考我们在 Agent Lightning 文章中重点介绍的这一点。 理解框架设计理念：vLLM 对 **kwargs 的严格处理并非缺陷，而是一种出于安全考虑的有意选择。理解这些设计决策有助于快速找到根本原因，避免被意外行为所困扰。 开放生态系统的挑战：诸如“Enforcer”工具调用之类的高级功能是成熟专有服务的标志。如何在像vLLM这样的开源项目中稳健而优雅地实现这些功能，是社区亟待解决的一项重要挑战。