AI 工程化的灵魂拷问你的平台真的在解决问题吗一、一个问题就够了这一年看了不少号称AI 平台的项目。它们的共同特征大致如下一个漂亮的 Web Console、支持一键部署多种模型、GPU 资源使用率面板做得像商业产品、甚至集成了模型市场。每次这样的演示结束之后我只有一个问题你的平台上线之后业务侧的推理失败率从多少降到了多少这个问题往往让演示者陷入短暂的沉默。不是这个问题难回答而是大多数 AI 平台的出发点就不是解决这个问题。它们的出发点可能是我们要做一个功能齐全的 AI 平台而不是我们要解决推理服务的不稳定问题。二、平台建设的三种动机技术驱动为技术而技术这种动机的典型表现是团队刚拿到几台 GPU 服务器Kubernetes 搭好了Jupyter Notebook 跑通了觉得是时候做一个平台了。他们花两个 sprint 搭一个 Web Console支持模型上传和部署再做一个 GPU 监控面板自认为平台已经完成了。但业务方真正需要的是什么模型推理的请求不是人工通过 Web Console 提交的而是业务代码通过 API 调用的。一个不能暴露标准 OpenAI 兼容 API 的平台对业务方来说根本不是平台——是一个需要额外适配的负担。更常见的一个现象是业务方默默地继续用公有云 API因为你的平台虽然有了但稳定性还不如公有云。平台做出来了但核心问题——推理延迟和可用性——没有被解决。功能驱动功能越多离问题越远功能驱动的平台PRD 里的 Feature List 可以写满两页 A4 纸模型管理、版本控制、一键部署、模型市场、AB 测试、推理评测、成本分析、用户管理、RBAC 权限……功能驱动的背后是别人有的我们也要有的心态。这种心态的代价是团队把大量精力花在了边缘功能上——比如开发一个月没人用两次的模型市场——而真正的核心矛盾——GPU 资源调度不合理导致的推理排队超时——迟迟没有被解决。这类平台最典型的特征需求会上讨论的是我们能不能支持 Qwen 的新版本而不是上个月 P99 延迟恶化了 23%原因是什么。讨论功能远比讨论故障容易。但解决的问题远比功能数量重要。问题驱动从故障反推平台问题驱动的平台建设思路完全不同。它的出发点不是我们要做什么而是我们遇到了什么问题。第一步把问题量化。推理延迟不可控具体是多少P50、P99、P99.9 分别是什么哪个时间段最差哪个业务线的请求最慢第二步把问题归因。延迟高是因为 GPU 推理慢还是因为排队时间长排队时间长是因为总并发太高还是因为某些请求占片时间太长第三步对症下药。排队时间长 → 引入推理队列优先级。推理慢是因为请求 token 过长 → 引入 token 预算管理和显存感知路由。GPU 不够用 → 引入弹性伸缩基于队列深度自动扩容。每一步都不是因为这样做看起来很厉害而是因为这样做能解决眼前这个让它睡不着觉的问题。三、从指标反推平台价值评价一个 AI 平台的唯一标准不是功能列表有多长而是核心指标有没有改善。以下是我们的平台在上线前后三个月的指标变化指标平台上线前平台上线后变化推理请求 P99 延迟2,340ms847ms-64%推理服务可用率98.1%含外部 API 故障99.72%1.62pp故障平均发现时间MTTD47 分钟靠业务方反馈2 分钟Prometheus 告警-96%月 GPU 推理成本¥31,000外购 API¥47,230自建52%每百万 token 推理成本¥23.5外购¥11.8自建长文本-50%两个关键观察第一故障发现时间从 47 分钟降到 2 分钟这是观测体系的价值第二月度总成本虽然涨了但单位 token 成本降了一半——这意味着成本增长是由业务量增长驱动的而不是效率低下。四、什么时候不该做平台问题驱动的前提是确实有问题需要被解决。如果你的团队模型调用频率很低日均低于 5,000 次公有云 API 的延迟在可接受范围内P99 3,000ms且你没能力投入持续的 GPU 运维——那就不要做平台。做平台的代价不只是代码和 GPU 采购。真正的代价是每多一套基础设施就多了一个事故源。GPU 节点宕机、推理框架版本不兼容、K8s 调度策略出错——这些都是你不再能推给供应商的问题。不当的决策在没有明确痛点的前提下为了未来可能需要而搭建平台。过度建设的平台和没有平台是一样的——都解决不了眼前的问题。五、总结文章标题是一个赤裸裸的问题但答案其实也赤裸裸如果你的平台上线后业务侧的推理失败率和延迟没有可量化的改善那它就没有真正在解决问题。它就只是一个被完成了的工程任务而不是一个被解决了的工程问题。AI 工程化的核心不是把 AI 做成平台而是把 AI 做成可靠的基础设施。可靠意味着什么意味着业务方调用你的推理 API 时不需要考虑任何关于 GPU、模型、延迟的事——他们只需发请求然后得到结果。能做到这一点你才算解决了真问题。做不到的话回去看看你是哪种动机驱动在做平台。基础设施不需要漂亮话。它需要的是一组核心指标和一群盯着这些指标不放的人。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0731 资料来源索引并在发布前将具体来源贴到对应断言之后。