语言建模目标

预训练的核心训练目标是语言建模（Language Modeling），即最大化模型对训练文本的预测概率。根据模型架构的不同，有两种主要变体：

因果语言建模（Causal Language Modeling, CLM）：用于自回归解码器模型（如 GPT、LLaMA、Qwen）。模型只能根据当前 token 之前的 token 来预测当前 token：

其中 \theta 是模型参数，x_{<t} 是位置 t 之前的所有 token。这种单向建模是自回归生成的基础。

掩码语言建模（Masked Language Modeling, MLM）：用于编码器模型（如 BERT、RoBERTa）。输入序列中随机遮盖 15% 的 token，模型需要根据上下文（包括左右两侧）预测被遮盖的 token：

其中 \mathcal{M} 是被遮盖位置的集合，x_{\setminus \mathcal{M}} 是未遮盖的上下文 token。

预训练数据

预训练数据的规模和质量直接决定模型能力：

训练数据规模演进：GPT-1 (5GB) → GPT-3 (570GB) → LLaMA-2 (2TB) → DBRX (12TB) → DeepSeek-V3 (14.8T tokens)。每一代模型的数据量增长约 3-10 倍。

计算成本

预训练是计算成本最高的环节。以 DeepSeek-V3（671B 总参/37B 活跃参数）为例：

• 训练数据：14.8T tokens
• 计算消耗：约 280 万 H800 GPU 小时
• 硬件成本：约 557 万美元（按租赁价格）
• 训练时间：约 2 个月（使用 2048 块 H800）

与后续阶段的关系

预训练是微调和对齐的基础。预训练向模型"注入"了世界知识和语言能力，而后续的微调和对齐则负责"塑造"模型的行为方式。没有充分的预训练，后续微调的效果将受到根本制约。

全量微调（Full Fine-tuning）

全量微调更新模型的所有参数。对于 70B 参数的模型，全量微调需要使用约 560GB 的 GPU 显存（FP16 精度），通常需要 8-16 张 A100-80G 或 H100-80G 显卡。

数学形式：

其中 \theta 是模型的所有参数，N 是训练样本数，\mathcal{L} 是任务相关的损失函数（如交叉熵），f(x_i; \theta) 是模型输出，y_i 是目标标签。

优点：理论上可达到最优适应效果。
缺点：训练成本极高，每个下游任务需要训练并存储完整的模型副本，不便于多任务部署。

参数高效微调（PEFT）

PEFT（Parameter-Efficient Fine-Tuning）只更新一小部分额外参数，冻结预训练参数不变。典型方法包括：

LoRA（Low-Rank Adaptation）：

W_0 是冻结的预训练权重，BA 是低秩分解的增量矩阵，秩 r 通常取 8、16 或 32。训练时只更新 B 和 A，W_0 保持不变。推理时可将 BA 合并入 W_0 中，不增加推理延迟。

AdaLoRA：动态分配参数预算到不同层，重要层分配更多参数，不重要层分配更少。

Prefix Tuning：在输入序列前添加可学习的连续向量（soft prompt），只更新这些向量。

全量微调 vs PEFT 对比

在 vLLM 中的微调部署支持

vLLM 支持动态加载多个 LoRA 适配器，无需重启服务：

# 启动 vLLM 服务，支持 LoRA
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --max-loras 4 \
    --max-lora-rank 64

# 请求时指定 LoRA 适配器
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "meta-llama/Llama-2-7b-hf",
        "messages": [{"role": "user", "content": "翻译成英文：今天天气很好"}],
        "extra_body": {"lora": "path/to/translation-adapter"}
    }'

vLLM 的 LoRA 支持基于 punica kernel 实现批量 LoRA 计算，同一 batch 中的不同请求可以使用不同的 LoRA 适配器，互不干扰。

对话格式训练

指令微调的训练数据采用对话格式，通常包含多轮交互。最常用的格式是 ChatML（Chat Markup Language）：

<|im_start|>system
你是一个乐于助人的 AI 助手。
<|im_end|>
<|im_start|>user
请解释量子计算的基本原理。
<|im_end|>
<|im_start|>assistant
量子计算利用量子力学中的两个核心原理——叠加（superposition）和纠缠（entanglement）...
<|im_end|>

ChatML 格式的关键元素：

• <|im_start|>：标记角色（system/user/assistant）的开始
• <|im_end|>：标记对话回合的结束
• 特殊 token ID：这些控制 token 在词汇表中分配特定 ID，训练时它们的 logits 不计入损失函数

损失掩码（Loss Masking）：在指令微调的损失计算中，只对 assistant 回复部分的 token 计算损失，对 user 输入和 system prompt 部分进行掩码：

其中 \mathcal{A} 是 assistant 回复部分的 token 位置集合。这种掩码防止模型在训练中"学习"复述用户的输入，确保模型只学习如何做出有用的回复。

数据构成

高质量的指令微调数据通常包含：

典型数据集

• OpenAssistant：~16K 人工标注对话
• ShareGPT：~90K 用户与 GPT 的真实对话
• Alpaca：52K GPT-4 生成的指令数据
• Dolly：15K 人工标注指令数据
• UltraChat：1.5M 多轮对话

与 RLHF 的关系

Instruction Tuning 是 RLHF 的前置步骤。在完整的 RLHF 流程中，Stage 1 就是指令微调（SFT）。基座模型在指令微调后虽然能遵循指令，但输出的"风格"可能不正确——缺乏对齐、容易胡编乱造。RLHF 的后续阶段（Reward Modeling + RL Optimization）负责进一步将模型输出与人类偏好对齐。

四阶段流程

RLHF 包含以下四个阶段：

Phase 1: SFT（监督微调）
  预训练模型 + 高质量指令数据 → 指令遵循模型

Phase 2: 偏好数据收集
  从 SFT 模型采样多个回复 → 人工标注偏好 (good/bad)

Phase 3: Reward Model 训练
  SFT 模型 + 偏好比较数据 → 奖励模型
  数据格式: (prompt, completion_A, completion_B, preference)

Phase 4: RL 优化（PPO）
  SFT 模型 + 奖励模型 → 对齐人类偏好的最终模型
  目标: 最大化奖励，同时保持与 SFT 模型的 KL 散度约束

Bradley-Terry 模型（奖励模型训练）

奖励模型的训练目标是最大化人类偏好数据的似然。给定一个 prompt x 和两个输出 y_w（被偏好）、y_l（不被偏好），Bradley-Terry 模型假设人类偏好概率与奖励值的差异呈逻辑斯蒂分布：

其中 r_\phi(x, y) 是奖励模型（通常基于 SFT 模型，去掉最后的 unembedding 层，加上一个线性层输出标量），\sigma 是 sigmoid 函数。

训练损失：

这个损失函数的直觉是：最大化偏好回复与不偏好回复之间的奖励差距。

PPO 阶段

PPO（Proximal Policy Optimization）是 RLHF 中使用的强化学习算法。其目标函数为：

对于 LLM 的 RLHF 场景，PPO 损失进一步包含两个约束：

1. 奖励信号：R(x, y) = r_\phi(x, y) - \beta \cdot D_{\text{KL}}(\pi_\theta(y|x) \| \pi_{\text{ref}}(y|x))
2. KL 散度惩罚：防止模型过度偏离 SFT 模型，避免奖励黑客（reward hacking）问题：
   D_{\text{KL}}(\pi_\theta \| \pi_{\text{ref}}) = \mathbb{E}_{y \sim \pi_\theta} \left[ \log \frac{\pi_\theta(y|x)}{\pi_{\text{ref}}(y|x)} \right]

完整 PPO 损失：

其中 \beta 控制 KL 惩罚的强度，\alpha 决定了两种损失之间的权衡。

在 vLLM 中的奖励模型支持

vLLM 原生支持奖励模型推理（用于 RLHF 训练中的奖励计算或评估）：

# 加载奖励模型
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-Math-RM-72B \
    --task token_classify \
    --pooler-config '{"pooling_type": "ALL", "step_tag_id": null}'

# 使用 Score API 获得奖励分数
curl http://localhost:8000/v1/score \
    -H "Content-Type: application/json" \
    -d '{
        "model": "Qwen/Qwen2.5-Math-RM-72B",
        "text_1": "What is 2+2?",
        "text_2": "The answer is 4."
    }'
# 返回: {"score": 2.34}  (越高表示回复越好)

过程奖励模型（PRM）的 StepPool 实现：

class StepPool(AllPool):
    def forward(self, hidden_states, pooling_metadata):
        # 1. 调用 AllPool 获得全 token 输出
        pooled_data = super().forward(hidden_states, pooling_metadata)
        # 2. 只提取 step_tag_id 位置的隐藏状态
        step_mask = (input_ids == step_tag_id)
        return pooled_data[step_mask]

RLHF 的挑战

1. 训练不稳定：PPO 对超参数敏感，KL 惩罚系数 \beta 的调节需要大量实验
2. 奖励黑客：模型学会通过"取巧"获得高奖励而非真正改善质量
3. 奖励泄露：奖励模型可能学到表面特征（如偏好更长回复）而非真正的质量信号
4. 计算开销大：需要同时运行策略模型、参考模型、奖励模型和价值模型，共 4 个模型

数学推导

DPO 的出发点是将 RLHF 的最优策略解表示为闭式形式。经典的 RLHF 目标是：

这个优化问题有已知的闭式解：

其中 Z(x) 是配分函数。反过来，奖励函数可以用策略比率表示：

将奖励函数代入 Bradley-Terry 偏好模型：

配分函数 Z(x) 消掉了！得到：

最终 DPO 损失函数：

DPO vs RLHF 对比

局限性

DPO 的一个关键假设是存在一个在偏好数据上表现良好且无需进一步 KL 正则化的最优策略。当偏好数据存在噪声或不一致时，DPO 可能不如 PPO 稳健。此外，DPO 不支持在线采样——它只能从已有的偏好数据中学习，无法像 PPO 那样通过与环境的交互动态采样和优化。

工作原理

GRPO 的工作流程如下：

1. 给定 prompt x，从当前策略 π_θ 采样 G 个回复 {y_1, y_2, ..., y_G}
2. 为每个回复计算奖励 r(x, y_i)
3. 在组内计算优势函数：
   A_i = (r(x, y_i) - mean(r)) / std(r)
4. 使用组内优势更新策略 π_θ
5. 加入 KL 散度约束，防止偏离参考模型

核心优势函数

GRPO 的优势函数基于组内统计量，而非价值网络的估计：

其中 \mu_G = \frac{1}{G}\sum_{j=1}^G r(x, y_j)，\sigma_G = \frac{1}{G}\sum_{j=1}^G (r(x, y_j) - \mu_G)^2 是组内奖励的均值和标准差。

关键洞察：通过组内标准化，GRPO 消除了对价值网络的需求。价值网络是 PPO 中最易崩溃的组件之一，因为它需要为每个 token 位置估计未来回报的期望值。GRPO 将这个复杂问题简化为组内比较，显著提高了训练稳定性。

GRPO 目标函数

为什么 DeepSeek-R1 选择 GRPO

1. 价值网络是 PPO 的薄弱环节：价值网络需要准确估计任意状态下的预期回报，这在 LLM 的庞大状态空间中极为困难。GRPO 完全消除了这一依赖。
2. 组内比较天然消除偏差：同一组内的回复共享相同的 prompt，它们的奖励差异直接反映了生成质量差异，不受跨 prompt 的奖励波动影响。
3. 计算效率更高：无需维护价值网络，节省了一半的 GPU 显存和计算量。
4. 扩展性好：增加组大小 G 可以降低优势估计的方差，提供简单的扩展路径。DeepSeek-R1 论文中使用了 G=64 的组大小。

GRPO vs PPO vs DPO 对比

定义公式

对于包含 T 个 token 的测试序列 x = (x_1, x_2, \ldots, x_T)：

等价地，perplexity 是平均交叉熵损失的指数：

其中 \mathcal{L}_{\text{CE}} = -\frac{1}{T} \sum_{t=1}^{T} \log P(x_t | x_{<t})。

信息论解释

交叉熵与编码长度：交叉熵 H(P_{\text{data}}, P_{\text{model}}) 表示使用模型 P_{\text{model}} 的编码方案来编码真实分布 P_{\text{data}} 中的数据所需的平均比特数。Perplexity 是将这个比特数转换为"有效选择数"的结果。

Perplexity 作为分支因子：

• PPL = 100 意味着模型在预测下一个 token 时，面对的有效选择数相当于从 100 个等概率选项中挑选
• PPL = 2 意味着模型几乎能确定下一个 token（类似二元选择）

与信息量的关系：

这是每个 token 的平均信息量（以比特计），也称为模型的压缩率。

典型模型的 Perplexity

注意：perplexity 与词汇表大小和 tokenizer 密切相关，不同模型之间的 perplexity 比较必须在相同 tokenizer 和相同测试集上进行才有意义。

局限性

• 只衡量概率建模能力，不衡量生成质量、事实准确性或有用性
• 对短序列敏感，少量 token 的预测错误会显著影响整体值
• 无法捕捉语义连贯性和逻辑一致性
• 低 perplexity 不一定意味着高生成质量（如模型可能只学会了"安全"但无用的预测）

BLEU（Bilingual Evaluation Understudy）

BLEU 最初用于机器翻译评估，通过比较模型输出与参考翻译的 n-gram 重叠来衡量质量。

修正精度（Modified Precision）：

简短惩罚（Brevity Penalty, BP）：

最终 BLEU 分数：

通常 N=4，w_n = 1/N（即 BLEU-4）。

ROUGE（Recall-Oriented Understudy for Gisting Evaluation）

ROUGE 主要用于文本摘要评估，侧重于召回率而非精确率。

ROUGE-N：

ROUGE-L（基于最长公共子序列）：

BLEU vs ROUGE

局限性

• 语义盲区：只关注表面 n-gram 重叠，"汽车"和"车辆"被视为完全不匹配
• 同义词惩罚：语义等价但词汇不同的表达会被低分
• 无法评估创造性：对于开放式生成任务（如创意写作、对话），n-gram 重叠几乎无意义

学科覆盖

• STEM：数学、物理、化学、生物、计算机科学
• 人文：历史、哲学、法律、政治学
• 社会科学：经济学、心理学、社会学
• 其他：医学、会计、地质学等

测试方式：格式化选择题 prompt → 模型选择 A/B/C/D → 计算正确率。

分数解读

代表性模型分数：

批评

• 选择题格式限制了评估范围，不适用于开放式推理
• 部分题目可能泄漏到训练数据中（数据污染）
• 不同模型的 prompt 工程差异可能导致不公平比较

HumanEval

HumanEval 由 OpenAI 于 2021 年提出，包含 164 个手写 Python 编程问题，每个问题包含函数签名、docstring 和测试用例。

评估方式：Pass@k 指标——生成 k 个候选代码，至少有一个通过所有测试用例即算成功：

其中 n 是生成样本数，c 是通过测试的样本数。

MBPP（Mostly Basic Python Programming）

MBPP 包含约 974 个 Python 编程问题，相比 HumanEval 更基础（涉及字符串操作、列表处理等）。

MBPP vs HumanEval：

局限

• 只有 Python，不涵盖其他语言
• HumanEval 题目数量少（164 道），统计方差大
• 后续出现了更大规模的评估集：MultiPL-E（多语言）、SWE-bench（真实仓库级）、Codeforces（竞赛级）

GPQA（Graduate-Level Google-Proof Q&A）

GPQA 由纽约大学等机构于 2023 年发布，包含 448 道研究生级别的多项选择题。题目由领域专家撰写，覆盖物理、化学、生物学等。

特点：

• 问题难度极高（人类专家准确率约 65%）
• 题目不能被 Google 搜索直接解答（"Google-proof"）
• 需要真正的领域知识而非信息检索

MATH

MATH 包含 12,500 道数学竞赛题目，覆盖代数、几何、微积分等 7 个类别。

评估方式：5 levels of difficulty。每个问题需要模型生成带最终答案的完整解题过程。评估时提取最终答案与标准答案精确匹配。

GSM8K

GSM8K 包含约 8,500 道小学数学应用题，每道题需要 2-8 步推理。使用 CoT（Chain-of-Thought）可显著提升分数：

MT-Bench

MT-Bench 由 LMSYS 组织于 2023 年提出，包含 80 个高质量的多轮对话问题，覆盖 8 个类别（写作、推理、数学、编程、提取、STEM、人文、角色扮演）。

评估方式：使用 LLM-as-a-Judge（通常是 GPT-4）对模型回复进行 1-10 分的打分。每个问题包含两轮对话，更考验模型的对话连贯性。

局限性：

• LLM Judge 本身可能带有偏见（偏好特定风格或长度）
• 评价标准不完全透明
• 不同 LLM-as-Judge 模型可能给出不同结果

Chatbot Arena

Chatbot Arena（又称 LMSYS Chatbot Arena）是一个众包的 LLM 评估平台，采用匿名 A/B 测试 + ELO Rating 的方式进行模型排名。

ELO Rating 系统：

1. 用户匿名比较两个模型的输出，选择更好的一方
2. 基于比赛结果更新双方 ELO 分数：
   E_A = \frac{1}{1 + 10^{(R_B - R_A) / 400}}
R_A' = R_A + K \cdot (S_A - E_A)
   其中 R_A、R_B 是当前评分，E_A 是 A 获胜的期望概率，S_A 是实际结果（1 表示胜，0 表示负，0.5 表示平），K 是 K 因子（控制评分更新幅度）。
3. 经过大量配对比较后，ELO 评分收敛到反映模型相对质量的水平

特点：

• 亚马逊 Mechanical Turk + 网站用户参与，数据量大
• 与实际使用场景高度一致
• 不受单一评估者偏见影响
• 但是评估者的偏好可能不代表目标用户群体

CUDA Core

CUDA Core 是 NVIDIA GPU 中的通用标量计算单元。每个 CUDA Core 可以执行一个浮点或整数运算（如加法、乘法、逻辑运算）。它们基于 SIMT（Single Instruction, Multiple Threads）架构，32 个线程组成一个 warp，以 warp 为单位执行相同的指令。

典型规格：A100 有 6,912 个 CUDA Core，H100 有 16,896 个 CUDA Core。CUDA Core 的算力通常以 TFLOPS（FP32）衡量：A100 约 19.5 TFLOPS，H100 约 67 TFLOPS。

Tensor Core

Tensor Core 是 NVIDIA 从 Volta 架构（V100，2017 年）引入的专用矩阵计算单元，专门加速矩阵乘加运算（D = A \times B + C）。Tensor Core 可以在一个时钟周期内完成 4x4 矩阵的乘加操作，在 AI 训练和推理中发挥关键作用。

精度支持演进：

Tensor Core 关键算力（以 FP16 FMA 计算，TFLOPS）：

关键差异：Tensor Core 的 FP16 算力是 CUDA Core FP32 的 15-30 倍。这意味着当运算可以被量化为低精度矩阵乘法时（如 Attention 的 QK^T 和 PV 计算），性能可以提升 1-2 个数量级。

在 LLM 推理中的实际影响

在 vLLM 中，KV Cache 量化（FP8）和模型权重量化（FP8/INT4）依赖于 Tensor Core 的高效低精度计算：

# vLLM 中的 FP8 量化推理
# 使用 torch._scaled_mm（底层调用 Tensor Core 的 FP8 MMA）
import torch

# 假设 weight 和 input 都被量化为 FP8
weight_fp8 = weight.to(torch.float8_e4m3fn)
input_fp8 = input.to(torch.float8_e4m3fn)

# Tensor Core 的 FP8 矩阵乘法
# Hopper GPU 上比 FP16 快 2x
output = torch._scaled_mm(input_fp8, weight_fp8.t())

vLLM 的 float8_e4m3fn 支持需要 Hopper GPU（H100/H200）的 Tensor Core。在 Ampere GPU（A100）上只支持 INT8 Tensor Core 加速。

技术原理

HBM 通过硅通孔（Through-Silicon Via, TSV）技术将多个 DRAM 芯片垂直堆叠，并通过中间层（interposer）连接到 GPU 核心。这种 3D 堆叠架构实现了：

1. 超宽总线：HBM2e 有 1024-bit 的内存总线（GDDR6 为 32-bit），但运行频率较低
2. 高带宽：通过宽总线弥补低频的不足
3. 小体积：堆叠设计节省 PCB 空间

各代 HBM 规格对比

实际 GPU 中的 HBM 配置：

HBM 与 LLM 推理的关系

HBM 带宽是 LLM 推理最重要的硬件瓶颈。Decode 阶段是典型的内存带宽密集型操作：每次前向传播需要读取完整的模型参数（如 70B 模型约 140GB FP16 权重），而计算量却很小。在 A100（2 TB/s）上，理论最小 TPOT 约为 70ms/token（70B 模型，无 batching 时）。

这就是为什么 H200（4.8 TB/s）相比 H100（3.35 TB/s）在 LLM 推理中可获得 30-50% 的 token 生成速度提升——更高的 HBM 带宽直接缩短了每次读取权重的时间。

三级存储层次

GPU 的内存层次从上到下依次为：

寄存器 (Register)
  ↓  延迟: <1ns, 带宽: ~50 TB/s
SRAM (共享内存 / L1 缓存)
  ↓  延迟: ~5-10ns, 带宽: ~10-20 TB/s
HBM (高带宽显存)
  ↓  延迟: ~200-300ns, 带宽: 2-8 TB/s
DRAM (系统主内存, CPU 端)
  ↓  延迟: ~100-200ns（通过 PCIe/NVLink）, 带宽: 50-200 GB/s
SSD (磁盘存储)
  ↓  延迟: ~10-100μs, 带宽: 2-14 GB/s

各层级关键参数

FlashAttention 如何利用内存层次

FlashAttention 是 HBM-SRAM 层次利用的典范。传统 Attention 的计算模式是"从 HBM 读取 → 计算 → 写回 HBM"，而 FlashAttention 通过 Tiling（分块）技术将计算限制在 SRAM 中：

# 伪代码：FlashAttention 的 Tiling 策略
def flash_attention(Q, K, V, block_size):
    # 将 Q, K, V 切分为 B_m 和 B_n 大小的块
    for i in range(0, n, B_m):   # Q 块
        for j in range(0, n, B_n): # K, V 块
            # 将 Q_i, K_j, V_j 从 HBM 加载到 SRAM
            qi = load_to_sram(Q[i:i+B_m])
            kj = load_to_sram(K[j:j+B_n])
            vj = load_to_sram(V[j:j+B_n])

            # 在 SRAM 中进行矩阵乘法和 softmax
            s_ij = qi @ kj.T          # SRAM 运算
            p_ij = softmax(s_ij)      # SRAM 运算
            o_i += p_ij @ vj          # SRAM 累积

            # 最终结果写回 HBM
            save_to_hbm(o_i)

IO 复杂度对比：

• 标准 Attention：O(n^2 \cdot d) HBM 访问
• FlashAttention：O(n^2 \cdot d / M) HBM 访问，其中 M 是 SRAM 大小

实际中通常获得 2-4 倍的 attention 计算加速。

Memory Wall（内存墙）

Memory Wall（内存墙） 是指计算速度增长远快于内存带宽增长导致的性能瓶颈。在 LLM 推理中，Memory Wall 意味着：GPU 的计算能力远远超过其从 HBM 读取数据的能力，因此大部分推理时间花在数据搬运上，而非计算上。

定量分析（以 H100 + LLaMA-70B 为例）：

• 模型参数：140 GB（FP16）
• HBM 带宽：3.35 TB/s
• 读取所有参数的理论时间：140 GB / 3.35 TB/s ≈ 42 ms
• 而 H100 的计算能力：989 TFLOPS（FP16 Tensor Core）

一次 forward pass 的计算量约为 2 \times (L \times n \times d \times 4) \approx 2 \times 80 \times 4096 \times 8192 \times 4 \approx 21.5 TFLOPs

计算时间：21.5 TFLOPS / 989 TFLOPS ≈ 22 ms

实际时间 = max(42ms, 22ms) ≈ 42ms → 受限于内存带宽！

这就是为什么增加 HBM 带宽（如 H100→H200，带宽从 3.35→4.8 TB/s）比增加计算能力（H100→B200）对 LLM 推理的收益更直接。

主要版本对照

在 vLLM 中的影响

vLLM 在编译和运行时检查 Compute Capability 来决定启用哪些优化：

# vLLM 中的 Compute Capability 检查（简化）
import torch

capability = torch.cuda.get_device_capability()  # e.g., (8, 0) for A100

if capability >= (9, 0):  # Hopper
    # 启用 FP8 量化
    use_fp8 = True
elif capability >= (8, 0):  # Ampere
    # 使用 BF16 和 TF32
    use_bf16 = True
    allow_tf32 = True

if capability >= (8, 0):
    # 启用 FlashAttention（需要 Ampere 以上架构）
    use_flash_attn = True

InfiniBand

InfiniBand 是为高性能计算（HPC）设计的专用网络技术，提供极低延迟和高带宽：

特点：

• RDMA（Remote Direct Memory Access）：无需 CPU 干预，GPU 之间直接读写
• 低延迟：亚微秒级（~0.5-1μs）点对点延迟
• 无损网络：内置流量控制和拥塞管理，零丢包
• 成本高：专用交换机、网卡和线缆

RoCE（RDMA over Converged Ethernet）

RoCE 是在标准以太网上实现 RDMA 的协议。RoCEv2 将 RDMA 数据包封装在 UDP 中，运行在标准以太网上。

特点：

• 共享基础设施：与普通以太网共享交换机和线缆
• 需要 PFC（Priority Flow Control）：RoCE 依赖以太网的流量控制来保证无损传输
• 成本低：相比 InfiniBand，无特殊硬件需求
• 延迟略高：约 1-3μs 点对点延迟

在分布式训练中的对比

在 vLLM 分布式推理中的影响

vLLM 使用 NCCL（NVIDIA Collective Communications Library）进行 GPU 间通信。NCCL 自动选择最快的通信路径：

NVLink (同节点 GPU 间) > InfiniBand (跨节点) > RoCE (跨节点) > TCP/IP (兜底)

在多节点场景下（节点间通过 InfiniBand/RoCE），带宽大幅下降（典型 100-400 Gbps = 12.5-50 GB/s），TP 的通信开销会显著增加，因此通常限制 TP size 不超过单节点 GPU 数量。跨节点的分布式策略通常使用 PP（流水线并行）或 DP（数据并行），而非 TP（张量并行）。

三阶段流程

RAG 的核心流程为 Retrieve → Augment → Generate：

输入查询
    │
    ▼
[检索阶段] → Query Encoding → Vector Search / BM25 Search → 获取 Top-K 文档
    │
    ▼
[增强阶段] → 将检索文档与原始查询拼接为增强 prompt
    │
    ▼
[生成阶段] → LLM 基于增强 prompt 生成回复

详细步骤：

Step 1: Retrieve（检索）

Query: "什么是 LoRA 微调？"
  → Embedding Model 编码查询向量
  → 向量数据库近似最近邻搜索 (ANN)
  → 返回 Top-3 最相关文档:
    doc_1: "LoRA（Low-Rank Adaptation）..."
    doc_2: "Parameter-Efficient Fine-Tuning..."
    doc_3: "QLoRA: 4-bit 量化的 LoRA..."

Step 2: Augment（增强）

{{context}}
根据以下资料回答问题：
{doc_1}
{doc_2}
{doc_3}

问题：什么是 LoRA 微调？

Step 3: Generate（生成）

LLM 基于增强 prompt 生成：
"LoRA 微调是一种参数高效微调方法..."

RAG 的核心优势

主要策略对比

固定大小分块

最简单的方法，按固定的 token 数（如 256、512 或 1024）切割文档：

# 固定大小分块（带重叠）
def chunk_fixed(text, chunk_size=512, overlap=50):
    tokens = tokenizer.encode(text)
    chunks = []
    for i in range(0, len(tokens), chunk_size - overlap):
        chunk = tokens[i:i + chunk_size]
        chunks.append(tokenizer.decode(chunk))
    return chunks

重叠（overlap） 参数（通常为 chunk_size 的 10-20%）用于缓解切割点处语义断裂的问题。

基于文档结构的分块

利用文档的标题层级（Markdown #、HTML <h1> 等）作为自然的分块边界：

# 递归字符文本分割器（LangChain 实现）
from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ".", "!", "?", ",", " ", ""],
)
chunks = text_splitter.split_text(document)

语义分块

基于语义相似度检测"主题边界"的分块策略：

# 语义分块（简化版）
def semantic_chunk(text, sentence_model, threshold=0.8):
    sentences = split_into_sentences(text)
    chunks = []
    current_chunk = [sentences[0]]

    for i in range(1, len(sentences)):
        # 计算当前句与 chunk 平均 embedding 的相似度
        sim = cosine_similarity(
            sentence_model.encode(sentences[i]),
            sentence_model.encode(" ".join(current_chunk))
        )
        if sim > threshold:
            current_chunk.append(sentences[i])
        else:
            chunks.append(" ".join(current_chunk))
            current_chunk = [sentences[i]]

    return chunks

Chunking 质量评估指标：

• 检索命中率：与查询相关的文档是否被正确分割
• 语义完整性：chunk 内部是否具有一致的语义主题
• 信息密度：chunk 中有用信息的比例

主流 Embedding 模型

vLLM 支持的嵌入模型：

_EMBEDDING_MODELS = {
    "BertModel": ("bert", "BertEmbeddingModel"),
    "RobertaModel": ("roberta", "RobertaEmbeddingModel"),
    "RobertaForMaskedLM": ("roberta", "RobertaEmbeddingModel"),
    "JinaEmbeddingsV5Model": ("jina", "JinaEmbeddingsV5Model"),
}

选型考虑因素

1. 嵌入维度：高维度（1024-4096）提高检索精度但增加存储和计算成本。可使用 Matryoshka 嵌入（如 intfloat/e5-mistral-7b-instruct）进行降维（如 1024→256），同时保持好的检索效果。
2. 上下文长度：chunk 大小受限于嵌入模型的最大输入长度。bge/insstructor 的 512 token 限制对长文档分块构成约束，而 jina-embeddings-v3 和 gte 支持更长的上下文。
3. 对比学习训练：e5 和 bge 使用对比学习（Contrastive Learning）训练，能更好地区分语义相关的正样本和无关的负样本。

主流方案对比

向量搜索算法

HNSW（Hierarchical Navigable Small World）：当前向量数据库的主流 ANN 算法，构建多层图结构，高层图提供快速导航，低层图提供精确搜索。

# HNSW 搜索示意图
# 第 3 层（最高）: 🟢 → 🟢 → 🟢  (稀疏连接，长距离跳跃)
# 第 2 层:       🟢 → 🟢 → 🟢 → 🟢
# 第 1 层:       🟢 → 🟢 → 🟢 → 🟢 → 🟢 → 🟢
# 第 0 层（最密集）: 全连接图

HNSW 的搜索过程：从最顶层开始，贪婪地走向最近邻，然后下降到下一层重复，直到到达最底层。

IVF（Inverted File Index）：将向量空间划分为 N 个 Voronoi 单元，搜索时只搜索查询向量所在的单元和邻近单元。需要训练一个 K-means 聚类器来定义单元中心。

vLLM 中的 RAG 集成

vLLM 本身不做检索（不包含向量数据库），而是作为生成引擎。典型的 vLLM + RAG 架构为：

RAG 系统
├── 检索层: Milvus/Pinecone 等向量数据库
│   ├── Chunking: 文档切分为检索单元
│   ├── Embedding: 调用 vLLM 的 embed 接口编码
│   └── Indexing: 向量索引构建 (HNSW/IVF)
├── 精排层: vLLM 的 Rerank Model (cross-encoder)
│   └── Score API 的 classify 任务
└── 生成层: vLLM 的 LLM 推理
    └── Chat Completions API + 检索上下文

两阶段检索策略（在 vLLM 中的 Score API 支持）：

# 阶段 1: Bi-encoder 粗排（余弦相似度）
query_embedding = embed_model.embed([user_query])
doc_embeddings = embed_model.embed(doc_chunks)
scores = cosine_similarity(query_embedding, doc_embeddings)
top_k_indices = argsort(scores)[-50:]  # 粗排保留 Top-50

# 阶段 2: Cross-encoder 精排（vLLM Score API classify 任务）
pairs = [(user_query, doc_chunks[i]) for i in top_k_indices]
rerank_scores = rerank_model.score(pairs)  # cross-encoder 精排
final_indices = argsort(rerank_scores)[-5:]  # 精排保留 Top-5

密集检索（Dense Retrieval）

使用神经网络嵌入模型（如 bge、e5）将文本编码为稠密向量，通过向量相似度搜索：

• 优点：理解语义，同义词匹配（如"汽车"和"车辆"）
• 缺点：需要大量训练数据；对罕见词和精确匹配效果差

稀疏检索（BM25）

基于词频-逆文档频率（TF-IDF）的改进算法：

• 优点：精确关键词匹配，无需训练，可解释性强
• 缺点：无法处理同义词和语义相似

融合策略

Hybrid Search 通常使用加权融合或重排序融合：

# 加权融合
def hybrid_search(query, alpha=0.5):
    dense_scores = dense_search(query)   # 向量相似度
    sparse_scores = bm25_search(query)   # BM25 分数

    # 先对两种分数进行归一化
    dense_scores = min_max_normalize(dense_scores)
    sparse_scores = min_max_normalize(sparse_scores)

    # 加权融合
    final_scores = alpha * dense_scores + (1 - alpha) * sparse_scores
    return argsort(final_scores)

代表性重排序模型：RRF（Reciprocal Rank Fusion）：

其中 \text{rank}_m(d) 是文档 d 在方法 m 中的排名，k 是常数（通常 60）。RRF 不需要分数归一化，对分数分布不敏感。

核心评估指标

示例对比

假设有 3 个查询，每个查询的检索结果中相关文档的位置如下：

整体：Hit Rate = 2/3 ≈ 66.7%, MRR = (1.0 + 0.33 + 0) / 3 ≈ 0.44

NDCG 的额外价值：NDCG 考虑多个相关文档的位置，而非只关注第一个。例如如果 Q1 在位置 1 和 5 有相关文档，NDCG 会同时奖励两个位置（按折扣累加），而 MRR 只考虑位置 1。

HyDE 的直觉

Query: "What is the capital of France?"
  → LLM generates hypothetical document: "France's capital is Paris..."
  → Embed hypothetical document (not the query)
  → Search with this embedding
  → Better than query embedding because the embedding space alignment improves

各方法在 vLLM 生态中的定位

• Self-RAG：需要训练支持反射 token 的模型，不属于 vLLM 的推理优化范畴
• CRAG：对外部搜索的依赖超出了 vLLM 的能力边界
• RAPTOR：主要是一个分块和索引策略，可以与 vLLM 的嵌入服务和 Prefix Caching 结合使用
• HyDE：需要一个 LLM 来生成假设文档，可以直接使用 vLLM 的 Chat API 实现