直接回答
端侧模型的功能开关是一项会改变执行路径的配置输入，不是新路径有效的证据。如果开关选择模型制品、backend、parser、提示策略或并发设置，每次测试都应记录开关的生效值及配置版本。否则报告可能把不同 runtime 的结果误认为同一种条件。开关可以降低发布风险，但会增加分支和组合，仍然需要有计划地验证。 先把配置来源说清楚。应用内固定配置不同于远程拉取的值；远程来源会引入网络可用性、隐私、缓存和同意问题。本文只讨论随构建或测试记录的确定性应用配置，不讨论远程功能开关服务。不要只为切换本地推理就增加云端依赖。每项开关都要写明责任人、允许值、默认值、兼容要求，以及变化后是否必须重建 runtime。任何开关都不能悄悄把私人输入发送至远端 backend，也不能改变“离线”承诺的含义。 故障分析时一次只改变一个变量。如果 release 同时更换模型制品、backend 和 parser，测试通过或失败都无法归因。配置回执应包含应用构建、flag 集合修订、确切 artifact ID、runtime/backend 选择、parser 修订和任务策略。测试 harness 读取实际生效的回执，而不是开发者原本想选的值。如果请求 backend 后发生回退，应分别记录请求值和观察结果。一个名为 useGpu 的 flag 不足以证明任务真的在 GPU 上执行。 把回滚设计成状态转换。关闭开关应阻止新操作进入该路径；已经开始的任务则按明确规则取消或完成。如果旧配置对应不同模型 session 或 parser 状态，不能复用不兼容 runtime 对象。协调器应安全取消或排空任务、关闭自有资源、切回先前配置，并在接受下一请求前准备对应状态。旧配置的回调必须标记来源；路径不再活动时应忽略迟到结果。 有计划地覆盖开关矩阵。测试默认、开启、关闭、未知值、配置不匹配和回滚。并非所有笛卡尔组合都值得测试；应按依赖关系和风险选择，并记录省略组合。确认启动、模型加载、任务结果、取消和下一请求在支持的每种配置下符合预期。Fake runtime 适合验证分支选择；宣称实际执行行为时还需固定制品与 runtime 的真实测试。单元测试通过不能证明 backend 兼容。 让性能证据和产品文案引用同一回执。版本说明若描述某个 backend 或 artifact，不可挂到实际使用另一配置的测试上。若没有性能原始证据，开关本身不会创造证据。不能从开关存在推断硬件支持，也不能从构建成功推断运行兼容。项目事实要求结论绑定确切制品和测试记录。 最后，为开关设置最短合理寿命。临时实验要有责任人和删除日期。回滚或正式采用后，清除失效分支与旧配置路径，避免永久留下无人理解的组合。保存简洁审计记录，说明开关目的、覆盖测试和默认版本。这能减少未来任务意外进入未维护推理路径的概率。 多开关相互依赖时，要画出约束而非只列 true/false。例如 parser 版本可能要求输入 schema 修订一致；模型 artifact 的切换可能要求新 runtime session。对不允许的组合，应在配置解析阶段明确拒绝，不应等到 native 推理后才暴露异常。配置验证失败时让用户看到功能暂不可用，并保存错误类别，不应降级到未经记录的另一条路径。 测试报告附上 receipt ID，使代码评审、benchmark 和发布说明引用同一配置事实。若回执包含设备、runtime 或制品信息，按项目数据规则控制访问。不要把回执作为用户行为分析收集，也不要记录用户输入。目标是可重现配置，而不是建立新的遥测数据源。对于远程配置尚未有事实支持的项目，不暗示功能已存在或服务已部署。
为结构化输出 parser 变化设置本地开关
团队准备测试模型的新版输出解析器。部分响应可能格式错误，旧解析器需在受控回滚时继续可用。
决策
将 parser 选择写进应用配置回执，让每项任务使用一个有记录的变体，并测试回滚和进行中状态策略。
预期结果
结果能说明使用了哪个 parser/runtime；切换不会静默重跑任务或错标测试。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- BENCHMARK-01：测试结果需绑定实际使用的配置和工作负载，不能依赖开发者意图。
- COVE-MODEL-02：制品身份应明确；切换 flag 不等于制品兼容或设备支持已获验证。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 定义开关合同与负责人. 写明默认值、允许值、负责人、到期时间、兼容约束，以及变化是否需要重建或关闭 runtime。特别标出隐私影响。
- 生成实际配置回执. 把生效值绑定应用构建、制品、runtime/backend、parser 和任务策略。每条测试记录读取回执，不能依赖开发者备注。
- 一次只改变一个诊断维度. 除待测开关外保持 artifact、backend、parser 和工作负载稳定。记录请求与观察到的 backend，不得在无测量时声称性能。
- 覆盖回滚与进行中任务. 关闭路径，按预先规则取消或完成操作，排空或关闭不兼容状态，并验证旧回调不能改变新配置。
- 实验后移除临时分支. 为开关设置到期日期；采用或回滚后清理无用路径，在发布证据中注明决策及新的默认配置。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每项测试都注明生效开关版本、制品、runtime/backend、parser 和任务策略。
- 影响 runtime 的开关有明确所有者、默认值、允许值和资源重建策略。
- 回滚不会接受不兼容任务状态，也不会将旧 callback 应用到新变体。
- 不开关推断 backend 执行、机型兼容、隐私边界或性能。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 构建时固定的本地开关 | 随应用/测试配置版本记录 | 复现稳定，但需构建或受控配置更新才能改变。 |
| 远程 runtime 开关 | 只有先审核网络、隐私与降级策略才使用 | 安装后可变化；离线默认值和缓存值也需要独立证据。 |
| 未记录的开发者开关 | 不用于基准或发布结论 | 事后无法重建实际执行路径。 |
需要避免的失败模式
- 只记录“打开了 GPU flag”，却没有证据证明实际执行 backend。
- 回滚时保留旧 session 或 parser 上下文，让新路径收到不兼容状态。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
打开 GPU 开关能证明任务用了 GPU 吗？
不能。它只记录请求配置。实际执行证据应另行记录，并说明发生的 fallback 及测试使用的具体制品、设备和运行变体，不能只看开关值。
离线时能远程控制 runtime 开关吗？
远程值可能不可获取或过期。应明确本地默认值和缓存行为；本文不声称具体服务已部署，也不建议为开关擅自联网或上传用户输入。
实验结束后还应保留开关吗？
通常不应。设定负责人和清除日期；实验采用或回滚后移除旧分支，避免长期留下未经验证的组合，并记录新的默认值及测试范围。