从 AVX/AMX 到 Tensor Core：CPU 工程师理解 LLM 量化

一句话抓住本质

如果你做过 CPU 性能优化，可以先把 LLM 量化理解为：

先用 Scale 把数值变成更窄的 operand，再按硬件要求打包成 tile，送入低精度矩阵乘单元，用更宽的类型累加，最后用 profiler 证明实际走了这条路径。

CPU 与 GPU 的数学没有换一套。真正变化的是并行规模、存储层次、支持的低精度格式，以及运行时如何选择 Kernel。

1. 先迁移这六个 CPU 心智模型

CPU 里熟悉的概念	量化/GPU 中对应的问题	可以迁移的直觉	不能直接画等号
INT8、定点数、饱和与舍入	Quantize、Scale、zero-point	有限编码必须覆盖原始数值范围	FP8/FP4 是非均匀浮点编码，不是小号 INT
AVX-512 VNNI、AMX Tile	Tensor Core MMA/GEMM	专用指令只有在 operand、layout、shape 合同时才生效	AMX 属于 CPU core，Tensor Core 属于 GPU SM 的并行执行体系
INT8 点积后 INT32 累加	W4A8、Acc=FP32/INT32	输入精度和累加精度必须分开描述	W4A8 本身不说明 accumulator
Cache Line、alignment、packing	group/block Scale、tensor layout	数据布局会决定 load 和计算效率	Block 是数值共享 Scale 的范围，不是硬件 Cache Line
Memory Wall、Roofline	Decode 权重/HBM 带宽瓶颈	先算 bytes，再判断瓶颈是否在带宽	GPU 的 HBM/L2/Shared Memory 不是 CPU DRAM/LLC/L1 的简单改名
perf、PMU、IBS	GPU trace、Kernel dtype、HBM counter	声明的配置必须由运行证据确认	两边的事件语义、采样机制和并行归因不同

下面按这六个锚点展开。

2. Scale 就是你熟悉的“表示范围合同”

CPU 上做定点数或 INT8 推理时，核心动作是把连续数值映射到有限整数集合。对称量化可写成：

$$q = \operatorname{clip}\left(\operatorname{round}\left(\frac{x}{s}\right), q_{\min}, q_{\max}\right), \qquad \hat{x} = s \cdot q$$

从 CPU 视角看：

• q 类似实际进入向量/矩阵指令的窄类型 operand；
• s 是窄类型编码与原始数值范围之间的合同；
• clip 对应超出表示范围后的饱和；
• rounding 与 saturation 共同产生量化误差；
• zero-point 只属于部分非对称整数方案，不是所有量化格式都有。

GPU 上的 FP8/FP4 仍然需要回答同一个问题：如何让有限编码覆盖张量分布。区别是 FP 格式的值分布不均匀，并且可能使用 current、delayed 或 block scaling。

因此最稳定的理解不是“FP8 比 INT8 高级”，而是：

value format 决定有哪些离散值
+ Scale 决定这些值覆盖哪段真实范围
+ granularity 决定多少元素共享一把尺子

3. VNNI、AMX 和 Tensor Core 都在做什么

3.1 从标量、向量到 Tile

执行方式	数据组织	典型工作
标量 ALU	单个或少量寄存器值	普通算术、控制与尾部处理
AVX-512 VNNI	一维 SIMD 向量	把多步 INT8 multiply-add 合并为点积累加
Intel AMX	二维 Tile register	让 TMUL 对 tile 执行矩阵乘累加
NVIDIA Tensor Core	GPU 矩阵 fragment/tile	在大量并行线程协作下执行低精度 MMA

Intel 官方资料给出的经典 AMX 合同是：

INT8 × INT8 → INT32 accumulate
BF16 × BF16 → FP32 accumulate

这和 GPU 的关键共性是：窄类型主要用于输入与乘法吞吐，累加通常使用更宽的类型保护数值稳定性。

GPU 上则必须按具体架构和 Kernel 核对：

(operand A dtype,
 operand B dtype,
 accumulator dtype,
 output dtype,
 tile shape,
 scale layout)
→ executed Tensor Core path

所以 W4A8 类似 CPU 代码里只告诉你两个输入的类型，却没有告诉你使用哪条 instruction、如何 packing、累加到哪里，以及尾部是否 fallback。

3.2 Checkpoint 与 ISA binary 是同一类边界

CPU 工程师不会因为源码里出现 int8_t 就断言机器一定执行了 VNNI/AMX；还会检查：

• 编译器是否向量化；
• CPU feature 是否开启；
• oneDNN/OpenVINO 选择了什么 primitive；
• layout、shape 和 tail 是否让专用路径生效；
• 热点里是否仍是 unpack、reorder 或普通指令。

GPU 量化完全一样：

• Checkpoint 写着 FP4，不代表执行了 FP4 Tensor Core；
• Engine 可能重打包、cast、dequant、pre-expand、fallback 或拒绝；
• 只有加载日志、显存回读和 Kernel trace 能证明最终路径。

4. Cache Line 与 Block Scale：可以类比，但不是一回事

二者的共同点是都在定义“一个管理单元”：

• Cache Line 定义内存层次搬运和一致性的基本数据块；
• quant block/group 定义多少个低精度值共享一个 Scale。

但它们解决的是不同问题：

维度	Cache Line	Quant block/group
控制对象	存储层次的数据搬运与命中	数值范围与量化误差
典型单位	byte-addressed hardware block	tensor 某一维的连续元素组
元数据	tag、valid、coherence state	Scale、可选 zero-point
主要代价	miss、带宽浪费、false sharing	Scale 开销、padding、Q/DQ 与 Kernel 限制

它们会在 Kernel 中相遇：如果 block layout 让 Scale 和 packed value 访问不连续，最终仍会表现为低 load efficiency、额外事务或更多转换。

5. Memory Wall：CPU 的公式可以直接迁移

CPU 上你会用工作集大小、Cache miss 和 DRAM 带宽估算下限。GPU Decode 也可以先写：

$$T_{\mathrm{weight}} \gtrsim \frac{ \text{weight payload} + \text{Scale metadata} + \text{padding} }{ \text{effective HBM bandwidth} }$$

从 BF16 降到 4 bit，只能先推出裸权重 payload 下降；不能直接推出 TPOT 改善 4 倍，因为端到端还包含：

$$T_{\mathrm{e2e}} = T_{\mathrm{weight}} + T_{\mathrm{KV}} + T_{\mathrm{Q/DQ}} + T_{\mathrm{compute}} + T_{\mathrm{communication}} + T_{\mathrm{schedule}}$$

这和 CPU 上“结构体缩小 4 倍，不代表程序快 4 倍”是同一个道理：瓶颈可能转移，新增 unpack、分支、尾部处理和访存不连续也会吃掉收益。

6. 从 perf/IBS 迁移到 GPU Trace

不要背 GPU 工具名字，先沿用你熟悉的证据问题：

要证明什么	CPU 常用证据	GPU 对应证据
是否执行目标低精度指令	disassembly、PMU、library verbose	Kernel 名、operand dtype、engine log
是否受内存墙限制	LLC miss、DRAM BW、stall、IBS load latency	HBM throughput、L2、memory/SOL、Kernel timeline
layout 是否低效	split load、unaligned、Cache miss	transaction efficiency、cast/reorder、短 Kernel
是否发生 fallback	scalar tail、generic primitive	高精度替代 Kernel、Q/DQ、pre-expand
端到端是否受益	cycles/request、QPS、P95	TTFT、TPOT、TPS/TPM、成本

证据顺序也一样：

1. 固定 workload 和软件版本。
2. 确认实际执行路径。
3. 判断 compute、memory 还是调度瓶颈。
4. 对比相同 Case 的端到端指标。
5. 质量、容量和性能分别下结论。

7. CPU 工程师的最短学习路径

建议按以下顺序读，不需要先补完整 CUDA：

1. Scale 与量化误差：先稳住数值表示。
2. W/A/Acc/Out：像读 ISA operand 一样读精度合同。
3. AMX → Tensor Core：理解 tile 矩阵乘和宽精度累加。
4. Memory Wall → HBM：用 Roofline 判断量化打在哪个瓶颈。
5. perf/IBS → GPU trace：用运行证据证明 Kernel，而不是相信标签。
6. 最后再扩展到 KV Cache、MoE、TP/EP 和服务调度。

核心主线始终只有一句：

先确认数据如何表示，再确认硬件如何执行，最后确认瓶颈和端到端结果是否真的改变。

相关页面

• 量化基础 — Scale、W/A/Acc/Out 与性能边界
• 量化方法与评测 — PTQ/QAT 和四道验收门
• FP4/FP8 量化 — FP8/FP4 Scale recipe 与 Tensor Core 合同
• Compute-bound vs Memory-bound — GPU Roofline 与 Prefill/Decode 瓶颈
• Intel AMX 指令 — Tile register 与 TMUL
• CPU Cache — Memory Wall、Cache Line 与局部性
• AMD IBS — L3 miss、访存延迟和 NUMA 归因

参考资料

• Intel AMX Overview
• Intel AMX AI Tuning Guide
• Intel AMX INT8 Code Sample
• NVIDIA TensorRT Quantization Schemes
• NVIDIA FP8 Current Scaling