Posts on Bevisy's Blogs

LLM 术语全景图（十一）：术语关系总览与核心趋势

Mon, 27 Jul 2026 11:30:00 +0800

这是「大模型训练与推理术语全景图」系列的第 11 篇（系列收尾），不引入新概念，而是把前 10 篇的 64 个术语放回它们的关系网络中：注意力机制的演进谱系、模型与术语的对照、并行策略的组合、量化方法的选型、GPU 精度与算力。最后给出 10 条核心趋势和参考资源索引。主要参考来源：前 10 篇引用的全部论文与技术报告

开篇：把 64 个术语放回关系网络

本篇是系列收尾，不引入新概念，而是把前 10 篇的 64 个术语放回它们的关系网络中：注意力机制的演进谱系、模型与术语的对照、并行策略的组合、量化方法的选型、GPU 精度与算力。最后给出 10 条核心趋势和参考资源索引。

注意力机制演进关系图

MHA (原始 Transformer)
├── MQA (极端共享 K/V，1 组)
├── GQA (分组共享 K/V，当前主流)
│ └── + QK-Norm (稳定性增强)
├── MLA (低维压缩 K/V，DeepSeek 首创)
│ ├── + DSA (稀疏选择，DeepSeek V3.2)
│ │ └── + IndexShare (复用 indexer，GLM-5.2)
│ └── + CSA/HCA (序列压缩，DeepSeek V4)
├── CCA (压缩空间直接计算，ZAYA1)
├── Lightning Attention (线性注意力，MiniMax)
├── KDA (改进线性注意力，Kimi Linear)
├── SWA (固定窗口)
│ └── + Global (混合，Gemma 3/Laguna)
├── NoPE (无位置编码层)
└── Hybrid (以上混合，2025-2026 趋势)
 ├── 3:1 线性+全局 (Kimi Linear, Qwen3-Next)
 ├── 5:1 SWA+全局 (Gemma 3)
 └── CSA+HCA 交替 (DeepSeek V4)

模型与术语对照表

模型	注意力	架构	位置编码	后训练	特殊技术
DeepSeek V3	MLA	MoE (256+1)	RoPE	SFT + RL	MTP, 无辅助损失路由
DeepSeek R1	MLA	MoE (256+1)	RoPE	SFT + GRPO	RLVR, 蒸馏, “Aha Moment”
DeepSeek V4	CSA + HCA	MoE + mHC	RoPE	—	mHC, Muon, 序列压缩
GLM-5	MLA + DSA	MoE (256+1)	RoPE	SFT + RL	DSA
GLM-5.2	MLA + DSA + IndexShare	MoE (256+1)	RoPE	SFT + RL	IndexShare (indexer 复用 4 层)
Kimi K2	MLA	MoE (384+1)	RoPE	SFT + RL	MuonClip
Kimi Linear	KDA + MLA (3:1)	MoE	NoPE (线性层)	—	KDA, 线性注意力
MiniMax-01/M1	Lightning Attention + Full	MoE (32)	RoPE	RL (CISPO)	闪电注意力, 1M 上下文
MiniMax M2	Full Attention (回归)	MoE	RoPE	RL	放弃线性注意力
Qwen3	GQA + QK-Norm	Dense / MoE	RoPE	SFT + DPO/GRPO	—
Qwen3-Next	Gated DeltaNet + Full (3:1)	MoE	NoPE (线性层)	—	线性注意力混合
Llama 3/4	GQA	Dense / MoE	RoPE	SFT + RLHF	Chunked attention (Llama 4)
Gemma 3	GQA + SWA (5:1) + QK-Norm	Dense	RoPE	SFT + RLHF	—
Gemma 4	MQA + Cross-Layer KV	Dense / MoE	RoPE	—	KV 共享, Per-Layer Emb
GPT-4/o1	(闭源)	(闭源)	(闭源)	RLHF	推理模型
Claude 3.5/4	(闭源)	(闭源)	(闭源)	Constitutional AI	—

注：DeepSeek V3/R1 技术报告未明确记载 QK-Norm，故注意力列只标 MLA。QK-Norm 的采用模型见篇 02。

并行策略关系图

训练并行
├── DP (数据并行) — 每卡完整模型，分数据
│ ├── ZeRO-1 (分片优化器状态)
│ ├── ZeRO-2 (+ 分片梯度)
│ ├── ZeRO-3 / FSDP (+ 分片参数)
│ │ └── ZeRO-Infinity (卸载到 CPU/NVMe)
│ └── 嵌套 FSDP (按层分片)
├── TP (张量并行) — 层内切分权重，NVLink 域
│ ├── Attention: Q/K/V 列并行 → 输出行并行
│ └── FFN: 第1层列并行 → 第2层行并行
├── PP (流水线并行) — 层间切分，可跨节点
│ ├── GPipe (微批次填充)
│ └── 1F1B (交替调度，省激活内存)
├── EP (专家并行) — MoE 专用，All-to-All 路由
├── CP (上下文并行) — 序列切分，超长上下文
│ ├── Ring Attention (环形 KV 传递)
│ └── Ulysses (All-to-All head 重排)
└── SP (序列并行) — TP 辅助，切分 LayerNorm/Dropout

推理并行（通常更简单）
├── TP (张量并行) — 多卡共服务一个请求
├── EP (专家并行) — MoE 推理标配
├── CP (上下文并行) — 1M token 超长上下文
└── 分离式 — Prefill 池 + Decode 池

量化方法对比

方法	精度	硬件要求	校准	精度损失	适用场景
GPTQ	INT4/INT8	A100+	需要	< 1%	权重量化，通用
AWQ	INT4/INT8	A100+	需要	< 1%	权重量化，快于 GPTQ
SmoothQuant	INT8	A100+	需要	< 1%	W8A8，激活也量化
FP8	FP8	Hopper+	可选	< 0.5%	推理首选，算力翻倍
GGUF	2-8 bit	CPU/Metal	无需	可控	消费级硬件本地部署
QAT	任意	同训练	训练	最小	精度要求极高场景

GPU 精度与算力对照

精度	H100 算力	B200 算力	用途	备注
FP32	67 TFLOPS	—	优化器状态	非 Tensor Core
TF32	495 TFLOPS	—	兼容 FP32	自动降精度
BF16	989 TFLOPS	2.2 PFLOPS	训练默认	Tensor Core
FP16	989 TFLOPS	2.2 PFLOPS	推理/训练	需 loss scaling
FP8	1979 TFLOPS	4.5 PFLOPS	推理/训练	Hopper 新增
INT8	1979 TFLOPS	—	推理	需校准
FP4	—	9 PFLOPS	推理	Blackwell 新增

核心趋势总结

KV Cache 是第一瓶颈：MLA → DSA → CSA/HCA → 线性注意力，所有创新都围绕降低 KV Cache 成本
混合架构成为主流：纯完整注意力 → 3:1 / 5:1 混合，完整注意力成为稀缺资源
MoE 普及：大模型几乎全部 MoE 化，激活比持续下降（DeepSeek V4 ~4%）
RL 驱动推理能力：GRPO/RLVR 替代传统 RLHF，涌现推理行为
训练优化器更新：AdamW → Muon，收敛效率提升
残差连接也在进化：标准残差 → mHC 多残差流，信息通路更宽
FP8 取代 INT8：Hopper GPU 原生 FP8 支持，浮点量化几乎无损且算力翻倍
推理分离式架构：Prefill/Decode 分池部署，各阶段独立优化，吞吐提升 30-60%
并行策略组合化：大模型训练标配 TP+EP+PP+DP/ZeRO 多维并行，推理标配 TP+EP
PEFT 成为微调标配：LoRA/QLoRA 使单卡微调 70B 模型成为可能，多 LoRA 热切换服务

本篇小结

本篇是系列收尾，不引入新概念，而是把前 10 篇的 64 个术语放回关系网络：

演进谱系图把注意力机制从 MHA 到 MLA、CSA/HCA、线性注意力、混合架构的分支与组合画在一棵树上，让前两篇的概念回到同一张图里。
模型与术语对照表把 15 个代表模型按注意力、架构、位置编码、后训练、特殊技术五列对齐，读者可横向对照"谁用了什么"。
并行策略关系图把训练侧的 DP/TP/PP/EP/CP/SP 与推理侧的 TP/EP/CP/分离式分别画出，呼应篇 6。
量化方法对比表把 GPTQ/AWQ/SmoothQuant/FP8/GGUF/QAT 按精度、硬件、校准、精度损失、适用场景五列对齐，呼应篇 8。
GPU 精度与算力对照表把 FP32 到 FP4 的算力与用途对齐，呼应篇 7。
核心趋势 10 条浓缩全系列主线：KV Cache 是第一瓶颈、混合架构主流化、MoE 普及、RL 驱动推理、优化器更新、残差进化、FP8 取代 INT8、推理分离式架构、并行策略组合化、PEFT 成微调标配。

本篇的价值不在于新知识，而在于把分散在 10 篇里的术语重新编织成一张可查阅的关系网——单篇看细节，本篇看整体。

参考资源汇总

核心参考文章

Sebastian Raschka “The Big LLM Architecture Comparison”: https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison
Sebastian Raschka “A Visual Guide to Attention Variants”: https://magazine.sebastianraschka.com/p/visual-attention-variants
Sebastian Raschka “Recent Developments in LLM Architectures” (CSA/HCA/mHC): https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures
Sebastian Raschka “From DeepSeek V3 to V3.2”: https://magazine.sebastianraschka.com/p/technical-deepseek
Sebastian Raschka “GLM-5.2 IndexShare”: https://sebastianraschka.com/blog/2026/glm-5-2-indexshare.html
Sebastian Raschka “A Dream of Spring for Open-Weight LLMs” (MiniMax/Qwen/Ling): https://magazine.sebastianraschka.com/p/a-dream-of-spring-for-open-weight
Sebastian Raschka “From GPT-2 to gpt-oss”: https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the
LLM Architecture Gallery: https://sebastianraschka.com/llm-architecture-gallery

核心视频

“Hybrid Attention and Gated DeltaNet: How 2026 LLMs Actually Work”: https://www.youtube.com/watch?v=SH6Cyhunl8s
“LLM Architecture in 2026” (Sebastian Raschka 播客): https://www.youtube.com/watch?v=Y6APnyZT6XU
Yannic Kilcher “GRPO Explained”: https://www.youtube.com/watch?v=bAWV_yrqx4w

重要论文索引（arXiv 链接）

“Attention Is All You Need” (Transformer 原始论文): https://arxiv.org/abs/1706.03762
“RoPE / RoFormer” (旋转位置编码): https://arxiv.org/abs/2104.09864
“YaRN” (上下文扩展): https://arxiv.org/abs/2309.00071
“GQA” (分组查询注意力): https://arxiv.org/abs/2305.13245
“FlashAttention” (闪存注意力): https://arxiv.org/abs/2205.14135
“PagedAttention / vLLM” (分页注意力): https://arxiv.org/abs/2309.06180
“Speculative Decoding” (推测解码): https://arxiv.org/abs/2211.17192
“DPO” (直接偏好优化): https://arxiv.org/abs/2305.18290
“DeepSeekMath / GRPO” (组相对策略优化): https://arxiv.org/abs/2402.03300
“Hyper-Connections” (超连接，mHC 前身): https://arxiv.org/abs/2409.19606
“CCA” (压缩卷积注意力): https://arxiv.org/abs/2510.04476

本系列共 11 篇，本文是第 11 篇。系列导读见：LLM 术语全景图：系列导读

LLM 术语全景图（十）：推理服务——Prefill Decode 与性能指标

Mon, 27 Jul 2026 11:15:00 +0800

这是「大模型训练与推理术语全景图」系列的第 10 篇，覆盖推理服务与性能指标的 6 个概念：Prefill/Decode、TTFT、TPOT、Prefix Caching / RadixAttention、Chunked Prefill、Disaggregated Inference。主要参考框架/服务：vLLM、SGLang、TGI、DeepSeek 推理服务、Sarathi-Serve、DistServe、Splitwise

开篇：推理服务的两个阶段和两个指标

LLM 推理不是一次"模型前向"，而是两个特性截然不同的阶段。Prefill（预填充）一次性处理整个 prompt，构造 N×N 注意力矩阵、打满 GPU 算力，是 compute-bound；Decode（解码）逐 token 生成，每步都要读回全部模型权重与 KV Cache、算力利用率往往低于 5%，是 memory-bound。用户感知到的两个维度恰好对应这两阶段：TTFT（首 token 延迟）由 prefill 主导，决定"是不是即时响应"；TPOT（单 token 生成时间）由 decode 主导，决定"是不是流畅"。高效推理服务（vLLM、SGLang）的所有优化都围绕这两阶段展开——Chunked Prefill 把长 prompt 切块，避免 prefill 阻塞正在 decode 的请求；Prefix Caching 复用历史 KV，多轮对话 TTFT 降低 50-90%；Disaggregated Inference 干脆把两阶段分池部署，prefill 池高算力、decode 池高带宽，吞吐再提 30-60%。本篇按"两阶段 → 两指标 → 三类优化"的脉络梳理这 6 个术语。

推理服务与性能指标（Inference Serving & Metrics）

LLM 推理不是简单的"模型前向"。高效推理服务需要理解 prefill/decode 两阶段、关键延迟指标和缓存策略。

Prefill/Decode

缩写：—
中文名称：预填充与解码
简短介绍：LLM 推理分两个阶段。Prefill（预填充）一次性处理整个 prompt，计算密集（compute-bound）；Decode（解码）逐 token 生成，内存密集（memory-bound）。两阶段特性不同，优化策略也不同。
详细介绍：两阶段的本质区别：

Prefill 阶段：
- 输入：完整 prompt（N 个 token）
- 计算：N × N 注意力矩阵 + N 层 FFN
- 特性：compute-bound，GPU 算力打满
- 耗时：与 prompt 长度 N 的平方成正比（注意力）+ 线性（FFN）
Decode 阶段：
- 输入：逐个 token（1 个/步）
- 计算：1 × N_kv 注意力（与所有历史 KV）+ N 层 FFN
- 特性：memory-bound，需读取全部权重 + KV Cache，但计算量小
- 耗时：与模型大小成正比（读权重的时间），与 KV Cache 大小成正比
为什么 decode 慢：
- 每生成 1 个 token 需读取全部模型权重（如 70B 模型 = 140GB BF16）
- H100 HBM 带宽 3.35 TB/s → 读 140GB 需 ~42ms → 仅 ~24 token/s
- 算力远未打满（利用率可能 < 5%）
优化策略差异：
- Prefill：Flash Attention（减少 IO）、TP（并行计算）、Chunked Prefill
- Decode：量化（减少权重大小 → 减少读取时间）、 batching（多请求分摊权重读取）、推测解码（减少 decode 步数）
Continuous Batching 的关键：允许不同请求同时处于 prefill 和 decode 阶段，GPU 持续高利用率。
关联论文/模型：vLLM、SGLang、TGI 等推理框架的基础概念
权威分析链接：
- https://docs.vllm.ai/en/latest/design/v1/
- https://huggingface.co/blog/martinigoyanes/llm-inference-at-scale-with-tgi

Time To First Token

缩写：TTFT
中文名称：首 Token 延迟
简短介绍：从发送请求到收到第一个生成 token 的时间。主要由 prefill 阶段决定，是用户体验的关键指标（尤其是对话场景）。
详细介绍：TTFT 的构成：

TTFT = 排队延迟 + 网络延迟 + Prefill 计算时间

排队延迟：请求到达时 GPU 正忙，需等待当前 batch 处理完网络延迟：请求传输到推理服务器的时间（通常可忽略） Prefill 计算时间：处理 prompt 的时间

Prefill 时间估算：
- 短 prompt（100 token）：~10-50ms
- 中等 prompt（1K token）：~100-500ms
- 长 prompt（10K token）：~1-5s
- 超长 prompt（100K token）：~10-60s（无优化时）
优化 TTFT 的方法：
- Chunked Prefill：将长 prompt 分块处理，避免长 prefill 阻塞 decode
- Prefix Caching：如果多个请求共享相同前缀（如 system prompt），缓存其 KV
- TP：多卡并行 prefill 加速
- 量化：减少权重读取（对长 prompt 的 FFN 计算有帮助）
典型目标：对话场景 TTFT < 200ms，用户感知"即时响应"。
关联论文/模型：vLLM、SGLang 推理框架；LLM 推理服务标准指标
权威分析链接：
- https://docs.vllm.ai/en/latest/design/metrics.html

Time Per Output Token

缩写：TPOT
中文名称：单 Token 生成时间
简短介绍：decode 阶段平均生成一个 token 的时间。由 memory-bound 特性决定，是吞吐和延迟的关键指标。TPOT 的倒数即为单请求解码速度（token/s）。
详细介绍：TPOT 的决定因素：

TPOT ≈ (模型权重大小 + KV Cache 大小) / HBM 带宽

示例（70B BF16, 8K 上下文, H100 80GB）：
- 权重：140GB
- KV Cache：~8GB
- HBM 带宽：3.35 TB/s
- TPOT ≈ 148GB / 3.35TB/s ≈ 44ms → ~23 token/s
优化 TPOT 的方法：
- 量化：INT4/FP8 权重 → 读取量减半/四分之一 → TPOT 减半/四分之一
- Batching：多请求共享一次权重读取 → 每请求均摊 TPOT 降低
- MLA/GQA：减少 KV Cache → 减少 KV 读取时间
- 推测解码：一次验证多 token → 有效 TPOT 降低
TPOT vs 吞吐：
- 单请求 TPOT：1 个请求的解码速度（用户体验）
- 批量吞吐：batch_size / TPOT（系统效率）
- 增大 batch 可提高吞吐但不变 TPOT（权重只需读一次，多请求共享）
典型目标：对话场景 TPOT < 50ms（20+ token/s），用户感知流畅。
关联论文/模型：vLLM、SGLang 推理框架；LLM 推理服务标准指标
权威分析链接：
- https://docs.vllm.ai/en/latest/design/metrics.html

Prefix Caching / RadixAttention

缩写：—
中文名称：前缀缓存 / 基数注意力
简短介绍：缓存已计算 prompt 的 KV Cache，当新请求共享相同前缀时直接复用，跳过 prefill。SGLang 的 RadixAttention 用基数树管理缓存，实现自动 prefix 复用。
详细介绍：Prefix Caching 的场景：
- 多轮对话：每轮都包含完整历史 → 历史部分的 KV 可复用
- System prompt：所有请求共享同一 system prompt → 缓存其 KV
- Few-shot：相同示例前缀 → KV 复用
- Agent 工作流：多次调用中共享上下文
实现：
1. 计算每个 prompt 的 hash（基于 token 序列）
2. 新请求到达时，检查是否有前缀的 KV Cache 命中
3. 命中部分跳过 prefill，只 prefill 不命中部分
4. 新计算的 KV 也存入缓存
vLLM 的实现：Automatic Prefix Caching，基于 PagedAttention 的 block 管理，自动检测前缀匹配。

SGLang RadixAttention：
- 用基数树（Radix Tree）管理 KV Cache
- 树的每条路径代表一个 token 序列前缀
- 新请求沿树匹配最长前缀，未命中部分分支新建
- LRU 淘汰策略管理缓存容量
效果：
- 多轮对话 TTFT 降低 50-90%（历史部分跳过 prefill）
- System prompt 场景几乎消除重复计算
- 对 Agent 工作流（重复调用）效果显著
关联论文/模型：“SGLang RadixAttention” (Zheng et al., 2023, arXiv:2312.07104)；vLLM Automatic Prefix Caching
权威分析链接：
- https://lmsys.org/blog/2024-01-17-sglang/
- https://docs.vllm.ai/en/latest/features/automatic_prefix_caching.html

Chunked Prefill

缩写：—
中文名称：分块预填充
简短介绍：将长 prompt 的 prefill 分成多个小块，与 decode 请求混合调度，避免长 prefill 阻塞正在 decode 的请求。vLLM V1 的核心调度策略之一。
详细介绍：Chunked Prefill 解决的问题：

无 Chunked Prefill 时：
- 一个 10K token 的 prefill 请求到达
- GPU 花 ~2s 处理这个 prefill
- 正在 decode 的其他请求全部暂停 2s → TPOT 暴涨
Chunked Prefill 方案：
1. 将 10K token 的 prefill 分成 20 个 512-token 块
2. 每个 iteration 只处理 1 个 prefill 块 + 当前所有 decode token
3. prefill 和 decode 在同一 batch 混合执行
4. 20 个 iteration 后 prefill 完成
效果：
- decode 请求每步都能执行 → TPOT 不受长 prefill 影响
- prefill 总时间略增（分块效率略低），但整体延迟体验更好
- GPU 持续高利用率（prefill 块 + decode 混合填满算力）
vLLM V1 默认开启 Chunked Prefill，chunk_size 通常 512~2048 token。

与 Continuous Batching 的关系：Chunked Prefill 是 Continuous Batching 的增强——传统 Continuous Batching 只混合不同 decode 请求，Chunked Prefill 进一步混合 prefill 和 decode。
关联论文/模型：vLLM V1；SGLang；Sarathi-Serve (arXiv:2308.16369)
权威分析链接：
- https://docs.vllm.ai/en/latest/design/v1/
- https://arxiv.org/abs/2308.16369

Disaggregated Inference

缩写：Disaggregated Inference / Prefill-Decode 分离
中文名称：分离式推理
简短介绍：将 prefill 和 decode 分配到不同的 GPU 池执行，各池针对各自阶段优化（prefill 池用高算力配置，decode 池用高带宽配置），通过 KV Cache 传输连接两阶段。
详细介绍：分离式推理的动机：

Prefill 和 Decode 的计算特性完全不同：
- Prefill：compute-bound，需要高 FLOPS（TP 度数高）
- Decode：memory-bound，需要高 HBM 带宽（batch 大更高效）
传统推理（混合在同一 GPU 池）：
- 同一 GPU 同时做 prefill 和 decode → 两阶段互相干扰
- prefill 阻塞 decode（或 chunked prefill 增加 prefill 延迟）
分离式推理：
1. Prefill 池：专门处理 prefill，高 TP 度数，compute-optimized
2. 计算完的 KV Cache 传输到 Decode 池
3. Decode 池：专门做 decode，大 batch（多请求共享权重读取），memory-optimized
KV Cache 传输：
- 跨池传输 KV Cache 是主要开销
- 通过高速互连（NVLink/InfiniBand）传输
- 可在 prefill 最后几层时就启动传输（overlap）
优势：
- 两阶段各自独立优化，吞吐提升 30-60%
- prefill 不会被 decode 拖慢，decode 不会被 prefill 阻塞
- 可根据负载独立扩缩两池
实践：DeepSeek 推理服务采用分离式架构；vLLM 正在支持；Moonshot/SGLang 也在探索。

局限：KV Cache 传输增加延迟和复杂度，需要高速互连；对短序列收益小。
关联论文/模型：“DistServe: Disaggregating Prefill and Decoding” (Zhong et al., 2024, arXiv:2401.09670)；DeepSeek 推理服务；Splitwise (arXiv:2311.18677)
权威分析链接：
- https://arxiv.org/abs/2401.09670
- https://docs.vllm.ai/en/latest/design/v1/

本篇小结

本篇 6 个推理服务术语沿"两阶段 → 两指标 → 三类优化"的脉络归位：

Prefill/Decode 是推理的两个阶段：前者一次性处理整个 prompt，compute-bound，GPU 算力打满；后者逐 token 生成，memory-bound，每步读全部权重但算力利用率常 < 5%。两阶段特性截然不同，优化策略也不同。
TTFT（首 token 延迟）由 prefill 主导，决定"是不是即时响应"，对话场景尤其敏感。
TPOT（单 token 生成时间）由 decode 主导，决定"是不是流畅"；其倒数即单请求解码速度（token/s）。增大 batch 能提高系统吞吐却不改变单请求 TPOT，因为权重只需读一次、多请求共享。
Prefix Caching / RadixAttention 缓存已计算 prompt 的 KV，新请求共享前缀时直接复用跳过 prefill；SGLang 的 RadixAttention 用基数树管理缓存，多轮对话 TTFT 可降至 1/10。
Chunked Prefill 把长 prompt 的 prefill 切块与 decode 混合调度，避免长 prefill 阻塞正在 decode 的请求；vLLM V1 的核心调度策略之一。
Disaggregated Inference 把 prefill 和 decode 分到不同 GPU 池，各池针对各自阶段优化（prefill 池高算力、decode 池高带宽），DeepSeek 推理服务已落地，吞吐再提 30-60%，代价是 KV Cache 跨池传输。

三类优化层层递进：Prefix Caching 复用历史 KV → Chunked Prefill 让长 prompt 不再阻塞 decode → Disaggregated Inference 干脆分池部署。前两者在单池内调度，后者跨越池边界，代价是 KV Cache 传输开销。

本系列共 11 篇，本文是第 10 篇。系列导读见：LLM 术语全景图：系列导读

LLM 术语全景图（九）：参数高效微调——LoRA 与 QLoRA

Mon, 27 Jul 2026 11:00:00 +0800

这是「大模型训练与推理术语全景图」系列的第 9 篇，覆盖参数高效微调（Parameter-Efficient Fine-Tuning）的 3 个概念：LoRA、QLoRA、PEFT。主要参考模型/框架：HuggingFace PEFT、bitsandbytes、vLLM

开篇：PEFT 把全量微调的显存墙拆掉

全量微调大模型的显存成本几乎不可承受：65B 模型全量微调需约 780GB 显存，对应 40+ 张 A100， optimizer state 占了大头。参数高效微调（PEFT）只训练少量额外参数，绕开这堵墙，其中 LoRA 的低秩适配是核心思想——在冻结的预训练权重旁加一对小矩阵 A、B，只训练它们。QLoRA 进一步把篇 8 的量化技术用到微调场景：QLoRA = NF4 量化 + LoRA，先把基座量化到 4-bit 冻结，再在上面训 LoRA，把 65B 微调显存从 ~780GB 压到 ~33GB，单张 A100 80GB 即可。本篇沿"LoRA 原理 → QLoRA 量化叠加 → PEFT 方法谱系"三个概念展开，点出与篇 8 量化方法的衔接。

参数高效微调（Parameter-Efficient Fine-Tuning）

全量微调大模型成本高昂。参数高效微调（PEFT）只训练少量额外参数，达到接近全量微调的效果。

Low-Rank Adaptation

缩写：LoRA
中文名称：低秩适配
简短介绍：在冻结的预训练权重旁添加低秩分解的适配矩阵（A×B），只训练 A 和 B（参数量 « 原始权重），达到接近全量微调的效果。最流行的 PEFT 方法。
详细介绍：LoRA 的数学形式：

原始权重 W (d×d)，LoRA 添加：ΔW = B × A
- A: r×d (降维), B: d×r (升维), r « d (通常 r=8/16/64)
- 前向：y = W·x + B·A·x = (W + ΔW)·x
- 训练时 W 冻结，只训练 A 和 B
参数量对比（d=4096, r=8）：
- 全量微调：4096 × 4096 = 16.7M 参数/层
- LoRA：4096 × 8 + 8 × 4096 = 65K 参数/层（减少 256x）
初始化技巧：A 用随机高斯初始化，B 用零初始化 → 训练初期 ΔW=0，不改变原模型行为。

推理时合并：W_merged = W + B×A，合并后无额外推理开销（与全量微调相同速度）。

LoRA 的应用位置：通常加在 Attention 的 Q/V 投影上（最有效），也可加在 K/V 和 FFN。

Alpha 缩放：ΔW = (α/r) × B×A，α 控制 LoRA 更新的强度，通常 α=2r。

多 LoRA 服务：一个基座模型 + 多个 LoRA 适配器，可在推理时热切换（vLLM 支持多 LoRA 服务）。
关联论文/模型：“LoRA: Low-Rank Adaptation of Large Language Models” (Hu et al., 2021, arXiv:2106.09685)；PEFT 库 (HuggingFace)；vLLM 多 LoRA
权威分析链接：
- https://arxiv.org/abs/2106.09685
- https://huggingface.co/docs/peft/en/package_reference/lora

Quantized LoRA

缩写：QLoRA
中文名称：量化低秩适配
简短介绍：LoRA + 量化的组合。将基座模型量化到 4-bit (NF4) 冻结，只在量化模型上训练 LoRA 适配器。使在单张消费级 GPU 上微调 70B 模型成为可能。
详细介绍：QLoRA 的关键创新：
1. NF4 (NormalFloat 4-bit) 量化：
  - 针对 LLM 权重正态分布设计的 4-bit 量化格式
  - 量化分位数与正态分布的分位数对齐，信息损失最小
  - 比 INT4 精度更高
2. 双重量化（Double Quantization）：
  - 量化常量（scale/zero-point）本身也量化（8-bit）
  - 进一步节省显存（每参数省 ~0.4 bit）
3. 分页优化器（Paged Optimizer）：
  - 用 PagedAttention 同款技术管理优化器状态
  - 显存峰值时自动将优化器状态卸载到 CPU
效果：
- 65B 模型全量微调需 ~780GB 显存（40+ 张 A100）
- QLoRA 微调 65B 仅需 ~33GB（单张 A100 80GB 足够）
- 精度接近全量 BF16 微调（差距 < 1%）
训练流程：
1. 加载 4-bit NF4 量化模型（冻结）
2. 添加 LoRA 适配器（FP16 训练）
3. 前向：4-bit 反量化 → 计算 → LoRA 适配
4. 反向：梯度只流过 LoRA 参数
实践工具：HuggingFace PEFT + bitsandbytes
关联论文/模型：“QLoRA: Efficient Finetuning of Quantized LLMs” (Dettmers et al., 2023, arXiv:2305.14314)；bitsandbytes；HuggingFace PEFT
权威分析链接：
- https://arxiv.org/abs/2305.14314
- https://huggingface.co/blog/4bit-transformers-bitsandbytes

Parameter-Efficient Fine-Tuning

缩写：PEFT
中文名称：参数高效微调
简短介绍：一类只训练模型少量参数（而非全量参数）的微调方法总称。包括 LoRA、Adapter、Prefix Tuning、Prompt Tuning 等。HuggingFace PEFT 库统一了这些方法的接口。

详细介绍：PEFT 方法谱系：

方法	额外参数位置	参数量占比	推理开销
LoRA	权重低秩分解	0.1~1%	可合并，无额外开销
Adapter	层后插入小网络	1~5%	增加一层计算
Prefix Tuning	KV 前加可学习前缀	0.1%	增加 prefix 长度
Prompt Tuning	输入嵌入加可学习向量	<0.01%	增加输入长度
P-Tuning v2	每层加 prefix	0.1~1%	同 prefix tuning

LoRA 是当前最主流的选择（可合并、无推理开销、效果好）。

PEFT 的核心价值：

单卡可微调大模型（QLoRA: 单卡 70B）
多任务：一个基座 + 多个 LoRA 适配器
存储高效：LoRA 适配器仅几十 MB
可组合：多个 LoRA 可叠加/混合

关联论文/模型：“PEFT: Parameter-Efficient Fine-Tuning” (HuggingFace)；LoRA、Adapter、Prefix Tuning 系列论文
权威分析链接：
- https://huggingface.co/docs/peft/
- https://github.com/huggingface/peft

本篇小结

本篇 3 个 PEFT 术语沿"低秩适配 → 量化叠加 → 方法谱系"归位：

LoRA 用低秩分解 ΔW = B×A（A: r×d, B: d×r, r « d）把可训参数压到全量的 0.1~1%，d=4096/r=8 时 65K vs 16.7M（减少 256x）；初始化技巧（A 随机高斯、B 零初始化）保证训练初期 ΔW=0；推理时合并 W_merged = W + B×A 后无额外开销，这是相对 Adapter 的关键优势；α=2r 缩放控制更新强度；vLLM 支持多 LoRA 热切换。
QLoRA 是篇 8 量化方法在微调场景的落地：NF4（针对权重正态分布设计的 4-bit）+ 双重量化 + 分页优化器三个创新，把 65B 全量微调 ~780GB 压到 ~33GB 单卡 A100 80GB，精度差距 < 1%；流程是 4-bit NF4 冻结 + LoRA FP16 训练，工具链 HuggingFace PEFT + bitsandbytes。
PEFT 是方法总称，谱系表中 LoRA 凭"可合并、无推理开销、效果好"成为当前最主流选择，其余 Adapter/Prefix/Prompt/P-Tuning v2 各有参数位置与推理开销取舍。

QLoRA 正是篇 8 量化与篇 9 PEFT 的结合点：把 NF4 量化技术用在微调而非推理，让单卡微调大模型从奢望变为例行。

本系列共 11 篇，本文是第 9 篇。系列导读见：LLM 术语全景图：系列导读

LLM 术语全景图（八）：量化方法——从 GPTQ 到 FP8

Mon, 27 Jul 2026 10:45:00 +0800

这是「大模型训练与推理术语全景图」系列的第 8 篇，覆盖量化方法的 6 个概念：GPTQ、AWQ、SmoothQuant、GGUF/llama.cpp、FP8 Quantization、QAT。主要参考模型/框架：AutoGPTQ、AutoAWQ、vLLM、llama.cpp、Hopper GPU

开篇：量化的两条路线分野

量化在 LLM 时代分出两条路线。数据中心路线——GPTQ、AWQ、SmoothQuant、FP8——面向 GPU 高吞吐服务，在精度与算力间求平衡：权重压到 INT4 省显存，激活保高精度，或用 W8A8 享受 Tensor Core 算力翻倍。消费级路线——GGUF——面向 CPU 与 Apple Metal 本地部署，把权重、tokenizer、架构参数打包进单文件，让 MacBook 也能跑 70B 模型。两条路线工具链不重叠，场景互补。路线内部一个明确趋势：FP8 正在取代 INT8 成为数据中心推理首选。LLM 激活值有大量异常值，定点 INT8 难以同时覆盖，需 SmoothQuant 辅助；而 FP8 浮点格式的指数位天然适配异常值动态范围，几乎无损即可拿到 Hopper GPU 上 BF16 两倍的 Tensor Core 算力。本篇按此脉络梳理 6 个量化术语。

量化方法（Quantization Methods）

量化是将高精度模型参数降至低精度以减少显存和加速推理的技术。本篇展开具体方法。

GPTQ

缩写：GPTQ
中文名称：GPTQ 量化
简短介绍：基于二阶 Hessian 信息的训练后量化方法，逐层将权重量化到 INT4/INT8，利用校准数据补偿量化误差。生成式任务中几乎无损，是 INT4 权重量化的主流方案。
详细介绍：GPTQ 的核心思想：
1. 逐层量化：对每一层的权重矩阵 W 逐列量化
2. Hessian 信息：用校准数据计算 H = X^T · X（输入的二阶统计量）
3. 顺序量化：量化第 j 列时，用 Hessian 信息预测量化误差，并补偿到未量化的列
4. 公式：quant 后的误差被投影到剩余权重上，最小化输出误差
量化流程：
- 准备 ~128 条校准数据（如 C4/WikiText 片段）
- 逐层运行校准数据，收集输入激活
- 对每层权重做 GPTQ 量化（~几分钟）
- 保存量化后的权重 + scale/zp
典型精度：
- W4A16（权重 INT4，激活 FP16）：显存 ~25% BF16，精度损失 < 1%
- W8A16：显存 ~50%，几乎无损
支持框架：AutoGPTQ、vLLM（原生支持 GPTQ 推理）、HuggingFace transformers

局限：主要量化权重，激活仍需 FP16（W4A16 模式）；对极小模型（< 1B）精度损失更大。
关联论文/模型：“GPTQ: Accurate Post-Training Quantization for GPT” (Frantar et al., 2022, arXiv:2210.17323)；AutoGPTQ；vLLM
权威分析链接：
- https://arxiv.org/abs/2210.17323
- https://docs.vllm.ai/en/latest/features/quantization/gptqmodel/

Activation-aware Weight Quantization

缩写：AWQ
中文名称：激活感知权重量化
简短介绍：通过分析激活值的分布识别"重要权重"（对应大激活的权重），对重要权重保持高精度、对非重要权重量化压缩。比 GPTQ 更快（无需反向传播补偿），精度相当。

详细介绍：AWQ 的核心发现：

不是所有权重同等重要——与大激活值对应的权重对量化误差更敏感。保持这些"重要权重"的高精度（或用 per-channel scale 缩放），其余权重可激进量化。

AWQ 方法：

用校准数据统计每通道激活的幅度分布
对大激活通道的权重乘以 scale s（放大），量化后精度更高
对应的激活除以 s（反缩放），保持等价性
量化：W’ = quant(W × s), X’ = X / s → W’ × X’ ≈ W × X

与 GPTQ 对比：

特性	GPTQ	AWQ
方法	Hessian 补偿	激活感知缩放
校准	需要（二阶计算）	需要（统计激活）
速度	较慢（逐列补偿）	较快（仅需统计）
精度	略优（复杂模型）	相当
通用性	广	广

支持：AutoAWQ、vLLM（原生支持）、HuggingFace

W4A16 模式下 AWQ 和 GPTQ 是最常用的两种 INT4 量化方案。

关联论文/模型：“AWQ: Activation-aware Weight Quantization for LLM Compression” (Lin et al., 2023, arXiv:2306.00978)；AutoAWQ；vLLM
权威分析链接：
- https://arxiv.org/abs/2306.00978
- https://docs.vllm.ai/en/latest/features/quantization/auto_awq/

SmoothQuant

缩写：—
中文名称：平滑量化
简短介绍：将量化难度从激活值转移到权重的训练后量化方法。通过 per-channel 缩放因子"平滑"激活的异常值，使权重和激活都能用 INT8 量化（W8A8），无需 FP16 激活。
详细介绍：SmoothQuant 解决的问题：

LLM 激活值有大量异常值（outlier），使 INT8 量化激活困难。GPTQ/AWQ 量化权重但保持激活 FP16（W4A16），仍需 FP16 计算。SmoothQuant 使 W8A8 成为可能——权重和激活都是 INT8，享受 Tensor Core INT8 算力加速。

核心方法：将量化难度从激活值转移到权重，具体步骤如下：
1. 统计每通道激活的最大值 s_j = max(|X_j|)^α / max(|W_j|)^(1-α)
2. 平滑：W’_j = W_j / s_j, X’_j = X_j × s_j
3. 平滑后：W’ 的通道更均匀（便于量化），X’ 的异常值被抑制
4. 量化：W’_int8 = quant(W’), X’_int8 = quant(X')
α 参数（迁移强度）：α=0.5 是平衡点，典型值 0.5~0.8。

优势：
- W8A8：权重和激活都 INT8，推理用 INT8 GEMM（Tensor Core INT8 算力是 BF16 的 2x）
- 无需 FP16 激活 → 减少内存带宽 → decode 加速
- 精度损失小（< 1%）
局限：INT8 精度不如 FP8（定点格式对异常值不友好），Hopper GPU 上 FP8 更优。
关联论文/模型：“SmoothQuant: Accurate and Efficient Post-Training Quantization for LLMs” (Xiao et al., 2022, arXiv:2211.10438)；MIT-Han-Lab
权威分析链接：
- https://arxiv.org/abs/2211.10438
- https://github.com/mit-han-lab/smoothquant

GGUF / llama.cpp Quantization

缩写：GGUF
中文名称：GGUF 量化格式
简短介绍：llama.cpp 项目定义的模型文件格式，支持 2~8 bit 多种量化方案，专为 CPU/消费级 GPU 推理优化。可在普通笔记本上运行大模型，是本地部署最流行的格式。

详细介绍：GGUF（GPT-Generated Unified Format）替代了旧的 GGML 格式：

支持的量化方案（按精度从高到低）：

量化名	bit/权重	说明
Q8_0	8	INT8 + FP16 scale，几乎无损
Q6_K	6	6-bit 混合，精度好
Q5_K_M	5.5	5-bit 混合，精度较好
Q4_K_M	4.5	4-bit 混合，主流选择
Q4_0	4	基础 4-bit，速度快
Q3_K_M	3.5	3-bit 混合，精度有损
Q2_K	2	极限压缩，明显有损

特点：

单文件存储权重 + 元数据（tokenizer、架构参数）
支持 CPU (AVX2/NEON) + GPU (CUDA/Metal) 混合推理
部分层可在 GPU 计算，其余在 CPU（offload 层数可控）
内存映射加载，启动快

使用场景：

MacBook (Metal) 上跑 70B 模型（Q4 需 ~35GB 内存）
没有数据中心 GPU 的本地开发和测试
边缘设备部署

与 vLLM/FP8 的关系：GGUF 面向消费级硬件和 CPU 推理，vLLM/FP8 面向数据中心 GPU 高吞吐服务。两者互补，不竞争。

关联论文/模型：llama.cpp (Georgi Gerganov)；GGUF 规范
权威分析链接：

FP8 Quantization

缩写：FP8
中文名称：FP8 量化
简短介绍：利用 Hopper GPU 原生 FP8 Tensor Core 的量化方案。相比 INT4/INT8 定点量化，FP8 浮点格式天然适配 LLM 激活的异常值分布，几乎无损且算力翻倍。正在取代 INT8 成为推理量化的首选。

详细介绍：FP8 量化的两种模式：

W8A8（权重+激活 FP8）：
- 权重和激活都用 FP8（E4M3）
- GEMM 用 FP8 Tensor Core（H100 算力 1979 TFLOPS，BF16 的 2x）
- 需要校准确定 scale factor（per-tensor 或 per-channel）
- 精度损失通常 < 0.5%
仅权重量化（W8A16）：
- 权重 FP8，激活 BF16
- 用于不支持 FP8 计算的 GPU（如 A100）
- 显存减半，但计算无加速

两种 FP8 编码格式（由 “FP8 Formats for Deep Learning” 定义）：

E4M3（4 位指数 + 3 位尾数）：更多尾数位，精度更高，用于权重/激活与前向推理
E5M2（5 位指数 + 2 位尾数）：更多指数位，动态范围更大，用于梯度/反向传播推理场景主要使用 E4M3；E5M2 因动态范围大，在训练的反向梯度中更常见。

FP8 vs INT8：

特性	FP8 (E4M3)	INT8
格式	浮点（指数+尾数）	定点
异常值	天然适配（浮点有指数）	需要缩放/校准
精度	更好（LLM 激活）	需 SmoothQuant 等辅助
算力	H100 原生 1979T	H100 原生 1979T
门槛	需 Hopper+	A100 即可

实践用法（vLLM）：

FP8 权重量化（无需校准）

–quantization fp8

FP8 KV Cache（长上下文减半 KV 内存）

–kv-cache-dtype fp8

局限：需 Hopper (H100/H200) 或 Ada (RTX 4090/6000) 架构。A100 不支持 FP8 Tensor Core。

关联论文/模型：“FP8 Formats for Deep Learning” (2022)；vLLM FP8；TensorRT-LLM FP8；FlashAttention-3 FP8
权威分析链接：
- https://docs.vllm.ai/en/latest/features/quantization/fp8/
- https://nvidia.github.io/TensorRT-LLM/reference/precision.html

Quantization-Aware Training

缩写：QAT
中文名称：量化感知训练
简短介绍：在训练过程中模拟量化效应（假量化），让模型在训练时就适应低精度表示。精度高于训练后量化（PTQ），但需要训练成本。
详细介绍：QAT vs PTQ：

PTQ（训练后量化）：训练完的 FP16/BF16 模型直接量化，无需再训练
- 优点：快速，无需训练数据和资源
- 缺点：低 bit（INT4 以下）精度损失明显
QAT（量化感知训练）：在微调阶段插入假量化节点
- 前向传播时模拟量化：x_fake = dequant(quant(x))，让模型"看到"量化误差
- 反向传播用 STE（Straight-Through Estimator）绕过量化不可导问题
- 模型学会调整权重以适应量化噪声
QAT 流程：
1. 从预训练 FP16 模型出发
2. 插入假量化节点（目标精度如 INT4/INT8）
3. 用训练数据继续训练几个 epoch
4. 导出真正的量化模型
适用场景：
- 需要 INT4 以下极端量化且 PTQ 精度不够时
- 部署在边缘设备（手机、嵌入式）有严格精度约束
- 对精度要求极高的生成任务
实践中：LLM 很少用 QAT（训练成本高），大多用 PTQ（GPTQ/AWQ/FP8）已足够。QAT 更多用于 CV 模型和移动端部署。
关联论文/模型：“Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference” (Jacob et al., 2018, arXiv:1712.05877)；LLM-QAT (arXiv:2207.04265)
权威分析链接：
- https://arxiv.org/abs/1712.05877

本篇小结

本篇 6 个量化术语沿"两条路线 + 一个趋势"归位：

GPTQ 基于 Hessian 信息的逐列补偿，W4A16 模式下显存 ~25% BF16、精度损失 < 1%，局限是仅量化权重、激活仍需 FP16。
AWQ 以"与大激活值对应的权重更敏感"为出发点，用 per-channel scale 缩放而非二阶补偿，比 GPTQ 更快、精度相当；W4A16 下与 GPTQ 并列最常用 INT4 方案。
SmoothQuant 把量化难度从激活值转移到权重，使 W8A8 成为可能，享受 Tensor Core INT8 算力（BF16 的 2x）；但 INT8 定点格式对异常值不友好，Hopper GPU 上 FP8 更优。
GGUF 是消费级路线的代表，Q2_K~Q8_0 单文件便携，MacBook Metal 上 Q4 跑 70B 约 35GB 内存；与 vLLM/FP8 数据中心路线互补而非竞争。
FP8 Quantization 是数据中心推理的新首选：E4M3（前向/推理，更多尾数）与 E5M2（反向/梯度，更多指数）两种编码，浮点格式天然适配 LLM 激活异常值，H100 上算力 1979 TFLOPS（BF16 的 2x）；硬件门槛是 Hopper/Ada，A100 不支持 FP8 Tensor Core。
QAT 精度高于 PTQ 但需训练成本，LLM 实践中很少用 QAT，PTQ（GPTQ/AWQ/FP8）已足够；QAT 主要用于 CV 模型与移动端部署。

两条路线的边界清晰：数据中心 GPU 上 FP8/INT8 量化服务高吞吐推理，消费级 CPU/Metal 上 GGUF 单文件服务本地部署；FP8 取代 INT8 的趋势由 LLM 激活异常值分布驱动，定点格式需 SmoothQuant 辅助，浮点格式原生适配。

本系列共 11 篇，本文是第 8 篇。

LLM 术语全景图（七）：GPU 硬件与计算——从 Tensor Core 到 HBM

Mon, 27 Jul 2026 10:30:00 +0800

这是「大模型训练与推理术语全景图」系列的第 7 篇，覆盖 GPU 硬件与计算的 8 个概念：Tensor Core、MMA/WGMMA、TMA、HBM、BF16、FP8、AllReduce/AllGather/ReduceScatter、NVLink/NVSwitch。主要参考架构：NVIDIA Volta/Ampere/Hopper/Blackwell、CUTLASS、FlashAttention-3、NCCL

开篇：理解 GPU 硬件是优化 LLM 的前提

LLM 推理的两个阶段受限于完全不同的资源。prefill 一次性处理整段 prompt，矩阵乘法的 FLOPs 大、每个权重被反复使用，瓶颈落在 Tensor Core 算力上，属于 compute-bound；decode 逐 token 自回归生成，每生成 1 个 token 都要把全部模型权重和当前 KV Cache 从 HBM 读进 SM，FLOPs 很小但读取量极大，瓶颈落在 HBM 带宽上，属于 memory-bound。这两种瓶颈分别决定了优化方向：compute-bound 看算力（更低精度、更稠密的 Tensor Core 利用率），memory-bound 看带宽（更小的权重、更少的读取）。量化把权重从 BF16 压到 FP8/INT4，本质是减少单位计算的 HBM 读取量；MoE 每次只激活少数专家，本质是减少单次 decode 实际需要读取的权重。所有主流 LLM 优化都能归到"降读取"或"降计算"这两条路径上，而判断走哪条路径的前提，是先看清 GPU 的算力墙和带宽墙分别在哪。本篇按硬件层次梳理 8 个术语：从计算单元（Tensor Core、MMA/WGMMA、TMA）、到内存与数据格式（HBM、BF16、FP8）、再到多卡互连（AllReduce 系原语、NVLink/NVSwitch）。

GPU 硬件与计算（GPU Hardware & Compute）

Tensor Core

缩写：—
中文名称：张量核心
简短介绍：NVIDIA GPU 上专门用于矩阵乘法（GEMM）的硬件单元，单个时钟周期可完成一个矩阵乘加操作。相比 CUDA Core 做标量乘法，Tensor Core 吞吐量高出一个数量级，是 LLM 计算的核心引擎。

详细介绍：Tensor Core 的计算能力：

CUDA Core：每周期 1 个 FP32 FMA（fused multiply-add） Tensor Core：每周期一个矩阵乘加，如 D = A × B + C（A/B/C/D 是小矩阵块）

各代 Tensor Core 支持的精度：

GPU 架构	Tensor Core 代	支持精度
Volta (V100)	第 1 代	FP16
Ampere (A100)	第 3 代	FP16, BF16, TF32, INT8, INT4
Hopper (H100)	第 4 代	FP16, BF16, TF32, FP8(E4M3/E5M2), INT8
Blackwell (B200)	第 5 代	FP4, FP6, FP8, BF16, FP16

对 LLM 的影响：

训练：BF16 是主力精度（Tensor Core 原生加速，动态范围大）
推理：FP8（Hopper）和 FP4（Blackwell）大幅提升吞吐
A100-SXM4-40GB：第 3 代 Tensor Core，BF16 算力 312 TFLOPS

MMA 指令：Tensor Core 通过 MMA (Matrix Multiply-Accumulate) 指令编程。CUTLASS 和 Triton 库在底层调用 MMA 指令实现高效 GEMM。

关联论文/模型：NVIDIA Volta 架构白皮书 (2017)；CUTLASS 库；Triton 编译器
权威分析链接：
- https://docs.nvidia.com/cutlass/latest/media/docs/cpp/cute/00_quickstart.html
- https://developer.nvidia.com/blog/cutlass-linear-algebra-cuda/

Matrix Multiply-Accumulate

缩写：MMA / WGMMA
中文名称：矩阵乘加指令
简短介绍：驱动 Tensor Core 的底层指令。MMA 是 Ampere 及之前架构的同步指令，WGMMA (Warp Group MMA) 是 Hopper 架构引入的异步指令，支持 TMA 加载数据，吞吐量大幅提升。
详细介绍：MMA vs WGMMA：

MMA（Ampere 及之前）：
- 同步执行，线程束(warp)级
- 数据需先加载到寄存器，再调用 MMA
- 矩阵块较小（如 16×8×16 for FP16）
- 数据加载和计算串行，有等待空闲
WGMMA（Hopper）：
- 异步执行，线程束组(warp group, 4 warps)级
- 可直接从共享内存(shared memory)异步执行矩阵乘加
- 矩阵块更大（如 64×128×16 for BF16, 128×256×32 for FP8）
- 与 TMA 配合：TMA 异步加载数据到共享内存，WGMMA 异步从共享内存计算
- 计算和数据加载可重叠（double buffer），接近峰值算力
编程接口：
- PTX 汇编：mma.sync / wgmma.mma_async 指令
- CUTLASS 3.x：Cute 库封装 WGMMA
- Triton：编译器自动选择 MMA/WGMMA
对 LLM 的影响：WGMMA 使 H100 的 FP8 算力达到近 2000 TFLOPS（理论峰值），是 A100 BF16 的 ~6x。Flash Attention-3 专门利用 WGMMA + TMA 实现 FP8 注意力。
关联论文/模型：NVIDIA Hopper 架构白皮书 (2022)；CUTLASS 3.x；FlashAttention-3
权威分析链接：
- https://docs.nvidia.com/cuda/parallel-thread-execution/
- https://github.com/NVIDIA/cutlass

Tensor Memory Accelerator

缩写：TMA
中文名称：张量内存加速器
简短介绍：Hopper 架构引入的专用硬件单元，用于在 HBM 和共享内存之间高效异步搬运多维张量。替代手动内存管理，与 WGMMA 配合实现计算-通信重叠。
详细介绍：TMA 解决的问题：

传统方式：程序员用 global memory load 指令逐元素/逐块加载数据到寄存器，再存储到共享内存。线程开销大，带宽利用率低。

TMA 方式：
1. 预设张量描述符（descriptor）：定义 HBM 中的张量形状、跨度、维度
2. 单条指令发起异步拷贝：整个多维切片从 HBM → 共享内存
3. 不占用线程，由专用 DMA 引擎执行
4. 通过 mbarrier（内存屏障）同步完成
TMA 优势：
- 异步：不占用计算线程，与 WGMMA 计算重叠
- 多维：原生支持 1D~5D 张量拷贝，无需手动算地址
- 高带宽：接近 HBM 峰值带宽（H100: 3.35 TB/s）
- 跨节点：直接支持多卡共享内存间拷贝（配合 NVSwitch）
与 Flash Attention-3 的关系：FA3 的核心优化之一就是用 TMA 替代 FA2 中的手动数据加载，实现 prefetch + 计算重叠，FP8 注意力吞吐提升 ~75%。

Blackwell (B200) 进一步增强 TMA，支持 FP4 精度张量搬运。
关联论文/模型：NVIDIA Hopper 架构白皮书 (2022)；FlashAttention-3 (arXiv:2407.08608)；CUTLASS 3.x
权威分析链接：
- https://docs.nvidia.com/cuda/parallel-thread-execution/#tensor-memory-accelerator
- https://github.com/Dao-AILab/flash-attention

High Bandwidth Memory

缩写：HBM
中文名称：高带宽内存
简短介绍：GPU 上的高带宽显存，通过 3D 堆叠 DRAM 实现远超普通 DDR 的带宽。LLM 推理的主要瓶颈往往不是算力而是 HBM 带宽（memory-bound）。

详细介绍：各代 HBM 参数：

HBM 代	GPU	带宽	容量
HBM2	V100	0.9 TB/s	32GB
HBM2e	A100 80GB	2.0 TB/s	80GB
HBM3	H100 SXM5	3.35 TB/s	80GB
HBM3e	B200	8 TB/s	192GB

Memory-bound vs Compute-bound：

LLM 推理的 decode 阶段是典型的 memory-bound：

每生成 1 个 token，需从 HBM 读取全部模型权重 + KV Cache
计算量小（1 个 token × 全部权重），但读取量大
瓶颈 = 权重 / HBM 带宽，而非算力

LLM 推理的 prefill 阶段是 compute-bound：

处理整段 prompt，矩阵乘法计算量大
瓶颈 = FLOPs / Tensor Core 算力

量化算例：decode 每生成 1 token 需读取全部模型权重（70B = 140GB BF16），H100 3.35 TB/s → ~42ms → ~24 token/s。这就是 decode 阶段的天花板——单卡 H100 跑 70B BF16 的理论极限约 24 token/s，实际还要扣 KV Cache 读取和算力开销。

优化启示：

量化（INT4/FP8）减少权重大小 → 减少读取量 → 加速 decode
Flash Attention 减少 HBM 读写 → 加速注意力
MoE 只激活部分专家 → 减少实际读取的权重

带宽利用率：高效实现（如 Flash Attention）可达 HBM 峰值带宽的 70-85%。

关联论文/模型：NVIDIA 各架构白皮书；HBM 标准 (JEDEC)
权威分析链接：
- https://www.nvidia.com/en-us/data-center/h100/
- https://arxiv.org/abs/2205.14135 (Flash Attention IO 复杂度分析)

Bfloat16

缩写：BF16
中文名称：Brain 浮点 16 位
简短介绍：Google Brain 团队设计的 16 位浮点格式，与 FP16 相同的总位数但指数位更多（8 位指数 + 7 位尾数），动态范围与 FP32 相同，训练稳定性远优于 FP16。现代 LLM 训练和推理的默认精度。

详细介绍：BF16 vs FP16 vs FP32：

格式	总位数	指数	尾数	动态范围	精度
FP32	32	8	23	±3.4e38	高
FP16	16	5	10	±65504	中
BF16	16	8	7	±3.4e38	低（同 FP32 范围）

BF16 的优势：

与 FP32 相同的指数位（8 位），动态范围完全一致
训练时无需 loss scaling（FP16 需要，否则梯度下溢）
与 FP32 互转简单：BF16 → FP32 只需右侧补零
Ampere+ Tensor Core 原生支持 BF16

实践用法：

训练：权重和激活用 BF16，主权重和优化器状态用 FP32（混合精度训练）
推理：BF16 是无损推理的默认精度，权重占 FP32 的一半
KV Cache：通常用 BF16 存储

注意：BF16 尾数只有 7 位（FP16 有 10 位），精度略低。但 LLM 训练对动态范围更敏感，BF16 是更好的选择。

关联论文/模型：Google Brain (2018)；Ampere/Hopper/Blackwell Tensor Core 原生支持
权威分析链接：
- https://en.wikipedia.org/wiki/Bfloat16_floating-point_format

FP8

缩写：FP8
中文名称：8 位浮点
简短介绍：Hopper 架构原生支持的 8 位浮点格式，有两种变体 E4M3（4 位指数 + 3 位尾数）和 E5M2（5 位指数 + 2 位尾数）。相比 BF16 算力翻倍、显存减半，是推理量化和训练加速的新标准。

详细介绍：FP8 的两种格式：

格式	指数	尾数	动态范围	精度	适用场景
E4M3	4	3	±448	较高	前向传播、权重、激活
E5M2	5	2	±57344	较低	反向梯度（需要更大范围）

混合精度 FP8 训练：

前向：权重和激活用 E4M3
反向：梯度用 E5M2
主权重和优化器仍用 FP32/BF16

Hopper 算力对比：

精度	H100 算力 (TFLOPS)	相对 BF16
BF16	989	1x
FP8	1979	2x

推理中的 FP8：

权重 FP8：显存减半（相比 BF16），decode 阶段读取量减半 → 吞吐近翻倍
KV Cache FP8：长上下文场景的 KV Cache 内存减半
几乎无损：FP8 量化精度损失通常 < 1%（比 INT8 更好，因为浮点格式天然适配异常值）

与 INT8 的区别：FP8 是浮点格式，有指数和尾数，能更好地表示大动态范围的 LLM 激活值。INT8 是定点格式，需要校准和缩放因子。

Blackwell (B200) 进一步支持 FP4 和 FP6，算力可达 10 PFLOPS 级别。

关联论文/模型：“FP8 Formats for Deep Learning” (NVIDIA/ARM/Intel, 2022)；Hopper 架构；FlashAttention-3 (FP8 attention)；vLLM FP8 推理
权威分析链接：
- https://docs.nvidia.com/deeplearning/performance/mixed-precision-training/
- https://docs.vllm.ai/en/latest/features/quantization/fp8/

AllReduce / AllGather / ReduceScatter

缩写：—
中文名称：集合通信原语
简短介绍：多 GPU 通信的三个基础原语。AllReduce 求和并广播结果，AllGather 收集各卡数据拼成完整结果，ReduceScatter 求和后按分片分发。是 TP/PP/DP/FSDP 的通信基础。
详细介绍：三种通信原语：

AllReduce（TP/DP 用）：
- 各卡有一个相同大小的张量，求和后所有卡获得相同结果
- Ring AllReduce：通信量 = 2 × (N-1)/N × tensor_size（最优）
- 用途：TP 中 attention/FFN 后的梯度同步；DP 中梯度同步
AllGather（FSDP/ZeRO-3 前向用）：
- 各卡有不同的分片，收集拼成完整张量，所有卡获得相同完整结果
- 通信量 = (N-1)/N × tensor_size
- 用途：FSDP 前向恢复完整参数；CP 中收集各段 KV
ReduceScatter（FSDP/ZeRO-3 反向用）：
- 各卡有完整张量，求和后按分片分发——每卡只得到一个分片
- 通信量 = (N-1)/N × tensor_size
- 用途：FSDP 反向后分片同步梯度
关系：AllReduce = ReduceScatter + AllGather（先求和分片，再收集完整）

通信库：
- NCCL (NVIDIA Collective Communications Library)：GPU 集合通信标准库
- 依赖 NVLink/NVSwitch 拓扑，跨节点走 InfiniBand/RoCE
通信优化：
- 计算-通信重叠：在前向计算时同时启动下一步的通信
- 梯度分桶(bucketing)：将梯度分成多个 bucket 分别通信，重叠更充分
- 通信压缩：梯度 BF16/FP8 传输减少带宽
关联论文/模型：NCCL (NVIDIA)；Horovod；Megatron-LM 通信优化
权威分析链接：
- https://docs.nvidia.com/deeplearning/nccl/
- https://docs.pytorch.org/docs/stable/distributed.html

NVLink / NVSwitch

缩写：—
中文名称：NVLink 互连 / NVSwitch 交换
简短介绍：NVIDIA 的高速 GPU 互连技术。NVLink 是点对点直连（单链路 50-100 GB/s），NVSwitch 是全互连交换芯片（所有 GPU 间全带宽）。是 TP 等高通信量并行的硬件基础。

详细介绍：NVLink 各代带宽：

NVLink 代	GPU	单链路带宽	总带宽
NVLink 2	V100	25 GB/s	300 GB/s
NVLink 3	A100	50 GB/s	600 GB/s
NVLink 4	H100	50 GB/s	900 GB/s
NVLink 5	B200	100 GB/s	1.8 TB/s

与 PCIe 对比：

PCIe 5.0：~64 GB/s（单向），共享带宽
NVLink 4：900 GB/s（总），点对点专用
NVLink 比 PCIe 高 10-15 倍

NVSwitch：

专用 ASIC 交换芯片，使节点内所有 GPU 全互连（而非点对点）
8× H100 + NVSwitch：任何两卡间 900 GB/s 全带宽
DGX H100/H200 节点标配

对并行策略的影响：

TP：通信量大（每层 2 次 AllReduce），必须在节点内（NVLink 域），跨节点 TP 性能急剧下降
PP：通信量小（只传隐状态），可跨节点（InfiniBand）
EP：All-to-All 通信，最好在节点内或高带宽网络
DP/FSDP：梯度同步通信量中等，可跨节点

实践规则：TP ≤ 节点内 GPU 数（如 TP=8 for 8×H100），DP/PP 可跨节点。

关联论文/模型：NVIDIA NVLink 白皮书；DGX H100/H200 架构
权威分析链接：
- https://www.nvidia.com/en-us/data-center/nvlink/

本篇小结

本篇 8 个 GPU 硬件术语沿"算力墙 vs 带宽墙"两条主线归位：

Tensor Core 是 GPU 上专门做矩阵乘加的硬件单元，每周期完成一个小矩阵块 D = A×B + C，相比 CUDA Core 的标量 FMA 高出一个数量级；各代支持的精度逐步扩展（Volta FP16 → Ampere +BF16/TF32/INT8/INT4 → Hopper +FP8 → Blackwell +FP4/FP6），A100-SXM4-40GB 的 BF16 算力为 312 TFLOPS。
MMA / WGMMA 是驱动 Tensor Core 的底层指令。MMA 是 Ampere 及之前的同步 warp 级指令，数据加载与计算串行；WGMMA 是 Hopper 的异步 warp group 级指令，可直接从共享内存异步执行矩阵乘加，并与 TMA 配合实现计算-加载重叠。WGMMA 使 H100 的 FP8 算力达到近 2000 TFLOPS，约为 A100 BF16 的 6x；Flash Attention-3 专门利用 WGMMA + TMA 实现 FP8 注意力。
TMA 是 Hopper 引入的张量内存加速器，单条指令即可发起异步拷贝、把整个多维切片从 HBM 搬到共享内存，不占用计算线程。FA3 用 TMA 替代 FA2 中的手动数据加载，实现 prefetch + 计算重叠，FP8 注意力吞吐提升约 75%。
HBM 是 GPU 上的高带宽显存，带宽从 V100 的 0.9 TB/s 增长到 B200 的 8 TB/s。LLM 推理 decode 阶段是 memory-bound：每生成 1 token 需读取全部模型权重，70B BF16 = 140GB，H100 3.35 TB/s → ~42ms → ~24 token/s 的理论上限。prefill 阶段则是 compute-bound，瓶颈在 Tensor Core 算力。
BF16 是 16 位浮点格式，8 位指数 + 7 位尾数，与 FP32 指数位相同、动态范围完全一致，训练时无需 loss scaling，是现代 LLM 训练和推理的默认精度。
FP8 是 Hopper 原生支持的 8 位浮点格式，有 E4M3（前向/权重/激活）和 E5M2（反向梯度）两种变体；H100 上 BF16 为 989 TFLOPS、FP8 为 1979 TFLOPS，正好 2x。Blackwell B200 进一步支持 FP4 和 FP6，算力可达 10 PFLOPS 级别。
AllReduce / AllGather / ReduceScatter 是多 GPU 集合通信的三个基础原语：AllReduce 求和并广播、AllGather 收集拼完整、ReduceScatter 求和后按分片分发；AllReduce = ReduceScatter + AllGather。它们是 TP/PP/DP/FSDP 的通信基础，由 NCCL 实现，底层依赖 NVLink/NVSwitch 拓扑。
NVLink / NVSwitch 是 NVIDIA 的高速 GPU 互连：NVLink 是点对点直连，NVSwitch 是全互连交换芯片。NVLink 总带宽从 V100 的 300 GB/s 增长到 B200 的 1.8 TB/s，比 PCIe 5.0 高 10-15 倍。TP 通信量大必须在 NVLink 域内，DP/PP 可跨节点。

一句话收束：LLM 的所有主流优化都能归到"降读取"（量化、MoE、Flash Attention）或"降计算"（更低精度、更稠密的 Tensor Core 利用率）两条路径上；判断走哪条路径，前提是先看清算力墙和带宽墙分别在哪——这正是本篇 8 个术语要回答的问题。

本系列共 11 篇，本文是第 7 篇。

LLM 术语全景图（六）：并行策略——多维并行的组合

Mon, 27 Jul 2026 10:15:00 +0800

这是「大模型训练与推理术语全景图」系列的第 6 篇，覆盖并行策略的 8 个概念：Data Parallelism、Tensor Parallelism、Pipeline Parallelism、Expert Parallelism、Context Parallelism、Sequence Parallelism、FSDP、ZeRO。主要参考模型：DeepSeek V3、GLM-5、Llama 3、Megatron-LM、vLLM

开篇：并行策略是组合问题

大模型的多卡并行不是单一策略的选择题，而是多维度的组合题。各策略切分的对象不同：Data Parallelism（DP）切 batch，Tensor Parallelism（TP）在层内切权重矩阵，Pipeline Parallelism（PP）在层间切模型，Expert Parallelism（EP）切专家，Context/Sequence Parallelism（CP/SP）切序列。训练大 MoE 模型常同时叠加 TP+EP+PP+DP（或 FSDP/ZeRO 替代纯 DP），DeepSeek V3 即是 TP=8 + EP=32 + PP + DP 的组合；推理侧则以 TP+EP 为主，PP 较少使用（vLLM V1 才补上 PP 推理）。组合时关键约束是通信带宽层级——TP 每层都要 AllReduce，对带宽极敏感，必须放在 NVLink 域内（单节点，TP=2/4/8）；PP 的 stage 间只传隐状态、EP 的 All-to-All 通信量较小，可跨节点；DP 的 AllReduce 介于二者之间。一句话：高带宽通信配高频切分（TP 在节点内），低带宽链路配低频切分（PP/EP 跨节点）。本篇按切分对象逐条梳理这 8 个术语。

并行策略（Parallelism Strategies）

LLM 训练和推理都需要多 GPU 协作。并行策略决定模型参数、梯度、优化器状态、激活值如何在多卡间分割与通信。

Data Parallelism

缩写：DP
中文名称：数据并行
简短介绍：每张 GPU 持有完整模型副本，将不同 batch 分配给不同 GPU 并行计算，反向传播后通过 AllReduce 同步梯度。最简单的并行方式，但要求单卡能放下完整模型。
详细介绍：DP 的工作流程：
1. 将 batch 均分到 N 张 GPU，每卡持有相同模型权重
2. 各卡独立前向 + 反向计算，得到本地梯度
3. AllReduce 通信：所有 GPU 梯度求和取平均
4. 各卡用同步后的梯度更新本地权重
通信模式：每步训练需 1 次 AllReduce（梯度同步），通信量 = 2 × model_size（ring-allreduce 发送+接收各一次）。

纯 DP 的限制：单卡必须能放下完整模型 + 优化器状态 + 激活值。对 7B 模型，bf16 权重 14GB + AdamW 优化器状态 (fp32 m/v) 56GB + 激活值 → 需 80GB+ 显存。超过单卡容量就必须用 FSDP/ZeRO 或 TP/PP。

与 FSDP/ZeRO 的关系：FSDP/ZeRO 是 DP 的改进版，将模型参数也分片到各卡，解决单卡放不下的问题。
关联论文/模型：PyTorch DDP (DistributedDataParallel)；所有多卡训练的基础
权威分析链接：
- https://docs.pytorch.org/docs/stable/generated/torch.nn.parallel.DistributedDataParallel.html
- https://docs.vllm.ai/en/latest/serving/parallelism_scaling.html

Tensor Parallelism

缩写：TP
中文名称：张量并行
简短介绍：将单个层的权重矩阵按行或列切分到多张 GPU 上，各卡并行计算矩阵乘法的不同部分，再通过 AllReduce/AllGather 拼接结果。实现层内并行，是 MoE 大模型推理的标配。
详细介绍：TP 的两种切分方式：
1. Column Parallelism（列并行）：W 按 output 维度切分
  - 各卡计算 Y_i = X · W_i（输入相同，权重不同）
  - 输出拼接需 AllGather
2. Row Parallelism（行并行）：W 按 input 维度切分
  - 各卡计算 Y_i = X_i · W（输入不同，权重相同）
  - 输出求和需 AllReduce
Transformer 层的 TP 策略（Megatron 方案）：
- Attention：Q/K/V 投影用列并行（按 head 切分，天然并行），输出投影用行并行
- FFN：第一个 Linear 列并行，第二个 Linear 行并行
- 一层内只需 2 次 AllReduce（attention 后 + FFN 后）
TP 的通信开销：每层 2 次 AllReduce，通信量 = 2 × hidden_size × seq_len × batch × 2 (send+recv)。

TP 度数选择：通常 TP=2/4/8（受 NVLink 带宽限制，跨节点 TP 性能差）。推理时 TP=N 意味着 N 张卡共同服务一个请求。

vLLM 推理：–tensor-parallel-size N

与 EP 的关系：MoE 模型通常 TP + EP 组合——注意力用 TP，专家用 EP。
关联论文/模型：“Megatron-LM” (Shoeybi et al., 2019, arXiv:1909.08053)；DeepSeek V3 (TP=8)；GLM-5 (TP=8)；vLLM 推理标配
权威分析链接：
- https://docs.vllm.ai/en/latest/serving/parallelism_scaling.html
- https://arxiv.org/abs/1909.08053

Pipeline Parallelism

缩写：PP
中文名称：流水线并行
简短介绍：将模型的不同层分配到不同 GPU 上，数据像流水线一样依次通过各卡。解决单卡放不下深层模型的问题，但有流水线气泡（bubble）开销。
详细介绍：PP 的工作方式：

将 L 层模型分到 N 个 stage（GPU），每个 stage 处理 L/N 层。 GPU 0 (layer 0-15) → GPU 1 (layer 16-31) → … → GPU N-1 (layer L-N*16 ~ L-1)

问题：朴素 PP 下，GPU 0 计算 forward 时 GPU 1~N-1 空闲 → 气泡占比 1-1/N。

GPipe 方案（微批次填充）：
- 将一个 batch 分成 M 个 micro-batch
- M 个 micro-batch 流水通过各 stage
- 气泡占比 = (N-1) / (M+N-1)，M 越大气泡越小
1F1B 调度（Megatron）：交替执行 1 个 forward + 1 个 backward，减少激活值内存峰值。

PP 的通信：stage 间传递隐状态，通信量 = hidden_size × batch × seq_len，比 TP 小得多（适合跨节点）。

PP 在推理中的应用：较少用于推理（推理无反向传播，气泡问题不同），主要用于训练。vLLM V1 已支持 PP 推理。

注意：推测解码（Speculative Decoding）长期与 PP 不兼容，vLLM V1 近期才解决。
关联论文/模型：“GPipe” (Huang et al., 2019, arXiv:1811.06965)；Megatron-LM (1F1B 调度)；DeepSpeed
权威分析链接：
- https://docs.vllm.ai/en/latest/serving/parallelism_scaling.html
- https://arxiv.org/abs/1811.06965

Expert Parallelism

缩写：EP
中文名称：专家并行
简短介绍：MoE 模型专用并行策略，将不同的专家（expert）分配到不同 GPU 上，每个 token 通过 All-to-All 通信路由到对应专家所在的卡上计算。
详细介绍：EP 的核心流程：
1. Router 在每卡本地计算路由（哪些 token 去哪些专家）
2. All-to-All 通信：将 token 发送到目标专家所在 GPU
3. 各卡上的专家计算 FFN
4. All-to-All 通信：将结果送回原始卡
5. Router 加权合并结果
EP 的通信模式：2 次 All-to-All（dispatch + combine），通信量取决于 token 数和激活专家数。

EP 度数：通常等于专家数或其因子。如 DeepSeek V3 有 256 个专家，EP=256 意味着每卡 1 个专家。实际中 EP=8/16/32 更常见（每卡多个专家）。

TP + EP 组合（大 MoE 模型标配）：
- Attention 层：TP 切分（按 head 分卡）
- MoE 层：EP 切分（按 expert 分卡）
- 示例：DeepSeek V3 训练用 TP=8 + EP=32 + DP=… + PP=…
EP 的挑战：
- 负载不均衡：某些专家被选中的 token 多，导致某些 GPU 过载
- All-to-All 通信：跨节点延迟高，需要高效通信库（如 NCCL）
- DeepSeek V3 的无辅助损失路由策略帮助均衡
关联论文/模型：“GShard” (Lepikhin et al., 2020, arXiv:2006.16668)；“Switch Transformer” (Fedus et al., 2021, arXiv:2101.03961)；DeepSeek V3 (技术报告)；GLM-5 (技术报告)
权威分析链接：
- https://docs.vllm.ai/en/latest/serving/parallelism_scaling.html
- https://arxiv.org/abs/2101.03961

Context Parallelism

缩写：CP
中文名称：上下文并行
简短介绍：将输入序列按长度维度切分到多张 GPU 上，各卡并行处理序列的不同段落，通过环式通信交换 KV 实现完整注意力。用于超长上下文训练和推理。
详细介绍：CP 解决的问题：

长序列（128K~1M token）的注意力计算 O(n^2) 和 KV Cache 内存超出单卡容量。CP 将序列分段，多卡协作完成注意力。

工作方式（Ring Attention / Ulysses 两种方案）：

Ring Attention：
1. 序列分成 N 段，每卡持有 1 段的 Q/K/V
2. KV 在卡间环形传递，每卡依次与其他段的 K/V 做注意力
3. N 步后完成完整注意力计算
Ulysses（DeepSpeed Ulysses）：
1. 序列按 head 维度分卡（不是按序列位置）
2. 通过 All-to-All 将 Q/K/V 重排为每卡持有所有位置的部分 head
3. 各卡独立计算部分 head 的完整注意力
4. 再 All-to-All 重排回去
使用 CP 的模型：DeepSeek V3（训练用 CP）、GLM-5（1M 上下文训练）、Kimi Linear（1M 上下文）。

vLLM 推理中：CP 用于超长上下文推理（如 1M token），–context-parallel-size N。
关联论文/模型：“Ring Attention” (Liu et al., 2023, arXiv:2310.01889)；“DeepSpeed Ulysses” (Microsoft, 2023)；DeepSeek V3 训练
权威分析链接：
- https://docs.vllm.ai/en/latest/serving/parallelism_scaling.html
- https://arxiv.org/abs/2310.01889

Sequence Parallelism

缩写：SP
中文名称：序列并行
简短介绍：将序列的激活值沿序列维度切分到多卡，主要用于减少 TP 中 LayerNorm 和 Dropout 的冗余计算和内存。与 CP 类似但侧重点不同——SP 是 TP 的辅助，CP 是独立的注意力并行。
详细介绍：SP 的两种含义：
1. Megatron SP（TP 辅助）：
  - TP 只切分 Q/K/V/FFN 矩阵，LayerNorm 和 Dropout 在所有 TP 卡上冗余计算
  - SP 将 LayerNorm/Dropout 的激活沿序列维度切分，各卡只处理部分 token
  - 在进入 TP 层前用 AllGather 恢复完整序列
  - 减少激活内存，但增加通信
2. DeepSpeed Ulysses SP（= CP 的一种实现）：
  - 与上述 Megatron SP 不同，是独立的序列维度并行
  - 通过 All-to-All 重排 head 和 sequence 维度
Megatron SP 与 CP 的区别：
- SP：只切分非 TP 部分（LayerNorm/Dropout），注意力仍在单卡完整计算
- CP：注意力本身也并行化，多卡协作完成完整注意力
实践中 SP 通常与 TP 配合使用（TP+SP），而 CP 可独立使用。
关联论文/模型：“Megatron-LM” (arXiv:2104.04473, SP 部分)；DeepSpeed Ulysses
权威分析链接：
- https://github.com/NVIDIA/Megatron-LM

Fully Sharded Data Parallelism

缩写：FSDP
中文名称：全分片数据并行
简短介绍：DP 的进化版，将模型参数、梯度、优化器状态全部分片到各 GPU，计算时按需 AllGather 恢复完整参数，反向后 ReduceScatter 分片梯度。PyTorch 原生支持的大模型训练方案。
详细介绍：FSDP 的工作流程：

前向传播：
1. 进入某层前，AllGather 从各卡收集该层完整参数
2. 用完整参数计算前向
3. 计算完后立即丢弃完整参数，只保留本卡分片（节省显存）
反向传播：
1. 再次 AllGather 恢复该层参数
2. 计算梯度
3. ReduceScatter 将梯度按分片同步到各卡
4. 各卡用本地分片梯度更新本地分片的优化器状态
显存节省：模型参数+梯度+优化器从全量 (16+16+32 = 64 bytes/param, fp32 AdamW) 降至 1/N。7B 模型在 N=8 卡上每卡仅需 ~8GB 而非 ~56GB。

FSDP vs ZeRO-3：两者原理几乎相同，FSDP 是 PyTorch 原生实现，ZeRO-3 是 DeepSpeed 实现。FSDP 更易用，ZeRO 配置更灵活。

FSDP 的分层分片（nested FSDP / per-layer sharding）：可按层粒度分片，进一步减少峰值显存（只需单层完整参数在内存中）。

混合并行：FSDP + TP + PP 可组合使用。如 FSDP(dp=4) + TP(tp=8) + PP(pp=2) 用于超大模型。
关联论文/模型：“PyTorch FSDP” (Zhao et al., 2023, arXiv:2304.11277)；PyTorch 2.x 原生支持；Llama 3 训练
权威分析链接：
- https://docs.pytorch.org/docs/stable/fsdp.html
- https://arxiv.org/abs/2304.11277

Zero Redundancy Optimizer

缩写：ZeRO
中文名称：零冗余优化器
简短介绍：DeepSpeed 提出的训练内存优化方案，逐步消除 DP 中的冗余：ZeRO-1 分片优化器状态，ZeRO-2 额外分片梯度，ZeRO-3 额外分片参数。FSDP 的理论基础。
详细介绍：ZeRO 的三个阶段：

基线（纯 DP）：每卡存储完整参数(P) + 梯度(G) + 优化器状态(O)
- 以 7B 模型 fp32 AdamW 为例：P=28GB, G=28GB, O=56GB → 共 112GB/卡
ZeRO-1：分片优化器状态 O → 每卡 1/N 的 O
- 节省：56GB → 56/N GB。总显存 28+28+56/N
ZeRO-2：额外分片梯度 G → 每卡 1/N 的 G 和 O
- 节省：(28+56)/N。总显存 28+84/N
- 反向后只同步本卡负责的参数的梯度
ZeRO-3：额外分片参数 P → 每卡 1/N 的 P、G、O
- 节省：全部 112/N。7B 模型 8 卡只需 14GB/卡
- 前向/反向需 AllGather 恢复完整参数（= FSDP）
通信代价：
- ZeRO-1/2：与纯 DP 相同（1 次 AllReduce 梯度），无额外通信
- ZeRO-3：每层 1 次 AllGather(前向) + 1 次 ReduceScatter(反向)，通信量增加
ZeRO-Infinity：进一步将分片卸载到 CPU 内存和 NVMe SSD，突破 GPU 显存限制。

实践选择：ZeRO-2 是性能和内存的最佳平衡点（无额外通信开销）。ZeRO-3 用于单卡放不下的超大模型。
关联论文/模型：“ZeRO: Memory Optimizations Toward Training Trillion Parameter Models” (Rajbhandari et al., 2020, arXiv:1910.02054)；DeepSpeed；FSDP 基于此设计
权威分析链接：
- https://www.deepspeed.ai/tutorials/zero/
- https://arxiv.org/abs/1910.02054

本篇小结

本篇 8 个并行策略术语沿"切什么维度 + 内存如何分片"两条线归位：

DP 每卡完整模型分不同数据，最简单但要求单卡放下完整模型；反向后 AllReduce 同步梯度。
TP 层内切权重矩阵，各卡算矩阵乘法的不同部分再 AllReduce/AllGather 拼接；NVLink 域内有效，是 MoE 大模型推理标配。
PP 层间切分，数据像流水线依次通过各卡，解决深模型单卡放不下的问题，但有流水线气泡开销；GPipe 和 1F1B 两种调度。
EP MoE 专用，把不同专家分到不同 GPU，token 通过 All-to-All 通信路由到专家所在卡。
CP 把输入序列按长度切分到多卡，各卡处理不同段落并通过环式通信交换 KV 实现完整注意力；用于超长上下文训练和推理。
SP 切序列的激活值，主要用于减少 TP 中 LayerNorm/Dropout 的冗余计算；是 TP 的辅助，与 CP 的区别是 SP 依附于 TP、CP 是独立的注意力并行。
FSDP DP 的进化版，参数/梯度/优化器状态全部分片，计算时按需 AllGather 恢复完整参数；PyTorch 原生支持的大模型训练方案。
ZeRO DeepSpeed 的内存优化三阶段：ZeRO-1 分片优化器状态、ZeRO-2 加分片梯度、ZeRO-3 加分片参数（= FSDP）；ZeRO-2 是性能与内存的最佳平衡点（无额外通信），ZeRO-3 用于单卡放不下的超大模型。

组合关系：大模型训练标配 TP+EP+PP+DP/ZeRO 多维并行（TP 在 NVLink 域内、PP 跨节点、DP/ZeRO 切数据、EP 切专家），推理标配 TP+EP。FSDP 是 ZeRO-3 的工程实现，两者理论基础一致。

本系列共 11 篇，本文是第 6 篇。

LLM 术语全景图（五）：推理优化——从推测解码到 Flash Attention

Mon, 27 Jul 2026 10:00:00 +0800

这是「大模型训练与推理术语全景图」系列的第 5 篇，覆盖推理优化的 5 个概念：Speculative Decoding、PagedAttention、Continuous Batching、Quantization（总览）、Flash Attention。主要参考框架/论文：vLLM、FlashAttention、Orca、DeepSeek V3 MTP

开篇：推理优化的两个方向

推理优化沿两个方向展开。第一是减少单位计算的代价：Flash Attention 通过 tiling 重排注意力计算的内存访问模式，把 HBM 与 SRAM 之间的读写复杂度从 O(n²) 降到 O(n²/M)，不改变注意力的数学结果；Quantization 把权重/激活从 BF16 降到 INT8/INT4/FP8，直接压低显存占用和每步访存量。第二是提高 GPU 利用率：PagedAttention 把 KV Cache 切成固定 block 按需分配，消除碎片让显存利用率从 ~20% 提升到 ~96%；Continuous Batching 在每个 iteration 动态进出请求，避免短序列空等长序列；Speculative Decoding 用小模型先起草、大模型并行验证，减少 decode 步数。本篇按这两个方向梳理 5 个推理优化术语。

推理优化（Inference Optimization）

Speculative Decoding

缩写：SpecDec / 推测解码
中文名称：推测解码
简短介绍：用小模型（draft model）快速生成候选 token，大模型（target model）并行验证，接受正确的候选 token 以加速推理。典型加速 2-3 倍，输出完全无损。
详细介绍：推测解码的工作流程：
1. Draft：小模型快速生成 k 个候选 token {t_1, t_2, …, t_k}
2. Verify：大模型一次前向传播，并行计算这 k 个 token 的概率
3. Accept/Reject：对每个候选 token，如果大模型也认为正确则接受，否则从拒绝点重新采样
关键性质：输出分布与纯大模型生成完全一致（无损），通过拒绝采样保证数学等价。

变体：
- 标准 SpecDec：独立的小模型作为 draft
- MTP 推测：DeepSeek V3/R1 用训练时 MTP 模块作为内置 draft model
- Medusa：多头并行预测
- EAGLE：在隐空间而非 token 空间做推测
vLLM 中的使用： –speculative-config=’{“method”: “deepseek_mtp”, “num_speculative_tokens”: 1}'

性能：典型场景加速 2-3x，但加速比取决于 draft 模型的接受率（accept rate）。

注意：推测解码目前与 Pipeline Parallelism 不兼容（vLLM V1 已部分解决）。
关联论文/模型：“Speculative Decoding” (Leviathan et al., 2023, arXiv:2211.17192)；DeepSeek V3 MTP (技术报告)；EAGLE、Medusa
权威分析链接：
- https://rocm.docs.amd.com/projects/ai-developer-hub/en/latest/notebooks/inference/mtp.html
- https://docs.vllm.ai/en/latest/features/spec_decode.html

PagedAttention

缩写：—
中文名称：分页注意力
简短介绍：vLLM 提出的 KV Cache 管理方法，将 KV Cache 分为固定大小的块（page），按需分配，类似操作系统的虚拟内存分页机制，大幅减少显存碎片和浪费。
详细介绍：PagedAttention 的设计：

传统方式：为每个序列预分配最大长度的连续 KV Cache 空间问题：实际序列通常远短于最大长度，造成大量显存浪费和碎片

PagedAttention：
- 将 KV Cache 分为固定大小的 block（如 16 token/block）
- 每个序列维护一个 block table（类似页表），映射逻辑位置到物理 block
- 按需分配 block，不需要预分配最大长度
- 显存利用率从 ~20% 提升到 ~96%
优势：
- 支持更大的 batch size（更多并发请求）
- 允许变长序列（无需预知长度）
- 支持共享 KV（如 beam search 共享 prefix）
PagedAttention 是 vLLM 高吞吐推理的核心技术，已被广泛集成到主流推理框架。
关联论文/模型：“Efficient Memory Management for LLMs with PagedAttention” (Kwon et al., 2023, arXiv:2309.06180)；vLLM
权威分析链接：
- https://docs.vllm.ai/

Continuous Batching

缩写：—
中文名称：连续批处理 / 动态批处理
简短介绍：在推理过程中动态插入新请求和移除已完成请求，而非等待整个 batch 全部完成。与 PagedAttention 配合实现高吞吐推理。
详细介绍：传统静态批处理 vs 连续批处理：

静态批处理：batch 中最长的序列决定整个 batch 的等待时间，短序列 GPU 空闲连续批处理：每个 iteration 检查 batch，完成的请求移出，新请求加入

配合 PagedAttention，不同序列可以不同长度、不同阶段（prefill/decode 混合），实现 GPU 持续高利用率。

vLLM、TGI、SGLang 等推理框架均采用连续批处理作为基础调度策略。
关联论文/模型：vLLM (arXiv:2309.06180)；Orca (OSDI 2022)
权威分析链接：
- https://docs.vllm.ai/

Quantization

缩写：Quant / 量化
中文名称：模型量化
简短介绍：将模型参数从高精度（FP32/FP16/BF16）降至低精度（INT8/INT4/FP8），减少显存占用和推理延迟。分为训练后量化（PTQ）和量化感知训练（QAT）。
详细介绍：主要量化方案：

按精度：
- FP8：Hopper GPU 原生支持，几乎无损
- INT8：W8A8（权重和激活都 INT8），精度损失较小
- INT4：W4A16（权重 INT4，激活 FP16），显存大幅减少但需要校正
- GGUF：llama.cpp 格式，支持 2-8 bit 量化
按方法：
- PTQ（Post-Training Quantization）：训练后直接量化，简单快速
  - GPTQ：基于二阶信息的逐层量化
  - AWQ：保护重要权重的激活感知量化
  - SmoothQuant：将量化难度从激活转移到权重
- QAT（Quantization-Aware Training）：训练时模拟量化，精度更高但需训练
实际效果（以 70B 模型为例）：
- BF16：~140 GB（需 2×A100 80GB）
- INT8：~70 GB（1×A100 80GB）
- INT4：~35 GB（1×A100 40GB 可行）
趋势：FP8 量化成为 Hopper/Blackwell GPU 上的主流选择，近乎无损且硬件原生支持。

本条为量化总览，按精度和按方法的分类到此为止；具体量化方法（GPTQ / AWQ / SmoothQuant / FP8 详析等）见篇 8。
关联论文/模型：GPTQ (arXiv:2210.17323)；AWQ (arXiv:2306.00978)；SmoothQuant (arXiv:2211.10438)；llama.cpp GGUF
权威分析链接：
- https://docs.vllm.ai/en/latest/features/quantization/

Flash Attention

缩写：FA / FlashAttn
中文名称：闪存注意力
简短介绍：通过重新组织注意力计算的内存访问模式，减少 GPU HBM 和 SRAM 之间的读写次数，在不改变注意力数学结果的情况下加速计算 2-4 倍。
详细介绍：Flash Attention 的核心思想：

问题：标准注意力的中间矩阵 (Q·K^T) 大小为 n×n，远超 GPU SRAM 容量，需频繁读写 HBM 方案：将 Q/K/V 分块加载到 SRAM，计算局部注意力并累积结果，避免实例化完整 n×n 矩阵

关键技术：
1. Tiling：将 Q/K/V 分块，每次处理一个块
2. Recomputation：反向传播时不存储中间矩阵，重新计算（省显存但略增计算）
3. Online Softmax：分块计算 softmax 的数值稳定算法
性能：
- 前向传播：减少 HBM 读写，IO 复杂度从 O(n^2) 降至 O(n^2 / M)，M 为 SRAM 大小
- 反向传播：不存储 attention matrix，显存从 O(n^2) 降至 O(n)
- 实测加速：2-4x（取决于序列长度和硬件）
Flash Attention 已成为 LLM 训练和推理的标准组件，PyTorch 2.0+ 内置支持。

版本演进：FA1 (2022) → FA2 (2023, 更高效) → FA3 (2024, 支持 FP8)

注意：Flash Attention 是计算优化，不改变注意力的数学结果。与稀疏注意力（DSA/SWA）是正交概念——前者优化"怎么算"，后者改变"算什么"。
关联论文/模型：“FlashAttention: Fast and Memory-Efficient Exact Attention” (Dao et al., 2022, arXiv:2205.14135)；FlashAttention-2 (Dao, 2023)；FlashAttention-3 (2024)
权威分析链接：
- https://github.com/Dao-AILab/flash-attention

本篇小结

Speculative Decoding（推测解码） 用 draft model 起草、target model 并行验证，输出分布通过拒绝采样与纯大模型生成数学等价（无损），典型加速 2-3x；与 Pipeline Parallelism 不兼容，vLLM V1 已部分解决。
PagedAttention 把 KV Cache 切成固定 block 按需分配，配 block table 类比操作系统的虚拟内存分页，显存利用率从 ~20% 提升到 ~96%，是 vLLM 高吞吐的核心。
Continuous Batching 在每个 iteration 动态进出请求，配合 PagedAttention 让 prefill/decode 混合、变长序列共存，GPU 持续高利用率；源自 Orca (OSDI 2022)。
Quantization 按精度（FP8/INT8/INT4/GGUF）和按方法（PTQ vs QAT）两条轴分类；70B 模型 BF16 ~140GB / INT8 ~70GB / INT4 ~35GB；具体量化方法见篇 8。
Flash Attention 用 tiling + online softmax 把 IO 复杂度从 O(n²) 降到 O(n²/M)（M 为 SRAM 大小），是计算优化而非改变注意力数学；与稀疏注意力（DSA/SWA）正交——前者优化"怎么算"，后者改变"算什么"。

本系列共 11 篇，本文是第 5 篇。

LLM 术语全景图（四）：训练方法——从 RLHF 到 GRPO 的演进

Mon, 27 Jul 2026 09:45:00 +0800

这是「大模型训练与推理术语全景图」系列的第 4 篇，覆盖训练方法的 6 个概念：GRPO、RLHF、DPO、SFT、Knowledge Distillation、Muon Optimizer。主要参考模型：DeepSeek R1、Qwen3、Llama 3、Kimi K2、GPT-4

开篇：后训练范式的三个阶段

后训练（post-training）在 2022-2026 年间走过三个可辨识的阶段。第一阶段是 SFT（Supervised Fine-Tuning）：用人工标注的高质量 (prompt, response) 对微调预训练基座，让模型学会遵循指令、采用对话格式输出，几乎所有对话 LLM 的第一步后训练都是 SFT。第二阶段是 RLHF/DPO 对齐人类偏好：RLHF 先训练 Reward Model 再用 RL 优化，DPO 则跳过 Reward Model 直接从偏好数据优化，目标是让模型输出符合人类对"有用、无害、诚实"的偏好。第三阶段是 GRPO/RLVR 用可验证奖励驱动推理能力涌现：RLVR（RL with Verifiable Rewards）用规则验证奖励（如数学答案对错、代码测试通过）替代学到的 Reward Model，GRPO 去掉 PPO 的 Critic 用组内相对优势做基线。DeepSeek R1-Zero 跳过 SFT 直接做纯 GRPO（RLVR）就涌现出长链推理和"Aha Moment"，是这一阶段的标志性事件——它证明 RL 可独立于 SFT 涌现推理能力，但 R1 正式版仍加入 SFT 阶段以提升最终可用性。本篇按这条主线梳理 6 个训练方法术语。

训练方法（Training Methods）

Group Relative Policy Optimization

缩写：GRPO
中文名称：组相对策略优化
简短介绍：DeepSeek 提出的强化学习算法，去除 PPO 的独立价值网络（critic），改用同一 prompt 的多个采样响应的组内平均作为基线，大幅降低训练内存和计算成本。
详细介绍：GRPO vs PPO：

PPO 需要训练 4 个模型：Actor、Critic、Reward Model、Reference Model GRPO 只需 3 个：Actor、Reward Model、Reference Model（去掉 Critic）

GRPO 的优势计算：
1. 对同一 prompt x，采样 G 个响应 {o_1, …, o_G}
2. 用 Reward Model 或规则打分得到 {r_1, …, r_G}
3. 组内归一化：advantage_i = (r_i - mean(r)) / std(r)
4. 用 advantage 更新 Actor（带 PPO 的 clip 机制）
关键优势：
- 省去 Critic 模型——PPO 需训练 Actor 和 Critic 两个模型，GRPO 只训练 Actor 一个，需训练的模型显存减少约一半
- 组内相对比较天然适合推理任务（数学/代码有明确对错）
- DeepSeek R1-Zero 证明纯 RL（无 SFT）也能涌现推理能力（“Aha Moment”）
DeepSeek R1 训练流程：
1. R1-Zero：V3 基座 → 纯 GRPO（无 SFT）→ 涌现推理
2. R1：V3 基座 → 少量 SFT（CoT 数据）→ GRPO → SFT（600K+200K 样本）→ GRPO
采用 GRPO 的模型：DeepSeek R1、Qwen3（部分阶段）、Kimi K1.5 等。
关联论文/模型：“DeepSeekMath” (arXiv:2402.03300, 首次提出 GRPO)；DeepSeek R1 (arXiv:2501.12948)
权威分析链接：
- https://snorkel.ai/grpo
- https://huggingface.co/learn/llm-course/en/chapter12/3
- https://www.youtube.com/watch?v=bAWV_yrqx4w (Yannic Kilcher GRPO 讲解)

Reinforcement Learning from Human Feedback

缩写：RLHF
中文名称：基于人类反馈的强化学习
简短介绍：通过人类偏好数据训练奖励模型，再用该奖励模型通过 RL 优化 LLM 输出。ChatGPT 的核心训练方法，使模型输出符合人类偏好。
详细介绍：RLHF 的标准三阶段：
1. SFT（监督微调）：用人类标注的高质量对话微调基座模型
2. Reward Model 训练：用人类偏好评判数据（A > B 或评分）训练奖励模型
3. RL 优化：用 PPO/GRPO 等算法，以 Reward Model 的分数为奖励优化 SFT 模型
关键组件：
- Preference Data：人类标注 (prompt, response_A, response_B, preference)
- Reward Model：学习预测人类偏好分数
- Reference Model：KL 散度约束，防止 RL 优化偏离原始分布
变体：
- RLAIF：用 AI（而非人类）生成偏好数据，降低标注成本
- DPO（Direct Preference Optimization）：跳过 Reward Model，直接从偏好数据优化
- RLVR（RL with Verifiable Rewards）：规则验证奖励（如数学答案对错），无需 Reward Model
GPT-4/Claude 的训练使用 RLHF；DeepSeek R1 使用 RLVR + GRPO；Qwen3 使用 DPO + GRPO 组合。
关联论文/模型：“InstructGPT” (Ouyang et al., 2022, arXiv:2203.02155)；“Constitutional AI” (Claude, Anthropic)；ChatGPT、GPT-4、Claude
权威分析链接：
- https://huggingface.co/learn/llm-course/en/chapter12/3
- https://www.turingpost.com/p/attention-types

Direct Preference Optimization

缩写：DPO
中文名称：直接偏好优化
简短介绍：跳过显式 Reward Model 训练，直接从偏好数据对优化 LLM。将 RLHF 的两阶段（训练 RM + RL 优化）简化为单阶段，训练更简单稳定。
详细介绍：DPO 的核心思想：

传统 RLHF：偏好数据 → 训练 RM → RL 优化 Actor DPO：偏好数据 → 直接优化 Actor（用特定损失函数）

DPO 损失：

L_DPO = -log σ(β · [log π(y_w|x)/π_ref(y_w|x) - log π(y_l|x)/π_ref(y_l|x)])

其中 y_w 是偏好响应，y_l 是不偏好响应，π 是当前策略，π_ref 是参考策略。

优势：无需训练和部署独立的 Reward Model，训练流程更简单，显存更少。劣势：对偏好数据质量更敏感，不如 PPO/GRPO 灵活。

采用 DPO 的模型：Qwen3（部分后训练阶段）、Llama 3 Instruct、Mistral 等。
关联论文/模型：“Direct Preference Optimization” (Rafailov et al., 2023, arXiv:2305.18290)；Llama 3、Qwen3
权威分析链接：
- https://huggingface.co/learn/llm-course/en/chapter12

Supervised Fine-Tuning

缩写：SFT
中文名称：监督微调
简短介绍：用人工标注的高质量输入-输出对微调预训练基座模型，使其学会遵循指令和对话格式。几乎所有对话 LLM 的第一步后训练。
详细介绍：SFT 的训练方式：

输入：高质量 (prompt, response) 对损失：标准的 next-token prediction loss（仅在 response 部分计算）

数据规模：
- DeepSeek R1：SFT 阶段使用 600K 推理样本 + 200K 通用样本
- Qwen3：数十万到百万级 SFT 样本
- Llama 3：超过 10M 对话样本
SFT 在训练流程中的位置：
- 预训练（海量无标注文本）→ SFT（标注对话）→ RLHF/DPO（偏好优化）
DeepSeek R1 的特殊路径：R1-Zero 跳过 SFT 直接做纯 RL，证明 RL 可独立涌现推理能力。但 R1 正式版仍加入了 SFT 阶段以提升可用性。
关联论文/模型：“InstructGPT” (Ouyang et al., 2022)；DeepSeek R1 (技术报告)；Qwen3 (技术报告)
权威分析链接：
- https://huggingface.co/learn/llm-course/en/chapter12

Knowledge Distillation

缩写：KD / 蒸馏
中文名称：知识蒸馏
简短介绍：用大模型（教师）的输出训练小模型（学生），使小模型获得接近大模型的能力。DeepSeek R1 用 R1 蒸馏出多个小模型。
详细介绍：LLM 蒸馏的常见方式：
1. 输出蒸馏（Output Distillation / 黑盒蒸馏）：
  - 用教师模型生成高质量响应（含 CoT 推理链）
  - 将这些响应作为 SFT 数据训练学生模型
  - DeepSeek R1 的做法：用 R1 生成 800K 推理数据，蒸馏到 Qwen/Llama 1.5B~70B（官方写法为 Llama-3.1-8B-Base 和 Llama-3.3-70B-Instruct）
2. Logits 蒸馏（白盒蒸馏）：
  - 学生模型学习教师模型的 logits 分布（软标签）
  - 损失：KL(p_teacher || p_student)
  - 保留更多信息（比硬标签丰富）
DeepSeek R1 蒸馏模型表现（技术报告表格）：
- R1-Distill-Qwen-1.5B 在 AIME 28.9%，超过 GPT-4o
- R1-Distill-Qwen-7B 在 AIME 55.5%
- R1-Distill-Qwen-32B 接近 o1-mini
注意：蒸馏不能创造新能力，只能传递教师已有的能力。学生模型的上限是教师模型。
关联论文/模型：DeepSeek R1 (arXiv:2501.12948, 蒸馏部分)；“Distilling Reasoning” 等
权威分析链接：
- https://huggingface.co/learn/llm-course/en/chapter12/3

Muon Optimizer

缩写：Muon
中文名称：Muon 优化器
简短介绍：基于矩阵正交化的新型优化器，对 2D 参数矩阵做 SVD 正交化后再更新梯度，收敛速度快于 AdamW。DeepSeek V4 等新一代模型采用。
详细介绍：Muon 的核心思想：

标准 Adam/AdamW：对每个参数的梯度做一阶/二阶动量估计 Muon：对 2D 权重矩阵的梯度做正交化（Newton-Schulz 迭代近似 SVD），然后更新

特点：
- 仅适用于 2D 矩阵参数（Linear 层权重），1D 参数（bias、norm）仍用 AdamW
- 正交化使更新方向更稳定，减少训练震荡
- 收敛更快：在同等性能下可减少训练步数
采用 Muon 的模型：DeepSeek V4（Muon-based optimization）；Kimi K2（MuonClip，Muon 的改进版本）

注意：Muon 是 2025 年出现的新优化器，生态尚在发展，但已被多个大型模型验证有效。
关联论文/模型：“Muon” (J. Jordan, 2024-2025)；DeepSeek V4 (技术报告)；Kimi K2 技术报告 (MuonClip)
权威分析链接：
- https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures (DeepSeek V4 部分)

本篇小结

本篇 6 个训练方法术语沿"后训练三阶段"归位：

SFT 是几乎所有对话 LLM 的第一步，用标注 (prompt, response) 对教会模型对话格式；DeepSeek R1-Zero 跳过 SFT 直接 RL 是例外而非通则，R1 正式版仍回归 SFT。
RLHF 用学到的 Reward Model 优化人类偏好，标准三阶段（SFT → RM → RL）；DPO 跳过 RM 直接从偏好数据优化，单阶段更简单但对数据质量更敏感。
GRPO 去掉 PPO 的 Critic，用组内相对优势做基线，需训练的模型从 2 个减到 1 个（Actor），显存减少约一半（按"需训练的模型"计）。GRPO 配合 RLVR 的可验证奖励，是 R1-Zero 涌现推理的算法载体。
Knowledge Distillation 不创造新能力，只传递教师已有能力；R1 蒸馏 800K 推理数据到 Qwen 1.5B~32B 和 Llama 8B/70B，其中 R1-Distill-Qwen-1.5B 在 AIME 28.9% 已超过 GPT-4o。
Muon Optimizer 是 2025 年新优化器，对 2D 矩阵参数做正交化更新，已被 DeepSeek V4 和 Kimi K2（MuonClip）采用，生态发展中。

本系列共 11 篇，本文是第 4 篇。系列导航见：LLM 术语全景图系列导读。

LLM 术语全景图（三）：模型架构——MoE 与残差连接的演进

Mon, 27 Jul 2026 09:30:00 +0800

这是「大模型训练与推理术语全景图」系列的第 3 篇，覆盖模型架构的 8 个概念：MoE、MTP、mHC、RoPE、YaRN、RMSNorm、SwiGLU、KV Cache。主要参考模型：DeepSeek V3/V4、GLM-5、Kimi K2、Llama 3、Mixtral

开篇：模型架构的三条演进线

把 2023 年到 2026 年的主流 LLM 架构按时间铺开，能清晰看到三条并行的演进线，本篇的 8 个概念分别落在其中。

第一条线是 FFN 的 MoE 化。 稠密 FFN 被替换为多个并行专家，路由器为每个 token 只激活少量专家。结果是模型总参数量大幅膨胀（DeepSeek V3 达 671B、Kimi K2 达 1T），但单次前向的激活参数仍保持在 30B-40B 量级，激活比压到 5% 上下。MoE 让"大参数量"与"低激活成本"第一次解耦。

第二条线是残差连接从单流到多流。 标准 ResNet 残差是 y = x + F(x) 的单残差通路；Hyper-Connections 把它扩展为 n 个并行残差流，并用 Pre/Res/Post 三类映射在层间混合；mHC 进一步把 Res Mapping 约束到双随机矩阵流形，避免深层堆叠时信号不可预测地放大或缩小。残差通路变宽，但 FLOPs 几乎不增。

第三条线是基础组件趋于稳定。 位置编码收敛到 RoPE（长上下文用 YaRN 扩展），归一化收敛到 RMSNorm 的 Pre-Norm 用法，FFN 激活收敛到 SwiGLU，KV Cache 则成为所有自回归推理绕不开的物理瓶颈。这三类组件已没有太多设计争议，新一代模型主要在 MoE 和残差结构上做差异化。

下面逐一展开。

模型架构（Architecture Components）

Mixture of Experts

缩写：MoE
中文名称：混合专家模型
简短介绍：将 FFN 层替换为多个并行的"专家"网络，通过路由器（router/gate）为每个 token 选择少量专家激活，实现大参数量但低激活成本的模型。

详细介绍：MoE 的核心计算：

Router 计算：g(x) = softmax(W_gate · x)，为每个专家打分
Top-k 选择：选出得分最高的 k 个专家
加权输出：y = Σ g_i(x) · Expert_i(x)，仅对选中的 k 个专家计算

关键设计选择：

专家数量：DeepSeek V3 有 256 个路由专家 + 1 个共享专家；Qwen3-235B 有 128 个专家
Top-k：通常 k=1~8，DeepSeek V3 激活 8 个路由专家 + 1 个共享专家
共享专家（Shared Expert）：所有 token 都经过的专家，提供通用知识，DeepSeek MoE 首创

代表模型的 MoE 配置：

模型	总参数	激活参数	激活比	专家数
DeepSeek V3	671B	37B	5.5%	256+1
DeepSeek V4-Pro	~700B+	~30B	~4%	256+1
Kimi K2	1T	32B	3.2%	384+1
Qwen3-235B	235B	22B	9.4%	128
MiniMax-01	456B	46B	10%	32
GLM-5	744B	40B	5.4%	256+1

注：GLM-5 的 744B 总参/40B 激活来自 GLM-5 技术报告（arXiv:2602.15763），激活比 40/744 ≈ 5.4%。DeepSeek V3 的 671B/37B/5.5%/256+1 来自 DeepSeek V3 技术报告（arXiv:2412.19437）。

负载均衡：DeepSeek V3 首创无辅助损失（auxiliary-loss-free）策略，避免传统负载均衡损失损害模型质量。

关联论文/模型：DeepSeekMoE (arXiv:2401.06066)；DeepSeek V3 (技术报告 arXiv:2412.19437)；Qwen3 (技术报告)；Kimi K2 技术报告；GLM-5 (技术报告 arXiv:2602.15763)；Mixtral
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/moe/
- https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

Multi-Token Prediction

缩写：MTP
中文名称：多 Token 预测
简短介绍：训练时不仅预测下一个 token，还同时预测未来第 2、3…个 token，通过额外的预测头增加训练信号密度。推理时可复用 MTP 模块做推测解码。
详细介绍：MTP 的训练目标：

标准 next-token：L = -log P(x_{t+1} | x_{<=t}) MTP-k：L = -Σ_{i=1}^{k+1} log P(x_{t+i} | x_{<=t}, x_{t+1}, …, x_{t+i-1})

DeepSeek V3 使用 MTP-1（预测 1 个额外 token）：
- 主解码器预测 x_{t+1}
- MTP 模块以主解码器的隐状态 + x_{t+1} 为输入，预测 x_{t+2}
- MTP 损失权重通常为 0.1（主损失 + 0.1 × MTP 损失）
推理时的两种用法：
1. 标准：忽略 MTP 头，逐 token 生成（不影响推理）
2. 推测解码：MTP 头作为内置的 draft model，一次预测多个 token，经验证后批量接受
在 vLLM 中启用：--speculative-config='{"method": "deepseek_mtp", "num_speculative_tokens": 1}'

采用 MTP 的模型：DeepSeek V3/R1、DeepSeek V4、GLM-5 系列、Inkling
关联论文/模型：DeepSeek V3 (arXiv:2412.19437, Section 4.4)；DeepSeek R1 (技术报告)
权威分析链接：

Manifold-Constrained Hyper-Connections

缩写：mHC
中文名称：流形约束超连接
简短介绍：DeepSeek V4 引入的残差连接改进，将 Transformer 块中的单残差流扩展为多个并行残差流，并通过双随机矩阵约束确保混合稳定。
详细介绍：mHC 的演进路径：

标准残差连接 → Hyper-Connections (HC) → mHC
1. 标准 ResNet 残差：y = x + F(x)，单残差流
2. Hyper-Connections：将单残差流扩展为 n 个并行残差流
  - Pre Mapping：将 n 个流合并为 1 个隐向量供 Attention/MoE 处理
  - Res Mapping：层间残差流混合（学习矩阵）
  - Post Mapping：将层输出分发回 n 个流
3. mHC 关键约束：
  - Res Mapping 投影到双随机矩阵流形（行和=1、列和=1、非负）
  - Pre/Post Mapping 也约束为非负有界
  - 避免深层堆叠时信号放大/缩小的不可预测行为
DeepSeek V4 使用 n=4 个并行残差流。实测仅增加 6.7% 训练时间开销，但指标可比基线少用一半训练 token 达到同等性能。

核心价值：在几乎不增加 FLOPs 的情况下，使残差通路更宽更表达，且约束保证深层模型稳定性。
关联论文/模型：“mHC: Manifold-Constrained Hyper-Connections” (arXiv:2512.24880, DeepSeek, 2025-12-31)；Hyper-Connections 原始论文 (arXiv:2409.19606, Zhu et al., 2024)；DeepSeek V4 (技术报告)
权威分析链接：
- https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures (Section 5.1)

Rotary Position Embedding

缩写：RoPE
中文名称：旋转位置编码
简短介绍：通过旋转矩阵编码 token 间的相对位置关系，将位置信息融入 Q 和 K 的旋转中，使注意力分数自然反映相对距离。当前绝大多数 LLM 的默认位置编码方案。
详细介绍：RoPE 的数学形式：

对位置 m 的向量 x，将其每两个维度分为一组，旋转角度 θ_i = m · base^(-2i/d)：

R(x, m) = x · R_m，其中 R_m 是分块旋转矩阵

关键性质：
- <R(Q, m), R(K, n)> = <Q, K> 旋转后内积仅依赖相对位置 (m-n)
- base 通常为 10000（LLaMA、DeepSeek V3 等多数模型）；部分长上下文模型（如 Qwen2、GLM-4-1M）调高到 500000~1000000 以利于长上下文外推
外推问题：训练时最大位置 m_max 有限（如 4K），推理时超出范围的角度超出训练分布，质量退化。

采用 RoPE 的模型：LLaMA 全系列、Qwen 全系列、DeepSeek V2/V3、GLM-4、Mistral、Kimi K2 等。

注意：MLA 需要将 RoPE 部分独立处理（RoPE 不兼容低秩压缩），这是 MLA 实现复杂度的来源之一。
关联论文/模型：“RoFormer: Enhanced Transformer with Rotary Position Embedding” (Su et al., 2021, arXiv:2104.09864)；LLaMA、Qwen、DeepSeek、Mistral 等
权威分析链接：
- https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the
- https://www.turingpost.com/p/attention-types

Yet Another RoPE Extension

缩写：YaRN
中文名称：YaRN 上下文扩展
简短介绍：目前最主流的 RoPE 上下文扩展方法，通过分段插值 + 温度缩放，在少量微调（约 400 步）下将上下文从 4K 扩展到 128K+。
详细介绍：YaRN 的核心方法：
1. 分段策略：将 RoPE 的频率维度分为三段
  - 高频段：保持原样（局部信息不需要外推）
  - 中频段：插值 + 温度缩放（平滑过渡）
  - 低频段：纯插值（长距离信息需要外推）
2. 温度缩放：调整 softmax 温度补偿插值带来的注意力分布变化
3. 微调：仅需约 400 步微调即可适应新长度
采用 YaRN 的模型：Qwen 系列（4K→128K）、DeepSeek（4K→128K）、LLaMA 系列、GLM 等。

其他上下文扩展方法对比：
- PI (Position Interpolation)：线性插值所有频率，简单但效果一般
- NTK-aware：调整 base，不微调直接外推
- YaRN：分段 + 温度，当前最优
关联论文/模型：“YaRN: Efficient Context Window Extension” (Peng et al., 2023, arXiv:2309.00071)；Qwen、DeepSeek、LLaMA 系列

RMSNorm

缩写：RMSNorm
中文名称：均方根归一化
简短介绍：LayerNorm 的简化版本，去除均值计算仅用均方根归一化，计算更快且在大规模训练中表现稳定。几乎所有现代 LLM 的默认归一化方案。
详细介绍：RMSNorm vs LayerNorm：

LayerNorm: y = (x - μ) / sqrt(σ^2 + ε) · γ + β RMSNorm: y = x / RMS(x) · γ, 其中 RMS(x) = sqrt(mean(x^2) + ε)

RMSNorm 去掉了均值减法和偏置 β，计算量更小，且在大规模训练中更稳定。

使用方式：
- Pre-Norm（主流）：在 attention/FFN 之前做归一化，梯度更稳定
- Post-Norm（GPT-2 风格）：在之后做，训练不稳定，已少用
- Inside-Residual Post-Norm（OLMo 2）：在残差路径内部做 post-norm
采用 RMSNorm 的模型：LLaMA 全系列、Qwen3、DeepSeek V3/V4、GLM-5、Mistral、Gemma 3、Kimi K2 等几乎所有现代模型。
关联论文/模型：“Root Mean Square Layer Normalization” (Zhang & Sennrich, 2019, arXiv:1910.07467)；几乎所有现代 LLM
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/ (各模型卡片的 Related Concepts)
- https://github.com/rasbt/LLMs-from-scratch/blob/main/ch04/01_main-chapter-code/ch04.ipynb

SwiGLU

缩写：SwiGLU
中文名称：SwiGLU 激活函数
简短介绍：GLU（Gated Linear Unit）的变体，使用 SiLU（Swish）作为门控激活函数，替代传统 ReLU/GELU。几乎所有现代 LLM FFN 层的标准配置。
详细介绍：SwiGLU 的公式：

SwiGLU(x) = SiLU(W·x) ⊙ (V·x) 其中 SiLU(x) = x · sigmoid(x)（也称 Swish）

对比传统 FFN：
- 传统：FFN(x) = W2 · activation(W1 · x)，单一激活
- SwiGLU：FFN(x) = W2 · [SiLU(W_gate · x) ⊙ (W_up · x)]，门控机制
门控机制使网络能动态选择信息通过与否，比固定激活函数更有表达力。

实现细节：SwiGLU FFN 有 3 个权重矩阵（W_gate, W_up, W_down），比传统 2 个多一个，因此隐藏维度通常调整为 2/3 × 4d 以保持参数量。

采用 SwiGLU 的模型：LLaMA 全系列、Qwen3、DeepSeek V3/V4、GLM-5、Mistral、Kimi K2、PaLM 等。
关联论文/模型：“GLU Variants Improve Transformer” (Shazeer, 2020, arXiv:2002.05202)；LLaMA、Qwen、DeepSeek 等
权威分析链接：
- https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the

KV Cache

缩写：KV Cache
中文名称：键值缓存
简短介绍：自回归生成时，缓存之前 token 在每层注意力的 K/V 矩阵，避免重复计算。KV Cache 大小是长上下文推理最硬的物理瓶颈。
详细介绍：KV Cache 的大小计算：

KV Cache = 2(K+V) × n_layers × n_kv_heads × d_head × seq_len × batch × bytes_per_param

示例（DeepSeek V3, 128K 上下文, bf16, batch=1）：
- MLA 压缩后：约 68.6 KiB/token × 128K = ~8.6 GB
- 对比 Llama 3 8B（GQA）：128 KiB/token × 128K = ~16 GB
- 对比 OLMo 2 7B（MHA）：512 KiB/token × 128K = ~64 GB
注：以上 MHA/GQA 数字为示意量级，便于横向对比 MLA 的压缩收益。

KV Cache 是长上下文推理的核心瓶颈，催生了大量优化：
- 压缩 KV 表示：MLA（低维压缩）、CCA（压缩空间计算）
- 减少序列条目：CSA/HCA（序列压缩）、SWA（局部窗口）
- 跨层共享：Gemma 4 的 Cross-Layer Attention
- 线性注意力：Lightning Attention、KDA（O(1) 状态替代 O(n) 缓存）
- 分页管理：vLLM PagedAttention
趋势：随着推理模型（o1/R1）和 Agent 工作流需要更长的上下文，KV Cache 优化成为 2025-2026 年架构设计的最大驱动力。
关联论文/模型：所有 Transformer 模型；MLA (DeepSeek V2)、PagedAttention (vLLM)
权威分析链接：
- https://magazine.sebastianraschka.com/p/coding-the-kv-cache-in-llms
- https://sebastianraschka.com/llm-architecture-gallery/kv-cache-calculations/

本篇小结

本篇 8 个模型架构术语沿"稀疏激活 + 残差连接进化 + 位置编码/归一化/FFN 标准件 + KV Cache 瓶颈"四条线归位：

MoE 把 FFN 替换为多个并行专家网络，路由器为每个 token 选少量专家，实现大参数量但低激活成本；2025-2026 年大模型几乎全部 MoE 化，激活比持续下降（DeepSeek V4 ~4%）。
MTP 训练时同时预测未来多个 token 增加训练信号密度，推理时可复用 MTP 模块做推测解码；DeepSeek V3 用 MTP，是训练与推理的连接点。
mHC 把 Transformer 块的单残差流扩展为多个并行残差流，用双随机矩阵约束保证混合稳定；DeepSeek V4 引入，信息通路更宽。
RoPE 通过旋转矩阵把相对位置编入 Q/K 的旋转中，使注意力分数自然反映相对距离；当前绝大多数 LLM 的默认位置编码。
YaRN 通过分段插值 + 温度缩放做 RoPE 上下文扩展，约 400 步微调即可从 4K 扩到 128K+；目前最主流的上下文扩展方法。
RMSNorm 去掉 LayerNorm 的均值计算仅用均方根归一化，计算更快且大规模训练稳定；几乎所有现代 LLM 的默认归一化。
SwiGLU 用 SiLU 作为 GLU 门控激活替代 ReLU/GELU；几乎所有现代 LLM FFN 层的标准配置。
KV Cache 缓存历史 token 的 K/V 避免重复计算，但其体积随上下文线性增长，是长上下文推理最硬的物理瓶颈——催生篇 1 的 MLA/CSA/HCA 压缩、篇 5 的 PagedAttention 分页管理、篇 10 的 Prefix Caching 复用。

KV Cache 是本篇与篇 1（注意力压缩）、篇 5（推理优化）、篇 10（推理服务）的交叉点：架构设计层面的每一次创新，最终都要回到这个物理瓶颈上检验。

本系列共 11 篇，本文是第 3 篇。系列导航见：LLM 术语全景图系列导读。

LLM 术语全景图（二）：注意力机制下——线性注意力与混合架构

Mon, 27 Jul 2026 09:15:00 +0800

这是「大模型训练与推理术语全景图」系列的第 2 篇，覆盖注意力机制后半部分的 6 个概念：Lightning Attention、KDA、NoPE、QK-Norm、CCA、Hybrid Attention。主要参考模型：MiniMax、Kimi (Moonshot)、ZAYA、OLMo、Qwen

开篇：线性注意力从理论到生产的曲折路径

线性注意力从理论到生产的路径比预想中曲折。Lightning Attention 在 MiniMax-01 上把注意力复杂度从 O(n^2) 降到 O(n)，纸面效率可观；但 MiniMax 在 M2 中放弃了 Lightning Attention，回归完整 softmax attention。这不是个别工程取舍，而是一个清晰的技术信号：在推理和多轮任务中，线性注意力的精度无法满足生产要求，且其低精度 KV 状态对 prefix caching 支持偏弱，使得长上下文复用这一关键推理优化失去杠杆。生产环境的精度门槛比纸面效率更重要，这是 2025-2026 年线性注意力落地必须正视的现实。本篇沿着这条主线，展开 Lightning Attention、KDA、NoPE、QK-Norm、CCA 与 Hybrid Attention 六个概念。

Lightning Attention

缩写：—
中文名称：闪电注意力
简短介绍：MiniMax 提出的线性注意力实现，将注意力计算从 O(n^2) 降至 O(n)，通过将 softmax 近似为线性形式并利用矩阵乘法结合律重排计算顺序。
详细介绍：Lightning Attention 基于线性注意力理论：

标准 softmax attention: O(Q·K^T)·V — 复杂度 O(n^2 × d) 线性注意力: φ(Q)·(φ(K)^T·V) — 复杂度 O(n × d^2)

关键技巧：利用 (Q·K^T)·V = Q·(K^T·V) 的结合律，先算 K^T·V（大小 d×d，与序列长度无关），再乘 Q，将序列维度从二次降为线性。

MiniMax-01 采用混合架构：大部分层使用 Lightning Attention（线性），少量层使用完整 softmax attention（保证精度）。

MiniMax M2 的转折：MiniMax 在 M2 中放弃了 Lightning Attention，回归完整注意力，原因是线性注意力在推理和多轮对话场景中精度不足。这表明线性注意力在生产环境中的成熟度仍有争议。

对比：Kimi Linear 的 KDA 是另一种线性注意力变体，通过 channel-wise gating 改善精度。
关联论文/模型：MiniMax-01 (arXiv:2501.08313)；MiniMax-M1 (arXiv:2506.13585)；MiniMax M2 (回归完整注意力)
权威分析链接：
- https://magazine.sebastianraschka.com/p/a-dream-of-spring-for-open-weight (MiniMax M2 分析)
- https://kaitchup.substack.com/p/minimax-m2-and-kimi-linear-why-full

Kimi Delta Attention

缩写：KDA
中文名称：Kimi 三角注意力 / Kimi Delta 注意力
简短介绍：Moonshot AI 在 Kimi Linear 中提出的线性注意力变体，是对 Gated DeltaNet 的改进，引入 channel-wise（逐通道）衰减门控，实现更精细的内存遗忘控制。
详细介绍：KDA 的技术演进路径：

DeltaNet → Gated DeltaNet → KDA

核心机制：
1. Delta 规则：将 attention state 的更新视为在线梯度下降，新 key-value 对通过 delta 规则更新状态矩阵 S
2. Gated DeltaNet 在此基础上添加标量衰减门控（scalar decay gate）
3. KDA 将标量衰减升级为对角化逐通道门控 Diag(α_t)，每个通道独立控制遗忘率
优势：
- 逐通道门控使模型能对不同信息维度采用不同的记忆/遗忘策略
- 增强位置感知能力
- 最高 75% KV Cache 压缩，1M token 上下文下解码吞吐最高 6× 提升（据 Moonshot 官方 GitHub，指标限定 1M token 上下文）
Kimi Linear 架构：3:1 混合（3 层 KDA + 1 层全局 MLA），48B 总参数 / 3B 激活，1M 上下文。
关联论文/模型：Kimi Linear (arXiv:2510.26692)；Gated DeltaNet (arXiv:2504.12236)；DeltaNet (2024)
权威分析链接：
- https://github.com/MoonshotAI/Kimi-Linear
- https://magazine.sebastianraschka.com/p/a-dream-of-spring-for-open-weight
- https://www.youtube.com/watch?v=SH6Cyhunl8s (Hybrid Attention and Gated DeltaNet 视频)

No Positional Encoding

缩写：NoPE
中文名称：无位置编码
简短介绍：不在注意力计算中显式注入位置信息，依赖因果掩码（causal mask）隐式编码位置。部分模型在选定的层中省略 RoPE 以降低长上下文计算开销。
详细介绍：NoPE 的原理：

标准 Transformer 需要位置编码（绝对位置 APE / 旋转位置 RoPE）来感知 token 顺序。但研究发现，在 decoder-only 模型中，因果掩码（下三角掩码）本身已隐含了顺序信息。

NoPE 的使用方式：
- 完全 NoPE：所有层均不使用位置编码（少数实验性模型）
- 交替 NoPE：大部分层用 RoPE，每隔几层用 NoPE（主流方式）
采用 NoPE 的模型：
- SmolLM3 (3B)：每 4 层有 1 层用 NoPE
- Nemotron 3 / Soofi S：Mamba-2 层 + NoPE
- Kimi Linear：线性注意力层使用 NoPE（线性注意力本身通过状态矩阵隐含位置信息）
动机：RoPE 在长上下文外推时角度超出训练分布，NoPE 层不受此限制，有助于长上下文泛化。
关联论文/模型：SmolLM3 (HuggingFaceTB, 2025-06)；Nemotron 3 (NVIDIA)；Kimi Linear (技术报告)
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/nope/
- https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

QK-Norm

缩写：QK-Norm
中文名称：查询-键归一化
简短介绍：在注意力计算前对 Query 和 Key 应用 RMSNorm 归一化，防止注意力分数过大导致训练不稳定。被 OLMo 2、Qwen3 等广泛采用。
详细介绍：QK-Norm 的操作：

Q’ = RMSNorm(Q), K’ = RMSNorm(K) Attention = softmax(Q’ · K’^T / sqrt(d_k)) · V

QK-Norm 在 RoPE 之前对 Q/K 应用 RMSNorm（Raschka 在架构对比中确认这一位置）。QK-Norm 替代或补充了传统的 1/sqrt(d_k) 缩放。RMSNorm 使 Q 和 K 的范数保持稳定，防止深层网络中 Q·K 值爆炸导致 softmax 饱和。

采用 QK-Norm 的模型：
- OLMo 2：MHA + QK-Norm
- Qwen3 (235B/32B/4B/8B)：GQA + QK-Norm
- MiniMax M2：per-head 变体的 QK-Norm
效果：改善训练稳定性，特别是在大规模模型和长上下文训练中。
关联论文/模型：OLMo 2 (arXiv:2501.00656)；Qwen3 (arXiv:2505.09388)；MiniMax M2 (技术报告)
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/qk-norm/
- https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

Compressed Convolutional Attention

缩写：CCA
中文名称：压缩卷积注意力
简短介绍：Zyphra 在 ZAYA1-8B 中提出的注意力机制，将 Q/K/V 压缩到低维潜在空间后直接在压缩空间执行注意力计算，并用卷积混合增强压缩表示的表达力。
详细介绍：CCA 与 MLA 的区别：

MLA：压缩 KV 存储 → 解压 → 在原始空间计算注意力 CCA：压缩 Q/K/V → 直接在压缩空间计算注意力 → 解压输出

这意味着 CCA 不仅减少 KV Cache，还减少注意力 FLOPs（prefill 和训练阶段）。

额外的卷积混合：在压缩后的 Q 和 K 上应用一维卷积，为压缩表示注入局部上下文信息（V 不做卷积，因为 V 是内容而非打分）。

ZAYA1-8B 使用 CCA + 4:1 GQA + 极稀疏 MoE（每 token 仅激活 1 个专家）。

据 CCA 论文报告，在同等压缩设置下 CCA 优于 MLA，但目前仅在 ZAYA1-8B 验证。
关联论文/模型：“Compressed Convolutional Attention” (arXiv:2510.04476, 2025-10)；ZAYA1-8B (arXiv:2605.05365)
权威分析链接：
- https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures (Section 4)

Hybrid Attention

缩写：—
中文名称：混合注意力
简短介绍：在同一个模型中交替使用不同类型的注意力层（如线性注意力 + 完整注意力），在效率和精度之间取得平衡。2025-2026 年的主流趋势之一。
详细介绍：混合注意力的常见模式：
1. 线性 + 全局（3:1）：3 层线性注意力 + 1 层完整注意力
  - Kimi Linear：3 层 KDA + 1 层 MLA
  - Qwen3-Next：3 层 Gated DeltaNet + 1 层 full attention
2. 滑动窗口 + 全局（5:1）：5 层 SWA + 1 层全局注意力
  - Gemma 3 (27B)：52 层 SWA + 10 层全局
  - Laguna XS.2：30 层 SWA + 10 层全局
3. Mamba-2 + GQA：SSM 层 + 少量注意力层
  - Nemotron 3：6 层 GQA + 23 层 Mamba-2
  - Soofi S：相同架构
4. CSA + HCA：压缩稀疏 + 重度压缩交替
  - DeepSeek V4：CSA 和 HCA 交替
核心思想：完整注意力是昂贵但精确的"稀缺资源"，放在关键层；廉价注意力放在大部分层以控制成本。

反例：MiniMax M2 放弃混合注意力回归完整注意力。原因在于 linear attention 在推理和多轮任务中精度不足，且低精度 KV 状态对 prefix caching 支持偏弱，使长上下文复用失去杠杆（Raschka 在 M2 分析中明确指出这两点）。
关联论文/模型：Kimi Linear (技术报告)；Qwen3-Next；Gemma 3；Nemotron 3；DeepSeek V4 (技术报告)
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/hybrid-attention/
- https://www.youtube.com/watch?v=SH6Cyhunl8s (Hybrid Attention and Gated DeltaNet)
- https://www.youtube.com/watch?v=Y6APnyZT6XU (LLM Architecture in 2026, 49:00 段)

本篇小结

本篇 6 个注意力相关术语沿"线性注意力从理论到生产 + 配套稳定性与混合架构"两条线归位：

Lightning Attention 把 softmax 近似为线性形式并用结合律重排计算，将注意力复杂度从 O(n²) 降到 O(n)；但 MiniMax 在 M2 中放弃它回归完整注意力，原因是线性注意力在推理和多轮任务中精度不足，且低精度 KV 状态对 prefix caching 支持偏弱——生产环境的精度门槛比纸面效率更重要。
KDA 是 Gated DeltaNet 的改进，把标量衰减门控升级为逐通道对角门控 Diag(α_t)，每个通道独立控制遗忘率；Kimi Linear 用 3:1 混合（3 层 KDA + 1 层全局 MLA），1M token 上下文下最高 75% KV 压缩与 6× 解码提升（Moonshot 官方指标，限定 1M 上下文）。
NoPE 在选定层省略位置编码，依赖因果掩码隐式编码位置，降低长上下文计算开销；常见于线性注意力层（Kimi Linear、Qwen3-Next）。
QK-Norm 在注意力计算前对 Q/K 做 RMSNorm，防止注意力分数过大导致训练不稳定；OLMo 2、Qwen3、Gemma 3 已广泛采用，是"免费的稳定性增强"。
CCA 把 Q/K/V 压缩到低维潜在空间后直接在压缩空间执行注意力，并用卷积混合增强表达力；ZAYA1-8B 的实践，与 MLA 的区别是 MLA 上投影还原后再算注意力，CCA 在压缩空间直接算。
Hybrid Attention 在同一模型中交替使用不同注意力层（线性 + 完整、SWA + 全局、CSA + HCA），完整注意力作为稀缺资源放在关键层；2025-2026 年的主流趋势，但 MiniMax M2 放弃混合回归完整注意力是重要反例。

本系列共 11 篇，本文是第 2 篇。系列导航见：LLM 术语全景图系列导读。

LLM 术语全景图（一）：注意力机制上——MHA 到 MLA 的压缩演进

Mon, 27 Jul 2026 09:00:00 +0800

这是「大模型训练与推理术语全景图」系列的第 1 篇，覆盖注意力机制前半部分的 8 个概念：MHA、MQA、GQA、MLA、SWA、DSA、CSA、HCA。主要参考模型：DeepSeek、GLM、Kimi (Moonshot)、Llama、Gemma、MiniMax

开篇：为什么 2025-2026 年注意力机制在密集创新

2025-2026 年，注意力机制的迭代密度显著上升，其驱动力并非抽象的"模型变大"，而是一个具体的工程瓶颈：KV Cache 已成为长上下文推理的第一代价。在自回归解码阶段，每生成一个 token 都要对所有历史 token 的 K/V 做注意力，这意味着 KV Cache 的体积随上下文长度线性增长，而它在显存中的驻留又直接挤占了 batch size 与并发上限。当推理模型需要维持数万 token 的思维链、Agent 工作流需要在单次会话中携带工具调用历史与检索结果时，KV Cache 从"可优化项"变成了"硬约束"。MHA 到 MQA、GQA 的头维度压缩，MLA 的潜在维度压缩，SWA/DSA 的序列维度稀疏，CSA/HCA 的序列维度压缩，本质都在回答同一个问题：在不牺牲检索精度的情况下，如何让 KV Cache 不再是长上下文推理的瓶颈。本篇按这条主线梳理前 8 个注意力变体。

注意力机制（上）

Multi-Head Attention

缩写：MHA
中文名称：多头注意力
简短介绍：Transformer 原始论文提出的注意力机制，每个注意力头有独立的 Q/K/V 投影，能从不同子空间捕获不同的注意力模式。
详细介绍：对于输入序列 X，每个头独立计算：

Q_h = X·W_h^Q, K_h = X·W_h^K, V_h = X·W_h^V

Attention(Q_h, K_h, V_h) = softmax(Q_h·K_h^T / sqrt(d_k)) · V_h

多头输出拼接后经线性投影得到最终输出。头数 h 通常为 32~96，每头维度 d_k = d_model / h。MHA 的 KV Cache 占用最大：每 token 需存储 2 × n_layers × n_heads × d_head 维度。

示例：GPT-2 XL（1.5B）有 48 层 × 25 头，每 token KV Cache 约 300 KiB（bf16）。
关联论文/模型：“Attention Is All You Need” (Vaswani et al., 2017, arXiv:1706.03762)；GPT-2、GPT-3、原始 Transformer；OLMo 2 仍保留 MHA
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/mha/
- https://www.turingpost.com/p/attention-types

Multi-Query Attention

缩写：MQA
中文名称：多查询注意力
简短介绍：所有查询头共享同一组 K/V 投影，是 MHA 的极端压缩形式，大幅减少 KV Cache 但可能损失精度。
详细介绍：MQA 只保留一个 K/V 头，所有 Q 头都共享这同一组 K/V：

K = X·W^K (仅一份), V = X·W^V (仅一份)

每个 Q 头独立计算 attention，但 K/V 共享。KV Cache 减少到 MHA 的 1/n_heads。例如 32 头模型从 32 组 KV 降至 1 组，显存节省 ~96%。

在 GQA 的统一框架下理解：当 GQA 的 KV 头数 n_kv_heads = 1 时即 MQA，当 n_kv_heads = n_heads 时即 MHA。MQA 是 GQA 的极端特例（仅 1 个 KV 头）。Gemma 4 E2B 使用 MQA + 跨层 KV 共享进一步压缩。
关联论文/模型：“Fast Transformer Decoding” (Shazeer, 2019, arXiv:1911.02150)；PaLM、Falcon、Gemma 4 E2B
权威分析链接：
- https://arxiv.org/abs/1911.02150
- https://www.pythonalchemist.com/llm-architectures/attention-variants

Grouped Query Attention

缩写：GQA
中文名称：分组查询注意力
简短介绍：MHA 和 MQA 的折中方案，将查询头分组，每组共享一对 K/V 头，在精度和 KV Cache 压缩之间取得平衡。当前最主流的注意力机制。
详细介绍：将 n_heads 个 Q 头分成 n_groups 组，每组共享一组 K/V。用 KV 头数 n_kv_heads 表达压缩程度：
- n_kv_heads = 1 时即 MQA（极端压缩）
- n_kv_heads = n_heads 时即 MHA（无压缩）
- 介于两者之间即 GQA
例如 Llama 3 8B：32 个 Q 头，8 个 KV 头（4:1 分组），KV Cache 降至 MHA 的 25%。

GQA 是 2024-2026 年最广泛采用的注意力机制：
- Llama 3/4：GQA + RoPE
- Qwen3：GQA + QK-Norm
- Mistral Small 3.1：标准 GQA
- Kimi K2：GQA（部分层）
KV Cache 每 token（bf16）= 2 × n_layers × n_kv_heads × d_head × 2 bytes
关联论文/模型：“GQA: Training Generalized Multi-Query Transformer Models” (Ainslie et al., 2023, arXiv:2305.13245)；Llama 3、Qwen3、Mistral、Kimi K2
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/gqa/
- https://friendli.ai/blog/gqa-vs-mha

Multi-head Latent Attention

缩写：MLA
中文名称：多头潜在注意力
简短介绍：DeepSeek 提出的注意力机制，通过低秩投影将 K/V 压缩到低维潜在空间存储，推理时再上投影还原，大幅减少 KV Cache 同时保持精度。
详细介绍：MLA 的核心思想是对 K/V 做低秩压缩：
1. 压缩：c_KV = W_DKV · x （将 d_model 压缩到 d_c，d_c « n_heads × d_head）
2. 上投影：K = W_UK · c_KV, V = W_UV · c_KV
3. 查询同样压缩：c_Q = W_DQ · x, Q = W_UQ · c_Q
KV Cache 只需存储压缩后的 c_KV（d_c 维），而非完整的 K/V。以 DeepSeek V3 为例：KV Cache 每 token 仅 68.6 KiB（bf16），远低于同规模 MHA 模型。

MLA 的关键创新：RoPE 需要独立处理。MLA 将 K 分为两部分——压缩部分（走低秩路径）和 RoPE 部分（独立计算），以兼容旋转位置编码。

采用 MLA 的模型：
- DeepSeek V2/V3/V4：MLA 是核心注意力
- GLM-5/5.1/5.2：MLA + DSA
- Kimi K2.5：MLA
- Kimi Linear：3:1 混合 KDA + MLA（全局层用 MLA）
- Mistral（部分新模型）
关联论文/模型：DeepSeek-V2 (arXiv:2405.04434)；DeepSeek-V3 (arXiv:2412.19437)；GLM-5 (技术报告)；Kimi Linear (arXiv:2510.26692)
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/mla/
- https://magazine.sebastianraschka.com/p/visual-attention-variants (Visual Guide to Attention Variants)

Sliding Window Attention

缩写：SWA
中文名称：滑动窗口注意力
简短介绍：每个 token 只关注固定大小窗口内的邻近 token（如 1024 或 4096），而非整个序列，将注意力复杂度从 O(n^2) 降至 O(n×w)。
详细介绍：SWA 限制注意力范围到局部窗口 [t-w, t]：

Attention(Q, K, V) 限制为仅计算 |i - j| <= w 的位置

窗口大小 w 通常为 512~4096 token。SWA 可显著减少 KV Cache 和注意力计算量，但无法直接捕获长距离依赖。

实践中通常混合使用 SWA + 全局注意力层：
- Gemma 3 (27B)：52 层 SWA + 10 层全局（5:1 比例）
- Mistral Small 3.1：5:1 SWA + 全局
- Laguna XS.2：30 层 SWA + 10 层全局
- Llama 4 Maverick：36 层 chunked + 12 层 full GQA
信息传递机制：局部窗口层层传递，信息通过多层 SWA 逐步扩散到远距离（类似消息传递）。
关联论文/模型：“Longformer” & “BigBird” (2020)；Mistral 7B；Gemma 3；Llama 4；Laguna XS.2
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/swa/
- https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

DeepSeek Sparse Attention

缩写：DSA
中文名称：DeepSeek 稀疏注意力
简短介绍：DeepSeek V3.2-Exp 引入的稀疏注意力机制，通过学习到的选择器（indexer）动态选择需要关注的 token 子集，在保持检索能力的同时大幅降低注意力计算量。
详细介绍：DSA 的工作原理：
1. Indexer 层：用一个轻量级网络对序列中的 token 打分，选出最重要的 top-k token
2. Attention 仅在选中的 token 上计算，而非全部
3. 保留局部窗口（近期 token 全部可见）+ 选中的稀疏 token
与 SWA 的区别：SWA 是固定窗口，DSA 是动态选择。与标准稀疏注意力的区别：DSA 的选择是端到端学习的，不是预设模式。

GLM-5 用 DSA；GLM-5.2 在 DSA 基础上引入 IndexShare 机制：一个 DSA indexer 的结果复用到后续 4 层，进一步降低 1M token 上下文的计算成本（见 GLM-5 GitHub：reuses the same indexer across every four sparse attention layers）。

采用 DSA 的模型：
- DeepSeek V3.2-Exp：MLA + DSA
- GLM-5：MLA + DSA
- GLM-5.1/5.2：MLA + DSA + IndexShare（5.2 引入 IndexShare）
- DeepSeek V4：CSA（基于 DSA 选择器）+ HCA
关联论文/模型：DeepSeek V3.2-Exp 技术报告；GLM-5 (技术报告)；DeepSeek V4 (技术报告)
权威分析链接：
- https://sebastianraschka.com/llm-architecture-gallery/deepseek-sparse-attention/
- https://magazine.sebastianraschka.com/p/technical-deepseek (From DeepSeek V3 to V3.2)
- https://sebastianraschka.com/blog/2026/glm-5-2-indexshare.html (GLM-5.2 IndexShare)

Compressed Sparse Attention

缩写：CSA
中文名称：压缩稀疏注意力
简短介绍：DeepSeek V4 引入的注意力机制，结合序列维度压缩和 DSA 风格的稀疏选择，以较低的压缩率保留更多细节，适合需要精确检索的场景。
详细介绍：CSA 的核心设计：
1. 序列维度压缩：将连续的 token 组压缩为更少的 KV 条目（但压缩率比 HCA 温和）
2. 稀疏选择：使用 DSA 风格的 indexer 选择最相关的压缩条目
3. 局部窗口：保留近期 token 的未压缩 KV 用于精确注意力
4. 共享 KV 注意力：压缩条目使用共享 K/V 进一步降低开销
与 MLA 的关键区别：MLA 压缩的是单个 token 的 KV 表示维度（per-token compression），CSA 压缩的是序列长度维度（sequence-length compression），即将多个 token 的信息汇总到更少的条目中。其中"共享 KV 注意力"（shared-KV）的点在 Raschka 原文中有提及，此处保留。

CSA 保留较多压缩条目（细节多），但需要稀疏选择来控制计算量。HCA 则是更激进的版本。

在 DeepSeek V4 中，CSA 和 HCA 交替使用：CSA 负责精确检索，HCA 负责低成本全局覆盖。
关联论文/模型：DeepSeek V4 (技术报告)；mHC 论文 (arXiv:2512.24880)
权威分析链接：
- https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures (Section 5.2)
- https://sebastianraschka.com/llm-architecture-gallery/ (DeepSeek V4 卡片)

Heavily Compressed Attention

缩写：HCA
中文名称：重度压缩注意力
简短介绍：DeepSeek V4 引入的注意力机制，将每 128 个 token 激进压缩为一个 KV 条目，然后对这些少量压缩条目做密集注意力，以最低成本实现全局覆盖。
详细介绍：HCA 的设计思路与 CSA 互补：
1. 激进压缩：每 128 个 token 压缩为 1 个 KV 条目（压缩率 128:1）
2. 密集注意力：压缩后条目数量极少，可以对所有条目做完整 attention
3. 局部窗口：同样保留近期未压缩 token
对比 CSA vs HCA：
- CSA：温和压缩 + 稀疏选择 → 更多细节，但需要选择器开销
- HCA：激进压缩 + 密集注意力 → 更少条目，无需选择器，但丢失细节
DeepSeek V4 交替使用 CSA 和 HCA，使两者互补。

效果指标（DeepSeek V4 论文，1M token 上下文，相对 V3.2）：
- V4-Pro：27% FLOPs、10% KV Cache
- V4-Flash：10% FLOPs、7% KV Cache
注意：CSA/HCA 比 MLA 更复杂，目前仅在 DeepSeek V4 大规模验证，不一定普遍优于 MLA。
关联论文/模型：DeepSeek V4 (技术报告)
权威分析链接：
- https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures (Section 5.2 CSA/HCA)
- https://sesamedisk.com/sebastian-raschka-llm-architecture-gallery-2026

本篇小结

本篇 8 个注意力变体可以沿三条压缩主线归位：

头维度压缩：MHA → MQA → GQA，沿 n_kv_heads 轴从 n_heads 到 1 逐级压缩，GQA 的 n_kv_heads=1 即 MQA、n_kv_heads=n_heads 即 MHA。
潜在维度压缩：MLA 把 per-token 的 K/V 压进低秩潜在空间，是另一种正交的压缩方向。
序列维度压缩 / 稀疏：SWA 用固定窗口、DSA 用学习到的 indexer 做稀疏选择，CSA/HCA 则直接压缩序列长度本身，HCA 更激进、CSA 更温和，DeepSeek V4 让两者交替互补。

本系列共 11 篇，本文是第 1 篇。系列导航见：LLM 术语全景图系列导读。

LLM 术语全景图：系列导读（11 篇导航）

Mon, 27 Jul 2026 08:45:00 +0800

大模型训练与推理涉及 64 个核心概念，从注意力机制的压缩演进到推理服务的性能指标，横跨模型架构、训练方法、并行策略、GPU 硬件、量化、微调等多个领域。本系列按主题分册，每篇聚焦一个领域，便于逐篇阅读和单篇引用。

系列目录

篇号	标题	覆盖概念数
01	注意力机制（上）：MHA 到 MLA 的压缩演进	8
02	注意力机制（下）：线性注意力与混合架构	6
03	模型架构：MoE 与残差连接的演进	8
04	训练方法：从 RLHF 到 GRPO 的演进	6
05	推理优化：从推测解码到 Flash Attention	5
06	并行策略：多维并行的组合	8
07	GPU 硬件与计算：从 Tensor Core 到 HBM	8
08	量化方法：从 GPTQ 到 FP8	6
09	参数高效微调：LoRA 与 QLoRA	3
10	推理服务：Prefill 解码与性能指标	6
11	术语关系总览与核心趋势	总览

共 64 个概念条目 + 1 篇总览。

阅读建议

按顺序读：篇 01-02 注意力 → 篇 03 架构 → 篇 04 训练 → 篇 05-10 推理/部署侧 → 篇 11 总览串联
按兴趣跳读：每篇独立成文，条目间无前置依赖
查阅参考：篇 11 附术语关系图、模型对照表、量化对比表、GPU 精度算力表、核心趋势、参考资源索引

推测解码技术全景对比与 DeepSpec 落地分析

Wed, 22 Jul 2026 18:00:00 +0800

项目：DeepSpec | 撰写日期：2026-07-22 目标：系统讲解推测解码技术优缺点，对比 DeepSpec 项目包含的三种方案（DSpark / DFlash / Eagle3）以及 DeepSeek MTP，并梳理各方案在 vLLM 和 SGLang 两大推理引擎中的落地情况（附 PR 链接）。

一、推测解码技术概述

1.1 核心思想

推测解码（Speculative Decoding）借鉴 CPU 投机执行的思想：先用一个「又快又小」的草稿模型（draft model）猜接下来的 γ 个 token，再让「又慢又准」的目标模型（target model）一次性验证这一整块。猜对的直接用，猜错的修正。

加速公式（DSpark 论文式 1）：

L = (T_draft + T_verify) / τ

τ：每轮目标模型平均接受的 token 数（接受长度）
T_draft：草稿模型生成花费
T_verify：目标模型验证花费

加速只有三条路：草稿更快（降低 T_draft）、草稿更准（提高 τ）、验证更聪明（降低 T_verify / 按需截断）。

1.2 无损保证

推测解码最精妙的数学性质：无论草稿模型多烂，输出分布严格等于目标模型。

核心机制是拒绝采样（Rejection Sampling）：

接受概率 = min(1, p_target(x) / p_draft(x))
被拒绝位置从残差分布重采一个修正 token（bonus token）

两路径合并后，最终输出每个 token 的概率严格等于 p_target(x)。草稿模型只影响速度，不影响质量。

1.3 三种草稿生成方式

这是理解各方法差异的关键：

纯串行（自回归派）：逐 token 生成，每步一次前向

优点：每个 token 基于已确定的前文，准确
缺点：γ 次前向，T_draft ∝ γ；为控延迟被迫用极浅网络（1 层），容量受限

纯并行（并行派）：一次前向同时出 γ 个 token

优点：1 次前向出全部 token，T_draft 几乎与 γ 无关；可用更深网络（5 层）
缺点：位置间独立，无法建模依赖，后缀衰减严重（多模态碰撞问题）

半自回归（混合派）：并行 backbone 出基线 + 串行 head 注入依赖

优点：兼顾速度和后端质量
缺点：串行 head 有少量额外延迟（极小）

二、DeepSpec 项目中的三种方案对比

DeepSpec 仓库当前包含三种草稿模型算法，代表了推测解码的三个技术方向。

2.1 DSpark（半自回归 + 置信度调度）

论文：arXiv 2607.05147（DeepSeek-AI，2026）

架构：

[并行 backbone: 5层，一次出全部基线 logits]
 ↓
[串行 Markov head: 轻，逐位注入前一个 token 的偏置]
 ↓
[置信度头: 预测每个位置的接受概率，调度器据此截断]

核心技术：

半自回归生成：并行 backbone 一次出 γ 个基线 logit，串行 Markov head 逐位加低秩转移偏置 B_k = W2·W1[x_{k-1}]（rank=256），使第 k 位依赖前面已采样的 token。每个 token 概率都是精确 softmax，满足无损保证。
置信度调度验证：
- 置信度头：给每个位置打条件接受概率 c_k
- STS 校准：逐位温度校准，ECE 从 3%-8% 降到约 1%
- 硬件感知前缀调度器：按生存概率贪心截断，最大化全局吞吐 Θ = τ × SPS(B)，且截断只依赖已处理前缀（因果性/无损）
训练损失：CE(0.1) + L1/TV(0.9) + 置信度 BCE(1.0)，位置加权 w_k = e^{-(k-1)/γ}

离线效果（Table 1，平均接受长度 τ，block_size=7）：

目标模型	vs Eagle3	vs DFlash
Qwen3-4B	+30.9%	+16.3%
Qwen3-8B	+26.7%	+18.4%
Qwen3-14B	+30.0%	+18.3%
Gemma4-12B	全面领先	跨模型族泛化

具体（Qwen3-4B, GSM8K）：Eagle3=5.14，DFlash=5.40，DSpark=6.11

线上效果（DeepSeek-V4-Flash/Pro 真实流量，对比 MTP-1）：

引擎	等吞吐下单用户提速	中等 SLA 下吞吐提升
V4-Flash	+60%-85%	+51%
V4-Pro	+57%-78%	+52%

优点：

接受长度 τ 最高（~6+），块越长优势越大（γ=7 时 +16%，γ=15 时 +30%）
2 层 DSpark 超过 5 层 DFlash——注入一点自回归比堆并行层更划算
串行 head 几乎不增延迟（γ 从 4→16，每轮延迟只比 DFlash 多 0.2%-1.3%）
置信度调度首次让高并发生产环境安全使用多 token 推测解码
负载自适应：低并发扩验证预算榨干算力，高并发自动收缩保护 batch 容量

缺点：

需要为每个目标模型单独训练草稿（紧耦合：同族、hidden_size 匹配、tokenizer 一致）
置信度调度器的线上版本（异步 ZOS 适配、变长路由 kernel）属 DeepSeek 内部框架，未开源
对本身接受率极低的复杂查询，草稿侧固定开销无法回收

2.2 DFlash（纯并行）

论文：arXiv 2602.06036

架构：DSpark 去掉 Markov head 和置信度头

DeepSpec 仓库中，DFlash 和 DSpark 共用同一个 Trainer 和模型代码，仅配置不同：

markov_rank=0 → Markov head 变零矩阵，退化为纯并行
confidence_head_alpha=0 → 不训练置信度头
l1_loss_alpha=0，ce_loss_alpha=1.0 → 只用 CE loss

生成方式：

backbone([anchor, mask, mask, ..., mask]) → [l₁, l₂, ..., l₇] → 独立采样
1 次草稿前向，但位置间无依赖

优点：

1 次前向出全部 token，T_draft 几乎与 γ 无关
可用深网络（5 层），位置 1 的接受率最高（数学 0.88，优于自回归派的 0.81）
实现简单（无串行 head，无置信度调度）
训练只需 CE loss，不需置信度标签

缺点：

后缀衰减：后面位置因位置间独立，接受率急剧下降（位置 2-7 从 0.72 降到 0.63）
多模态碰撞：上下文可能是 “of course” 也可能是 “no problem”，并行 head 同时推 “course” 和 “problem”，串成 “of problem”
无法在高并发下安全使用长块（无置信度截断机制，验证浪费 batch 容量）
接受长度 τ ~4-5，不如半自回归派

2.3 Eagle3（纯串行 + TTT）

论文：arXiv 2503.01840

架构：1 层自回归草稿头 + Test-Time Training（TTT）

核心技术：

草稿模型只有 1 层（draft_num_hidden_layers=1），逐 token 串行生成
TTT（Test-Time Training）：推理过程中草稿模型参数动态更新，每 7 步用目标模型反馈微调
读目标模型最后层 hidden state，共享 embedding 和 lm_head

生成方式：

draft(t₁) → draft(t₂) → ... → draft(t₇)
7 次草稿前向，但每步有完整依赖

优点：

每个 token 基于已确定前文，准确度高
TTT 机制让草稿适应当前上下文，长期对话中越来越准（分布外泛化能力强）
1 层网络前向+反向极快，TTT 微调开销小
第一个 token 准确率最高（前缀匹配生存的关键）

缺点：

T_draft ∝ γ，块越长草稿越慢，被迫用极浅网络（1 层），容量受限
位置 1 的接受率不如并行派（数学 0.81 vs 0.88），因 1 层网络容量小
TTT 推理时有额外梯度计算开销
高并发下多 token 验证开销大（无置信度调度）
接受长度 τ ~4-5，块越长劣势越明显

2.4 三方案对比总表

维度	DSpark	DFlash	Eagle3
生成方式	半自回归	纯并行	纯串行
草稿层数	5 层	5 层	1 层
串行依赖	Markov head（低秩 rank=256）	无	完整自回归
置信度调度	有（STS 校准 + 贪心调度器）	无	无
T_draft vs γ	几乎无关 + 极小串行开销	几乎无关	∝ γ（线性增长）
位置 1 接受率	高（深网络 + 串行修正）	最高（深网络）	中（1 层容量受限）
后缀衰减	轻微（Markov head 注入依赖）	严重（位置间独立）	无（逐 token 依赖）
TTT 推理时训练	无	无	有（每 7 步微调）
训练损失	CE + L1/TV + 置信度 BCE	仅 CE	CE + step loss
接受长度 τ	~6+（最高）	~4-5	~4-5
高并发安全	是（置信度截断）	否	否
分布外适应	依赖训练数据覆盖	依赖训练数据覆盖	TTT 动态适应
代码位置	`modeling/dspark/`	`modeling/dspark/`（配置不同）	`modeling/eagle3/`

三、DeepSeek MTP 与推测解码的关系

3.1 MTP 是什么

MTP（Multi-Token Prediction，多 Token 预测）是 DeepSeek-V3 技术报告提出的训练阶段技术。预训练时不只预测下一个 token，还同时预测未来第 2、3…个 token，迫使模型学更好的表征。

3.2 MTP 架构

DeepSeek-V3 的 MTP 是串行链式的，每个模块的输入依赖前一个模块的输出（保持完整因果链）：

主模型 → hidden h₀ → MTP模块1 → 预测 token₂ → hidden h₁ → MTP模块2 → 预测 token₃ → ...

每个 MTP 模块：输入 = concat(RMSNorm(h_{k-1}), RMSNorm(Emb(token_k))) → 投影 → Transformer → 预测 token_{k+1}

3.3 MTP vs 推测解码

维度	MTP	推测解码
本质	训练阶段技术	推理阶段技术
主要目的	改善训练表征质量	加速推理
草稿来源	MTP 模块（预训练时联合训练）	独立小模型 / 挂载头 / n-gram
训练方式	与主模型联合预训练	草稿模型单独训练
推理时	默认丢弃 MTP 模块	必须有草稿模型参与
结合点	MTP 模块可当推测解码的草稿模型	DeepSeek 生产环境就是如此

3.4 DeepSeek 生产环境的实际做法

预训练时：主模型 + MTP 模块联合训练，MTP loss 权重 0.1
推理时：保留 MTP-1（只保留第一个 MTP 模块，预测 2 个 token），因为高并发下多 token 验证开销过大
MTP-1 第二 token 接受率约 85%-90%，约 1.8x 推理加速
DSpark 论文的核心贡献之一：首次让高并发生产环境安全使用多 token 推测解码，此前只能用 MTP-1

3.5 MTP vs EAGLE/DSpark 的技术亲缘

共同点：都读目标模型 hidden state，都有轻量 Transformer 层 + 共享 embedding/unembedding。

关键区别：

MTP 模块：预训练时与主模型联合训练，权重与主模型耦合优化
EAGLE/DSpark 草稿：后训练阶段单独训练，主模型冻结

MTP 当草稿用时接受率不如专门训练的方案（MTP-1 τ~~2 vs DSpark τ~~6+），但 MTP 的额外好处是训练阶段就提升了主模型质量，这是推测解码草稿不具备的。

四、各方案在 vLLM 中的落地情况

vLLM 是当前最活跃的开源 LLM 推理引擎，对推测解码的支持最为全面。

4.1 总览

vLLM 支持的推测解码方法（截至 2026-07）：

方法	支持状态	配置 method
EAGLE / EAGLE-3	已合并，生产可用	`eagle3`
DFlash	已合并，生产可用	`dflash`
DSpark	已合并，积极完善中	`dspark`
DeepSeek MTP	已合并，成熟	`deepseek_mtp`
P-EAGLE（并行 EAGLE）	已合并	`eagle3` + `parallel_drafting: true`
N-gram	已合并	`ngram`
独立草稿模型	已合并	`draft`

官方文档：https://docs.vllm.ai/en/latest/features/speculative_decoding

4.2 Eagle3 在 vLLM

Eagle3 于 2026 年 4 月开始在 vLLM 中落地，Red Hat 团队主导集成。

关键 PR：

PR	标题	合并日期
#37512	MiniMax-M2: add Eagle3 speculative decoding support	2026-04-06
#39450	Add Gemma4 Eagle3 support	2026-04-10
#43132	[Spec Decode] Add Qwen3 architecture support for EAGLE3	2026-06-21
#42764	[Model] Support post-norm architecture for EAGLE-3 speculators	2026-05-19
#41826	Added peagle speculators support	2026-05-12

Red Hat 博客报道 Eagle3 在 vLLM 中最高可达 2.5x 加速： https://developers.redhat.com/articles/2025/07/01/fly-eagle3-fly-faster-inference-vllm-speculative-decoding

P-EAGLE（并行版 Eagle3）在 vLLM 中通过 parallel_drafting: true 启用，B200 上比 Eagle3 快 1.05x-1.69x： https://vllm.ai/blog/2026-03-13-p-eagle

4.3 DFlash 在 vLLM

DFlash 于 2026 年 4 月开始在 vLLM 中落地，同样由 Red Hat 团队主导。

关键 PR：

PR	标题	合并日期
#38300	[Speculative Decoding] Add DFlash speculators config parsing	2026-04-15
#43445	[Spec Decode] Allow causal DFlash	2026-05-28
#44586	[MRV2][Spec Decode] DFlash	2026-06-10
#45181	[Spec Decode] Support mixed KV page sizes for DFlash	2026-06-21
#45319	[Model][Dflash] Enable Dflash for Qwen3NextForCausalLM	2026-06-12
#46770	[Model Runner V2][DFlash] Enable dflash attention backend selection	2026-06-26
#47914	[Spec Decode] Support hybrid (SWA + full attention) DFlash drafters	2026-07-08

vllm-project/speculators 项目提供 DFlash 草稿模型训练，训练后可直接部署到 vLLM： https://github.com/vllm-project/speculators

4.4 DSpark 在 vLLM

DSpark 于 2026 年 7 月 1 日合并到 vLLM，目前处于积极完善阶段，有大量 follow-up PR 在修复边缘情况和扩展支持。

关键 PR：

PR/Issue	标题	状态	日期
#46910	[Feature]: Support DSpark for DeepSeek V4（Feature Issue）	Closed (COMPLETED)	2026-06，2026-07-02 关闭
#46995	[Spec Decode] DSpark（主 PR）	Merged	2026-07-01
#47093	[Spec Decode] DSpark speculators checkpoint support	Merged	2026-07-02
#47216	[Spec Decode][DSpark] Add Gemma4-12B DSpark draft model	Merged	2026-07-16
#47419	[ROCm] Enable DeepSeek-V4 DSpark on AMD (MI350X/MI355X)	Merged	2026-07-10
#47677	[XPU] Add DSpark speculative decoding support for DeepSeek-V4	Merged	2026-07-16
#47377	[Spec Decode] Add DSpark support for Qwen3.5 target models	Open	2026-07
#48692	[MRV2][Spec Decode] Adaptive Speculative Decoding - Initial Support	Open	2026-07
#47584	[Spec Decode][Perf] Rowwise-fp8 draft lm_head for DSpark (opt-in)	Open	2026-07

主 PR #46995 的设计说明：

支持加载 DeepSeek-V4 DSpark 模型和 DeepSeek 训练的 Qwen3-DSpark 模型
DSpark 使用非因果滑动窗口注意力，复用现有 SparseMLA 后端（扩展 topk），无需重新实现 MLA attention
支持通过 --speculative-config 配置

vLLM Ascend 也有对应 RFC：

vllm-ascend#11126：[RFC]: Add DSpark speculative decoding support for DeepSeek-V4

4.5 DeepSeek MTP 在 vLLM

DeepSeek MTP 是 vLLM 中最早支持的推测解码方法之一，2025 年 2 月即合并。

关键 PR：

PR	标题	合并日期
#12755	[Model][Speculative Decoding] DeepSeek MTP spec decode	2025-02-19
#44821	fix: prefix DeepSeek V4 MTP projections	2026-06-10
#44420	[feature] add index share feature for DSA MTP	2026-06-07
#46994	[Spec][V2] Support MTP speculative decoding under pipeline parallelism	Open

配置示例：

{"method": "deepseek_mtp", "num_speculative_tokens": 1}

MTP 已支持 PP > 1（pipeline parallelism），是当前最成熟的推测解码选项。

4.6 vLLM 推测解码生态：vllm-project/speculators

vLLM 团队维护了专门的草稿模型训练库： https://github.com/vllm-project/speculators

统一训练框架，训练后直接部署到 vLLM
支持 P-EAGLE、DFlash、EAGLE-3 训练
已发布多个模型：Qwen3-8B DFlash（τ~3.74）、Gemma4-31B DFlash/Eagle3 等
DFlash 模型通过 PR #38300 实现无缝部署

五、各方案在 SGLang 中的落地情况

SGLang 是 LMSYS 团队维护的高性能推理引擎，对推测解码的支持同样全面。

5.1 总览

SGLang 支持的推测解码方法：

方法	支持状态	配置
EAGLE-2	已合并，成熟	`--speculative-algorithm EAGLE`
EAGLE-3	已合并，成熟	`--speculative-algorithm EAGLE3`
DFlash	已合并，成熟	`--speculative-algorithm DFLASH`
DSpark	已合并，积极完善中	`--speculative-algorithm DSPARK`
MTP	已合并，成熟	DeepSeek 模型原生支持
N-gram	已合并	`--speculative-algorithm NGRAM`
独立草稿模型	已合并	`--speculative-algorithm STANDALONE`

官方文档：https://docs.sglang.ai/advanced_features/speculative_decoding.html

5.2 Eagle3 在 SGLang

Eagle3 通过 SpecForge 框架训练，部署到 SGLang：

SpecForge（sgl-project/SpecForge）：Eagle3 训练框架
- 仓库：https://github.com/sgl-project/SpecForge
- 博客：https://www.lmsys.org/blog/2025-07-25-spec-forge
SGLang Eagle3 已支持多种模型（Llama、Qwen3、Kimi-K2.6 等）

关键 PR（SGLang 中的 Eagle3 相关）：

PR	标题	合并日期
#26506	[spec decoding] support kimi-k2.6-eagle3.1-mla draft	2026-05-28
#29464	Fix EAGLE draft hidden dim extraction and centralize spec helpers	2026-06-28
#26726	fix(spec-dec): treat num_nextn_predict_layers=0 the same as absent for EAGLE3	2026-06-05
#30947	[EAGLE] perf: Fuse topk=1 draft postprocess	2026-07-16
#31380	[Spec] Consolidate the verify step into eagle_worker_common	2026-07-16

5.3 DFlash 在 SGLang

DFlash 在 SGLang 中已成熟，支持多种后端和优化。

关键 PR：

PR	标题	合并日期
#29338	[Spec] Add DFLASH basic sanity CI test	2026-06-29
#29228	[Spec] Merge dflash triton kernels into a single dflash.py	2026-06-25
#29541	[Spec] Publish DFLASH verify read-done event for fine-grained WAR barrier	2026-06-29
#29446	Add Laguna XS.2.1 DFlash support to SGLang	2026-07-02
#29218	[Spec] DFlash: support pure-MLA targets with an fp8 KV cache (Kimi-K2.x-NVFP4)	2026-07-08
#29995	[Spec] Remove the ServerArgs clone hack from DFlashWorkerV2	2026-07-03
#31468	[Spec] DFlash: remove per-step host syncs (spec-v2 overlap)	2026-07-18
#31677	[Spec] Extract DFlash compact draft-cache rebuild helpers	2026-07-20
#29884	[Doc] Cookbook: Laguna-XS-2.1 (DFlash low-latency + high-throughput)	2026-07-02

5.4 DSpark 在 SGLang

DSpark 于 2026 年 7 月 12 日合并到 SGLang，LMSYS 团队发布了详细的工程博客。

主 PR 及关键 follow-up：

PR	标题	状态	日期
#29488	[Feature] Support DSpark Speculative Decoding for DeepSeek V4（Feature Issue）	Open	2026-06-27
#30261	[Spec] Add DSpark: confidence-scheduled speculative decoding（主 PR）	Merged	2026-07-12
#31434	[Perf] Cache uniform ragged-verify layout for DSpark verify-all compact	Merged	2026-07-16
#31985	[Perf] Fold dspark dense draft embedding into the draft graph	Merged	2026-07-22
#31986	[Perf] Stack dspark dense draft per-layer ctx KV projection into one GEMM	Merged	2026-07-22
#30720	[WIP] Enable GLM-5.2 DSpark compact verify functionality	Open	2026-07
#31026	[ROCm] Add DeepSeek-V4 DSpark for AMD GPU (MI350X/MI355X)	Open	2026-07
#30964	[AMD] Support DeepSeek V4 DSpark on AMD HIP platform	Open	2026-07
#31139	[PP&Spec] enable speculative decoding (MTP&DSpark) under PP	Open	2026-07
#31466	[Spec] DSpark support prefill/decode disaggregation	Open	2026-07
#31513	[Spec] Support DSPARK in disaggregation decode mode	Open	2026-07

SGLang DSpark 工程博客（强烈推荐阅读）： https://www.lmsys.org/blog/2026-07-06-dspark-sglang

博客核心内容：

SGLang 实现了 DSpark 的置信度调度器、逐请求变长验证（ragged verify）、全 CUDA graph 覆盖
三种验证模式：static（全块验证）、compact（按调度器截断，生产路径）、cap-accept（全块验证但只提交截断窗口，用于观测上限）
Ragged verify under full CUDA graphs：变长请求前打包到一个紧凑缓冲区，按总量对齐到捕获的 graph tier，截断后重放真正更小的 graph
SPS cost table：离线 profiling 步时间模型，在线让调度器决定每请求验证预算
零开销调度（ZOS）：集成到 SGLang 的 overlap scheduler

启动命令示例（DeepSeek-V4-Flash）：

python3 -m sglang.launch_server \
 --model-path deepseek-ai/DeepSeek-V4-Flash-DSpark \
 --speculative-algorithm DSPARK \
 --tp 4 --dp-size 4 --enable-dp-attention --enable-dp-lm-head \
 --moe-a2a-backend none --moe-runner-backend flashinfer_mxfp4 \
 --swa-full-tokens-ratio 0.1 --chunked-prefill-size 1024 \
 --mem-fraction-static 0.8 --cuda-graph-max-bs 192 \
 --max-running-requests 1024 --disable-radix-cache \
 --trust-remote-code --host 0.0.0.0 --port 30000

5.5 MTP 在 SGLang

SGLang 从 2025 年 1 月起就提供 DeepSeek 模型的 day-0 支持，MTP 支持较早成熟。

关键 PR：

PR	标题	合并日期
#26471	DeepSeek-V4 Online Compress support MTP	2026-06-16
#24436	[Gemma 4] Adding MTP support	2026-05-07
#30333	[AMD] Fix DeepSeek V4 MTP accuracy issue	2026-07-07
#30238	[AMD] Support two batch overlap with MTP on DeepSeekV4	2026-07-16
#28982	fix(mtp): avoid mtp perf regression in deepseek when enable eplb	2026-07-09

SGLang MTP 教程： https://company.hpc-ai.com/blog/sglang-speculative-decoding-tutorial

六、DeepSpec 落地情况总结

6.1 落地成熟度对比

方案	vLLM	SGLang	备注
Eagle3	生产可用（2026-04 起合并，多模型支持）	生产可用（SpecForge 训练 + SGLang 部署）	两个引擎都成熟
DFlash	生产可用（2026-04 起合并，多后端支持）	生产可用（多 kernel 优化，多模型支持）	两个引擎都成熟
DSpark	已合并（2026-07-01），积极完善中	已合并（2026-07-12），积极完善中	大量 follow-up PR 修复边缘情况
DeepSeek MTP	成熟（2025-02 起合并）	成熟（day-0 支持）	两个引擎最早支持的方法

6.2 DSpark 落地特点

DSpark 在两个引擎中的落地都处于「核心功能已合并、积极扩展」阶段：

vLLM 侧：

主 PR #46995 支持加载 DeepSeek-V4 DSpark 和 Qwen3-DSpark 检查点
已扩展到 Gemma4-12B（#47216）、ROCm（#47419）、XPU（#47677）
正在添加 Qwen3.5 支持（#47377）、自适应推测解码（#48692）
Red Hat 团队发布了 GLM-5.2 DSpark speculator preview： https://huggingface.co/RedHatAI/GLM-5.2-speculator.dspark-preview

SGLang 侧：

主 PR #30261 实现了完整的置信度调度 + ragged verify + CUDA graph
LMSYS 发布了详细工程博客，展示了 DSpark 对 MTP 和 non-spec 的吞吐/延迟优势
正在扩展到 GLM-5.2（#30720, #31047）、ROCm（#30964, #31026）、PD 分离（#31466, #31513）
性能优化 PR 持续合并（#31985, #31986 融合 embedding 和 KV projection）

6.3 从研究到生产的完整路径

1. 训练（DeepSpec / SpecForge / vllm-project/speculators）
 准备数据 → 用目标模型重新生成回答 → 预计算 target cache → 训练草稿模型

2. 评测（DeepSpec eval.py）
 accept_len / accept_rate@k 指标

3. 部署（vLLM / SGLang）
 --speculative-config '{"method": "dspark", "model": "path/to/draft"}'
 --speculative-algorithm DSPARK --speculative-draft-model-path ...

七、方案选型建议

7.1 按场景选

场景	推荐方案	理由
高并发生产服务	DSpark	置信度调度负载自适应，不拖垮吞吐
低并发交互式（batch=1）	Eagle3 / DSpark	接受率高的方案在低并发下收益最大
目标模型有原生 MTP	DeepSeek MTP	零额外训练，直接用
不想训练草稿模型	N-gram / Lookahead	零训练成本，但加速有限
跨模型族通用	独立草稿模型	即插即用，但接受率最低
追求最高接受长度	DSpark	τ~6+，块越长优势越大
追求分布外泛化	Eagle3（TTT）	推理时动态适应新上下文
快速验证 / 不确定效果	DFlash	实现简单，训练只需 CE loss

7.2 按引擎选

需求	vLLM	SGLang
最全面的 spec decode 支持	方法最多	方法最多
DSpark 置信度调度	基础支持	完整实现（compact ragged verify）
Eagle3 训练框架	vllm-project/speculators	SpecForge
DeepSeek 模型优化	支持	day-0 深度优化
AMD GPU 支持	支持（ROCm）	支持（ROCm）
文档/教程	完善	完善 + cookbook

八、参考文献

DSpark 论文：arXiv 2607.05147
DFlash 论文：arXiv 2602.06036
Eagle3 论文：arXiv 2503.01840
EAGLE 论文：arXiv 2401.15077
Medusa 论文：arXiv 2401.10774
Leviathan 2023（经典推测解码）：arXiv 2211.17192
DeepSeek-V3 技术报告（MTP 原始来源）
Better & Faster LLMs via Multi-token prediction：arXiv 2404.19737
推测解码综述：arXiv 2411.13157、arXiv 2502.19732
vLLM 推测解码文档：https://docs.vllm.ai/en/latest/features/speculative_decoding
SGLang 推测解码文档：https://docs.sglang.ai/advanced_features/speculative_decoding.html
DSpark in SGLang 博客：https://www.lmsys.org/blog/2026-07-06-dspark-sglang
SpecForge：https://github.com/sgl-project/SpecForge
vllm-project/speculators：https://github.com/vllm-project/speculators
Red Hat Eagle3 博客：https://developers.redhat.com/articles/2025/07/01/fly-eagle3-fly-faster-inference-vllm-speculative-decoding
P-EAGLE 博客：https://vllm.ai/blog/2026-03-13-p-eagle

附录：关键 PR 速查索引

vLLM

方案	关键 PR	说明
DeepSeek MTP	#12755	初始支持（2025-02）
Eagle3	#37512, #39450, #43132	MiniMax-M2 / Gemma4 / Qwen3 支持
DFlash	#38300, #44586, #43445	配置解析 / MRV2 / causal DFlash
DSpark	#46995, #47093, #47216	主 PR / speculators checkpoint / Gemma4
P-EAGLE	#41826	peagle speculators 支持

SGLang

方案	关键 PR	说明
Eagle3	#26506, #29464	Kimi-K2.6 / 通用 spec helper
DFlash	#29338, #29228, #29446	CI / triton kernel / Laguna XS
DSpark	#30261, #31434, #31985	主 PR / ragged-verify layout / perf 优化
MTP	#26471, #24436	DeepSeek-V4 / Gemma4 MTP

拆解 Kimi K3：2.8 万亿参数背后，6 项架构创新如何让 MoE 训练稳得住

Tue, 21 Jul 2026 22:30:00 +0800

2026 年 7 月 17 日，月之暗面（Moonshot AI）发布了 Kimi K3——全球首个公布的 3T 级开源模型。2.8 万亿参数，原生多模态视觉能力，100 万 token 上下文窗口，896 个专家中激活 16 个。这些数字本身已经足够吸引眼球。

但如果你关注大模型的工程实现，真正值得深挖的不是跑分，而是一个更本质的问题：把参数堆到万亿级并不难，难的是训练过程中不崩、专家负载不偏、推理成本不失控。

Kimi K3 在架构层面拿出了 6 项核心技术来回答这个问题：

Kimi Delta Attention (KDA) — 新型注意力基座
Attention Residuals (AttnRes) — 跨深度选择性表征检索
Stable LatentMoE — 896 选 16 的极致稀疏 MoE
Quantile Balancing — 基于分位数的专家均衡
Per-Head Muon — 逐头独立优化器
SiTU + Gated MLA — 激活控制与注意力选择性

本文逐一拆解这 6 项技术，看它们如何共同支撑起一个稳定的 3T 级训练流程。

一、注意力机制重构：KDA 与 AttnRes

1.1 Kimi Delta Attention (KDA)

KDA 是 K3 架构的注意力基座，官方将其定位为「高效 scaling 注意力的基础」。传统 Transformer 的注意力机制在超长上下文（100 万 token）下面临双重挑战：计算量随序列长度平方增长，KV cache 内存开销线性膨胀。

KDA 的设计目标是提供一种计算和内存都更高效的注意力变体，作为万亿参数规模下的基础组件。值得注意的是，KDA 在设计之初就考虑了与前缀缓存（prefix caching）的兼容性——这一点在后面的推理部署部分会再次涉及，因为 K3 团队已经将 KDA 的前缀缓存实现贡献给了 vLLM 社区。

关于 KDA 的精确数学形式（如是否采用线性注意力近似、delta 规则的具体定义），官方博客未展开，需要等待技术报告。

1.2 Attention Residuals (AttnRes)

如果说 KDA 解决的是序列长度方向（“宽度”）的效率问题，那么 Attention Residuals 解决的是模型深度方向（层间）的效率问题。

标准 Transformer 中，每一层的输出通过残差连接与输入相加：x_{l+1} = x_l + f_l(x_l)。这种全量累加意味着信息在所有层之间无差别地传递——无论浅层学到的基础特征是否在深层仍然需要，深层都得"背着"这些信息继续往前走。

AttnRes 的核心思想是选择性检索：不是无差别地把所有历史信息累加进来，而是让深层根据当前需要，选择性地从浅层表征中检索有用的部分。这类似于一个注意力机制，但作用域不是 token 之间，而是层与层之间。

打个比方：标准残差连接像是"每层都把所有行李背在身上"，越深的层负担越重；AttnRes 则是"需要的时候去对应的柜子里取"，深层只携带当前任务真正需要的信息。

这种设计在深层网络中尤为重要。当模型层数随参数量增长时，信息在层间的冗余传递会带来梯度消散和表征退化问题，AttnRes 通过选择性机制缓解了这一痛点。

下图是 Kimi K3 官方发布的架构总览图，展示了这六项技术如何组合在一起：

图源：Kimi K3 官方博客（kimi.com/blog/kimi-k3）。图中左侧两个面板分别展开了 Stable LatentMoE 和 KDA 的内部结构；右侧主干展示了 Block Attention Residuals 骨干——每一层由 KDA / Gated MLA / Stable LatentMoE 组成，层间通过 α 节点（AttnRes 操作）选择性传递信息，而非全量残差累加。

小结

KDA 和 AttnRes 构成了一组正交互补的设计：

维度	技术	解决的问题
序列长度（宽度）	KDA	长上下文的计算/内存效率
模型深度（深度）	AttnRes	层间信息冗余传递

二、极致稀疏的 MoE：Stable LatentMoE

Kimi K3 的 MoE 配置是 896 个专家，每次激活 16 个，稀疏比达到 56:1。

这个数字有多极端？对比一下：

模型	专家总数	激活专家数	稀疏比
DeepSeek-V3	256	8	32:1
Kimi K2	384	8	48:1
Kimi K3	896	16	56:1

注：DeepSeek-V3 与 Kimi K2 数据来自各自官方技术报告/模型卡，供横向参考。K3 数据来自 K3 官方博客。

更高的稀疏比意味着在相同激活参数量下，模型拥有更大的知识容量（总参数更多），但每次推理只动用一小部分——这就是 MoE 的核心优势。然而，稀疏比越高，两个工程难题就越尖锐：

路由稳定性：896 个专家中选 16 个，路由器需要在海量选项中做出一致的决策，训练初期很容易震荡。
负载均衡：如果某些专家总是被选中而其他专家闲置，就造成算力浪费；更严重的是，在专家并行（Expert Parallelism）部署时，负载不均直接导致 GPU 空转。

“Stable LatentMoE” 这个名字中的两个修饰词暗示了对应的解法：

Latent：路由决策可能不是直接在 token embedding 空间进行，而是在隐空间（latent space）中完成，从而获得更平滑的路由信号。
Stable：在 56:1 的稀疏度下保持训练稳定，依赖于后续几项配套技术——Quantile Balancing 和 Per-Head Muon。

K3 官方称，配合训练和数据配方的改进，这些结构变化相比 K2 带来了约 2.5 倍的整体 scaling 效率提升。需要说明的是，官方原文的表述是"convert compute into intelligence more effectively"，即每单位算力能转化为更多的智能——换言之，达到同等能力水平所需的算力显著降低（粗略理解为"同等能力下算力约 ÷ 2.5"，或"同等算力下能力约 × 2.5"）。注意这是官方自报的宏观口径，精确的测量定义有待技术报告披露。

三、专家均衡的新解法：Quantile Balancing

背景痛点

专家负载不均衡是 MoE 训练的经典难题。主流的解决方案是引入辅助损失（auxiliary loss）：给"热门"专家施加惩罚，鼓励路由器更均匀地分配 token。这个方法有效，但有一个臭名昭著的副作用——balancing 超参数极度敏感。

不同的模型规模、不同的训练阶段，最优的 loss 权重各不相同。调大了，好的专家被压制，模型能力下降；调小了均衡无效，部分专家饿死。在实践中，这个超参往往是 MoE 训练中最难调的旋钮之一。

K3 的做法

K3 的 Quantile Balancing 采取了完全不同的思路：

直接从 router score 的分位数（quantile）推导专家分配，消除启发式更新和敏感的 balancing 超参数。

传统方法看的是 router 给每个专家打的绝对分数，然后通过 loss 去调整这些分数的分布。Quantile Balancing 不看绝对分数，而是看相对排名。

直觉上可以这样理解：假设 router 对 896 个专家各打了一个分数，Quantile Balancing 会把这些分数排序，然后根据分位数（如前 1.8% 的分位阈值，对应 16/896）来确定哪些专家被激活。因为分位数天然适应不同专家之间分数尺度的差异——不管某个专家的绝对分数是 0.9 还是 0.09，只要它排在前面就会被选中。

这种做法的好处：

无需调超参：不再需要一个手工设定的 balancing loss 权重
自适应：分位数天然随训练过程变化，不需要退火策略
大规模友好：在 896 个专家的大规模 EP（Expert Parallelism）下依然有效

四、优化器进化：Per-Head Muon

先说 Muon 是什么

Muon 是 2024 年由 Keller Jordan 等人推动走红的优化器，核心创新是对权重矩阵的梯度做 Newton-Schulz 迭代正交化。不过，对梯度/权重矩阵做正交化以改善优化的思想并非 Muon 首创——更早的 RightMatrix 等工作就探索过类似思路，Muon 的贡献在于将其工程化为一个通用、可大规模训练的优化器。简单来说，标准优化器（Adam、AdamW）直接用梯度更新权重，而 Muon 先把梯度投影到一个更"正交"的方向上再更新。

效果是在小至中规模模型上显著加速收敛。Moonshot 自己在 K2 时期就已经采用了 Muon 优化器。

Per-Head 的改进

标准 Muon 对一个权重矩阵做统一的正交化处理。但注意力层的权重矩阵实际上是由多个 head 拼接而成的，而不同 head 学到的模式差异很大：

有的 head 关注局部依赖（邻近 token 的句法关系）
有的 head 关注长程依赖（段落级的语义关联）
有的 head 负责位置信息编码

如果对这些 head 统一施加相同的正交化处理，可能对某些 head 过于激进，对另一些又不够。Per-Head Muon 的改进是对每个 attention head 独立执行优化，让每个 head 获得最适合自己的更新策略。

在 3T 规模下，这个改进的意义不仅是收敛速度。大模型训练一次的成本极高（以百万美元计），优化器效率的每一点提升，都意味着用更少的算力和时间达到同样的效果。K3 官方将 Per-Head Muon 列为前述 2.5 倍 scaling 效率提升的关键因素之一。

五、激活与注意力控制：SiTU 与 Gated MLA

5.1 SiTU (Sigmoid Tanh Unit)

SiTU 是 K3 采用的新型激活函数，结合了 sigmoid 和 tanh 的特性。它的定位是替代 GELU、SwiGLU 等主流激活函数，改善激活值的分布控制。

在万亿参数规模下，激活函数的选择看似微小，实则影响巨大。不良的激活值分布会导致梯度传播不稳定，尤其在深层网络中。SiTU 的具体数学形式有待技术报告披露，但其设计目标是明确的：在极端规模下提供更受控的激活行为。

5.2 Gated MLA

MLA（Multi-head Latent Attention）是 DeepSeek 提出的注意力变体，核心是将 KV cache 压缩到隐空间中——用一个低秩的隐向量来表示原本需要大量内存的 Key 和 Value，在推理时再解压还原。

Gated MLA 在此基础上引入了门控（gate）机制。门控的作用是让模型学会"什么时候该注意、什么时候该忽略"，提升注意力的选择性。这在 100 万 token 的上下文中尤为重要：面对海量输入，模型需要高效地忽略无关信息，而非对所有内容分配等量的注意力资源。

MLA 的 KV 压缩 + 门控的选择性 = 推理时显著更省显存，这对于部署成本至关重要。

六、训练与部署工程

6.1 量化感知训练（QAT）

K3 从 SFT 阶段起就引入了量化感知训练：MXFP4 权重 + MXFP8 激活。

这里需要区分两种量化策略：

训练后量化（PTQ）：模型训练完成后，再把权重/激活压到低精度。简单但可能掉精度。
量化感知训练（QAT）：在训练过程中就让模型"感受"到量化带来的噪声，模型参数在训练时就适应了低精度表示。

K3 选择 QAT 的好处是推理时直接使用 MXFP4/MXFP8，无需额外转换步骤，同时保持了模型质量。MXFP4（Microscaling FP4）是 OCP 制定的新兴低精度格式，相比传统 INT4 有更好的数值动态范围，硬件兼容性也在快速扩展。

6.2 全平衡专家并行

在大规模 EP（Expert Parallelism）部署下，896 个专家分布在多张 GPU 上。如果某些 GPU 上的专家总是被频繁调用而另一些空闲，就会造成整体吞吐瓶颈。

K3 的方案是全平衡的专家并行训练，两个关键设计：

静态 shape：所有计算图的形状在编译时就确定，避免运行时动态分配带来的开销
关键路径无 host 同步：传统方案中，负载均衡调度通常需要在 CPU（host）端进行决策，然后同步给 GPU，这个 host↔GPU 同步是性能杀手。K3 把均衡逻辑完全做到 GPU 侧，消除了同步等待

6.3 推理部署：supernode + Mooncake + vLLM

K3 的推理部署方案是一个完整的系统工程：

硬件层面——推荐 supernode 配置，即 64 张以上加速器组成的高带宽通信域。大规模 MoE 推理对 all-to-all 通信带宽极度敏感，supernode 架构通过 NVLink/高速互联将通信延迟降到最低。

缓存层面——KDA 的前缀缓存实现已贡献给 vLLM 社区。前缀缓存是降低推理成本的利器：对于编码场景，大量请求共享相同的系统提示和代码上下文，缓存这些前缀可以避免重复计算。

架构层面——基于 Mooncake 的分离式推理架构（disaggregated inference），将 prefill（首 token 计算）和 decode（续写）分配到不同的计算资源上，各自独立扩缩容。

实战效果：在编码工作负载中，官方 API 的缓存命中率超过 90%。这直接反映在定价上：

计费类型	价格
缓存命中输入	$0.30 / MTok
缓存未命中输入	$3.00 / MTok
输出	$15.00 / MTok

缓存命中的输入价格仅为未命中的十分之一。对于高频编码场景（如 IDE 插件、代码 agent），绝大部分输入都会命中缓存，实际使用成本可以压到非常低。

结语：K3 架构给行业带来了什么信号

回顾 Kimi K3 的 6 项架构创新，可以提炼出三个值得行业关注的趋势：

信号一：万亿级 MoE 的训练稳定性问题，正在被系统性地解决。

过去，把 MoE 推到万亿规模最大的障碍不是算力，而是训练过程中各种不稳定——路由震荡、专家失衡、梯度异常。K3 的做法是针对每个环节给出专门的解法：KDA/AttnRes 稳住信息流，Quantile Balancing 稳住路由，Per-Head Muon 稳住优化，QAT 稳住精度。这不是某一项技术的一招鲜，而是一套系统工程。

信号二：优化器和路由均衡这两个方向正在快速成熟。

Muon 系列优化器从 2024 年提出到 2026 年被用于 3T 级模型，只用了不到两年。Quantile Balancing 则直接替代了 MoE 训练中最让人头疼的 balancing 超参。这两个方向的成熟速度意味着，它们很可能成为下一代大模型训练的标配。

信号三：开源模型正在以「架构效率」缩小与闭源的差距。

K3 的总参数是 2.8T，但激活参数量远小于此。真正的竞争力不来自参数总量，而来自每一单位算力能转化为多少智能——K3 称相比 K2 提升了约 2.5 倍（前文已说明口径）。当开源模型在架构效率上逼近甚至局部超越闭源模型时，开源与闭源的差距将以新的方式被重新定义。

最后提醒：本文的分析基于官方博客的公开信息。K3 的完整技术报告将随模型权重一同发布，届时我们会对架构细节做更精确的验证和补充。

本文基于 Kimi K3 官方技术博客（https://www.kimi.com/blog/kimi-k3）撰写。

Kata Containers 安全容器GPU支持实践

Tue, 21 Jun 2022 23:14:52 +0800

kata-containers 安全容器 GPU 支持实践

本文着重讲述如何在 kata-containers 安全容器中支持 GPU 设备，对安全容器本身的介绍会比较少，如果感兴趣的话，可以参考 kata-containers 官网。接下来，就是讲述如何一步步在安全容器中支持 GPU 设备，以Tesla P100 PCIe 16GB为例。

准备阶段

下载官方 release 包
下载官方代码，编译需要使用到的组件containerd-shim-kata-v2，kata-agent，虚拟机镜像 kata-containers.img或者kata-containers-initrd.img,虚拟机内核 vmlinuz
GPU 支持实践

准备 release 包

可以从官方的 release 页面获取最新的包，此处使用当前最新版本2.4.2。

# 下载
wget https://github.com/kata-containers/kata-containers/releases/download/2.4.2/kata-static-2.4.2-x86_64.tar.xz
# 解压并置于 /opt 目录下
tar xf kata-static-2.4.2-x86_64.tar.xz
mv opt/kata /opt/

编译必要组件

拉取 kata-containers 源码注意：源码需要包含此PR

mkdir -p $GOPATH/src/github.com/kata-containers
cd $GOPATH/src/github.com/kata-containers

git clone https://github.com/kata-containers/kata-containers.git
git clone https://github.com/kata-containers/tests.git
# 如果当前用户不是 root 用户，则需要将 tests 仓库切换到 root 用户，否则后续编译镜像需要安装 libseccomp 会失败
sudo chown -R root:root tests

编译`containerd-shim-kata-v2`

# 编译 containerd-shim-v2
make -C $GOPATH/src/github.com/kata-containers/kata-containers/src/runtime containerd-shim-v2

编译内核

# 准备依赖
apt-get install -y --no-install-recommends \
	 bc \
	 bison \
	 build-essential \
	 ca-certificates \
	 curl \
	 flex \
	 git \
	 iptables \
	 libelf-dev \
	 patch
# 切换目录
cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/packaging/kernel/
# 下载内核源码；准备 config 文件；
./build-kernel.sh -v 5.15.23 -g nvidia -f setup
# 编译 kernel
./build-kernel.sh -v 5.15.23 -g nvidia build
# 安装 kernel
sudo -E ./build-kernel.sh -v 5.15.23 -g nvidia install
# 安装目录 /usr/share/kata-containers
vmlinuz-5.15.23-92-nvidia-gpu # 所需内核模块
## 或者
vmlinux-5.15.23-92-nvidia-gpu # 所需内核模块

# 制作 linux-header deb 或者 rpm 包，由于接下来将使用 ubuntu 作为基础镜像，所以此处使用 deb 包
cd kata-linux-5.15.23-92
make deb-pkg
## 生成 deb 包
linux-headers-5.15.23-nvidia-gpu_5.15.23-nvidia-gpu-1_amd64.deb
linux-image-5.15.23-nvidia-gpu_5.15.23-nvidia-gpu-1_amd64.deb
linux-libc-dev_5.15.23-nvidia-gpu-1_amd64.deb

编译虚拟机镜像

虚拟机镜像分为两种 initrd 和 image，此处以 image 为例。

# rootfs 构建
export ROOTFS_DIR=${GOPATH}/src/github.com/kata-containers/kata-containers/tools/osbuilder/rootfs-builder/rootfs
rm -rf ${ROOTFS_DIR}
cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/osbuilder/rootfs-builder

# 确保 kata-containers/tests 仓库在 $GOPATH 目录下，且属主是 root 用户，否则安装 libseccomp 会失败
script -fec 'sudo -E EXTRA_PKGS="gcc make curl gnupg coreutils apt tar kmod pkg-config libc-dev libc6-dev pciutils" GOPATH=$GOPATH USE_DOCKER=true ./rootfs.sh ubuntu'

# 下载 GPU 驱动
## 根据官网 https://www.nvidia.com/Download/Find.aspx 选择所需 GPU 驱动；以 P100 显卡最新驱动 NVIDIA-Linux-x86_64-515.48.07.run 为例，将下载好的驱动放到目录 ${ROOTFS_DIR}/root
## 同时将编译内核生成的 deb 包防放到目录 ${ROOTFS_DIR}/root

# 编译 GPU 驱动
## 注意：确保本机有 GPU 设备，否则编译会失败；
mount -t sysfs -o ro none ${ROOTFS_DIR}/sys
mount -t proc -o ro none ${ROOTFS_DIR}/proc
mount -o bind,ro /dev ${ROOTFS_DIR}/dev
mount -t devpts none ${ROOTFS_DIR}/dev/pts
mount -t tmpfs none ${ROOTFS_DIR}/tmp

chroot ${ROOTFS_DIR}
export PATH=$PATH:/bin:/usr/local/sbin:/usr/sbin:/sbin

cd /root

# ubuntu dpkg 命令目前处于不可用状态，需要创建一些目录如下：
mkdir /var/lib/dpkg
touch /var/lib/dpkg/status
mkdir /var/lib/dpkg/updates/
mkdir -p /var/lib/dpkg/info/
touch /var/lib/dpkg/info/format-new
mkdir -p /var/cache/apt/archives/partial
mkdir -p /var/log/apt/
mkdir /var/lib/dpkg/alternatives

# 安装之前准备的内核 deb 包
dpkg -i *.deb

# 解压 NVIDIA 驱动包，并编译
chmod +x NVIDIA-Linux-x86_64-515.48.07.run
./NVIDIA-Linux-x86_64-515.48.07.run -x
cd NVIDIA-Linux-x86_64-515.48.07
./nvidia-installer -k 5.15.23-nvidia-gpu

## 编译完成后可清理 root 目录，减少镜像体积

# 安装 nvidia-container-toolkit
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
mkdir -p /usr/share/yrings/
mkdir -p /etc/ssl/certs
apt install ca-certificates
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
apt update
apt install nvidia-container-toolkit
apt clean all

## 准备 hook 文件
mkdir -p /usr/share/oci/hooks/prestart/
touch /usr/share/oci/hooks/prestart/nvidia-container-toolkit.sh
chmod +x /usr/share/oci/hooks/prestart/nvidia-container-toolkit.sh

# /usr/share/oci/hooks/prestart/nvidia-container-toolkit.sh
cat << EOF > /usr/share/oci/hooks/prestart/nvidia-container-toolkit.sh
#!/bin/bash -x

/usr/bin/nvidia-container-toolkit -debug \$@
EOF

# 退出，并清理
exit

umount ${ROOTFS_DIR}/sys
umount ${ROOTFS_DIR}/proc
umount ${ROOTFS_DIR}/dev
umount ${ROOTFS_DIR}/dev/pts
umount ${ROOTFS_DIR}/tmp

# 构建 image
## rootfs
export ROOTFS_DIR=$GOPATH/src/github.com/kata-containers/kata-containers/tools/osbuilder/rootfs-builder/rootfs

## image
cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/osbuilder/image-builder
script -fec 'sudo -E USE_DOCKER=true ./image_builder.sh ${ROOTFS_DIR}'
## 得到 kata-containers.img

## initrd 可按照如下方式：
cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/osbuilder/initrd-builder
script -fec 'sudo -E AGENT_INIT=yes USE_DOCKER=true ./initrd_builder.sh ${ROOTFS_DIR}'

至此，全部文件准备完毕。

配置 kata-containers 和 containerd 以使用 GPU

# 配置 containerd
## 配置文件 /etc/containerd/config.toml，新增
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
 runtime_type = "io.containerd.kata.v2"
 # privileged_without_host_devices = true

## 将 containerd-shim-kata-v2 移至可执行目录
cp $GOPATH/src/github.com/kata-containers/kata-containers/src/runtime/containerd-shim-kata-v2 /usr/local/bin/

## 将 kata-containers.img 移至 /usr/share/kata-containers
## 将 vmlinuz-5.15.23-92-nvidia-gpu 移至 /usr/share/kata-containers

## 配置 kata-containers
mkdir -p /etc/kata-containers
cp /opt/kata/share/defaults/kata-containers/configuration.toml /etc/kata-containers/
## 修改配置文件 configuration.toml
kernel = "/usr/share/kata-containers/vmlinuz-5.10.25-85-nvidia-gpu"
image = "/usr/share/kata-containers/kata-containers.img"
enable_iommu = true
hotplug_vfio_on_root_bus = true
pcie_root_port = 1

验证 GPU

# 查看 GPU vfio id
$ sudo lspci -nn -D | grep -i nvidia
0000:d0:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:20b9] (rev a1)
$ BDF="0000:d0:00.0"
$ readlink -e /sys/bus/pci/devices/$BDF/iommu_group
79

# 启动容器验证
$ ctr -n k8s.io run --rm --runtime "io.containerd.kata.v2" --device /dev/vfio/79 --rm -t "docker.io/nvidia/cuda:11.6.0-base-ubuntu20.04" cuda bash
$ nvidia-smi
Tue Jun 21 10:18:31 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 515.48.07 Driver Version: 515.48.07 CUDA Version: 11.7 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla P100-PCIE... Off | 00000000:02:00.0 Off | Off |
| N/A 41C P0 30W / 250W | 0MiB / 16384MiB | 3% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+

至此，我们就可以在安全容器中使用 GPU 设备。

参考

NVIDIA-GPU-passthrough-and-Kata

Close Swap on Ubuntu20.04

Tue, 25 May 2021 13:55:24 +0800

临时关闭

sudo dphys-swapfile swapoff

永久关闭

sudo systemctl disable dphys-swapfile.service --now
# 注释fstab
#/dev/mapper/vgubuntu-swap_1 none swap sw 0 0

linux 利用loop设备模拟块设备

Fri, 02 Apr 2021 16:37:51 +0800

linux 利用loop设备模拟块设备

创建虚拟设备

losetup --help
 -a 显示所有已经使用的回环设备状态
 -d 卸除回环设备
 -f 寻找第一个未使用的回环设备
 -e <加密选项> 启动加密编码

# 查找第一个未使用的回环设备
losetup -f
# 创建文件
dd if=/dev/zero of=./disk.img bs=4M count=1024
# 将disk.img 虚拟成一个回环设备
losetup -f disk.img
# 查询此设备
losetup -a | grep disk.img
/dev/loop25: [64768]:3296700 (/home/zbb/temp/disk/disk.img)

# 格式化设备
mkfs.ext4 /dev/loop25
# 挂载块设备
mount /dev/loop25 test # test 为自定义目录

# 卸载设备
umount test
losetup -d /dev/loop25

Install Kubernetes1.20.1 and Containerd1.4.3 on Ubuntu with ZFS

Mon, 11 Jan 2021 13:56:02 +0800

基于ZFS的Ubuntu20.04安装kubernetes1.20

containerd 安装

containerd containerd.io 1.4.3 269548fa27e0089a8b8278fc4fc781d7f65a939b

安装

# 安装必要组件
$ sudo apt-get update
$ sudo apt-get install \
 apt-transport-https \
 ca-certificates \
 curl \
 gnupg-agent \
 software-properties-common
# 安装gpg key
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
# 验证gpg key
$ sudo apt-key fingerprint 0EBFCD88
# 添加 repo
$ sudo add-apt-repository \
 "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
 $(lsb_release -cs) \
 stable"
# 安装containerd
$ sudo apt-get update
$ sudo apt-get install containerd.io

安装参考

配置修改适配 zfs

查看 zfs 插件

$ sudo ctr plugins ls | grep zfs 
io.containerd.snapshotter.v1 zfs linux/amd64 ok

准备config.toml

$ sudo cp /etc/containerd/config.toml /etc/containerd/config.toml.bk
$ sudo chmod 646 /etc/containerd/config.toml
$ sudo containerd config default > /etc/containerd/config.toml

修改snapshotter为zfs

[plugins."io.containerd.grpc.v1.cri".containerd]
 #snapshotter = "overlayfs"
 snapshotter = "zfs"

重启containerd，containerd不支持配置热加载

$ sudo systemctl restart containerd

挂载 zfs 到containerd指定目录

查询 pool

$ sudo zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 460G 8.64G 451G - - 0% 1% 1.00x ONLINE -

挂载目录

$ sudo zfs create -o mountpoint=/var/lib/containerd/io.containerd.snapshotter.v1.zfs rpool/containerd

查看挂载的目录

$ sudo zfs list
NAME USED AVAIL REFER MOUNTPOINT
...
rpool/containerd 96K 437G 96K /var/lib/containerd/io.containerd.snapshotter.v1.zfs

验证

拉取镜像

$ sudo ctr i pull --snapshotter=zfs docker.io/library/nginx:1.17

启动容器

$ sudo ctr run --rm --net-host -d --snapshotter=zfs docker.io/library/nginx:1.17 test

查看nginx启动结果

$ sudo ctr t ls
TASK PID STATUS 
test 1494537 RUNNING
$ netstat -alptn | grep 80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
$ curl http://127.0.0.1:80 # 正常可访问
<!DOCTYPE html>
...
<p><em>Thank you for using nginx.</em></p>
</html>

待解决的问题

问题 1

非root账户，sudo权限不指定参数snapshotter创建container，提示ctr: failed to mount /tmp/containerd-mount589724034: invalid argument，无法创建容器。

切换成root用户，依旧提示，但是容器可以正常创建

(root)$ ctr run --rm --net-host -d docker.io/library/nginx:1.17 test
ctr: failed to mount /tmp/containerd-mount589724034: invalid argument
(root)$ ctr t ls
TASK PID STATUS 
test 1494537 RUNNING

kubernetes 安装

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.1", GitCommit:"c4d752765b3bbac2237bf87cf0b1c2e307844666", GitTreeState:"clean", BuildDate:"2020-12-18T12:09:25Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.1", GitCommit:"c4d752765b3bbac2237bf87cf0b1c2e307844666", GitTreeState:"clean", BuildDate:"2020-12-18T12:00:47Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

安装

当前安装工具有很多，此处选择使用kubeadm

准备kubernetes 源(使用阿里镜像源)，并安装必要组件

sudo apt-get update
sudo apt-get install apt-transport-https
curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add - 
sudo cat << EOF >/etc/apt/sources.list.d/kubernetes.list
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF

sudo apt-get update
sudo apt-get install kubelet kubeadm kubectl

安装完成后 kubelet 服务会处于不断重启状态，暂时不需要关注，kubelet等待连接kube-apiserver，预期现象。

启动kubernetes集群

准备容器镜像

$ kubeadm config images list # 查看需要准备的镜像
k8s.gcr.io/coredns:1.7.0
k8s.gcr.io/etcd:3.4.13-0
k8s.gcr.io/kube-apiserver:v1.20.1
k8s.gcr.io/kube-controller-manager:v1.20.1
k8s.gcr.io/kube-proxy:v1.20.1
k8s.gcr.io/kube-scheduler:v1.20.1
k8s.gcr.io/pause:3.2

containerd 镜像加速

配置参考：

[plugins."io.containerd.grpc.v1.cri".registry]
 [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
 [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
 #endpoint = ["https://registry-1.docker.io"]
 endpoint = ["https://as065r9f.mirror.aliyuncs.com"]

启动集群

$ sudo kubeadm init --pod-network-cidr=10.10.0.0/16 --service-cidr=10.20.0.0/16 --kubernetes-version=v1.20.1 --apiserver-advertise-address 192.168.126.246 --cri-socket /run/containerd/containerd.sock

–kubernetes-version: 指定 kubernetes 版本；
–apiserver-advertise-address：指定 kube-apiserver 监听的ip地址；
–pod-network-cidr：指定 Pod 的网络范围；
–service-cidr：指定 Service 的网络范围；
–cri-socket：指定cri(社区趋势：cri 采用 containerd)

验证安装结果

# 根据提示拷贝kubeconfig文件
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.1", GitCommit:"c4d752765b3bbac2237bf87cf0b1c2e307844666", GitTreeState:"clean", BuildDate:"2020-12-18T12:09:25Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.1", GitCommit:"c4d752765b3bbac2237bf87cf0b1c2e307844666", GitTreeState:"clean", BuildDate:"2020-12-18T12:00:47Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Flannel 安装

kubernetes v1.17+ 版本

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

需要修改配置：

net-conf.json: |
 {
 "Network": "10.10.0.0/16", # kubeadm init 创建时使用的pod-network-cidr
 "Backend": {
 "Type": "vxlan"
 }
 }

参考连接

待解决问题

containerd 一直会刷新 error 日志

Jan 11 17:49:51 zbb-sonypc containerd[1566292]: time="2021-01-11T17:49:51.380076683+08:00" level=error msg="Failed to get usage for snapshot \"sha256:ffc9b21953f4cd7956cdf532a5db04ff0a2daa7475ad796f1bad58cfbaf77a07\"" error="zfs does not implement Usage() yet"

参考issue

规避办法

暂时通过修改代码规避
bevisy/zfs bevisy/containerd

Burn the Operating System Installation Disk on Mac

Wed, 06 Jan 2021 19:22:16 +0800

在 Macbook 上烧录 iso 镜像，制作操作系统盘

查看烧录 U 盘

diskutil list # 例如：/dev/disk3

取消挂载 U 盘

diskutil unmountDisk /dev/disk3

烧录

# 以 ubuntu-20.04.iso 为例
sudo dd if=~/Downloads/ubuntu-20.04.iso of=/dev/disk3 bs=1m && sync # sync 作用: 使缓存落盘

查看 dd 烧录进度

# 查看 dd 进程
ps -ef | grep -i dd
0 188 185 0 2:33PM ttys000 0:12.33 dd if=/Users/xx/Downloads/ubuntu-20.04.5-desktop-amd64.iso of=/dev/disk2 bs=1m
# 查看烧录进度
sudo kill -SIGINFO 188

弹出 U 盘

diskutil eject /dev/disk3

Install TigerVncServer On Ubuntu 20.04

Fri, 31 Jul 2020 11:47:14 +0800

Ubuntu 20.04 安装 Tigervncserver

# 安装
$ sudo apt update
$ sudo apt install xfce4 xfce4-goodies tigervnc-standalone-server # 推荐使用 xfce4 桌面

# 启动
$ vncpasswd # 配置 vnc 客户端连接密码
$ vncserver
$ vncserver -kill :1 # 关闭创建的 vnc server

# 修改配置，解决黑屏和灰屏问题
$ touch $HOME/.vnc/xstartup
$ chmod u+x $HOME/.vnc/xstartup
$ cat > $HOME/.vnc/xstartup << EOF
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
startxfce4 &
EOF
# 再次启动
$ vncserver :1 --geomotry 1366x768 # --geometry 参数随意

# 使用 vnc viewer 连接，端口号为 5091

使用 lxde 桌面

# 安装
$ sudo apt install xorg lxde-core lxterminal
# 配置 vncserver 启动桌面
$ cat > $HOME/.vnc/xstartup << EOF
 #!/bin/sh
 lxterminal &
 /usr/bin/lxsession -s LXDE &
 EOF

Install Wechat Client On Ubuntu 20.04

Wed, 29 Jul 2020 11:16:31 +0800

Ubuntu 20.04 安装微信客户端

clone repo

deepin-wine-ubuntu

执行脚本

sudo chmod a+x install_2.8.22.sh && ./install_2.8.22.sh

下载微信deb包，并安装

下载地址

安装微信：

sudo dpkg –i deepin.com.wechat_2.6.8.65deepin0_i386.deb

安装字体：(参考issue：https://github.com/wszqkzqk/deepin-wine-ubuntu/issues/253)

sudo apt install fonts-wqy-microhei fonts-wqy-zenhei

Ubuntu 20.04 显示器分辨率模式调整

Mon, 27 Jul 2020 10:24:29 +0800

Ubuntu 20.04 显示器分辨率模式调整

问题描述

Ubuntu 20.04 提示无法识别显示器，默认以分辨率1024x768(4:3)展示

问题解决

添加新的分辨率模式

查询输出接口

$ xrandr
Screen 0: minimum 320 x 200, current 2624 x 900, maximum 16384 x 16384
eDP-1 connected primary 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
 1600x900 60.01*+ 59.99 59.94 59.95 59.82 
 1440x900 59.89 
...
 360x202 59.51 59.13 
 320x180 59.84 59.32 
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 1024x768+1600+0 (normal left inverted right x axis y axis) 0mm x 0mm # 注意此行
 1024x768 60.00* 
 800x600 60.32 56.25 
 848x480 60.00 
 640x480 59.94 
HDMI-2 disconnected (normal left inverted right x axis y axis)

外界显示器输出接口为 DP-2

生成分辨率模式并添加

$ cvt 1920 1080
# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync

# 新建分辨率模式(可以不执行)
$ sudo xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
# 添加分辨率模式
$ sudo xrandr --addmode DP-2 "1920x1080_60.00"
$ sudo xrandr --output DP-2 "1920x1080_60.00"

总结

这里主要是通过修改输出信号来适配外接显示器，实际上外接显示器的型号未识别。

Kata-containers Compile And Installed

Sat, 25 Jul 2020 23:06:12 +0800

[TOC]

kata-containers 编译安装

kata-runtime 编译安装

# download source code
$ go get -d -u github.com/kata-containers/runtime
$ cd ${GOPATH}/src/github.com/kata-containers/runtime
# compile and install
$ make
$ make install

# Install Dir
/usr/libexec/kata-containers/kata-netmon
/usr/local/bin/kata-runtime
/usr/local/bin/containerd-shim-kata-v2
/usr/share/defaults/kata-containers/*

kata-shim 编译安装

# download source code
$ go get -d -u github.com/kata-containers/shim
$ cd ${GOTAH}/src/github.com/kata-containers/shim
# compile and install 
$ makn
$ make install

# Install Dir
/usr/libexec/kata-containers/kata-shim

kata-proxy 编译安装

# download source code
$ go get -d -u github.com/kata-containers/proxy
$ cd ${GOTAH}/src/github.com/kata-containers/proxy
# compile and install 
$ make
$ make install

# Install Dir
/usr/libexec/kata-containers/kata-proxy

编译 kata 所需的 kernel

# download source code
$ go get -d -u github.com/kata-containers/packaging
$ cd ${GOTAH}/src/github.com/kata-containers/packaging/kernel
$ git checkout stable-1.12

# On Ubuntu20.04 should install some essential packages
$ sudo apt install -y \
	gcc \
	make \
	libncurses5-dev \
	openssl \
	libssl-dev \
	build-essential \
	pkg-config \
	libc6-dev \
	bison \
	flex \
	libelf-dev
# Also you should install yq from github: https://github.com/mikefarah/yq
# 注意：如果缺少依赖，会导致内核编译所需要的 .config 文件，无法主动生成，可以将 configs/ 和 configs/fragments 目录下对应文件拼接成完整文件。
$ ./build-kernel.sh -v 5.4.60 -f -d setup # stable-1.12 支持的最新LTS内核
# compile kernel
$ ./build-kernel.sh -v 5.4.60 -f -d build

# Output File:
${GOPATH}/src/github.com/kata-containers/packaging/kernel/kata-linux-5.4.60-89/vmlinux

# Install Dir:
/usr/share/kata-containers/vmlinux

编译 agent (可选)

$ go get -d -u github.com/kata-containers/agent
$ cd $GOPATH/src/github.com/kata-containers/agent && make

编译 rootfs 文件系统

# stable-1.10 方法
# Download source code
$ go get -d -u github.com/kata-containers/osbuilder

# generate rootfs
$ export ROOTFS_DIR=${GOPATH}/src/github.com/kata-containers/osbuilder/rootfs-builder/rootfs
$ sudo rm -rf ${ROOTFS_DIR}
$ cd $GOPATH/src/github.com/kata-containers/osbuilder/rootfs-builder
# ${distro} 需要替换成具体的系统，推荐 centos
# 此处增加额外的包，是为了后续便于进入虚拟机调试
#$ script -fec 'sudo -E GOPATH=$GOPATH USE_DOCKER=true EXTRA_PKGS="bash coreutils" ./rootfs.sh ${distro}'
$ script -fec 'sudo -E GOPATH=$GOPATH USE_DOCKER=true EXTRA_PKGS="bash coreutils vim net-tools procps curl iproute" http_proxy=http://{proxy}:{ip} https_proxy=http://{proxy}:{ip} ./rootfs.sh ${distro}'
# 由于网络原因，可以构建时候添加 http_proxy 代理;
$ script -fec 'sudo -E GOPATH=$GOPATH USE_DOCKER=true EXTRA_PKGS="bash coreutils" http_proxt=http://{IP}:{PORT} ./rootfs.sh ${distro}'

# 开启vm debug（host进入vm）
## 方案一(官方文档目前的方案，支持kata-containers 1.10.7;kata-agent 1.10.7)
## 1.确保rootfs已安装 bash coreutils
## 2./etc/kata-containers/configuration.toml 配置文件修改
$ sudo sed -i -e 's/^kernel_params = "\(.*\)"/kernel_params = "\1 agent.debug_console"/g' "${kata_configuration_file}"
## 3.确保配置文件的[proxy.kata] enable_debug 不为 true （默认不为true）
$ sudo awk '{if (/^\[proxy\.kata\]/) {got=1}; if (got == 1 && /^.*enable_debug/) {print "#enable_debug = true"; got=0; next; } else {print}}' /etc/kata-containers/configuration.toml > /tmp/configuration.toml
## 4.使用 socat 访问，回车可进入bash，虚拟机刚启动会刷新大量日志，等待日志刷新完毕即可

# 方案二（之前使用的方案，也是官方方案，通过添加额外的kata-debug.service，相比方案一qemu无需传递内核参数agent.debug_console，同样确保配置文件的[proxy.kata] enable_debug 不为 true （默认不为true））
# Create a debug systemd service
$ cat <<EOT | sudo tee ${ROOTFS_DIR}/lib/systemd/system/kata-debug.service
[Unit]
Description=Kata Containers debug console

[Service]
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
StandardInput=tty
StandardOutput=tty
# Must be disabled to allow the job to access the real console
PrivateDevices=no
Type=simple
ExecStart=/bin/bash
Restart=always
EOT

# Add a dependency to start the debug console:
$ sudo sed -i '$a Requires=kata-debug.service' ${ROOTFS_DIR}/lib/systemd/system/kata-containers.target

# Output File:
${GOPATH}/src/github.com/kata-containers/osbuilder/rootfs-builder/rootfs

# 注意事项
# 1.安全容器开启debug console后，host使用socat访问vm，访问console.sock一次只允许一个连接，如果已存在进入虚拟机的连接，则其它连接均被阻塞

# stable-1.12
# Download source code
$ go get -d -u github.com/kata-containers/osbuilder
$ cd $GOPATH/src/github.com/kata-containers/osbuilder
# 构建rootfs
mkdir -p ${PWD}/myrootfs
export USE_DOCKER=true
export EXTRA_PKGS="vim bash coreutils vim net-tools procps curl iproute"
export AGENT_VERSION="1.12.0"
export AGENT_SOURCE_BIN="$GOPATH/src/github.com/kata-containers/agent" # kata-agent 二进制文件目录
export http_proxy=http://{}
export https_proxy=http://{}
./rootfs-builder/rootfs.sh -r ${PWD}/myrootfs centos # 可根据需求修改 distro
## 如果出现镜像构建在下载github文件卡住，可将对应{distro}目录下的Dockerfile.in模板，直接添加上ENV proxy
# 构建img
# build image based rootfs created above
sudo USE_DOCKER=true ./image-builder/image_builder.sh "${PWD}/myrootfs"

编译 rootfs.img

# stable-1.10 方法
# make sure rootfs is not MODIFIED!!! if you want to add new Agent
# install agent (optional)
$ sudo install -o root -g root -m 0550 -t ${ROOTFS_DIR}/bin ../../agent/kata-agent
$ sudo install -o root -g root -m 0440 ../../agent/kata-agent.service ${ROOTFS_DIR}/usr/lib/systemd/system/
$ sudo install -o root -g root -m 0440 ../../agent/kata-containers.target ${ROOTFS_DIR}/usr/lib/systemd/system/

# Compile
$ cd $GOPATH/src/github.com/kata-containers/osbuilder/image-builder
$ script -fec 'sudo -E USE_DOCKER=true ./image_builder.sh ${ROOTFS_DIR}'

# install
$ commit=$(git log --format=%h -1 HEAD)
$ date=$(date +%Y-%m-%d-%T.%N%z)
$ image="kata-containers-${date}-${commit}"
$ sudo install -o root -g root -m 0640 -D kata-containers.img "/usr/share/kata-containers/${image}"
$ (cd /usr/share/kata-containers && sudo ln -sf "$image" kata-containers.img)

# Output File:
$GOPATH/src/github.com/kata-containers/osbuilder/image-builder/kata-containers.img

编译 initrd.img

# make sure rootfs is not MODIFIED!!! if you want to add new Agent
# install agent(optional)
$ sudo install -o root -g root -m 0550 -T ../../agent/kata-agent ${ROOTFS_DIR}/sbin/init

# Compile
$ cd $GOPATH/src/github.com/kata-containers/osbuilder/initrd-builder
$ script -fec 'sudo -E AGENT_INIT=yes USE_DOCKER=true ./initrd_builder.sh ${ROOTFS_DIR}'

# install
$ commit=$(git log --format=%h -1 HEAD)
$ date=$(date +%Y-%m-%d-%T.%N%z)
$ image="kata-containers-initrd-${date}-${commit}"
$ sudo install -o root -g root -m 0640 -D kata-containers-initrd.img "/usr/share/kata-containers/${image}"
$ (cd /usr/share/kata-containers && sudo ln -sf "$image" kata-containers-initrd.img)

# Output File:
$GOPATH/src/github.com/kata-containers/osbuilder/initrd-builder/kata-containers-initrd.img

编译 qemu on aarch64

# 下载代码
$ go get -d github.com/kata-containers/tests
# 准备依赖
$ sudo apt install -y libcap-ng-dev libglib2.0-dev libpixman-1-dev librbd-dev libattr1-dev libcap-dev
# 编译构建
$ script -fec 'sudo -E ${GOPATH}/src/github.com/kata-containers/tests/.ci/install_qemu.sh'

# 注意：如果安装失败，清直接删除文件夹，然后重新跑升级脚本
$ sudo rm -rf ${GOPATH}/src/github.com/kata-containers/packaging # 可不操作
$ sudo rm -rf ${GOPATH}/src/github.com/qemu
# 如果需要编译指定代码分支的qemu版本，需要切换tests分支，以及packaging分支为同一分支
# 由于脚本.ci/install_qemu.sh go get 获取packaging代码后未切换分支，所以需要构建失败后，手动切换分支
# 目前已知最新的版本的qemu patch是针对qemu 5.1的，并不能直接使用master代码，会导致patch合入失败

Docker 对接 kata-runtime

修改 Docker 配置文件/etc/docker/daemon.json

{
 "debug": true,
 "default-runtime": "runc", # 可替换成 kata-runtime
 "runtimes": {
 "kata": {
 "path": "/usr/local/bin/kata-runtime" # 不支持直接配置成 containerd-shim-kata-v2
 }
 }
}

重启 docker 服务（必须）

验证修改生效

sudo docker run --rm --name test busybox:latest uname -a 与宿主机内核对比，验证是否生效

调试 kata-runtime

# docker 开启 debug: /etc/docker/daemon.json 添加参数 (需重启服务)
{ "debug": true }
# kata配置文件/etc/kata-containers/configuration.toml，开启 enable_debug

# 查看日志
$ journalctl -ft kata-runtime

Containerd 对接 containerd-shim-kata-v2

修改 containerd 的配置/etc/containerd/config.toml

containerd config default 生成当前版本默认配置

version = 2
root = "/var/lib/containerd"
state = "/run/containerd"
plugin_dir = ""
disabled_plugins = []
required_plugins = []
oom_score = 0

[grpc]
 address = "/run/containerd/containerd.sock"
 tcp_address = ""
 tcp_tls_cert = ""
 tcp_tls_key = ""
 uid = 0
 gid = 0
 max_recv_message_size = 16777216
 max_send_message_size = 16777216

[ttrpc]
 address = ""
 uid = 0
 gid = 0

[debug]
 address = ""
 uid = 0
 gid = 0
 level = "debug" # 开启debug

[metrics]
 address = ""
 grpc_histogram = false

[cgroup]
 path = ""

[timeouts]
 "io.containerd.timeout.shim.cleanup" = "5s"
 "io.containerd.timeout.shim.load" = "5s"
 "io.containerd.timeout.shim.shutdown" = "3s"
 "io.containerd.timeout.task.state" = "2s"

[plugins]
 [plugins."io.containerd.gc.v1.scheduler"]
 pause_threshold = 0.02
 deletion_threshold = 0
 mutation_threshold = 100
 schedule_delay = "0s"
 startup_delay = "100ms"
 [plugins."io.containerd.grpc.v1.cri"]
 disable_tcp_service = true
 stream_server_address = "127.0.0.1"
 stream_server_port = "0"
 stream_idle_timeout = "4h0m0s"
 enable_selinux = false
 sandbox_image = "k8s.gcr.io/pause:3.1"
 stats_collect_period = 10
 systemd_cgroup = false
 enable_tls_streaming = false
 max_container_log_line_size = 16384
 disable_cgroup = false
 disable_apparmor = false
 restrict_oom_score_adj = false
 max_concurrent_downloads = 3
 disable_proc_mount = false
 [plugins."io.containerd.grpc.v1.cri".containerd]
 snapshotter = "overlayfs"
 default_runtime_name = "runc"
 no_pivot = false
 [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
 runtime_type = ""
 runtime_engine = ""
 runtime_root = ""
 privileged_without_host_devices = false
 [plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime]
 runtime_type = ""
 runtime_engine = ""
 runtime_root = ""
 privileged_without_host_devices = false
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
 runtime_type = "io.containerd.runc.v1"
 runtime_engine = ""
 runtime_root = ""
 privileged_without_host_devices = false
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata] # 新增
 runtime_type = "io.containerd.kata.v2"
 runtime_engine = ""
 runtime_root = ""
 privileged_without_host_devices = false
 [plugins."io.containerd.grpc.v1.cri".cni]
 bin_dir = "/opt/cni/bin"
 conf_dir = "/etc/cni/net.d"
 max_conf_num = 1
 conf_template = ""
 [plugins."io.containerd.grpc.v1.cri".registry]
 [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
 [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
 endpoint = ["https://registry-1.docker.io"]
 [plugins."io.containerd.grpc.v1.cri".x509_key_pair_streaming]
 tls_cert_file = ""
 tls_key_file = ""
 [plugins."io.containerd.internal.v1.opt"]
 path = "/opt/containerd"
 [plugins."io.containerd.internal.v1.restart"]
 interval = "10s"
 [plugins."io.containerd.metadata.v1.bolt"]
 content_sharing_policy = "shared"
 [plugins."io.containerd.monitor.v1.cgroups"]
 no_prometheus = false
 [plugins."io.containerd.runtime.v1.linux"]
 shim = "containerd-shim"
 runtime = "runc"
 runtime_root = ""
 no_shim = false
 shim_debug = false
 [plugins."io.containerd.runtime.v2.task"]
 platforms = ["linux/amd64"]
 [plugins."io.containerd.service.v1.diff-service"]
 default = ["walking"]
 [plugins."io.containerd.snapshotter.v1.devmapper"]
 root_path = ""
 pool_name = ""
 base_image_size = ""

注意：确保containerd-shim-kata-v2 文件在 $PATH 目录下

验证：

# 创建容器
sudo ctr -n testns run --runtime io.containerd.kata.v2 -d --rm docker.io/library/busybox:latest busybox
# 查看容器 id
sudo ctr -n testns t ls
# 进入容器
sudo ctr -n testns t exec -t --exec-id {ID} busybox sh
# 查看内核版本
$ uname -a # 对比宿主机内核

调试 containerd-shim-runtime-v2

# containerd 配置开启 debug(需重启服务)
# kata配置文件/etc/kata-containers/configuration.toml，开启 enable_debug (需重新创建安全容器)

# 查看日志
$ journalctl -ft kata

附录

kata-containers 2.0 安装

下载release包

Release 地址

下载 Kata Containers 2.0.0-alpha3

解压后，拷贝至文件夹 /opt

准备配置文件和containerd-shim-kata-v2

# 准备配置文件
$ cp /opt/kata/share/defaults/kata-containers/configuration-qemu.toml /etc/kata-containers/configuration.toml
# 准备 containerd-shim-kata-v2
$ cp /opt/kata/bin/containerd-shim-kata-v2 /usr/local/bin/

配置文件修改如下：

[hypervisor.qemu]
path = "/opt/kata/bin/qemu-system-x86_64"
kernel = "/opt/kata/share/kata-containers/vmlinuz.container"
image = "/opt/kata/share/kata-containers/kata-containers.img"
machine_type = "pc"
kernel_params = ""
firmware = ""
machine_accelerators=""
cpu_features="pmu=off"
default_vcpus = 1
default_maxvcpus = 2
default_bridges = 1
default_memory = 2048
disable_block_device_use = false
shared_fs = "virtio-9p"
virtio_fs_daemon = "/opt/kata/bin/virtiofsd"
virtio_fs_cache_size = 1024
virtio_fs_extra_args = []
virtio_fs_cache = "auto"
block_device_driver = "virtio-scsi"
enable_iothreads = false
enable_vhost_user_store = false
vhost_user_store_path = "/var/run/kata-containers/vhost-user"
enable_debug = true
[factory]
[agent.kata]
enable_debug = true
kernel_modules=[]
[netmon]
path = "/opt/kata/libexec/kata-containers/kata-netmon"
enable_debug = true
[runtime]
enable_debug = true
internetworking_model="tcfilter"
disable_guest_seccomp=true
sandbox_cgroup_only=false
experimental=[]
EnablePprof = true

对接docker和containerd需要注意

注意：此版本无法与 docker配合使用，与containerd 使用正常。

问题探讨

1.如果关闭用来开启debug console的kata-debug.service会发生什么？

进入vm，关闭kata-debug.service，等待kata-debug.service最终停止后，重新使用socat无法再进入bash终端

bash-4.2# systemctl stop kata-debug
[ 249.392708] systemd[1]: Failed to determine peer security context: Protocol not available
[ 249.394714] systemd[1]: Accepted new private connection.
[ 249.395681] systemd[1]: Got unexpected auxiliary data with level=1 and type=2
[ 249.397145] systemd[1]: Got unexpected auxiliary data with level=1 and type=2
[ 249.397455] systemd[1]: Got unexpected auxiliary data with level=1 and type=2
[ 249.397759] systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StopUnit cookie=1 reply_cookie=0 error=n/a
[ 249.398545] systemd[1]: Trying to enqueue job kata-debug.service/stop/replace
[ 249.398983] systemd[1]: Installed new job kata-containers.target/stop as 51
[ 249.399290] systemd[1]: Installed new job kata-debug.service/stop as 50
[ 249.399604] systemd[1]: Enqueued job kata-debug.service/stop as 50
Terminated
bash-4.2# systemctl status kata-debug
[ 258.097267] systemd[1]: Failed to determine peer security context: Protocol not available
[ 258.098268] systemd[1]: Accepted new private connection.
[ 258.098453] systemd[1]: Got unexpected auxiliary data with level=1 and type=2
[ 258.098762] systemd[1]: Got unexpected auxiliary data with level=1 and type=2
[ 258.098928] systemd[1]: Got unexpected auxiliary data with level=1 and type=2
[ 258.099088] systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1/unit/kata_2ddebug_2eservice interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 error=n/a
[ 258.099783] systemd[1]: Sent message type=method_return sender=n/a destination=n/a object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
● kata-debug.service - Kata Containers debug console
 Loaded: loaded (/usr/lib/systemd/system/kata-debug.service; static; vendor preset: disabled)
 Active: deactivating (stop-sigterm) since Wed 2020-10-14 08:11:57 UTC; 8s ago
 Main PID: 57 (bash)
 CGroup: /system.slice/kata-debug.service
 ├─ 57 /bin/bash
 └─231 systemctl status kata-debug
[ 258.101662] systemd[1]: Got disconnect on private connection.
bash-4.2# system[ 339.593226] systemd[1]: kata-debug.service stop-sigterm timed out. Killing.
[ 339.593989] systemd[1]: Watching 57 through watch_pids1.
[ 339.594710] systemd[1]: kata-debug.service changed stop-sigterm -> stop-sigkill
[ 339.595681] systemd[1]: Received SIGCHLD from PID 57 (bash).
[ 339.596281] systemd[1]: Child 57 (bash) died (code=killed, status=9/KILL)
[ 339.596722] systemd[1]: Child 57 belongs to kata-debug.service
[ 339.597060] systemd[1]: Unwatching 57.
[ 339.597276] systemd[1]: kata-debug.service: main process exited, code=killed, status=9/KILL
[ 339.597722] systemd[1]: kata-debug.service changed stop-sigkill -> failed
[ 339.598098] systemd[1]: Job kata-debug.service/stop finished, result=done
# 此处kata-debug.service完全退出，无法再进入终端

# 尝试重新进入终端，会发现回车后无法打开bash终端
root@zbb-pc:/run/vc/vm/d658a67be082b2952c360e7539b5bfa7ac744ae8b84d844d57547d36915e184f# socat "stdin,raw,echo=0,escape=0x11" "unix-connect:./console.sock" 

# 重启容器后，可重新进入终端
# 此处发现重启容器过程，其实是新建一个同名的容器，因为会发现vm原有目录文件均被删除，生成同名文件夹。如果查看前后vm目录，应该文件inode已产生变化。

Compile qemu on Ubuntu 20.04

Fri, 24 Jul 2020 22:21:51 +0800

Compile qemu on Ubuntu 20.04

下载源码

git clone https://git.qemu.org/git/qemu.git
cd qemu
git submodule init
git submodule update --recursive

编译安装

./configure
make

问题

# ERROR: glib-2.48 gthread-2.0 is required to compile QEMU
$ sudo apt install -y libglib2.0-dev

# ERROR: pixman >= 0.21.8 not present.
# Please install the pixman devel package.
$ sudo apt install -y libpixman-1-dev

The Skills of VIM

Fri, 24 Jul 2020 15:02:12 +0800

VIM 使用技巧

查找

大小写敏感控制

# VIM 默认大小写敏感查找；

# 大小写不敏感查找
：/foo\c
# 大小写敏感查找
：/foo\C

查找光标当前单词

# normal 模式下，"*" 键查找当前单词

Vim 查找和替换

:{作用范围}s/{目标}/{替换}/{替换标志}

# 当前行替换
：s/vivian/sky/ 替换当前行第一个 vivian 为 sky 
：s/vivian/sky/g 替换当前行所有 vivian 为 sky 

# 范围替换； n 为数字，若 n 为 .，表示从当前行开始到最后一行 
：n,$s/vivian/sky/ 替换第 n 行开始到最后一行中每一行的第一个 vivian 为 sky 
：n,$s/vivian/sky/g 替换第 n 行开始到最后一行中每一行所有 vivian 为 sky 
：2,12s/hello/world/ 2-12行,第一次出现替换
：.,+2s/hello/world/ 当前行与接下来的2行，第一次出现替换

# 全行替换
：%s/vivian/sky/（等同于 ：g/vivian/s//sky/） 替换每一行的第一个 vivian 为 sky 
：%s/vivian/sky/g（等同于 ：g/vivian/s//sky/g） 替换每一行中所有 vivian 为 sky 
 
# 使用"#"作为分隔符，此时中间出现的 / 不会作为分隔符 
：s#vivian/#sky/# 替换当前行第一个 vivian/ 为 sky/ 
：%s+/oradata/apras/+/user01/apras1+ （使用+ 来 替换 / ）： /oradata/apras/替换成/user01/apras1/ 

# 替换确认，添加参数c，提示是否替换
:%s/hello/world/gc 针对每一个匹配项，提示是否替换

Compile Linux Kernel on Ubuntu 20.04

Fri, 24 Jul 2020 00:41:59 +0800

Linux 内核编译(Ubuntu 环境)

下载内核代码

https://www.kernel.org/

安装依赖

sudo apt update
sudo apt install -y \
	gcc \
	make \
	libncurses5-dev \
	openssl \
	libssl-dev \
	build-essential \
	pkg-config \
	libc6-dev \
	bison \
	flex \
	libelf-dev

准备.config和自定义配置

cd {Download}/linux-5.4.32/
sudo cp /boot/config-{uname -r} .config
sudo make menuconfig

编译内核

# 编译内核
sudo make
sudo make modules_install

安装内核

sudo mv {Download}/linux-5.4.32 /usr/src/
cd /usr/src/linux-5.4.32/
sudo make install
sudo mkinitramfs -o /boot/initrd.img-5.4.32
sudo update-initramfs -c -k 5.4.32
sudo update-grub2

验证

sudo reboot
uname -a

Zsh-And-Oh My Zsh-Installation summary

Sat, 18 Jul 2020 12:14:33 +0800

zsh 安装总结

安装zsh

# Ubuntu 18.04
sudo apt update
sudo apt install zsh -y

安装 Oh My Zsh

# https://ohmyz.sh/#install
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

插件安装

# 使用 Oh My Zsh 安装插件；默认安装目录为 $ZSH_CUSTOM/plugins (by default ~/.oh-my-zsh/custom/plugins)
git clone https://github.com/zsh-users/zsh-autosuggestions.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

# 配置 .zshrc，添加插件列表
plugins=(zsh-autosuggestions
 zsh-syntax-highlighting)

# 启动新终端，查看效果示例
zsh

通过nginx为netdata提供https访问

Tue, 21 Jan 2020 15:56:21 +0800

nginx 代理 netdata 并添加鉴权

netdata 安装

#!/bin/bash

docker run -d --name=netdata \
 -p 30002:19999 \
 -v /etc/passwd:/host/etc/passwd:ro \
 -v /etc/group:/host/etc/group:ro \
 -v /proc:/host/proc:ro \
 -v /sys:/host/sys:ro \
 -v /var/run/docker.sock:/var/run/docker.sock:ro \
 -e DO_NOT_TRACK=1 \
 --cap-add SYS_PTRACE \
 --security-opt apparmor=unconfined \
 netdata/netdata

nginx 安装

#!/usr/bin/env bash

docker run -d \
 --name nginx \
 -v $(pwd)/html:/usr/share/nginx/html \
 -v $(pwd)/conf.d:/etc/nginx/conf.d \
 -v $(pwd)/ssl:/etc/nginx/ssl \
 -v $(pwd)/passwords:/etc/nginx/passwords \
 -p 8080:80 \
 -p 8443:443 \
 -e TZ="Asia/Chongqing" \
 nginx
# 需要准备的文件
.
├── conf.d
│   └── default.conf
├── html
│   ├── 50x.html
│   └── index.html
├── nginx-start.sh
├── passwords
└── ssl
 ├── nginx.crt
 └── nginx.key

nginx 配置

upstream netdata {
 server 192.168.124.2:19999;
 keepalive 64;
}

server {
 listen 80;
 server_name localhost;

 #charset koi8-r;
 #access_log /var/log/nginx/host.access.log main;

 location / {
 root /usr/share/nginx/html;
 index index.html index.htm;
 }

 location = /netdata {
 return 301 /netdata/;
 }

 location ~ /netdata/(?<ndpath>.*) {
 proxy_redirect off;
 proxy_set_header Host $host;

 proxy_set_header X-Forwarded-Host $host;
 proxy_set_header X-Forwarded-Server $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_http_version 1.1;
 proxy_pass_request_headers on;
 proxy_set_header Connection "keep-alive";
 proxy_store off;
 proxy_pass http://netdata/$ndpath$is_args$args;

 gzip on;
 gzip_proxied any;
 gzip_types *;
 }

 #error_page 404 /404.html;

 # redirect server error pages to the static page /50x.html
 #
 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root /usr/share/nginx/html;
 }

 # proxy the PHP scripts to Apache listening on 127.0.0.1:80
 #
 #location ~ \.php$ {
 # proxy_pass http://127.0.0.1;
 #}

 # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
 #
 #location ~ \.php$ {
 # root html;
 # fastcgi_pass 127.0.0.1:9000;
 # fastcgi_index index.php;
 # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
 # include fastcgi_params;
 #}

 # deny access to .htaccess files, if Apache's document root
 # concurs with nginx's one
 #
 #location ~ /\.ht {
 # deny all;
 #}
}


server {
 listen 443 ssl;
 ssl_certificate /etc/nginx/ssl/nginx.crt;
 ssl_certificate_key /etc/nginx/ssl/nginx.key;
 keepalive_timeout 60;
 server_name localhost;
 server_tokens off;

 fastcgi_param HTTPS on;
 fastcgi_param HTTP_SCHEME https;

 access_log /var/log/nginx/access.log;
 error_log /var/log/nginx/error.log;

 location / {
 root /usr/share/nginx/html/;
 index index.html index.htm;
 }

 location = /netdata {
 return 301 /netdata/;
 }

 location ~ /netdata/(?<ndpath>.*) {
 proxy_redirect off;
 proxy_set_header Host $host;

 proxy_set_header X-Forwarded-Host $host;
 proxy_set_header X-Forwarded-Server $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_http_version 1.1;
 proxy_pass_request_headers on;
 proxy_set_header Connection "keep-alive";
 proxy_store off;
 proxy_pass http://netdata/$ndpath$is_args$args;

 gzip on;
 gzip_proxied any;
 gzip_types *;
 }
}

访问nginx http://nginxurl:80/netdata/ 或者 https://nginxurl:443/netdata/，验证生效。

生成 ssl 证书和密钥

# 有效时间 7 天
openssl req -x509 -nodes -days 7 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt -subj "/C=CN/ST=SiChuan/L=Chengdu/O=Example Inc./OU=Web Security/CN=localhost"

生成的证书未经权威机构认证，但是不影响使用，只是浏览器会提示非安全的证书。

nginx 配置https 服务

server {
 listen 443 ssl;
 ssl_certificate /etc/nginx/ssl/nginx.crt;
 ssl_certificate_key /etc/nginx/ssl/nginx.key;
 keepalive_timeout 60;
 server_name localhost;
 server_tokens off;

 fastcgi_param HTTPS on;
 fastcgi_param HTTP_SCHEME https;

 access_log /var/log/nginx/access.log;
 error_log /var/log/nginx/error.log;

 location / {
 root /usr/share/nginx/html/;
 index index.html index.htm;
 }

 location = /netdata {
 return 301 /netdata/;
 }

 location ~ /netdata/(?<ndpath>.*) {
 proxy_redirect off;
 proxy_set_header Host $host;

 proxy_set_header X-Forwarded-Host $host;
 proxy_set_header X-Forwarded-Server $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_http_version 1.1;
 proxy_pass_request_headers on;
 proxy_set_header Connection "keep-alive";
 proxy_store off;
 proxy_pass http://netdata/$ndpath$is_args$args;

 gzip on;
 gzip_proxied any;
 gzip_types *;
 }
}

nginx 添加鉴权

nginx 目前开启的是全局 ssl ，即通过 443 端口进入的请求均为 https，但是upstream 上的服务依旧是 http。

创建认证文件，开启 nginx 基础认证

# 提示输入密码和确认密码
printf "username:$(openssl passwd -apr1)" > /etc/nginx/passwords

在 server directive 中开启认证

server {
 listen 443 ssl;
 # ...
 auth_basic "Protected";
 auth_basic_user_file passwords;
 # ...
 access_log /var/log/nginx/access.log;
 error_log /var/log/nginx/error.log;
}

HTTP 自动跳转HTTPS 安全配置

参考 Nginx 服务器证书安装

server {
 listen 443;
 #填写绑定证书的域名
 server_name www.domain.com; 
 ssl on;
 #网站主页路径。此路径仅供参考，具体请您按照实际目录操作。
 root /var/www/www.domain.com; 
 index index.html index.htm; 
 #证书文件名称
 ssl_certificate 1_www.domain.com_bundle.crt; 
 #私钥文件名称
 ssl_certificate_key 2_www.domain.com.key; 
 ssl_session_timeout 5m;
 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_prefer_server_ciphers on;
 location / {
 index index.html index.htm;
 }
}
server {
 listen 80;
 #填写绑定证书的域名
 server_name www.domain.com; 
 #把http的域名请求转成https
 rewrite ^(.*)$ https://$host$1 permanent; 
}

使用权威机构签名证书

查看证书内容

openssl x509 -in nginx.crt -noout -text

查看key内容

openssl rsa -in nginx.key -noout -text

申请腾讯云免费SSL证书

腾讯云免费ssl证书申请

Reference

Running Netdata behind Nginx

Enabling TLS support

Nginx 服务器证书安装

通过Travis CI 部署静态页面到 github page

Tue, 21 Jan 2020 00:25:33 +0800

Travis CI 部署 Hexo 生成文件到 master 分支

文档主要实现Hexo利用 Travis CI 完成 github page 部署。

由于 username.github.io 仓库不允许切换 github page 分支，必须将 master 分支作为静态资源分支，所以新建 develop 分支作为开发分支。

详细的步骤参考将 Hexo 部署到 GitHub Pages，此处主要贴出区别的 Travis CI 配置文件：

sudo: false
language: node_js
node_js:
 - 13.6.0
cache: npm
branches:
 only:
 - develop
script:
 - hexo generate
deploy:
 provider: pages
 skip-cleanup: true
 github-token: $GH_TOKEN
 keep-history: false
 target_branch: master
 local-dir: public
 on:
 branch: develop

上述配置信息解释参考 GitHub Pages Deployment。

参考文档

GitHub Pages Deployment

将 Hexo 部署到 GitHub Pages