AI 时代的 GPU 生存工具包
随着 AI 负载的扩散，程序员们正在争论：自己究竟需要多了解 GPU，还是把它们当作高层 API 背后的黑箱加速器即可。评论者将 CPU 和 GPU 架构、多线程、SIMD 以及 transformer 训练进行对比，解释并行性真正重要的地方，同时也指出了 CUDA 的易用性、Nvidia 的主导地位以及 AMD 的 ROCm 生态成熟度等现实问题。许多人认为，只有一部分开发者会真正编写低层 GPU 代码，但对加速器、内存带宽和批处理如何影响性能的基本认识，正越来越会影响日常工程决策。
开发者了解 GPU 的重要性
- 围绕“每个开发者都必须知道”这种说法展开争论。
- 有些人认为，大多数开发者只会通过 API 使用 AI，不需要深入了解 GPU。
- 也有人表示，相关知识（如 GPU/AI 基础）正变得越来越有用，而且学习成本很低。
- 还有人担心，这类标题是在利用冒名顶替综合征，也有点击诱饵之嫌。
CPU 与 GPU、并行性与性能
- 讨论了摩尔定律以及单线程速度的极限（“功耗墙”、“内存墙”、ILP 限制）。
- 多线程被视为必要但并不完美：有开销、同步成本，以及阿姆达尔定律的限制。
- SIMD/向量指令被强调为一个经常被低估但很强大的能力；也有人说编译器/运行时在这方面正变得更好。
- CPU 和 GPU 都拥有许多计算单元；GPU 用牺牲复杂控制流来换取极高的吞吐量和带宽。
- 延迟与吞吐量：GPU 和加速技术主要提升吞吐量，而不是单次请求延迟。
CUDA、厂商锁定与替代方案
- 许多人觉得 CUDA 直接明了、很有生产力，且对合适的工作负载能带来巨大加速。
- 也有人指出，上手成本确实存在（文档很长、需要 C++ 知识、复杂 kernel 的调试很痛苦）。
- 建议：与图形 API + 计算方案相比，优先选择 CUDA（更容易编写和维护）。
- 反对意见集中在这会进一步强化 Nvidia 的垄断；反驳则是，实践者必须使用当下最好的工具。
- AMD/ROCm：被认为在进步，但仍比 CUDA 粗糙；关键问题是缺少可租用的高端 AMD GPU。HIP 有助于可移植性，但并不丝滑。
语言与“自动并行”
- 有人提出一种能透明地最大化 CPU/GPU 利用率的语言。
- 也有人怀疑编译器不可能总能推断并优化任意代码；提到了 Futhark、JAX、Mojo、HVM、superoptimizers 等研究工具和 DSL，作为部分尝试。
- 讨论中区分了并发（Erlang/Elixir）与数值型 GPU 并行。
针对文章和示例的具体批评
- Mandelbrot 基准测试：只有大约 10 倍的加速，被认为低得可疑；很可能主要受 JIT/开销和基线选择不佳影响。
- 有评论者发现一个 bug：CUDA kernel 实际上并没有被调用；作者后来修复了。
- 对文章的其他抱怨包括：
- 对 CPU 执行过程过度简化。
- 忽略了 SIMD 讨论。
- 混入了不属于“每个人都必须知道的最低限度”指南里的 AWS 产品细节。