足下科技高性能计算一面凉经

《面试题目》

1. 场景题为主（原帖未记录具体题目，作者自评答得不好）。
2. 项目相关（问得很少，作者的项目均基于 Ampere 架构 GPU）。
3. 反问环节：面试官介绍了行业动态。

《参考解析》

这场面试透露出的岗位定位：原帖最关键的信息是面试官的判断——这个岗位不太需要做算子，更需要做更高层的优化。这对准备方向影响很大：写 CUDA kernel、调 tile/共享内存这一套属于算子级别的底层优化，而”更高层”通常指图级别与系统级别的优化，比如算子融合与图重写、内存复用与显存规划、量化与低比特推理、KV Cache 与批调度策略、多卡并行切分（TP/PP/EP）、以及端到端流水线编排。投这类岗位前，先看清 JD 里写的是 kernel 还是框架/图优化，两者的准备路径完全不同。

关于算子优化的复用性：原帖作者的观察很到位——算子优化的成果复用性强（一个高效的 GEMM/Attention kernel 全网都能用），也正因如此，主流框架和厂商已经把常见算子打磨得很充分，个人很难做出明显更快的版本。要在算子方向做出成绩，通常得绑定特定硬件特性或特定 shape 分布（比如极长序列的 Attention、MoE 的稀疏分组 GEMM、低比特 kernel），在通用算子上硬碰不太划算。这恰好解释了面试官为什么说”不需要做算子”。

场景题该怎么准备：既然面试以场景题为主，准备重点应该放在”给定模型和硬件，如何把吞吐/延迟做上去”这类问题上。答题框架建议固定为四步：①先算账——权重大小（参数量 × 位宽 / 8）、KV Cache 大小（2 × 层数 × kv 头数 × head_dim × 序列长 × batch × 位宽）、显存上限与带宽上限，先判断瓶颈是显存容量、显存带宽还是算力；②再定位——用 profiling（Nsight Systems/Compute）看时间花在 prefill 还是 decode、是 kernel 计算还是访存、有没有空闲气泡；③后开方——显存不够就量化权重/KV、用 PagedAttention 减少碎片、CPU offload；带宽受限就用算子融合和 FlashAttention 减少 HBM 往返；算力受限就上低比特 tensor core 或投机解码；④最后验证——给前后对比数据（吞吐、P99 延迟、显存占用、精度损失），没有数字的方案不算方案。

项目偏”玩具”怎么办：基于 Ampere 的个人项目在面试里被看轻很常见，补救思路不是换更贵的卡，而是把项目做出工程纵深：给出完整的性能分析报告（瓶颈定位过程、优化前后对比曲线）、做过多方案对比（不同 tile 大小/不同量化位宽/不同并行策略）、有端到端的真实约束（延迟预算、精度验收）。哪怕数据规模小，只要论证闭环、有量化结论，说服力就远高于”我跑通了一个 demo”。

给后续面试的建议：作者自评”处女面不紧张、面试官人挺好”，说明心态没问题，短板在场景题的答题结构。把上面四步框架练熟，再补一些推理引擎的实际参数（vLLM 的 --gpu-memory-utilization、--max-model-len、--enable-prefix-caching，TensorRT-LLM 的 max_batch_size、kv_cache_free_gpu_memory_fraction），这种岗位的面试就会顺很多。