Appearance
Model Infrastructure：算力、集群与模型服务
如果说 AI 应用最后呈现给用户的是一个会回答、会调用工具、会持续执行任务的系统，那么最底下首先要成立的一层，是 Model Infrastructure。
这一层不负责理解业务，不负责组织工作流，也不直接决定 agent 会不会做事。它负责的是另一件更基础的事：
让模型能够被训练出来、部署起来、稳定地提供推理服务。
很多讨论里，一说 AI Infrastructure，默认指的就是这一层。
这一层到底在解决什么
可以把 Model Infrastructure 理解成模型世界里的地基工程。它要回答的不是“模型会不会做任务”，而是：
- 模型能不能装进硬件
- 训练集群能不能稳定把模型跑完
- 推理服务能不能在目标延迟下吐出足够吞吐
- 多用户同时请求时会不会崩
- 更新模型版本时会不会把线上服务拖垮
如果这些问题没解决，上层所有 RAG、工具调用、workflow 和 agent 设计都会失去前提。
这一层通常包含哪些东西
Model Infrastructure 最常见的对象包括：
- GPU / TPU
- 高速网络
- 存储
- 训练集群
- 推理集群
- serving engine
- 模型权重分发
- 调度与弹性伸缩
- 监控与故障恢复
这些词放在一起时看起来像“资源堆叠”，但真正的问题其实只有一个：
如何把一个又大、又贵、又吃带宽、又吃显存的模型，变成一个稳定可用的服务。
1. 计算：模型先得有地方跑
模型基础设施的第一件事当然是计算。
但这里的“计算”不是抽象的 CPU 时间，而是非常具体的限制条件：
- 显存够不够
- 卡间带宽够不够
- 节点间网络够不够快
- 单卡吞吐能不能支撑目标并发
- 整体功耗和散热能不能承受
大模型之所以强，不只是因为参数多，也因为它把基础设施问题推得很极端。模型越大，工程上越容易碰到这些硬边界：
- 权重放不下
- KV cache 撑爆显存
- batch 一上来延迟飙升
- 节点一多，通信开销吞掉收益
所以这一层最先要学会的，不是“模型提示词怎么写”，而是 容量、带宽、延迟、吞吐、利用率 这些底层物理约束。
2. 训练集群：把模型从参数初始化推到可用状态
训练时的基础设施，解决的是 模型如何被造出来。
这时真正关键的往往不是某一张卡有多快，而是整个训练系统能不能稳定长时间运行：
- 数据怎么持续喂进去
- checkpoint 怎么保存
- 节点故障后怎么恢复
- 通信拓扑怎么减少浪费
- 训练任务怎么调度到合适集群
读者容易把训练理解成“多买点 GPU 就行”。但工程现实通常更像：
训练不是单机跑久一点，而是一个长时间、高同步、高成本、极怕中断的分布式系统。
所以当你看到别人讨论训练集群时，重点常常不是模型架构本身，而是：
- IB / NVLink / NVSwitch
- 分布式训练框架
- checkpoint 恢复
- 存储吞吐
- 调度稳定性
这些都属于 Model Infrastructure，而不是上层 AI 应用架构。
3. 推理集群：把模型变成在线服务
模型训练出来以后，还要面对另一类完全不同的问题：怎么服务真实请求。
推理集群最常关心的是：
- 首 token 延迟能不能接受
- 每秒 token 吞吐够不够
- 并发高了以后服务是否还能稳定
- 长上下文会不会把显存和 KV cache 压爆
- 混合模型路由时如何维持整体 SLA
训练时你关注的是“能不能把模型训完”，推理时你关注的是“能不能以合理延迟、合理成本持续服务用户”。
这也是为什么推理基础设施会非常重视：
- batching
- KV cache 管理
- paged attention
- continuous batching
- speculative decoding
- 多模型部署
- 冷热实例切换
这些都不是业务逻辑，而是“模型服务化”本身的工程学。
4. Serving Engine：把权重接成可调用接口
很多人把“部署模型”想成起一个 API。真正做过之后会发现，中间差着一整层 serving engine。
这层负责的事包括：
- 加载权重
- 管理 tokenizer
- 管理并发请求
- 维护 KV cache
- 实现 batch 策略
- 提供 OpenAI-compatible 或自定义接口
所以你会经常看到这些名字：
- vLLM
- TensorRT-LLM
- Triton Inference Server
- TGI
- SGLang
它们不是“可有可无的封装”，而是把模型从一堆张量参数，变成一个可部署、可并发、可调优服务的关键层。
5. 调度与可靠性：把单次运行变成长期服务
只要模型进入生产环境，问题就不再是“它能跑一次”，而是“它能不能一直跑”。
所以 Model Infrastructure 还要负责：
- 服务发现
- 自动扩缩容
- 多区域部署
- 故障转移
- 发布回滚
- 权重版本管理
- GPU 资源分配
- 健康检查
这一层跟传统分布式系统很像，但又更苛刻，因为模型服务通常同时具备三个特点：
- 资源占用高
- 时延敏感
- 请求方差大
也就是说，一点点调度失误，就可能表现成非常具体的用户问题：首字慢、回答突然截断、流式输出卡住、长上下文请求大量超时。
6. 为什么这一层不能替代上层
Model Infrastructure 非常重要，但它解决的是“模型能不能稳定跑”，不是“模型能不能稳定工作”。
哪怕你把部署做得很好，下面这些事仍然不会自动发生：
- 模型不会凭空理解你的企业知识
- 模型不会自动接上数据库和浏览器
- 模型不会自动形成多步执行能力
- 模型不会自动知道哪些操作需要审批
- 模型不会自动解释自己为什么失败
所以很多团队在 Model Infrastructure 上投入很多以后，仍然会发现业务效果不够好。不是因为底层不重要，而是因为 跑起来 和 用起来 根本是两层不同的问题。
你应该怎样理解这一层
对读者来说，最重要的不是背多少厂商名词，而是建立一个判断习惯：
当一个讨论主要围绕下面这些问题时，你大概率就在谈 Model Infrastructure：
- 显存和带宽够不够
- 训练和推理集群怎么配
- serving engine 选什么
- 并发、吞吐和延迟怎么平衡
- 权重如何发布、回滚和扩缩容
一旦问题开始转向知识接入、工具调用、workflow、观测和审批，那通常就已经不是这一层了。
结论
- Model Infrastructure 负责把模型变成可训练、可部署、可服务的底层能力
- 它的核心问题是计算、带宽、吞吐、延迟、调度和可靠性
- 它决定模型能不能稳定跑，但不决定模型能不能完成真实工作