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 或自研联邦调度器。

决策3：GPU 独占还是共享

错误选项：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 个月新一代），自建机房的硬件老化速度比云快。

正确权衡：初期用云托管 GPU（AWS/AWS/GCP），按需付费降低初期风险。流量稳定后（日均 QPS >10k 且延迟 SLO 稳定）再评估自建机房的成本优势。自建机房的前提：GPU 利用率 >70%（云上利用率低的时候自建更亏）、运维团队 >5 人、硬件采购渠道稳定。

三、推理服务层：5个决策时刻

决策6：动态 Batching 还是固定批次

错误选项：固定批次。代价：低流量时批次填不满，GPU 利用率低；高流量时批次溢出，请求排队延迟飙升。固定批次无法适应流量的自然波动。

正确权衡：默认用动态 Batching（vLLM 的 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个决策时刻

决策16：API 网关自研还是用开源（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 做联邦查询。

决策19：IAM 统一还是各服务自管

错误选项：各服务各自管理认证和授权。代价：每个服务独立实现认证逻辑（JWT 验证、RBAC 校验），代码重复、策略不一致、用户管理分散。新服务接入平台时认证集成工作量重复。用户权限变更需要逐个服务更新。

正确权衡：IAM 统一管理——平台级 IAM 服务（基于 OIDC + RBAC），所有服务统一对接。推理服务的认证在网关层完成，内部服务间用 mTLS。IAM 统一的代价是初期实现成本高，但换来的是认证策略的一致性和新服务接入的低成本。不要在初期就做细粒度的 RBAC——先用粗粒度（服务级别访问控制），业务稳定后再细化到模型级别和用户级别。

决策20：成本核算按模型还是按团队

错误选项：成本核算按团队。代价：团队成本和模型成本不对应——一个团队可能运行 3 个模型，另一个模型可能被 3 个团队共享。按团队核算看不到哪个模型烧钱最多，优化方向不明确。GPU 成本是大头（占总成本 60%~80%），GPU 消耗按模型而非按团队分配。

正确权衡：成本核算双维度——按模型和按团队。按模型维度看 GPU 利用率、推理吞吐、Token 消耗，定位资源浪费点。按团队维度看预算执行率、成本趋势，做预算管理。两个维度的数据在成本仪表盘上都要展示，交叉分析才能发现真正的优化机会（如某个模型被多个团队共享，合并调用可以减少 GPU 占用）。

六、总结：决策的核心规律

AI 平台建设的 20 个决策时刻有一个共同规律：初期决策的容错率比后期高，但初期决策的影响范围比后期大。决策顺序应该是：先做影响范围大但可逆的决策（存储方案、监控方案），后做影响范围大且不可逆的决策（推理框架、调度架构）。每个不可逆决策前必须有三个月的踩坑数据——不要在第一天就拍板自研推理框架或拆多集群。一句话：AI 平台的决策不是选最优方案，而是选最可逆方案——可逆的决策错了能改，不可逆的决策错了要还债几个月。