Azure ML端点部署：预处理集成、选型及计费差异咨询

• 该需求完全可以实现，不需要调用方在发送请求前自行完成数据标准化、OHE编码等预处理操作，也完全支持将训练阶段拟合得到的StandardScaler、OHE编码器等预处理逻辑和模型部署在同一个端点中，这也是Azure ML官方推荐的生产级部署方案，从根源上避免训练-推理数据分布不一致的问题。
• 具体实现有两种通用方案，按需选择即可：
  • 方案一（最推荐，出错率最低）：训练阶段直接使用sklearn.pipeline.Pipeline拼接全流程：通过ColumnTransformer分别配置分类特征的OHE编码规则、数值特征的StandardScaler标准化规则，最后衔接你训练好的分类/回归模型，在训练集上完成整个pipeline的拟合后，将整个pipeline对象序列化注册为Azure ML模型，部署后端点接收到原始数据会自动按训练时的逻辑完成预处理、推理全流程，不需要额外写推理逻辑。
  • 方案二（适合自定义逻辑复杂的场景）：编写自定义入口脚本score.py，在init()函数中同时加载训练好的模型、在训练集上fit完成的StandardScaler对象、OHE编码器对象；在run()函数中先对传入的原始请求数据依次执行编码、标准化转换，再送入模型推理，最后返回推理结果。
• 只有当你仅部署裸模型、未将预处理逻辑打包进端点时，才需要调用方自行完成数据预处理，这种方案极易因为预处理逻辑不一致、统计值（比如scaler的均值、方差）不匹配导致推理结果偏差，生产环境不推荐使用。

注意：无论用哪种方案，预处理环节的StandardScaler、OHE编码器都必须使用训练集拟合完成后保存的对象，推理阶段仅能执行transform()操作，绝对不能在请求处理环节重新对传入的原始数据执行fit()，否则会因为统计值偏差导致推理结果完全错误。

• 端点选型结论：你的场景必须选用实时（在线）端点，不适合使用批量部署（batch deploy）。
  • 批量端点的设计定位是异步离线任务处理：任务提交后需要等待计算资源调度、节点启动，处理延迟为分钟级到小时级，仅适合不需要即时返回结果的场景（比如每日定时批量跑数、离线生成预测报表），完全无法满足用户在应用内操作后即时看到预测结果的交互需求。
  • 你提到的单次请求2000-40000条记录的负载，实时端点完全可以承载：部署时根据推理性能需求选择对应规格的计算实例，配置自动扩缩容策略即可，4万条记录的推理在配置合理的节点上仅需数秒到十几秒，完全符合应用内展示的延迟要求。注意提前在部署配置中调大请求体大小限制、推理超时时间，避免触发默认阈值拦截大请求。
• 实时端点计费规则：
  • 如果使用ACI实例或者固定实例数配置的托管在线端点/AKS端点，只要实例处于运行状态，无论是否有API请求都会产生计费，空闲时段的成本需要自行承担，这类配置更适合测试场景或者流量持续稳定的生产场景。
  • 如果使用支持自动缩容到0节点的Serverless托管在线端点，无请求时计算节点会缩容到0，不会产生空闲时段的计算费用，仅在请求到达、节点启动处理请求时按实际消耗的计算资源计费，非常适合流量波动大的面向用户的应用场景。
• 批量端点与在线端点的成本差异：
  • 批量端点无常驻资源成本，仅在批量任务运行时按实际占用的计算资源时长计费，单位计算资源的单价和在线端点同规格资源基本一致，但因为不支持低延迟响应，无法适配你的业务场景。
  • 在线端点如果采用固定实例配置，因为存在空闲时段的资源浪费，长期运行成本高于批量端点；如果采用缩容到0的Serverless配置，无请求时几乎无成本，高负载持续有请求时的成本和同规格批量端点基本持平，同时能满足低延迟交互要求，是你这个场景的最优选择。

内容的提问来源于stack exchange，提问作者MaciJab