当前形势
企业 AI 团队面临着降低大语言模型运营成本的巨大压力。实现这一目标的主要手段是模型量化，这是一种通过将模型的高精度浮点权重转换为低精度整数（如 INT8）来缩小模型的技术。这使得推理更快、更便宜，但我们现在发现，它也带来了可靠性方面的隐藏成本。最近的一篇论文《The Integer Alibi: Localizing Cross-Kernel Divergence in INT8-Quantized LLM Inference》揭示了一个惊人的不一致性来源。研究人员证明，在相同的硬件上，使用完全相同的量化模型和相同的输入，仅仅因为改变了用于数学运算的底层 GPU 软件包——即内核——就可能产生完全不同的输出。
具体来说，该研究发现，对于相同的 INT8 矩阵乘法，使用 NVIDIA 的 CUTLASS 内核与使用开源的 Triton 内核会导致 LLM 的最终输出存在差异。这一发现打破了大多数工程团队的一个基本假设：底层的、高度优化的软件包是可互换的商品。事实并非如此。这种微观层面的细微差异在宏观层面造成了重大的、不可预测的差异，直接威胁到实现真正 AI 可复现性的目标。
这预示着什么 在 AI 技术栈中对性能优化的不懈追求并非中立行为；它引入了细微且难以诊断的变量，可能会破坏模型的确定性。企业领导者不能再将运行模型的基础设施视为一个黑盒。
真正的挑战
这一发现带来的核心挑战是，它提高了对 AI 治理和可靠性的要求。多年来，确保模型行为一致性的重点一直放在控制模型权重、输入数据和解码参数（例如，将“temperature”设置为零）等变量上。我们现在有证据表明，另一个关键变量一直隐藏在显而易见之处：GPU 上底层数学运算的具体实现。这是企业 AI 技术栈的一个层面，大多数应用程序开发人员、数据科学家甚至 MLOps 工程师都很少（甚至从未）直接接触过。
这就造成了一个巨大的盲点。当模型出现意外行为时，团队可能会花费数周时间调试应用程序代码、数据管道或模型本身，却从未怀疑根本原因在于深度学习框架在选择一个 GPU 内核而非另一个时做出的一个静默、自动的选择。对于金融或医疗等受监管的行业来说，比特级的可复现性对于审计、合规和事件取证至关重要，因此这是不可接受的风险。正如麦肯锡关于管理 AI 风险的分析中所述，无法可靠地复现结果会侵蚀信任并使问责变得复杂。
此外，这个问题使整个 AI 生命周期变得复杂。如果基准测试结果因所用内核而异，你如何验证模型的性能？如果你无法保证唯一改变的变量是你想要改变的那个，你又如何进行 A/B 测试？一个稳定、可互换的基础是严谨的软件工程和科学方法的基石。这项研究表明，在量化 AI 推理的世界里，这个基础比我们想象的要不稳定。
企业行动手册
应对这一挑战需要从管理模型转向治理整个技术栈的思维转变。底层组件的可互换性不能再被理所当然地假定，而必须被强制执行。我们认为，有必要采取一种积极主动、有纪律的方法来减轻这一新兴风险。这涉及到将治理框架扩展到覆盖整个技术栈的深度，这是我们构建强大的数据平台与 AI 准备能力方法的核心原则。
企业必须从被动接受其 AI 基础设施转变为主动、有意识的标准化。这意味着不仅要明确定义、版本化和锁定 Python 库和模型权重，还要锁定 CUDA 驱动程序、深度学习框架，以及在可能的情况下，用于关键操作的特定内核。这种级别的控制是 MLOps 成熟度的重大提升，但现在对于任何在关键任务或受监管环境中部署 AI 的组织来说，这已成为一个先决条件。一个全面的AI 治理与风险框架现在必须考虑到这些硬件和软件依赖性，才能被认为是完整的。
| 场景 | 建议方法 | 主要风险 | 时间线 |
|---|---|---|---|
| 高风险应用（如财务报告、临床诊断） | 强制执行一个完全版本化、标准化的推理技术栈。如果无法保证比特级的可复现性，则使用 FP16/BF16 精度代替 INT8。 | 性能下降和推理成本增加。 | 立即 |
| 内部生产力工具（如内容摘要） | 容忍轻微的非确定性。使用 INT8 量化以节省成本，但需实施强大的端到端监控以捕捉显著的行为漂移。 | 如果未经人工监督，意外的模型输出可能导致错误的业务决策。 | 未来 3-6 个月 |
| 研发与模型原型设计 | 允许在技术栈中进行灵活的实验，但要求为每个实验详细记录完整的环境（驱动版本、库、硬件）。 | 研究结果可能无法完美复现，从而减慢从实验室到生产的转化过程。 | 持续进行 |
| 第三方 AI 服务（基于 API） | 要求供应商对其推理技术栈及确保确定性输出的政策保持透明。在服务水平协议中包含可复现性保证。 | 如果供应商无法提供足够的透明度，可能导致供应商锁定或无法满足合规要求。 | 未来 6-12 个月 |
按角色划分：本季度该做什么
| 角色 | 本季度优先事项 |
|---|---|
| 首席信息官 (CIO) | 委托进行风险评估，识别当前 AI 生产组合中非确定性构成重大业务或合规风险的应用。强制推行新的治理政策，要求所有高风险系统实现技术栈标准化。 |
| 首席技术官 (CTO) | 启动技术深度调研，盘点当前使用的不同推理技术栈。指派 MLOps 和平台工程团队开发一个“黄金”容器化推理环境，以便在整个组织内进行标准化。 |
| 首席信息安全官 (CISO) | 更新事件响应和数字取证手册，将底层推理技术栈作为异常行为的潜在来源。确保审计日志捕获关于任何给定模型预测的硬件和软件环境的足够详细信息。 |
检验策略的几个问题
- 我们目前如何验证模型的输出在不同的开发、测试和生产环境中是一致的？
- 对于我们推理技术栈中的底层软件（CUDA、内核、驱动程序），我们的标准化和版本控制政策是什么？
- 对于我们的哪些应用，比特级的 AI 可复现性是不可协商的监管或业务要求？我们目前如何测试和强制执行它？
- 在评估新的 MLOps 平台或云 AI 服务时，我们如何评估和减轻内核级差异的风险？
- 如果一个问题最终追溯到是 GPU 内核差异引起的，我们的调试和事件响应流程将如何处理？
结语
将 AI 推理技术栈视为简单商品的时代已经结束。对性能的追求引入了一个隐藏的复杂性和风险层，它会悄无声息地破坏模型的可靠性。要使企业 AI 真正值得信赖和可审计，领导者必须掌控并治理技术栈的每一层，从应用程序代码一直到硬件内核。实现 AI 的可复现性不再仅仅是一个数据科学问题，它已成为系统工程和公司治理的根本性挑战。