GS Caltex打通SageMaker无代码模型生产化，部署缩至数小时

摘要：韩国能源化工企业GS Caltex将SageMaker Canvas中由流程工程师验证的模型与Data Wrangler预处理流程，交接到SageMaker Pipelines、Model Registry和EventBridge组成的生产管线。ML工程师可复用模型资产、审批状态及预处理逻辑，每30分钟执行一次Batch Transform批量推理，不再长期维持实时端点。公司称部署周期由约一周缩短至数小时，并降低推理成本。方案的关键并非新模型，而是打通无代码开发、版本治理与可审计调度之间的工程断点。

---

核心做法：把无代码模型资产接入可编排的生产管线

GS Caltex将模型开发与上线运维拆成两条协作路径：流程工程师在SageMaker Canvas中可视化准备数据、构建并评估模型；ML工程师则在SageMaker Pipelines中配置生产步骤、模型版本和调度计划。经Canvas验证的模型通过Model Registry完成注册与审批，Data Wrangler生成的.flow文件及对应SageMaker Processing配置负责复用预处理逻辑。

整套生产链路为：

EventBridge定时触发 → Pipelines编排 → Processing预处理 → Batch Transform推理 → S3结果汇总

EventBridge负责每30分钟启动管线，Pipelines维护步骤依赖，Processing运行Data Wrangler流程，Batch Transform使用已审批模型执行批量推理，最终将预测结果写回S3。ML工程师可通过CloudWatch日志和Pipeline执行状态定位失败环节。

五步生产推理管线如何工作

参考实现将工作流拆成五个明确步骤：

1. PrepareInput：准备推理输入，并在必要时补齐训练流程所依赖的目标列。
2. PreprocessNewData：在SageMaker Processing中执行导出的Data Wrangler .flow文件。
3. DropTargetColumn：移除占位目标列和CSV表头，输出无表头的特征文件。
4. BatchPredict：调用SageMaker Batch Transform完成批量预测。
5. AssembleResults：按记录位置合并预处理结果与预测文件。

步骤之间通过depends_on确定执行顺序，并利用步骤输出属性传递S3 URI，而不是在代码中硬编码中间结果位置。这种做法将预处理、推理和结果组装拆成可审计单元，每个阶段都能独立检查输入输出。

工程上最棘手的问题是训练数据包含目标列，而真实推理数据通常不包含目标列。参考实现会在预处理前加入类型和列位置匹配的占位值，完成变换后再将其删除。不过，这一技巧仅在目标列不影响特征计算时成立；如果流程按目标值过滤样本、由目标值派生特征或执行目标编码，就必须进一步拆分推理所需的状态，不能机械套用占位值方案。

复用预处理资产的关键：保持变换状态一致

Data Wrangler流程记录的不仅是代码式操作，还包含训练阶段学习到的缩放、编码等状态。生产推理时必须复用这些参数，不能对每个批次重新拟合，否则输入分布和训练时的特征空间将发生漂移。

迁移时需要逐一核对：

• .flow文件引用的S3输入位置；
• Processing作业使用的容器镜像及其版本；
• 输出节点与输出名称；
• 缩放、编码等已学习参数；
• Canvas与Processing在相同输入上的列顺序、数据类型和转换结果。

原文特别提醒，声明Pipeline参数并不会自动替换.flow文件内部的S3 URI。若多个执行共用固定输入路径，可能发生并发覆盖；更稳妥的实现是在每次运行前复制流程文件并更新源URI，同时把中间结果与最终结果按执行ID隔离。跨Region部署时，还需确认容器镜像在目标区域可用。

模型审批必须落实到执行路径

模型注册后，Model Registry会记录模型包、评估结果和审批状态，但审批状态并不会自动阻止每次Batch Transform调用。因此，部署代码应显式检查ModelPackageStatus与ModelApprovalStatus，再根据已审批的model_package_arn创建SageMaker模型资源。

生产配置还应固定模型包ARN和模型名称。如果审批被撤销，调度器或部署流程需要同步停止或切换对应执行配置，不能仅依赖控制台中的状态展示。模型注册和资源创建只在新版本发布时执行，每30分钟的推理任务复用已部署模型，不会重复注册。

Batch Transform与实时端点的工程权衡

SageMaker Pipelines本身负责无服务器编排，但Processing与Batch Transform仍会依据实例类型、实例数量和运行时长计费，并产生S3、CloudWatch等配套费用。

| 维度 | 实时推理端点 | Pipelines + Batch Transform | |---|---|---| | 资源生命周期 | 实例持续在线 | 作业结束后释放计算资源 | | 成本驱动 | 端点在线时长与容量 | 作业时长、频率、实例数及配套服务 | | 适用场景 | 持续在线请求、稳定低延迟 | 周期性批量处理累积数据 | | 新增模型影响 | 增加常驻容量与托管成本 | 增加批处理任务时长和并发压力 |

每30分钟调度意味着每天最多产生48次执行，但成本不能只按“推理计算”估算。完整运行时间还包括实例启动、预处理、后处理、失败重试和跨服务等待。对于低频、允许分钟级延迟的数据处理任务，批处理可以释放闲置端点容量；若业务要求稳定的亚秒级响应，Batch Transform仍会因启动和编排开销失去优势。

还需防止调度重叠：单个Pipeline内部的依赖控制不会阻止另一次Pipeline执行并发启动。生产系统应检查活动执行，避免同一数据窗口被重复处理，并使用独立输出路径隔离不同批次。

结果合并是容易被忽略的正确性风险

参考实现按行位置合并预处理数据与预测文件，这种方法隐含一个前提：预处理过程不能改变行序或丢弃记录。如果流程执行排序、过滤、去重或聚合，预测与原始记录可能错位。

上线前至少应校验：

• 输入与输出行数一致；
• 源记录ID和预测结果的映射稳定；
• 预处理输出列名、类型及顺序与训练特征一致；
• Schema错误或预处理失败时禁止发布下游结果。

对于不能保证稳定行序的场景，应在预处理前附加唯一记录ID，并在结果汇总时按键连接，而不是依赖文件行号。

GS Caltex的实际收益与局限

GS Caltex报告，模型部署时间由约一周缩短至数小时，推理改为每30分钟执行一次，并实现了有意义的成本节省。其收益主要来自减少重复集成工作：流程工程师继续负责模型有效性和工艺知识，ML工程师则聚焦部署、监控与运行治理。

不过，“一周到数小时”和“成本降低”均为企业自报结果，原文没有给出具体项目数、模型类型、数据规模、部署前后的绝对成本或完整基准。对于实际采用者，更合理的验证方式是分别记录开发、审批、集成、试运行和上线耗时，并比较端点在线费用与批处理全链路费用。

落地建议

团队可从一个已验证模型开始，先手动执行Pipeline完成端到端对照，再开放定时调度。推荐顺序是：

1. 对齐Canvas与Processing的输出列、类型、行数和转换值；
2. 验证占位目标列不会改变任何特征；
3. 固定并版本化预处理容器、.flow文件与模型包；
4. 用代表性数据测量全流程耗时和总成本；
5. 测试重叠执行、失败重试与重复数据窗口；
6. 为CloudWatch失败告警、处理延迟和数据质量设置阈值；
7. 为每次运行记录输入窗口、流程版本、模型包ARN、执行ARN及输出位置。

这套架构的真正价值，是把Canvas的易用性与Pipelines的可编排性连接起来，同时利用Model Registry保留治理边界。它并不消除模型漂移、数据质量或业务漂移，但能显著降低从“已验证模型”到“可重复生产任务”之间的集成摩擦。

---

消息来源：AWS Machine Learning Blog (2026-11-13)

—— 完 ——

主题标签： #SageMaker Canvas 关注 #SageMaker Pipelines 关注 #MLOps 关注 #批量推理 关注 #GS Caltex 关注