本实践指南详细介绍如何在腾讯云 TI 平台上利用“服务版本”和“流量分配”功能，实现模型服务的灰度发布：将在线服务的模型从 DeepSeek-V3 平稳过渡升级到新版本 DeepSeek-V3.1。
备注：请在操作升级前评估新旧模型版本对您生产业务的兼容性，确认可以安全升级后再按照本指南进行操作。
前提条件
当前状态：您的在线服务正在使用 DeepSeek-V3 模型，服务版本号为 V1。该服务已稳定运行，承载100%的线上流量，实例数量为1个。
本次目标：将服务平滑升级至最新的 DeepSeek-V3.1 模型，作为新版本 V2 逐步上线，最终完全替代旧版本。
资源准备：需提前准备足够的机器资源，至少能在已有 V1 的基础上再额外启动一个 V2 服务实例用于初始流量切换验证。
操作步骤
模型独立验证
在将新版本模型接入生产流量之前，应首先对其进行独立的功能性测试，确保新版本模型的推理结果和接口行为符合用户预期。
1. 新建服务
访问 TI 平台模型服务 > 在线服务列表页面，单击新建服务，在参数配置页选择 “内置大模型-DeepSeek 系列模型-DeepSeek-V3.1” ，配置相关资源和参数后，启动服务并等待其运行。
2. 接口测试
待上述服务处于“运行中”状态后，用户需要使用测试脚本或工具调用服务接口，进行详细的参数验证。此时，用户可通过单击服务名称进入详情页面，通过“服务调用”页面，直接发起服务请求。
本实践场景主要验证分析的内容是：将 DeepSeekV3 和 DeepSeekV3.1 进行简单对比，从通用场景分析可得知 DeepSeekV3.1 和 DeepSeekV3 的回包是兼容的，分析过程可以参考下表。
场景 | 请求体 | DeepSeekV3 响应 | DeepSeekV3.1 响应 |
一般请求 |  |  |  |
Function Call 使用 |  |  |  |
JSON 格式化输出 |  |  |  |
除了本实践分析的上述内容外，针对用户不同的业务场景，建议用户再使用一些真实业务请求对服务进行测试分析，如：
Token 统计：调用接口并检查返回结果中的 Token 使用量（prompt_tokens, completion_tokens）是否正常统计。
思维链（Chain of Thought）：如果模型支持思维链，验证返回的思维链过程是否清晰、逻辑自洽，且返回的字段（content、reasoning_content）内容是否正确。
其他参数：如调用中使用到其他参数，如 temperature、top_p、max_new_tokens 等，验证这些参数在新版本中依然有效且按预期工作。
此外，还可以按需关注一些服务的高级功能验证：
Function Call：如模型支持，且您的应用使用了 Function Call 功能，请模拟调用并检查模型是否能正确理解用户意图，生成符合预期的函数调用 JSON。
JSON Object 输出：如模型支持，且您的应用要求模型输出 JSON 格式（如通过 response_format: json_object ），请验证新版本生成的 JSON 是否符合预设 Schema，字段完整且类型正确。
3. 结果比对
将新版本模型的测试结果与当前模型的已知稳定结果进行比对，确认没有功能或行为上的问题。如果在验证过程中发现任何问题，应立即停止灰度计划，回到模型或代码层面进行修复和重新部署。如确认新版模型可兼容后，可开始本次灰度发布操作。
正式部署模型新版本
1. 在 TI 控制台的"模型服务 > 在线服务"列表页面，找到您的旧版本 DeepSeek-V3 模型发布的在线服务。
2. 单击服务名称，进入服务详情页，单击新增版本，准备发布一个新的服务版本用以部署新模型。
3. 在新增版本的参数配置页面，在内置大模型列表中选择 DeepSeek 系列：DeepSeek-V3.1，配置相应资源和服务参数，然后启动服务。
4. 等待服务新版本部署完成，看到 V1 和 V2 均在“运行中”状态，新的 V2 版本发布后，平台默认“流量分配”为“0”，此时不会有服务请求分配到 V2。
小流量灰度验证（第一阶段）
在新版本服务部署成功后，先进行第一阶段的灰度验证，将少量流量导入 V2 进行观察。
1. 分配流量权重
单击服务名称进入服务详情页面，单击流量分配，配置实现将 V2 的流量权重从 0 调整至 10；同时，将旧版本 V1 的流量权重调整为90。此时有10%的服务请求流量会分配到 V2 。
2. 监控与观察
可通过监控页面的请求负载查看各版本的负载情况，查看负载是否符合流量权重预期，如：
观察 V2 的负载
观察 V1 的负载
观察 V2 的日志
建议用户持续监控至少30分钟到1小时，根据实际业务情况也可延长观察时间至天级别，建议关注以下内容：
告警监控：检查可观测平台中配置的相关告警，注意观察升级时间段内是否出现任何告警信息，例如实例重启等异常情况。
核心指标：观察新版本 V2 的请求数、首 Token 时延、输出速率等指标，确保其表现符合预期。
日志分析：检查 V2 的日志，确认是否有异常报错。
业务指标：从业务侧检查模型推理结果的准确性、接口返回是否符合预期等。
逐步增加流量（第二阶段）
如果第一阶段监控结果良好，表明 DeepSeek-V3.1 版本稳定可靠，可以逐步扩大灰度流量。
备注：在执行这一步之前，可以分阶段提升 V2 的流量权重，例如从 10 提升到 20、30 等，并持续观察。请确保服务实例数量与承载的流量相匹配。
1. 调整实例数量
本文仅以单个实例为例，因此没有实际演示"调整实例数量"的操作。但在实际场景中，如果 V1 的实例数量较多，则在调整流量权重时，需要同步调整 V2 的实例数量，确保实例数量与分配的流量权重相匹配。
2. 调整流量权重
首先，将 V2 的流量权重从 10 提升至 50，然后，将 V1的流量权重下调至50，最后，各有 50% 的流量分配给两个版本。
3. 持续监控
查看 V2 版本的监控和日志。
对于本阶段的监控观测建议：
进行更长时间的监控，由于这个阶段承载更多线上流量，能更全面地暴露潜在问题。
特别关注业务表现，确保在流量增加的情况下，业务侧依然可以正确处理新版本返回的结果。
全量升级与资源清理（第三阶段）
在服务新版本 V2 以50%流量稳定运行一段时间后，执行最终的服务流量全量切换。
备注：执行全量升级前，建议继续分阶段提升 V2 的流量权重，例如从 50 提升到 60、70 等，并持续观察系统表现。请确保服务实例数量与承载的流量相匹配。
1. 全量流量切换
将 V2 的流量权重提升至 100，同时将 V1 的流量权重降至 0。
2. 服务缩容与下线旧版本
查看服务 V1 版本的监控和日志，确认所有线上流量成功切换至 V2 后，将 V1 的实例数量缩容至 0。
通过这些灰度发布的步骤，您可以在确保服务稳定性的前提下，实现服务模型从 DeepSeek-V3 到 DeepSeek-V3.1 的平滑升级，如在过程中发现问题，则可以随时调整流量权重和实例数量，快速恢复升级中遇到的问题。
