企业官网建设流程全解析

1. 这不是“翻译”，而是一场从 Python 层到硅基电路的精密接力

你写完 PyTorch 模型，调用model(input)，几毫秒后拿到输出——这背后没有魔法，只有一条被精心设计、层层优化、环环相扣的指令流水线。它从你写的 Python 代码开始，经过 AST 解析、图构建、算子融合、内存布局重排、Kernel 生成、寄存器分配，最终变成 GPU 上千个 SM 单元同步执行的 warp-level 指令流。这条链路，就是 AI 编译器的全栈。

我做模型部署和推理加速六年，亲手调过从 Jetson Nano 到 A100 集群的上百个模型，也踩过torch.compile在不同 CUDA 版本下 fallback 到 eager mode 的坑。很多人把torch.compile当成一个“开关”，以为开了就自动变快；也有人把 Triton 当成“高级 CUDA”，觉得写几个 block 和 grid 就能搞定高性能 Kernel。这两种理解都漏掉了最关键的一环：编译器不是在“加速代码”，而是在重构计算的物理实现方式。它要回答的问题不是“怎么算得更快”，而是“在当前 GPU 架构上，什么数据布局、什么访存模式、什么并行粒度，能让 SM 的 ALU 和 Tensor Core 同时饱和？”

标题里“从 PyTorch 代码到 GPU 指令”这十个字，拆开看是技术路径，合起来看是工程哲学。PyTorch 代码是人类可读的抽象，GPU 指令是硬件可执行的原子操作，中间隔着的不是一层“编译”，而是五层以上深度耦合的转换：前端语义解析 → 中间表示（IR）构建 → 平台无关优化 → 硬件特化 lowering → 指令生成与调度。每一层都在做取舍：要不要牺牲一点灵活性换性能？能不能把两个小矩阵乘合并成一个大 GEMM？是否值得为特定显存带宽设计非对齐访存策略？这些决策，直接决定了你的模型在 A100 上是跑 80ms 还是 45ms，决定了 7B 模型能否在单卡 24G 显存上跑满 batch=4。

所以这篇不是教程，也不是 API 文档复述。它是我在 NVIDIA、AMD、昇腾三家芯片厂商的 SDK 支持团队驻场三个月，又在三个不同规模的推理服务项目中反复验证后，梳理出的真实生产环境中的编译器全栈逻辑图谱。你会看到torch.compile背后真正触发的 IR 变换节点，会明白为什么 Triton Kernel 里tl.dot的allow_tf32=True在 A100 上是默认开启但在 RTX 4090 上反而要手动关闭，会搞懂torch._inductor.config.triton.autotune里那个max_autotune_gemm=True实际上是在搜索多少种不同的分块（tiling）策略。所有内容，都来自实测日志、反汇编片段和 profiler 抓帧数据，不讲概念，只讲“这一行代码，最终在 GPU 上干了什么”。

2. 全栈拆解：五层转换如何决定你的模型速度上限

AI 编译器的“全栈”不是营销话术，它对应着五个物理上不可跳过的处理阶段。每个阶段都有明确的输入/输出、核心算法、失败退路和性能拐点。忽略其中任何一层，都会让你的优化努力打折扣——比如你花三天手写了一个 Triton Kernel，结果发现torch.compile根本没把它接进去，因为前端 IR 已经在 fusion 阶段把你的算子拆散了。

2.1 第一层：Python 前端解析与 FX 图捕获（不是“静态图”，而是“可塑图”）

torch.compile的起点不是.forward()方法，而是torch.fx.symbolic_trace对模型的符号化追踪。这里的关键在于：它捕获的是“可执行语义”，而非“源码结构”。举个例子：

def forward(self, x): a = x @ self.w1 b = torch.relu(a) c = b @ self.w2 return c + self.bias

FX tracer 不会原样保留这四行 Python，而是构建一个包含call_function、call_module、get_attr节点的有向无环图（DAG）。每个节点记录：

• 输入张量的 shape、dtype、device（注意：此时 device 是 symbolic 的，如cuda:0）
• 运算符的语义（如aten.add.Tensor）
• 参数绑定关系（self.w1被解析为get_attr节点指向model.w1）

提示：torch.compile默认使用backend="inductor"，这意味着 FX 图会被送入 TorchInductor 编译器。但你可以用torch.compile(model, backend="aot_eager")强制走 eager 模式，用于 debug 图结构——这是排查“为什么我的自定义算子没被编译”的第一招。

这个阶段的脆弱点在于动态控制流。FX tracer 对if/else、for循环的支持有限。例如：

for i in range(x.size(0)): # x.size(0) 是 runtime 值 y = y + self.layers[i](x)

这种写法会导致 tracer 失败或 fallback。解决方案不是改写成nn.Sequential，而是用torch.nn.utils.rnn.pack_padded_sequence或显式展开（unroll）循环——后者在 LLM 推理中很常见，比如 KV Cache 更新时的for循环必须 unroll 成固定步长。

实操心得：我在线上服务中遇到过一次诡异的 latency 波动，最后发现是某个分支里的len(list)调用被 tracer 当作常量捕获，导致图在不同 batch size 下复用错误的 shape。解决方法是在该位置插入torch._dynamo.mark_dynamic(x, 0)显式声明动态维度。

2.2 第二层：TorchInductor IR 构建与平台无关优化（真正的“大脑”）

FX 图只是起点，TorchInductor 的核心工作是将其转换为自己的中间表示（IR）——一种基于Lattice的、支持高阶函数和副作用的 SSA 形式。这个 IR 的关键特性是：它不假设任何硬件细节，只描述“计算应该发生什么”，不规定“在哪里发生”。

IR 构建后立即进行三类关键优化：

1. 算子融合（Operator Fusion）：把matmul + relu + matmul合并成一个fused_linear_relu_linear节点。这不是简单拼接，而是重新规划内存访问：避免中间结果写回 global memory，直接在 shared memory 或 register 中流转。
2. 内存布局重排（Layout Optimization）：将NCHW格式自动转为NHWC或NCHWc（channel-packed），以匹配 GPU 的访存对齐要求。实测显示，在 ResNet50 的 conv1 层，NCHWc比NCHW在 V100 上提升 12% 带宽利用率。
3. 常量折叠（Constant Folding）：提前计算torch.ones(1024) * 0.5这类表达式，减少 runtime 开销。

注意：这些优化是“安全”的——它们保证语义等价。但torch.compile的dynamic=True参数会放宽约束，允许在 runtime 重新编译不同 shape 的图，代价是首次运行延迟增加。线上服务必须权衡：dynamic=False更稳，dynamic=True更省显存。

一个典型失败案例：某客户模型在torch.compile后反而变慢 30%。profile 发现aten.convolution节点被拆成了 7 个独立 kernel，而不是预期的 fused conv+bn+relu。根因是 BN 层的running_mean和running_var在训练模式下是requires_grad=True，触发了 gradient 相关的 IR 分支，禁用了 fusion。解决方案：推理时显式调用model.eval()并model.requires_grad_(False)。

2.3 第三层：硬件特化 Lowering（从数学到硅片的第一次“落地”）

当 IR 准备就绪，编译器开始“选硬件”。torch.compile默认 target 是 CUDA，但它会根据torch.cuda.get_device_properties(0)返回的major和minor（如 A100 是 8.0，RTX 4090 是 8.9）选择不同的 lowering 策略：

Lowering 的核心任务是：把 IR 中的matmul映射到具体的 PTX 指令序列，并决定如何切分 workload。这里引入了“tiling”概念——把一个大矩阵乘分解成多个小块（tile），每个 tile 对应一个 warp 的工作单元。Tiling 策略直接影响：

• Shared memory 使用量（决定 occupancy）
• Register pressure（决定 warp 数量）
• L2 cache 命中率（决定访存延迟）

Triton 的价值就在此刻体现：它提供了一套比 CUDA C 更高层的 tiling 抽象。比如tl.dot(a, b, allow_tf32=True)这一行，编译器会生成：

• mma.sync.aligned.m16n8k16指令（A100）
• mma.sync.aligned.m16n8k8指令（4090）
• 自动插入cp.async预取（H100）

而如果你手写 CUDA，就得为每种架构维护三套 kernel 代码。这就是为什么torch.compile能“一次编写，多卡运行”。

2.4 第四层：Triton Kernel 生成与 Autotuning（性能的“临门一脚”）

Lowering 后，编译器调用 Triton 编译器生成.ptx文件。但关键一步是autotuning：它不是生成一个 kernel，而是生成几十甚至上百个变体，然后在真实 GPU 上 benchmark，选出最优者。

autotuning 的搜索空间包括：

• Block size：BLOCK_SIZE_M,BLOCK_SIZE_N,BLOCK_SIZE_K
• Warp size：num_warps=2/4/8
• Shared memory 使用量：num_stages=2/3/4
• 是否启用allow_tf32或fp8模式

以torch.nn.functional.linear为例，autotuning 会尝试：

• BLOCK_SIZE_M=64, BLOCK_SIZE_N=256, BLOCK_SIZE_K=32, num_warps=4
• BLOCK_SIZE_M=128, BLOCK_SIZE_N=128, BLOCK_SIZE_K=64, num_warps=8
• ... 共 36 种组合

然后在 GPU 上运行 100 次，取平均 latency。这个过程耗时，但只在首次编译时发生。后续相同 shape 的 tensor 会复用 cache。

实操心得：线上服务启动慢？不是torch.compile本身慢，而是 autotuning 在 warmup。解决方案：在服务启动后，用典型输入（如torch.randn(1, 512, 768)）主动触发 compile，再 load model。我们有个项目，warmup 阶段从 42s 降到 3.7s，靠的就是预热 +torch._inductor.config.compile_threads=16加速编译。

另一个坑：autotuning 依赖CUDA_VISIBLE_DEVICES。如果服务用docker run -e CUDA_VISIBLE_DEVICES=1启动，但 autotuning 时torch.cuda.device_count()返回 1，它就会在 device 0 上 benchmark，导致生成的 kernel 在 device 1 上性能暴跌。正确做法：在 autotune 前设置os.environ["CUDA_VISIBLE_DEVICES"] = "1"。

2.5 第五层：PTX 到 SASS 指令生成与调度（GPU 的“最终判决”）

生成的.ptx文件还不是最终指令。它要经过 NVIDIA 的ptxas汇编器，编译成 GPU 的原生指令集 SASS（Streaming ASSembly）。这一步由 driver 完成，用户不可见，但至关重要：

• ptxas会做 final register allocation，决定每个 warp 使用多少 registers
• 它会插入bar.sync指令确保 warp 内同步
• 它会根据 SM 的 compute capability 优化指令调度（instruction scheduling）

SASS 指令的效率，直接体现在nsight compute的 profiler 数据里。比如：

• sms__sass_thread_inst_executed_op_fadd_pred_on：实际执行的 FADD 指令数
• sms__inst_executed_op_fma_pred_on：FMA 指令数（比 FADD+FML 更高效）
• lts__t_sectors.op_read：L2 cache 读取 sector 数

一个经典案例：某模型在 A100 上sms__inst_executed_op_fma_pred_on占比仅 62%，说明大量计算没走 FMA。分析 SASS 反汇编发现，tl.dot的allow_tf32=True被忽略了，因为输入 tensor 是torch.float32。解决方案：显式 castx = x.to(torch.bfloat16)，让编译器强制走 TF32 path。

3. 关键技术点深挖：torch.compile 与 Triton 如何协同作战

torch.compile和 Triton 不是“谁包含谁”的关系，而是松耦合的协作关系。理解它们的接口边界，才能避免“写了 Triton Kernel 却没被调用”的尴尬。

3.1 torch.compile 的 backend 机制：Inductor 是如何“召唤”Triton 的？

torch.compile的backend参数本质是一个 callable，接收 FX Graph，返回一个可执行的CompiledFunction。"inductor"backend 的内部流程是：

1. graph_module→torch._inductor.compile_fx(graph_module, example_inputs)
2. compile_fx调用torch._inductor.codegen.cpp_builder生成 C++ wrapper
3. C++ wrapper 中嵌入torch._inductor.codegen.triton生成的.so文件
4. .so文件由 Triton 编译器生成，包含kernel_0,kernel_1等函数指针

关键点在于：Triton Kernel 只负责“计算密集型算子”，不负责“控制流”。比如一个for循环调用 10 次tl.dot，torch.compile会生成一个 C++ loop，每次 call Triton kernel；而不会把整个 loop 编译进 Triton。

验证方法：设置TORCHINDUCTOR_DUMP_CODE=1，编译后会在/tmp/torchinductor_*目录下生成：

• debug/dump_fx_graph.txt：FX 图
• debug/dump_reshaped_graph.txt：IR 图
• debug/dump_triton_code.py：生成的 Triton kernel 源码

打开dump_triton_code.py，你会看到类似：

@triton.jit def kernel_0( in_ptr0, in_ptr1, out_ptr0, xnumel, rnumel, XBLOCK: tl.constexpr, RBLOCK: tl.constexpr, ): # ... 200 行 Triton 代码

这就是torch.compile最终交给 Triton 的“作业”。

3.2 Triton Kernel 的编写规范：何时该自己写，何时该信任 Inductor？

Triton 不是万能的。Inductor 自动生成的 kernel 在通用场景下足够好，但在以下情况，手写 Triton 是唯一选择：

• 特殊内存模式：比如需要__ldg（cached read）或__stwb（write-back）指令，Inductor 不支持。
• 非标准数据类型：如int4量化权重，Inductor 的quantized_matmul还不成熟。
• 极致访存优化：比如用tl.load的cache_modifier="wt"绕过 L1 cache，直接写 L2。

手写 Triton 的黄金法则：

1. 永远从tl.dot开始：不要重写 GEMM，先用tl.dot，再 profile 瓶颈。
2. 用tl.debug_barrier()定位 warp divergence：在可疑位置插入，看是否所有 warp 都执行到。
3. 检查tl.store的 alignment：未对齐的 store 会导致 3x 性能下降。用tl.arange(0, BLOCK_SIZE)+mask保证安全。

一个真实案例：某语音模型的conv1d层在 Inductor 下 latency 18ms，手写 Triton 后降到 9.2ms。差异在于：Inductor 用torch.conv1d的通用实现，而手写 kernel 把 input channel 拆成BLOCK_SIZE=64的 tile，用tl.load一次性加载 64 个 channel，完美匹配 A100 的 L1 cache line（128 bytes）。

3.3 Autotuning 的实战配置：如何让编译器为你打工

torch._inductor.config是性能调优的总开关。关键参数：

最有效的组合是：

import torch torch._inductor.config.max_autotune = True torch._inductor.config.max_autotune_gemm = True torch._inductor.config.compile_threads = 32 torch._inductor.config.triton.autotune = True # 避免 autotuning 时占用过多显存 torch._inductor.config.triton.cudagraphs = True

cudagraphs=True是关键：它让 autotuning 在 CUDA Graph 中运行，避免 context switch 开销，提速 3-5x。

3.4 CUDA 版本与 PyTorch 的隐式绑定：为什么你的 2.1.0 不能跑 CUDA 12.3？

PyTorch 的 wheel 包是预编译的，它捆绑了特定版本的 CUDA toolkit。比如torch-2.1.0+cu118表示：

• PyTorch C++ backend 编译时链接了 CUDA 11.8 的libcudart.so
• 它调用的cublas、cudnn版本也锁定在 11.8 生态

如果你强行用CUDA_HOME=/usr/local/cuda-12.3，会发生：

• libcudart.so.12找不到，报错lib not found
• 即使 LD_LIBRARY_PATH 修复，cudnn的 ABI 不兼容，kernel launch 失败

正确做法：PyTorch 版本与 CUDA toolkit 版本必须严格匹配。查表方法：

• pip show torch→ 看Version和Summary中的+cuXXX
• nvcc --version→ 看 CUDA 版本
• 对照 PyTorch 官网 的 wheel 表

常见陷阱：Ubuntu 22.04 默认apt install nvidia-cuda-toolkit安装的是 CUDA 11.8，但你想用 CUDA 12.x。解决方案不是升级 toolkit，而是用conda install pytorch torchvision torchaudio pytorch-cuda=12.1 -c pytorch -c nvidia，conda 会自动解决依赖。

4. 实操全流程：从零部署一个编译优化的 LLaMA-7B

理论说完，来个完整实操。目标：在单卡 A100-40G 上，用torch.compile+ Triton 加速 LLaMA-7B 的推理，达到 45 tokens/sec。

4.1 环境准备：避开 90% 的安装坑

不要用pip install torch。按以下顺序：

1. 驱动与 CUDA：

   # 检查驱动 nvidia-smi # 必须 >= 515.65.01（A100 支持） # 安装 CUDA toolkit 11.8（PyTorch 2.1.0 官方支持） wget https://developer.download.nvidia.com/compute/cuda/11.8.0/local_installers/cuda_11.8.0_520.61.05_linux.run sudo sh cuda_11.8.0_520.61.05_linux.run --silent --no-opengl-libs export PATH=/usr/local/cuda-11.8/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH

2. PyTorch 与 Triton：

   # 安装匹配的 PyTorch pip3 install torch==2.1.0+cu118 torchvision==0.16.0+cu118 --extra-index-url https://download.pytorch.org/whl/cu118 # Triton 必须 >= 2.2.0（支持 autotuning） pip3 install triton==2.2.0

3. 验证基础功能：

   import torch print(torch.__version__) # 2.1.0+cu118 print(torch.cuda.is_available()) # True print(torch.cuda.get_device_properties(0)) # major=8, minor=0

注意：Manjaro 用户常遇到nvidia-uvm模块未加载。解决：sudo modprobe nvidia-uvm，并加到/etc/modules。

4.2 模型加载与编译：参数与时机的精细控制

LLaMA-7B 的forward有大量torch.bmm和torch.softmax，是torch.compile的最佳场景。

import torch from transformers import AutoModelForCausalLM, AutoTokenizer model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-chat-hf", torch_dtype=torch.float16, device_map="auto") tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-chat-hf") # 关键：编译前必须完成 device_map，否则会 fallback model = model.eval() model.requires_grad_(False) # 编译！注意：只编译 model.forward，不编译 tokenizer compiled_model = torch.compile( model, mode="max-autotune", # 启用 full autotuning fullgraph=True, # 禁止 dynamic shape fallback dynamic=False # shape 固定，提升稳定性 ) # Warmup：用典型输入触发编译 input_ids = tokenizer("Hello, how are you?", return_tensors="pt").input_ids.to("cuda") with torch.no_grad(): _ = compiled_model(input_ids)

mode="max-autotune"是核心。它等价于：

torch._inductor.config.max_autotune = True torch._inductor.config.max_autotune_gemm = True

4.3 性能对比与 Profiler 分析：看见“快”在哪里

用torch.profiler对比 eager 和 compiled：

# Eager mode with torch.no_grad(): with torch.profiler.profile(activities=[torch.profiler.ProfilerActivity.CUDA]) as prof: _ = model(input_ids) print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10)) # Compiled mode with torch.no_grad(): with torch.profiler.profile(activities=[torch.profiler.ProfilerActivity.CUDA]) as prof: _ = compiled_model(input_ids) print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10))

典型结果：

flash_attention的大幅下降，是因为torch.compile把q,k,v的 reshape + transpose 融合成一个 kernel，避免了三次 global memory 访问。

4.4 显存优化：ComfyUI Multigpu 方案的底层原理

comfyui-multigpu的本质是Tensor Parallelism + Inductor 的跨设备 IR 优化。它不是简单地model.to("cuda:0")和model.to("cuda:1")，而是：

1. 用torch.distributed初始化 process group
2. 修改模型的forward，把nn.Linear的 weight 按列 split 到多个 GPU
3. torch.compile捕获 split 后的图，生成跨 GPU 的 NCCL all-reduce kernel

关键代码：

# 在 Linear 层插入 all-reduce class TPLinear(nn.Linear): def forward(self, x): x = super().forward(x) # local compute if self.tp_size > 1: dist.all_reduce(x, op=dist.ReduceOp.SUM) # 同步结果 return x

torch.compile会识别dist.all_reduce调用，并在 lowering 阶段插入ncclAllReducePTX 指令。这比手动写 CUDA NCCL wrapper 更安全，因为编译器知道 tensor 的 layout 和 device。

5. 常见问题与避坑指南：那些文档里不会写的真相

5.1 “为什么我的模型 compile 后反而变慢？”——五大高频原因

一个血泪教训：某金融模型用torch.fft做时序分析，torch.compile直接 crash。我们试了torch._dynamo.disable()，但发现 disable 后整个模型都没 compile。最终方案：把fft部分提取成独立函数，@torch._dynamo.disable，其余部分正常 compile。这样 80% 的计算被加速，FFT 部分保持原生速度。

5.2 Triton 安装失败的终极解法

pip install triton失败的 90% 情况是 GCC 版本不匹配。Triton 需要 GCC >= 11。

# Ubuntu 20.04 默认 GCC 9.4，升级 sudo apt update sudo apt install software-properties-common sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt update sudo apt install gcc-11 g++-11 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 100 --slave /usr/bin/g++ g++ /usr/bin/g++-11 # 验证 gcc --version # 必须 11.x # 再安装 pip install triton==2.2.0

CentOS 7 用户更惨：默认 GCC 4.8。必须用devtoolset-11：

sudo yum install centos-release-scl sudo yum install devtoolset-11 scl enable devtoolset-11 bash pip install triton==2.2.0

5.3 GPU 服务器运维的硬核监控：不只是nvidia-smi

nvidia-smi只能看到 utilization 和 memory，但真正的瓶颈在：

• SM Utilization：nvidia-smi dmon -s u，看sm__inst_executed_op_fma_pred_on占比
• L2 Cache Hit Rate：nvidia-smi dmon -s m，lts__t_sectors.op_readvslts__t_sectors.op_read_hit
• PCIe Bandwidth：nvidia-smi dmon -s b，pvi__throughput如果接近 32GB/s（PCIe 4.0 x16），说明 host-to-device 传输是瓶颈

一个线上故障：模型 latency 突然翻倍，nvidia-smi显示 GPU util 95%，但dmon -s u显示sm__inst_executed_op_fma_pred_on仅 15%。深入看dmon -s m，lts__t_sectors.op_read_hit为 0% —— L2 cache 全 miss！根因是torch.compile生成的 kernel 用了太大的BLOCK_SIZE_K，导致 shared memory 不足，数据全走 global memory。解决方案：torch._inductor.config.triton.dense_indexing=True强制小块 tiling。

5.4 PyTorch 环境搭建的“降级哲学”

很多工程师迷信“最新版”，但生产环境要信奉“降级哲学”：

• PyTorch：选 LTS 版本（如 2.0.1），不是 2.3.0
• CUDA：选 PyTorch 官方 wheel 支持的版本（如 cu118），不是 cu123
• Triton：选稳定 release（2.2.0），不是 nightly

理由：LTS 版本经过大规模验证，bug 更少。我们有个项目，从 PyTorch 2.2.0 降级到 2.0.1，torch.compile的 fallback 率从 12% 降到 0.3%，因为 2.2.0 的 dynamo frontend 对某些 control flow 有 regression。

降级命令：

pip uninstall torch torchvision torchaudio pip install torch==2.0.1+cu118 torchvision==0.15.2+cu118 --extra-index-url https://download.pytorch.org/whl/cu118

5.5 视频模型双 GPU 的真相：不是“越多越好”

video-model-dual-gpu的常见误区是认为“两卡=两倍速度”。实际上：

• 如果模型是nn.DataParallel，第二卡 util 通常 < 20%，因为 gradient sync 是瓶颈
• 正确方案是FSDP（Fully Sharded Data Parallel）或DeepSpeed，它们把模型参数 shard 到多卡
• torch.compile对 FSDP 的支持在 2.1.0+ 才完善，必须用FSDP(..., use_orig_params=True)

验证双卡效率：

# 启动时加 export CUDA_VISIBLE_DEVICES=0,1 # 在代码中 model = FSDP(model, use_orig_params=True) compiled_model = torch.compile(model, mode="max-autotune") # 看 nvidia-smi，两卡 util 应该都 > 70%

如果卡0 util 85%，卡1 util 30%，说明 FSDP 配置错误，参数没 shard 好。

6. 我的实操体会：编译器不是黑箱，而是可调试的精密仪器

做了六年模型部署，我最大的体会是：AI 编译器正在从“工具”变成“伙伴”。早期我们调模型，靠的是手工 kernel、手写 CUDA、反复改 block size；现在，torch.compile把这些经验编码进了 autotuning 算法里。它比人更擅长搜索 tiling 空间，比人更懂 GPU 的寄存器文件大小。

但伙伴不是神。它需要你给清晰的指令：fullgraph=True告诉它“别怕，shape 固