AI基础设施选型全景：从GPU到推理引擎再到应用框架的层级化决策
AI基础设施选型全景：从GPU到推理引擎再到应用框架的层级化决策
AI基础设施选型的一个常见错误是"从下往上选"——先选GPU，再适配推理框架，最后凑应用框架。
正确的顺序恰恰相反：先定义你的应用场景，再往上追溯各层的能力要求。
本文提出一个五层决策模型，帮助你在每个层级做出协调一致的选型。
一、AI基础设施五层模型
1.1 为什么需要分层决策？
AI基础设施的选型存在"层级耦合"——底层选择会约束上层选项，上层的性能需求会传导到底层。如果各层的选型各自为政，最终架构会出现"关键路径上的短板"或"过度采购造成的浪费"。
1.2 五层模型定义
| 层级 | 名称 | 核心问题 | 典型选项 |
|---|---|---|---|
| L1 | 硬件层 | GPU/TPU/NPU选什么？多少卡？ | A100/H100/B200/L40S/昇腾910B |
| L2 | 云平台层 | 自建还是上云？裸金属还是K8s？ | AWS/Azure/GCP/阿里云/自建IDC |
| L3 | 推理引擎层 | 用什么推理框架？ | vLLM/TensorRT-LLM/SGLang/TGI |
| L4 | 编排框架层 | 如何管理Prompt和Agent？ | LangChain/LlamaIndex/Spring AI/自研 |
| L5 | 应用框架层 | 如何构建最终应用？ | RAG/ChatBot/Agent/AI Coding助手 |
二、各层选型标准与推荐
2.1 L1 硬件层：GPU选型决策
GPU选型是AI基础设施中锁定效应最强的一层——更换GPU意味着重做驱动适配、推理框架编译和性能调优。
| GPU型号 | 显存(GB) | FP16 TFLOPS | 显存带宽(GB/s) | 功耗(W) | 市场定位 | 参考价格(USD) |
|---|---|---|---|---|---|---|
| H100 SXM | 80 | 990 | 3,350 | 700 | 训练+推理旗舰 | $30,000 |
| H200 SXM | 141 | 990 | 4,800 | 700 | H100的显存升级版 | $35,000 |
| B200 | 192 | 2,250 | 8,000 | 1000 | Blackwell旗舰 | $40,000+ |
| L40S | 48 | 366 | 864 | 300 | 推理优化 | $8,000 |
| A100-80G | 80 | 312 | 2,039 | 400 | 性价比推理 | $12,000 |
| 昇腾910B | 64 | 320 (BF16) | 1,600 | 350 | 国产替代 | ¥90,000 |
| AMD MI300X | 192 | 1,300 (FP8) | 5,300 | 750 | H100竞品 | $20,000+ |
选型决策框架：
- 大模型训练（70B+）：必须是H100/B200级别，显存是硬约束（70B FP16训练需约560GB显存，至少8×H100）。
- 大模型推理（70B）：A100-80G是最佳性价比之选。H100在推理吞吐上比A100高约40%，但成本高2.5倍，ROI不如A100。
- 中等模型推理（7B-13B）：L40S单卡可跑13B模型（FP16），功耗仅300W，适合大规模推理部署。
- 国产化需求：昇腾910B的实际可用算力约为A100的60-70%，生态适配（CUDA→CANN迁移）是主要挑战。
2.2 L2 云平台层：自建 vs 托管
| 维度 | 自建K8s+GPU集群 | 云原生MaaS（Model as a Service） | 托管推理服务 |
|---|---|---|---|
| GPU资源确定性 | ✅ 独享 | ⚠️ 可能有排队 | ✅ 按SLA保障 |
| 运维复杂度 | 高（GPU驱动+网络+存储+调度） | 低 | 零 |
| 模型灵活性 | 任意模型 | 仅限平台支持的模型 | 需平台适配 |
| 成本（100卡年化） | ¥4,000,000（硬件+运维） | ¥8,000,000 | ¥12,000,000+ |
| GPU利用率 | 65-80%（自优化后） | 90%+（平台统一调度） | 对用户不透明 |
| 弹性扩缩容 | ⚠️ 受限于GPU库存 | ✅ 分钟级 | ✅ 自动 |
| 适合的团队 | 有专职SRE+GPU运维经验 | 无GPU运维能力 | 专注应用层 |
自建的门槛正在降低：NVIDIA GPU Operator（GPU驱动的K8s Operator）已经相当成熟，配合Kuberay（Ray on K8s），自建GPU集群的运维难度已从"需要专人"降到"有经验的SRE即可"。对于日均推理请求超过500万次的中大型团队，自建的18个月内即可回本。
2.3 L3 推理引擎层
（详见第1篇博客的完整对比）。这里给出在五层模型中的定位说明：
- vLLM：最佳通用选择，适合自建集群的80%场景。
- TensorRT-LLM：极致性能导向，适合GPU固定为NVIDIA且追求P99<200ms的场景。
- SGLang：共享前缀或结构化生成场景的专项引擎。
- TGI：HuggingFace生态的最佳适配，适合模型快速迭代的验证阶段。
L3选型的关键约束来自L1和L2：如果你选了昇腾910B（L1），TensorRT-LLM不可用，只能在vLLM和SGLang之间选择（两者已开始适配昇腾）。如果你选了MaaS平台（L2），L3可能被完全接管。
2.4 L4 编排框架层
（详见第6篇博客的完整对比）。从五层模型角度补充建议：
- L4是业务逻辑密度最高的一层——Prompt模板、Agent策略、检索管道都在这里。
- 框架的锁定效应在L4最强：LangChain的Agent逻辑深度嵌入框架后，迁移到LlamaIndex的代价可能比重写还高。
- 推荐策略：先用框架验证，稳定后自研核心路径。框架帮你找出"什么值得自研"。
2.5 L5 应用框架层
L5是离用户最近的一层，需要根据应用形态选择：
| 应用形态 | 推荐技术栈（从上到下） | 关键能力 |
|---|---|---|
| 企业知识库RAG | LlamaIndex + vLLM + A100 + 自建 | 文档解析+语义检索+溯源 |
| 智能客服ChatBot | Spring AI + vLLM + L40S + K8s | 多轮对话+工单系统集成 |
| AI编码助手 | 自研编排 + vLLM + A100 + 云平台 | FIM补全+仓库级上下文 |
| 复杂Agent | LangChain + vLLM + H100 + 自建 | 多步推理+工具调用+沙箱执行 |
三、总成本建模与优化
3.1 五层TCO模型
构建一个日均处理100万次推理请求（平均512 input + 256 output tokens）的AI应用，使用Llama-3-70B模型：
| 层级 | 组件 | 方案A（自建极致优化） | 方案B（云托管平衡） | 方案C（全SaaS） |
|---|---|---|---|---|
| L1 | GPU | 4×A100-80G（自购） | — | — |
| L2 | 云平台 | 自建K8s集群 | AWS P4d实例 | — |
| L3 | 推理引擎 | vLLM | vLLM（自管） | Bedrock/PAI |
| L4 | 编排框架 | 自研（Go） | Spring AI | LangChain |
| L5 | 应用框架 | RAG系统 | RAG系统 | 综合应用 |
| 年化TCO | ¥380,000 | ¥1,250,000 | ¥2,800,000 | |
| 单次请求成本 | ¥0.0010 | ¥0.0034 | ¥0.0077 |
3.2 成本优化的五个杠杆
| 优化方向 | 预期节省 | 实施难度 | 适用场景 |
|---|---|---|---|
| Prompt Caching（复用KV Cache） | 20-30% | 低 | 多轮对话、批量处理 |
| 模型量化（FP16→INT4） | 40-60%显存 | 中 | 对精度不敏感的场景 |
| 批处理调度优化 | 15-25%吞吐提升 | 中 | 延迟不敏感的离线任务 |
| Speculative Decoding | 30-50%延迟降低 | 高 | 小模型辅助大模型推理 |
| 多模型分层路由 | 30-40%总成本 | 中高 | 区分简单/复杂请求 |
成本优化的黄金法则：先做软优化（缓存、调度），再做硬优化（量化、蒸馏），最后才考虑硬件升级。
3.3 层级决策全景图
四、关键策略与反模式
4.1 各层的决策时机和调整周期
| 层级 | 决策锁定程度 | 建议重评周期 | 决策关键人 |
|---|---|---|---|
| L1 硬件 | 极高（2-3年锁定） | 18个月 | 架构师 + 采购 |
| L2 云平台 | 高（1-2年锁定） | 12个月 | SRE + 架构师 |
| L3 推理引擎 | 中（可混合部署） | 6个月 | ML工程师 |
| L4 编排框架 | 中低（部分可迁移） | 3-6个月 | 后端工程师 |
| L5 应用框架 | 低（需求驱动） | 持续迭代 | 产品+工程 |
4.2 最常见的三种反模式
反模式一："先买最贵的GPU，后面再说"
症状：花200万采购了8×H100，实际负载利用率不到30%。症结在于L3和L4根本没准备好，H100在跑vLLM时和A100的吞吐差距远小于价格差距。
反模式二："每个层级都选'最好的'"
症状：H100 + K8s自建 + TensorRT-LLM + LangChain Agent。这套组合的运维复杂度是指数级的——团队可能花60%的时间在维持基础设施运转，而非构建应用。
反模式三："忽略层级间的约束关系"
症状：选了昇腾910B（国产化要求），但编排框架深度依赖NVIDIA的CUDA生态，导致大量兼容性适配工作。L1的选择会传导到L3-L5，选型前必须验证全链路的兼容性。
结论
-
自上而下决策，自下而上验证。先定义L5（你的应用是什么），再看L4（需要什么编排能力），再选L3（推理引擎的适配性），再评估L2和L1。但在最终确定前，从L1开始验证全链路兼容性。
-
"够用就好"是AI基础设施选型的第一原则。H100比A100好40%，但贵250%。GPU是最大的单笔支出，过度采购的浪费远大于"不够用时的补充采购"。如果无法精确预估需求，先用云平台弹性验证，再确定自建规模。
-
L3和L4是最应该"多方案共存"的层。推理引擎可以vLLM主力 + TensorRT-LLM关键 + SGLang专项，编排框架可以LangChain验证 + 自研生产。这两层的锁定成本相对可控，不必追求"统一"。
-
关注国产芯片的迭代：昇腾910B的算力和生态在2026年已经有了质的飞跃，CANN（昇腾的CUDA等价物）的适配工具链显著改善。如果你有国产化时间表，现在就应该在L3和L4层做好双芯片架构的适配准备。
-
AI基础设施选型不是一次性的，而是持续的优化过程。GPU每18个月换代、推理框架每季度大更新、模型架构可能彻底改变推理范式（如MoE模型的专家路由对GPU拓扑的特殊要求）。建立一个"每季度重新评估各层选型"的机制，比找到一个"完美的初始选型"重要得多。
作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。
更多推荐
2
0- 0
已为社区贡献1条内容
所有评论(0)