作者：毛烁

过去一年，企业在AI投入上的策略正在发生明显收缩。CIO、CTO们逐渐意识到，AI落地的问题已经不再是“有没有能力做”，而是成为了“现有做法是否还能继续做”的问题。

一方面，在于成本结构的挑战。随着内存等关键硬件价格上涨，大模型在推理阶段的资源消耗持续放大，算力投入变成了长期、线性增长的支出。另一方面，模型迭代节奏显著加快。企业刚完成一次部署，模型版本便有了更新，导致系统周期被不断压缩。

这些因素叠加在一起，就改变了其对企业级AI的技术判断。继续通过堆GPU推进落地，不仅成本不可控，也缺乏长期稳定性。在这样的前提下，企业开始重新审视AI的系统形态，思考是否能够通过架构层优化，在可控成本与合规前提下，把AI变成可持续运行的工程能力。

用Cloudera大中华区技术总监刘隶放的话说，问题的关键不在于“算得有多强”，而在于企业是否能够在真实业务环境中，持续让AI产出确定性的结果。

Cloudera 大中华区技术总监 刘隶放

01 以“湖仓一体”对抗数据熵增

在实际落地过程中，许多企业发现，AI的不确定性往往并不是出现在模型本身，而是更早地暴露在数据层面。一旦进入真实业务环境，模型训练、特征工程与推理调用需要同时依赖多套数据系统，数据口径一致、来源清晰，是绕不开的问题。

也正是在这一背景下，合规被提前摆到了台面上。“在谈企业级AI之前，我们必须先谈合规。没有合规，AI无从谈起。”刘隶放反复强调。但在他看来，合规并不是独立的条件，而是企业数据体系复杂性不断累积后的结果。当数据无法被统一管理、无法被清晰追溯，AI的风险首先会在合规问题中显现出来。

对大多数企业而言，从最早的ODS（操作型数据存储），到数据仓库，再到数据集市，数据在不同层级之间被反复复制、清洗、重组。虽然在以报表和传统分析为核心的时代，这种架构尚可接受，但是一旦进入AI应用场景，其代价便会被迅速放大，带来存储成本的指数级增长，更持续侵蚀数据的一致性。

当AI模型需要跨平台、跨引擎调用数据时，“究竟该使用哪一份数据”反而成了一个难以回答的问题。

针对这一现实挑战，Cloudera给出的答案是推进“数据湖仓一体”（Data Lakehouse）架构，并拥抱Iceberg表格式。刘隶放解释道：“过去是数据库负责报表，数据湖负责分析，两套系统、两份数据。如今，随着Iceberg组件的成熟，我们已经可以直接在数据湖之上构建数据仓库级别的能力。”

这一数据湖仓一体架构转型所释放的技术红利十分明确：

其一是零数据冗余。企业无需再为不同计算引擎（Spark、Hive、Impala、AI Training等）反复搬运和复制数据。一份数据即可支撑多种工作负载。

其二，Schema Evolution（模式演进）。面对结构化数据与非结构化数据（例如车企的车窗图像数据）并存、融合分析的需求，数据湖仓一体架构通过统一的元数据管理机制，使模式演进变得可控且可追溯。

对Cloudera本身来说，在于数据血缘（Data Lineage）能力的补齐。2024年底Cloudera收购Octopai的技术价值，正是在这一阶段集中显现。刘隶放指出：“收购Octopai后，很快与我们的SDX（共享数据体验）体系完成了深度融合。现在，我们不仅知道数据存放在哪里，还可以通过可视化方式清晰追溯数据从何而来、被谁修改过、最终被哪些模型所使用。”

对于金融、医疗等合规要求极高的行业而言，这种端到端的数据可追溯性，是AI模型通过合规审查并进入生产环境的重要基础。

02  拒绝“黑箱”运行  AI 引擎装上“变速箱”

如果说数据是AI的燃料，那么计算层就是驱动这些燃料持续运转的引擎。在这一层面，Cloudera在2025年8月收购的Taikun，正是为这台引擎补上的关键“变速箱”。

刘隶放特意强调：“Cloudera收购Taikun，并不是为了去卖Kubernetes，而是为了给客户提供一个长期、可控且可持续演进的运行环境。”

随着AI工作负载日益复杂，企业IT环境正走向前所未有的碎片化，模型训练往往依赖公有云所提供的弹性GPU资源，而模型推理则必须回到本地数据中心或专有环境中运行，以满足隐私保护与合规要求。在这种多云与本地并存的现实条件下，Taikun的核心价值，在于提供了统一的控制平面（Unified Control Plane），将分散的计算环境重新纳入同一套治理体系。

从技术实现上看，Taikun的加入，让Cloudera真正实现了计算与存储的解耦，以及跨环境的一致性运行能力：

1.统一接口。无论底层运行在AWS、Azure，还是私有云的Bare Metal之上，上层AI应用所面对的始终是标准的Kubernetes API，从而屏蔽了基础设施差异。

2.BYOE（Bring Your Own Engine）。作为高度开放的技术策略。用户企业不再被厂商预设的计算引擎所绑定，而是可以在Cloudera平台上自由运行Spark、Flink，甚至是自行封装的AI推理服务。

3.零停机运维。面向拥有数千台服务器的大型车企等重资产行业，Taikun支持在不中断业务的前提下进行滚动升级。这一能力对于实时性和连续性要求极高的生产制造场景尤为关键。

这些能力的背后，意味着AI平台的抽象层级开始从“数据和模型”向下延伸至“运行环境”本身。计算不再只是被动消耗的资源，而成为可治理、可审计、可持续演进的基础能力。

这一转变，正是AI系统走向长期生产系统所经历的技术跃迁。

03   把AI资产真正留在企业里

在不少企业内部，模型训练代码、特征工程逻辑和运行环境，往往绑定在某个数据科学家的个人电脑、Notebook环境，或者某次临时搭建的云实例上。一旦人员流动、环境变化或模型升级，原本“能跑”的模型就变成了不可复现、不可维护的黑箱资产。

为应对这一现实挑战，Cloudera在模型层面强调一套松耦合（Loose Coupling）的工程化原则——不把AI能力绑定在人、机器或某个一次性的环境上，而是通过平台机制，将模型拆解为可管理、可复现、可替换的工程对象

在具体实现上，Cloudera引入了“模型控制器”的核心组件，用于对模型的训练、部署、推理和回滚进行统一管理。这一组件的关键在于为模型固化完整的工程上下文，确保模型在进入生产环境后仍然可理解、可定位、可操作。

在模型注册阶段，平台会同时记录并绑定多个信息。

第一，是模型版本与Hash标识。每一次模型产出都会生成唯一的版本号与Hash，用于精确区分模型二进制本身。当线上效果异常时，工程团队可以快速确认当前服务实例运行的到底是哪一个模型，而不是停留在“看起来是最新版”的模糊判断中。这也是模型回滚和多版本并行部署的基础。

第二，是训练所使用的数据集版本（对应Iceberg表快照）训练数据明确绑定到某一个Iceberg表快照。当模型指标发生波动时，可以直接判断问题来自数据分布变化，还是模型参数本身的调整，避免在“是不是数据变了”这个问题上反复猜测。

第三，是特征工程与参数配置。所有特征处理逻辑、特征选择规则以及超参数配置都会与模型版本一起固化，而不是散落在Notebook或脚本中。这保证了模型可以被完整复现，也避免了“代码没变，但结果不一样”的隐性风险。

第四，是评估指标与基准结果。每一次训练结果都会附带当时的评估指标和对照基准，用来判断模型提升是否真实存在，还是统计波动。当线上表现退化时，可以快速对比历史版本，明确是模型问题，还是业务环境发生了变化。

第五，部署目标与运行环境信息。模型在注册阶段就会明确其部署位置和运行环境，包括目标集群、计算引擎类型以及资源规格。这使得“训练能跑、上线跑不起来”的环境不一致问题，在进入生产前就被提前暴露并解决。

通过这套机制，模型就成为了一个带有完整上下文、可被平台理解和操作的工程单元。

在模型策略选择上，刘隶放也基于现实工程条件给出了更务实的建议。刘隶放指出，在硬件成本持续上升、工程复杂度不断提高的背景下，不应盲目押注大模型。如果企业具备较强的工程和算力能力，可以在RAG（检索增强生成）之上进行Fine-tuning；如果能力有限，至少要把RAG体系搭完整。

建议背后也有一套清晰的分层设计：

RAG层上，检索索引直接构建在企业私有数据之上，并与Iceberg表的版本保持一致。每一次检索结果都具备明确的数据来源和版本边界，便于回溯和审计。

模型层可优先采用相对小参数模型，降低推理时的显存占用和延迟压力。Fine-tuning仅针对特定业务语义进行，而非覆盖通用能力。

推理层上，推理服务作为独立计算引擎运行，通过BYOE机制进行调度，既可以部署在公有云GPU环境，也可以运行在本地数据中心，满足隐私与合规要求。

通过私有数据 + RAG + 小参数模型的组合，模型生成过程就不是不可解释的黑箱。每一次回答，都可以追溯，同时将算力成本控制在可预期范围内。

04 写在最后

Cloudera 围绕数据层、资源调度层与模型交付层所做了一系列的补全，本质上是在降低系统的不确定性边界。

在数据侧，以Iceberg为核心的湖仓一体架构，通过快照、Schema 演进与时间点一致性，将训练数据、特征数据与业务事实绑定在同一可验证状态中。

Octopai 提供的跨系统血缘分析，使数据流转路径与影响范围具备了工程级上午可见性。

在算力侧，Taikun提供的统一Kubernetes控制平面，将GPU、CPU 及其他加速资源抽象为标准化调度对象，减少模型训练与推理对单一云平台专有能力的依赖。

在模型交付层，通过模型版本、数据快照与运行上下文的强绑定，推理结果获得了可复现与可回滚的前提条件。

当这些被系统性引入后，AI才能以更接近传统IT的方式运行。随着模型能力趋于同质化，企业间真正拉开差距的，将是对数据可控、算力可迁移工程稳定性的长期治理能力。

正是这些能力，决定了AI是否具备进入核心生产系统并持续运行的工程条件。