AI 平台建设的20个决策时刻：选错了就要花几个月还债

AI 平台建设的20个决策时刻选错了就要花几个月还债基础设施不需要漂亮话。AI 平台建设不是技术选型的堆砌而是一系列决策的组合。每个决策看起来都是局部选择——用什么推理框架、用什么调度器、用什么存储方案——但这些局部决策的组合决定了平台的整体架构走向。选错了不是换个组件就行而是整个架构的假设基础变了需要重新设计。我们团队做过三次 AI 平台建设每次都有决策错误导致的返工。这篇文章把 20 个关键决策时刻列出来每个都附带错误选项的代价和正确选项的权衡。一、背景决策错误的代价为什么这么高AI 平台的组件之间有强耦合关系推理框架决定了模型格式和部署方式调度器决定了资源分配策略存储方案决定了数据流转路径。一旦在底层决策上选错了方向上层组件的设计假设就全部失效。比如选了静态调度器后来发现需要动态 Batching就得把推理框架换成支持动态调度的版本同时把调度策略从静态改为动态连带修改监控指标和告警规则——一个决策错误导致三个组件重写。二、基础设施层5个决策时刻决策1自研推理框架还是用开源vLLM/Triton错误选项自研推理框架。代价至少需要 3 个全职工程师维护推理框架本身半年内无法交付平台功能。推理框架的优化内存管理、调度策略、CUDA kernel 融合需要深度 GPU 编程经验这不是大多数后端团队能覆盖的。正确权衡小团队5 个推理工程师用开源框架vLLM 或 Triton只做集成和运维。大团队5 个推理工程师可以考虑自研但前提是已有至少 6 个月的框架踩坑经验清楚开源框架的哪些限制需要突破。自研之前先用开源跑三个月收集真实瓶颈数据再决定是否自研。决策2单集群还是多集群错误选项上线第一天就搞多集群。代价多集群的网络、认证、数据同步在初期没有流量压力的时候看不出问题但运维复杂度翻倍。而且多集群的调度器配置GPU 分配、亲和性规则、HPA 参数要分别维护一致性很难保证。正确权衡初期用单集群流量规模超过单集群承载能力通常 500 GPU 或 3 个可用区再拆多集群。拆分时机看三个指标GPU 利用率峰值 80%、跨可用区延迟 5ms、运维变更频率 2 次/天。拆分后的多集群管理方案用 Karmada 或自研联邦调度器。决策3GPU 独占还是共享错误选项GPU 独占分配——每个推理服务占整张 GPU。代价小模型4B 参数的推理只需要 2~4GB 显存独占一张 24GB GPU 是浪费。资源利用率低导致成本高GPU 采购预算持续超支。正确权衡小模型用共享方案MPS 或时间片大模型13B 参数用独占。共享方案上线前必须压测验证——推理延迟是否稳定、显存隔离是否有效、共享 Pod 之间是否互相干扰。不要一上来就共享——先独占跑三个月收集利用率数据再决定哪些模型可以共享。决策4模型存储用对象存储还是块存储错误选项模型文件存块存储PVC。代价块存储的容量有限通常 1TB多个大模型同时存储时空间不够。块存储挂载到 Pod 的 IO 延迟高网络存储模型加载时间长。而且块存储的快照和版本管理不如对象存储方便。正确权衡模型文件存对象存储S3/OSS推理 Pod 启动时从对象存储下载模型到本地 SSD 缓存。首次加载从对象存储拉取30s120s后续加载从本地缓存5s10s。缓存策略Pod 重启用本地缓存模型版本更新时清除缓存重新拉取。决策5自建机房还是云托管错误选项自建机房。代价GPU 服务器采购周期 3~6 个月机房网络和电力配置需要专业团队初期投入巨大。而且 GPU 型号更新快每 18 个月新一代自建机房的硬件老化速度比云快。正确权衡初期用云托管 GPUAWS/AWS/GCP按需付费降低初期风险。流量稳定后日均 QPS 10k 且延迟 SLO 稳定再评估自建机房的成本优势。自建机房的前提GPU 利用率 70%云上利用率低的时候自建更亏、运维团队 5 人、硬件采购渠道稳定。三、推理服务层5个决策时刻决策6动态 Batching 还是固定批次错误选项固定批次。代价低流量时批次填不满GPU 利用率低高流量时批次溢出请求排队延迟飙升。固定批次无法适应流量的自然波动。正确权衡默认用动态 BatchingvLLM 的 continuous batching 或 Triton 的 dynamic batching。设定最大批次大小防止延迟飙升和最大等待时间防止低流量时请求等太久。动态 Batching 的调优参数max_batch_size、max_wait_time需要在生产流量下实测——压测数据不代表真实流量模式。决策7单模型端点还是多模型端点错误选项所有模型共用一个端点路由在端点内部做。代价端点内部的路由逻辑复杂不同模型的延迟、并发限制、排队策略不同一个模型的流量波动影响所有模型的延迟。路由层和推理层耦合在一起修改任何一个模型的策略都需要改端点代码。正确权衡每个模型或模型组独立端点API 网关做外部路由。独立端点的优势故障隔离、独立扩缩容、独立 SLO。代价是多端点的运维成本更多 Pod、更多监控面板但这个成本远低于共用端点的路由复杂度。决策8推理 API 用 HTTP 还是 gRPC错误选项只用 HTTP。代价流式推理如 LLM 的 token 逐个返回用 HTTP SSE 实现不稳定——客户端断连后重连机制复杂、服务端的半开连接处理不统一。多模型调用链如 Agent 的多步骤推理用 HTTP 的延迟叠加效应明显——每个 HTTP 请求的连接建立和 TLS 握手都增加延迟。正确权衡外部 API 用 HTTP兼容性好、调试方便内部服务间调用用 gRPC流式支持好、连接复用延迟低。网关层做 HTTP/gRPC 协议转换。流式推理的 gRPC 实现Server-Sent Events 模式要处理客户端断连和半开连接——这不是框架自动处理的需要代码层面实现。决策9模型格式标准化还是各模型各格式错误选项各模型各格式——HuggingFace SafeTensors、ONNX、PyTorch、TensorFlow 各自保存。代价推理框架需要适配多种格式加载逻辑不一致版本管理混乱。模型格式转换如 PyTorch → ONNX可能引入精度损失每次转换都要验证。正确权衡内部统一一种格式推荐 SafeTensors 或 ONNX。新模型接入平台时先做格式转换和精度验证确认无损后再上线。格式标准化的代价是转换工作量但换来的是推理框架的统一加载逻辑、版本管理的一致性、模型仓库的结构化。决策10排队在推理层还是调度层错误选项排队在推理层每个推理 Pod 自己管理请求队列。代价排队状态分散在各个 Pod 里无法全局优化——某个 Pod 的队列可能很长而相邻 Pod 的队列是空的。调度层看不到排队状态无法做智能路由。正确权衡排队在调度层网关或专用排队服务。调度层掌握所有 Pod 的负载状态可以把请求路由到最空闲的 Pod。推理 Pod 不做排队——收到请求立刻推理满了就返回拒绝让调度层重试。代价是调度层需要维护所有 Pod 的实时负载状态心跳或指标推送状态更新延迟不能超过 1s。四、数据与训练层5个决策时刻决策11特征平台自研还是用开源Feast错误选项自研特征平台。代价特征平台的工程量比想象大——在线特征的低延迟读取、离线特征的数据管道、特征版本管理和一致性保证、特征注册和发现。自研这些需要至少 2 个全职工程师半年时间产出可能还不如 Feast。正确权衡初期用 Feast 或类似开源方案只做集成和定制。Feast 不够的地方用扩展插件而不是重写。团队规模 20 人时不要自研特征平台——ROI 不够。当 Feast 的性能或功能瓶颈确实影响业务时再考虑局部替换。决策12训练和推理同集群还是分集群错误选项训练和推理放在同一个 GPU 集群。代价训练任务长时间占用 GPU几小时到几天推理服务需要的 GPU 空间被挤压。训练任务的调度策略抢占式、弹性扩缩和推理服务的调度策略稳定、低延迟天然矛盾。混合部署的调度器配置极其复杂——需要同时处理两种完全不同的工作负载。正确权衡训练和推理分集群。推理集群保持稳定配置GPU 独占或受控共享、固定 HPA 参数训练集群用弹性调度抢占式、按需扩缩。两个集群共享对象存储模型文件和数据集但各自独立调度和管理。分集群的代价是 GPU 资源利用率在空闲期更低但换来的是推理服务的稳定性和运维的简洁性。决策13数据管道用消息队列还是批处理错误选项所有数据管道用消息队列Kafka。代价批处理场景如每日模型评测、历史数据回填用消息队列的效率低——消息队列是逐条处理批处理需要批量加载和并行计算。消息队列的运维成本也不低Kafka 集群的 broker 管理、topic 配置、消费延迟监控。正确权衡实时场景用消息队列推理日志采集、特征实时更新批处理场景用批处理框架Spark/Airflow。不要用一套方案覆盖所有数据流——实时管道和批处理管道的设计假设完全不同。两者共享数据存储层但处理逻辑各自独立。决策14向量数据库选型错误选项选最热门的向量数据库如 Pinecone、Weaviate。代价热门方案不一定适合你的场景——Pinecone 是 SaaS 方案数据不能本地存储Weaviate 的内存消耗大大规模数据集成本高。选型时不看性能基准测试只看社区活跃度。正确权衡选型标准按优先级排列数据规模百万级 vs 亿级、查询延迟要求10ms vs 100ms、运维复杂度自建 vs SaaS、成本模型按存储 vs 按查询。小规模数据百万向量用 pgvector复用 PostgreSQL 运维经验大规模数据百万向量用 Milvus 或 Qdrant分布式、高性能。SaaS 方案只适合小团队快速验证——数据安全和成本不可控是长期风险。决策15评测集管理流程错误选项评测集散落在各模型团队的本地机器里。代价评测集没有版本管理模型更新后评测结果无法对比。不同团队的评测集口径不一致同一模型的准确率在不同团队报告里差 5%~10%。评测集更新时没有通知机制模型团队不知道评测标准变了。正确权衡评测集集中管理——用 Git 仓库或专用平台存储评测集版本和变更记录可追溯。评测集的更新走 PR 流程变更需要模型团队 review。每次模型更新自动触发评测流水线结果和基准对比后输出报告。评测集覆盖度定期检查——新增业务场景要及时补充评测样本。五、平台治理层5个决策时刻决策16API 网关自研还是用开源Kong/APISIX错误选项自研 API 网关。代价网关需要认证、限流、日志、路由、协议转换——每个功能都需要单独实现和测试。自研网关的稳定性和性能很难在短期内达到开源方案的水平。而且网关是所有请求的入口出问题影响全局——自研的风险极高。正确权衡用 Kong 或 APISIX 做网关只做插件定制。推理场景特有的插件如 Token 计数、模型路由、排队策略用网关的插件机制实现不要重写网关本身。自研的前提条件网关的定制需求超过插件机制的能力比如需要自定义调度逻辑嵌入网关且团队有 2 个专职网关工程师。决策17模型版本管理走 Git 还是专用平台错误选项模型版本管理走 Git。代价大模型文件10GB不适合 Git 管理——Git 的对象存储机制对大文件效率低clone 和 push 时间过长。Git LFS 可以解决存储问题但增加了运维复杂度LFS 服务器单独部署。模型版本和代码版本耦合在一起模型团队的变更需要走代码团队的 PR 流程。正确权衡模型文件用专用模型仓库MLflow、DVC 或自建对象存储 元数据库代码和配置走 Git。模型仓库存储模型文件和元信息训练参数、评测结果、关联数据集版本Git 存储推理代码和部署配置。两者通过元信息中的 commit hash 关联不直接耦合。决策18监控用 Prometheus 还是商业方案错误选项直接用商业方案Datadog/Grafana Cloud。代价商业方案的计费模型按指标数量或主机数量——AI 平台的指标量是传统服务的 5~10 倍GPU 指标、推理指标、Token 指标、模型质量指标成本快速飙升。而且商业方案的指标查询延迟在自定义指标多的时候会上升。正确权衡核心基础设施指标CPU、内存、磁盘、网络和 Kubernetes 指标用 Prometheus 自建模型质量指标和业务指标用商业方案或自建可视化平台。Prometheus 的运维成本在初期低于商业方案——AI 平台起步期指标量大但预算少自建 Prometheus 更划算。规模超过 10k 指标/秒后考虑 Thanos 或 Cortex 做联邦查询。决策19IAM 统一还是各服务自管错误选项各服务各自管理认证和授权。代价每个服务独立实现认证逻辑JWT 验证、RBAC 校验代码重复、策略不一致、用户管理分散。新服务接入平台时认证集成工作量重复。用户权限变更需要逐个服务更新。正确权衡IAM 统一管理——平台级 IAM 服务基于 OIDC RBAC所有服务统一对接。推理服务的认证在网关层完成内部服务间用 mTLS。IAM 统一的代价是初期实现成本高但换来的是认证策略的一致性和新服务接入的低成本。不要在初期就做细粒度的 RBAC——先用粗粒度服务级别访问控制业务稳定后再细化到模型级别和用户级别。决策20成本核算按模型还是按团队错误选项成本核算按团队。代价团队成本和模型成本不对应——一个团队可能运行 3 个模型另一个模型可能被 3 个团队共享。按团队核算看不到哪个模型烧钱最多优化方向不明确。GPU 成本是大头占总成本 60%~80%GPU 消耗按模型而非按团队分配。正确权衡成本核算双维度——按模型和按团队。按模型维度看 GPU 利用率、推理吞吐、Token 消耗定位资源浪费点。按团队维度看预算执行率、成本趋势做预算管理。两个维度的数据在成本仪表盘上都要展示交叉分析才能发现真正的优化机会如某个模型被多个团队共享合并调用可以减少 GPU 占用。六、总结决策的核心规律AI 平台建设的 20 个决策时刻有一个共同规律初期决策的容错率比后期高但初期决策的影响范围比后期大。决策顺序应该是先做影响范围大但可逆的决策存储方案、监控方案后做影响范围大且不可逆的决策推理框架、调度架构。每个不可逆决策前必须有三个月的踩坑数据——不要在第一天就拍板自研推理框架或拆多集群。一句话AI 平台的决策不是选最优方案而是选最可逆方案——可逆的决策错了能改不可逆的决策错了要还债几个月。