岗位写“推理优化”，怎么判断它是不是真做算子融合这类底层工作？

一份公开教程提到，它把计算描述为操作图，让 cuDNN 选择引擎来运行，再由使用者自己控制这一选择；构建流程是 validate、build operation graph、create execution plans、check support、build plans 五步，然后针对指针的 variant pack 执行。这条线索对求职者的价值在于：它把“底层性能工作”拆成了可辨认的动作，而不是一句“熟悉推理框架”。

读岗位描述时，可以先找这些具体词：算子融合、引擎选择、执行计划构建、自动调优、plan 序列化与复用、动态形状、CUDA graph capture。如果通篇只写“熟悉 TensorRT/ONNX”“会调 batch size”，那更可能是框架调参或工程集成。两者都需要人，但日常问题不同：前者要回答“为什么这个配置更快”，后者更多是“怎么把模型跑起来”。

面试时问什么，能区分“底层性能工作”和“框架调参工作”？

可以问团队最近一次性能提升是怎么定位的：是换了引擎配置，还是自己构建了执行计划？教程内容从单个融合卷积推进到跨引擎配置的自动调优、FP8 风格 epilogue、attention、plan 序列化、动态形状和 CUDA graph capture，这条递进线本身就是很好的提问素材。

假设场景：面试官说“我们做推理加速”。你可以追问，团队是否自己维护算子融合规则，是否做跨引擎配置的自动调优，是否处理 plan 序列化以跳过进程启动时的编译开销。如果对方回答集中在“调框架参数、换版本、加显存”，那这份工作离底层还有距离。反过来，如果对方能讲清执行计划怎么建、怎么复用，说明你更可能接触到性能核心。 延伸阅读：明汯投资2026暑期实习：STEM专业必看，AI+量化硬核岗值不值得投？

注意，这只是判断思路，不是对某家公司岗位的断言。原文并未说明这些技术在实际公司中的招聘需求或团队分工，也没有岗位数量变化的信息。

想往这个方向准备，先学什么、不学什么？

优先理解图构建、引擎选择、自动调优和 plan 复用这条主线。教程提到，把已构建的 matmul 图序列化为字节，重新加载到新的图对象，并通过整数 UID 执行，从而在进程启动时跳过编译开销——这类“构建一次、复用多次”的思路，比背某个框架的 API 参数更接近底层性能工作的日常。

取舍上，如果你目标是底层性能岗，先把张量维度与 stride、操作图、执行计划这些概念弄熟；如果目标是框架调参岗，先把模型部署链路和常见瓶颈跑通。两者不必对立，但准备顺序不同。

一个实际可做的小建议：挑一个你熟悉的模型，试着用“操作图—引擎选择—执行计划”的语言，向自己解释一次它为什么快或慢。说不清的地方，就是你面试前最该补的那块。