选 GPU 还在看算力？推理的瓶颈从来不是算力

选 GPU 的时候，大多数人盯着算力看。算力越高越快，这是直觉。

但这个直觉在 AI 推理场景下是错的。推理的瓶颈几乎从来不在算力，而在内存带宽。

原因很简单：推理的过程不是"算"，而是"读"。当模型做推理时，它需要把数十亿甚至数千亿的参数从显存加载到计算单元。这个"读取"的速度，决定了 token 生成的速度。算力决定了你能一次算多复杂的东西，内存带宽决定了你能多快把参数喂给计算单元。

以 H100 和 A100 的对比为例。H100 的 FP8 算力是 A100 的 6 倍（3958 TFLOPS vs 624 TFLOPS），但内存带宽只提升了 1.7 倍（3.35 TB/s vs 2 TB/s）。如果在跑小 batch 推理，算力根本跑不满，瓶颈全在带宽上。H100 实际的推理速度提升可能只有 1.5 到 2 倍，而不是 6 倍。

这就是为什么很多人在 A100 上跑推理觉得够用，换了 H100 却没感受到预期中的巨大提升，选型时盯着算力看，实际花的钱在带宽上。

对于推理为主的场景，选型策略应该是：先算清楚你的模型需要多少内存带宽，再决定 GPU 型号。公式很简单：模型参数量 × 每个参数需要的字节数 / 目标 token 生成速度 = 需要的内存带宽。这个数字大于 GPU 的峰值带宽，你就遇到了带宽瓶颈；远小于峰值带宽，说明算力才是你的瓶颈。

别让 GPU 选型变成一场参数军备竞赛。看清你的 workload 到底绑在算力上还是绑在带宽上，比看懂所有的 benchmark 都重要。

GPU 选型是 AI 基础设施决策中最关键也最复杂的选择之一。不仅要考虑硬件的价格和性能，还要考虑与现有软件栈的兼容性、长期的可扩展性和运营成本。云 GPU 和本地 GPU 各有优劣，云 GPU 灵活性高但长期成本可能更高，本地 GPU 一次性投入大但单位成本更低。对于初创团队和小型项目，建议优先使用云 GPU，避免过早的硬件投资。选择 GPU 时还需要关注显存大小、内存带宽、互连带宽和能效比等指标。不同的工作负载对不同的指标敏感，推理密集的场景更关注显存和带宽，训练密集的场景更关注算力和互连。

AI 领域有一个普遍的趋势：技术进步的速度远超组织和个人的适应速度。这意味着今天的最佳实践可能在半年后就过时了。因此与其追求掌握某个特定技术的所有细节，不如培养快速学习和判断技术价值的能力。当一个新的框架或模型发布时，快速判断它对自己的工作有没有价值，值得花多少时间去学习。对于没有长期价值的热点，保持关注即可，不需要深入学习。对于有长期价值的趋势，投入足够的时间深入理解底层原理，而不仅仅是会使用工具。这种能力的培养需要持续阅读、实践和总结。每周花固定时间阅读技术博客和论文，每月做一个实践项目验证所学知识，每季度进行一次知识体系的复盘和重构。

在软件开发领域，有一条经验法则：任何在开发阶段看起来很聪明但让调试变得困难的做法，最终都不是好主意。这条法则在 AI 应用开发中尤其适用。AI 应用的不确定性比传统软件高得多，这意味着调试和排查问题的难度也大得多。因此 AI 应用的设计应该追求简单、透明、可追踪。简单意味着每个组件的职责清晰，组件之间的依赖关系明确。透明意味着系统的每个决策过程都可以被追溯和理解。可追踪意味着每次模型调用、每步推理过程都被记录在案。只有做到了这三条，你才能在系统出现问题时快速定位根因。

AI 项目的技术栈选择决定了开发效率和后期维护的成本。Python 是目前 AI 开发的主流语言，拥有最丰富的生态。TypeScript 在 AI 应用开发中也越来越流行，特别是在需要前后端一体化的场景中。选择技术栈时的核心原则是优先考虑团队熟悉的技术，减少学习成本。框架选择同理，LangChain 功能丰富但复杂度也高，直接调用 API 可能更可控。建议从最简单的方案开始，随着需求复杂度的增加逐步引入框架。过早的框架选择会让系统复杂度不必要地增加。