AI 市场的瓶颈已经不只是“模型够不够聪明”。从芯片制造、先进封装，到数据中心供电、网络互联，再到模型推理阶段的 Token 成本，每一层都会影响最终的软件架构。Jordan Nanos 在《From Fab To Token: The State Of The Market》中把这些环节放在同一张图上讨论：硬件供给决定了算力扩张速度，网络决定了 GPU 能否有效协同，而 Tokenomics 则决定了模型能力能否以合理成本交付给用户。
不能只看 GPU 数量
数据中心扩张通常以 GPU 数量或理论 FLOPS 衡量，但这些指标并不能直接代表可用的 AI 服务能力。一个集群能否跑出稳定吞吐，还取决于几类约束：
- 芯片制造和先进封装能否提供足够的加速器。
- HBM 等高带宽内存是否成为供应瓶颈。
- 电力、散热和机架密度是否允许继续扩大部署。
- 节点之间的网络带宽和延迟是否支持大规模分布式训练与推理。
- 软件栈能否把硬件利用率维持在可接受水平。
因此，基准测试中的单卡性能和真实系统中的端到端性能之间，可能存在明显差距。尤其是大模型训练，通信、同步和内存访问会吞掉一部分理论计算能力；推理服务则更容易受到 KV cache、批处理策略和请求长度变化的影响。
工程团队需要关注的指标也应从“单个 GPU 每秒多少操作”扩展为“每美元、每瓦、每秒能够生成多少有效 Token”。这会把硬件选择、并行策略和产品定价连接起来。
网络是扩展模型的隐形边界
当模型规模超出单个设备或单台服务器的容量后，系统必须通过张量并行、流水线并行或专家并行来分布计算。此时，网络不再只是基础设施细节，而是模型架构的一部分。
如果每层计算都需要在节点之间频繁交换激活值，网络延迟会直接进入请求的关键路径。带宽不足时，增加更多 GPU 甚至可能带来收益递减：计算资源增加了，但设备在等待通信。
这也解释了为什么“更大的集群”不必然等于“更快的模型”。实际性能受到以下因素共同影响：
- 并行切分是否减少跨节点通信。
- 通信是否可以与计算重叠。
- 批处理是否足以摊薄网络和调度开销。
- 模型是否适合使用稀疏专家或其他减少激活计算的结构。
- 推理请求是否具有稳定的长度和流量分布。
对软件架构而言，一个重要结论是：模型服务层需要知道硬件拓扑。把所有 GPU 当成同质资源，再用通用负载均衡器随机分发请求，可能会隐藏 NUMA、节点内互联和跨节点网络带来的差异。
从 FLOPS 转向 Tokenomics
用户最终购买的通常不是 FLOPS，而是生成结果。Token 因此成为连接基础设施成本与产品价值的单位。
一次请求的成本并不只由输出 Token 数决定。输入上下文越长，预填充阶段的计算和内存压力越大；输出越长，解码阶段占用加速器的时间越久。并发、缓存命中率、批处理效率和模型量化方式也会改变单位 Token 成本。
可以用一个简化模型快速估算推理成本。下面的 Python 示例只用于预算和敏感性分析，实际生产成本还应加入网络、存储、运维、闲置容量和故障冗余等项目。
运行前只需修改脚本顶部的参数：
from dataclasses import dataclass
@dataclass
class InferenceCost:
accelerator_hour_usd: float
accelerators: int
utilization: float
input_tokens_per_request: int
output_tokens_per_request: int
requests_per_hour: int
def cost_per_request(self) -> float:
if not 0 < self.utilization <= 1:
raise ValueError("utilization must be between 0 and 1")
hourly_cost = self.accelerator_hour_usd * self.accelerators
effective_hourly_requests = self.requests_per_hour * self.utilization
return hourly_cost / effective_hourly_requests
def cost_per_million_tokens(self) -> float:
total_tokens = self.input_tokens_per_request + self.output_tokens_per_request
return self.cost_per_request() / total_tokens * 1_000_000
cost = InferenceCost(
accelerator_hour_usd=2.50,
accelerators=8,
utilization=0.65,
input_tokens_per_request=2_000,
output_tokens_per_request=800,
requests_per_hour=900,
)
print(f"cost/request: ${cost.cost_per_request():.4f}")
print(f"cost/million tokens: ${cost.cost_per_million_tokens():.2f}")
这个模型最适合做三类决策：比较不同硬件租赁价格，评估提高利用率的收益，以及判断上下文长度是否正在推高成本。它也提醒我们，降低成本不一定只能依靠更便宜的芯片；改善批处理、缓存和路由，同样可能产生显著效果。
软件架构需要适应供给约束
当加速器供给紧张时，系统设计应当允许模型和硬件发生变化，而不是把某一种 GPU 或某一个模型规格写死在业务代码中。可以从几个方向入手：
- 为模型服务定义统一的推理接口，把模型版本、量化格式和硬件放到部署配置中。
- 记录输入 Token、输出 Token、首 Token 延迟、生成吞吐和 GPU 利用率。
- 根据请求长度和优先级进行队列隔离，避免长上下文请求拖慢交互式请求。
- 使用连续批处理、Prefix Cache 或 KV cache 管理降低重复计算。
- 对高价值请求和后台批任务采用不同的服务等级与成本预算。
- 在跨节点部署前测量通信开销，确认扩容带来的吞吐增长是否超过网络成本。
基准测试也应尽量贴近实际业务。只测一个固定输入和固定输出长度，无法反映真实流量中的长尾请求。更可靠的测试至少应覆盖不同上下文长度、并发水平、批处理大小和缓存命中率。
落地时的检查清单
从晶圆厂到 Token 的链路说明，AI 系统的性能和经济性是跨层问题。团队在规划下一轮扩容或模型迁移时，可以检查：
- 是否知道当前供应限制发生在 GPU、HBM、封装、电力还是网络层。
- 是否同时跟踪延迟、吞吐、利用率和每百万 Token 成本。
- 是否验证了单机扩容与跨节点扩容的真实收益。
- 是否把上下文长度、缓存和批处理纳入成本模型。
- 是否为硬件替换、模型量化和服务降级保留配置空间。
AI 基础设施的竞争不会只由某一代芯片的峰值性能决定。能够把硬件供给、网络拓扑、模型并行和 Token 经济性统一起来的团队，才更容易在成本、规模和用户体验之间做出可持续的取舍。