1. 从旧版本升到 lmdeploy v0.13.0我踩到的第一个坑lmdeploy v0.13.0 是一次覆盖面很广的版本更新它把新模型接入、KV Cache 量化、Anthropic 兼容端点、Mixed Modality 多模态输入、工具调用解析、调度公平性这些能力一次性补齐。如果你正在用 lmdeploy 跑大模型推理服务或者准备把旧版本升级上来这一版值得认真对待。它适合三类人一是已经在用 lmdeploy 做在线推理、想升级到新端点的开发者二是想用 TurboQuant 压低显存占用、在有限卡上跑更长上下文的部署同学三是需要 Anthropic 风格接口、又不想改上层应用代码的团队。我这次升级的起点是一个跑了几个月的旧版本服务模型是 Qwen 系列接口走 OpenAI 路由。升级到 v0.13.0 之后最直观的变化是启动参数和配置文件需要重新对齐尤其是量化策略和端点开关。旧配置直接拿过来启动会遇到 quant_policy 不识别、Anthropic 端点没开、多模态消息结构报错这几类问题。下面我把从环境准备到端点验证的完整过程拆开讲配置和命令都可以直接复制。先说结论v0.13.0 的升级不是改个版本号就完事它涉及量化参数、服务端点、消息类型三块配置的联动。只要把这三块对齐升级过程其实很顺。2. TaoToken 作为统一 Key/API 通道的前置准备在讲 lmdeploy 配置之前先解决一个容易被忽略的前置问题模型权重和接口调用的凭证管理。我这次升级同时要验证 Anthropic 兼容端点和 OpenAI 路由如果每个端点都单独配一套 Key管理起来很乱。我的做法是用 TaoToken 作为统一的 Key/API 通道把模型对话、编码计划、控制台这些入口收敛到一处。TaoToken 在这里的角色是统一凭证和调用入口官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。你需要在控制台里先创建好 API Key后面 lmdeploy 的 Anthropic 兼容端点验证和 OpenAI 路由验证都会用到它。具体动作分三步。第一步打开控制台创建 Key入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建后把 Key 复制到本地环境变量不要写进代码仓库。第二步如果你要验证模型对话能力可以用模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 先确认目标模型可用。第三步如果你打算长期跑编码或 Agent 任务可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 把额度规划好再上服务。注意Key 只放在环境变量里比如export TAOTOKEN_API_KEYsk-xxxx不要硬编码进 config.toml 或启动脚本。lmdeploy 的端点验证阶段会读取这个变量。这一步看起来和 lmdeploy 没关系但实际升级时端点连通性验证、多模态请求测试都要靠它。先把 Key 准备好后面排障会省很多事。3. lmdeploy v0.13.0 的可复制 config.toml 骨架v0.13.0 的配置项比旧版本多了不少尤其是量化和服务端点部分。下面这份 config.toml 是我实测能跑通的骨架你可以按自己的模型路径和卡数调整。重点看三个区块模型与量化、服务端点、多模态消息。[model] model_path /data/models/Qwen3.5-35B-A3B trust_remote_code true dtype float16 [quant] # TurboQuant 使用 quant_policy42 作为 KV Cache Quantization 方案 quant_policy 42 # kernel block size 相关配置v0.13.0 新增支持 kernel_block_size 64 [server] host 0.0.0.0 port 23333 # 开启 OpenAI 兼容路由 openai_route true # 开启 Anthropic 兼容服务端点 anthropic_route true # 暴露 repetition n-gram 参数 repetition_ngram true [session] # 用户输入 session_id 映射到内部 session_id map_session_id true [logging] # v0.13.0 的 modern logging utils level INFO format json几个关键点解释一下。quant_policy 42是 TurboQuant 的开关它作用于 KV Cache 量化能明显降低长上下文场景的显存占用。kernel_block_size是 v0.13.0 新增的底层调度参数配合缓存块布局使用我设成 64 在多数场景下比较稳。anthropic_route true是这一版的重点开了之后服务会同时暴露 Anthropic 风格端点。map_session_id true解决会话一致性问题多轮对话时不会串会话。如果你用的是 Ascend 平台还要额外注意 prefix caching 的修复已经合入配置里不用特殊开关但建议在启动日志里确认 prefix caching 已启用。如果你跑的是 MoE 模型且 tp1v0.13.0 修复了 mtp 相关问题配置里保持默认即可。启动命令如下注意把模型路径换成你自己的lmdeploy serve api_server \ /data/models/Qwen3.5-35B-A3B \ --server-name 0.0.0.0 \ --server-port 23333 \ --quant-policy 42 \ --kernel-block-size 64 \ --trust-remote-code \ --log-level INFO启动后观察日志重点看三行TurboQuant 是否生效、Anthropic 端点是否注册、prefix caching 是否启用。如果 TurboQuant 没生效日志里会有 quant_policy 相关警告这时候回去检查配置项拼写。4. 端点连通性验证与成功结果服务起来之后别急着接业务先做端点连通性验证。我分三步走OpenAI 路由、Anthropic 兼容端点、Mixed Modality 多模态输入。第一步验证 OpenAI 路由。用 curl 发一个最简请求curl -s http://127.0.0.1:23333/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: Qwen3.5-35B-A3B, messages: [{role: user, content: 用一句话说明什么是 KV Cache 量化}], max_tokens: 128 }成功的话会返回标准 OpenAI 格式的 JSONchoices 里有内容。如果返回 404说明 openai_route 没开返回 401检查 Key。第二步验证 Anthropic 兼容端点。v0.13.0 新增的 Anthropic-compatible serving endpoints 走的是/v1/messages路径curl -s http://127.0.0.1:23333/v1/messages \ -H Content-Type: application/json \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -d { model: Qwen3.5-35B-A3B, max_tokens: 128, messages: [{role: user, content: 解释一下 TurboQuant 的作用}] }注意 Anthropic 风格用的是x-api-key头不是Authorization。返回结构里会有content数组这是 Anthropic 格式的特征。如果这里报 400多半是 messages 结构不对Anthropic 端点对 role 和 content 的嵌套要求更严格。第三步验证 Mixed Modality 多模态输入。v0.13.0 支持更多 message item types可以传混合模态消息curl -s http://127.0.0.1:23333/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: Qwen3.5-35B-A3B, messages: [{ role: user, content: [ {type: text, text: 描述这张图的内容}, {type: image_url, image_url: {url: https://example.com/demo.png}} ] }], max_tokens: 256 }三个端点都返回正常结果说明升级基本完成。我实测下来Anthropic 端点的响应结构和 OpenAI 路由有差异上层应用如果同时用两个端点解析逻辑要分开写。5. 本篇常见错误排查升级过程中我遇到几个典型报错这里集中列一下方便你对照。第一个quant_policy 42 not supported。这是旧版本残留的配置缓存或者 lmdeploy 没升到 v0.13.0。先确认版本lmdeploy --version必须是 0.13.0。如果版本对但还报错检查是不是装了多个环境pip 装到了另一个 Python 里。第二个Anthropic 端点返回 404。v0.13.0 的 Anthropic 端点默认可能不注册需要在启动参数里显式开启。我用的启动命令里没有单独的 anthropic 开关实际是通过配置文件anthropic_route true生效的。如果你只用命令行启动确认参数拼写或者改用配置文件方式。第三个多模态请求报unsupported message item type。这是 message item types 没对齐。v0.13.0 扩展了支持类型但要求 content 是数组结构且每个 item 带type字段。旧版本可能只支持字符串 content升级后要改请求体。第四个高并发下 prefill 延迟升高。v0.13.0 修复了高 decode 负载下 prefill starvation 的问题但如果你还看到类似现象检查是不是调度参数没跟上。这个修复是内置的不需要额外配置确认版本正确即可。第五个seed0不生效。旧版本会静默忽略 seed0v0.13.0 改成用is not None判断。如果你做实验复现升级后 seed0 会正常起作用这算行为变化不是 bug。第六个Ascend 平台 prefix caching 异常。v0.13.0 修复了 Ascend 场景下的 prefix caching升级后如果还有问题检查驱动和固件版本是否匹配。提示排障时优先看启动日志的前 50 行TurboQuant、Anthropic 端点、prefix caching 的注册信息都在那里。日志格式在 v0.13.0 里换成了 modern logging utils结构化程度更高grep 关键词更快。如果上面这些排查完还是不通接入相关的文档可以看 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。这两个入口能覆盖大部分凭证和接入问题。6. 升级后的接入建议与 CTA升级到 v0.13.0 之后我的建议是先把 OpenAI 路由和 Anthropic 端点分别跑通再决定业务走哪条路。如果你的上层应用是 Anthropic 风格直接用新端点省掉适配层如果是 OpenAI 风格保持原路由但记得把 repetition n-gram 参数用起来生成控制更细。长期跑编码或 Agent 任务的话Coding Plan 的额度规划比单次调用更划算入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。如果你还在选模型阶段模型对话页面可以先试效果再决定部署哪个权重。最后提醒一句v0.13.0 的 trust_remote_code 改成了显式控制这是安全边界的变化。升级后如果你的模型需要远程代码必须在配置里显式打开否则会加载失败。这个改动我一开始没注意卡了十几分钟才反应过来。把配置对齐、端点验证做完这次升级就算平稳落地了。
