4. GPU与硬件加速高频问题
模型Serving工程师的面试中，GPU与硬件加速是区分“会调库”和“懂系统”的分水岭。面试官通常不会只问“CUDA是什么”，而是通过显存、算子、多卡三条线，判断你是否具备把模型真正压进生产环境的能力。本章给出回答框架、追问路径与公司侧重点。
一、核心原理：CUDA、显存与算子的底层关系
CUDA的核心是“主机-设备”异构模型：CPU负责调度与逻辑控制，GPU通过大量线程并行执行计算。面试中要能讲清Grid、Block、Thread的层级，以及Warp是调度最小单位。显存管理则围绕“分配-使用-释放”展开，推理场景中显存被权重、KV Cache、激活值和临时缓冲区共同占用。算子优化本质是减少访存、提高计算密度，让Kernel更接近GPU的算力上限。
一句话回答模板：“CUDA决定并行粒度，显存决定能跑多大模型，算子决定单步延迟，多卡决定吞吐上限。四者共同决定Serving的QPS与成本。”
二、方法流程：显存与算子优化的排查路径
遇到OOM或延迟抖动时，建议按以下流程回答，体现工程化思维：
- 现象确认：是启动即OOM，还是运行中增长？是单卡还是多卡？
- 指标采集：用nvidia-smi、torch.cuda.memory_summary、Nsight Systems定位。
- 归因分析：区分权重、KV Cache、碎片、临时Buffer。
- 方案选择：量化、PagedAttention、显存池、算子融合。
- 验证回归：对比QPS、P99、显存峰值与精度损失。
# 常用排查命令
nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv
python -c "import torch; print(torch.cuda.memory_summary())"
nsys profile --stats=true python serve.py三、案例场景：多卡推理的三种策略
多卡推理是高频追问点。面试官想确认你是否理解Tensor Parallel、Pipeline Parallel和Data Parallel的适用边界。以下清单可直接作为回答骨架：
| 策略 | 切分维度 | 适用场景 | 主要瓶颈 |
|---|---|---|---|
| 数据并行 | Batch | 小模型高吞吐 | 梯度/权重同步 |
| 张量并行 | 层内矩阵 | 大模型单层放不下 | NCCL通信频繁 |
| 流水并行 | 层间 | 超深模型 | 气泡与负载不均 |
加分表达：“多卡推理不是简单加卡，而是通信与计算的权衡。张量并行降低单卡显存，但引入All-Reduce；流水并行减少通信，但产生气泡。实际Serving常采用TP+PP混合，并用Continuous Batching提升利用率。”
四、误区与复盘：面试中容易踩的坑
误区一：只背概念，说不出显存占用公式。应能估算：权重 + KV Cache + 激活 + 碎片。
误区二：把算子优化等同于“用TensorRT”。要能讲清融合、量化、内存对齐的具体收益。
误区三：多卡只谈DataParallel。要能对比TP/PP/DP的通信模式与扩展效率。
复盘时建议准备一个真实项目：例如“通过PagedAttention将KV Cache碎片降低40%，P99从800ms降到350ms”。用数据收尾，比堆砌术语更有说服力。公司侧重点上，大厂关注Nsight指标与NCCL调优，创业公司关注单位成本下的QPS和快速上线能力。
掌握本章框架后，面对CUDA、显存、算子、多卡四类问题，都能用“原理-流程-案例-复盘”的结构稳定输出，既展示深度，也体现Serving工程师的系统视角。