Simon Willison 这次发的不是新模型,是一个版本号还停在 0.1a0 的小插件——llm-chat-completions-server。装上以后,你本地用 LLM 管理的所有模型,不管来自哪个插件,统统会被包进一个和 OpenAI Chat Completions 长得一样的接口里,挂在你指定的端口上。
这插件的写法更扎眼:全部代码由 GPT-5.6 Sol 生成,Simon 自己的评价是它"确实很懂 OpenAI 这套接口的形状"。但插件真正要验证的,不是模型好不好用,是 LLM 自己刚上线的日志去重机制——扛不扛得住越聊越长的多轮对话。
装了什么,怎么用
用法很直接:先装预发布版的 LLM(uv tool install llm --pre),再装这个插件(llm install llm-chat-completions-server),跑一句 llm chat-completions-server -p 9001,本地就起了一个服务。
它暴露的不是新模型,是你通过各种插件已经装好的全部模型——统一包在 OpenAI Chat Completions 格式的接口后面。认这套消息格式的客户端,理论上都能直接把请求打过来,背后跑的其实是本地模型。
开发者省了一层活:不用自己写适配代码去兼容不同模型的调用方式,直接用现成的 OpenAI SDK 或客户端连过来就行。流式输出、鉴权、多用户隔离——这些生产环境绕不开的问题,发布信息里都没提。插件版本号还停在 0.1a0,这本身就是个提醒:别急着拿去跑生产。
为什么真正的测试对象是日志
Chat Completions 这套接口有个特点:对话状态由客户端自己维护,每一轮请求都要把完整历史重新发一遍。聊得越久,请求体越长,服务端日志里的重复内容也越堆越多。
LLM 0.32rc1 给这个问题开了一刀:给消息的每个片段算哈希,内容一样就不重复落盘,这是一套内容寻址的日志设计。这个新插件,就是拿真实的多轮对话流量去检验这套设计管不管用。
发布信息没有给出具体的存储节省比例,也没有延迟数据。去重解决的是日志侧的重复存储问题,不改变模型本身的回答质量或速度。目前只能说这是一次设计意图的验证,不是已经跑出来的性能结论。
兼容接口不新鲜,新意在哪
LLM 本身跟 OpenAI 没有从属关系,是 Simon 维护的独立工具,底下接了一堆不同厂商的模型插件。给这些模型加一层兼容接口,他选的是 OpenAI 的消息格式,不是自己另发明一套——这个选择本身不算新鲜。
Ollama、LiteLLM、vLLM 这类本地或自托管推理工具,早就自带 OpenAI 兼容接口,而且已经被主流客户端广泛对接。放在这个背景下看,llm-chat-completions-server 的位置更清楚:
| 项目 | 定位 | 成熟度 | 典型场景 |
|---|---|---|---|
| Ollama / LiteLLM / vLLM 等 | 本地或自托管推理服务,原生带 OpenAI 兼容接口 | 相对成熟,主流客户端已广泛对接 | 日常调用、生产部署 |
| llm-chat-completions-server | LLM 工具的测试插件,顺带包一层兼容接口 | 0.1a0,刚发布的早期版本 | 验证内容寻址日志的去重设计 |
这插件的新意不在兼容 OpenAI,而在给日志去重找了一个真实的高强度测试场——多轮对话,不断变长的请求体。
本地及多模型应用开发者可以先在测试环境接现成的 OpenAI 客户端,验证自己的模型能不能跑通这套接口。生产环境要用,认证、限流、多用户隔离得自己补,插件目前都没交代。
关注接口标准化的读者更适合把这当一个个案观察。OpenAI 兼容接口早就是本地推理生态的常见外壳,这个插件只是又添了一个,不构成"标准之战已经结束"的证据。
接下来值得看的:0.1a0 到正式版之间会不会补上流式响应和鉴权;LLM 0.32 正式发布后,去重设计有没有公开的存储和延迟数据;其他本地推理框架要不要跟进这套按内容哈希去重的日志思路。
0.1a0 这个版本号说明得很清楚:测试还没做完,别急着把这次兼容当成终点。