一年云原生 AI 实战那些书里不会写的关键决策基础设施不需要漂亮话。2024 年我全程参与了一个云原生 AI 平台的从零搭建到生产运行。这一年做了很多技术决策有些做对了有些做错了。这篇文章记录的是那些技术书和最佳实践里不会写的关键决策——不是应该怎么做是我们实际怎么做和为什么这么做。一、技术选型在理想和现实之间妥协决策 1K8s 还是 Nomad项目启动时的第一个决策容器编排平台选什么理想方案Kubernetes业界标准生态完善。现实约束团队里只有 2 个人用过 K8s其余都是听说过的水平项目周期 3 个月没时间让大家系统学 K8s平台需要管理的主要是 AI 训练任务批处理不是微服务最终决策Kubernetes但用最简化的方式。我们没有用 K8s 的所有功能只用了 20% 的功能Deployment、Service、ConfigMap、PVC其余 80% 的功能CRD、Operator、Service Mesh...暂时不用。学习策略边做边学遇到问题再查文档不追求系统性掌握。结果3 个月后平台上线K8s 相关故障 2 次都是配置错误团队基本掌握了 K8s 的核心用法。如果重来我会先做 K8s 的基础培训1 周再动手搭建。实践中学习效率高但踩的坑也多有些坑是可以提前避免的。决策 2TensorFlow 还是 PyTorchAI 框架选什么算法团队希望用 PyTorch灵活、易调试但公司之前的项目都是 TensorFlow有积累、有经验。决策过程我们做了一个技术评估矩阵维度TensorFlowPyTorch权重团队经验8 分5 人熟悉3 分1 人熟悉30%生态完善度8 分9 分20%生产部署便利性9 分TF Serving 成熟6 分需要 TorchServe 或转 ONNX25%灵活性/易用性5 分9 分25%加权平均TF 7.55 分PyTorch 6.5 分。最终决策新项目用 PyTorch老项目继续用 TensorFlow。原因算法团队的反馈是PyTorch 的开发效率高 30%长期来看这 30% 的效率提升能抵消学习成本。结果6 个月后团队所有人都能熟练用 PyTorch模型开发周期从平均 2 周降到 1 周。这个决策做对了。二、架构设计在完美和可用之间取舍决策 3微服务还是模块化单体平台的功能模块有模型管理、训练任务调度、推理服务管理、监控告警、用户管理。理想方案微服务架构每个模块独立部署、独立扩展。现实约束团队规模小8 个人维护 5 个微服务成本高模块之间的调用关系复杂微服务化后分布式追踪和调试会变难项目周期紧微服务化会拖慢进度最终决策模块化单体 预留微服务化接口。具体做法// 用 Go 的 internal 包实现模块隔离 project/ ├── cmd/ │ └── server/ │ └── main.go ├── internal/ │ ├── modelmanager/ │ ├── trainscheduler/ │ ├── inferenceservice/ │ ├── monitoring/ │ └── usermanager/ ├── pkg/ # 可被外部引用的公共包 └── api/ # gRPC/HTTP API 定义每个模块在internal下是独立的包模块间通过接口通信不是直接函数调用为未来微服务化预留了空间。结果3 个月上线 MVP6 个月后用户量增长把推理服务模块拆成了独立微服务。如果一开始就是微服务可能现在还在处理分布式事务问题。决策 4自研训练调度器还是用 K8s 原生调度训练任务的调度是个核心功能。K8s 原生支持批处理任务Job、CronJob但我们还需要优先级调度紧急任务优先资源配额管理不同团队有不同的 GPU 配额检查点机制Spot 实例被回收后能从检查点恢复方案对比方案优点缺点K8s 原生调度简单无需额外开发功能不够自研调度器功能完全定制开发成本高维护成本高K8s 自定义调度器功能可扩展社区有参考需要学习 K8s 调度器开发最终决策K8s 自定义调度器基于 kube-batch。原因完全自研性价比低K8s 原生功能不够折中方案是用开源的批处理调度器kube-batch做二次开发。踩坑记录kube-batch 的文档很少遇到问题只能看代码。有一次调度器 OOM我们排查了 2 天才找到原因kube-batch 的默认配置不支持我们这种规模的集群80 节点需要调大资源限制。如果重来我会直接用 K8s 的 Coscheduling 特性1.18 版本支持不引入额外的调度器。功能少一点但稳定性高。三、运维策略在自动化和成本之间平衡决策 5监控方案选什么监控是必须的但监控方案有很多选择Prometheus Grafana开源、Datadog商业、阿里云 ARMS托管。成本对比方案部署成本运维成本/年license 成本/年Prometheus低10 万人力0Datadog低2 万人力60 万200 个节点ARMS低5 万人力30 万最终决策Prometheus Grafana但只监控核心指标。我们没有监控所有指标那样成本太高只监控基础设施指标CPU、内存、磁盘、网络K8s 指标Pod 状态、调度延迟业务指标训练任务成功率、推理延迟、GPU 利用率非核心指标比如每个容器的详细网络流量不监控需要的时候临时查。结果监控成本 10 万/年1 个运维工程师 part-time 维护覆盖了 95% 的故障场景。决策 6日志方案选什么日志方案和监控类似也有很多选择。我们最终选了Loki Grafana。原因Loki 的存储成本低只索引元数据不索引日志内容和 Grafana 集成好监控和日志在同一个界面查询语法简单LogQL 比 Elasticsearch 的查询简单踩坑记录Loki 的查询性能不如 Elasticsearch特别是全文本搜索场景。我们有一个需求是搜索包含某个错误关键词的所有日志用 Loki 需要扫描所有日志很慢。解决方案错误日志单独用 Elasticsearch 存储普通日志用 Loki。混合方案各取所长。四、团队协作在技术和管理之间找平衡决策 7代码审查要做到什么程度团队对代码审查的标准有分歧。有人觉得应该严格每行代码都要 review有人觉得应该宽松只 review 核心模块。最终决策分层审查策略。核心模块的定义涉及数据安全的代码涉及资金交易的代码被 10 个地方调用的公共函数这个策略平衡了代码质量和开发效率。核心模块严格审查非核心模块快速迭代。决策 8技术债务什么时候还项目前期为了赶进度写了一些能跑但不够优雅的代码。什么时候重构这些代码错误做法专门排期重构因为业务需求永远做不完重构排期永远排不上。正确做法把重构融入日常开发。我们的规则改某个模块之前先重构这个模块让代码处于比以前更好的状态修复 bug 时顺便重构相关的代码每个月预留 1 天做技术债务清理这个策略的聪明之处在于重构的成本分摊到日常开发中不会和业务需求冲突。五、那些书里不会写的决策这一年的实战我学到的最重要的一课是技术决策不是选择题A 对 B 错是权衡题A 和 B 各有优劣选更适合当前场景的。书里会告诉你微服务是趋势应该用微服务但不会告诉你如果你的团队只有 5 个人微服务可能是噩梦。书里会告诉你Kubernetes 是标准应该用 K8s但不会告诉你K8s 的学习曲线很陡如果项目周期只有 3 个月可能来不及。书里会告诉你监控很重要应该监控所有指标但不会告诉你监控所有指标的成本可能比你节省的钱还多。所以关键决策的能力不是知道正确答案是知道在当前约束下哪个方案更合适。约束包括团队的技术能力项目的周期要求公司的预算限制业务的风险容忍度这些约束书里不会写因为只有你自己知道。六、总结这一年做了很多决策有对的也有错的。但回头看最重要的不是哪个决策做对了而是建立了一套做决策的方法论。这套方法论包括先算 ROI不要为了技术而技术要算投入产出比。小步快跑不要追求一步到位先做一个能用的版本再迭代优化。预留退路每个关键决策都要想好如果做错了怎么办预留回滚或迁移的方案。持续复盘定期回顾决策结果做对的总结经验做错的吸取教训。最后说一句云原生 AI 平台不是靠正确的技术选型成功的是靠持续的迭代优化成功的。技术选型只是起点真正的挑战在后面的运维、优化、迭代。基础设施不需要漂亮话。能解决实际问题、能持续交付价值的决策就是好决策。
