机器学习模型为什么不能完全按照普通软件的发布方式部署

机器学习模型并不是脱离传统软件工程体系的一套独立技术。实际上，生产环境中的机器学习系统同样会使用 Git、CI/CD、容器镜像、镜像仓库、Kubernetes、自动化测试、灰度发布和版本回滚。真正的区别在于，传统软件主要围绕代码和运行环境进行交付，而机器学习系统除了代码，还必须管理模型权重、训练数据、特征处理、模型评估指标以及推理硬件等一系列依赖。因此，机器学习模型不能简单地把一个软件包复制到服务器上，就认为部署已经完成。

传统应用通常可以把源代码、编译产物、依赖库和配置文件组织成一个相对稳定的发布单元。例如一个 Web 服务构建出容器镜像以后，只要运行环境满足要求，同一个镜像通常可以在测试环境、预发布环境和生产环境中重复部署。机器学习推理服务也可以采用完全相同的容器化方式，但容器中的推理程序只是整个模型服务的一部分。模型权重可能是数百 MB、数 GB 甚至更大，而且通常还需要独立的模型版本和存储管理。

因此，一个生产模型不能只记录“代码版本是多少”。更完整的模型发布信息通常还包括模型版本、模型文件或对象存储地址、训练数据版本、特征处理逻辑、训练参数、评估结果、运行时版本以及部署所使用的硬件环境。这样，当线上模型出现效果下降或者延迟突然升高时，工程团队才能追溯究竟是模型本身发生变化，还是代码、数据、依赖库、配置或者硬件环境发生了变化。

模型的计算特征也会影响部署方式，但这里需要避免把机器学习和普通软件简单划成两种完全不同的计算模式。普通程序同样存在动态内存、缓存和运行时计算，机器学习模型的特殊性主要来自大规模张量计算以及模型参数规模。以 Transformer 为例，推理过程中需要执行矩阵乘法、注意力计算、归一化以及其他算子，大量计算会依赖 GPU、NPU 或其他专用加速器。

对于大语言模型，还存在 KV Cache 这一特殊的运行时缓存。模型在生成文本时，可以缓存已经计算过的 Key 和 Value，避免每生成一个新 Token 都重新计算整个历史上下文。KV Cache 的显存占用通常会随着上下文长度增加而增加，在其他主要参数固定的情况下，可以近似理解为与缓存的 Token 数量呈线性关系，而不是指数级增长。Batch size、层数、注意力头数量、KV 头数量以及数据类型都会影响实际占用，因此生产环境需要根据具体模型计算显存需求。

模型参数本身也会带来明显的内存带宽压力。以 NVIDIA A100 为例，其高带宽内存系统具有很高的理论带宽，但理论规格并不等于任何模型推理任务都会达到同样的实际吞吐。对于不同的模型和工作负载，瓶颈可能来自 GPU 计算能力、显存带宽、算子效率、CPU 数据准备、PCIe 传输、批处理策略或者网络通信。LLM 的生成阶段在某些工作负载下尤其容易受到显存访问效率影响，因此需要通过实际 profiling 判断瓶颈，而不能只看 GPU 型号。

模型输入也使部署链路比普通 Web 服务更加复杂。一个计算机视觉模型可能接收 JPEG 或 PNG 图片，随后执行解码、尺寸调整、色彩处理、归一化和张量布局转换；自然语言模型可能需要 tokenizer 将文本转换为 Token ID；传统机器学习模型则可能依赖特征编码、缺失值处理和标准化。不同模型的预处理方式完全不同，因此这些步骤应该被视为模型服务的一部分，并纳入版本管理和测试。

预处理也不一定必须与模型计算图深度集成。简单的预处理可以由 CPU 完成，性能要求较高时可以采用 GPU 加速，也可以由独立的数据处理服务完成。对于实时系统，真正重要的是整个请求链路的延迟，而不是规定所有预处理必须放进模型计算图。工程人员需要通过 profiling 判断 CPU、GPU、内存、网络以及数据转换究竟在哪里消耗了时间。

模型部署还有一个普通软件通常没有那么突出的特点，就是“功能正确”并不代表“业务效果正确”。一个软件版本只要测试用例通过、接口行为符合预期，通常就可以进入发布流程；模型则需要进一步验证准确率、召回率、F1、AUC、生成质量或者其他与具体任务相关的指标。不同模型的评价指标不同，因此模型发布流程往往需要同时包含软件测试和模型评估。

更重要的是，模型效果可能随着真实生产数据变化而发生变化。训练数据与线上数据的分布出现差异时，可能产生数据漂移；输入与目标变量之间的关系发生变化，则可能涉及概念漂移。这并不意味着模型一定立即失效，但生产系统需要持续监控相关指标，并在必要时重新训练、重新评估和重新发布。传统软件也需要监控错误率和业务指标，但机器学习系统还需要额外关注模型效果和数据变化。

模型更新因此也不能简单理解成“修改代码以后重新编译”。模型更新可能只是替换权重，也可能同时改变 tokenizer、特征处理、模型结构和推理代码。某些模型更新不需要重新构建容器镜像，尤其是推理代码保持不变、模型权重独立存储的情况下；另一些更新则可能需要新的运行时依赖，因此必须重新构建镜像。成熟的系统应该明确记录模型版本与代码提交、容器镜像摘要以及配置版本之间的对应关系。

这也是模型注册中心和容器镜像仓库需要分工的原因。容器镜像仓库主要保存应用和运行时镜像，例如推理服务器、Python 依赖以及相关系统库；模型注册中心主要记录模型版本、生命周期状态、评估结果和相关元数据；模型文件本身则经常存放在对象存储或专门的模型制品存储系统中。三者可以通过版本信息建立关联，但不应该把所有东西强行塞进同一个仓库。

GPU 和 NPU 的资源管理同样需要纳入部署体系。Kubernetes 可以负责容器调度和资源管理，但它本身并不会自动理解一个模型需要多少显存、哪些 CUDA 或 NPU 运行时、什么硬件架构以及怎样进行批处理。生产环境通常需要通过资源请求、设备插件、运行时配置和节点标签等方式，让工作负载被调度到合适的计算节点。

在某些边缘设备中，CPU、GPU 和 NPU 确实可能协同工作，但这属于具体硬件和模型架构决定的实现方式，并非所有机器学习部署都必须如此。有的模型完全运行在 CPU 上，有的主要运行在 GPU 上，也有模型通过 NPU 加速。部署设计应该从实际算子支持、内存带宽、功耗、延迟和吞吐要求出发，而不是为了“异构计算”而增加复杂度。

推理框架则负责把训练得到的模型变成能够高效执行的计算任务。ONNX Runtime、TensorRT 等工具可以根据模型和硬件执行图优化、算子融合、精度转换以及硬件加速。具体能够使用哪些优化能力，需要看模型结构、版本和目标硬件。量化也不是简单点击一个选项就能完成，INT8、FP16、BF16 等不同精度会影响显存占用、吞吐以及模型效果，需要通过实际验证确定。

因此，机器学习部署真正复杂的地方，不是因为它不能使用传统软件工程方法，而是因为传统软件交付链路之外又增加了一组模型特有的依赖。一个成熟的生产系统仍然可以使用 Git 管理代码，通过 CI 运行测试，通过容器构建运行环境，通过镜像仓库保存不可变镜像，再由 Kubernetes 或其他平台完成部署。与此同时，还需要独立管理模型版本、模型制品、训练数据版本、模型评估、推理性能和线上效果。

对于大型 AI 平台来说，最终需要解决的是可追溯性。出现一次线上问题时，工程人员应该能够回答：当前运行的到底是哪一版推理代码、哪一个容器镜像、哪一个模型权重、使用了哪一版数据和特征处理逻辑、采用什么配置、运行在哪种硬件上，以及上线以后模型效果和资源消耗发生了什么变化。

所以，机器学习模型并不是不能按照普通软件的方式发布，而是不能只按照普通软件最简单的方式发布。传统 CI/CD、容器化和基础设施自动化仍然是底座，只是模型系统需要在这套底座上增加模型注册、模型制品管理、数据与特征版本、模型评估、GPU/NPU资源管理以及线上模型监控。理解这一点以后，机器学习部署就不再是一套神秘的“特殊发布体系”，而是一种在成熟软件工程基础上增加数据和模型生命周期管理能力的工程系统。