7.3 全链路部署工作流

7.3 全链路部署工作流

本节摘要：把六章的技能串成一条可重复的部署工作流：七个阶段的出入口交付物、自动化回归的三道闸门、上线后的遥测指标与反馈闭环。工作流的意义不是流程本身，而是让「下次部署」复制这次的成功。

全书走到的终点，是把零散的动作组装成可重复的流程。判断一个团队部署能力是否成熟，看的不是某次调优的惊艳数字，而是第二次做同类项目时，有多少动作可以直接复用。本节给出的七阶段工作流与三道闸门，就是为「可复用」设计的。

七个阶段，各自的出入口

阶段一，约束与选型：输入是业务需求，动作是 1.3 与 1.4 节的三问决策法，出口是「设备 + 运行时 + 延迟预算」三行字的选型记录。别小看三行字——它是后续所有分歧的仲裁依据。

阶段二，转换与对拍：按第 2 章产出 IR，对拍脚本进入版本库，出口是「IR + 数值一致性报告」。

阶段三，压缩决策：按第 4 章先量化后评估，出口是「精度与性能对照表」，达标线在阶段一就写好。

阶段四，编译与调度：按第 3 章定性能提示与并发模型，出口是「基准报告 + 属性快照」——7.1 节的三件套在此首次亮相。

阶段五，服务化：按第 6 章定路线与拓扑，出口是「过八项清单的服务」。

阶段六，灰度验证：小流量真实数据，验收指标与阶段一一致，出口是「灰度报告」。

阶段七，上线与遥测：全量发布，进入持续监控，出口不是一次事件而是长期的数据流。

七个阶段的最大价值在于责任切分：跨团队协作时，「转换环节的对拍谁负责、性能闸门谁签字」不再靠嘴皮，靠阶段边界。出问题时按环节归因（7.2 节铁律），改流程时按阶段复盘。

图 7-3 七阶段闭环与三道闸门

三道闸门：自动化的质量底线

闭环图里的三道闸门必须自动化，人工检查在迭代压力下必然失守。

闸门一，数值一致性：每次模型或转换配置变更，对拍脚本在 CI 里自动执行，误差超阈值即拦截。它防的是「看不见的精度损失」——最安静也最贵的一类事故。

闸门二，精度达标：全量测试集的指标对比基线，掉点超过预算即拦截，量化变更走 4.4 节的完整排错。闸门的核心是「基线受版本管理」——没有基线的达标判断都是感觉。

闸门三，性能达标：基准工具在标准环境跑，吞吐与延迟百分位对比基线，劣化即拦截。设备与提示参数固化在流水线配置里，保证每次测的是同一个系统。

三道闸门对应的正是三个最常见的回归来源：转换引入的数值变化、压缩带来的精度损失、配置漂移造成的性能劣化。每道闸门拦下的每一次合并，都是一次被避免的线上事故。

遥测与反馈：上线不是终点

全量上线后，四类指标持续回流：延迟分位数与吞吐（7.1 节口径）、错误率与超时率、资源水位（内存、温度）、以及业务向的模型输出分布——最后一类最容易被忽略，却最早暴露「数据分布漂移」：当输入分布逐渐偏离训练与校准数据，模型精度会无声劣化，等业务指标报警时往往已过期数月。输出分布监控就是提前量。

告警触发的复盘按固定套路走：7.2 节定环节、按阶段找责任、修复进闸门防复发。复盘的产物回流两处——故障案例库（给 7.2 节的索引加行）与工作流本身（哪个阶段漏了检查就补哪个阶段）。工作流因此是活的：每个项目结束时它都比项目开始时厚几页。

阶段出口物长什么样

七个阶段的出口交付物，补一份具体的形态说明，让流程可落地。阶段一的选型记录是一页纸：三条约束、选型结论、三条理由，评审十分钟。阶段二的对拍报告是两张表：误差统计表(最大、平均、分布)与环境快照，加上「通过或未通过」的结论行。阶段三的对照表在 4.1 节见过原样。阶段四的基准报告附属性快照，7.1 节的档案化就是它的归宿。阶段五的八项清单逐项打勾，负责人签名。阶段六的灰度报告含业务指标对比与异常清单。阶段七的遥测基线就是监控面板的初始阈值。这份清单的共同特征：每一份都轻、都具体、都有人签名。流程的死法通常是「交付物太重没人写」或「太虚没人看」——一页纸加签名，是两者之间的平衡点。

小团队的极简版工作流

七阶段对大项目成立，三五人团队照搬会累。给一个极简变体：阶段一与阶段二合并成「定约束转模型」(选型记录可以只有三行字)，阶段三视项目需要跳过(不做压缩就没有这个阶段)，阶段四五合并成「调通上线」(小团队的服务化往往就是一个进程加一份配置)，阶段六七合并成「灰度加盯盘」。合并后的极简版只剩四个动作，但两条底线不能省：对拍脚本必须跑(闸门一不可省)，基准对比必须做(闸门三不可省)。流程可以瘦，验证不可缺——这是极简版与「没有流程」之间唯一的、也是本质的区别。

与上游团队的协作接口

全链路工作流的另一端接着算法团队，阶段边界就是协作接口。实践中有三条经验。其一，把部署约束前置到模型设计：2.3 节的「部署友好建议清单」在模型设计评审时就交给算法组，比训练完再改结构便宜十倍。其二，用数据说话的交接单：模型从算法侧交到部署侧时，附精度报告、输入输出规格、已知短板三件套——「口头说没问题」不算交接。其三，共建回归集：部署侧发现的问题样本(7.2 节的故障案例)回流给算法侧进训练或评测集，两侧的验证集共同生长。这三条经验合起来是一句话：部署与算法不是下游加工上游交付的流水线，而是一条双向反馈的环——工作流里的每一份出口物，都是这个环上的接头。

三个高频追问

工作流话题收尾，回答三个高频追问。追问一：流程会不会拖慢迭代速度？设计得当不会——闸门是自动化的，跑在 CI 里，单次执行分钟级；真正拖慢迭代的是没有闸门的团队：每次事故后的排查与返工，消耗的时间远超闸门的运行成本。流程的意义正是把「事故驱动的慢」换成「例行检查的快」。追问二：历史项目没有这些交付物，怎么补？不补历史，只做增量——从下一个项目起按阶段留档，同时把当前在线系统的基准档案与遥测基线补起来(这两样是运维的刚需)；完整的流程覆盖靠新项目滚动建立，补历史档案的完美主义会拖死行动力。追问三：这套工作流适用于其他推理栈吗？适用于大部分——七阶段的骨架、三闸门的思想、遥测的口径都是推理栈无关的，换的只是工具名；这本书教到第 7 章，读者应该已经能看出哪些是 OpenVINO 的细节、哪些是部署的通则——分清这两者，才是从「会用一个工具」到「会做部署」的毕业礼。

写在最后：把判断力留给值得的地方

七章走完，回顾这本教程的立场：部署是一连串选择题，工具与方法负责把大部分选择变成有据可依的常规题，把工程师的判断力留给真正的新问题。这本书教不完部署——设备在换代、模型在演化、工具链在更新，但它教过的决策方法——先定约束再选方案、先测量后动手、按环节归因、用闸门守底线——在工具链换代后依然成立。愿你下一次面对「模型在我机器上跑不快」的抱怨时，手里多的是方法，少的是运气。

本节要点回顾

• 七阶段流程：约束选型、转换对拍、压缩决策、编译调度、服务化、灰度、上线遥测，每阶段有明确出口交付物。
• 三道闸门：数值一致、精度达标、性能达标，全部自动化并入合并流程，基线受版本管理。
• 遥测四类指标：性能、错误、资源、输出分布；输出分布监控是精度无声劣化的提前量。
• 闭环即进化：复盘产物回流案例库与工作流，流程随项目生长。