1. 从“试点”到“AI工厂”这个提法到底在说什么“AI工厂”这个词最近被反复提起很多人第一反应是又一个营销概念。但如果你真正在企业里落地过AI项目就会明白这个词背后指向的是一个非常具体的痛点绝大多数企业的AI应用还停留在“试点”阶段做完一个POC概念验证就没了下文根本形不成规模化、可持续的生产能力。所谓“试点”典型场景是这样的某个业务部门觉得AI能解决一个问题于是拉上两三个算法工程师搞了几个月出了一个Demo准确率看起来还不错。然后呢然后就没有然后了。模型部署到哪里谁来维护数据管道怎么持续供给推理成本谁来承担这些问题在试点阶段统统没有答案。结果就是企业花了不少钱攒了一堆“AI试点项目”的PPT但真正在生产环境里跑起来、每天产生业务价值的屈指可数。“AI工厂”要解决的恰恰是这个断层。它的核心思路是把AI能力当作一种工业品来生产——有稳定的原材料输入数据有标准化的生产线训练与推理流水线有质量管控模型评估与监控有产能规划算力调度最终有可交付的产品AI服务。这个类比不是修辞上的花哨而是对基础设施提出了完全不同的要求。我见过不少团队在试点阶段用的是几块消费级显卡模型训练靠一台工作站推理直接跑在测试服务器上。这种模式在试点阶段完全够用但一旦要扩展到几十个业务场景、每天处理百万级请求立刻就会撞上三堵墙算力墙、数据墙、运维墙。算力不够可以买但怎么买、买什么、怎么组网、怎么调度这些问题的答案和试点阶段完全不同。数据墙指的是数据供给的稳定性和质量——试点时可以用一份清洗好的静态数据集但生产环境里数据是持续流入的格式在变、分布在变、质量在波动。运维墙则是指模型上线后的监控、回滚、版本管理、成本控制这些在试点阶段基本被忽略。所以“AI工厂”这个提法本质上是在说AI的基础设施需要从“手工作坊”升级为“工业流水线”。这个升级涉及芯片、网络、存储、软件栈、调度系统等多个层面的协同设计不是简单地把GPU数量翻十倍就能解决的。接下来我会从几个关键维度拆解这个升级过程中真正要面对的技术选择和实操细节。2. 算力底座的选择逻辑为什么不是“越多越好”2.1 训练与推理对硬件的要求根本不是一回事很多人在规划AI基础设施时习惯性地把“算力”等同于“GPU数量”这是一个非常危险的简化。训练和推理对硬件的要求差异巨大如果混在一起规划要么浪费钱要么跑不动。训练阶段的核心瓶颈通常在显存带宽和卡间互联带宽。一个大模型训练任务往往需要几十甚至上百张加速卡协同工作卡与卡之间的梯度同步频率极高。如果互联带宽不够加速卡就会大量时间花在等数据上利用率可能连30%都不到。这就是为什么训练集群里网络拓扑和互联方案如此关键——它直接决定了你花大价钱买的加速卡到底是在算还是在等。推理阶段的核心瓶颈则完全不同。推理通常是显存容量和能效比优先。一个在线服务可能同时加载多个模型每个模型都要占用显存而且推理是7×24小时持续运行的电费和散热成本会随时间线性累积。这时候一张功耗低、显存够用、推理延迟稳定的卡可能比一张峰值算力更高但功耗惊人的卡更划算。我参与过一个推荐系统的推理集群规划最初选型时有人提议直接用训练集群同款的高端卡理由是“统一采购方便”。实测下来发现推理场景下高端卡的利用率长期低于40%而功耗却是中端推理卡的三倍以上。后来换成推理优化型加速卡在保证延迟SLA的前提下整体拥有成本下降了将近一半。这个教训说明算力规划必须区分训练和推理两条线不能一刀切。2.2 集群规模扩大后网络才是真正的瓶颈单机八卡的时代很多人对网络的重要性没有感知。但当集群扩展到几百张卡、上千张卡的时候网络架构就成了决定训练效率的头号因素。这里有一个容易被忽略的细节梯度同步的通信模式是“全规约”All-Reduce也就是说每张卡都要和其他所有卡交换数据。如果网络拓扑设计不合理比如用了传统的树形以太网架构核心交换机的带宽会被瞬间打满训练任务就会卡在通信上。这也是为什么大规模训练集群普遍采用胖树Fat-Tree或者更激进的轨道优化拓扑——目的就是让任意两张卡之间的通信路径尽可能短、带宽尽可能大。一个实操中的经验在规划训练集群时先算清楚“最坏情况下的通信量”再倒推网络带宽需求。具体来说假设你有N张卡每张卡的梯度数据量是M字节一次全规约的通信量大约是2M(N-1)/N字节。如果训练一轮的时间预算里通信占比不能超过20%你就能算出每张卡需要的网络带宽下限。这个计算比拍脑袋选交换机靠谱得多。2.3 算力调度静态分配是最大的浪费试点阶段通常是一个人用几台机器静态分配没问题。但到了“AI工厂”阶段多个团队、多个项目共享一个算力池静态分配就会导致严重的资源碎片化——A团队的卡在跑任务时B团队闲着B团队要用的时候A团队的卡又空不出来。这时候就需要引入算力调度层。它的核心功能是把物理加速卡抽象成资源池按需分配给不同的训练或推理任务。好的调度系统能做到任务排队、优先级抢占、碎片整理、故障自动迁移。我见过一个团队在引入调度系统后同样的硬件规模下任务吞吐量提升了将近40%原因就是之前大量卡处于“被占用但实际空闲”的状态。不过调度系统也不是银弹。它引入的额外抽象层会带来一定的性能开销尤其是对延迟极度敏感的在线推理任务调度决策必须在毫秒级完成。所以常见的做法是训练任务走调度池推理任务走固定分配加弹性扩缩容两者用不同的策略管理。3. 数据管道AI工厂里最容易被低估的环节3.1 试点阶段的数据集和生产环境的数据流是两码事做试点的时候数据通常是“离线准备好的一份文件”。算法工程师拿到这份数据写个脚本加载进来训练就开始了。但生产环境里数据是持续流入的流而且这个流有几个让人头疼的特性。第一是格式漂移。上游业务系统升级了字段名改了或者某个字段的类型从整数变成了字符串你的数据管道如果没做兼容处理直接就会崩。第二是分布漂移。用户的兴趣在变、市场环境在变今天训练好的模型三个月后可能效果就明显下降了。第三是质量波动。试点时用的数据是经过人工清洗的生产环境里数据可能包含大量噪声、缺失值、异常值。所以“AI工厂”的数据管道必须具备几个能力schema校验、分布监控、自动清洗、版本回溯。schema校验保证数据格式符合预期不符合就告警而不是静默失败分布监控跟踪关键特征的统计量变化偏移超过阈值就触发重新训练自动清洗处理缺失值和异常值版本回溯让你能随时回到某个时间点的数据快照方便排查问题。3.2 特征存储别让每个团队重复造轮子我见过太多公司里每个算法团队都在自己写特征处理代码。推荐团队写一套用户特征风控团队又写一套搜索团队再写一套。同样的“用户最近7天活跃天数”这个特征三个团队三种实现口径还不一致。这不仅浪费人力更严重的是导致模型之间的特征不可复用A模型验证有效的特征B模型想用还得重新实现一遍。特征存储Feature Store就是为解决这个问题而生的。它的核心思想是把特征的定义、计算逻辑、存储、服务统一管理起来。离线训练时从特征存储批量读取在线推理时从特征存储实时读取保证训练和推理的特征口径完全一致。这个“训练-推理一致性”是很多模型上线后效果暴跌的根因——训练时用的特征计算逻辑和线上服务时不一样模型看到的输入分布变了效果自然崩。搭建特征存储的投入不小但一旦建成新模型的上线周期可以从几个月缩短到几周。我的建议是如果公司有超过三个算法团队且模型需要频繁更新特征存储的优先级应该排在算力扩容之前。3.3 数据版本管理出了问题能回滚才是硬道理模型可以回滚数据能不能回滚这个问题在试点阶段几乎没人关心但在生产环境里至关重要。假设某天模型效果突然下降你怀疑是数据出了问题但数据是持续流入的你怎么知道“现在这份数据”和“上周那份数据”有什么区别数据版本管理要解决的就是这个问题。它的做法是给每个时间窗口的数据打上版本标签记录数据的来源、处理逻辑、统计摘要。当出现问题时可以快速对比不同版本的数据分布定位是哪一批数据引入了异常。更进一步如果确认是数据问题可以回滚到之前的版本重新训练模型。实操建议数据版本管理不需要一开始就做得很重。可以从最简单的开始——每天的数据快照保留一份元数据行数、关键字段的均值方差、缺失率存到一个轻量级的数据库里。这个成本很低但出问题时能救命。4. 从训练到推理的“最后一公里”部署与运维的坑4.1 模型格式转换一个看似简单却频繁翻车的环节训练框架和推理框架往往不是同一套。训练可能用PyTorch推理可能用TensorRT或者ONNX Runtime。这中间就涉及模型格式转换。这个环节看起来只是跑一个转换脚本的事但实际操作中翻车率极高。常见的问题包括某些算子不支持、精度在转换后下降、动态shape处理不一致、转换后的模型性能反而不如预期。我印象最深的一次是一个视觉模型在转换后推理速度只提升了10%远低于预期的3倍。排查了很久才发现转换工具默认把某个关键层做了低精度量化导致计算量虽然小了但引入了额外的反量化开销整体反而没快多少。后来手动指定了混合精度策略才达到预期效果。所以模型转换不能当成一个黑盒操作必须验证转换前后的数值一致性并且在目标硬件上做端到端的性能基准测试。不要只看转换工具输出的“成功”字样就以为万事大吉。4.2 推理服务的弹性扩缩容省钱的關鍵推理服务的流量通常有明显的波峰波谷。白天请求量大深夜请求量小。如果按峰值配置资源深夜就会大量浪费如果按均值配置白天高峰期就会超时。弹性扩缩容要解决的就是这个问题。它的核心是根据实时流量指标QPS、延迟、队列长度动态调整推理实例的数量。听起来简单但实操中有几个坑扩容太慢导致高峰期已经过去了新实例才起来缩容太快导致流量突然回升时服务不可用指标选择不当导致扩缩容震荡。我的经验是扩容要激进缩容要保守。扩容阈值设低一点宁可多开几个实例也不要让请求排队缩容阈值设高一点并且加一个冷却时间窗口避免刚缩完又得扩。另外预热很重要——新启动的推理实例需要加载模型、初始化运行时这段时间内它的处理能力是不足的不应该立刻接收全量流量。4.3 模型监控上线只是开始模型上线不是终点而是起点。生产环境里的模型会面临各种试点阶段遇不到的问题输入数据异常、模型预测偏移、依赖服务故障、硬件性能退化。没有监控这些问题你根本不知道。模型监控至少要覆盖三个层面系统层GPU利用率、显存占用、推理延迟、错误率、数据层输入特征的分布、缺失率、异常值比例、模型层预测结果的分布、置信度分布、业务指标变化。这三个层面缺一不可。只看系统层你不知道模型是不是在“胡说八道”只看模型层你不知道是不是硬件出了问题导致延迟飙升。一个实用的技巧给模型监控设置“影子模式”。新模型上线时让它和旧模型并行运行但只记录新模型的预测结果而不实际生效。对比两者的预测差异如果差异在可接受范围内再逐步切流量。这个做法能极大降低新模型上线的风险。5. 成本控制AI工厂能不能持续运转的命门5.1 算力成本只是冰山一角很多人算AI项目的成本时只算了加速卡的采购费用。但实际运营下来电费、散热、机架空间、网络带宽、运维人力加起来往往比硬件采购费用还高。尤其是大规模推理集群7×24小时运行电费是持续流出的现金。我做过一个粗略的测算一个中等规模的推理集群如果加速卡利用率只有30%那么每有效算力单位的成本是满负荷运行时的三倍以上。换句话说提高利用率就是最直接的成本优化手段。而提高利用率的关键在于合理的调度策略、准确的容量规划、以及持续的利用率监控。5.2 训练任务的成本优化 checkpoint策略很关键训练大模型时checkpoint检查点的保存频率直接影响存储成本和训练效率。保存太频繁存储写入成为瓶颈而且占用大量存储空间保存太少一旦训练中断回滚的代价很大。我的经验是根据训练任务的稳定性和单次epoch的时间来决定checkpoint间隔。如果训练任务很稳定很少中断可以每几个epoch保存一次如果训练环境不太稳定比如共享集群可能需要更频繁。另外checkpoint可以分层保存——最近的几个保留完整状态更早的只保留模型权重丢弃优化器状态这样能省不少存储。5.3 推理成本优化批处理与量化的取舍推理成本优化的两个主要手段是批处理和量化。批处理是把多个请求合并成一个批次一起推理提高硬件利用率量化是降低模型权重的数值精度减少计算量和显存占用。但这两个手段都有代价。批处理会增加单个请求的延迟——你得等够一批才能开始推理。对于延迟敏感的场景比如实时交互批处理的大小必须严格控制。量化则可能影响模型精度尤其是对数值敏感的模型量化后效果可能明显下降。所以成本优化不是无脑开大batch或者无脑量化而是要根据业务对延迟和精度的容忍度来权衡。我的做法是先建立基线不批处理、不量化的延迟和精度然后逐步调整参数观察延迟和精度的变化曲线找到性价比最高的那个点。6. 组织与流程技术之外的决定性因素6.1 试点团队和生产团队的鸿沟很多公司里做AI试点的是算法团队负责生产运维的是基础设施团队。这两个团队的目标、技能、工作方式都不一样。算法团队关心模型效果基础设施团队关心稳定性和成本。试点做完要上线时经常出现“算法团队觉得基础设施团队不支持基础设施团队觉得算法团队不懂运维”的局面。解决这个问题的关键是尽早让基础设施团队介入。不要等模型训练完了才去找运维而是在项目立项时就拉上运维一起评估这个模型上线后需要多少资源推理延迟要求是多少数据管道怎么对接监控怎么做这些问题在早期解决的成本远低于上线前才发现。6.2 建立AI平台的“产品思维”“AI工厂”要持续运转不能靠项目制——每个项目都从头搭一遍基础设施。正确的做法是把AI能力平台化当成一个内部产品来运营。平台团队负责提供算力调度、数据管道、特征存储、模型部署、监控告警等通用能力业务团队在这些能力之上做自己的模型和业务逻辑。这个转变对组织能力的要求很高。平台团队需要理解业务需求业务团队需要适应平台的使用方式。但一旦跑通新业务的上线速度会大幅提升因为不需要重复建设基础设施了。6.3 度量与迭代AI工厂也需要KPI最后一点AI工厂的运营需要可度量的指标。没有度量就没有改进。我建议关注几个核心指标算力利用率实际用于计算的时间占比、模型上线周期从代码提交到生产部署的时间、推理服务可用性SLA达成率、单位推理成本每千次请求的成本、模型效果衰减速度上线后效果下降的速率。这些指标不需要一开始就全部追踪可以从一两个开始逐步完善。关键是形成“度量-发现问题-优化-再度量”的闭环。我见过一个团队只追踪了算力利用率这一个指标就发现了大量资源浪费优化后节省了可观的成本。从试点到AI工厂本质上是从“项目思维”转向“产品思维”和“运营思维”。技术选型和架构设计很重要但组织流程和持续运营的能力才是决定AI工厂能不能真正跑起来的关键。我在实际操作中的体会是先把一个场景做深做透跑通从数据到训练到推理到监控的完整链路再考虑横向扩展。贪多求快、同时铺开多个场景往往每个都做不深最后又退回到“试点”状态。