2024 大模型与编译器技术秋招面试题解析
前言
随着大模型技术的快速发展,底层系统、编译器优化及架构设计成为面试中的高频考点。本文整理了一些近期涉及 Triton、MLIR、LLM 推理优化及 GPU 架构的面试问题,并结合技术背景进行补充解析,旨在帮助读者建立更系统的知识体系。
Triton 相关
1. Triton Kernel 优化方法
Triton 作为 OpenAI 推出的 DSL,旨在简化 GPU 算子开发。优化通常分为两个阶段:
- 浅层优化:通过替换低效算子、使用 atomic op 合并 Kernel、拆分循环、调整 Config(如 Block Size)等方式实现初步性能提升。大部分情况下,完成这一步后性能已接近原生算子库。
- 深层优化:当浅层优化不足时,需分析下降后的 IR(Intermediate Representation),使用性能分析工具(如 Nsight Systems/Compute)对照算子库实现。重点检查访存是否连续、生成的汇编指令是否符合预期。若仍无法达标,可参考开源算子库的实现启发编译器的 lowering 过程,或在 IR 下降过程中添加 Pattern 优化。
2. Triton 下降流程与 Layout 理解
官方定义的下降流程为:triton-lang -> triton ir -> triton gpu dialect -> llvmir (nvvm ir) -> ptx -> sass。
其中 llvmir 更准确的说法是 nvvm ir,相比标准 LLVM IR 额外扩展了硬件 Intrinsic 和 Conversion。PTX 后续会根据硬件信息转为 SASS。
Layout 机制:在 triton gpu dialect 中首次出现,用于辅助 Op 的 Conversion 和 Transform。
- Distributed Layout:描述 Tensor 如何被 Thread 访问。包括 Block Layout、MMA Layout 和 DotOperand Layout。Block Layout 利用 AxisInfoAnalysis 获取 Load/Store 指针操作的 Tensor 形状及连续性信息,用于 Memory-Coalesce(访存合并)。MMA/DotOperand Layout 指导特定 Op 的 Operand 数据布局。
- Shared Layout:描述 Shared Memory 中可能被同时访问的数据。Shared Memory 按 Bank 组织,同一时间多个 Thread 访问同一 Bank 会产生 Bank Conflict,导致吞吐异常。通过 Layout-Swizzling 调整数据排布以避免冲突。
此外,寒武纪开源的 triton-linalg 展示了其他 DSA(ASIC)接入 Triton 的路径:triton-lang -> triton ir -> linalg dialect -> hardware dialect -> llvm ir -> ... -> hardware assembly。这种架构将硬件无关的 Dialect 与硬件抽象隔离,便于在不同架构上复用优化逻辑。
3. 支持 Triton 的好处及差异
好处:用户可方便地自定义 Kernel,迁移成本低;开发人员可构建算子库或特定加速库,许多框架已集成 Triton Kernel 实现。
差异:从 TTIR 开始分叉,不依赖官方的 TTGIR 后续优化 Pass,本质上更贴近 SPMD 编程范式,部分原语有独立映射。优化 IR 根据特定硬件特性定制。
MLIR 相关
1. MLIR Codegen 适合的任务类型
Codegen 路径更适合访存密集型任务。相较于解释执行,Codegen 能更好地调整数据的 Memory 层次,优化不同 Memory Space 之间的 Data Flow,从而降低延迟并提高吞吐量。
2. SIMD 与 SIMT 优化的异同
- SIMD:核心优化 Latency。要求访存连续,使用连续指令(非 Strided/Scalar)。常见优化包括 Tile 并行执行、Core 间利用 SMEM 交换数据、Core 内循环展开做软流水、Core 间异步以减少访存延迟。


