GPU 架构与计算模型

共 24 题
📑 题目列表 24 题
#
★★★

1. GPU 与 CPU 的架构差异,SIMT(Single Instruction Multiple Thread)模型如何为高吞吐并行设计?

请说明 GPU 与 CPU 在架构设计上的根本差异,并解释 SIMT(Single Instruction Multiple Thread)模型如何针对高吞吐并行进行设计?

  • 了解 CPU 与 GPU 在控制流、缓存、算力密度上的差异
  • 理解 SIMT 与 SIMD 的关系及 SIMT 的执行模型
  • 掌握 GPU 面向吞吐量(throughput)而非延迟(latency)的设计哲学

CPU 采用少量复杂核心,配备大容量缓存和复杂分支预测/乱序执行,目标是降低单线程延迟;GPU 则采用大量简单核心,拥有极高的线程并发度,用大量线程并行来隐藏延迟,目标是最大化吞吐量。SIMT 模型下,GPU 以 warp(通常 32 线程)为单位执行同一指令,多条线程并行执行相同指令但作用于不同数据,本质上是"以线程数量补延迟"的策略。SIMT 与 SIMD 的区别在于 SIMT 的线程是独立调度的,每个线程有自己的寄存器、程序计数器和状态,但同一 warp 内共享指令流;当 warp 内出现分支发散时,不同路径会被串行执行,造成吞吐损失。整个设计围绕"吞吐优先"展开:寄存器堆极大、缓存较小、隐藏内存延迟靠线程切换而非数据预取。

理解 GPU 是为吞吐量优化的,关键在于认识到延迟隐藏的代价是尽量让硬件始终有可用线程可切换。CPU 追求单线程快,GPU 追求同时执行尽可能多的线程。SIMT 的 warp 统一指令流是性能来源,也是分支发散问题的根源。

#
★★

2. GPU 内存层次中 Global Memory、Shared Memory、Register、L1/L2 Cache 的容量与延迟,如何为 LLM 推理优化内存访问?

请描述 GPU 内存层次(Global、Shared、Register、L1/L2 Cache)的容量与延迟特性,并说明在 LLM 推理中如何优化内存访问?

  • 掌握 GPU 各层内存的容量与延迟量级
  • 理解不同内存的访问单元与并行方式
  • 能针对 LLM 推理(KV Cache、权重、中间激活)给出访存优化策略

GPU 内存层次自下而上依次为:Global Memory(HBM,容量最大可达数十 GB,延迟数百周期,需通过读取 32 字节/128 字节的 cacheline 合并访问)、L2 Cache(数 MB,延迟数十周期)、L1 Cache/Shared Memory(每 SM 数百 KB,延迟约 20-30 周期)、寄存器(每线程数百个,延迟最低)。访问顺序是并发线程写数据到寄存器,再通过 Shared Memory 复用,最后回写 Global Memory。在 LLM 推理中,内存访问优化至关重要:权重和 KV Cache 都是访存密集的,应利用共享内存做 tiling 复用数据、利用缓存局部性、用连续一次性读取(vectorized/合并访问)减少访存次数,并尽量复用寄存器中的中间结果。此外,把 KV Cache 保持在较高缓存层次或使用更高效的 KV 管理(如 PagedAttention)能显著减少 HBM 往返。

LLM 推理是典型的 memory-bound 场景,瓶颈常在 HBM 带宽而非算力。因此优化重点是减少全局内存访问次数、提高数据复用率,这正是 FlashAttention、tiling 等技术的核心动机。

#
★★

3. NVIDIA Hopper(H100/H200)与 Blackwell(B100/B200)架构核心,Transformer Engine、FP8 Tensor Core、NVLink Switch 系统有哪些创新点?

请说明 NVIDIA Hopper(H100/H200)与 Blackwell(B100/B200)架构的核心创新点,包括 Transformer Engine、FP8 Tensor Core 和 NVLink Switch 系统?

  • 掌握 Transformer Engine 的动态精度选择机制
  • 理解 FP8 Tensor Core 的性能与精度收益
  • 了解 NVLink Switch 在多卡互联中的作用

Hopper 架构引入了 Transformer Engine,可以在矩阵乘时动态选择 FP16/BF16/FP8 等精度,结合逐层观察激活值动态决定是否使用 FP8,从而在不牺牲精度的前提下提升训练速度。FP8 Tensor Core 支持 E4M3 和 E5M2 两种格式,配合双倍吞吐使 H100 的 FP8 算力约为 FP16 的两倍。NVLink Switch 将多卡互联从点到点拓扑升级为交换机拓扑,H100 通过 NVLink4 提供 900GB/s 的双向带宽,实现多卡高带宽低延迟通信。Blackwell 在此基础上进一步强化:更快的 FP4/FP8 支持、更高的 NVLink 带宽(NVLink5 达 1.8TB/s)、增强的 NVLink Switch 以支持更大规模集群,并首次引入对 2 位/4 位精度推理的强支持,同时为大规模训练提供更高的互联带宽与可扩展性。

这些架构创新共同指向两个方向:一是提高单卡算力密度(FP8/FP4 与 Tensor Core),二是增强多卡互联(NVLink Switch)以支撑超大规模模型训练。理解 Transformer Engine 的关键是它"动态选择精度"。

#
★★

4. Warp 与调度模型,Warp Size、Occupancy、Warp Divergence 如何影响核函数性能,为什么 SIMT 下的分支发散会造成吞吐损失?

请解释 Warp Size、Occupancy、Warp Divergence 如何影响核函数性能,并说明 SIMT 下分支发散为何造成吞吐损失?

  • 理解 warp size(通常 32)与调度单位
  • 掌握 occupancy 的概念及其对延迟隐藏的影响
  • 理解 warp divergence 的成因与代价

Warp 是 GPU 调度与执行的最小单位,通常为 32 个线程,warp 内线程共享一条指令流。Occupancy 指活跃 warp 数占设备支持最大 warp 数的比例,高 occupancy 能提供更多可切换的线程以隐藏访存与指令延迟,但过高的 occupancy 也会因寄存器/共享内存不足而受限。Warp Divergence 指同一 warp 内线程因分支条件不同而走不同路径,此时 GPU 会串行执行各分支路径,并用 predication 屏蔽不相关的线程,导致该 warp 的有效吞吐下降。例如一个 warp 中一半线程走 if 分支、一半走 else 分支,则两条路径都要执行,吞吐减半。因此应尽量让线程在 warp 内同质化执行,避免线程间数据相关的分支。

性能优化需在 occupancy 与资源占用之间权衡:提高 occupancy 提升延迟隐藏能力,但会占用更多寄存器/共享内存。避免分支发散的关键是让分支粒度大于 warp(即整个 warp 走同一分支),或用数据规整化的方式消除分支。

#
★★

5. Shared Memory 与 Bank Conflict,GPU 共享内存的 bank 组织方式,bank 冲突如何用 padding 或调整访问模式规避?

请说明 GPU 共享内存的 bank 组织方式,以及如何用 padding 或调整访问模式来规避 bank 冲突?

  • 理解共享内存按 bank 划分的并行访问机制
  • 掌握 bank conflict 的成因
  • 掌握 padding 与访问模式调整两条规避手段

GPU 的共享内存被划分为多个 bank(通常 32 个),每个 bank 在单个周期内只能响应一次访问。当同一 warp 内多个线程在同一周期访问同一 bank 的不同地址时,就会发生 bank conflict,硬件会将这样的访问串行化为多个事务,降低吞吐。例如线程访问地址 threadIdx 与 threadIdx+1 若落在同一 bank 就会冲突。规避方法主要有两种:一是 padding,即在每行数据末尾添加一个元素(如 matrix 行宽加 1),使不同行错开 bank 起始位置,从而避免按行访问时冲突;二是调整访问模式,例如让线程按照转置/交错方式访问,或对索引做仿射变换(如 threadIdx 与 threadIdx/N 组合),使同一周期内线程访问的地址落于不同 bank。理想情况下每个周期 32 个线程访问 32 个不同 bank,吞吐最大。

bank conflict 是共享内存优化的常见陷阱。padding 简单有效,但要保证不对齐访问不破坏向量化;调整访问模式则更灵活,常配合数据布局变换一起使用。

#
★★

6. CUDA kernel launch 的开销组成,为什么小 kernel 频繁启动会受限于 launch overhead,CUDA Graphs 如何批量提交并降低开销?

请分析 CUDA kernel launch 的开销组成,解释小 kernel 频繁启动为何受限于 launch overhead,并说明 CUDA Graphs 如何批量提交降低开销?

  • 理解 kernel launch 的 CPU-GPU 同步开销
  • 掌握小 kernel 场景下 launch overhead 占比高的原因
  • 理解 CUDA Graphs 的捕获与回放机制

Kernel launch 的开销包括 CPU 端构造与提交参数、驱动与运行时经过的多次上下文切换、以及 CPU-GPU 之间的同步与命令分发。这些开销通常在微秒级,虽然单个 kernel 很小,但当 kernel 执行时间本身极短(几微秒)时,launch overhead 会占主导,使得 GPU 大部分时间处于等待而非计算。CUDA Graphs 通过图捕获(graph capture)将一系列 kernel 的启动依赖关系记录为图,然后一次性实例化并回放,减少了逐次 launch 的 CPU 开销和启动延迟,使多个小 kernel 能批量提交、连续执行。图回放还能利用流的并行性在 GPU 上提前调度,进一步提升吞吐。

频繁启动小 kernel 是推理场景的常见瓶颈。CUDA Graphs 把"多次启动"变成"一次捕获、多次回放",是降低 launch overhead 的关键手段,尤其适合计算图结构固定的场景。

#
★★

7. AMD MI300/MI325 与 NVIDIA 的竞争,ROCm 与 CUDA 生态的差距及项目(PyTorch native support)进展如何?

请分析 AMD MI300/MI325 与 NVIDIA 的竞争格局,说明 ROCm 与 CUDA 生态的差距以及 PyTorch native support 等项目的进展?

  • 了解 AMD MI300/MI325 的硬件规格
  • 理解 ROCm 相对 CUDA 的生态差距
  • 了解 PyTorch 对 ROCm 的原生支持进展

AMD MI300 系列(包括 MI300X 与 MI300A)以超大 HBM 容量(如 192GB)和较高算力与 NVIDIA H100 竞争,MI325 进一步升级显存与带宽,在推理场景针对显存容量有优势。软件生态上,ROCm 是 AMD 的 CUDA 对应异构计算平台,但长期落后于 CUDA:工具链、库(cuBLAS/cuDNN)成熟度、算子覆盖、社区规模与文档均不如 CUDA。不过近年 ROCm 进展明显,PyTorch 已提供原生 ROCm 支持(通过 PYTORCH_ROCM_ARCH 编译的 ROCm 版本),使主流模型无需改动即可在 AMD 上运行;同时 AMD 积极推动 HIP(将 CUDA 代码翻译为 ROCm 的友好层)来降低迁移成本。总体而言,AMD 硬件在性价比与显存上有竞争力,但生态成熟度仍是追赶 CUDA 的主要障碍。

生态之争关键是软件栈与算子覆盖。ROCm 通过 HIP 兼容层和 PyTorch 原生支持来缩小迁移成本,但深层优化(如 cuDNN 级 expert 算子)仍依赖社区与厂商持续投入。

#
★★

8. 国产 GPU(寒武纪、燧原、摩尔线程、天数智芯、华为昇腾)的工程现状与软件栈成熟度?

请评估国产 GPU(寒武纪、燧原、摩尔线程、天数智芯、华为昇腾)的工程现状与软件栈成熟度?

  • 了解主要国产 GPU 厂商及其产品定位
  • 掌握各厂商软件栈(编程语言、算子库、框架适配)的成熟度
  • 理解国产 GPU 在生态上与 NVIDIA 的差距

国产 GPU 在推理与训练上均有布局:华为昇腾(Ascend)凭借昇腾软件栈(CANN、MindSpore、MindIE)和庞大的推理部署规模在国产化中领先,Triton 与 PyTorch 适配也较成熟;寒武纪(Cambricon)以思元系列和寒武纪编译器(CNToolkit)主攻推理与训练;燧原(Enflame)的邃思系列配合公司自研软件栈;摩尔线程(Moore Threads)提供基于 MUSA 的 CUDA 兼容方案,尝试降低迁移成本;天数智芯(Iluvatar)推出天垓系列与自研栈。总体而言,国产 GPU 的硬件算力在部分场景已可用,但软件栈成熟度普遍低于 CUDA:统一的多卡通信、算子库覆盖、编译器优化成熟度、社区与文档都仍在完善中,框架适配与上线运维成本较高。生态建设是国产 GPU 规模化落地的关键瓶颈。

国产 GPU 的挑战主要不在硬件而在软件生态的完整性与稳定性。评估时要关注算子覆盖、编译器、通信库、框架适配与生产稳定性,昇腾因规模化部署在工程成熟度上相对领先。

#
★★

9. Roof-line 模型,如何判断一个 GPU kernel 是 memory-bound 还是 compute-bound,算力与 HBM 带宽的比值如何指导优化方向?

请解释 Roof-line 模型,说明如何判断一个 GPU kernel 是 memory-bound 还是 compute-bound,以及算力与 HBM 带宽的比值如何指导优化方向?

  • 理解算术强度(arithmetic intensity)的概念
  • 掌握 Roof-line 模型判断瓶颈的方法
  • 能根据算力带宽比给出优化方向

Roof-line 模型用算术强度(AI,即每字节访存对应的浮点运算次数 FLOPs/Byte)来刻画算子的访存-计算特征。将设备算力(FLOPs/s)与带宽(Bytes/s)的比值称为 ridge point(转折点)。当算子的算术强度高于 ridge point 时,它处于 compute-bound(计算受限),性能上限由算力决定;低于 ridge point 时则为 memory-bound(访存受限),性能上限由带宽决定。优化方向据此区分:对 memory-bound 的 kernel,应重点减少访存量(如数据复用、tiling、算子融合、使用更低的精度),而不是单纯提高算力利用率;对 compute-bound 的 kernel,则应优化计算效率(如提升 Tensor Core 利用率、减少无效计算)。LLM 推理中 Attention、GEMM 等通常偏 memory-bound,因此带宽优化是关键。

Roof-line 模型是判断优化方向的标尺。先算算子的算术强度,再与设备 ridge point 比较,就能确定瓶颈是带宽还是算力,从而决定优化重点,避免在错误的瓶颈上花功夫。

#
★★

10. 矩阵乘的优化路线,从 Naive 到 Shared Memory Tiling 再到 Tensor Core(WMMA/MMA),各阶段分别优化了什么瓶颈?

请描述矩阵乘从 Naive 到 Shared Memory Tiling 再到 Tensor Core(WMMA/MMA)的优化路线,并说明各阶段分别优化了什么瓶颈?

  • 理解 Naive 实现的问题(L2/HBM 反复访问)
  • 掌握 tiling 通过共享内存复用数据减少访存
  • 理解 Tensor Core 用大块矩阵运算提升算力

矩阵乘的优化分阶段演进。Naive 实现按标量逐元素计算,每个输出元素都从全局内存读入所需数据,导致 HBM 访问量巨大、数据复用率低,瓶颈在带宽。Shared Memory Tiling 阶段把矩阵按块(如 16x16/32x32)分块加载到共享内存,多个线程复用同一块数据,显著减少全局内存访问次数,使访存瓶颈得到缓解,同时配合寄存器分块进一步复用。Register Tiling 在每个线程内累积多个输出元素,减少重复读取。Tensor Core 阶段(WMMA/MMA 指令)利用硬件专门做矩阵乘加(如 m16n8k16、m16n8k8 等),把数千个 FLOP 压进单条指令,极大提升算力密度,让 kernel 从带宽受限转向算力受限并逼近算力上限。现在高性能实现(cuBLAS/cutlass)还会结合 TMA、多级流水线、swizzle 去中心化等进一步优化。

这条优化路线本质是"先降低访存(tiling),再提升算力(Tensor Core)"。理解每一步解决的瓶颈,才能在遇到具体 GEMM 时选择正确的优化手段与期望性能。

#
★★

11. GPU 虚拟化与共享,MIG、vGPU 与 K8s 设备插件的隔离粒度差异,在推理服务中如何选择共享与隔离策略?

请比较 MIG、vGPU 与 Kubernetes 设备插件在 GPU 虚拟化与共享上的隔离粒度差异,并说明推理服务中如何选择共享与隔离策略?

  • 理解 MIG 的硬件级隔离
  • 理解 vGPU 的软件虚拟化
  • 理解 K8s 设备插件与共享机制

MIG(Multi-Instance GPU)是 NVIDIA 的硬件级 GPU 切片技术,把一张 GPU 在硬件层面划分为多个独立实例,每个实例拥有独立的计算、内存与带宽资源,隔离性强、故障隔离好,适合需要严格资源隔离的场景。vGPU 是虚拟化(VM)层面的 GPU 虚拟化,通过虚拟 GPU 驱动把 GPU 分配给多个虚拟机,隔离在中介虚拟化层面。Kubernetes 设备插件(device plugin)让 GPU 以可调度资源暴露给容器,配合时间切片(time-slicing)或 MIG 可支持多容器共享一张卡。在推理服务中,隔离与共享的取舍取决于需求:需要严格保障延迟与资源隔离时选 MIG 或独占 GPU;对吞吐优先、可容忍波动时用时间切片共享或 vGPU 提高利用率。通常用设备插件统一管理 GPU 的分配与共享,并在稳定性与利用率之间权衡。

隔离粒度由硬件到软件递减:MIG(硬件隔离)> vGPU(虚拟机隔离)> time-slicing(时间分片)。推理服务选择策略要平衡资源利用率与延迟/稳定性保障,规模较大时常用共享提升利用率、关键业务用独占或 MIG 保障。

#
★★

12. 统一内存(unified/managed memory)的页迁移机制,GPU 与 CPU 访问时页面如何迁移,与显式 cudaMemcpy 如何取舍?

请说明统一内存(managed memory)的页迁移机制,解释 GPU 与 CPU 访问时页面如何迁移,以及它与显式 cudaMemcpy 的取舍?

  • 理解 managed memory 的按需页迁移机制
  • 掌握显式拷贝与托管内存的取舍
  • 理解超订阅与页错误开销

统一内存(cudaMallocManaged)让 CPU 与 GPU 共享同一份虚拟地址空间,物理页面按需在两者之间迁移。当 GPU 访问尚未常驻的页面时,会触发页迁移(page migration),由驱动把页面从 CPU 内存搬到 GPU 显存;反之亦然。这种方式编程简单、无需手动管理哪个指针在哪个设备,但每次迁移都有缺页开销,且跨设备访问时若迁移频繁会导致性能下降。与显式 cudaMemcpy 相比,显式拷贝把数据搬移的时机和路径完全交由程序员控制,可以提前、批量、异步地搬移,避免运行期缺页,性能更可预测,但编程复杂度高。取舍原则:数据访问模式简单、可预测时用显式拷贝;开发迭代快、数据小或访问模糊时用 managed memory,但要注意性能敏感内核中避免频繁跨设备缺页。

统一内存的价值在易用性,代价是隐式迁移的不可控开销。高性能路径应显式用 cudaMemcpyAsync 或使用 pinned memory 加速,托管内存适合原型与低访存敏感场景。

#
★★

13. 树形归约(tree reduction)kernel 中 __syncthreads 的作用,为什么跨 block 归约必须分两阶段,漏掉同步会怎样?

请说明树形归约 kernel 中 __syncthreads 的作用,解释为什么跨 block 归约必须分两阶段,以及漏掉同步会产生什么后果?

  • 理解 __syncthreads 的 block 内同步语义
  • 掌握树形归约的阶段划分
  • 理解漏掉同步导致的数据竞争

树形归约在共享内存中分步累加,每一步把数据量减半,最终得到 block 的局部和。__syncthreads 用于保证同一 block 内所有线程到齐后再进入下一步,确保先写的共享内存数据被其他线程读取前已写入完成。由于 GPU 中不同 block 之间没有直接同步机制,也没有全局共享内存,因此"跨 block 归约"必须分两阶段:第一阶段每个 block 在自身共享内存中归约得到局部和,写回全局内存;第二阶段(通常由单独的 kernel 或一个 block)把各 block 的局部和再归约成最终结果。如果漏掉 __syncthreads,会出现同一 block 内不同 warp 进度不一致,导致某线程读取了下一次循环尚未写入的数据,产生数据竞争与错误结果,且该错误是竞态、难以复现的。

__syncthreads 只同步 block 内线程,不能跨 block。跨 block 归约必须拆成两阶段,否则无法保证各 block 的局部结果都就绪。漏同步会引发竞态,是调试困难的不确定性 bug。

#
★★

14. GPU CUDA ROCm SYCL interoperability 的 SIMT 执行模型与 CPU SIMD 在分支发散上的根本差异?

请比较 GPU 的 SIMT 执行模型与 CPU 的 SIMD 在分支发散处理上的根本差异?

  • 理解 SIMT 的线程级并行与 SIMD 的向量并行
  • 掌握分支发散在两种模型下的处理方式
  • 理解两者在掩码与调度上的差别

CPU 的 SIMD(如 SSE/AVX)是单条指令同时对多个向量通道(lane)数据操作,程序员显式管理向量宽度,分支通过掩码(predication)或标量 fallback 处理,且 CPU 有复杂的分支预测与乱序执行来掩盖分支代价。GPU 的 SIMT 则以 warp 内的多个线程为单位共享指令流,每个线程有自己的程序计数器与寄存器,分支发散时 GPU 会串行执行各路径并屏蔽不相关线程(predication/selective execution),没有 CPU 那样的分支预测器,因此发散代价直接反映为吞吐损失。根本差异在于:CPU SIMD 的并行度是固定且由程序员控制的向量宽度,分支代价小且有预测缓冲;GPU SIMT 的并行度来自成千上万线程的调度,分支发散会让同一 warp 内不同路径串行,导致吞吐下降。这也是 GPU 代码要尽量避免 warp 内发散而 CPU 对分支容忍度较高的原因。

两者的核心区别在于"指令流与数据流的对应关系"。SIMD 把向量宽度固定,分支靠 CPU 预测缓冲;SIMT 用线程组共享指令流,分支靠串行各路径,代价是吞吐。理解这点能指导写出对 GPU 友好的分支结构。

#
★★

15. GPU CUDA ROCm SYCL interoperability 的存储层次(Register → Shared → L1 → L2 → DRAM → HBM)在 AI 推理中的延迟梯度?

请说明 GPU 存储层次(Register → Shared → L1 → L2 → DRAM → HBM)在 AI 推理中的延迟梯度,以及如何据此优化?

  • 掌握各存储层次的延迟递增关系
  • 理解延迟梯度对推理优化的指导
  • 掌握数据复用与缓存利用策略

GPU 存储层次按延迟从低到高排列:寄存器(最快,单周期以内)→ Shared Memory(约 20-30 周期)→ L1 Cache(接近共享内存)→ L2 Cache(数十周期)→ DRAM/HBM(数百周期,最慢)。这构成一个清晰的延迟梯度:越靠近计算单元,容量越小、速度越快。在 AI 推理中,这个梯度指导优化:把反复使用的数据(如权重 tile、KV Cache 块)尽量上移到寄存器与共享内存;通过 tiling 让数据在共享内存复用,减少落到 L2/HBM 的访问;利用缓存局部性让热数据命中 L1/L2。FlashAttention 正是利用 SRAM(共享内存)容量小但快的特点,把分块数据放在片上,减少对 HBM 的读写。优化目标就是让访问尽量停留在高延迟梯度顶端的低延迟层。

延迟梯度决定优化方向:数据越热越要放在靠近计算的位置。推理中访存瓶颈主要来自 HBM,因此所有优化都围绕"把数据拿到片上、复用、减少 HBM 往返"。

#
★★

16. GPU CUDA ROCm SYCL interoperability 的 CUDA、ROCm、SYCL、OpenCL 在软件栈上的等价抽象与生态对比?

请比较 CUDA、ROCm、SYCL、OpenCL 在软件栈上的等价抽象及其生态差异?

  • 理解各异构编程模型的抽象层次
  • 掌握各模型的生态与厂商绑定
  • 理解可移植性与性能的权衡

CUDA 是 NVIDIA 专有的异构计算平台,提供 CUDA C 扩展、运行时/驱动 API、cuBLAS/cuDNN 等丰富库,性能与生态最成熟,但绑定 NVIDIA 硬件。ROCm 是 AMD 的对应平台,提供 HIP(可把 CUDA 代码翻译为 HIP,兼容层)、ROCm 库(rocBLAS/rocSparse)与编译器,目标是让 CUDA 代码可移植到 AMD。SYCL 是开放的、基于 C++ 的异构编程标准,通过单源 C++ 和队列抽象屏蔽设备差异,可移植到 NVIDIA/AMD/CPU 等,但深入性能优化需依赖厂商扩展。OpenCL 是最早的开放异构标准,抽象层次低、可移植性广,但开发效率低、难以获得与 CUDA 同等的深度优化。抽象的等价性上,四者都提供"kernel + 内存 + 队列/流"的核心抽象,但 CUDA 生态最完备、性能上限最高,SYCL/OpenCL 强调可移植、ROCm 绑定 AMD。选择取决于性能需求、目标硬件与生态成熟度。

四者共享"设备内核 + 内存管理 + 命令队列"的抽象,但 CUDA 生态最成熟、性能最好,SYCL 强调跨厂商可移植性。工程上常通过 HIP/SYCL 层做跨平台迁移,性能关键路径仍用厂商原生 API。

#

17. TPU(Google)与 Trainium(AWS)的非 NVIDIA 加速路线,在 LLM 训练与推理中的位置如何?

请说明 TPU(Google)与 Trainium(AWS)等非 NVIDIA 加速路线在 LLM 训练与推理中的定位?

  • 了解 TPU 与 Trainium 的架构特点
  • 理解其在 LLM 训练与推理中的优劣势
  • 掌握与 NVIDIA 生态的对比

TPU 是 Google 的专用矩阵加速芯片,采用脉动阵列(systolic array)架构,对矩阵乘等计算密集算子高度优化,配合稀疏核与超大片上内存,在 LLM 训练与推理中通过 XLA 编译栈发挥优势,大量用于 Google 内部(如 Gemini 与 PaLM)的训练。Trainium 是 AWS 的专用训练芯片,提供高性价比的训练算力,配合 Neuron SDK 与 PyTorch 集成,在 AWS 生态内用于大规模训练。二者的共同点是绕开 NVIDIA 的软硬件绑定,通过专用架构与自家编译栈(XLA/Neuron)获得性价比优势,但生态成熟度、算子覆盖与通用性不如 CUDA。它们的定位更多是"在特定云厂商生态内、为大规模训练/推理提供替代方案",而 NVIDIA 仍是通用 AI 计算的事实标准,尤其在算子与生产工具的完备性上。

TPU/Trainium 的竞争力来自专用架构与云厂商集成,弱点是生态与算子通用性。训练强、推理可选,但都依赖自家编译栈,迁移成本与定制深度是考量点。

#

18. FlashAttention 的 tiling 为什么能减少 HBM 读写,与 GPU 片上 SRAM 容量和分块大小的关系如何?

请说明 FlashAttention 的 tiling 为什么能减少 HBM 读写,以及它与片上 SRAM 容量和分块大小的关系?

  • 理解 FlashAttention 的 IO 优化动机
  • 掌握 tiling 减少 HBM 访问的原理
  • 理解分块大小与 SRAM 容量的约束

标准 Attention 会把 Q、K、V 和中间 S、P 矩阵全部写回 HBM,注意力分数矩阵 S(N×N)与概率 P 都需落地到 HBM 再读回,导致 HBM 读写量高达 O(N²)。FlashAttention 通过分块(tiling)把 Q、K、V 分块装入片上 SRAM(即共享内存),在片上完成 S 与 P 的计算,并用在线 softmax 算法(分块更新最大值与归一化系数)避免保存整个 S 矩阵。这样 HBM 读写量从 O(N²) 降到 O(N),只取决于 Q、K、V 的规模。分块大小受片上 SRAM 容量约束:块越大,越能减少 HBM 往返,但必须在 SRAM 容量内放得下 Q、K、V 块与中间结果;块太小则 HBM 重读次数增多。因此选择与 SRAM 容量匹配的块大小,是减少 HBM 访问的关键。

FlashAttention 的核心洞察是"把算法搬到片上内存做",用在线 softmax 避免中间结果落盘,从而把 IO 复杂度从 O(N²) 降到 O(N)。分块大小是 SRAM 容量与带宽权衡的体现。

#

19. 多卡通信拓扑,NVLink/NVSwitch/InfiniBand 对 All-Reduce 带宽与训练/推理扩展性的影响,通信占比如何估算?

请说明 NVLink/NVSwitch/InfiniBand 等多卡通信拓扑对 All-Reduce 带宽与训练/推理扩展性的影响,以及如何估算通信占比?

  • 理解 NVLink/NVSwitch/InfiniBand 的带宽量级
  • 掌握通信拓扑对通信时间的影响
  • 能估算通信占比判断扩展瓶颈

NVLink 是 GPU 板内/卡间高速互联(如 H100 900GB/s、B200 更高),NVSwitch 是机内交换机,把多卡互联成全互联拓扑,InfiniBand 是跨节点的高速网络(如 400Gbps/800Gbps)。All-Reduce 等集合通信的物理带宽决定了通信时间,而拓扑决定是否可以并行/分片通信。全互联拓扑(NVSwitch)让通信带宽高、拓扑简单,适合张量并行;跨节点用 InfiniBand 时带宽相对低,通信时间占比上升。通信占比可通过估算:假设每步通信量与模型大小、并行度相关,通信时间 = 数据量 / 有效带宽,计算时间 = 计算 FLOPs / 算力,二者比值即通信占比。当通信占比高时,扩展性下降(Amdahl 效应),需要优化通信(重叠、压缩、更好的拓扑)或调整并行策略。训练与推理的扩展性都受通信/计算比约束,通信占比越高,扩展效率越低。

通信占比是判断扩展性的关键指标。高带宽互联(NVSwitch/NVLink)降低通信占比,跨节点低带宽则放大通信时间。估算通信占比能指导选择并行策略与拓扑优化。

#

20. GPU 的 Grid/Block/Thread 并行层次与 warp 调度如何组织?

请说明 GPU 的并行层次 Grid/Block/Thread 与 warp 调度的关系?

  • 理解 Grid/Block/Thread 的层次结构
  • 理解 block 映射到 SM、warp 的调度单位
  • 理解组织层次对性能的影响

GPU 的并行组织分三层:Grid(网格)包含多个 Block(线程块),Block 包含多个 Thread(线程)。Launch 时指定 Grid 与 Block 的维度,硬件把 Block 分派到不同的 SM(流多处理器)上执行,一个 SM 可以同时承载多个 Block。在 SM 内部,线程再按 warp(通常 32 个线程)分组,warp 是硬件调度与执行的最小单位,SM 以 warp 为单位发射指令。这个层次结构决定了:Block 是软件上的调度单元(可映射到 SM),warp 是硬件上的执行单元;跨 block 不能直接同步,但可用原子操作或全局内存协作。合理划分 Block 大小与 Grid 大小能影响 SM 负载均衡、occupancy 与资源利用。理解层次结构是编写高效 CUDA kernel 的基础。

Grid/Block/Thread 是软件视角的层次,SM/warp 是硬件视角。Block 决定 SM 分配与资源占用,warp 决定执行粒度。层次划分影响负载均衡、occupancy 与同步范围。

#

21. GPU 内存层级中全局/共享/寄存器内存与带宽的关系?

请说明 GPU 全局内存、共享内存与寄存器的带宽与使用特点?

  • 理解各内存层级的带宽差异
  • 掌握各层级的使用场景
  • 理解带宽对 kernel 性能的影响

GPU 内存层级中,全局内存(HBM)带宽最大(可达 TB/s 级)但延迟最高、需合并访问;共享内存带宽高、延迟低,是 block 内线程共享数据的高效手段,但容量有限(每 SM 数百 KB)且存在 bank 冲突风险;寄存器带宽最高、延迟最低,但每个线程数量有限,是私有数据的最快存储。三者的带宽与容量成反比:寄存器最小最快,共享内存居中,全局内存最大最慢。优化时优先把高频复用的数据放到寄存器与共享内存,减少全局内存访问;全局内存访问要合并(coalesced)以利用带宽。理解各级带宽就能判断瓶颈:若数据在全局内存反复访问,即使带宽大,其延迟与流量也会拖慢 kernel,因此要尽量复用与上移。

带宽与容量的权衡是 GPU 内存优化的核心。寄存器留给私有中间量,共享内存复用 block 内数据,全局内存合并访问。合理安排数据层级能显著提升带宽利用率。

#

22. GPU CUDA ROCm SYCL interoperability 在光线追踪、矩阵运算(Tensor Core)、稀疏计算上的硬件卸载策略?

请说明 GPU 在光线追踪、矩阵运算(Tensor Core)、稀疏计算上与其它编程模型交互时的硬件卸载策略?

  • 理解专用硬件单元(RT Core、Tensor Core、稀疏单元)的卸载
  • 掌握不同 workload 的卸载收益
  • 理解与通用计算的配合

现代 GPU 集成了多种专用硬件单元,通过在 kernel 中调用对应指令/库把特定计算卸载到专用硬件:光线追踪由 RT Core(Ray Tracing Core)处理,通过专门的 BVH 遍历与交检测指令加速,避免通用计算消耗;矩阵运算由 Tensor Core 处理,通过 WMMA/MMA 指令以块为单位完成矩阵乘加,算力远超通用 CUDA 核心;稀疏计算由稀疏单元(如 NVIDIA 的 Sparse Tensor Core)通过稀疏矩阵描述(压缩的稀疏行/列)跳过零元素,减少无效计算。这些专用单元的卸载策略是:把计算密集的规则运算(矩阵乘)交给 Tensor Core,把几何密集的光线场景交给 RT Core,把含大量零的运算交给稀疏单元。在异构编程模型(CUDA/ROCm/SYCL)中,通过对应 API 或指令显式调用这些单元,实现硬件加速。卸载的核心收益是让专用单元与通用核心并行工作,提升整体吞吐。

硬件卸载把规则计算交给专用单元,通用核心做其余工作。RT Core 卸载光线追踪、Tensor Core 卸载矩阵乘、稀疏单元卸载稀疏运算,是各类异构 workload 提速的关键。

#

23. GPU CUDA ROCm SYCL interoperability 的 cudaGraph、stream priority、cudaMallocAsync 在推理中的延迟优化?

请说明 cudaGraph、stream priority、cudaMallocAsync 在推理中的延迟优化作用?

  • 理解 cudaGraph 减少 launch 开销
  • 理解 stream priority 的调度优先级
  • 理解 cudaMallocAsync 的异步内存管理

在推理延迟优化中:cudaGraph 通过捕获并回放整个计算图,减少逐 kernel launch 的 CPU 开销与启动延迟,让多个 kernel 连续、并行执行,适合固定结构推理图;stream priority 允许为不同流设置优先级,让关键 kernel(如关键路径上的计算)优先执行,减少低优先级 kernel 抢占导致的延迟波动;cudaMallocAsync 引入异步内存池,把内存分配/释放与计算流解耦,避免同步 malloc 阻塞,减少内存分配产生的延迟尖峰。三者结合,cudaGraph 降低启动开销、stream priority 保证关键路径优先、cudaMallocAsync 消除分配阻塞,共同把推理延迟压到更低且更稳定。

推理延迟优化是系统工程:启动开销(cudaGraph)、调度优先级(stream priority)、内存分配(cudaMallocAsync)都会带来延迟。组合这些机制能显著降低延迟均值与抖动。

#

24. GPU CUDA ROCm SYCL interoperability 在 MIG(Multi-Instance GPU)、MPS、Time-Slicing 上的资源分割能力?

请说明 GPU 在 MIG、MPS、Time-Slicing 三种资源分割机制上的能力差异?

  • 理解 MIG 的硬件级隔离
  • 理解 MPS 的进程级计算共享
  • 理解 Time-Slicing 的时间分片

MIG(Multi-Instance GPU)把一张 GPU 在硬件层面切分为多个独立实例,每个实例拥有独立的 SM、内存与带宽,隔离性与故障隔离最强,适合需要严格资源隔离的推理场景。MPS(Multi-Process Service)是进程级共享,让多个进程共享 GPU 的计算资源,通过并发提交减少上下文切换,但内存与带宽仍共享,可提升利用率但隔离性弱。Time-Slicing(时间分片)把 GPU 按时间片轮流分配给多个租户,实现简单、利用率提升,但无隔离,且切换会导致上下文切换开销与延迟抖动。三者的取舍:MIG 隔离最强、利用率略低;MPS 与 Time-Slicing 提高利用率但隔离弱。推理服务按业务需求选择:需要稳定延迟与隔离用 MIG,追求高利用率可容忍波动用 MPS/Time-Slicing。

资源分割的粒度与隔离强度从高到低:MIG(硬件实例)> MPS(进程虚拟共享)> Time-Slicing(时间分片)。选择取决于对隔离与利用率的权衡,生产推理常混合使用。