网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

过去两年，AI 基础设施（AI Infra）领域发生了一件非常有意思的事情。

一方面，GPU 的计算能力不断提升。从 A100 到 H100，再到最新一代 GPU，理论算力几乎每一代都有数倍增长；另一方面，HBM 容量也越来越大，单卡显存已经达到数十 GB 甚至上百 GB。

按理来说，GPU 更快、显存更大，大模型推理应该越来越快。

但现实却并非如此，很多团队在线上监控中都会看到类似的数据：

GPU Utilization：35%

GPU Memory：95%

GPU Compute：等待中……

GPU 并没有一直在计算，而是频繁处于等待状态。

为什么？因为对于今天的大模型而言，GPU 最大的问题已经不是算不动，而是"吃不饱"。

真正限制 AI 性能的，是数据能否持续、高效地送到 GPU，而这正是 Bandwidth（带宽） 要解决的问题。

一、Bandwidth 到底是什么？

很多开发者第一次接触带宽时，想到的都是：

• 家里的宽带
• 千兆网络
• 10Gb 网卡

实际上，在 AI 系统中，Bandwidth 的范围远比网络宽得多。

一个完整的大模型系统涉及多个层面的数据传输：

SSD
   │
CPU Memory（DDR）
   │
PCIe
   │
GPU HBM
   │
Tensor Core

如果部署的是多 GPU 集群，还会增加：

GPU0 ── NVLink ── GPU1
   │                  │
NVSwitch          NVSwitch
   │                  │
InfiniBand / RDMA 网络

因此，在 AI 系统里，Bandwidth 指的是整个计算链路上的数据传输能力。

它不仅包括：

• HBM 带宽
• PCIe 带宽
• NVLink 带宽
• 网络带宽
• 存储带宽

更准确地说：

Bandwidth 决定了数据能够以多快的速度流向 GPU。

二、GPU 为什么越来越容易"饿"？

可以把 GPU 想象成一家现代化工厂。

GPU Core 是流水线上的工人，而模型参数、KV Cache、Prompt 等数据就是生产原料。

如果原料能够源源不断送到流水线，工人就可以持续工作。

但如果运输系统跟不上，即使工人再多、设备再先进，也只能停下来等待。

AI 推理也是一样，一次 Token 生成通常需要经历下面几个步骤：

读取 Prompt
        │
读取模型参数
        │
读取 KV Cache
        │
Attention 计算
        │
生成 Token
        │
写回 KV Cache

真正执行矩阵计算的时间，只占整个流程的一部分。

更多时间花在：

• 加载模型参数
• 读取历史 KV Cache
• GPU 之间同步数据
• 写回新的缓存

因此，GPU 的利用率越来越受数据传输速度影响。

现代 AI 推理，本质上已经是一条数据流水线，而不仅仅是一条计算流水线。

三、为什么大模型比传统计算更依赖带宽？

传统 HPC（高性能计算）通常属于"计算密集型"任务。

例如天气模拟、流体力学、科学计算。

数据加载一次后，GPU 可以持续计算很长时间。

而 Transformer 推理完全不同，每生成一个 Token，都需要重新访问历史上下文。

例如：

Prompt

↓

Embedding

↓

读取 KV Cache

↓

Attention

↓

FFN

↓

生成新 Token

随后进入下一轮：

再次读取 KV Cache

↓

Attention

↓

生成下一个 Token

Context 越长，需要访问的数据越多。

因此，大模型推理属于典型的：

Memory Intensive + Bandwidth Intensive Workload（内存和带宽密集型任务）。

随着 Context Window 从 4K 提升到 32K、128K，甚至百万 Token，Bandwidth 的重要性还会继续提高。

四、为什么 NVIDIA 一直在升级 HBM？

很多人关注 GPU 时，更在意显存容量。

例如：

• 24GB
• 48GB
• 80GB
• 192GB

其实，对于 AI 来说，更重要的是 HBM Bandwidth。

原因很简单，GPU 每秒可以完成海量矩阵计算，如果数据供应速度跟不上，再强的 GPU 也只能等待。

可以把 GPU 看作汽车发动机，而 HBM 就像燃油供应系统。

发动机动力再强，如果供油不足，汽车依然无法跑出最高速度。

同样，对于 GPU 来说：

HBM 的价值不仅在于容量，更在于能够持续提供超高带宽的数据访问能力。

这也是为什么 HBM 每一次升级，都不仅提升容量，更大幅提升数据吞吐能力。

五、为什么多 GPU 比单 GPU 更难优化？

很多开发者认为：

GPU 越多，推理速度越快。

事实上，多 GPU 带来的不仅是更多算力，还有更多通信。

例如一个 70B 模型：

GPU0 ── GPU1 ── GPU2 ── GPU3

模型参数分布在不同 GPU 上，每完成一次 Attention，都需要跨 GPU 同步数据。

GPU 数量越多：

• 通信次数越多；
• 数据同步越频繁；
• Bandwidth 压力越大。

因此，很多情况下：

限制多 GPU 性能的不是 Compute，而是 Communication。

这也是 NVLink、NVSwitch 和 InfiniBand 存在的意义。

它们不是为了提升 GPU 算力，而是为了降低 GPU 之间的数据交换成本。

六、AI 为什么进入 Data Flow 时代？

过去十年，大家关注的是 CPU；后来，GPU 成为 AI 的核心；而今天，越来越多 AI 公司开始关注另外一个问题：

如何让数据更快流动？

无论是：

• FlashAttention
• PagedAttention
• Continuous Batching
• Speculative Decoding
• KV Cache

这些技术看似不同，其实都围绕同一个目标：

减少数据搬运，提高 Bandwidth 利用率。

换句话说，现代 AI 优化已经不只是优化计算，而是在优化整个数据流。

因此，AI 系统开始进入真正的 Data Flow Era（数据流时代）。

七、Bandwidth 正在成为 AI 基础设施的新竞争力

如果说过去 AI 拼的是模型规模，那么今天 AI 拼的是系统效率。

一套完整的 AI 基础设施已经演变为：

Application
      │
Agent Runtime
      │
Inference Runtime
      │
KV Cache
      │
GPU Scheduler
      │
Network
      │
GPU Cluster

Compute 决定 GPU 能算得多快；Memory 决定 GPU 能存多少数据；而 Bandwidth 决定数据能否持续流向 GPU 三者缺一不可。

真正优秀的 AI 系统，不一定拥有最多的 GPU，而是能够让 GPU 始终保持高利用率。

因此，越来越多企业开始投入：

• 高速互联网络
• GPU 调度系统
• 推理 Runtime
• Cache 优化
• 数据流水线设计

本质上都是为了提高整个系统的 Bandwidth Efficiency（带宽利用率）。

总结

过去，我们总认为 AI 的核心竞争力来自 GPU。

后来发现，仅有 GPU 远远不够。

今天，大模型的发展再次证明：

GPU 的计算能力提升速度，已经快于数据传输能力的提升速度。

未来 AI 的竞争，将逐渐从"芯片竞争"演变为"数据流竞争"。

对于 AI 基础设施而言：

• Compute 决定计算速度；
• Memory 决定数据容量；
• Bandwidth 决定数据流动效率。

真正高性能的 AI 系统，不是拥有最多 GPU，而是能够让 Compute、Memory 和 Bandwidth 三者协同工作，让数据始终保持高速流动。

这也是为什么越来越多 AI 公司开始重构 Runtime、优化 KV Cache、建设高速互联网络。

因为未来 AI 拼的，不只是算力，而是整个 Data Flow System（数据流系统）。