VAD 的核心任务是 判断一段音频中哪些时间段有人说话哪些时间段没有人说话（也就是他就是一个音频是不是有静音的检测器），也就是区分语音和非语音（或静音）部分。想象一下，在一个有背景噪音的环境中，VAD 就像一个智能“守门人”，它能准确识别什么时候有人在说话，什么时候是纯粹的环境噪音或沉默。

VAD模型工作原理

音频数字化过程：声音通过震动转化为电压的模拟信号，但是电脑只能处理数字信号（01等），因此在数字化信号处理过程中通过ADC（模数转换器）进行处理，其主要是如下几件事情：1、采样每隔固定时间测量一次声音幅度，常用指标 Hz表示每秒采样多少声音副本（常用的8Hz、16Hz）；2、量化采样后数值结果是一批连续点，但是计算机存储数据范围有限如8bit就只有 2^8=256因此需要将数值进行量化处理如 0.123456V-->37，常用指标为 位深如8bit、16bit等；实际代码去理解音频处理过程（以模型训练中数据加载进行理解），在测试音频中通过绘制出波形图、Mel频谱图：

其中在波形图中，X 轴 = 时间，Y 轴 = 振幅（空气振动强度），密集振荡的区域 → 有声音，平坦区域 → 静音。在Mel频谱图中：X轴 = 时间，Y 轴 = Mel 频率（人耳感知的频率刻度，低频分辨更精细），颜色 = 能量 (dB)。它将一维时序信号变成二维热力图，同时展示什么频率在什么时候出现。

Mel 频谱图计算过程：
Step 1 — 预加重 (Pre-emphasis)：$y_t’ = y_t - \alpha \cdot y_{t-1}$（$\alpha \approx 0.97$），增强高频分量，补偿发声时声门和嘴唇对高频的衰减。
Step 2 — 分帧 (Framing)：将一维信号切成重叠的小段。每帧长度通常 20~40ms（如 16kHz 下 512 点 = 32ms），帧移通常 10ms（如 160 点）。帧与帧之间有重叠，保证时间上的连续性。
Step 3 — 加窗 (Windowing)：对每帧乘以汉明窗或汉宁窗，减少分帧带来的频谱泄漏（边缘截断效应）：$x_n^{windowed} = x_n \cdot w_n$。
Step 4 — STFT / FFT：对每帧做短时傅里叶变换，得到该帧的功率谱：$P = |\text{FFT}(x)|^2$。此时得到的是线性频率刻度上的能量分布。
Step 5 — Mel 滤波器组 (Mel Filterbank)：人耳对低频的分辨能力远高于高频。将线性频率 $f$（Hz）映射到 Mel 刻度：
\(m = 2595 \cdot \log_{10}\left(1 + \frac{f}{700}\right)\)
用 $N$ 个三角形滤波器（如 80 个）在 Mel 刻度上等距排列，对功率谱加权求和，得到 $N$ 维的 Mel 能量向量。
Step 6 — 转 dB (Log Compression)：$\text{Mel}{\text{dB}} = 10 \cdot \log{10}\left(\frac{\text{Mel}}{\text{ref}}\right)$，取对数压缩动态范围，也更贴近人耳对响度的对数感知特性。最终得到一个 (n_mels × n_frames) 的二维矩阵——即 Mel 频谱图。

回到VAD模型处理过程中，理想的VAD模型效果就是在上述波形图中找到静音区域（尽量不受到背景噪音的干扰）然后切分出来（亦或者从Mel图中剔除掉db小的内容）

前置知识

理解了上面的 Mel 频谱图计算过程后，我们还需要掌握几个贯穿所有 VAD 模型的核心概念，才能理解后面每个模型的参数为什么这样设计、该怎样调。

一、采样率（Sample Rate）

采样率 = 每秒采集多少个声音振幅的”快照”，单位 Hz。16kHz 意味着每秒在波形上取 16,000 个点。

为什么 VAD 几乎全是 16kHz？

• 人类语音主要能量集中在 300Hz ~ 3.4kHz（电话频带）。根据奈奎斯特定理，采样率 ≥ 语音最高频率 × 2 即可完整保留信息，所以 8kHz 就够了。
• 但 16kHz 能保留到 8kHz 的高频泛音（齿音、摩擦音等），这些对语音清晰度和 VAD 判断有帮助，而 44.1kHz/48kHz 的超声波段对 VAD 无意义只会增加计算量。
• 16kHz 是语音处理领域的黄金平衡点——信息完整、计算友好。

二、位深（Bit Depth）

位深 = 每个采样点用多少 bit 存储振幅值。8bit → $2^8=256$ 个可能值，16bit → $2^{16}=65,!536$ 个。16bit 是音频处理的标配——能表达从耳语到呐喊的动态范围而不过载或淹没在量化误差里。

三、分帧：帧长、帧移与重叠

为什么分帧？ 语音是非平稳信号，频率成分随时间剧烈变化。直接对整段 10 秒音频做傅里叶变换会丢失所有时间信息——你不知道哪个频率发生在第几秒。所以在 Mel 频谱图计算的 Step 2 中，我们把长音频切成几十毫秒的小片段（帧），假设每帧内信号近似平稳，对每帧分别分析。

两个关键参数：

例如 FSMN-VAD 的 frame_out_ms=25（帧长 25ms）、frame_in_ms=10（帧移 10ms），WebRTC VAD 固定 30ms 帧长。

帧长 25ms, 帧移 10ms:
|========帧0========|
          |========帧1========|
                    |========帧2========|
                              ...
|<-- 10ms -->|

四、特征：STFT 功率谱 vs Fbank（梅尔滤波器组能量）

不同 VAD 模型使用的输入特征不同，理解它们的区别很重要：

Fbank 就是 Mel 频谱图计算过程的 Step 1~5（跳过 Step 6 转 dB），得到的是 80 维能量值而非 dB。两者没有绝对的优劣：功率谱信息完整但维度高、冗余多；Fbank 压缩了维度，语音信息密度更高、模型更容易训练。

五、分贝（dB）：为什么用对数尺度

音频处理中几乎处处用 dB 而不是线性能量值，原因有两条：

1. 人耳对数感知：声压 10 倍 → 听感约 2 倍响。dB 就是对能量取对数，匹配人耳特性。
2. 压缩动态范围：耳语和呐喊的能量差可达 $10^6$ 倍，线性值下小信号完全被淹没。转 dB 后变成 60dB 差距，算法更好处理。

两个常用 dB 公式：

能量 VAD 中的 threshold_db=-30 意思是：帧 RMS 能量比最大 RMS 低 30dB 以下算静音。−30dB 约等于最大能量的 1/32，是一个比较保守的静音阈值。

六、VAD 后处理：滞后机制（Hysteresis）

这是理解 VAD 参数最核心的概念。模型输出的逐帧概率（0 或接近 1 = 语音，0 或 接近 0 = 静音）往往伴随频繁跳变——一帧语音、一帧静音、一帧语音……这是因为：

• 词语之间的短暂停顿（”今天——天气——很好”）
• 爆破音/塞音的瞬时低能量段
• 模型自身的抖动

直接按帧级概率切分会得到大量碎片。所有 VAD 都会用一套滞后（Hysteresis）机制来平滑：

flowchart TD
    A["逐帧概率"] --> B{"概率 > 阈值 ?"}
    B -->|是| C["触发计数 +1"]
    B -->|否| D["静音计数 +1"]
    C --> E{"连续触发 ≥ min_speech ?"}
    E -->|是| F["语音段开始"]
    F --> G["持续记录..."]
    G --> H{"连续静音 ≥ min_silence ?"}
    H -->|否| G
    H -->|是| I["语音段结束"]
    I --> J{"本段时长 ≥ min_dur ?"}
    J -->|是| K["保留此语音段"]
    J -->|否| L["丢弃（太短）"]

对应的常见参数（不同模型叫法略有不同）：

这四个参数的组合决定了 VAD 的激进程度——是宁可多切（保守，漏语音少但杂音多）还是宁可不切（激进，杂音少但可能漏语音）。

七、端点检测（Endpoint Detection）

FSMN-VAD 参数中大量的 start_point、end_point、lookback、lookahead 参数，就是端点检测的具体实现。核心思想与滞后机制一致，但更精细：

• 起点检测：连续 N 帧判语音后才标记起点，可以回溯（lookback_time_start_point）补回触发前的部分，避免切掉辅音开头
• 终点检测：连续 M 帧静音后才标记终点，可以提前（lookahead_time_end_point）减少延迟
• 双阈值 (Dual Threshold)：某些实现（如 FSMN-VAD 的 speech_noise_thresh_low/high）用高阈值确认”有语音”，用低阈值确认”语音结束”，防止能量波动导致反复切换

八、其他参数速查

有了这些前置知识，再看下面每个模型的参数表，就能理解每个参数控制的是哪一步、调大会产生什么效果。

常用VAD模型架构

WebRTC VAD — 高斯混合模型 (GMM)

Google 在 WebRTC 项目中开源的经典 VAD ¹，浏览器内置，极轻量零依赖，是实时通信场景的事实标准。采用纯信号处理方法，无需神经网络。

模型结构

特征提取¹：每帧提取 6 个子带（80Hz~4kHz 按对数刻度划分）的能量，得到一个 6 维特征向量。
模型结构：每个子带用 2 个高斯分布 分别建模语音和噪声的能量分布，共 12 个高斯分量。对每帧的 6 维特征向量，计算其在语音 GMM 和噪声 GMM 下的似然比：

LLR > 阈值则判为语音帧。GMM 参数通过 EM 算法离线训练，推理仅需查表 + 指数运算。

flowchart LR
    A[16kHz PCM] --> B[30ms 分帧]
    B --> C[6 子带能量]
    C --> D[语音 GMM 似然]
    C --> E[噪声 GMM 似然]
    D --> F[似然比 > 阈值?]
    E --> F
    F --> G[语音 / 静音]

模型使用

from AudioVADProcess import VADProcess

vad = VADProcess.create("webrtc", aggressiveness=2)
segments = vad.detect("audio.wav")

Silero VAD — CRNN（CNN + GRU）

Silero 团队开源的企业级 VAD ²，训练数据覆盖 6000+ 语种，模型仅 2MB，单 CPU 线程 <1ms/帧，社区最活跃的开源 VAD（GitHub 9.6k Stars）。

模型结构

特征提取²：输入 16kHz 音频 → 512 点 STFT（32ms 窗，10ms 帧移）→ 257 维功率谱。
模型结构（前向计算流）：

STFT (257, T)
  ↓
Conv1d(k=3, 257→128) + ReLU
  ↓
Conv1d(k=3, 128→64) + ReLU
  ↓
2× GRU(hidden=64, bidirectional)
  ↓
Linear(128→1) + Sigmoid
  ↓
每帧语音概率 ∈ [0, 1]

CNN 负责提取局部时频模式（如共振峰、谐波结构），双向 GRU 捕捉前后时间上下文（如语音段边界过渡），最后 Sigmoid 输出逐帧概率。总参数约 2MB，纯 PyTorch JIT，可导出 ONNX。

模型使用

from AudioVADProcess import VADProcess

vad = VADProcess.create("silero", threshold=0.6, min_speech_duration_ms=300)
segments = vad.detect("audio.wav")

FSMN-VAD — 前馈序列记忆网络

https://modelscope.cn/models/iic/speech_fsmn_vad_zh-cn-16k-common-pytorch/summary

模型结构

阿里达摩院在 FunASR 中开源的 VAD 模块 ³，基于前馈序列记忆网络（FSMN），专为中英文语音场景优化，仅 0.4M 参数。其具体模型结构：

特征提取³：80 维 Fbank（梅尔滤波器组能量），帧长 25ms，帧移 10ms。
模型结构：在传统的序列建模模型RNN/LSTM等在第 t 帧的结果依赖第 t−1 帧的隐藏状态，所以无法并行化，训练和推理都很慢，FSMN 的核心洞察是：序列建模不一定需要递归。如果你能让每一帧直接”看到”前后若干帧的信息，就能用纯前馈网络（可并行）达到类似的上下文建模效果，因此FSMN 的核心思想是在标准前馈网络（FFN）的隐藏层中插入 可学习的记忆模块 (Memory Block)：

其中 $h_t$ 是当前帧的隐藏向量，$a_i, c_j$ 是前向/后向记忆权重。相比 LSTM/GRU，FSMN 无需序列化递归计算，所有帧可并行前向传播，训练和推理都更快。对于上述个公式在具体的模型结构设计中对于输入特征维度 $(B,T,D)$ 直接可以通过循环去对时间维度 $T$ 进行读取然后进行编码即可，实际上更加高效的计算直接通过卷积进行实现：

class MemoryBlock(nn.Module):
  """FSMN 核心：可学习的固定窗口上下文加权模块。
  
  公式: h̃_t = h_t + Σ a_i ⊙ h_{t-i} + Σ c_j ⊙ h_{t+j}
  
  关键设计：a_i, c_j 是 d 维向量（不是矩阵），参数量仅 O(d × (N+M))，
  远小于自注意力的 O(d²)。
  """
  
  def __init__(self, dim: int, forward_order: int, backward_order: int):
      """
      Args:
          dim: 隐藏层维度 d
          forward_order: 前向阶数 N（看过去多少帧）
          backward_order: 后向阶数 M（看未来多少帧）
      """
      super().__init__()
      self.N = forward_order   # 前向记忆阶数
      self.M = backward_order  # 后向记忆阶数
      
      # 可学习的记忆权重向量，形状 (N+1, dim) 和 (M, dim)
      # +1 是因为 i=0 也包含在内（当前帧自身的 weight）
      self.forward_weights = nn.Parameter(torch.randn(forward_order + 1, dim) * 0.02)
      self.backward_weights = nn.Parameter(torch.randn(backward_order, dim) * 0.02)
  
  def forward(self, x: torch.Tensor) -> torch.Tensor:
      """
      Args:
          x: (B, T, dim) — 批量 × 时间帧 × 隐藏维度
      Returns:
          (B, T, dim) — 融合上下文后的增强表示
      """
      B, T, d = x.shape
      out = torch.zeros_like(x)
      
      # ---------- 逐帧计算（可优化为 conv1d，这里保持公式的直观性）----------
      for t in range(T):
          # --- 前向部分：Σ a_i ⊙ h_{t-i}，i = 0..N ---
          forward_sum = torch.zeros(B, d, device=x.device)
          for i in range(self.N + 1):
              idx = t - i
              if idx >= 0:
                  forward_sum = forward_sum + self.forward_weights[i] * x[:, idx, :]
          
          # --- 后向部分：Σ c_j ⊙ h_{t+j}，j = 1..M ---
          backward_sum = torch.zeros(B, d, device=x.device)
          for j in range(1, self.M + 1):
              idx = t + j
              if idx < T:
                  backward_sum = backward_sum + self.backward_weights[j - 1] * x[:, idx, :]
          
          out[:, t, :] = x[:, t, :] + forward_sum + backward_sum
      
      return out


class FastMemoryBlock(nn.Module):
  """MemoryBlock 的高效卷积实现版本。
  
  将逐元素加权求和等价为 depthwise 1D 卷积：
  - 前向部分等价于 causal conv1d (groups=dim)
  - 后向部分等价于 anti-causal conv1d (groups=dim)
  """
  
  def __init__(self, dim: int, forward_order: int, backward_order: int):
      super().__init__()
      self.N = forward_order
      self.M = backward_order
      
      # 前向权重：shape (dim, 1, N+1)，作为 depthwise conv 的 kernel
      # 卷积核排列：[w_0, w_1, ..., w_N]（从左到右 = 从当前到过去）
      fwd_kernel = torch.randn(dim, 1, forward_order + 1) * 0.02
      self.register_buffer('fwd_kernel', fwd_kernel)
      
      # 后向权重：shape (dim, 1, M)，右侧填充 0 作为 anti-causal
      bwd_kernel = torch.randn(dim, 1, backward_order) * 0.02
      self.register_buffer('bwd_kernel', bwd_kernel)
      
      # 用 Parameter 方式（支持训练）：
      self.fwd_weight = nn.Parameter(torch.randn(dim, 1, forward_order + 1) * 0.02)
      self.bwd_weight = nn.Parameter(torch.randn(dim, 1, backward_order) * 0.02)
  
  def forward(self, x: torch.Tensor) -> torch.Tensor:
      """
      x: (B, T, dim) → permute → (B, dim, T) 作为 depthwise conv 的输入
      """
      B, T, d = x.shape
      x_t = x.permute(0, 2, 1)  # (B, dim, T)
      
      # 前向 causal conv：padding 在左侧，只看过去
      fwd_out = F.conv1d(
          x_t, self.fwd_weight, groups=d,
          padding=self.N  # 左侧 pad N 个零（保证 causal）
      )[:, :, :T]  # 裁掉右侧多余的
      
      # 后向 anti-causal conv：padding 在右侧，只看未来
      bwd_out = F.conv1d(
          torch.flip(x_t, [2]),  # 时间反转
          self.bwd_weight, groups=d,
          padding=self.M
      )[:, :, :T]
      bwd_out = torch.flip(bwd_out, [2])  # 再反转回来
      
      out = x_t + fwd_out + bwd_out
      return out.permute(0, 2, 1)  # (B, T, dim)

不过在具体的“时序”数据中因为未来时间信息是未知的所以训练/推理过程中比较有效的策略：1、离线推理过程：训练过程中双向+推理使用双向，不过训练过程中直接使用 Dropout 随机不让 未来 信息融入；2、实时推理：此时需要将模型退化为因果FSMN（$tilde{h}t = h_t + \sum{i=0}^{N} a_i \odot h_{t-i}$），而为了保证实时推理的有效一般策略是使用 状态累计策略，通过固定采集音频进行输入而后对采集的音频中进行 “静音片段检测”当片段超过累计则进行放回，具体流程如下：

FSMN-VAD 仅 0.4M 参数，是当前最小的高精度 VAD。

模型使用

音频特征参数：

端点检测参数：

分段控制：

噪声与能量门限：

推理环境：

from AudioVADProcess import VADProcess

vad = VADProcess.create("fsmn", speech_noise_thres=0.9, sil_to_speech_time_thres=100,
                        max_single_segment_time=10000, device="cuda")
segments = vad.detect("audio.wav")

pyannote.audio — SincNet + LSTM + Self-Attention

法国 CNRS 开源的说话人日志工具包 ⁴，学术基准长期 SOTA，其语音活动检测（SAD）模块端到端从原始波形学习，无需手工特征。

模型结构

特征提取：直接用 SincNet 从原始波形学习滤波器，无需 STFT：

$f_l, f_h$ 是可学习的低/高频截止频率，相当于在频域学习一组带通滤波器。
模型结构：

原始波形 (1, T)
  ↓
SincNet (学习 64 个带通滤波器)
  ↓
2× LSTM (hidden=128, bidirectional)
  ↓
Multi-Head Self-Attention (4 heads)
  ↓
Linear(128→1) + Sigmoid
  ↓
逐帧语音概率

SincNet 替代手工 Fbank/STFT，端到端从波形学习；LSTM 建模长程时序依赖；自注意力聚合全局上下文，捕捉整段音频的语音分布模式。

模型使用

from AudioVADProcess import VADProcess

vad = VADProcess.create("pyannote", token="hf_xxx")
segments = vad.detect("audio.wav")

FireRedVAD

模型结构

小红书开源VAD模型⁵模型参数上只有0.6M基于DFSMN同时支持流式和非流式的使用，FSMN模型结构介绍

模型使用

from fireredvad import FireRedVad, FireRedVadConfig

config = FireRedVadConfig(
    use_gpu=use_gpu, speech_threshold=speech_threshold,
    smooth_window_size=smooth_window_size,
    min_speech_frame=min_speech_frame, max_speech_frame=max_speech_frame,
    min_silence_frame=min_silence_frame, merge_silence_frame=merge_silence_frame,
    extend_speech_frame=extend_speech_frame, chunk_max_frame=chunk_max_frame,
)
vad = FireRedVad.from_pretrained(model_dir, config)
result, _ = vad.detect(audio)

能量 VAD — RMS 阈值

最简单的 VAD 实现，仅依赖信号处理计算帧能量，零模型依赖、零网络请求、零额外存储，适合快速原型和噪声可控的环境。

模型结构

最朴素的方法：计算每帧 RMS → 转 dB → 与固定阈值比较。

$\text{dB}_t > \theta$（如 −30dB）判为语音。零模型依赖，但阈值固定，无法应对动态噪声环境。

模型使用

from AudioVADProcess import VADProcess

vad = VADProcess.create("energy", threshold_db=-25, min_speech_ms=100)
segments = vad.detect("audio.wav")

auditok — 能量 + 频谱

基于能量和频谱特性的纯算法 VAD，Python 生态中轻量级音频切分工具，无需训练，开箱即用。

模型结构

基于能量和频谱特性的传统信号处理方法。对音频流进行实时分帧，计算每帧短时能量，当能量连续超过阈值且持续足够时长时标记为语音段。核心逻辑为状态机：静音 → 检测到能量 → 语音段开始 → 能量持续低于阈值 + 静音超时 → 语音段结束。无需训练数据，纯算法实现。

模型使用

from AudioVADProcess import VADProcess

vad = VADProcess.create("auditok", energy_threshold=45, min_dur=0.5)
segments = vad.detect("audio.wav")

VAD模型补充介绍

训练/推理过程

• 训练数据构建

音频数据结构一般对于输入的音频读取过程中，假设直接通过torchaudio去读取 waveform, sample_rate = torchaudio.load("test.wav")对于两部分返回内容分别表示：1、sample_rate：采样率；2、waveform：[channel, time]表示通道数量以及音频采样点数量。比如说16Hz，3秒，单声道返回结果就是 torch.Size([1, 48000])。一般而言模型输入数据主要是两种：1、直接输入waveform数据；2、直接输入输入Mel/Fbank特征（会将音频的 waveform 数据进行转换）：对于输入为 [1, 48000]会直接转换为 [T,F]比如说 [300, 80]那么这样一来音频就变成 [bs, 300, 80]。

如果音频长度不一致一般就直接用padding策略即可

标签构建过程对于输入音频只需要标记出来中间那些位置有音频，比如说10s的音频设置10ms（每一秒100帧），那么0.80s ~ 3.50s对对应帧 80 到帧 349，全部标1依次类推这样一来标签就变成了：[0,0,...,1,...1,0...0]，但是对于训练数据如何去对音频截取窗口就需要考虑：因为很可能一段音频里面大部分都是静音的，这样就会导致模型效果不佳。一般的处理策略很多比如说有些ASR模型会返回每个字所对应的时间戳直接去根据这个时间戳截取即可。

• 损失函数设计

损失函数构建可以直接使用二元交叉熵损失函数处理即可

• 推理过程

对于输入音频进行读取获取1维的数组（如果双通道直接取平均即可）假设得到数据维度为 [1, 3s x 16000hz]，而后将1维的波形特征转化为2维矩阵特征假设得到维度信息为：[1, 300帧, 80]而后直接将这个音频输入到模型这哦你进行推理输出每一帧的概率 [1,300,1]。但是输出结果中可能出现在 t帧位置判断为静音（可能是错误判断），但是不能根据这个又把音频切分成两段，因此需要一个后处理过程最简单的就是直接静音帧累计策略（静音帧数累计>30就认为应该切分了）

除此之外有些时候还会使用 speech_pad 策略就是将预测的时间范围向前向后补充部分帧避免截断为题出现

除此之外还需要考虑超长音频吹过程（不可能直接全部输入到模型中，显存处理不下）具体过程如下（假设模型结构为FSMN）：

参考

前置知识

所有内容只去介绍基本概念与使用，更加丰富的细节建议去看官方文档（或者直接AI）。docker文档¹、FastAPI²

并发控制

对于高并发问题最简单理解方式：100个请求同时发送过来你如何进行处理这100个请求。可以串行解决（做完A做B）也可以并行处理（处理A的同时去处理B）

高并发是一个复杂工程设计问题：比如说你的请求优先级高那么如何进行“插队”处理、你的视频内容很长直接下载放到内存中会导致内存问题、其他请求超时如何处理（比如处理1个请求10s超时设置时间是30s那么如果请求很多就会出现超时问题）等等

下面主要去介绍常用的处理 高并发处理方式如通过异步/多线程/多进程进行处理、通过Redis队列进行控制、基于Ray原生的处理方式进行控制等等。

异步/多线程/多进程

首先程序任务主要为两类：1、CPU 密集：一直在”算“，CPU 满载（图片处理、模型推理、加密、大量计算）；2、IO 密集：大量时间在”等“（网络请求/读写文件）。而对于异步/多线程/多进程可以简单理解为（以餐厅服务多人为例）：一个服务员等菜的时候去别的桌子（异步）、多个服务员同时共用一个厨师（多线程）、直接开多家餐厅（多进程）

进程好理解，在python有 GIL（全局解释器锁），同一时刻只有一个线程能执行 Python 代码，因此对于多线程和异步（两个都是处理IO密集的）使用“差异不大”，如果并发大（比如1w请求）可以考虑异步（不可能开1w个进程）、如果库是同步的就多线程（如request）

异步核心语法³，一般而言异步核心（一般而言涉及到高IO的可以用异步）就是如下几组语法：

import asyncio
# 声明协程函数
async def main():
    # 等待可以去执行其他任务
    await asyncio.sleep(3)
    # 创建 task，提交给事件循环调度执行（await 让出后才真正跑）
    task = asyncio.create_task(fetch())
# 创建 event loop 将main放进去进行循环调度
asyncio.run(main())

写异步操作过程中需要去注意：1、先去分析任务类型（如果是IO密集的），比如说使用fastapi中构建请求，就可以直接大胆的用异步比如说：

@app.get("/health")
async def health():
    ...

2、对于异步中其他语法可以简单理解：

• await：等待一个异步任务执行完成，并在等待期间主动让出 CPU 控制权，让事件循环去执行其他协程，不过await后只能跟协程/task/future
• asyncio.run：启动整个异步程序，并创建事件循环（Event Loop）去执行指定协程
• asyncio.create_task：去创建多个task任务，比如说一般会有health任务去检查所有服务，那么可以直接通过此方法直接去创建多个task然后异步执行
• asyncio.gather：并发执行多个协程，并等待所有协程全部完成后统一返回结果

Ray原始并发控制

Ray 在 actor/task 层面提供了原生的并发与容错控制，核心参数都写在 @ray.remote 装饰器（或调用时的 .options()）里：

@ray.remote(
    num_gpus=0.25,          # GPU 配额:分数=多个 actor 分时共用一张卡(逻辑调度配额,非物理隔离)
    max_concurrency=4,      # actor 内并发上限:一个 actor 同时最多处理 4 个调用(线程池)
    max_restarts=3,         # actor 进程崩溃后最多自动重建 3 次
    max_task_retries=2,     # 单次调用失败后最多自动重试 2 次
)
class Model:
    def infer(self, x): ...

并发控制原理：Ray 对 Actor 的并发控制分为两层——调度层 和 执行层。调度层由 Raylet + GCS 负责：当多个调用同时发往同一个 Actor 时，Raylet 先把它们放进该 Actor 的内部任务队列；执行层由 Actor 进程内的线程池（大小 = max_concurrency）消费这个队列——每个线程从队列取一个调用执行，执行完再取下一个，直到队列为空。

sequenceDiagram
    participant C1 as 调用方 A
    participant C2 as 调用方 B
    participant C3 as 调用方 C
    participant RL as Raylet (本地调度)
    participant TQ as Actor 内部任务队列
    participant TP as Actor 线程池<br/>(max_concurrency=2)
    participant GPU as GPU

    C1->>RL: actor.infer.remote(img1)
    C2->>RL: actor.infer.remote(img2)
    C3->>RL: actor.infer.remote(img3)

    RL->>TQ: 三个调用依次入队

    Note over TP: 线程-1 取任务1<br/>线程-2 取任务2<br/>任务3 排队等待

    TP-->>GPU: 线程-1 执行推理
    TP-->>GPU: 线程-2 执行推理

    Note over GPU: GPU kernel 实际串行<br/>但预处理/后处理可重叠

    TP->>C1: 返回结果1
    Note over TP: 线程-1 空闲 → 取任务3
    TP->>C2: 返回结果2
    TP-->>GPU: 线程-1 执行推理 (任务3)
    TP->>C3: 返回结果3

关键理解：max_concurrency 只是决定了同时有几个线程在”伺候”这个 Actor，但 GPU 计算本身是串行的——多个线程的 GPU kernel 在 CUDA stream 上排队执行。所以 max_concurrency 的实际收益来自让 IO/预处理与 GPU 计算重叠（线程 A 等在 GPU 上时，线程 B 可以做图像解码），而不是让 GPU “同时算两件事”。

几个要点：

• max_concurrency：控制 单个 actor 内部 的并发。注意 Python GIL + GPU kernel 本身是串行的，设 >1 主要让预处理/IO 与计算重叠，真正的 GPU 计算还是排队；对 非线程安全 的模型（比如 vLLM 引擎）必须设成 1 强制串行，否则并发进同一模型会崩。
• num_gpus：填分数（<1）时多个 actor 会被打包到同一张卡分时复用，它是 Ray 的调度配额不是显存物理隔离，所以同卡上几个 actor 的显存要自己算好别超（比如 0.2+0.5+0.3=1.0 刚好一张卡）。
• max_restarts + max_task_retries：容错，actor 崩了 Ray 自动拉起、调用失败自动重试。
• 超时取消：ray.get(ref, timeout=...) 超时后可 ray.cancel(ref)，但 同步方法一旦开跑就无法中断，cancel 只能撤掉还没起跑的排队任务（所以超时了 GPU 其实还在跑，要靠限流从源头控制）。

Ray 原生并发是”actor 内”的并发，实际工程里常在它之上再加一层 API 入口的信号量/限流做背压：给每个模型建一个大小 = 它 max_concurrency 的信号量，满额直接拒绝（快速失败返回 503），而不是让请求堆在 Ray 队列里干等到超时——这样慢模型的积压不会白白空耗 GPU，超时也不会误触发熔断。

Redis队列控制

用 Redis 做队列本质是削峰填谷：请求先进队列缓冲，后端 worker 按自己的处理能力慢慢消费，避免瞬时高并发直接压垮推理服务。典型三个角色：

• 生产者（API 层）：收到请求把任务塞进 Redis 队列（LPUSH），立刻返回一个任务 id（异步任务模式，不阻塞等结果）。
• 消费者（worker）：循环从队列阻塞取任务（BRPOP）处理，结果写回 Redis（SET result:<id>）。
• 客户端：拿 id 轮询结果，或用 WebSocket 等服务端推送。

并发控制原理：Redis 队列实现的是消费端拉取模式——不是服务端主动推送，而是多个 worker 自己去抢任务，天然形成竞争消费。核心依赖 Redis List 的以下特性：

sequenceDiagram
    participant P as 生产者 (FastAPI)
    participant R as Redis List<br/>"infer_queue"
    participant W1 as Worker 1
    participant W2 as Worker 2
    participant M as GPU (模型推理)
    participant S as Redis KV<br/>result:(id)

    Note over P,S: ═══ 正常消费（消费 > 生产） ═══

    P->>R: LPUSH task_1
    W1->>R: BRPOP (阻塞等待)
    R->>W1: 弹出 task_1
    W1->>M: model.infer(task_1)
    M->>W1: 推理结果
    W1->>S: SET result:1

    Note over P,S: ═══ 多个 Worker 竞争消费 ═══

    P->>R: LPUSH task_2
    P->>R: LPUSH task_3

    par 竞争弹出
        W1->>R: BRPOP → 拿到 task_2
        W2->>R: BRPOP → 拿到 task_3
    end

    Note over W1,W2: Redis 单线程保证<br/>task_2 和 task_3 不会<br/>被同一个 Worker 取走

    par 并行推理
        W1->>M: infer(task_2)
        W2->>M: infer(task_3)
    end

    W1->>S: SET result:2
    W2->>S: SET result:3

    Note over P,S: ═══ 削峰场景（生产 > 消费） ═══

    P->>R: 瞬时 LPUSH 1000 个任务
    Note over R: 队列堆积 1000 条<br/>生产者已返回 task_id<br/>不阻塞、不丢请求

    loop 逐条消费
        W1->>R: BRPOP → 取一条 → 推理 → 写结果
        W2->>R: BRPOP → 取一条 → 推理 → 写结果
    end

    Note over R: 队列逐渐消化，最终归零

关键理解：Redis 队列的并发能力来自 “单队列 + 多消费者竞争”——队列本身只是一条 List，没有复杂的锁或分片，但多个 Worker 同时 BRPOP 时，Redis 的单线程模型天然保证每条任务只被一个 Worker 取走，不需要额外的分布式锁。横向扩展只需要加 Worker 进程数即可，Worker 之间完全无状态、无协调开销。

import redis
r = redis.Redis()

# 生产者:入队,立即返回 task_id
r.lpush("infer_queue", task_json)

# 消费者:阻塞取任务 --> 推理 --> 结果回写(存1小时)
_, task = r.brpop("infer_queue")
result = model.infer(task)
r.set(f"result:{task_id}", result, ex=3600)

它的价值：

• 削峰：1w 请求瞬时进来，队列缓冲，worker 不会被打爆；
• 限流/优先级：用多个队列（高优先级队列先消费）就能实现前面说的“插队”；
• 解耦+横向扩展：worker 可以多开几个进程/机器一起消费同一个队列。

生产上一般不自己撸队列，直接用 Celery / RQ（底层就是拿 Redis 当 broker）。这套模式最适合耗时任务异步化——比如前面提到的“长视频处理”，把同步 HTTP 变成“提交任务–>轮询/回调拿结果”，请求端秒回不占连接。

增加节点副本数量

在使用 Ray进行并发控制中单 actor 进程内推理串行（一个模型实例同时只跑一个请求），如果去提高并发数量可以直接 “扩充节点副本”（比如将开始的同一个功能的一个节点直接拓展到n个节点，通过这种方式同时也会带来显存的额外占用）其本质和多进程是相似的比如说下面代码：

import ray
from itertools import cycle

@ray.remote
class ModelA:
    def __init__(self): pass
    def output(self): return "A"

@ray.remote
class ModelB:
    def __init__(self): pass
    def output(self): return "B"

# 1) 配置里加副本数：(类, 副本数)
config = {
    "ModelA": (ModelA, 2),   # 起 2 副本
    "ModelB": (ModelB, 1),   # 单副本
}

ray.shutdown()
ray.init()

# 2) 命名展开 + 创建：N 副本注册为 name#0..name#N-1；1 副本沿用原名
def replica_names(name, n):
    return [name] if n <= 1 else [f"{name}#{i}" for i in range(n)]

actors = {}                      # {注册名: handle}
replicas = {}                    # {逻辑名: [注册名...]}
for name, (cls, n) in config.items():
    names = replica_names(name, n)
    replicas[name] = names
    for ray_name in names:
        actors[ray_name] = cls.options(name=ray_name).remote()

# 3) 轮询分流：每个逻辑名一个游标，round-robin 选副本
cursors = {name: cycle(names) for name, names in replicas.items()}

def pick(name):
    return actors[next(cursors[name])]

# ---- 使用 ----
print(actors)                    # {'ModelA#0':.., 'ModelA#1':.., 'ModelB':..}

for _ in range(4):               # 连续 4 次调用 ModelA，轮流落到 #0/#1
    ref = pick("ModelA").output.remote()
    print(ray.get(ref))

批处理

不去拓展额外的进程数量，可以通过批处理的方式提高并发，主要分为两种：1、动态批处理；2、连续批处理对于两种批处理方式解释如下：

• 1、动态批处理

对于同时输入的请求，可以尝试将这些请求进行合并组合到一起交给模型处理，比如说又yolo节点，同时输入3张图像（ABC）需要处理，如果是普通处理过程可能是：A->B->C，通过动态批处理则是直接将ABC三组图像组合交给模型处理（ 简单理解为模型训练过程中batch_size ），唯一需要注意的是需要设定批处理上线防止OOM出现，比如说以Yolo节点补充动态批处理为例：

import asyncio
import ray
from ultralytics import YOLO


@ray.remote(num_gpus=0.25)
class YOLOActor:
    def __init__(self, model_path="yolov8n.pt", max_batch_size=8, max_wait_ms=10):
        self.model = YOLO(model_path)
        self.max_batch_size = max_batch_size
        self.max_wait = max_wait_ms / 1000.0
        self._queue = None
        self._worker = None

    def _ensure_worker(self):
        if self._queue is None:
            self._queue = asyncio.Queue()
            self._worker = asyncio.create_task(self._batch_loop())
            
    async def _batch_loop(self):
        while True:
            first = await self._queue.get()                    # 阻塞等第一个请求
            batch = [first]
            start = asyncio.get_running_loop().time()
            while len(batch) < self.max_batch_size:
                remaining = self.max_wait - (asyncio.get_running_loop().time() - start)
                if remaining <= 0:
                    break
                try:
                    batch.append(await asyncio.wait_for(self._queue.get(), remaining))
                except asyncio.TimeoutError:
                    break                                      # 窗口到,不再等
            await self._run_batch(batch)

    async def _run_batch(self, batch):
        paths = [b[0] for b in batch]
        confs = [b[1] for b in batch]
        futs = [b[2] for b in batch]
        batch_conf = min(confs)
        try:
            loop = asyncio.get_running_loop()
            # 前向是同步阻塞(但 torch 计算段释放 GIL),丢到线程池避免卡住攒批循环
            results = await loop.run_in_executor(
                None, lambda: self.model(paths, conf=batch_conf, verbose=False)
            )
            for res, conf, fut in zip(results, confs, futs):
                fut.set_result(self._postprocess(res, conf))   # 按各请求自己的 conf 过滤
        except Exception as e:
            for fut in futs:
                if not fut.done():
                    fut.set_exception(e)                       # 整批失败,逐个报错

    @staticmethod
    def _postprocess(res, conf):
        dets = []
        if res.boxes is not None:
            for box in res.boxes:
                c = float(box.conf[0])
                if c < conf:                                   # 批用了最小 conf,这里按自身阈值筛
                    continue
                x1, y1, x2, y2 = box.xyxy[0].tolist()
                dets.append({
                    "bbox": [round(x1, 1), round(y1, 1), round(x2, 1), round(y2, 1)],
                    "class": res.names[int(box.cls[0])],
                    "conf": round(c, 4),
                })
        return dets
    
    async def infer(self, image_path: str, conf: float = 0.25):
        self._ensure_worker()
        fut = asyncio.get_running_loop().create_future()
        await self._queue.put((image_path, conf, fut))
        return await fut
ray.init()
actors = {"yolo": YOLOActor.options(name="yolo").remote()}
refs = [actors["yolo"].infer.remote(f"street{i}.jpg", conf=0.5) for i in range(16)]
for r in ray.get(refs):
    print(r)

对于上述批处理过程也比较简单：在每个节点内部创建队列在限制时间内的所有请求同时往队列中补充，在队满之后直接交给模型处理即可

• 2、连续批处理

主要是用在大模型文本生成过程中，比如说一般大模型模型处理过程⁴：

同时输入4个请求只有在最长的请求处理完毕之后这个批次才算解释，那么就会造成较大浪费，比如请求3在 $T_5$ 就已经处理完毕但是必须等到 $T_8$才能完成输出。那么 连续批处理过程就是优化这点

在 $S_3$ 在 $T_5$ 处理完毕之后下一秒直接将新的输入 $S_5$ 接着加入进来进行推理（保证时间利用最大化）。用下面列子解释过程，比如说bs=4其中ABC请求已经在生成处理，而请求E为新加入的请求其token长度为512，那么为了优化计算直接将4个请求就行拼接，那么此时输入形状为： [3+512,4096]，将输入拆分为不同的头（假设num_heads=32）那么：[515, 32, 128]，因为ABC这3个请求有KV-cache但是新的E是没有的那么：对于ABC这3组请求其KV为 [L+1, 32, 128]（其中L为历史长度）而E则是 [512, 32, 128]

值得注意的是：KV维度和Q一致都是 [1,32,128] 但是因为attention计算需要“之前内容”，因此就会把缓存的KVcache直接拿出来就行拼接也就是得到了 [L+1, 32, 128]

并发分析

除去上面介绍的几种方法，在并发控制中对于N卡还可以使用MPS⁵或者MIG⁶机制就行处理（需要注意不是所有的卡都支持），对于这两种机制都是都是让一张 GPU 被多个任务共享的机制。在模型部署推理过程中需要区分当前过程中的上限在哪里一般需要分析的有：

FastAPI

可以简单理解为将你的程序“打包成服务”，别人可以直接通过端口去访问你的代码，一个最简单例子：

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="fun-fastapi")

# 构建请求体
class SimpleComRequest(BaseModel):
    a: int = Field(description="实数A")
    b: int = Field(description="实数B")

@app.get("/v1/simple_com")
async def simple_com(request: SimpleComRequest):
    return request.a+ request.b

• @app.接口类型

一般而言 接口类型 如下几种，使用比较多的也就是get和post前者一般是获取信息，后者是提交任务

• 启动方式：一帮而言启动方式有两种：uvicorn main:app --port 8000 --host 127.0.0.1 --reload 或者直接 pyhton main.py其中第一种通过 --reload 参数保证代码修改之后自动重启服务不用每次都去手动启动服务，一般启动之后可以直接访问 127.0.0.1:8000/docs 去看所有的请求以及参数
• 请求体：可以简答理解为“函数参数”，别人调用你的服务用什么参数（对于参数越详细描述越好）

补充内容，除去上面使用的几种方式之外，实际开发过程中还会遇到如下几种场景：
1、实时交互，比如说我的模型都部署在服务器，但是我如果做实时视频监控识别/实时语音转录，此时就需要使用 websocket 功能（可以简单理解为双发不断“交换数据”协议），使用其核心作用在在于 前端、后端、算法端进行交互，以ASR（实时语音转录为例）对于这3端功能简要概述如下：后端负责不停地搬 + 给控制信号，算法负责在连续流里找句子的起止并出字，前端则是负责不断进行渲染。对于 websocket和前面的 post 请求方式类似：发送请求–>模型处理–>返回请求。那么大致伪代码如下（开发过程中需要注意前后算法确定彼此之间传递参数）：

音频处理过程主要流程：VAD（进行音频切分）–>ASR（进行音频转译）–>Punc（进行文本标点处理）

from fastapi import APIRouter, WebSocket, WebSocketDisconnect
router = APIRouter(prefix="/voice", tags=["voice-stream"])

# 请求端处理
@router.websocket("/stream/asr")
async def stream_asr(ws: WebSocket):
    await ws.accept()
    start = await asyncio.wait_for(ws.receive(), 60) # 持续从 ws 中接收
    if ...:
        # 发送错误信号
        await ws.send_json({"type": "error"})
    session = SessionProcess(...)
    # 发送准备信号
    await ws.send_json({"type": "ready"})
    while True:
        msg = await asyncio.wait_for(ws.receive(), 60) # 接受信息
        data = msg.get("bytes")
        if data is not None:                      # 音频帧：边收边出 partial/final
            await session.feed(data)
            continue
        ...
        if t == "end":
            await _send_frames(ws, await session.finish())
            await ws.send_json({"type": "done"})
            break
# 算法端处理
class SessionProcess:
    def __init__(...):
        self._pending = bytearray()
        self.buf = bytearray() # 对于音频可能就需要去考虑进行缓存累加，比如说缓存 1s 音频再去进行ASR处理，对于图像可能使用队列更加方便。两种核心都是 消费-生产模型
        ...
    async def feed(self, pcm: bytes):
        """接受数据-->缓存-->处理--->返回"""
        # 对于音频可能
        self.buf += pcm
        self._pending += pcm
        frames: List[dict] = []
        while len(self._pending)...:
            ...
            frames += await asr_process(...) # 主要返回字段 {"text":xxx}
        return frames

从上面代码可以发现对于 websocket 而言主要是如下几个功能：1、接收（信息）过程：直接通过ws.accept() 接收客户端消息，ws.receive()：接收消息，2、发送（信息）过程：发送和接受是相同的主要是发送2大类：文本帧以及 字节帧对于两者：

# 文本帧
{
    "type": "websocket.receive",
    "text": 'hello'
}
{
    "type": "websocket.receive",
    "text": '{"type":"start"}'
}
# 字节帧
{
    "type": "websocket.receive",
    "bytes": b'\x01\x02\x03\x04'
}

所以一般直接 ws.receive 而后后续直接 msg.get("text")或者 msg.get("bytes") 获取不同类型结果。

Docker

安装配置好docker之后运维国内监管可能需要去配置docker镜像

一句话介绍Docker作用：避免每次开发因为不同的开发环境问题而去抓狂。在docker中核心就是3部分组成：1、镜像（image）；2、容器（container）；3、dockerfile。对于这三部分实际上你可以简单的把image理解为可执行程序，container就是运行起来的进程。那么写程序需要源代码，那么“写”image就需要dockerfile，dockerfile就是image的源代码，docker就是”编译器”。因此我们只需要在dockerfile中指定需要哪些程序、依赖什么样的配置，之后把dockerfile交给“编译器”docker进行“编译”，也就是docker build命令，生成的可执行程序就是image，之后就可以运行这个image了，这就是docker run命令，image运行起来后就是docker container。

简单总结起来就是：dockerfile定义如何构建、image是构建后的模板、container是模板运行后的实例。首先我们编写 Dockerfile，用来描述项目需要什么环境、依赖以及启动方式；然后根据 Dockerfile 构建出 Image（镜像）；最后通过 Image 启动 Container（容器）运行程序。Container 可以理解为一个相对独立、隔离的运行环境，因此能够避免“我电脑能跑，你电脑跑不了”的问题。

如果要去打包一个docker需要执行的处理（直接AI分析去写所有的文件即可），1、写Dockerfile（去docker里面都需要执行哪些操作直接提前安排好运行），Dockerfile核心语法就是如下几个：FROM：使用的镜像比如说用到Python/Linux/cuda等版本信息、WORKDIR：设置工作目录、COPY：复制文件、RUN：执行命令（比如说apt install以及 pip install等命令）、CMD：相当于终端执行；2、docker-compose.yml文件；3、.dockerignore。
除此之外一些docker常用的基本命令：

对于上述语法中启动容器 docker run xxx里面 xxx一般就是镜像名称，在构建镜像之后可以直接 run即可，一般而言run的参数。所以一般而言Docker启动命令如下：

# 1、首先构建docker镜像，直接基于本目录去构建
docker build -t xxx:xxx . # 其中 xxx:xxx 代表具体镜像名称 . 代表当前目录，也就是说基于当前文件夹 Dockerfile 去构建docker镜像

# 2、创建docker容器
docker run -d --name example \
  --env-file .env.example \
  -e PORT=59420 \
  -v /data_share/model:/data_share/model \
  -v /本地文件夹:/docker文件夹
  -p 59420:8080 \
  xxx:xxx
# example为具体容器名称 xxx:xxx 为镜像名称 -p 分别代表本地端口:docker端口，也就是说docker内部放行8080走本地59420去访问 -v 去挂载目录，一般就是项目代码/模型权重

# 3、容器使用
docker logs example # 查看日志
docker stop example # 停止容器
docker rm -f example # 停止容器
docker rmi xxx:xxx  # 删除镜像
docker exec -it <容器名称或ID> /bin/bash # 进入容器

除去常用的docker语法，在使用过程中一般而言需要容器的“热重启”（本地修改–>容器自动修改）因此在启动容器时候就需要将本地文件进行挂载（使用参数 “-v” 即可），对于 Dockerfile 中 CMD 一般使用过程中我的 bash 脚本会去使用部分参数比如在使用fastapi中去使用端口等，在启动容器时候只需要 -e 脚本参数

Ray

一句话介绍Ray：主要是进行分布式计算 / 并行计算的开源框架，核心目标是：让你用“写本地 Python 的方式”，轻松把程序扩展到多台机器上运行（切记如果服务不涉及到多台府服务器协同/不是高并发不一定要用Ray）。不过Ray只负责管理核心计算还是Pytorch进行。 Ray 架构简单介绍，参考官方v2架构说明⁷简单介绍Ray架构设计，其中Ray 的架构可以拆解为五个核心组件：

Ray 核心组件

1. Node 组件：Head Node 与 Worker Node

Ray 集群由两类节点组成：

• Head Node（头节点）：集群的”大脑”。除了运行工作负载外，它还负责管理集群的全局状态（通过 GCS）、调度任务、运行 Dashboard 和 Autoscaler。它是集群中唯一知道所有节点信息的节点。
• Worker Node（工作节点）：集群的”手脚”。不参与全局决策，只负责接收 Head Node 分配的任务并执行。每个 Worker Node 上运行一个 Raylet 进程，负责本地的任务调度和资源管理。

可以把 Head Node 理解为建筑工地的总指挥，Worker Node 是各个工种的施工队——总指挥分配任务，施工队埋头干活。

2. Scheduler（调度器）

Ray 采用自底向上的分布式调度策略，调度逻辑分散在两层：

• Global Scheduler（全局调度器）：运行在 Head Node 的 GCS 中。它维护全局资源视图（哪个节点有空闲 GPU/CPU/内存），当本地调度器无法满足任务时接管调度。
• Local Scheduler（本地调度器，即 Raylet）：每个节点一个。优先在本地满足任务请求（减少数据传输），只有本地资源不足时才把任务”上报”给全局调度器。

这种设计避免了传统中心化调度的瓶颈——大多数任务的调度决策在本地就完成了，延迟极低。

3. Object Store（分布式对象存储）

Ray 基于 Apache Arrow / Plasma 实现了内存中的分布式对象存储，是 Ray 高性能的关键：

举个直观的例子：Worker A 在节点 1 上产生了一个 10GB 的 tensor，Worker B 在同一节点上可以直接”看到”它，就像两个线程共享同一块内存一样。

• 每个节点上运行一个 Object Store 进程（plasma_store），通过共享内存提供零拷贝的数据访问。
• 同一节点上的多个 Worker 进程可以通过共享内存直接读写同一份对象，无需序列化/反序列化。
• 跨节点的数据传输是惰性的——只有当某个节点的 Worker 真正需要某个对象时，才会从其他节点拉取。

4. Global Control Store（GCS，全局控制存储）

GCS 是 Ray 的分布式键值存储，运行在 Head Node 上，是整个系统的”中枢神经系统”：

• 存储集群元数据：节点列表、存活状态、资源总量。
• 存储系统状态：哪些 Actor 在哪个节点、函数定义、对象的位置信息（存储在哪个节点的 Object Store 上）。
• 提供 Pub/Sub 机制：当某个事件发生时（如节点故障、Actor 创建/销毁），GCS 会通知订阅者。

GCS 本身是一个 Redis-like 的 KV 存储，所有组件通过它与集群的”全局知识”交互。

5. Raylet

Raylet 是运行在每个节点上的守护进程（用 C++ 实现），是节点级的”管家”，负责三件事：

Raylet 的设计理念是”让每个节点自治”——即使 Head Node 暂时不可达，Worker Node 上的 Raylet 依然能继续调度本地的任务和执行中的 Actor。简单任务介绍一下上述过程：比如说使用Ray进行贝叶斯调参过程，假设我们一块CPU假设32个核心我们并行4组参数执行，每组任务拥有5个核心，那么此时我们就有4个Worker node，Head Node内部处理过程：去控制每次贝叶斯下一次的参数（比如说RF中节点数量等）那么此时计算出4组优化参数（如n、depth等），通过GCS（比如说告诉目前迭代轮次、指标等） 将任务写入队列，Scheduler 根据资源视图把任务分配到 4 个 Worker。每个Worker内部处理过程 ：各 Worker 的 Raylet 分配 5 个核，启动训练 → 结果写入本地 Object Store。 Head Node 拿到 4 个准确率 → 更新 GCS 中的历史记录 → 贝叶斯优化器计算下一轮参数 → 循环。

对于普通训练过程可能是：初始化参数–>进行参数计算得到效果–>贝叶斯优化器决定下一组参数–>循环

Ray Core

简单使用

Ray Core 是 Ray 的底层编程接口，上层的 Ray Data、Ray Train、Ray Tune 都建在它之上。它只做一件事：把”本地 Python”翻译成”集群上并行跑”。要理解它，先记住一个核心动作 .remote()：凡是加了它的调用都不阻塞，立刻返回一个 ObjectRef（可以理解为”取餐号”——任务还没好，但你先拿到了凭证），真正要结果时再用 ray.get() 凭号取餐。围绕这个动作，Ray 给了三个原语，解决三个递进的问题：

1、Task：把函数变成可并行的任务

最常见的需求：我有个函数要跑很多遍（不同参数），每遍互不相关，想并行。@ray.remote 就把普通函数变成”远程任务”。

import ray

@ray.remote                       # 装饰器：把函数注册为 Ray Task
def train_rf(n_estimators, max_depth):
    from sklearn.ensemble import RandomForestClassifier
    model = RandomForestClassifier(n_estimators=n_estimators, max_depth=max_depth)
    model.fit(X_train, y_train)
    return model.score(X_val, y_val)

# .remote() 发起任务：非阻塞，立刻返回 ObjectRef（取餐号）
refs = [train_rf.remote(n, d) for n, d in param_combinations]

# ray.get() 凭号取餐：阻塞，等所有结果回来
scores = ray.get(refs)

关键点：for 循环里的 4 个 .remote() 几乎瞬间执行完，因为它们只是”把任务提交出去”。4 个训练是在 4 个 Worker 上同时跑的，不是排队跑的。

对应到架构：@ray.remote 的函数定义被 GCS 记录 → 调用 .remote() 时 Scheduler 挑一个空闲 Worker 执行 → 返回值放进 Object Store，ray.get() 时取回。何时用：无状态的批量计算——批量调参、批量数据处理、Map 阶段。

2、Actor：把”加载一次”的东西常驻下来

Task 的问题：它是无状态的，每次调用都从零开始。如果每个任务都要先 YOLO("yolov8n.pt") 加载几百 MB 模型再推理，加载开销会把你拖死。Actor 解决这个问题——它是一个有状态、长期活着的 Worker：模型在 __init__ 里加载一次，常驻显存，之后每次 infer 直接用。

import ray
from ultralytics import YOLO

@ray.remote(num_gpus=0.25)          # 声明为 Actor，并分配 1/4 张 GPU
class YOLOActor:
    def __init__(self, model_path="yolov8n.pt"):
        self.model = YOLO(model_path)   # 只加载一次，常驻 GPU

    def infer(self, image_path: str, conf: float = 0.25):
        """对图片做目标检测，返回 bbox + 类别 + 置信度。"""
        results = self.model(image_path, conf=conf, verbose=False)
        dets = []
        if results[0].boxes is not None:
            for box in results[0].boxes:
                x1, y1, x2, y2 = box.xyxy[0].tolist()
                dets.append({
                    "bbox": [round(x1, 1), round(y1, 1), round(x2, 1), round(y2, 1)],
                    "class": results[0].names[int(box.cls[0])],
                    "conf": round(float(box.conf[0]), 4),
                })
        return dets
# 方式一
# 创建 Actor 实例：部署到某个 Worker，占用 0.25 张 GPU，模型在此刻加载
detector = YOLOActor.remote("yolov8n.pt")
# 调用方法：.remote() 仍然非阻塞，ray.get() 取结果
ref = detector.infer.remote("street.jpg", conf=0.5)
results = ray.get(ref)

# 方式二
ray.init()

model_class = {"yolo": YOLOActor}
actors = {}
for name, cls in model_class.items():
    # 将所有的节点加入到cluster中
    actors[name] = cls.options(name=name).remote()
model_a_ref = actors["yolo"].infer.remote("street.jpg", conf=0.5) # 传递参数给节点
print(model_a_ref, ray.get(model_a_ref)) # 获取节点结果

对于通过ray修饰的类在获取结果上先通过

Task vs Actor 的本质区别，看这张时序图（注意 __init__ 只发生一次）：

脚本进程                              Ray Worker 进程 (持有 GPU)
   │                                          │
   ├─ detector = YOLOActor.remote(...) ──────→│ 创建 Actor，执行 __init__
   │                                          │   YOLO(...) 加载到 GPU（仅此一次）
   │                                          │   模型常驻，等待调用
   │                                          │
   ├─ ref_a = detector.infer.remote("a.jpg")─→│ 直接推理（不再加载模型）
   ├─ ref_b = detector.infer.remote("b.jpg")─→│ 排队（受 max_concurrency 限制）
   │                                          │
   ├─ ray.get(ref_a) ←────────────────────────┤ 从 Object Store 取结果
   └─ ray.get(ref_b) ←────────────────────────┤

对应到架构：Actor 的生命周期由 GCS 管理，所在节点的 Raylet 为它分配资源、调度它的方法调用。何时用：需要”加载一次、反复用”的有状态场景——模型推理服务、维护计数器/缓存、有内部状态的流式处理。

3、Object：让数据在集群里零拷贝流转

前两个原语传的是”任务”，这个原语传的是”数据“。问题场景：你有个 10GB 的数据集，要被 4 个 Task 共用。如果每次 .remote(dataset) 都把它序列化、复制一份传过去，4 份 40GB，内存直接爆。ray.put() 把数据放进 Object Store 一次，返回一个 ObjectRef（指针），之后所有任务传这个引用就行，同节点的 Worker 直接共享内存读，零拷贝。

data_ref = ray.put(large_dataset)        # 放入 Object Store，返回引用（只存一份）

# 把"引用"传给任务，而不是数据本身
refs = [train_rf.remote(data_ref, params) for params in grid]
results = ray.get(refs)                   # 同节点零拷贝；跨节点才惰性拉取

其实你前面用 ray.get(refs) 取 Task / Actor 的结果时，背后就是 Object Store 在工作——所有 .remote() 的返回值都自动存在 Object Store 里。ray.put 只是让你手动把”输入数据”也放进去。

对应到架构：这就是前面 Object Store 组件讲到的——同节点共享内存零拷贝，跨节点惰性传输（谁用到才拉）。何时用：多个任务共享同一份大数据（数据集、大权重、配置），避免重复传输。
一句话总结 Ray Core：@ray.remote 把函数变 Task、把类变 Actor；ray.put/get 让数据通过 ObjectRef 在集群里透明流转。三者都靠 .remote() 异步发起、ray.get() 同步取回。理解了这三者，就理解了 Ray 的编程基础。除此之外，实际使用还绕不开两个配套能力：
1、资源分配，在 @ray.remote 装饰器里直接声明资源占用，如 @ray.remote(num_gpus=0.5, num_cpus=2)。注意 num_gpus=0.5 是软配额——Ray 只负责”按比例调度”，不强制隔离显存，靠你自己保证同卡上多个 Actor 显存加起来不超。支持的参数配置
2、并发控制，Actor 默认串行执行方法（一次一个），用 @ray.remote(max_concurrency=N) 可让单个 Actor 同时处理 N 个请求——配合上面的软配额，同一张卡上多个服务就能真正并发吃满 GPU。

参考

Claude Code简单使用

安装环境准备

目前大部分的skill或者说Clade Code运行任务（比如说读取文件等）都会用到python，因此就需要去安装python，除此之外如果要去安装一些skills还需要权重npm等，因此：在win电脑上更加建议直接使用wsl去搭建Claude Code，WSL安装方式，安装完毕之后其他命令就和linux安装命令相同，先去介绍基于WSL安装claude过程，执行如下命令：

对于配置DeepSeek：配置DeepSeek订阅

# ========== 1. 基础系统依赖 ==========
sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential python3 python3-pip python3-venv curl wget unzip git-all

# ========== 2. 安装 nvm + Node.js ==========
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash
# 重新加载 shell 配置
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
nvm install 26
node -v
npm -v
npm config set registry https://registry.npmmirror.com

# ========== 3. 安装 Miniconda ==========
wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/Miniconda3-latest-Linux-x86.sh
bash Miniconda3-latest-Linux-x86.sh -b   # -b 静默安装，跳过交互
~/miniconda3/bin/conda init bash
source ~/.bashrc

# ========== 4. 安装 Claude Code ==========
curl -fsSL https://claude.ai/install.sh | bash
# 确保 PATH 包含 ~/.local/bin（只添加一次）
grep -q 'export PATH="$HOME/.local/bin:$PATH"' ~/.bashrc || \
  echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

# ========== 5. 配置 DeepSeek API ==========
mkdir -p ~/.claude
cat > ~/.claude/settings.json << 'EOF'
{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "sk-你的DeepSeek-API-Key",
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_MODEL": "deepseek-v4-pro"
  },
  "autoUpdatesChannel": "latest",
  "theme": "dark"
}
EOF

# ========== 6. 安装 rtk ==========
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh
source ~/.bashrc
rtk init --global

对于WSL后续使用直接在终端里面输入 wsl 然后输入 claude 即可

安装与卸载

⭐在win电脑上更加建议直接使用wsl去搭建Claude Code，WSL安装方式，安装完毕之后其他命令就和linux安装命令相同

以win电脑为例按照官方过程直接输入命令即可，对于桌面端安装直接访问链接然后安装即可，对于终端安装参考链接首先安装 git然后直接终端（win+r 然后输入 cmd）执行安装即可：curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd或者直接：

打开 PowerShell然后输入安装命令：irm https://claude.ai/install.ps1 | iex
处理报错，如果遇到如下报错：

解决措施：（理论上）直接将VPN节点换到美国即可
处理报错，如果遇到报错 Failed to fetch version from https://downloads.claude.ai/claude-code-releases/latest: ECONNREFUSED

解决措施：将VPN开启虚拟网卡模式或者直接将VPN开全局代理即可
最后终端中出现如下界面表示安装完成

值得注意的是里面提到：Native installation exists.....，这是因为没有配置好系统环境变量，直接win+r然后输入 sysdm.cpl

点击确认即可完成环境变量配置处理。然后终端直接输入 claude
卸载过程就比较简单直接去删除对应文件即可，为了节约token选择直接安装rtk，首先下载对应文件并且解压（记住解压的路径），解压完成之后将对应文件添加到环境变量中（过程和上面配置claude code环境变量相同），然后 rtk.exe init --global（如果不行就直接输入D:\ClaudeCode\rtk.exe init --global，前面的路径为你解压路径）运行之后就可以开启节约token，值得注意的是如果环境变量添加了，终端输入 rtk 没有效果可以直接去 C:\Users\hjie\.claude\settings.json 里面修改配置，将里面的hook修改为

配置其他API

以DeepSeek配置过程为例，打开目录 C:\Users\hjie\.claude 然后

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "sk-",
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_MODEL": "deepseek-v4-pro"
  },
  "autoUpdatesChannel": "latest",
  "theme": "dark"
}

在配置完毕之后，打开 Powershell然后执行 claude

基础命令

在终端中所有的命令可以直接输入 / 来进行执行比如说切换模型 /model 然后按不同箭头选择模型（enter 回车选择模型），或者直接使用 @ 去访问文件等，简单使用过程中一般而言用的比较多的几个命令：1、/compact：去压缩对话，一般而言模型上下文有限去对上下文进行压缩

> /compact
# 基本压缩：将历史对话总结为关键要点
> /compact 保留认证模块的变更细节和当前测试失败信息
# 定向压缩：指定需要保留的重点内容

2、clear：完全重置，清空当前会话的全部对话历史和上下文，回到初始状态；3、/context查看上下文使用，显示当前上下文的占用情况和分类统计。除了基础命令之外有些时候还需要去控制claude 在执行一些 简单安全任务（比如说去搜索整理文件这些任务）在启动时候可以直接开启 claude --permission-mode auto强制自动判断需不要询问用户（一定要让他执行可信任务，不然可能删除一些重要东西导致出现错误，可以先去跑通一个任务之后，后续再去实现类似任务可以直接开启强制自动判断）或者直接在对话系统里面按键 shift+tab进行切换（直接切换到 auto mode on即可）：

而后再去执行 /sandbox（建立一个 沙盒隔离环境避免直接操作自己电脑导致误删文件等）

除此之外要监控各类task任务（比如说有些python自动脚本会到建立task）进行情况可以直接安装：npx claude-task-viewer然后就可以看到正在进行进程：

除此之外有些时候可能需要一次性进行多个任务（比如说去搜索A相关事情、搜索B相关事情）可以执行claude agents，这样就可以快速进行多组对话进行切换（或者直接在对话系统里面直接按箭头左右也可以）

插件安装

比如说安装用量检查插件或者安装superpowers：/plugin install superpowers@claude-plugins-official

MCP

MCP简单理解为赋予Claude Code工具调用权限，比如说想让Claude Code去收索文书等
比如说安装playwright（直接用自然语言描述你想做的事，而后调用对应的浏览器操作）：claude mcp add playwright npx @playwright/mcp@latest如果要卸载直接claude mcp remove playwright，安装完毕之后

可以看到MCP已经启动了，如果要去使用这个MCP直接 使用 playwright 打开浏览器访问 https://www.big-yellow-j.top/posts/2026/04/20/torch-basic-distribute-1.html 并且检查还有什么需要补充的分布式训练方式，以及内容上还有什么不足 去让Claude Code去调用playwright的MCP。

Skills使用

skills简单理解为一个可以复用的任务prompt（比如说创建PPT）不用每次都去重新写prompt直接通过skills进行复用即可，如果要去找其他的Skills直接可以访问：https://www.skills.sh/或者直接去安装find-skills让其帮你自动去搜索一些skills，

安装前简单了解一下skills有“两个目录”：1、项目目录（那么你的skills就只在这个项目起到效果），比如直接在你的文件夹里面进行打开就会访问项目目录比如说 D:\ClaudeCode\.claude；2、根目录（所有项目都可以用到这个skills），这个就是你的claude code安装目录比如说：C:\Users\hjie\.claude

第一种、安装他人skills¹有如下几种：1、复制文件夹直接将别人skills所有内容复制到skills目录下即可，2、直接下载，以获取微信文章为例直接访问地址然后搜索wechat-article-extractor在得到安装命令npx skills add https://github.com/freestylefly/wechat-article-extractor-skill --skill wechat-article-extractor在你的终端进行安装即可，安装完过程中可能要选择是 project 还是 global 根据提示进行选择即可

需要安装npm，安装方式参考：链接

安装完毕之后skills触发有两种：1、自动进行触发，比如在上述skills中有description字段

当你在claude中输入 提取微信文章：https://mp.weixin.qq.com/s/8axsDd-vY247Nd3oPZ9_zQ 他就会自动触发这个skills进行处理

2、手动触发，可以直接在 claude中输入 ‘/we’ 会在下面触发联想，然后通过箭头选择自己需要内容直接按 tab 补全命令

第二种、自定义skills：直接去看别人skills怎么写的然后进行修改即可，或者直接让claude code写skills

搜索自动化

一般而言在工作中可能需要去调研（比如说搜集论文、收集相关数据集等），推荐直接使用 crawl4ai 去自动搜索爬取内容，可以直接使用他的skills然后放到自己的目录下面，然后再终端中执行claude --permission-mode auto，然后输入自己要求：

最后输出结果（任务比较费时用来12min52s完成）

通过上面一轮对话处理下来token消耗

Agent Team协作

一般而言在使用claude code进行对话时候，都是执行一个任务，在等待结果之后再去执行一个新的任务，比如说法律一个案子需要同时去收集案子以及法条然后再去对材料进行整理，这里就需要用到agent team概念，简单介绍Agent team概念参考里面对于subagents和agent teams之间对比²：

两者之间差异点在于subagents相当于一个老师将任务分配给几位学生然后学生给老师一个反馈，agent teams相当于老师给学生分配任务，学生之间还在不断交流，那么以长沙货拉拉案为例，以一个法律从业者出发（本人非专业人员）去构建一个agent team来解决这个案子，首先本地创建一个文件夹然后执行claude code

mkdir CSHuolala # 创建文件夹
mkdir .claude   # 创建文件夹
echo '{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}' > /home/hjie/ClaudeCode/CShuolala/.claude/settings.json # 相当于写入文件
 claude --permission-mode auto --teammate-mode in-process  # teammate-mode 控制显示模式

# 测试的提示词是
为货拉拉案法庭辩护材料准备材料辩护词
1、任务 A：证据审查与现场环境重构（由 Evidence-Agent 认领）
2、任务 B：刑法因果关系与无罪/罪轻辩护词起草（由 Criminal-Law-Agent 认领）
3、任务 C：被害人过错分析及同行案例检索（由 Case-Search-Agent 认领）
4、任务 D：最后对辩护词进行审查（有Lawer-Agent认领）
执行顺序上首先执行任务A而后并行执行B和C，最后执行D
辩护词合适标准：1、辩护词合乎法律文书书写；2、所有收集材料都在本地文件夹保存；3、法律必需都有自己出处

值得注意的是上面任务都是基于网络进行搜索，实际情况可能需要对自己具体材料（比如说收集的材料）进行处理，可能就需要用到其他skills/mcp工具，在规划任务时候越详细越好（更加好控制模型）

可以看到目前之后一个 Evidence-Agent 在执行工作，可以直接通过键盘↓去进入 @main @Evidence-Agent然后键盘←→箭头进行跳装查看工作如何，或者直接通过npx claude-task-viewer然后进入对应网页查看如下：

那么在Evidence-Agent中执行效果如下：

很明显看到执行 争取审查+任务重构符合我的任务A要求，A执行完毕就会进行BC比如说得到如下：

可以看到另外两个agent也开始执行了，最后所有的整理的材料以及最后的书写得到的辩护词在百度网盘总共是花费了大概4元（DeepSeek-4-pro）

Claude Code工具开发

Skills开发

最简单方法直接看别人怎么写然后进行仿写即可

以crawl4ai提供的skills为例，参考这个例子规范文书写作skills（大部分内容基于AI出发，不一定符合实际法律工作内容），首先介绍如何去定义自己的skills而后去介绍在claude code中如何去定义自己的skills，比如说在crawl4ai文件中主要是如下几个文件³（不同skills可能差异，比如crawl4ai可能还有references）：

my-skill/
├── SKILL.md           # 主要说明（必需）
├── template.md        # Claude 要填写的模板
├── reference.md       # 详细介绍API使用文档，比如说在scripts里面会提前告诉我的模型运行scripts需要哪些参数
├── examples/
│   └── sample.md      # 显示预期格式的示例输出
└── scripts/
    └── validate.sh    # Claude 可以执行的脚本

首先核心内容就集中在 SKILL.md文件中，简单介绍一下他的 模板描写方式：

---
name: api-conventions
description: API design patterns for this codebase
---

When writing API endpoints:
- Use RESTful naming conventions
- Return consistent error formats
- Include request validation

首先对于上述模板中 --- 之间内容表示提前告诉我的模型这个 skills的一些基本配置，他一般有如下字段：

其实对于上述字段中最核心的就是：1、description：告诉模型这个skills都是干什么的；2、name：告诉模型你的skills叫什么（如果没有他就会用上层的文件夹名称），除此之外其他的也可以去注意一下使用（具体描述看上面的表格里面描述）：disable-model-invocation，在定义完skills中yaml之后就是关于第二部分，prompt书写（这部分其实就是相当于你将你一贯的prompt直接机械的告诉大模型，让他按照你这个内容去机械的进行操作），回到最上面去实现一个规范文书写作skills（很粗糙具体内容可能需要具体修改），首先明确我的skills都需要哪些内容：1、定义名称（legaldocnorm）；2、定义一些小的脚本工具，比如说对于文档（假设为docx文件）需要让模型去打开文件就需要一些脚本；3、其他。按照上述内容开始一个skills创作（全部基于wsl上，有些命令都是linux命令可以自然的转化到win上，比如创建文件夹）。
第一步、去构建一个所有文件“系统”以及大致SKILL.md文件（头部信息推荐英文，后续内容中英都行）最后所有文件见Github链接
第二步、去构建我的脚本 script（不会写直接让AI帮你写即可），最后的script见Github链接
第三步、去构建一个reference，因为法律文书在书写上比较规划，模型可能不知道具体如何书写可以简单给一个参考让模型规范输出（规范文本可以直接用最高法院提供模板），这里只提供两种规范文本供参考：1、广州市海珠区人民法院——民事答辩状；2、广州市海珠区人民法院——民事起诉状)，最后所有的reference见Github链接
skills底层原理：还是一个function calling，所谓 function calling比如说：“北京今天天气如何？”输入模型模型（大模型本身只能输出文本不能去搜索网页等功能）通过分析用户文本输出结构化信息：{"name": "get_weather", "arguments": {"date":xxx, ....}} 而后通过结构化信息进行工具调用（比如说调用搜索天气相关的API进行天气检索）。因此虽然claude code中skills都是文本prompt，大模型在检索到要使用的skills之后通过分析skills中内容自动解析处需要进行操作，因此claude code中skills底层就是：Prompt+Tool Description+ Few-shot examples+ Execution

MCP 开发

Claude Code抓包

简单网络抓包

为了分析Claude Code中每一步系统层都在发生什么就需要最Claude Code进行抓包，具体过程如下，首先对环境进行配置（基于wsl）：

# 基于wsl
conda create -n mitm python=3.11
conda activate mitm
pip install mitmproxy
mitmweb --listen-host 0.0.0.0 --listen-port 9870 # 8080 为代理端口 cc走这里 8081 web ui看流量

# 新建窗口
export http_proxy=http://0.0.0.0:9870
export https_proxy=http://0.0.0.0:9870
export HTTP_PROXY=http://0.0.0.0:9870
export HTTPS_PROXY=http://0.0.0.0:9870
export ALL_PROXY=http://0.0.0.0:9870
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem
export SSL_CERT_FILE=~/.mitmproxy/mitmproxy-ca-cert.pem
claude --permission-mode auto

在启动完毕之后，可以看到终端

而后直接去Claude code随便测试：1、你好；2、/crawl4ai 搜索一下Yolo系列论文，直接去终端里面提供的url地址然后可以直接~c 200（因为访问 https://api.anthropic.com/api/event_logging/v2/batch 可能会有很多失败会显示400，因此重点看一下链接成功的），比如说通过解析：

在输入第一段对话 你好 模型会输入很多内容如tools/skills描述等，但是这些内容绝大部分会“命中缓存”（观察deepseek中就有这种内容）⁴

所谓命中缓存意思就是说：这部分内容不用模型去重新计算可以直接复用，这是因为大模型生成过程是prefill+decode，prefill阶段就是对我的prompt进行编码，比如说上面输入模型是一个结构化文档，在vllm的cache逻辑中会将输入token进行block处理（比如每个block存储n个token）当出现block相同时候就会复用结果（必须保证如：输入1：QWERASDF和输入2：QWERASDF此时可以命中缓存，但是如果输入1改成WQERASDF就不行，因此为了更加大的命中缓存会直接将容易命中缓存输入放到模型输入前面如tools、system等），而decode就是对prefill后内容开始解码一个token一个token进行输出，即使如此还是建议如果skills不用就不要开启

而后可以看模型输出部分think+输出：

而后在第二部分对话中 /crawl4ai 搜索一下Yolo系列论文 首先可以看模型终端输出：

模型进行如下4次对话处理：
1、任务重写：从模糊到精确（第 1-3 轮）
第 1 轮：输入“搜索 Yolo 论文”，模型携带了 crawl4ai 的技能定义。
关键转折（你发现的 1 & 2 点）：crawl4ai生成了两个极其精确的搜索关键词：YOLO series papers object detection survey 2024 2025（针对综述）；YOLOv1 to YOLOv12 paper list arxiv（针对列表）
第 2-3 轮： 框架将这两个“进阶关键词”重新喂回给模型。这时，模型不再是处理你那个模糊的原始需求，而是拿到了已经被优化过的检索指令。目的： 这就是 Query Expansion（查询扩展）。Agent 知道直接搜“Yolo 论文”结果太乱，所以先把它拆解成“搜综述”和“搜最新版本列表”两个子任务。
2、执行与回传（第 4 轮）
动作： 携带了这两个精确关键词的对话被送入 web_search 工具。
结果： 搜索引擎返回了你看到的那一串包含 YOLOv1 到 YOLOv26 的 Arxiv 链接和详细摘要。
总结： 最终 DeepSeek 拿到这些被精准定位后的素材，进行最后的整合输出。

值得注意的是,web_search返回内容还是通过模型/工具进行总结的，比如说一个搜索得到5-6结果模型进行总结即可

抓包分析功能

通过上面抓包方式可以进一步去分析claude code中其中功能比如说 /compact，/resume 等，抓包分析resume：终端执行 /resume 之后而后直接输入新的内容在claude code直接加载历史对话而后补充到上下文中比如所大致结构如下：

{
    "model": "deepseek-v4-pro",
    "messages": [
      {
        "role": "user",
        "content": [
          {
            历史用户输入对话信息
          },
          {
            新的对话信息
          }
        ],
        .....
      }

在新的对话信息里面也会直接加载启用的skills等以及后续模型的tools也会加载（和第一次对话加载信息相同只是多了一组用户历史信息），但是这里简单介绍一些claude code中是如何去缓存对话信息的在路径 ~/.claude 中文件结构如下，对于每一组对话都会存储在 history.jsonl 中每组对话结构为 {"display":"你是什么模型","pastedContents":{},"timestamp":1780404540849,"project":"/home/huangjie/MdiriCode/Claude","sessionId":"5186f729-1c6e-4698-99e6-7ad2cd667cde"} 最后的sessionid对应每次对话的id信息，都会在 sessions文件夹（主要是记录上下文对话信息）中记录⁵

除此之外在projects文件夹中还会记录更加多内容，其大致结构如下：

projects/
 ├── sessionid.jsonl   # 区别于上面 session 里面只记录对话信息，此sessionid.jsonl则是记录所有 “日志记录”，比如说  {"type":"permission-mode","permissionMode":"auto","sessionId":"b69647ef-a95b-428d-a0ac-530440c7853f"}
 ├── memory/
 ├── subagents/
 ├──── xxxx.meta.jsonl # 主要记录 subagets 具体信息比如说：{"agentType":"claude-code-guide","description":"Explain Claude Code compaction","toolUseId":"call_00_0UXP3yM5PsH4VZ2ZbA1c5929"}
 ├──── xxxx.jsonl      # 子agents产生对话信息

主要介绍一些subagents，在claude code中一般是 主agent收到信息去分发给不同子agent，而后将子agent信息接收进行总结分析等（具体构建等见下面分析）。简单总结一些子agents：1、子代理只是向Anthropic发出的独立请求，每个请求都有自己的系统消息。 2、每个子代理都有自己的上下文窗口。它不会与其他子代理或主代理共享内存或聊天记录。 3、“主”Claude（委托代理）为子代理编写提示词，该提示词最终将成为子代理收到的第一条用户消息。 子代理完成任务后，会将其发现的摘要发送回主Claude，随后主Claude会尝试整合所有报告并对其进行解读。 在不断积累上下文之后就需要考虑对内容进行压缩，在claude中压缩过程有两种：1、直接 /compact；2、输入对应文本 /compact xxxx对于两种压缩方式通过抓包分析发现使用的提示词都是大致相同的（更加具体的压缩过程见后续分析）具体的压缩提示词如下：

CRITICAL: Respond with TEXT ONLY. Do NOT call any tools.

- Do NOT use Read, Bash, Grep, Glob, Edit, Write, or ANY other tool.
- You already have all the context you need in the conversation above.
- Tool calls will be REJECTED and will waste your only turn — you will fail the task.
- Your entire response must be plain text: an <analysis> block followed by a <summary> block.

Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions.
This summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context.

Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process:

1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify:
   - The user's explicit requests and intents
   - Your approach to addressing the user's requests
   - Key decisions, technical concepts and code patterns
   - Specific details like:
     - file names
     - full code snippets
     - function signatures
     - file edits
   - Errors that you ran into and how you fixed them
   - Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.
   - Note any security-relevant instructions or constraints the user stated (e.g., sensitive files or data to avoid, operations that must not be performed, credential or secret handling rules). These MUST be preserved verbatim in the summary so they continue to apply after compaction.
2. Double-check for technical accuracy and completeness, addressing each required element thoroughly.

Your summary should include the following sections:

1. Primary Request and Intent: Capture all of the user's explicit requests and intents in detail
2. Key Technical Concepts: List all important technical concepts, technologies, and frameworks discussed.
3. Files and Code Sections: Enumerate specific files and code sections examined, modified, or created. Pay special attention to the most recent messages and include full code snippets where applicable and include a summary of why this file read or edit is important.
4. Errors and fixes: List all errors that you ran into, and how you fixed them. Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.
5. Problem Solving: Document problems solved and any ongoing troubleshooting efforts.
6. All user messages: List ALL user messages that are not tool results. These are critical for understanding the users' feedback and changing intent. Preserve any security-relevant instructions or constraints verbatim so they remain in effect after compaction.
7. Pending Tasks: Outline any pending tasks that you have explicitly been asked to work on.
8. Current Work: Describe in detail precisely what was being worked on immediately before this summary request, paying special attention to the most recent messages from both user and assistant. Include file names and code snippets where applicable.
9. Optional Next Step: List the next step that you will take that is related to the most recent work you were doing. IMPORTANT: ensure that this step is DIRECTLY in line with the user's most recent explicit requests, and the task you were working on immediately before this summary request. If your last task was concluded, then only list next steps if they are explicitly in line with the users request. Do not start on tangential requests or really old requests that were already completed without confirming with the user first.
If there is a next step, include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there's no drift in task interpretation.

Here's an example of how your output should be structured:

<example>
<analysis>
[Your thought process, ensuring all points are covered thoroughly and accurately]
</analysis>

<summary>1. Primary Request and Intent:
   [Detailed description]

2. Key Technical Concepts:
   - [Concept 1]
   - [Concept 2]
   - [...]

3. Files and Code Sections:
   - [File Name 1]
      - [Summary of why this file is important]
      - [Summary of the changes made to this file, if any]
      - [Important Code Snippet]
   - [File Name 2]
      - [Important Code Snippet]
   - [...]

4. Errors and fixes:
    - [Detailed description of error 1]:
      - [How you fixed the error]
      - [User feedback on the error if any]
    - [...]

5. Problem Solving:
   [Description of solved problems and ongoing troubleshooting]

6. All user messages: 
    - [Detailed non tool use user message]
    - [...]

7. Pending Tasks:
   - [Task 1]
   - [Task 2]
   - [...]

8. Current Work:
   [Precise description of current work]

9. Optional Next Step:
   [Optional Next step to take]

</summary>
</example>

Please provide your summary based on the conversation so far, following this structure and ensuring precision and thoroughness in your response. 

There may be additional summarization instructions provided in the included context. If so, remember to follow these instructions when creating the above summary. Examples of instructions include:
<example>
## Compact Instructions
When summarizing the conversation focus on typescript code changes and also remember the mistakes you made and how you fixed them.
</example>

<example>
# Summary instructions
When you are using compact - please focus on test output and code changes. Include file reads verbatim.
</example>


REMINDER: Do NOT call any tools. Respond with plain text only — an <analysis> block followed by a <summary> block. Tool calls will be rejected and you will fail the task.

Agent架构问题

上面无论式skills涉及还是tools使用其实都会带来很多Agent底层设计问题比如说：1、上下文工程（Context Engine） 随着用户不断对话那么对话历史就会不断变长，如果将对话历史全部塞到对话窗口里面就会导致上下文过长问题（导致模型可能丢失/处理不好）；2、tools如果没有命中怎么办？ 等等诸如此类问题，因此下面对Agent设计过程中会遇到问题以及架构设计上内容进行介绍

Cache机制

最上面简单介绍一下缓存机制，通过相同cache缓存命中去选择复用，不过值得注意的是虽然在对话过程中（进行抓包分析）每次用户输入都是在最上面，但是模型会将这些信息进行编排 tools + system+ messages这种方式，保存缓存命中。 在不同模型中缓存命中方式存在些许差异，比如说：1、DeepSeek缓存命中机制：；2、Claude缓存命中机制
https://grok.com/c/b083cb5c-cf7a-40dd-8890-6998438f3d2a?rid=7f9573b4-b0ac-44f8-baa5-015f9f9caf5e
https://zhuanlan.zhihu.com/p/17239625983

Context Engine

所谓上下文工程指的是，随着用户之间对话那么窗口token就肯定会超出模型限制（比如DeepSeek的1M），那么就需要对历史对话进行处理如压缩等（不过值得注意的是假设模型上下文窗口是1M在claude code中不会将所有上下文都用完才会去压缩，会设定阈值进行压缩，比如说达到80%自动进行压缩），以如下代码为例：

from openai import OpenAI
client = OpenAI(api_key="xxx",base_url="https://api.deepseek.com")
messages = [
    {
        "role": "system",
        "content": "你是一个专业AI助手"
    }
]

while True:
    user_input = input("User: ")
    if user_input.lower() == "exit":
        break

    messages.append({
        "role": "user",
        "content": user_input
    })
    response = client.chat.completions.create(
        model="deepseek-chat",
        messages=messages,
        temperature=0.7
    )
    assistant_reply = response.choices[0].message.content
    messages.append({
        "role": "assistant",
        "content": assistant_reply
    })
    print("User:", user_input)
    print("\nAssistant:", assistant_reply)

模拟进行对话最后得到输出文本:

[{'content': '你是一个专业AI助手', 'role': 'system'},
 {'content': '我是小红来自美国，我现在问你一些问题请不多于100个字进行输出，请简单介绍一下北京和上海', 'role': 'user'},
 {'content': '北京是中国的首都，历史悠久，拥有故宫、长城等著名景点；上海是国际大都市，以现代金融和繁华商业闻名，外滩、东方明珠是标志性地标。',
  'role': 'assistant'},
 {'content': '北京和上海两个城市哪一个更加推荐我去？', 'role': 'user'},
 {'content': '这取决于你的旅行偏好。如果你喜欢历史文化，推荐北京，可以探索故宫、长城和胡同。如果你偏爱现代都市与商业氛围，上海更合适，有外滩、陆家嘴和时尚购物区。',
  'role': 'assistant'},
 {'content': '我想去看无人机表演推荐去哪个城市？深圳怎么样？', 'role': 'user'},
 {'content': '深圳是中国无人机表演最出色的城市之一，常有大疆等企业举办大型灯光秀。若想看科技感强的表演，深圳是首选。北京和上海也有相关活动，但深圳更具创新氛围。',
  'role': 'assistant'},
 {'content': '我是谁来自哪里？', 'role': 'user'},
 {'content': '你叫小红，来自美国。', 'role': 'assistant'}]

下面简单介绍几种常见的上下文压缩方式⁶:
1、Claude Code上下文压缩方案：比如说在上面抓包分析Claude Code的压缩过程就可以看到他所使用的压缩提示词，但是实际过程中不可能全部只通过压缩提示词进行上下文压缩，参考对Claude Code的逆向分析⁷简单总结其压缩方案：优先使用廉价规则清理，再到轻量摘要，最后才进行昂贵的 LLM 总结。廉价处理过程（对话持续进行持续压缩避免占用上下文）：将部分特定工具（比如说文件读取，那么就会获取很长的上下文）输出进行压缩，直接简化将文件内容缓存本地，并且只生成简单预览以及本地路径（通过预览如果需要复用直接通过路径再去获取文件信息）。 模型压缩过程（手动/自动执行压缩命令执行）：直接通过提示词去对所有的对话历史进行压缩（具体提示词见上面抓包得到的）。最后输出<analysis> + <summary> 两层⁸，其中<analysis>：允许模型在内部把对话按时间线梳理一遍，减少遗漏，<summary>：对外提供结构化的最终压缩结果，便于机器再加工（比如客户端替换历史、写入本地存档）。压缩完毕之后就会涉及到信息复用，claude code中直接把总结内容复用到上下文中即可比如说：

参考

分布式训练实现

各类分布式训练方式实现。

常见的分布式训练

1、数据并行（DP）

DP流程
缺点也是显而易见：

• 1、数据副本会冗余（因为要把数据先复制，然后进行分布）；
• 2、前向传递前在 GPU 上复制模型（由于模型参数是在主 GPU 上更新的，因此必须在每次前向传递开始时重新同步模型）；
• 3、GPU 利用率不均衡（损失计算在主 GPU 上进行，在主 GPU 上进行梯度降低和参数更新

DDP流程

对比 DP和 DDP¹
1、DP是一种 集中-分发机制（优化器/梯度计算都是再 master进程上处理好之后，然后分发到不同的进程中）
2、DDP是一种 独立-运行机制（每个进程都有自己的优化器，并且在计算梯度过程中：各进程需要将梯度进行汇总规约到主进程，主进程用梯度来更新模型权重，然后其 broadcast 模型到所有进程（其他GPU）进行下一步训练）

整体流程：
1、加载模型阶段。每个GPU都拥有模型的一个副本，所以不需要拷贝模型。rank为0的进程会将网络初始化参数broadcast到其它每个进程中，确保每个进程中的模型都拥有一样的初始化值。
2、加载数据阶段。DDP 不需要广播数据，而是使用多进程并行加载数据。在 host 之上，每个 worker进程都会把自己负责的数据从硬盘加载到 ` page-locked memory。DistributedSampler 保证每个进程加载到的数据是彼此不重叠的。 **3、前向传播阶段**。在每个GPU之上运行前向传播，计算输出。每个GPU都执行同样的训练，所以不需要有主 GPU。 **4、计算损失**。在每个GPU之上计算损失。 **5、反向传播阶段**。运行后向传播来计算梯度，在计算梯度同时也对梯度执行 all-reduce`操作。

由于数据实在不同设备上，但是是一个模型，对于梯度的计算可以：直接将不同设备之间梯度相互传播（每个设备的数据是不一样的，但是模型是相同的，这样计算梯度会不同），然后计算平均（alll-reduce计算方法）

6、更新模型参数阶段。因为每个GPU都从完全相同的模型开始训练，并且梯度被 all-reduced，因此每个GPU在反向传播结束时最终得到平均梯度的相同副本，所有GPU上的权重更新都相同，也就不需要模型同步了。注意，在每次迭代中，模型中的 Buffers 需要从rank为0的进程广播到进程组的其它进程上

2、张量并行（TP）

张量并行目的是模型参数矩阵太大，需要将他们拆分到不同设备。张量切分方式分为按行进行切分和按列进行切分，分别对应行并行（Row Parallelism）(权重矩阵按行分割)与列并行（Column Parallelism）(权重矩阵按列分割)。假设计算过程为：$y=Ax$ 其中 $A$ 为权重

列并行操作：对我的权重矩阵按列进行切分而后分配到不同设备上
观察上面图像上半部分，forward部分容易理解，对于backward部分理解：第一部分计算（反向传播-1）：得到两个新的Y1和Y2然后将他们进行拼接，计算梯度可以直接 $\frac{\partial L}{\partial Y_1} \frac{\partial L}{\partial Y_2}$ 得到梯度，第二部分计算（反向传播-2）：由于x是完整的因此可以直接：
$\frac{\partial L}{\partial X}=\frac{\partial L}{\partial X}|{A_1}+\frac{\partial L}{\partial X}|{A_2}$

行并行操作：将输入x以及权重矩阵都按行进行切分分配到不同设备上
观察上面图像上半部分，forward分别对输入x以及参数A进行才分然后计算，对于backward理解：第一部分（反向传播-2）：因为得到的Y是由两部分Y1和Y2直接相加得到结果，因此：$\frac{\partial L}{\partial Y_1}= \frac{\partial L}{\partial Y}$，第二部分（反向传播-1）：$\frac{\partial L}{\partial X}=[\frac{\partial L}{\partial X_1}+\frac{\partial L}{\partial X_2}]$

对于 列并行操作由于x是完整的只需要通过 all-reduce操作（将不同设别的梯度信息“汇总”起来）。行并行操作：由于x都被拆分了，因此需要通过 all-gather（将不同GPU梯度聚合而后广播）

all-reduce、all-gather等见：All-Gather, All-Reduce, reduce-scatter什么意思？

3、流水线并行（PP）

当模型变得过大以至于单个设备无法容纳其任何一层，或者需要以不同方式重叠计算和通信时，流水线并行提供了一种替代的扩展策略。不同于复制整个模型或拆分单个层的方法，流水线并行将模型本身按顺序分配到多个设备上。每个设备或设备组都成为流水线中的一个“阶段”，负责运行模型层的一个子集。其内部并行的机制，如一个在四个GPU上运行的四层模型：
GPU 0 (阶段 0): 运行第 1 层。
GPU 1 (阶段 1): 运行第 2 层。
GPU 2 (阶段 2): 运行第 3 层。
GPU 3 (阶段 3): 运行第 4 层并计算损失。
输入数据进入第一阶段（GPU 0）。处理后，输出激活被发送到第二阶段（GPU 1）。这会一直持续，直到最后阶段计算出输出和损失。随后，梯度以相反的顺序反向流经流水线。GPU 3 计算第 4 层的梯度，并将第 3 层输出的梯度发回给 GPU 2，然后 GPU 2 计算第 3 层的梯度并将其发回给 GPU 1，依此类推，直到梯度到达第一阶段。在这个过程中会存在 “流水线气泡问题”：当阶段 1 处理第一个数据批次时，阶段 0 处于空闲状态，等待下一个批次。类似地，当阶段 2 处理时，阶段 0 和 1 处于空闲状态（假设只有一个批次流过）（backwards同理），常见两种处理方式：

3.1 GPipe实现流水线并行

https://torchgpipe.readthedocs.io

GPipe²³ 将一个小批量（mini-batch）分割成多个微批量（micro-batch），使设备尽可能并行工作。其核心原理就是当每个分区处理完一个微型批次后，可以将输出扔给下一个分区，并立即开始处理下一个微型批次。

上图中b、c分别表示为 模型并行和 流水线并行都会有一个“拆分”的处理（模型并行和流水线并行都会对模型进行拆分，但模型并行主要关注模型的计算任务如何分布到不同设备，而流水线并行还结合了微批次化的数据处理，用于提升并行效率。），对比b-c很容易发现使用模型并行会有一个问题：设备闲置问题，只用第一层处理完之后才会进入到下一层，因此 流水线并行做的就是：在模型并行的基础上，进一步引入数据并行的办法，即把原先的数据再划分成若干个batch，送入GPU进行训练。

对比数据并行⁴
micro-batch 跟数据并行有高度的相似性：
1、数据并行是空间上的，数据被拆分成多个 tensor，同时喂给多个设备并行计算，然后将梯度累加在一起更新。
2、micro-batch 是时间上的数据并行，数据被拆分成多个 tensor，这些 tensor 按照时序依次进入同一个设备串行计算，然后将梯度累加在一起更新。

那么就会有存在一个问题：因为数据/模型被拆分，那么如何去处理梯度？对于上述两种方式，我们假设数据数量：10，然后设备个数：5，同时假设我们也将模型分布到这5个设备上，那么在 forawrd 阶段处理过程为：
数据并行：每个设备会处理2个数据（10/5）

流水线并行：因为模型分布在不同设备上（假设：$ld_1, ld_2, ld_3, ld_4, ld_5$），会有一个操作：将数据在拆分为不同 micro-batch（这里假设为5，得到：$md_1,md_2,md_3,md_4,md_5 $），这样一来随着前向传播：$t_0$ 时：$ld_1$ 处理 $md_1$；$t_1$ 时：$(ld_1, md_2), (ld_2, md_1)$（ 值得注意的是 此处的md_1是由 ld_1处理完md_1得到结果，更加准确描述是：$(ld_2, ld_1(md_1))$）。

同理在 backward 阶段处理过程（对于 数据并行直接依次计算梯度即可 ）为：在 forward 结束之后此时 流水线并行 中对于设备 ld_5 在 $t_9$: $ld_5$ 接收 Loss 传回的 $md_5$ 的梯度。它利用之前存的 $md_5$ 前向输入，重算一遍，算出 $W$ 的梯度。$t_{10}$: $ld_5$ 接收 Loss 传回的 $md_4$ 的梯度，重复上述动作。

如下图Gpipe中的forward 以及 backward 过程：

数据被切分成小的micro-batch，forward过程中一次将数据进行输入处理，在backward过程中则是依次将计算得到的梯度返回给上一层设备

不过值得注意的是，在Gpipe中存在 激活缓存机制：如果将每一个 micro-batch 计算结果都进行缓存会导致显存随 micro-batch 进行线性增长，因此在 forward 阶段丢弃中间保留边界，显存中只会保留 $md_i$ 的输入，在 backward阶段：即时计算，因为需要计算梯度那么直接将初始输入拿出来在计算 forward过程（也就是所谓的 gradient-checkpoint）。 以及 梯度累计机制：因为梯度更新必须是完整的一个batc处理之后才会进行（而我的数据都被拆分成小的micro-batch），因此在数据 $md_5 \rightarrow md_1$ 的过程中，激活缓存机制会不断的将梯度进行累积直到所有的数据处理完毕再进行参数更新。

gradient-checkpoint 过程：
比如说：$x \xrightarrow{x_1} a_1 \xrightarrow{x_2} a_2 \xrightarrow{x_3} a_3 \xrightarrow{x_4} a_4$ 那么计算loss： $loss=(a_4- y)^2$

朴素方法：$\frac{dloss}{dw_1}=\frac{dloss}{da_4} \times \frac{da_4}{da_3} \times \frac{da_3}{da_2} \times \frac{da_2}{da_1} \times \frac{da_1}{dw_1}$。前向过程需要计算并存储 $a_1, a_2, a_3, a_4$，反向时再调用这些激活值计算梯度。

梯度检查点：只存少量检查点，反向时若需要某个激活值但没有存储，则从最近的检查点重新计算前向。例如只保存 $a_1$ 和 $a_4$：

前向：正常计算 $a_1 \to a_2 \to a_3 \to a_4$，但只保存 $a_1$ 和 $a_4$，丢弃 $a_2, a_3$。

反向：
1、从 $a_4$ 开始反向，需要 $a_3$：从最近的检查点 $a_1$ 重新计算 $a_1 \to a_2 \to a_3$，得到 $a_3$ 后计算 $\frac{dloss}{dw_4}$ 和 $\frac{dloss}{da_3}$，然后丢弃 $a_2, a_3$。

2、继续反向，需要 $a_2$：再次从 $a_1$ 重新计算 $a_1 \to a_2$，得到 $a_2$ 后计算 $\frac{dloss}{dw_3}$ 和 $\frac{dloss}{da_2}$，丢弃 $a_2$。

3、反向到 $a_1$：$a_1$ 已保存，直接使用计算 $\frac{dloss}{dw_2}$。

4、最后计算 $\frac{dloss}{dw_1}$ 使用输入 $x$。

效果：内存从存储 4 个激活值减少到 2 个，代价是增加了额外的重计算（本例中 $a_1 \to a_2 \to a_3$ 被计算了多次）。

梯度检查点（gradient checkpointing） 的工作原理是从计算图中省略一些激活值（由前向传播产生，其中这里的”一些“是指可以只省略模型中的部分激活值，折中时间和空间，陈天奇在它的论文使用了如下动图的方法，即前向传播的时候存一个节点释放一个节点，空的那个等需要用的时候再backword的时候重新计算）。这减少了计算图使用的内存，降低了总体内存压力（并允许在处理过程中使用更大的批次大小）。

简单使用:

from torchgpipe import GPipe

model = nn.Sequential(a, b, c, d)
model = GPipe(model, balance=[2, 2], chunks=8)

# 1st partition: nn.Sequential(a, b) on cuda:0
# 2nd partition: nn.Sequential(c, d) on cuda:1

for input in data_loader:
    output = model(input)

对于 Gpipe 后续一个简单优化：因为梯度必须等所有 forward 处理完才会进行 backward 处理效率太低除此之外因为需要缓存 m 份 activation导致内存增加。原因是每个microbatch前向计算的中间结果activation都要被其后向计算所使用，所以需要在内存中缓存。，可以让模型交替执行 forward 和 backward（也就是 1F1B策略）

3.2 PipeDream 实现流水线并行

在论文⁵中提出在权重更新过程中存在问题：
1、同一个minibatch的前向传播和后向传播使用的参数不一致：比如在 Machine1上输入数据5时，用的是数据1的更新后参数，依次类推到数据5梯度更新时用的是1、2、3、4这4组数据梯度，这就导致 minibatch 5 的前向计算和后向计算时候，使用的参数不一致。即，第一行 Machine 1，蓝色 5 号 和 绿色 5 号 计算时候，必须都使用 绿色 1 号之后更新的参数。
2、同一个数据在不同Machine上做同样操作（同样做前向操作，或者同样做后向传播）使用的参数版本不一致。如对于 数据 5 在 machine 1 上的前向计算部分（蓝色5），他的前向逻辑在 数据1 的后向计算以后执行。但是 数据 5 在 machine 2 上的前向计算部分（蓝色5），是在 “数据 1, 数据 2” 的后向计算结束后才执行。这就导致了 数据 5 在两个stage上前向计算使用的参数版本不一致。

对于上述问题，其提出Weight stashing、Vertical Sync策略解决这个问题。Weight stashing过程如下：

PipeDream核心在于：同一个 micro-batch 的 forward 和 backward 使用同一份权重

以 数据5 为例：在forward中对于 Worker1 使用的是 数据1 更新后的权重，那么在 backward 中就需要去对 数据1 更新后权重进行 backward，因此在Worker1中为了保证上述原理，就需要去缓存1-4的数据的权重（因为数据5 backward 之前还进行其他3组数据）也就是 $W_1^{(1)},…,W_1^{(4)}$，那么类似的对于Worker2就需要去缓存2-4的数据的权重依次类推。数据5 的 backward 必须使用它 forward 时对应的权重版本也就是将 $W_1^{(1)}$ 拿出来（如 数据5 在worker1 forward中计算是：$o = W_1\times \text{Data}_5$ 那么 backward 时需要将 $W_1^{(1)}$ 拿出来）

Vertical Sync过程如下⁶：

每个进入管道的 数据 都与其进入流水线输入阶段时候的最新权重版本相联系。当小批次在流水线前向传播阶段前进时候，这个版本信息随着激活值和梯度一起流动。比如说上图中，强制所有worker在计算 minibatch 5 的时候都用本worker做 minibatch 1 反向传播之后的参数，具体来说就是：对于 worker 2，使用本阶段绿色1（1反向传播之后，更新的本阶段权重）来做 5 的前向传播。但是，这样同步会导致很多计算浪费无用。比如5更新时用的1的权重，但2/3/4后向传播的权重都白白计算了，所以默认不使用Vertical Sync。这样虽然每层不完全一致，但是由于weight stashing的存在，所有的参数都是有效的。

4、专家并行

状态切分优化显存

以上述DDP训练过程为例，为了更大限度的榨干设备显存（让其可以接受更加大的数据输入，而在模型训练过程中以Adam优化器为例在显存占用上：模型参数、优化器状态、梯度这三个是显存占用大头，那么为了优化就需要对其进行切分，每台设备只保存部分信息），就可以考虑使用 DeepSpeed 以及 toch原生的 FSDP2方式去对模型/梯度/优化器状态的分布式分片，除此之外对于更加大的模型可能就会考虑直接使用 混合并行（多种分布式训练叠加）

DeepSpeed

简单回顾一下DeepSpeed中基本原理，在 DeepSpeed中指出模型训练过程中显存占用上主要分为如下3块（假设模型的参数为 $\Phi$，使用混合精度训练，对于参数以及梯度会用fp16而对于adam优化器则是fp32）：1、模型参数（ $2\Phi$）；2、梯度（ $2\Phi$）；3、优化器状态（ $4+4+4\Phi$）

其中有3中不同的切分处理方式（上图从左到右）， Zero-1直接去对优化器进行切分每个设备只保留部分；Zero-2：额外去对梯度进行切分；Zero-3：额外去对模型参数进行切分。除此之外还会涉及到不同设备之间的同步方式：All-reduce（聚合所有结果，然后计算平均比如DDP中就是使用All-reduce）、reduce-scatter、All-Gather（收集每张卡状态然后广播所有设备）。简单使用DeepSpeed进行分布式训练：

import deepspeed
...
deepspeed_config = {
    "train_batch_size": 128,
    "optimizer": {
        "type": "Adam",
        "params": {"lr": 1e-3}
    },
    "fp16": {
        "enabled": True
    },
    "zero_optimization": {
        "stage": 2               
    },
    "gradient_accumulation_steps": 1,
    "steps_per_print": 50
}

model = ...
model, optimizer, _, _ = deepspeed.initialize(
    model=model,
    config=deepspeed_config,
    model_parameters=filter(lambda p: p.requires_grad, model.parameters())
)

for epoch in range(5):
    model.train()
    for batch_idx, (data, target) in enumerate(train_loader):
        data, target = data.to(model.device), target.to(model.device)
        outputs = model(data)
        loss = ...
        model.backward(loss)
        model.step()

使用deepspeed十分简单，只需要提前配置好deepspeed的参数，而后将其通过deepspeed初始化处理（模型、优化器等），而后后续训练就和普通训练过程差异不大，model.backward(loss) 和 model.step() 已经自动管理了梯度清零，所以传统训练里必须用的 optimizer.zero_grad() 不需要显式调用。

FSDP

其在基本思想上和DeepSpeed相似都是选择去对3部分进行切分，可以简单理解为：PyTorch 原生的 ZeRO-3 实现，通过在前反向计算时临时 All-Gather 完整参数、计算后立即释放的方式，将参数、梯度、优化器状态均匀分片到所有 GPU 上，使显存占用从 O(N) 降至 O(1/N)。 简单使用FSDP进行分布式训练：

from torch.distributed.fsdp import (
    FullyShardedDataParallel as FSDP,
    ShardingStrategy,
    StateDictType,
)
from torch.distributed.fsdp.wrap import size_based_auto_wrap_policy
from torch.distributed.algorithms._checkpoint.checkpoint_wrapper import (
    apply_activation_checkpointing,
)
import torch.distributed as dist

dist.init_process_group(backend="nccl")
local_rank = int(os.environ["LOCAL_RANK"])
torch.cuda.set_device(local_rank)

model = ...

auto_wrap_policy = size_based_auto_wrap_policy   # 基于参数数量的自动包装
model = FSDP(
    model,
    sharding_strategy=ShardingStrategy.FULL_SHARD,  # ZeRO-3 行为
    auto_wrap_policy=auto_wrap_policy,
    use_orig_params=True,            # 允许直接使用原始参数名
)
for epoch in range(5):
    sampler.set_epoch(epoch)
    model.train()
    for batch_idx, (data, target) in enumerate(train_loader):
        data, target = data.cuda(), target.cuda()
        optimizer.zero_grad()
        with torch.cuda.amp.autocast():
            outputs = model(data)
            loss = criterion(outputs, target)
        loss.backward()
        optimizer.step()

参考

在深度学习框架中，计算图（英文简称Graph）是一个有向无环图（DAG），它的节点代表操作（例如加法、乘法或者更复杂的函数），边则代表数据（例如张量或者标量）。计算图为深度学习中的前向传播（forward propagation）和反向传播（backward propagation）提供了一个可视化的框架，它能清楚地展示数据是如何流动和操作的。比如说以下面例子为例解释

简单例子

PyTorch 在 forward 时构建一张由 Node 组成的反向执行图，每个 Node 记录局部梯度计算规则和必要上下文，在 backward 时由 Engine 按拓扑顺序逐节点执行并完成梯度传播与累加。

参考上图中给出的例子¹，PyTorch 的计算图在底层负责记录张量之间的运算与依赖关系。要点：节点（Node） 为张量或运算；边（Edge）表示数据流，指明某张量由哪个运算生成或某运算的输入来自哪个张量；叶子节点为用户创建且需梯度的张量（requires_grad=True）。PyTorch 是动态图框架：每次 forward 即时构建计算图，执行后默认释放（除非 retain_graph=True）。调用 .backward() 时，框架沿计算图从输出向输入反向传播，逐节点累加梯度并回传到叶子张量（例如 $z=w=y_1\times y_2= \log(a) \times \sin(x_2)=\log(x_1\times x_2)\times \sin(x_2)$ 的梯度由对应运算节点按链式法则逐步计算）：

import torch
# 叶子节点
X1 = torch.tensor(2.0, requires_grad=True)
X2 = torch.tensor(3.0, requires_grad=True)

a = X1 * X2                  # a = X1 * X2
y1 = torch.log(a)            # y1 = log(a)
y2 = torch.sin(X2)           # y2 = sin(X2)
w = y1 * y2                  # w = y1 * y2
z = w                        # z = w

a.retain_grad()
y1.retain_grad()
y2.retain_grad()
w.retain_grad()
z.retain_grad()

print("Forward: z =", z.item())
z.backward()
print(f"dz/dz = 1 (输出对自己的梯度永远是1) -> {z.grad.item()}")
print(f"dz/dw = dz/dz * ∂z/∂w = 1 * 1 = {w.grad.item()}")
print(f"dz/dy1 = dz/dw * ∂w/∂y1 = {w.grad.item()} * y2 = {w.grad.item()} * {y2.item()} = {y1.grad.item()}")
print(f"dz/dy2 = dz/dw * ∂w/∂y2 = {w.grad.item()} * y1 = {w.grad.item()} * {y1.item()} = {y2.grad.item()}")
print(f"dz/da  = dz/dy1 * ∂y1/∂a = {y1.grad.item()} * (1/a) = {y1.grad.item()} * (1/{a.item()}) = {a.grad.item()}")
print(f"dz/dX1 = dz/da * ∂a/∂X1 = {a.grad.item()} * X2 = {a.grad.item()} * {X2.item()} = {X1.grad.item()}")
print(f"dz/dX2 = dz/da * ∂a/∂X2 + dz/dy2 * ∂y2/∂X2\n"
      f"       = {a.grad.item()} * X1 + {y2.grad.item()} * cos(X2)\n"
      f"       = {a.grad.item()} * {X1.item()} + {y2.grad.item()} * {torch.cos(X2).item()}\n"
      f"       = {X2.grad.item()}")

输出结果为：

Forward: z = 0.2528530955314636
dz/dz = 1 (输出对自己的梯度永远是1) -> 1.0
dz/dw = dz/dz * ∂z/∂w = 1 * 1 = 1.0
dz/dy1 = dz/dw * ∂w/∂y1 = 1.0 * y2 = 1.0 * 0.14112000167369843 = 0.14112000167369843
dz/dy2 = dz/dw * ∂w/∂y2 = 1.0 * y1 = 1.0 * 1.7917594909667969 = 1.7917594909667969
dz/da  = dz/dy1 * ∂y1/∂a = 0.14112000167369843 * (1/a) = 0.14112000167369843 * (1/6.0) = 0.023520000278949738
dz/dX1 = dz/da * ∂a/∂X1 = 0.023520000278949738 * X2 = 0.023520000278949738 * 3.0 = 0.07056000083684921
dz/dX2 = dz/da * ∂a/∂X2 + dz/dy2 * ∂y2/∂X2
       = 0.023520000278949738 * X1 + 1.7917594909667969 * cos(X2)
       = 0.023520000278949738 * 2.0 + 1.7917594909667969 * -0.9899924993515015
       = -1.7267885208129883

对于计算图就是对于你的输入数据进行了那种计算方式进行记录，后续梯度反向传播时候通过上面计算图（计算图保存了所有中间变量和梯度信息）来计算梯度更新参数。更加底层的了解一下上述整个过程，通过下面代码访问具体计算图：

def show_graph(fn, indent=0):
    if fn is None:
        return
    print("  " * indent, fn)
    for next_fn, _ in fn.next_functions:
        show_graph(next_fn, indent + 1)
show_graph(z.grad_fn)

最后输出内容就是：

 <MulBackward0 object at 0x7f3aac04af20>         z=y2* y3
   <LogBackward0 object at 0x7f3aac0494b0>       y2=log(y1)
     <MulBackward0 object at 0x7f3aac049690>     y1=x1*x2
       <AccumulateGrad object at 0x7f3aac049600> x1
       <AccumulateGrad object at 0x7f3aac049510> x2
   <SinBackward0 object at 0x7f3aac0495d0>       y3=sin(x2)
     <AccumulateGrad object at 0x7f3aac049690>   x2

那么在 forward 过程中，Step-1计算 $y1= x1\times x2$，那么此时创建Node：MulBackward0并且保存x1 x2，并且建立关系：

y1.grad_fn → MulBackward0
MulBackward0.next_functions → [AccumulateGrad(x1), AccumulateGrad(x2)]

那么在 backward 过程中，Step-1计算 MulBackward0（z=y2* y3）计算：

dz/dy2 = y3
dz/dy3 = y2

传递：

→ LogBackward0（带 y3）
→ SinBackward0（带 y2）

如果要得到模型具体的计算图下面两种方法：

import torch
from torchviz import make_dot
from torchvision.models import resnet18
"""
apt-get install -y graphviz
pip install torchviz
pip install onnxscript
"""
model = resnet18()
model.eval()
x = torch.randn(1, 3, 224, 224)
y = model(x)

dot = make_dot(y, params=dict(model.named_parameters()))
dot.format = 'png'
dot.render("model_graph")

onnx_file_path = "resnet18_model.onnx"
torch.onnx.export(
    model,                      # 要导出的模型
    x,                          # 虚拟输入
    onnx_file_path,             # 导出文件路径
    export_params=True,         # 是否导出权重参数
    opset_version=17,           # ONNX 算子版本，建议 12 及以上
    do_constant_folding=True,   # 是否执行常量折叠优化
    input_names=['input'],      # 输入节点的名称
    output_names=['output'],    # 输出节点的名称
    dynamic_axes={              # 可选：支持动态 Batch Size
        'input': {0: 'batch_size'},
        'output': {0: 'batch_size'}
    }
)
print(f"模型已成功导出至: {onnx_file_path}")

对于第二种可以直接将到处的模型通过网站：https://netron.app/ 去分析每个节点的具体参数以及输入和输出。在torch计算图概念中主要是两种计算方式：1、动态计算图；2、静态计算图，两者之间的核心差异在于前者计算图在 forward 执行过程中边执行边生成（执行每一个运算过程就会生成一个新的节点），而后者计算图在执行前已经完整确定，并作为“可优化程序”执行（提前解析表达式得到计算图）

torch.compile

对于上述图像简单了解几个基本过程²：
第一步：首先通过TorchDynamo —— “动态录音机”（抓图）
当你第一次运行被 torch.compile 装饰的函数时，Dynamo 会“偷偷”接管 Python 的执行。 它不是静态看代码，而是一边模拟运行，一边录音： 把所有 PyTorch 操作（加、乘、卷积、ReLU 等）记录下来，画成一张 FX Graph（一张计算流程图）（对于普通的python操作不会被记录）。 python 的普通代码（if 判断、for 循环、打印等）如果太复杂，就产生 Graph Break（图断开），这部分还是用原来的慢方式运行。 它还会记录“假设”：比如输入 tensor 的形状是 [32, 3, 224, 224]、类型是 float32 等。这些假设叫 Guards（守卫）。

第二步：AOTAutograd —— “提前准备反向传播”
如果是训练（需要 backward），Dynamo 只抓了前向（forward）。 AOTAutograd 会提前从前向图生成反向图（不用等到真正做 backward 时才临时建图）。 它还会把复杂操作分解成更基础的操作（PrimTorch），让后续优化更容易。 好处：前向+反向可以一起优化，节省内存（不用保存所有中间结果）。

第三步：TorchInductor（默认后端）—— “优化工厂 + 代码生成器”
拿到干净的计算图后，Inductor 开始大改造： 融合操作：把能合并的算子合成一个内核（例如 conv + batchnorm + relu 变成一个 GPU 内核，减少内存读写）。 布局优化、内存复用、循环优化等。 生成代码： GPU 上主要生成 Triton 代码（一种简单却高效的语言，比手写 CUDA 容易，性能接近官方）。 CPU 上生成 C++ 代码。

简单使用

值得注意的是：在torch>2.0之后引入一个新的概念 torch.compile³ 在传统的计算过程中，如 x+y那么pytorch就会执行Python 解释器调用函数、检查类型、分配内存、调用 GPU/CPU 操作等操作，这样以来过程就会比较慢，比如说简单的计算：

import torch
def fun1(a, b):
    return a+b
fun_compile = torch.compile(fun1)

@torch.compile
def fun2(a, b):
    return a+b

基本上只需要对涉及到计算的函数用 torch.compile处理即可（第一次编译速度比较慢，后续计算就快了），直接测试使用compile再模型训练过程中的表现，值得注意的是在使用Trl框架进行强化学习过程中，训练参数直接支持使用 compile（具体位置为：transformers/training_args.py，直接在DPOConfig中进行指定即可，直接使用 torch_compile= True 即可启动），如果是其它训练过程（假设使用accelerator框架进行）：

if compile:
    s_compile_time = time.time()
    model = torch.compile(model, mode="reduce-overhead")
    accelerator.print(f"Compile Time: {time.time() - s_compile_time:.2f}s")
...
model, optimizer, train_loader, test_loader = accelerator.prepare(model, optimizer, train_loader, test_loader)

在测试resnet50在CIFAR10数据集上表现如下（代码）：

# 使用compile
Compile Time: 0.89s
Epoch 00 | Train Time: 12.17s | Batch Time: 0.14764126466245067Train ACC: 11.19% | Test ACC: 11.89%
Epoch 05 | Train Time: 5.72s | Batch Time: 0.046339944917328506Train ACC: 15.49% | Test ACC: 15.54%
Epoch 10 | Train Time: 5.71s | Batch Time: 0.04499245176509935Train ACC: 18.26% | Test ACC: 19.50%
...
Epoch 85 | Train Time: 5.60s | Batch Time: 0.04556511859504544Train ACC: 37.01% | Test ACC: 39.24%
Epoch 90 | Train Time: 5.70s | Batch Time: 0.04652732245776118Train ACC: 37.74% | Test ACC: 40.30%
Epoch 95 | Train Time: 5.66s | Batch Time: 0.04582754933104223Train ACC: 38.30% | Test ACC: 41.03%

# 不使用compile
Epoch 00 | Train Time: 5.71s | Batch Time: 0.05050786174073511Train ACC: 11.29% | Test ACC: 11.41%
Epoch 05 | Train Time: 5.25s | Batch Time: 0.047670155155415436Train ACC: 15.84% | Test ACC: 16.45%
Epoch 10 | Train Time: 6.11s | Batch Time: 0.04854408575564015Train ACC: 18.56% | Test ACC: 19.64%
...
Epoch 85 | Train Time: 6.00s | Batch Time: 0.048004476391539284Train ACC: 36.92% | Test ACC: 39.01%
Epoch 90 | Train Time: 5.05s | Batch Time: 0.04837274064823073Train ACC: 37.71% | Test ACC: 39.21%
Epoch 95 | Train Time: 5.30s | Batch Time: 0.04843420398478605Train ACC: 38.82% | Test ACC: 40.20%

从上述结果上看，最后ACC差异不大，但是在每个epoch以及batch_time上还是有差异的，于此同时对于在GRPOTrainer上表现如下（只看loss和奖励值，测试的数据以及模型为trl-lib/DeepMath-103K和Qwen2-0.5B-Instruct，其中只使用1%数据）：


通过在Resnet以及GRPO两种训练中发现，时间上都会减少并且在模型最后效果是差异不大。下面进一步解释上面没有解释的几个概念。

torch.compile 参数

官方参数中提供的核心参数如下：

1. backend (后端)：决定了计算图最终被转化为何种形式。inductor (默认值)：这是最推荐的选择。它使用 TorchInductor 后端，将代码编译为 Triton (针对 GPU) 或 C++ (针对 CPU)。它能提供最深的算子融合和内存优化。cudagraphs：利用 NVIDIA 的 CUDA Graphs 技术，通过减少 CPU 启动 Kernel 的开销来加速小模型。其他：如 onnxrt (ONNX Runtime) 或 tvm，通常用于特定的硬件部署场景。
2. mode (预设模式)：1、 default：默认模式；2、 reduce-overhead：减少开销模式（使用 CUDA Graphs 减少 CPU 启动开销，最适合小 batch 或推理场景，但会增加显存占用）；3、 max-autotune：最大自动调优模式（使用 Triton 优化算子，如 ReLU、Softmax 等，编译时间较长）
3. fullgraph（全图捕捉）：False (默认)：如果编译器遇到无法处理的 Python 代码（如使用了复杂的第三方库或特殊的 print 语句），它会将图拆分成几个小图，中间夹杂着 Python 解释器执行。True：强制要求整个模型被捕捉为一张完整的计算图。如果模型中存在无法编译的代码，会直接报错。这通常用于追求极致性能的导出场景。
4. options可以直接向底层后端传递特定的优化指令。可以直接通过 torch._inductor.list_options()查看支持哪些操作，除此之外按照官方文档中介绍的几种处理方式：
   

基础概念

对于最开始提到的3组合概念：1、dynamo；2、AOTAutograd；3、TorchInductor下面逐一进行介绍

dynamo

最上面提到在使用 compile 之前会去获取计算图，之所以要提前获取计算图是因为：pytorch中有些计算如 ReLU(Add(A, B))等，执行逻辑就是先add而后计算relu，但是如果提前获取计算图可以直接通过triton将两部合并为一段代码进而减少计算提高速度（这就是动态计算图和静态计算图之间一个较大的差异，动态计算图便计算边获取图，静态提前获取整个计算图），参考⁴这些内容理解。比如说在官方示例中对于compile获取计算图过程为：

from typing import List
import torch
from torch import _dynamo as torchdynamo
def my_compiler(gm: torch.fx.GraphModule, example_inputs: List[torch.Tensor]):
    print("my_compiler() called with FX graph:")
    gm.graph.print_tabular()
    return gm.forward  # return a python callable

@torchdynamo.optimize(my_compiler)
def toy_example(a, b):
    x = a / (torch.abs(a) + 1)
    if b.sum() < 0:
        b = b * -1
    return x * b
for _ in range(100):
    toy_example(torch.randn(10), torch.randn(10))

得到的输出是：

对于上述参数解释如下：1、opcode（操作码），placeholder: 函数的输入参数（入口）。 call_function: 调用一个 Python 函数（如 add, mul）。 call_method: 调用一个对象的方法（如 tensor.sum()）。 output: 整个图的返回值（出口）；2、name: 这个节点在图中的唯一名称（可以理解为变量名）。 3、target: 实际执行的具体函数或目标。 4、args / kwargs: 该操作需要的输入参数。如果参数是 abs_1，表示它引用了前面名为 abs_1 节点的输出。

第一个图：逻辑分支的“上半部分”（对应我的 x = a / (torch.abs(a) + 1)） ，这个图展示了一段包含条件判断的计算逻辑：
输入: 接收两个输入 l_a_ 和 l_b_。
计算路径A: 计算 abs(l_a_) + 1，然后计算 l_a_ / (abs(l_a_) + 1)，结果存为 x。
计算路径B: 计算 l_b_.sum()，结果存为 sum_1。
条件判定: 判断 sum_1 < 0，结果存为 lt（此时其为一个bool类型数据）。
输出: 返回了一个元组 (lt, x)。 之所以要返回一个bool类型数据是因为 TorchDynamo 遇到了图中断（Graph Break）。Python 的 if 分支通常无法直接被编译进同一个静态图中。它先编译到 if 判定的地方，根据 lt 的真假，再决定后面走哪个子图。

后两个图：分支后的执行路径，由于代码中可能存在类似 if sum(b) < 0: return x * (-b) else: return x * b 的判断语法，编译器生成了两个不同的子图：子图 2：执行的是 x * (b * -1)。这对应 sum(b) < 0 成立时的逻辑。子图 3 ：执行的是 x * b。这对应 sum(b) < 0 不成立时的逻辑。那么最后通过上述过程将图处理为：

def forward(a, b):
    # 对应第一个图
    abs_1 = abs(a)
    add = abs_1 + 1
    x = a / add
    sum_1 = b.sum()
    
    # 此时发生了 Graph Break (图中断)
    # 因为后端需要知道 lt 是 True 还是 False 才能继续
    if sum_1 < 0:
        # 对应第二个图
        return x * (b * -1)
    else:
        # 对应第三个图
        return x * b

compile中具体获取计算图过程⁵⁶是直接通过捕获计算图是在翻译 Python 字节码⁷的过程中实现的，还是用最上面的例子直接通过 dis.dis(toy_example) 输出得到字节码：

对于 字节码 简单理解为：在执行python代码（源码）之前会将代码进行编译得到所谓的字节码，然后直接将字节码交给虚拟机执行，那么在 dynamo 过程中则是 逐条解释字节码，遇到tensor操作将其记录为计算图节点（可以简单将 计算图 理解为一个栈，遇到和pytorch相关计算就放到这个 栈 中）

 11           0 RESUME                   0

 12           2 LOAD_FAST                0 (a)
              4 LOAD_GLOBAL              1 (NULL + torch)
             14 LOAD_ATTR                2 (abs)
             34 LOAD_FAST                0 (a)
             36 CALL                     1
             44 LOAD_CONST               1 (1)
             46 BINARY_OP                0 (+)
             50 BINARY_OP               11 (/)
             54 STORE_FAST               2 (x)

 13          56 LOAD_FAST                1 (b)
             58 LOAD_ATTR                5 (NULL|self + sum)
             78 CALL                     0
             86 LOAD_CONST               2 (0)
             88 COMPARE_OP               2 (<)
             92 POP_JUMP_IF_FALSE        5 (to 104)

 14          94 LOAD_FAST                1 (b)
             96 LOAD_CONST               3 (-1)
             98 BINARY_OP                5 (*)
            102 STORE_FAST               1 (b)

 15     >>  104 LOAD_FAST                2 (x)
            106 LOAD_FAST                1 (b)
            108 BINARY_OP                5 (*)
            112 RETURN_VALUE

那么dynamo利用这个字节码的逻辑就是，输入：Python 字节码。 处理：逐条扫描字节码，若是 Tensor 运算就记在 FX Graph 账本上，若是普通 Python 逻辑就正常模拟。 结果：产生一个高效的 FX Graph + 一组确保安全的 Guards。

AOTAutograd

dynamo只是获取了forward过程，模型优化（backward过程）在compile中则是通过AOTAutograd进行处理为推理出来的计算图，自动生成配套的反向传播（Backward）计算图。在pytorch中还有一中计算梯度方式也是最常见的计算方式autograd对于这两种之间差异在于：
1、Autograd：你只写前向传播（forward），PyTorch 会在运行时动态记录每一步操作，自动构建一个计算图（computational graph）。当你对 loss 调用 .backward() 时，它就沿着这个图反向走一遍，用链式法则自动算出所有参数的梯度。 整个过程中这个图是动态、临时的：每次 forward 都会重新建图，用完就销毁（除非手动 retain_graph=True）。优点是超级灵活——支持 if、for 循环、任意 Python 代码，调试也方便。但缺点是每次都要重新建图，Python 开销大，不容易做全局优化。
2、AOTAutograd：它和普通 Autograd 的最大区别是：不是在运行时动态建图，而是提前就把前向和反向的整个计算图一次性捕获。第一次运行时，用“假张量”（FakeTensor）模拟一遍 forward，记录下所有操作，生成两个静态的 FX Graph（一个 forward，一个 backward）。这两个图是可分析、可复用、可优化的 Python 对象。

简单总结就是：Autograd每次计算都会重新去构建图，AOTAutograd提前将图创建好，下次用直接按照图去运行即可（省去创建费时）

TorchInductor

主要是对算子进行融合，比如说$y = \text{ReLU}(Ax + b)$，传统方式要读写三次显存，Inductor 会将其合并为一个 Kernel，数据读入显卡后一次性算完再写回。

参考

CPU 瓶颈比较好认。GPU 利用率像心电图一样上下跳动，高的时候在算，低的时候在等数据。htop 一看，CPU 某几个核打满了，其他的闲着，DataLoader 的 worker 数量没配对。GPU 计算瓶颈的表现是利用率高，但实际吞吐量低。这时候得看 MFU（Model FLOPs Utilization），如果 MFU 很低，说明 GPU 算力没被喂饱。可能是算子实现效率差，也可能是 kernel 太碎，调度开销太大。I/O 瓶颈有个很典型的症状：训练刚开始特别慢，跑几个 step 之后速度才上来。因为第一批数据要从磁盘读，后面的数据可能已经缓存到内存里了。iotop 一看，磁盘读写爆高，CPU 反而不怎么忙。多卡训练的通信瓶颈也好判断。看 nvidia-smi，某几张卡利用率明显比其他的低，它们在等梯度同步。在 profiler 里看 NCCL 相关操作，如果 AllReduce 的时间占到 30% 以上，就是通信在拖。还有个容易被忽略的：框架开销。Python 解释器本身、GIL 锁、过多的 Python 层函数调用，这些都会吃掉时间。在 torch.profiler 的 CPU trace 里，如果看到大量时间花在 Python 调度上而不是实际计算上，就是这个问题。

绝大部分时间 kernel算子一般都是优化比较好的（除非你自己去写算子），绝大多数情况下优化dataloader过程基本可以满足需求

dataloader过程

平时写代码过程中对于 dataloader过程处理比较简单：

from torch.utils.data import DataLoader, Dataset
class CustomDataset(Dataset):
    def __init__(self, ...):
        ...
    def __len__(self):
        # 一般就是直接返回数据数量
        ...
    def __getitem__(self, idx):
        # 一般就是对数据进行处理如标准化等
        ...
        # 如果处理报错就可以直接去下一个数据处理
        # next_index = (index + 1) % len(self)
        # return self.__getitem__(next_index)
    def collate_fn(self, batches):
        batch_size = len(batches)
        # 解包 batches 在 __getitem__ 中返回什么就解包得到什么
        _, _ = zip(*batches)
train_dataset = CustomDataset(xxx)
train_loader = DataLoader(
    train_dataset,
    batch_size=64,                  # 根据你的 GPU 显存调整，越大越好
    shuffle=True,
    num_workers=8,                  # 根据 CPU 核心数和实验调整（起始建议）
    pin_memory=True,                # 强烈推荐
    prefetch_factor=4,              # 可选，加速预取
    persistent_workers=True,        # 可选，推荐
    drop_last=True                  # 可选，避免小 batch
)

介绍dataloader原理之前先去看里面参数含义：1、batch_size（int）：一次处理多少数据；2、shuffle（bool）：是否对数据进行打乱（一般对val数据不打乱）；3、sampler：从样本中的采样策略；4、num_workers（int）：数据加载进程数量；5、collate_fn：对batch数据进行处理操作；6、pin_memory_device：指定 pin memory 操作的目标设备（通常配合 pin_memory=True 使用）；7、pin_memory（bool）：数据提前复制到cuda显存中。一般而言除去常用几个参数即使去调整 pin_memory 去加快数据加载速度，一般而言对于 num_workers 并非越大越好（习惯用8），可以通过实则调节而后通过 torch.profile去分析数据加载费时。

这里再去介绍一些Dataloader原理（图像来自知乎）：

Dataset 是整个数据加载流程的基础。它提供了一个索引访问接口，主要定义了两个方法：__len__()：返回数据集总样本数，__getitem__(index)：根据索引返回第 $i$ 个样本（样本可能来自磁盘读取、内存加载，或实时生成）。Sampler 与 BatchSampler 的作用如下：如果没有手动指定 sampler，且 shuffle=True，DataLoader 会自动使用 RandomSampler，在每个 epoch 开始时对所有样本的索引进行一次性随机打乱。BatchSampler 则负责将打乱后的索引列表，按照 batch_size 分组，形成一个个 batch 的索引列表（例如 [ [45, 7, 23, 12], … ]）。当 num_workers > 0 时，DataLoader 会启用多进程数据加载机制，具体流程如下：

主进程通过 BatchSampler 生成所有已打乱的 batch 索引列表。主进程将每个 batch 的索引（batch_indices）通过 index_queue 分发给不同的 worker 进程。每个 worker 进程 独立完成以下工作：接收一个 batch_indices（例如 [45, 7, 23, 12]）多次调用 dataset[i] 获取对应样本在 worker 进程内执行 collate_fn，将多个样本组装成一个完整的 batch将组装好的 batch 通过 worker_result_queue 发送回主进程，主进程接收到 batch 后，若设置了 pin_memory=True，则通过后台线程将其转换为 pinned memory（页锁定内存），最后将 batch 返回给训练循环使用。

对于 Dataloader 中可以做的修改内容不多，比如有比较常见的几种情况：1、我的数据（dataset）中我的数据有1T，设备处不了如何做？2、如何取定义自己的采样器？
1、处理大批量数据：一般在定义 dataset（pytorch中提供两种数据类型 Map-Style Datasets 以及 Iterable-Style Datasets） 过程中是直接通过 __len__ 以及 __getiem__ 去获取数据信息，如果数据有1T直接打开然后 len 势必导致问题，比较简单方式直接通过pytorch原生的 IterableDataset 进行处理将数据转化为数据流，除此之外还可以通过使用huggingface datasets中流式模式 dataset = load_dataset("json", data_files="data/1T.jsonl", streaming=True)，如果对于图像等可以直接使用 WebDataset 方式，以使用 IterableDataset 为例：

import json
import torch
from torch.utils.data import IterableDataset, DataLoader

class IterableDatasetJsonl(IterableDataset):
  def __init__(self, file_path, file_type: str='jsonl', shard_rank=0, num_shards=1):
    self.file_path = file_path
    self.file_type = file_type
    self.shard_rank = shard_rank
    self.num_shards = num_shards

  def __iter__(self):
    worker_info = torch.utils.data.get_worker_info()
    if worker_info is not None:
      shard_rank = self.shard_rank * worker_info.num_workers + worker_info.id
      num_shards = self.num_shards * worker_info.num_workers
    else:
      shard_rank, num_shards = self.shard_rank, self.num_shards

    with open(self.file_path, 'r', encoding='utf-8') as f:
      for i, line in enumerate(f):
        if i % num_shards == shard_rank:
          sample = json.loads(line)
          '''
          继续后处理
          '''
          yield sample

对于 IterableDataset 使用区别 datatset 最大差异就是直接在 iter 中对数据进行处理

2、使用不同的采样器，最常见的情况就是，1、对于图像进行分桶输入（比如有1024x1024也有1024x768），3、控制数据分布，如数据自身具有一定特征需要控制这些特征在一个batch中分布相对一致。

对于文本情况，如果需要输入 bs>1 一般而言直接定义 collate_fn 提前去对文本进行 padding 并且返回 mask（一般模型都可以接受mask作为输入），padding方式： padded_input_ids = pad_sequence(truncated, batch_first=True, padding_value=pad_token_id)（from torch.nn.utils.rnn import pad_sequence ）

import torch
import random
from collections import defaultdict
from torch.utils.data import DataLoader, Sampler, Dataset
class BucketBatchSampler(Sampler):
  def __init__(self, dataset, batch_size, drop_last=True, shuffle=True):
    self.dataset = dataset
    self.batch_size = batch_size
    self.drop_last = drop_last
    self.shuffle = shuffle

    self.buckets = defaultdict(list)
    # 直接去便利所有数据 在效率上存在一定欠缺
    for idx in range(len(dataset)):
      h, w = dataset.get_image_size(idx)
      self.buckets[(h, w)].append(idx)
    self.bucket_keys = list(self.buckets.keys())

  def __iter__(self):
    batches = []
    for key in self.bucket_keys:
      indices = self.buckets[key][:]
      if self.shuffle:
        random.shuffle(indices)

      for i in range(0, len(indices), self.batch_size):
        batch = indices[i:i + self.batch_size]
        if self.drop_last and len(batch) < self.batch_size:
          continue
        if batch:
          batches.append(batch)

    if self.shuffle:
      random.shuffle(batches)

    for batch in batches:
      yield batch

  def __len__(self):
    total = 0
    for indices in self.buckets.values():
      total += len(indices) // self.batch_size
      if not self.drop_last and len(indices) % self.batch_size != 0:
        total += 1
    return total

对于上述代码中在sampler中提前遍历了所有的数据并且根据分辨率进行分组（实际可能需要对图像进行分辨率计算–>根据计算预估分组） ，__iter__：定义如何生成采样顺序（在使用 for batch in dataloader 中就会使用这个方法），最后通过 yield 进行返回（因为 __iter__ 必须返回一个迭代器也可以使用 return），__len__：返回 该采样器在当前配置下会产生多少个 batch（或多少个样本）

宏观指标分析

最简单分析方法直接在模型运行过程中使用 time 去记录时间就可以快速了解每一个阶段耗时统计，除此之外还可以直接基于linux（假设服务器为linux Ubuntu系统）的基础命令进行分析，主要是分析CPU内存使用情况、GPU使用情况、磁盘io使用情况。CPU性能分析，一般而言可以直接使用htop、top、bytop等工具直接去看，这里直接使用bytop工具进行性能分析，首先安装bytop²（pip3 install bpytop --upgrade 或者直接使用 sudo apt install bpytop），而后就可以直接终端使用 bpytop就可以看到各项性能分析


使用方法比较简单直接通过数字选择（直接键盘输入数字）需要看到的面板：

1：显示/关闭 CPU性能分析
2：显示/关闭 内存/存储性能分析
3：显示/关闭 网络分析
4：显示/关闭 各项进程进行分析

首先通过上述 bpytop就可以简单了解各项进程上在内存上使用情况如何、CPU使用情况如何。GPU性能分析，对于GPU性能分析最简单工具直接使用 watch -n 0.1 nvidia-smi 每0.1s刷新nvidia-smi情况，主要是去看GPU利用率、显存占用情况

值得注意的是，有些时候即使将所有的在跑的程序都关闭但是发现显存还是被占用（利用率是0）³使用ps -ef命令

可以看到PID、PPID、CMD 3列重要信息，分别是进程ID、父进程ID、进程的启动命令。通过命令可以判断哪些进程是自己程序启动的进程，比如上方的python train.py就是我启动的进程，其他的均为系统进程或无关显存占用的进程。接下来杀死进程：从截图中看到python train.py程序的进程ID是594 和797，那么可以使用kill -9 594 797命令来结束进程。

但是常常占用显存的进程会很多，特别是在多卡并行时，按此方法会比较繁琐，以下介绍一种更强大的方式结束进程：通过ps -ef能看出，我自己的进程都包含了train关键字（并且其他无关的系统进程没有包含，防止误杀），那么使用grep命令可以过滤出我自己的进程，例如：

接下来是获取进程的ID，此时可以使用awk命令，awk命令用法复杂，这里简单记住以下命令即可：

最后再通过kill命令，即可完整的结束进程。完整命令为ps -ef | grep train | awk '{print $2}' | xargs kill -9

以上输出中会多出来一个No such process的错误，可以忽略，出现原因是grep train也会产生一个进程，被自己过滤出来。

微观指标分析

上面介绍了宏观指标去看CPU/GPU/磁盘/内存之间的使用情况，最好的情况就是这几项的指标都要上去保证在一个较好的情况下，下面进一步介绍更加微观的指标

基于torch profiler分析

直接使用torch原生工具⁴进行性能分析可以帮助我们分析和优化模型的执行时间、GPU 利用率、内存带宽等性能指标。通过 torch.profiler，你可以了解每一层模型在设备上的执行情况，分析 GPU 资源的利用率（再了解每一块的耗时之后就可以直接再去争对耗时较长的内容进一步分析优化了），具体代码测试过程中使用方法比较简单：

from torch.profiler import profile, ProfilerActivity, tensorboard_trace_handler
# 首先初始化 profile 
# 如果要使用tensorboard需要额外安装 pip install torch-tb-profiler
...

self.accelerator = Accelerator(...,log_with='tensorboard',project_dir=args.log_dir)
...
log_root = self.args.log_dir
if self.accelerator.is_main_process:
    profiler = profile(
        activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
        schedule=torch.profiler.schedule(
            wait=1,      # 等待步数
            warmup=1,    # 预热步数
            active=3,    # 活跃步数
            repeat=2     # 重复次数
        ),
        on_trace_ready=tensorboard_trace_handler(log_dir),
        record_shapes=True,            # 记录张量形状
        profile_memory=True,           # 记录内存使用
        with_stack=True,               # 记录调用栈
        with_flops=True                # 计算 FLOPs
    )
    profiler.start()
...
for epoch in range(1, self.num_epochs + 1):
    for batch_idx, (images, labels) in enumerate(self.train_loader):
        ...# 模型训练过程
        if profiler and self.accelerator.is_main_process:
            profiler.step()
if prof:
    # profiler.export_chrome_trace("trace.json")
    prof.stop()

torch profile使用比较简单就是先初始化而后start()启动记录器、step()记录结果、stop()停止记录，而后直接通过 tensorboard --logdir logs/ 即可（ 值得注意的是，上面代码只会记录少数步，当 repeat=0时候就会一直记录，不需要频繁记录那么多），上述过程中需要注意tensorboard和profile的存储的最终的文件夹要保持一致，对于启动后的在tensorboard中视图中各项结果分析如下⁵：
Overview（概览）：这个页面能帮你快速判断性能瓶颈在哪。

主要关注红框中内容，它会将每个Step（迭代）的时间拆分成 Kernel（计算）、Memcpy（数据传输）、Memset（GPU内存设置时间）、DataLoader（数据加载） 和 CPU Exec（CPU计算） 等几部分。如果”Kernel”占比低而”DataLoader”很高，说明数据加载是瓶颈；如果”CPU Exec”很高，则说明CPU侧的算子或逻辑存在优化空间。
Operator（算子）：这个表格是所有PyTorch操作（如aten::convolution）的性能数据。

主要关注红框中内容，Calls（运行过程中被使用次数）、Device xxx Duration（在 GPU 上花费的累计时间）、Host xxx Duration（在主机上花费时间），分析过程中主要是去更具耗时最长的就是优化重点。如果开启了with_stack=True，点击”Call Stack”还能直接跳转到你代码中调用该算子的位置
Trace（追踪）：这个时间线视图最直观，能让你看到每个算子和CUDA Kernel的精确起止时间。使用方法：在Chrome浏览器打开 chrome://tracing，然后加载生成的JSON文件。或者直接在TensorBoard的Trace页面分析。你可以通过鼠标滚轮缩放，并利用右上角的 Flow Events 按钮，查看是哪个CPU算子启动了一个GPU Kernel，这对于定位CUDA Kernel的启动延迟问题非常有帮助。

Memory（内存）：这个视图展示了内存随时间的分配和释放情况，帮你发现内存泄漏或不必要的显存占用。

Kernel（内核）：这是GPU上执行的底层函数视图。

主要是去查看GPU利用率（GPU Utilization）、SM效率（Est. SM Efficiency）以及Tensor Core的使用情况。如果这些指标偏低，说明GPU并没有被充分利用。

调节参数优化

CPU 瓶颈（一般就去修改数据处理过程，如数据增强等操作）可以直接调 num_workers、增大 prefetch_factor、把预处理卸载到 GPU等处理操作。

DataLoader(train_dataset, batch_size=args.batch_size, shuffle=False, num_workers=4, pin_memory=True)

I/O 瓶颈就换 SSD、预加载数据到内存、用 NVIDIA DALI。GPU 计算瓶颈就做算子融合、上 torch.compile、开混合精度。通信瓶颈就上梯度压缩、通信计算重叠。框架开销就减少 Python 调用、用 TorchScript 或者 C++ 扩展

参考

GSPO

处理长序列优化问题，将token级别处理为sequence级别

Qwen团队论文¹里面首先分析在GRPO中存在如下几点问题：1、奖励函数一般是sequence级别的（对整个回答进行评分）但是却对每个token去计算重要性比率；2、不同专家被不同token激活，导致路由（routing）在rollout和training阶段不一致，GRPO的token级噪声会直接把某些专家“训崩”。针对上述两点问题在GSPO中损失函数为：

区别与GRPO中改进就在于：1、去掉了对于token的平均（在GRPO中对于模型输出会计算token平均：$\frac{1}{\vert o_i \vert}\sum_{t=1}^{\vert o_i \vert}$）；2、计算sequence重要性：将GRPO中计算方式由 $r_{i,t}(\theta)=\frac{\pi_{\theta}(o_{i,t} \vert q,o_{i<t})}{\pi_{\theta_{old}}(o_{i,t} \vert q,o_{i<t})}$改为 $s_i(\theta)=(\frac{\pi_{\theta}(o_i \vert q)}{\pi_{\theta}(o_i \vert q)})^{\frac{1}{\vert o_i \vert}}$。通过改进GSPO区别GRPO表现：

两部分算法在代码差异点如下（Github-GRPOTrainer）：

log_ratio = per_token_logps - old_per_token_logps # shape: [batch*G, seq_len]
if self.importance_sampling_level == "token":
    log_importance_weights = log_ratio # 每个token都一个独立权重
elif self.importance_sampling_level == "sequence":
    log_importance_weights = (log_ratio * mask).sum(-1) / mask.sum(-1).clamp(min=1.0) # 所有token加权求和得到 sequence
    log_importance_weights = log_importance_weights.unsqueeze(-1) # # shape: [batch*G, 1] 得到sequence级别
coef_1 = torch.exp(log_importance_weights)

在trl中要实现GSPO直接使用可以直接使用参数：GRPOConfig(importance_sampling_level="sequence",) 就可以切换到GSPO优化了，按照论文里面参数配置

training_args = GRPOConfig(
    importance_sampling_level="sequence",
    beta=0.0,# 不加KL散度
    epsilon=3e-4,# clipping 下界
    epsilon_high=4e-4,# clipping 上界（
)

SAPO

Qwen团队论文²核心目标是解决“硬clipping的脆性问题”（当一条序列中只要有少数几个 token 的 ratio 超出 clipping 范围，整个序列的梯度就会被全部或大量抑制）。它在保持group-based RL（去Critic、组内相对优势）的基础上，把clipping机制从硬裁剪升级为温度控制的软控制，从而实现sequence-coherent（序列一致性） + token-adaptive（token自适应）的双重优势³，其损失函数为：

整个损失函数还是基于GRPO进行出发，将内部的 $\min(r, clip(r,1-\epsilon, 1+\epsilon))$ 替换为 $f$ 其中 $\sigma$ 是sigmoid函数，$x = r_{i,t}$ 重要性，$\tau$ 是温度参数。而在trl中使用改方法比较简单直接在config中进行指定即可：GRPOConfig(loss_type="sapo")具体的代码处理逻辑为：

elif self.loss_type in ["grpo", "bnpo", "dr_grpo", "dapo", "luspo"]: # trl 中默认直接计算DAPO损失
    coef_2 = torch.clamp(coef_1, 1 - self.epsilon_low, 1 + self.epsilon_high)
    if self.args.delta is not None:
        coef_1 = torch.clamp(coef_1, max=self.args.delta)

    per_token_loss1 = coef_1 * advantages
    per_token_loss2 = coef_2 * advantages
    per_token_loss = -torch.min(per_token_loss1, per_token_loss2)
elif self.loss_type == "sapo":
    # 首先计算 温度系数 直接根据优势值 >0-->有利的“行为” <0-->不利的“行为”
    temperatures = torch.where(advantages > 0, self.args.sapo_temperature_pos, self.args.sapo_temperature_neg)
    # 计算软边界
    soft_coef_1 = torch.sigmoid(temperatures * (coef_1 - 1)) * 4 / temperatures
    per_token_loss = -soft_coef_1 * advantages
...
if self.loss_type in ["grpo", "sapo"]:
    loss = ((per_token_loss * mask).sum(-1) / mask.sum(-1).clamp(min=1.0)).mean()
    normalizer = self.current_gradient_accumulation_steps if mode == "train" else 1.0  # no accum in eval
    loss = loss / normalizer

最终模型论文中的表现：

KL散度改进

KL 散度是用来度量两个概率分布相似度的指标，而计算过程也比较简单直接计算（假设为离散变量）：
\(\mathcal{D}_{KL}(P \Vert Q)=\sum_i P(i)\ln(\frac{P(i)}{Q(i)})\)

不过对于llm中对于内部的 $\sum$ 过程不可能去计算（因为token的词表是非常大的，直接 $\sum$ 不现实）那么退而求其次，只对模型的输出的token去计算log概率，因此就可以将KL计算过程改写为计算期望过程：
\(\mathcal{D}_{KL}(P \Vert Q)=E_{x～P}[\ln\frac{P(x)}{Q(x)}]\)

而对于整个期望的计算可以直接用蒙特卡洛估计方式计算：
\(\mathcal{D}_{KL}(P \Vert Q)≈\frac{1}{N}\sum_{i=1}^{N}\ln \frac{P(x)}{Q(x)} \quad x～P\)
对于上述过程在代码（trl）中计算方式也比较简单直接：

per_token_logps, entropies = self._get_per_token_logps_and_entropies(model,input_ids,...)
if self.beta != 0.0:
    ref_per_token_logps = inputs["ref_per_token_logps"]
    per_token_kl = (
        torch.exp(ref_per_token_logps - per_token_logps) - (ref_per_token_logps - per_token_logps) - 1
    )

在具体的KL计算过程中有3种K1（朴素估计器）：$K1=\log\frac{P(x)}{Q(x)}$、K2（平方对数估计量）：$K2=\frac{1}{2}(\log r)^2$、K3（Bregman 估计器）⁴：$K3=\frac{P(x)}{Q(x)}-1-\log \frac{P(x)}{Q(x)}$，目前主流使用都是基于K3，在DeepSeek-V3.2论文⁵中对于K3做了修改：

其中括号内部的为原始的K3计算，在DS中则是补充了一个 $\frac{\pi_\theta}{\pi_{old}}$ 那么按照论文里面的描述添加此项的好处在于在最初的K3计算过程中当 $𝜋_𝜃 ≪ 𝜋_{ref}$ 时候梯度会赋予过大且无界的权重以最大化这些标记的似然性，导致梯度更新噪声较大，这些噪声会累积，从而在后续迭代中降低样本质量，并导致训练动态不稳定。

参考

Kimi注意力残差连接

首先按照论文中逻辑出发，在标准的残差计算中：$h_l=h_{l-1}+f_{l-1}(h_{l-1})$ 对于这个计算方式在计算梯度传播过程中会直接将每一层的贡献是相同（直接计算上公式梯度）因此后续论文就提出做一个门控的残差连接方式 $h_l=\alpha_l \cdot h_{l-1}+\beta_l \cdot f_{l-1}(h_{l-1})$，对于上述两种残差注意力方式带来最大的问题就是：所有层的贡献都是一致的，除此之外后续层只能获取前层的信息导致更加前面层的信息被稀释（比如说l层只能获取l-1层信息，虽然l-2的信息会融合到l-1层但是l-2还是对l层的作用有限）。因此kimi的attention-residual出发点就是让后续层可以看到更加前面层的信息以及通过一个合适权重去控制残差连接，基于这个论文²里面提出方案如下图c中描述：

对于第n个block我将前面的几层的输出都进加权融合作为第n层的输入，具体融合方式为：
\(h_l= \alpha_{0\rightarrow l}\cdot h_1+ \sum_{i=1}^{l-1}\alpha_{i\rightarrow l}\cdot f_i(h_i)\)
其中 $\sum_{i=1}^{l-1}\alpha_{i\rightarrow l}=1$那么对于权重系数 $\alpha_{i\rightarrow l}$ 的计算方式为：

其实也就是计算softmax的注意力权重，里面的 $q_l=w_l$ 通过一个学习的向量以及历史层的输出去计算softmax值去控制权重特征融合。去看代码具体过程：

def block_attn_res(blocks: list[Tensor], partial_block: Tensor, proj: Linear, norm: RMSNorm) -> Tensor:
    V = torch.stack(blocks + [partial_block]) # [N+1, B, T, D]
    K = norm(V)
    logits = torch.einsum('d, n b t d -> n b t', proj.weight.squeeze(), K)
    h = torch.einsum('n b t, n b t d -> b t d', logits.softmax(0), V)
    return h

def forward(self, blocks: list[Tensor], hidden_states: Tensor) -> tuple[list[Tensor], Tensor]:
    partial_block = hidden_states          # 进入当前层的初始 hidden_states（通常是上一层的输出）
    
    # 在 Attention 子层前，先做一次 Block AttnRes
    h = block_attn_res(blocks, partial_block, self.attn_res_proj, self.attn_res_norm)
    
    # 如果当前层是 Block 的边界层 → 把当前 partial_block 作为完整 Block 保存下来
    if self.layer_number % (self.block_size // 2) == 0:
        blocks.append(partial_block)       # blocks 列表增长，新增一个完成的 Block rep
        partial_block = None               # 重置 partial（新 Block 从零开始？代码这里有小问题，实际可能要用 h 或重置逻辑）
    
    # 自注意力子层（标准 Transformer attention）
    attn_out = self.attn(self.attn_norm(h))
    partial_block = partial_block + attn_out if partial_block is not None else attn_out
    # ↑ 标准残差：partial_block += attn_out   （Block 内部用经典 +）

    # 在 MLP 子层前，再做一次 Block AttnRes（用不同的 proj 和 norm）
    h = block_attn_res(blocks, partial_block, self.mlp_res_proj, self.mlp_res_norm)
    
    # MLP 子层
    mlp_out = self.mlp(self.mlp_norm(h))
    partial_block = partial_block + mlp_out               # 再次标准残差累加
    
    return blocks, partial_block    # 返回更新后的 blocks 列表 + 当前 Block 的 partial sum

其实通过代码很容易发现在block计算过程就是，输入前将前n层的block特征进行attention-residual方式特征融合，在计算完毕之后进行一个普通的残差连接，而后在将输出进行mlp处理之前再次通过一次attention-residual连接处理。

字节混合注意力

在字节论文³中提出混合注意力去解决：随着 LLM 的深度增加，它们往往会遭遇信号衰减的问题：在浅层形成的有用特征会因反复的残差更新而逐渐被稀释，使得它们在更深的层中更难恢复（出发点和kimi的attention-residual相同）。

对于上图中提到的read以及write分别表示的是残差连接方式 $x=x+f(x)$里面分别对于x以及连接方式，比如说对于最开始残差连接我的read就是x（不去对x进行其他处理因此论文里面将其标记为identity）而我的连接方式是add因此将write处理为add。在上图b中选择直接将所有的信息进行拼接（比如说第i层计算输出就行和输入就行concat操作），虽然在信息传播过程是无损的，可以解决上面的信号衰减问题，但是这样会带来显存占用过高。那么论文里面提出Depth Attention处理过程为，对于输入通过相面方式处理：

其中对于 $K_i$ 以及 $V_i$ 表示的GQA过程中我的历史缓存的kv值而 $Q_{l-1}$ 则是上一层的Q结果，通过注意力融合方式得到最终的输入 $X_l^{in}$ 直接将这个结果解析attention的注意力计算得到 $X_l^{out}$，在得到结果之后通过：

又可以得到新的一层的输出结果（相当于替代了之前的残差连接通过相加为线性层处理方式）。除此之外进一步提出升级的 Mixture-of-Depth Attention方式：

对于上述过程中depth表示所有前面层的深度 KV cache（对应深度部分），而QKV则是表示当前层的结果（对应序列部分），10-23行处理序列部分注意力（就是比较常规的注意力计算过程），24-29行处理处理深度部分注意力，在计算注意力过程中会用softmax去更新同一个（m, acc, o），相当于将cache部分信息融入到注意力中。

总结

两篇论文中都是为了解决随着层数的叠加带来的“信息遗忘”问题，Kimi中选择直接将“历史block”信息通过注意力融合方式进行加权残差连接（attention-residual）也就是 $y=\alpha \cdot h_l+ \sum_{i=1}^{l-1} \alpha h_i$，具体过程为将历史所有的block结果和用一个可学习的向量之间计算softmax作为权重 $\alpha$ 具体残差发生在：1、mlp处理前；2、每一个block处理之后。在字节的mixture-of-depth attention处理方式则是直接将GQA中的kv-cache中的KV值用来计算注意力去弥补信息损失，具体过程为在序列部分直接计算常规注意力，在深度部分（KV cache历史结果）部分通过历史结果去更新在序列部分计算得到的注意力结果。

参考

conda create -n vllm_server python=3.12
conda activate vllm_server
pip install vllm==0.17.1

在之前介绍vllm的调度过程在token_budge下去处理waiting以及running队列，对于里面如何对块进行管理没有介绍，比如说在running和waiting队列中，虽然在token_budege下running队列处理过程，通过理论计算比如说我需要running生成一个token，你的显存能够你去生成这一个token吗？以及在waiting队列处理过程中获取我已经计算过的token以及prefill能不能处理这么多new_tokens？这些都需要 kv_cache_manager过程进行管理，比如说下面代码过程：

# running 队列中获取 num_new_tokens 是不是能够被分配到block
new_blocks = self.kv_cache_manager.allocate_slots(
                        request,
                        num_new_tokens,
                        num_lookahead_tokens=self.num_lookahead_tokens,
                    )
# waiting 队列获取已经计算过的token
new_computed_blocks, num_new_local_computed_tokens = (
    self.kv_cache_manager.get_computed_blocks(request)
)
# waiting 中prefill阶段能不能将所有的 num_new_tokens去分配block
new_blocks = self.kv_cache_manager.allocate_slots(
    request,
    num_new_tokens,
    num_new_computed_tokens=num_new_local_computed_tokens,
    new_computed_blocks=new_computed_blocks,
    num_lookahead_tokens=effective_lookahead_tokens,
    num_external_computed_tokens=num_external_computed_tokens,
    delay_cache_blocks=load_kv_async,
    num_encoder_tokens=num_encoder_tokens,
)

在代码中 kv_cache_manager初始化过程为：

# /vllm/v1/core/sched/scheduler.py
self.kv_cache_manager = KVCacheManager(
    kv_cache_config=kv_cache_config,
    max_model_len=self.max_model_len,
    enable_caching=self.cache_config.enable_prefix_caching,
    use_eagle=self.use_eagle,
    log_stats=self.log_stats,
    enable_kv_cache_events=self.enable_kv_cache_events,
    dcp_world_size=self.dcp_world_size,
    pcp_world_size=self.pcp_world_size,
    hash_block_size=self.block_size,
    metrics_collector=self.kv_metrics_collector,
)

对于初始化过程中几个关键参数解释如下：1、kv_cache_config：主要是管理 num_blocks设置（vllm/v1/kv_cache_interface.py）；2、max_model_len：模型支持的最大序列长度；3、enable_caching：开启前缀缓存。

block分配整体过程

在最开始介绍vllm中的整体框架中介绍如下几个参数：1、block_szie：这个一般就是默认16块也就是每一块block存储16个tokens；2、预分配显存大小：一般就是直接 设备显存x分配比率，比如说24Gx0.9≈21.6G也就是vllm提前占用21.6G显存（但是实际kv cache占用不一定就有21.6G，在初始化过程中模型会进行一次forward去计算出，模型运行期间除了 KV cache 以外所消耗的内存）；3、block数量：int(available_memory // page_size // num_layers)，page_szie一个 block在单层上的字节数计算过程为(K+V)$\times$ block_size $\times$ num_kv_heads$\times$ head_size$\times$ dtype_bytes=2 $\times$ 16 $\times$ num_kv_heads $\times$ head_size$\times$ dtype_bytes。num_layers：所有kv_cache_groups中层数的最大值，除此之外vllm为模型的每一层都分配了一个独立的、形状为 [2, num_blocks, block_size, num_kv_heads, head_size] 的KV缓存张量（具体过程后面描述）。那么vllm中整体分配过程如下¹：

对于每一组输入 prompt，在 prefill 阶段会根据 token 数提前分配 block：⌈num_tokens / block_size⌉ 块（例如 block_size=16，5 token 只需 1 块）。 prefill 阶段一次性把 prompt 的所有 token 的 KV 写入这些 block（对于每一个block中几个参数block_id表示当前block的序号，ref_cnt表示当前block被引用次数）。 decode 阶段是增量式的：每次只生成 1 个（或少量）新 token，如果当前最后一个 block 还有空位就继续写入；满了再申请新 block。 当 GPU KV cache 内存不足时，调度器会根据策略（默认 FCFS + 优先 decode）进行 preemption：可能把等待中的请求换出（移动到CPU中）、丢弃重排，或在某些配置下丢弃部分 running 请求。
虽然输入是多组 prompt，但 vLLM 会把它们拼接成一个“序列”来统一计算，以最大化 GPU 利用率。每个序列的 position ids 从 0 独立开始，通过 attention mask保证每组 token 只能看到自己组的信息，跨组完全隔离。 在 decode 阶段，vLLM 使用 slot_mapping tensor 来记录本次 forward 中每个要生成的新 token 对应到物理 KV cache 的哪个 slot 索引，从而实现非连续 block 的高效寻址和写入。

KVCacheManager处理过程

除了KVCache在vllm中还有一个prefix cache其作用表示当多个请求中有相同的前缀时，避免重复计算这部分内容，不过值得注意的是必须是公共前缀，中间相同并不能共享（原因很简单，decode阶段是用n-1去预测n如果两个序列中前k个都相同那么直接复用即可），比如说下面例子中
eg1：你好，帮我介绍武汉？ eg2：你好，帮我介绍北京？==>就可以直接复用 “你好，帮我介绍” 这部分kv cache
eg1：你好，帮我介绍武汉？ eg2：你是一个旅游专家，你好，帮我介绍北京？==>不能实现上面复用

在KVCacheManager（vllm/v1/core/kv_cache_manager.py）中核心逻辑如下几个，1、get_computed_blocks：为当前的request找到他的prefix cache；2、allocate_slots：为当前的new_token去申请分配block， 3、free：释放所有的block当request被处理完之后 ；3、cache_blocks：为prefix cache去分配block；4、reset_prefix_cache：清空所有的cache block。在了解核心逻辑之前了解block池创建过程。

blockpool创建

测试模型为：Qwen/Qwen2-0.5B-Instruct（后续具体数值和显存大小（32G）以及显存初始化大小（0.9）有关）
具体代码位置：vllm/v1/core/block_pool.py
kvcache block构建：vllm/v1/core/kv_cache_utils.py

在代码中（vllm/v1/core/block_pool.py）直接创建所有的blocks： self.blocks: list[KVCacheBlock] = [KVCacheBlock(idx) for idx in range(num_gpu_blocks)]（其中 num_gpu_block大小为：131928） 而里面的KVCacheBlock创建过程比较简单，为每一块block都去创建如下属性;

值得注意的是每一个block都是一个双向队列因此prev以及next分别指向上下的block的idx，而其它熟悉含义如下：block_id当前block的序号、ref_cnt当前block被引用次数。值得注意的是上面过程只是创建了一个元数据对象还不知道具体的显存物理地址，还是在代码 vllm/v1/core/kv_cache_utils.py 中的显存分配过程：

# vllm/v1/core/kv_cache_utils.py
# 测试模型为 Qwen/Qwen2-0.5B-Instruct
def get_kv_cache_config_from_groups(vllm_config: VllmConfig, kv_cache_groups: list[KVCacheGroupSpec], available_memory: int):
    if len(kv_cache_groups) == 1 and isinstance(kv_cache_groups[0].kv_cache_spec, UniformTypeKVCacheSpecs):...
    else:
        group_size = max(len(group.layer_names) for group in kv_cache_groups) # 24
        page_size = get_uniform_page_size(
            [group.kv_cache_spec for group in kv_cache_groups]
        ) # 8192
        assert group_size > 0, "group_size must be greater than 0"
        num_blocks = get_num_blocks(
            vllm_config, group_size, available_memory, page_size
        ) # 131928
        kv_cache_tensors = []
        for i in range(group_size):
            shared_by = []
            for j in range(len(kv_cache_groups)):
                if i < len(kv_cache_groups[j].layer_names):
                    shared_by.append(kv_cache_groups[j].layer_names[i])
            kv_cache_tensors.append(
                KVCacheTensor(size=page_size * num_blocks, shared_by=shared_by)
            )
    ...

kv_cache_groups对应的结果为（测试模型为 Qwen/Qwen2-0.5B-Instruct ）： kv_cache_groups=[KVCacheGroupSpec(layer_names=['model.layers.0.self_attn.attn', 'model.layers.1.self_attn.attn', ..., 'model.layers.23.self_attn.attn'], kv_cache_spec=FullAttentionSpec(block_size=16, num_kv_heads=2, head_size=64, dtype=torch.bfloat16, page_size_padded=None, head_size_v=64, sliding_window=None, attention_chunk_size=None))]
最终的返回内容为： kv_cache_config=KVCacheConfig(num_blocks=131928, kv_cache_tensors=[KVCacheTensor(size=1080754176, shared_by=['model.layers.0.self_attn.attn']), ...], kv_cache_groups=[KVCacheGroupSpec(layer_names=['model.layers.0.self_attn.attn', ...], kv_cache_spec=FullAttentionSpec(block_size=16, num_kv_heads=2, head_size=64, dtype=torch.bfloat16, page_size_padded=None, head_size_v=64, sliding_window=None, attention_chunk_size=None))])
1080754176= page_size* num_blocks= 8192x131928

上述代码主要是计算需要分配的显存大小和block数量，除此之外会对模型中每一层都去计算需要分配的kv_cache_tensor大小，比如说上面代码计算得到每一层结果都是：8192* 131928，也就是我的就会对每一层分配一个这么大的内容去显存中占用，直接去看具体显存分配过程，在代码（vllm/v1/worker/gpu_model_runner.py）中的初始化kv_cache_tensor过程如下：

# vllm/v1/worker/gpu_model_runner.py
def initialize_kv_cache_tensors(self, kv_cache_config: KVCacheConfig, kernel_block_sizes: list[int]):
    ...
    else:
        # 创建 kv_cache_tensors
        kv_cache_raw_tensors = self._allocate_kv_cache_tensors(kv_cache_config)
        # 修改 kv_cache_tensor 形状
        kv_caches = self._reshape_kv_cache_tensors(kv_cache_config, kv_cache_raw_tensors, kernel_block_sizes)
    return kv_caches

对于里面的创建 kv_cache_tensors过程则是直接通过 tensor = torch.zeros(kv_cache_tensor.size, dtype=torch.int8, device=self.device)去初始化一层的张量其大小为 kv_cache_tensor（page_size* num_blocks=8192x131928），而后将其分配给每一层 for layer_name in kv_cache_tensor.shared_by: kv_cache_raw_tensors[layer_name] = tensor而后将每层中分配得到的tensor大小通过 _reshape_kv_cache_tensors 处理，将最开始的 page_size* num_blocks的修改为 kv_cache_shape，让每个层真正需要的 KV cache 形状和 stride 布局，其中得到的kv_cache_shape为：(2, 131928, 16, 2, 64)对应 (K+V, num_blocks, block_size, num_kv_heads, head_size)。

也就是将上面提到的 KVCacheTensor 中每个size大小等于K+V$\times$ num_blocks$\times$ block_size$\times$ num_kv_heads$\times$ head_size$\times$ dtype_bytes

这样一来，整个 KV Cache 的物理显存占用和元数据管理由两大部分组成：物理 KV 数据存储部分（真正占大头显存） 在 kv_cache_tensors 创建和 reshape 阶段，vLLM 为模型的每一层 attention（或每个 KV cache group）提前分配好了对应的 KVCacheTensor。 形状为：(2, num_blocks, block_size, num_kv_heads, head_size)（比如说：(2, 131928, 16, 2, 64)） 这部分是真正存储 K 和 V 数值的显存。 每一层都有自己独立的（或通过 view 共享底层内存的）tensor。 所有层的 tensor 都使用相同的 num_blocks（131928） 作为第一维（block 维度）。 全局 Block 元数据管理部分（几乎不占显存） 在 BlockPool 中一次性创建：list[KVCacheBlock] = [KVCacheBlock(idx) for idx in range(num_gpu_blocks)] 这 num_gpu_blocks 个 KVCacheBlock 对象只保存元数据（block_id、ref_cnt、block_hash、last_access_time 等），不存储任何 KV 数据。
总结：block_pool想象成一个大池塘，当一个请求需要分配新的block时，就会从free_block_queue取出对应数量的block，如果不够，那就分配失败，当请求完成，释放所有block时，就将请求下的所有block释放回free_block_queue。

block分配逻辑

上面简单介绍了如何去分配每层中的显存占用以及创建block，下面介绍输入一个新的request如何去分配block进行占用。以上面waiting分配过程为例：KVCacheManager中初始block协调器（self.coordinator = get_kv_cache_coordinator）–> get_kv_cache_coordinator去选择不同的协调器通过 allocate_new_blocks去分配新的block，其内部逻辑是通过 manager进行配分–> manager实现逻辑在 get_manager_for_kv_cache_spec中通过不同的attention计算方式选择不同的分配方式（vllm/v1/core/single_type_kv_cache_manager.py）。

# get_kv_cache_coordinator 选择kvcache分配器 以KVCacheCooridantor为例 kv_cache_coordinator.py
def allocate_new_blocks(
    self,
    request_id: str,
    num_tokens: int,
    num_tokens_main_model: int,
    num_encoder_tokens: int = 0,
) -> tuple[list[KVCacheBlock], ...]:
    return tuple(
        manager.allocate_new_blocks(
            request_id,
            num_encoder_tokens
            if isinstance(manager, CrossAttentionManager)
            else num_tokens,
            num_tokens_main_model,
        )
        for manager in self.single_type_managers
    )
# 里面 self.single_type_managers 主要是通过 get_manager_for_kv_cache_spec获取，其代码定义位置为 single_type_kv_cache_manager.py
# get_manager_for_kv_cache_spec支持的attention分配逻辑
spec_manager_map: dict[type[KVCacheSpec], type[SingleTypeKVCacheManager]] = {
    FullAttentionSpec: FullAttentionManager,
    MLAAttentionSpec: FullAttentionManager,
    SlidingWindowSpec: SlidingWindowManager,
    ChunkedLocalAttentionSpec: ChunkedLocalAttentionManager,
    MambaSpec: MambaManager,
    CrossAttentionSpec: CrossAttentionManager,
    SinkFullAttentionSpec: SinkFullAttentionManager,
}

在 get_manager_for_kv_cache_spec 支持多种attention都是继承 SingleTypeKVCacheManger，主要去看其内部的 allocate_new_blocks 和 allocate_new_computed_blocks 这两部分代码逻辑，在 new_blocks中：比较简单直接计算需要分配的blocks数量（cdiv=a//b，用新的生成的tokens数量除block_size而后取整即可），而后去我的block pool去拿出对应数量的block即可。对于 new_computed_blocks则是从prefix cache中去拿出已经被处理过程的cache，那么上述整个cache block分配逻辑如下：

比如说我的模型只有4层，而后我输入token数量是50个，block_size是16这样一来就需要4个block才能存下所有的tokens，首先去检查prefix cache（也就是allocate_new_computed_blocks过程）假设前 2 个逻辑 block 已经缓存在 KV cache 中，那么req_to_blocks值假如就是 block_table = [10, 21, null, null]前两个是真实 hit 的 block_id，后两个先占位，而后通过 allocate_new_blocks计算还需要2个block去存储剩下的tokens假设得到的是45，67那么最后我的tokens存储的block_table就是 [10, 21, 45, 67]那么去计算prefill处理，这个过程就是直接拿着这个block_table去实际物理地址中去找（上面我的每一层提前缓存了 (2, 131928, 16, 2, 64)–(2, num_blocks, block_size, num_kv_heads, head_size) 这么多tensor）那么对于每一层

layer-0: kv_cache_layer0[:, [10,21,45,67], ...]
...
layer-3: kv_cache_layer0[:, [10,21,45,67], ...]

此时我的blok没有被填满，而后持续deocde到被填满（分配了4个刚刚好64个被填满）此时需要新的block加入是89那么拿出添加到 block_table中即可，而后依次类推。

Prefix Cache逻辑

Prefix Cache指的是缓存已处理请求的 kv-cache 块，并在新请求到达时重用这些块，前提是新请求与先前请求具有相同的前缀²。在推理框架SGLang中一个比较明显特点就是Prefix Cache不过两者在逻辑上存在差异，vllm是基于block而SGLang则是基于token级别的，也就是说vLLM中只有block被填满了斌且block内都是相同的才能复用prefix cache。在此之前在vllm中的block管理结构如下，block都是一个双链表，彼此之间都知道前后的block，比如说
第 0 个 block（tokens 0~15）： hash0 = hash( NONE_HASH + tuple(tokens[0:16]) + extra_keys )
第 1 个 block（tokens 16~31）： hash1 = hash( hash0 + tuple(tokens[16:32]) + extra_keys )
以此类推后续都是如此。不过必须注意的是：只有在你的block被完全填满（比如说有16个token）之后才会为这个block添加上hash标志！
在介绍调度器中，对于waiting队列管理中有一个逻辑就是new_computed_blocks, num_new_local_computed_tokens = self.kv_cache_manager.get_computed_blocks(request) 通过kv_manager去获取已经被计算过的blocks以及新的本地计算计算的tokens，这部分代码内容逻辑如下：

# kv_cache_manager.py
def get_computed_blocks(self, request: Request) -> tuple[KVCacheBlocks, int]:
    if not self.enable_caching or request.skip_reading_prefix_cache:
        return self.empty_kv_cache_blocks, 0

    computed_blocks, num_new_computed_tokens = (
        self.coordinator.find_longest_cache_hit(
            request.block_hashes,  # 请求预先计算好的 block hash 列表（链式）
            request.num_tokens - 1
        )
    )
    ...
    return self.create_kv_cache_blocks(computed_blocks), num_new_computed_tokens

从代码中对于被计算过的blocks获取方法直接通过 find_longest_cache_hit 去获取，这部分代码内部逻辑是我直接去遍历所有的KVCacheBlock中去看哪些 hash 是对应的，如果找到对应的那就可以直接复用即可，直接用官方例子来解释：
时间1：缓存为空，输入request0（prompt为A-O）总共15个token。直接从block pool中分配了 4 个块（假设每个块只能缓存4个token）。其中 3 个已满那么就会被缓存（直接使用SHA256进行编码，编码逻辑是： sha256( parent_hash + 本块tokens + extra ) 分别表示上一个列表、本block token、额外信息），第四个块部分填充了 3 个 token，那么此时被填满token的block直接建立hash id比如A-D对应ID=0，如果下次还有A-D的token输入可以直接从cache blocks直接复用（直接拿ID=0）

具体复用可以直接看上面显存分配过程，每层(K+V, num_blocks, block_size, num_kv_heads, head_size) 只需要去num_blocks去拿对应ID即可，除此之外虽然分了block但是计算时候还是复用的，比如说计算E时候会直接那 ABCD的cache内容

时间2：开始decode处理，这样就会对 request0 使块3填满，并请求新块以继续解码，这个时候有4块被填满那么就会在cache block中建立4个hash

时间 3：request1 到达，带有 14 个提示 token（A-J，k-n），其中前 10 个 token 与请求 0 相同。我们可以看到只有前 2 个块（8 个 token）命中缓存，因为第 3 个块只匹配了 4 个 token 中的 2 个。其具体的命中缓存内部逻辑如下，比如开始 request1在预分配的4个block其中前三块都是被填满建立索引假设是 *0 *1 *2 *3 （在我的request0中建立hash是 *0 *1 *4 *5 *6）那么会去调用 find_longest_cache_hit(request.block_hashes) 去cache blocks进行查找发现request2中 *2没有命中，那么直接复用 *0 以及 *1。也就对应下面图像中 request1服用了ID0和ID1，比如说代码：

@classmethod  
def find_longest_cache_hit(cls, block_hashes, max_length, ...):  
    computed_blocks = tuple([] for _ in range(len(kv_cache_group_ids)))  
    max_num_blocks = max_length // block_size  
      
    for block_hash in itertools.islice(block_hashes, max_num_blocks):
        # 直接去 blocks_hashes 中查找
        if cached_block := block_pool.get_cached_block(block_hash, kv_cache_group_ids):
            # 遇到匹配的cahce
            for computed, cached in zip(computed_blocks, cached_block):  
                computed.append(cached)  
        else:  
            break  
      
    if use_eagle and computed_blocks[0]:  
        for computed in computed_blocks:  
            computed.pop()  
      
    return computed_blocks

值得注意的是，只有当前面token都相同才会命中缓存，比如说Reques2输入是：BACDEFGHxxxx就是有EFGH相同也不会命中缓存，以为计算需要复用Request2开始的token式BACD完全和Request0的ABCD不同那么就不要复用EFGH的缓存

时间 4：请求 0 完成并释放。块 2、3 和 4 按反向顺序添加到空闲队列（但块 2 和 3 仍被缓存）。块 0 和 1 未添加到空闲队列，因为它们正在被请求 1 使用

时间 5：请求 1 完成并释放。

时间 6：请求 2 到达，带有 29 个提示 token，其中前 12 个 token 与请求 0 相同。请注意，即使空闲队列中的块顺序是 7 - 8 - 9 - 4 - 3 - 2 - 6 - 5 - 1 - 0，缓存命中的块（即 0、1、2）在分配前会被触碰并从队列中移除，因此空闲队列变为 7 - 8 - 9 - 4 - 3 - 6 - 5。结果，分配的块是 0（已缓存）、1（已缓存）、2（已缓存）、7、8、9、4、3（已驱逐）。

总结

KVCache中几个核心的代码文件：1、 kv_cache_manager.py：对block进行分配（不过核心调度代码在 kv_cache_coordinator.py中），包括输入新的token去计算需要多少block、prefix cache使用；2、block_pool.py：创建blook池核心就是根据计算得到的num_blocks去计算分配多少全局管理的block： KVCacheBlock；3、gpu_model_runner.py：直接为模型的每一层去占用物理显存，并且对于占用的物理显存通过全局的 KVCacheBlock进行管理。
对于block pool想象成一个池子总共有num_blocks个每个池子只能存储 block_size个token，我提前对我模型中每一层都分配了一个 (K+V, num_blocks, block_size, num_kv_heads, head_size)大小的张量进行占用，所有物理块共享这块连续的 GPU 内存，通过 block_id 进行分页索引，在新的prompt输入时候计算需要分配池子数量 len(tokens)//block_size，而后会将所有的token都放到池子中，对于填满了的池子会用一个hash标记放到block hash中，新的输入时候，进行hash计算如果在block hash中有重复的直接复用（prefix cache过程），而在具体计算中就直接根据block需要去分配的层中进行索引，比如说某个prompt分配了[1,2]那么计算过程就是 (K+V, [2,3], block_size, num_kv_heads, head_size) 去复用kv cache。当prompt被解码之后，他的block会放到block pool中，而且cache还在，新的输入过来就去检查是不是有被计算过程直接复用！

参考

conda create -n vllm_server python=3.12
conda activate vllm_server
pip install vllm==0.17.1

首先看vllm中直接使用模型进行推理的过程：

from vllm import LLM, SamplingParams
# model_name 可以直接用本地模型地址
llm = LLM(model='Qwen/Qwen2-0.5B-Instruct', download_dir=cache_dir,...)
sampling_params = SamplingParams(temperature=0.8,...)
prompt_list = ['Please tell me how to acceralate the llm generate!']
outputs = llm.generate(prompt_list, sampling_params)

代码中直接通过LLM去初始化一个大模型而后再去使用generate进行生成，核心去看里面生成过程vllm中是如何处理的，整个过程的运行逻辑如下¹：

具体代码中，在generate中（函数涉及到多层的嵌套）模型输入prompt、采样参数等然后会将参数直接输入 _run_completion

def _run_completion(self, prompts, params,....):
    self._add_completion_requests(
        prompts=prompts,
        params=params,
        use_tqdm=use_tqdm,
        lora_request=lora_request,
        priority=priority,
        tokenization_kwargs=tokenization_kwargs,
    )
    return self._run_engine(use_tqdm=use_tqdm, output_type=output_type)

在上述函数中 _add_completion_requests以及 _run_engine 分别起到的作用是：将输入prompt进行processor进行处理而后向llm_engine添加一个request请求（self.llm_engine.add_request）、而后面以后就好理解就是直接进行模型输出，首先判断是不是有没有没有处理完的请求而后逐一的去对请求进行处理。
总结一下 generate 过程：prompt–>处理添加请求（_add_request）–>处理请求（_run_engine）。因此主要去看一下这两个过程是如何处理的

_add_request 过程

主要是将输入的prompt进行编码，然后对输入的prompt去打上id，告诉模型每一次处理的prompt的序号id，以及prompt所对应的采样参数。在代码中处理十分简单在代码中：

def add_request(self, request_id, prompt, params,...) -> str:
    ...
    if isinstance(prompt, EngineCoreRequest):
        ...
    else:
        request = self.input_processor.process_inputs(
            request_id,
            prompt,
            params,
            supported_tasks=self.get_supported_tasks(),
            arrival_time=arrival_time,
            lora_request=lora_request,
            tokenization_kwargs=tokenization_kwargs,
            trace_headers=trace_headers,
            priority=priority,
        )
        prompt_text, _, _ = extract_prompt_components(self.model_config, prompt)

    self.input_processor.assign_request_id(request)
    req_id = request.request_id
    params = request.params
    n = params.n if isinstance(params, SamplingParams) else 1
    if n == 1:
        self.output_processor.add_request(request, prompt_text, None, 0)
        self.engine_core.add_request(request)
        return req_id

    parent_req = ParentRequest(request)
    for idx in range(n):
        request_id, child_params = parent_req.get_child_info(idx)
        child_request = request if idx == n - 1 else copy(request)
        child_request.request_id = request_id
        child_request.sampling_params = child_params
        self.output_processor.add_request(
            child_request, prompt_text, parent_req, idx
        )
        self.engine_core.add_request(child_request)
    return req_id

过程比较简单调用 processor 去对输入进行编码转换为对应的token，对应request的结果为：

EngineCoreRequest(request_id='1', prompt_token_ids=[4340, 525, 575, 11319], mm_features=None, sampling_params=SamplingParams(n=1, presence_penalty=0.0, frequency_penalty=0.0, repetition_penalty=1.05, temperature=0.8, top_p=0.9, top_k=40, min_p=0.0, seed=None, stop=[], stop_token_ids=[151643], bad_words=[], include_stop_str_in_output=False, ignore_eos=False, max_tokens=20, min_tokens=0, logprobs=5, prompt_logprobs=None, skip_special_tokens=True, spaces_between_special_tokens=True, structured_outputs=None, extra_args=None), pooling_params=None, arrival_time=1773562288.0634456, lora_request=None, cache_salt=None, data_parallel_rank=None, prompt_embeds=None, client_index=0, current_wave=0, priority=0, trace_headers=None, resumable=False, external_req_id=None, reasoning_ended=None)

通过EngineCoreRequest进行包裹输出里面主要是请求id、采样参数、文本编码后的token等，也就是相当于每次去请求llm都会告诉模型我问了什么、我的输出参数是什么。除此之外在request中还有几个比较重要的参数：

vllm/v1/request.py

• 1、status

表示当前request的状态，具体有如下几种²：
WAITING：请求刚被创建，在等待队列中等待被调度器调度。这是所有请求的初始状态。
WAITING_FOR_FSM：当请求使用结构化输出功能时，需要等待有限状态机（FSM）编译完成。在此期间，请求处于此状态。
WAITING_FOR_STREAMING_REQ：对于流式输入（如分块传输的提示词），请求在等待下一个输入块时会进入此状态。
WAITING_FOR_REMOTE_KVS：在分离式推理（disaggregated prefill/decode）或KV缓存卸载场景中，请求需要等待远端传输KV缓存数据时，会进入此状态。
PREEMPTED：当KV缓存资源紧张时，调度器可能会抢占一个正在运行的请求，将其放回等待队列以腾出资源给其他请求。被抢占的请求进入此状态。
RUNNING：请求成功获得资源，正在GPU上执行（进行prefill或decode阶段）。这是请求被服务的核心阶段。
FINISHED_STOPPED：请求正常结束。可能的原因包括：生成了终止符（EOS token），或者匹配到了用户指定的stop词或stop token。
FINISHED_LENGTH_CAPPED：请求生成的token数量达到了用户设置的max_tokens限制，因此被停止。
FINISHED_ABORTED：请求被客户端主动取消或中断。
FINISHED_IGNORED：请求因内部错误或状态无效而终止。这通常意味着处理过程出现了异常。

• 2、数量指标

1、num_prompt_tokens：输入prompt的长度；2、num_output_placeholders：表示异步调度中预留但尚未生成的输出令牌占位符数量；3、num_tokens_with_spec：表示包含推测解码tokens数量计算过程：len(prompt_token_ids) + len(output_token_ids) + len(spec_token_ids)==prompt占用token数量+输出tokens数量+推测未来token数量；

_run_engine过程

先去看核心代码：

def _run_engine(...):
    ...
    outputs: list[_O] = []
    while self.llm_engine.has_unfinished_requests():
        step_outputs = self.llm_engine.step()
        for output in step_outputs:
            assert isinstance(output, output_type)
            if output.finished:
                outputs.append(output)
                ...
    return sorted(outputs, key=lambda x: int(x.request_id))

对于上面过程直接去使用 step()进行模型输出，在 step()过程中

llm_engine.step() 过程

具体代码处理过程，详细解释看代码：

# /vllm/v1/engine/llm_engine.py
def step(self) -> list[RequestOutput | PoolingRequestOutput]:
    if self.should_execute_dummy_batch:
        self.should_execute_dummy_batch = False
        self.engine_core.execute_dummy_batch()
        return []

    # 1、模型输出过程得到结果 从 EngineCore 获取模型输出
    with record_function_or_nullcontext("llm_engine step: get_output"):
        outputs = self.engine_core.get_output()

    # 2、将 EngineCore的原始输出进行process处理 把 EngineCore 的原始输出 → 加工成用户能看懂的输出
    with record_function_or_nullcontext("llm_engine step: process_outputs"):
        iteration_stats = IterationStats() if self.log_stats else None
        processed_outputs = self.output_processor.process_outputs(
            outputs.outputs,
            engine_core_timestamp=outputs.timestamp,
            iteration_stats=iteration_stats,
        )
        self.output_processor.update_scheduler_stats(outputs.scheduler_stats)

    # 处理因 stop strings 命中而需要立即中止的请求
    with record_function_or_nullcontext("llm_engine step: abort_requests"):
        self.engine_core.abort_requests(processed_outputs.reqs_to_abort)

    # 记录统计信息（logging / metrics / tracing）
    with record_function_or_nullcontext("llm_engine step: record_stats"):
        if (
            self.logger_manager is not None
            and outputs.scheduler_stats is not None
            and len(outputs.outputs) > 0
        ):
            self.logger_manager.record(
                scheduler_stats=outputs.scheduler_stats,
                iteration_stats=iteration_stats,
                mm_cache_stats=self.renderer.stat_mm_cache(),
            )
            self.do_log_stats_with_interval()

    return processed_outputs.request_outputs

在上面过程中主要有4个过过程中不同过程模型输出内容：

EngineCoreOutputs(engine_index=0, 
outputs=[EngineCoreOutput(request_id='1-aadc7e9e', 
new_token_ids=[99882], 
new_logprobs=LogprobsLists(logprob_token_ids=array([[ 99882,  18493,  99882,  20412, 106789, 105792]], dtype=int32), 
logprobs=array([[-1.2735124, -1.2065492, -1.2735124, -1.9096742, -2.8471742,-2.8471742]], dtype=float32), ...)

1、模型输出过程得到结果：这个过程主要是去输出prompt后的第一个token，对于这部分结果中关注点在于logprob_token_ids、logprobs、new_token_ids分别表示我的模型输出的token以及对应的概率以及我的第一个输出token的id（直接从最大的概率进行解码输出即可）；

OutputProcessorOutput(
request_outputs=[RequestOutput(request_id=1, 
prompt='你是谁？', 
prompt_token_ids=[105043, 100165, 11319], 
encoder_prompt=None, encoder_prompt_token_ids=None, prompt_logprobs=None, 
outputs=[
CompletionOutput(index=0, 
text='我叫“小鱼”，我来自海底，我是海里的小鱼，我的小家叫', 
token_ids=[35946, 99882, 2073, 30709, 100655, 33590, 35946, 101919, 112002, 3837, 104198, 55135, 102073, 30709, 100655, 3837, 97611, 30709, 45629, 99882], 
routed_experts=None, cumulative_logprob=-35.836418479681015, 
logprobs=[
{35946: Logprob(logprob=-1.362297773361206, rank=1, decoded_token='我'),...}
{99882: Logprob(logprob=-0.3063066303730011, rank=1, decoded_token='叫'), ...}]

2、将 EngineCore的原始输出进行process处理：这个过程中主要是去看CompletionOutput部分内容，里面的token_ids表示的是从 prompt 之后开始的所有已生成 token id，而在logprobs中则是每一次生成词的概率，而后根据你采样的方式去选择输出。
上面过程知识模型“单步执行”的外层循环，但是有一个新的问题，比如说我的模型这一次直接输入了1w组prompt对于这些在vllm中是如何去处理呢？如何控制处理顺序呢？用下面图片来解释为什么要用调度器（下图过程是基于v0的，注意只是简单介绍一下调度器是工作过程的）：

调度器处理过程

在调度器中vllm有两块定义：1、vllm/v1/core/sched/scheduler.py；2、vllm/v1/core/sched/async_scheduler.py。这两部分调度器，后者直接继承前者并且作异步处理，具体使用何种调度器在参数定义 SchedulerConfig中可以使用 （vllm/config/scheduler.py）如果要具体使用何种采样器可以直接指定参数： async_scheduling=True/False 或者在启动server中使用参数 --no-async-scheduling。以 cheduler.py 出发分析其主要功能，在最开始的代码 add_request 中我将我的prompt都已经编码完毕，而后就是对编码后的内容进行处理，在代码中主要有两个队列负责request管理：1、waiting；2、running；这两部分都是python的deque()实例（双端队列，允许你从队列两侧添加或删除元素）

waiting 队列处理过程

对于编码后的所有的request 会直接都存储到 self.waiting 中而后在 waiting 队列中解析遍历内容写入 running 队列中进行执行，因此会从 waiting 中去拿出存储到request中那么代码过程为（主体框架，具体每一部分都在下面其他小的内容中描述）：

while self.waiting and token_budget > 0:
    if len(self.running) == self.max_num_running_reqs:
        break
    request = self.waiting.peek_request()
    request_id = request.request_id
    
    """"""""""""""""""""""""""""""
    # 第一步：对 request 状态进行检查
    """"""""""""""""""""""""""""""

    num_external_computed_tokens = 0
    load_kv_async = False
    connector_prefix_cache_queries, connector_prefix_cache_hits = 0, 0
    
    """""""""""""""""""""""""""""
    # 第二步：得到已经计算的tokens数量
    """""""""""""""""""""""""""""
    
    """""""""""""""""""""""""""""
    # 第三步：开始计算本次要为这个请求新增计算/生成的 tokens 数量
    """""""""""""""""""""""""""""
    
    """""""""""""""""""""""""""""
    # 第四步：开始计算需要缓存的 new_blocks
    """""""""""""""""""""""""""""  
      

对于上述waiting队列处理过程总结如下：首先在while大循环下确定waiting非空以及token_budget还有空余，而后从waiting中取出request，1、去判断request的状态情况，主要是判断这三类：

if request.status == RequestStatus.WAITING_FOR_REMOTE_KVS:...
if request.status == RequestStatus.WAITING_FOR_FSM:...
if request.status == RequestStatus.WAITING_FOR_STREAMING_REQ:...

在完成对request状态判断完毕之后2、得到已经计算的tokens数量，首先去判断request是不是以已经有过计算的tokens，如果没有（request没有被处理）就需要先去计算本地缓存（num_new_local_computed_tokens，先不去管缓存是怎么处理的分配的），以及从connector获取外部缓存（num_external_computed_tokens），最后计算得到 num_computed_tokens = num_new_local_computed_tokens + num_external_computed_tokens。之所以这样是因为：大模型生成过程是 prefill（编码prompt）+decode（正式生成），如果最开始我的token在我的block中已经被缓存了那么可以直接拿出进行复用（可以理解为prompt中有被处理过的token）

if request.num_computed_tokens == 0:
  # 本地缓存（本机 KV Cache Manager）
  new_computed_blocks, num_new_local_computed_tokens = self.kv_cache_manager.get_computed_blocks(request)
  # 外部缓存（通过 KVConnector，例如分布式 KV 转移、SharedStorage、LMCache、Offloading 等）
  if self.connector is not None:
    ext_tokens, load_kv_async = self.connector.get_num_new_matched_tokens(request, num_new_local_computed_tokens)
        
    request.num_external_computed_tokens = ext_tokens
    num_external_computed_tokens = ext_tokens
        
  num_computed_tokens = num_new_local_computed_tokens + num_external_computed_tokens
else:
   new_computed_blocks = self.kv_cache_manager.empty_kv_cache_blocks
   num_new_local_computed_tokens = 0
   num_computed_tokens = request.num_computed_tokens

在得到需要计算的tokens之后 3、去计算本地需要生成多少tokens，在上一步中得到这个request已经被计算的tokens数量，那么就需要计算本次还需要新计算/处理的 token 数量。在request.num_tokens表示的是当前总共拥有的 token 数量（prompt + 已经生成的 output tokens）

if load_kv_async:
  assert num_external_computed_tokens > 0
  num_new_tokens = 0
else:
  num_new_tokens = request.num_tokens - num_computed_tokens
  threshold = self.scheduler_config.long_prefill_token_threshold
  if 0 < threshold < num_new_tokens:
    num_new_tokens = threshold

第二步中查找前缀缓存命中（Prefix Cache Hit），确定“这个请求已经有哪一部分 KV 可以直接复用，不需要重新计算”，第三步中则是决定本次调度循环实际要处理多少新 tokens（num_new_tokens）

在得到本地需要生成新的token之后就需要 4、计算这些新的需要计算的token需要计算的block数量

new_blocks = self.kv_cache_manager.allocate_slots(
    request,
    num_new_tokens,
    num_new_computed_tokens=num_new_local_computed_tokens,
    new_computed_blocks=new_computed_blocks,
    num_lookahead_tokens=effective_lookahead_tokens,
    num_external_computed_tokens=num_external_computed_tokens,
    delay_cache_blocks=load_kv_async,
    num_encoder_tokens=num_encoder_tokens,
)

在得到需要计算的blocks之后就是将 5、waiting队列中内容加入到running队列中去进行计算了

request = self.waiting.pop_request()
if load_kv_async:
    # If loading async, allocate memory and put request
    # into the WAITING_FOR_REMOTE_KV state.
    skipped_waiting_requests.prepend_request(request)
    request.status = RequestStatus.WAITING_FOR_REMOTE_KVS
    continue

self.running.append(request)

总结一下 waiting 队列处理过程：1、取出一条request，去判断当前这条request的状态；2、计算当前request有多少token是被计算的（因为llm生成是 prefill+deocde），如果远程缓存中有了直接用远程缓存；3、计算需要新计算的tokens数量；4、对新的计算的tokens去分配block；5、加入到running中。对于waiting中几个关键参数设置如下：
1、token_budget：代表本次Step可处理的“新 Token 总数上限”。该参数在每次调度开始时都会根据 max_num_batched_tokens 进行初始化重置，用于约束本轮迭代的计算规模，防止单次推理耗时过长或显存溢出。

其具体消耗过程在每次step中优先被用于running（decode）使用，当所有的在running中prompt的被decode 处理完毕之后（也就是解码完毕）还有剩余的就回去waiting队列中去取prompt进行prefill。通过这样并行就会让vllm效率高处理快

2、long_prefill_token_threshold：如果一个 waiting 请求的 prompt 超长（> threshold），就强制切成小块，防止它一次性吃掉整个 token_budget，导致其他请求饿死。对应参数 long_prefill_token_threshold=1024
3、enable_prefix_caching：开始prefix缓存复用
4、max_num_seqs：最大并发数

简单列子解释调度过程
假如 request=[R1, R2] 分别都有3000和1000个tokens，我的参数配置是max_num_batched_tokens=2048（对应token_budget）、long_prefill_token_threshold=1024（最长处理1024长的prompt 对应long_prefill_token_threshold）、max_new_tokens=100（最大生成200个新的toknes假设没有eos去终止生成）

在最开始中R1是不够的因此需要被切分到最长内容（1024）而后R2去使用剩下的（1024）刚刚好满足1000token就会剩余24，那么下次调度过程中就会生成新的token_budge而后依次类推，只有当prompt的token完全被吃下之后才会去解码生成！一个更加极端情况，如果token_budge设置为1024，那么只有当先进的prompt被吃完才会去处理下一个prompt（此时先进的prompt就会在running队列中）。因此为了加速vllm过程可以适当的加大token_budge参数让其可以吃的更多。

running 队列处理过程

区别waiting需要不断调度请求，running相对比较简单，只需要将request进行block管理即可，整体过程如下

req_index = 0
while req_index < len(self.running) and token_budget > 0:
    request = self.running[req_index]
    """"""""""""""""""""""""""""""
    # 第一步、计算需要生成多少新的tokens
    """"""""""""""""""""""""""""""

    """"""""""""""""""""""""""""""
    # 第二步、进行资源抢占
    """"""""""""""""""""""""""""""

    """"""""""""""""""""""""""""""
    # 第三步、“执行”模型进行处理
    """"""""""""""""""""""""""""""

在读取得到新的请求之后，1、先去计算需要生成多少新的tokens（对应计算num_new_tokens）这个过程主要是如下（具体解释看代码）：

if (request.num_output_placeholders > 0 and request.num_computed_tokens + 2 - request.num_output_placeholders>= request.num_prompt_tokens + request.max_tokens
):
    req_index += 1
    continue
#  总tokens+ 异步预留tokens- 已经计算的tokens 就得到需要新生成tokens
num_new_tokens = (request.num_tokens_with_spec # 对于这个值一般就是对于 prompt tokens数量
                  + request.num_output_placeholders # 一般在 prefill 阶段是0 进入decoding阶段之后就是 1
                  - request.num_computed_tokens # 被计算的tokens
                  ) 
# 避免 prompt 过长直接全部占满
if 0 < self.scheduler_config.long_prefill_token_threshold < num_new_tokens:
    num_new_tokens = self.scheduler_config.long_prefill_token_threshold
# 依次调度中 只能生成 token_budge 
num_new_tokens = min(num_new_tokens, token_budget)
num_new_tokens = min(num_new_tokens, self.max_model_len - 1 - request.num_computed_tokens)

# 这块主要是处理多模态模型中token它在计算这一步要处理多少文本 Token 的同时，检查是否有“多模态数据（图像/视频/音频）”挡在路中间。如果有，就先分配计算资源给 Encoder（视觉/音频编码器）去处理这些输入。
if request.has_encoder_inputs:
    (encoder_inputs_to_schedule,num_new_tokens,new_encoder_compute_budget,external_load_encoder_input,) = self._try_schedule_encoder_inputs(request,request.num_computed_tokens,num_new_tokens,encoder_compute_budget,shift_computed_tokens=1 if self.use_eagle else 0,
    )

估算需要新生成多tokens，除此之外还需要报错新生成tokens数量不能超过token_budge。在得到需要新生成tokens之后，2、进行资源的抢占，知道需要新生成的tokens数量之后，显卡不一定能够吃下这么多的tokens，就需要进行资源抢占

with record_function_or_nullcontext("schedule: allocate_slots"):
    while True:
        new_blocks = self.kv_cache_manager.allocate_slots(request,num_new_tokens,num_lookahead_tokens=self.num_lookahead_tokens,)

        if new_blocks is not None:
            break
        # 优先级策略
        if self.policy == SchedulingPolicy.PRIORITY:
            preempted_req = max(self.running, key=lambda r: (r.priority, r.arrival_time),)
            self.running.remove(preempted_req)
            if preempted_req in scheduled_running_reqs:
                preempted_req_id = preempted_req.request_id
                scheduled_running_reqs.remove(preempted_req)
                token_budget += num_scheduled_tokens.pop(preempted_req_id)
                req_to_new_blocks.pop(preempted_req_id)
                scheduled_spec_decode_tokens.pop(preempted_req_id, None)
                preempted_encoder_inputs = scheduled_encoder_inputs.pop(
                    preempted_req_id, None
                )
                if preempted_encoder_inputs:
                    num_embeds_to_restore = sum(
                        preempted_req.get_num_encoder_embeds(i)
                        for i in preempted_encoder_inputs
                    )
                    encoder_compute_budget += num_embeds_to_restore
                req_index -= 1
        else:
            # 直接末尾踢掉
            preempted_req = self.running.pop()

        self._preempt_request(preempted_req, scheduled_timestamp)
        preempted_reqs.append(preempted_req)
        if preempted_req == request:
            break

对于资源抢占过程中，首先通过kv_cache_manager去计算对于request以及nun_new_tokens需要多少block，如果显卡还有显存，那么就直接给他分配，如果显存不过就需要进行资源抢占，1、PRIORITY（优先级策略）：直接找到running中队列中 优先级最低 且 到达时间最晚 的请求。 preempted_req = max(self.running, key=lambda r: (r.priority, r.arrival_time),)直接将他踢掉，而后释放这个request占用的 token_budget；2、直接踢掉末尾。在获取需要踢掉的request之后self._preempt_request去释放kv_cache、编码显存占用、重置状态为PREEMPTED将其放到waiting中。通过第一、二步计算了模型的新生成的tokens数量，并且根据这些数量对资源进行抢占，那么 3、调用模型“执行”，并非真的执行，前面两步拿到了模型整个过程中所有的需要的资源，就带着这些资源给模型进行执行。

# 首先将 request 加到 需要running “名单” 并且扣除 token预算
scheduled_running_reqs.append(request)
request_id = request.request_id
req_to_new_blocks[request_id] = new_blocks
num_scheduled_tokens[request_id] = num_new_tokens
token_budget -= num_new_tokens
req_index += 1
# 计算 在这一步分配的 Token 中，有多少是真正用于“推测”
if request.spec_token_ids:
    num_scheduled_spec_tokens = (
        num_new_tokens
        + request.num_computed_tokens
        - request.num_tokens
        - request.num_output_placeholders
    )

简单总结一下running过程：1、确定需要处理多少新的tokens，一般计算过程：总tokens数量（prompt的token数量+生成token数量，在prefill阶段没有生成那么就等于prompt长度，后续decoding阶段有生成就会增加这个数值）+预占用token数量（prefill阶段==0，decoding阶段==1）-已经处理的tokens数量，然后还需要将其控制在 token_budge下不能超过他；2、而后进行资源抢占，如果计算的 新生成的token可以满足显存分配，那么就为其分配，如果不满足就直接：1、踢出running队列中末尾的请求；2、或者提出优先级最低、时间最晚的请求。在确定好之后就需要将 剔除的资源进行释放；3、拿着前面两步内容去下一步让模型进行输出。

总结

llm生成过程中主要是prefill（编码prompt）+decode（解码输出），在调度过程中总结就是：先进先处理（对于先进入的request会一直占用直到被prefill完毕后才会给下一个prompt进行处理），run优先并行处理（进入running优先使用token预算，剩下预算的给下一个prompt进行prefill或者decode）。里面每次处理都会使用token预算（对应参数 max_num_batched_tokens），本次调度token预算用完进行下一次，并且调度值有限被running处理。
几个核心参数：
1、token_budget：代表本次Step可处理的“新 Token 总数上限”。该参数在每次调度开始时都会根据 max_num_batched_tokens 进行初始化重置，用于约束本轮迭代的计算规模，防止单次推理耗时过长或显存溢出。
2、long_prefill_token_threshold：如果一个 waiting 请求的 prompt 超长（> threshold），就强制切成小块，防止它一次性吃掉整个 token_budget，导致其他请求饿死。对应参数 long_prefill_token_threshold=1024
3、enable_prefix_caching：开始prefix缓存复用
4、max_num_seqs：最大并发数
5、num_prompt_tokens：输入prompt的长度；
6、num_output_placeholders：表示异步调度中预留但尚未生成的输出令牌占位符数量；
7、num_tokens_with_spec：表示包含推测解码tokens数量计算过程：len(prompt_token_ids) + len(output_token_ids) + len(spec_token_ids)==prompt占用token数量+输出tokens数量+推测未来token数量；

参考

FireRED OCR

OCR¹模型主要是对Qwen3-vl进行微调的一个模型，因此主要了解一下其数据构建过程以及其训练思路即可，因此对于其模型 数据构建过程中：

对数据进行聚类处理（筛选去重），直接通过轻量的ResNet/Vit对图像进行编码而后通过聚类算法（KNN等）去筛选出相似度高的、保留长尾数据（如表格等）；数据分类、这部分主要是对数据的语言类型、布局、数据来源（PDF、扫描件等）进行分类保证数据类别的分布；数据清洗：这部分主要是对数据进行识别（比如说有些数据可能只有图像）就需要使用PaddleOCR-VL进行识别、合成数据（通过提前设计好html/css模板去合成表格等数据）、还有一些内容就直接通过大模型去判断最后标签是不是有效的，比如说对于识别失败的，直接用llm判断markdown中格式不是都正确是不是有缺失，并且进行修复，判断图像是不是“好的”没有质量太低的（直接丢弃）

模型训练过程不是直接SFT+RL而是在此之前先去给模型赋予“文档”识别能力（可能基于Qwen3-VL非专门的OCR模型因此先去强化OCR中主要的3类任务能力，减轻后续SFT、RL难度）：第一阶段赋予模型文档识别能力：主要是对文档中进行多任务的微调包含如下3组任务：目标检测以及OCR、特定区域OCR（主要是通过提供prompt去识别对应区域内容）、页面转换（将布局转换为Markdown内容）；第二阶段监督微调：这部分数据相对去第一部分中的数学质量更加高，比如说转化公式严格满足和markdown保持一致，文档的种类更加丰富。第三阶段GRPO强化学习（主要是争对模型最后输出内容的格式），对于GRPO中奖励函数主要对4类内容进行打分：数学公式评分（直接通过Latex解析器处理数学公式如果失败处理记分-1，成功则是按照公式复杂度进行评分）、表格完整性评分（检查行/列是否一致及1或0）、文本准确性评分（计算文本之间Levenshtein distance，这个距离主要是计算从A–>B字符串需要进行多少次计算）、层级闭合（主要是记录标签是否闭合，比如html中 tag 之间）。最后对上面4类进行加权即为最后奖励值。

对于训练过程可以总结为：粗–>细–>强化

FireRED Edit

模型²结构如下（还是对qwen-image-edit做的微调，那么qwen-image-edit的lora也可以直接拿来用）

对于训练过程中，输入数据处理过程主要是对数据进行分桶保证显卡最大利用：计算batch的总视觉token数量尽量接近某个固定值C，而后在一个桶里面找一个最合适的分辨率（$\text{argmin}\sum \vert (H_iW_i-hw \vert)$ 小的hw为桶的尺寸）保证尺寸一致。image-text打乱处理，比如说交换Fig位置对应文本中位置也发生改变、随机丢弃图像文本也对应丢弃描述。

分桶后，训练过程一般优先从相同bucket中挑选样本组成batch；当bucket内样本不足batch_size时，会通过设置repeat参数（重复次数）来虚拟扩充样本量，从而保证训练能稳定、连续地进行，而不会频繁丢弃不完整batch。

模型训练策略：将VLM部分视觉提取特征提前处理好存储在本地避免训练过程中再计算、FSDP（梯度优化器状态切分放到节约显存）

模型训练分为5个阶段，每个阶段数据质量是越来越高的，主要看里面的DPO以及NFT处理过程。首先DPO过程，作者训练过程中发现对于Win以及Lose都会发生上升（也就是选择“好”以及选择“坏”的概率都在上升）：
\(\mathcal{L}_{\text {Ours }}=-\mathbb{E}_{\left(c, x_{w}, x_{l}\right) \sim \mathcal{D}}[\log \sigma(\beta[\underbrace{\left(\mathcal{L}_{l}^{\theta}-\mathcal{L}_{l}^{\text {ref }}\right)}_{\text {Lose Diff }}-\omega \cdot \underbrace{\left(\mathcal{L}_{w}^{\theta}-\mathcal{L}_{w}^{\text {ref }}\right)}_{\text {Win Diff }}])-\lambda \mathcal{L}_{w}^{\theta}]\)
对比普通的DPO就是将择优以及避坏都用不同参数而非相同的参数进行控制（$\beta$ 以及 $w$）。使用 DiffusionNFT优化策略，在DPO中需要成对的数据进行训练而DiffusionNFT³模型自己生成图片，然后通过一个奖励模型给这张图打分，这个分数被转化为最优概率 $r \in [0, 1]$
\(\mathcal{L}_{\mathrm{NFT}}=\mathbb{E}_{t, x_{0} \sim \pi^{\mathrm{old}}}[r \underbrace{\left\|v_{\theta}^{+}\left(x_{t}, t\right)-v\right\|^{2}}_{\text {Positive Match }}+(1-r) \underbrace{\left\|v_{\theta}^{-}\left(x_{t}, t\right)-v\right\|^{2}}_{\text {Negative Match }}]\)
对于里面奖励函数评分主要是两个：1、Fine-grained Logit-Weighted Ensembling Reward：一般RL过程中奖励值一般是离散的也就是1-5，论文里面做法让 reward model 先写 CoT 推理，然后只看它对[1,2,3,4,5]这几个数字 token 的 logits（具体过程：输入一张图像，先通过VLM输出COT回答最后给出评分，因为LLM生成token会在1-5每个数字都生成一个概率然后选择最大概率最为模型输出，因此我在llm输出数字时候变相的得到了1-5这几个数字的概率），用 softmax 做软概率加权平均，得到一个 [1.0～5.0] 区间内的连续软分数 → 再 ensemble 多条推理路径取平均 → 得到最终奖励 R；2、Layout-Aware OCR-based Reward：这个奖励函数主要是针对文字生成进行优化处理同时考虑文字的生成以及文字的布局是否准确；
一致性损失主要是为了保证训练过程中图像不“崩溃”（解噪过程中前期生成“轮廓”，后期生成“细节”，这个过程主要是保证细节不崩溃，如人脸改变等）
\(\mathcal{L}_{id} = \frac{1}{N} \sum_{i=1}^{N} \left( 1 - \frac{\phi(\mathcal{T}_i(x_0)) \cdot \phi(\mathcal{T}_i(x_{gt}))}{\|\phi(\mathcal{T}_i(x_0))\|_2 \cdot \|\phi(\mathcal{T}_i(x_{gt}))\|_2} \right)\)
里面的 $x_0$表示的是直接一步生成结果（之所以不用最后结果是因为你最后生成图像整个图像信息已经被确定了，如果对中间过程进行改进最后图像也会发生改进）

参考

熵坍缩

按照论文¹里面对于熵的定义

上面公式中 $\pi_\theta$ 以及 $\mathbf{D}$ 分别表示policy model（一般可以直接简单理解为我们需要优化的模型）以及数据集，对于熵值高低往往也就意味着模型输出的“不确定性”，高熵意味着模型可以尝试多种可能性，熵则意味着模型倾向于选择那些确定性的动作。在论文中¹在实验中经常会发现，在训练的初期，Policy Entropy会迅速下降到接近0（如下图左侧图深蓝色线所示），模型变得过于确定，不再尝试新路径，这会导致模型的效果达到瓶颈，上升停滞。毕竟，强化学习之所以能够生效，全都依赖于模型的输出具有多样性，每次的输出和reward都是不一样的；假如模型的输出每次都是一样的，那么强化学习就失去了意义，因此就会出现后期的准确率基本保持不变的情况也就是所谓的熵坍缩（entropy collapse）

机制分析

对于之所以会发生熵坍缩问题先说结论：单步熵变化 $ΔH ≈ −η ⋅ Cov[log π(a|s), A(s,a)]$，而该协方差在实践中结构性恒正。因为SFT之后模型默认输出高概率token，reward model 倾向给当前高概率的输出打高分最后导致恒正。
对于上述问题之所以发生在论文里面对于连续两步中熵的变化为：

上面公式中 $z_{s,a}^{k+1}- z_{s,a}^{k}$ 表示的是两步之间的输出差异，在梯度优化过程中 $z_{s,a}^{k+1}- z_{s,a}^{k}=-\eta \nabla_z J(\theta)$ 其中 $J(\theta)$ 表示优化目标（对应损失函数） $\eta$ 表示学习率，对于该等式可以证明得到 $z_{s,a}^{k+1}- z_{s,a}^{k}=-\eta \pi_{\theta}(a\vert s)A(s,a)$

那么将该式代入最上面等式中就可以得到：
\(\mathcal{H}\left(\pi_{\theta}^{k+1} \mid s\right)-\mathcal{H}\left(\pi_{\theta}^{k} \mid s\right) ≈-\eta \cdot \operatorname{Cov}_{a \sim \pi_{\theta}^{k}(\cdot \mid s)}(\log \pi_{\theta}^k(a|s),A(s,a))\)
对于上述公式中也就是证明了动作概率与对应的优势值之间相关性，如果正相关那么就会导致最后熵值的不断下降。

• 当 Cov > 0 时 → ΔH < 0 → 熵下降（policy 变得更确定）
• 当 Cov < 0 时 → ΔH > 0 → 熵上升（增加探索性）
• Cov = 0 → 熵基本不变（理想但极少出现的中性状态）

Cov[log π(a|s), A(s,a)] > 0 的含义：当前 policy 认为高概率概率的动作（log π 较大），在当前训练 batch 中也倾向于获得更高的优势估计 A（正相关）。反之，低概率动作即使偶尔拿到高 A，其对协方差的贡献也很微弱（因为采样权重 π(a) 本身极小）。而在训练过程中协方差几乎恒正，因为SFT 后模型“默认”倾向输出高概率 token → 这些 token 在 reward 眼中也“默认”较优 → 正相关 → 每步更新都系统性地压缩分布 → 熵单向坍缩。

左图：熵变化和协方差之间变化，也就证明了协方差增加导致熵下降；右图：按 prompt 难度分组的协方差分布Easy prompt（准确率高）：协方差大；Hard prompt（准确率低）：协方差小甚至为负；这说明：对容易任务，策略强化了已有倾向（熵下降）；对困难任务，模型更不确定（熵保持或上升）

解决措施

DAPO

按照论文²中介绍方法

在GRPO中对于 $\epsilon$ 一般默认就是0.2，而DAPO中直接设置两个超参数 $\epsilon_{low}$ 以及 $\epsilon_{high}$ 论文里面选择是0.2以及0.28，之所以使用该方法可以一定程度缓解问题是因为：增大上边界让低概率的tokens能够不被“压制”鼓励其输出，但是增大下边界可能导致采样空间的崩溃。之所以增大上边界影响分析如下：在最上面分析熵坍缩原因中因为模型更加“偏爱”输出高概率token导致坍缩问题，那么在DAPO中直接鼓励模型去输出低概率token去弱化相关性，增加上边界可以鼓励模型去输出低概率值。直观解释，比如说在模型输出过程中 $\pi_{\theta}(o_i\vert q)$ 在输出若干个token之后，比如说输出两个词：好（对应模型高概率值假设0.9）、呀（对应低概率值假设0.1），在裁剪过程中低概率的token上限就是1.2那么对应就是：1.2x0.1=0.012那么在后续不断优化过程中（比如说10步）得到结果就是 $0.1\times 1.2^5=0.249$ 如果增加上边界那么对应 $0.1\times 1.8^5=1.889$之间差距还是明显随着后续步数迭代这些低概率token就会有“表现”机会。
实际代码操作中以GRPO训练为例只需要在参数中指定GRPOConfig(epsilon_low=0.1, epsilon_high=0.3)

动态温度调度

按照论文³里描述在输出token中平均熵最高的词元通常起到“分叉”的作用，从而决定推理方向；而平均熵最低的词元则倾向于沿着既定路径执行推理步骤。

高熵Token（分岔点，”forking tokens” ）主要是逻辑连接词（however, thus, because）、假设词（suppose, assume, given）、修正词（wait, unless）。它们在推理路径上充当决策点。比如，模型在说”however”时，它可能在犹豫是继续当前思路还是转向反方观点。在说这些词的时候，推理就可以有多个不同的发展方向，所以模型在生成它们时很不确定，因此这些token是High Entropy的。低熵Token主要是词缀（如ing, ed）、代码片段、数学表达式的固定部分（如括号、等号）。这些表述是机械性的、高度可预测的。
因此解决熵坍缩问题里面就可以直接对于高熵token用较高的temperature去进行采样鼓励模型去输出这些高熵token，除此之外在论文里面还做了一个额外实验：只在高熵（选择20%的高熵token）token上计算policy gradient对于低熵的token梯度直接丢弃，最后得到优化效果发现丢弃token效果比使用全部token的效果要好。

实际代码操作中以GRPO训练为例只需要在参数中指定GRPOConfig(top_entropy_quantile=0.2)即可（2/8法则）实现丢弃部分token。参数具体解释：top_entropy_quantile（浮点数，可选，默认为 1.0）来自超越 80/20 规则的 ρ 参数。在策略损失项中只保留每个序列位置上的代币概率分布熵的 top-ρ 量化值，从而改善结果。范围： [0.0-1.0]。0.0的值会屏蔽除最高熵标记外的所有标记；1.0 会保留所有标记。如果与 mask_truncated_completions=True 一起使用，则只考虑来自非截断序列的标记。

奖励坍缩

奖励坍缩（reward collapse）：比如说在GRPO优化过程中在多奖励设置下，GRPO的group-wise normalization（组内归一化）会把不同奖励组合压缩成几乎相同的advantage（优势值），导致训练信号分辨率大幅下降。简单来说，当多个奖励信号被组合后，它们的相对差异被”抹平”了，模型无法有效区分哪些行为是真正更好的。这就像把不同颜色的颜料混合在一起，最终只剩下一种模糊的灰色，导致训练信号丢失。
比如说对于prompt产生的4组回答，我需要分别取评估回答格式是否正确、回答内容是否正确得到：A（1，1）；B（1，0）；C（0，1）；D（0，0）按照GRPO中计算有优势值方法：$A_i=\frac{r_i- \text{mean}(r_1,…,r_G)}{\text{std}(r_1,…,r_G)}$ 在对BC计算优势值发现两部分优势值是相等的，但是实际上B回答正确格式错误而C格式正确回答错误，最后优势值只会告诉模型两部分相同（在奖励曲线上一般是先去上升后续出现断崖下降）。

解决措施

GDPO

在论文⁴里面先对每个奖励分量独立组内标准化（得到每个分量的 normalized scalar），然后加权求和这些 normalized 值 → 最终 $ \hat{A}_i^{\text{GDPO}}$

比如说在下面例子中：

比如说在上面计算中在GRPO例子AD优势幅度完全对称（只是正负相反），模型很难学到“正确性比格式更重要”的信号。在GRPO（权重2：1）中A 和 D 的差距被极大放大：+2.683 vs -2.683（幅度翻倍）。模型能更强烈地学习到“优先追求高正确性，即使牺牲一些格式”，而 GRPO 中这个倾向非常弱。

# line 1254 in NVlabs/GDPO/trl-GDPO/trl-0.18.0-gdpo/trl/trainer/grpo_trainer.py
# Gather the reward per function: this part is crucial, because the rewards are normalized per group and the
# completions may be distributed across processes
rewards_per_func = gather(rewards_per_func)
rewards = (rewards_per_func * self.reward_weights.to(device).unsqueeze(0)).nansum(dim=1)

# Compute grouped-wise rewards
mean_grouped_rewards = rewards.view(-1, self.num_generations).mean(dim=1)
std_grouped_rewards = rewards.view(-1, self.num_generations).std(dim=1)
is_std_zero = torch.isclose(std_grouped_rewards, torch.zeros_like(std_grouped_rewards))

# Normalize the rewards to compute the advantages
mean_grouped_rewards = mean_grouped_rewards.repeat_interleave(self.num_generations, dim=0)
std_grouped_rewards = std_grouped_rewards.repeat_interleave(self.num_generations, dim=0)
advantages = rewards - mean_grouped_rewards
if self.scale_rewards:
    advantages = advantages / (std_grouped_rewards + 1e-4)

参考

简单回顾LLM训练过程

在Blog里面讨论过LLM框架这里简单讨论一下LLM训练过程，一般而言在LLM中训练主要分为如下几个阶段：1、预训练阶段：这部分简单理解就是让LLM能够说“人话”，自回归模型通过前一段文本然后预测下一个文本，并且让模型能够较好的“说话”（比如说：大语言模，下一个字可以正确输出 “型”）；2、后训练阶段：在得到一个能够说人话的模型之后，就需要让模型能够“思考”，这部分主要分为两部分：1、监督微调（SFT Supervised Training）；2、人类反馈强化学习（RLHF Reinforcement Learning from Human Feedback）。前者：顾名思义，我们首先使用监督学习方法，在少量高质量的专家推理数据上对 LLM 进行微调，例如指令跟踪、问题解答和/或思维链。希望在训练阶段结束时，模型已经学会如何模仿专家演示。后者：RLHF 利用人类反馈来训练奖励模型，然后通过 RL 引导 LLM 学习。这就使模型与人类的细微偏好保持一致。对于SFT以及RL两者之间差异可以简单理解为：SFT是模型对数据的“拟合”因为SFT过程中一般就是让模型输出去贴近我的数据集，而RL更加像模型对问题探索

DPO

DPO直接根据人类偏好数据对模型进行微调，使其生成更符合人类期望的输出，损失函数为：

其中：
$\pi_{\theta}$：当前优化的语言模型（策略模型，实际应用可能就是添加Lora的模型）。
$\pi_{\text{ref}}$：参考模型，通常是监督微调后的模型（或者就是原始模型，亦或者更加强大的模型），用于稳定训练。
$\sigma$：Sigmoid 函数，将偏好分数映射到 (0, 1)。
$\beta$：一个超参数，控制偏好强度的缩放（通常取值在 0.1 到 1 之间）。
$y_c,y_r$：优选和劣选回答。
$\mathcal{D}$：偏好数据集。

DPO 优化过程

直观理解上面过程，DPO模型是一种纯粹数据驱动的训练范式，比如说下面例子：

模型的优化目标就是需要让 我们的模型生成更加倾向生成Good answer 并且降低生成Bad answer的概率。假设存在数据集$\mathcal{D}=(\text{Prompt}, \text{GoodAnswer}, \text{BadAnswer})$（简化为：$D=(x, y_c, y_r)$）；模型：$\pi_{\theta}$、$\pi_{\text{ref}}$。损失函数为：

那么DPO处理过程为：
第一步进行数据准备与拼接。将输入数据通过tokenizer处理然后进行拼接得到两个输入队列： $[x,y_w]$ 以及 $[x,y_l]$
第二步前向计算 log-probabilities（只计算回答部分的 token 概率）。分别将两个序列输入 $\pi_\theta$ 和 $\pi_{\rm ref}$，得到 logitsq（(batch_size, seq_len, vocab_size)）。比如说对于chosen 序列：模型的输入长度为：$|x| + |y_w|$，模型输出 logits直接通过 logits = model(input_ids_chosen).logits 形状：$(1, |x|+|y_w|, V)$，只需要回答部分的 log-prob（log_probs = log_softmax(logits, dim=-1)），即从第 $|x|$ 个位置开始（注意：自回归模型中，第 $|x|$ 个 token 的预测对应 $y_w$ 的第一个 token）

per_token_logps = torch.gather(
    log_probs,
    dim=-1,
    index=labels.unsqueeze(-1)
).squeeze(-1)   # shape: (bs, seq_len)

# 忽略 prompt 部分（mask 掉前 |x| 个位置的 loss）
masked_logps = per_token_logps * response_mask
logps_chosen_θ = masked_logps.sum(dim=-1) / response_mask.sum(dim=-1).clamp(min=1)

通过上面代码就可以直接得到 $\log \pi_\theta(y_w | x) \approx \text{logps_chosen_θ}$。同理计算 $\log \pi_\theta(y_l | x)$、参考模型的 $\log \pi_{\rm ref}(y_w | x)$ 和 $\log \pi_{\rm ref}(y_l | x)$。
第三步计算loss并且反向传播。

log_ratio_w = logps_chosen_θ - logps_chosen_ref
log_ratio_l = logps_rejected_θ - logps_rejected_ref

diff = β * (log_ratio_w - log_ratio_l)
loss = -log(sigmoid(diff)).mean()

PPO

PPO是一种基于策略梯度的强化学习算法，核心思想是通过限制策略更新的幅度来保持训练的稳定性。其目标函数（通过KL散度处理）为：

$\pi_\theta$: 当前策略参数化的策略函数
$A_t$: 优势函数，衡量动作$a_t$相对于平均水平的优势
$\epsilon$: 超参数（通常0.1-0.2），限制策略更新的最大幅度
​Clipping机制：通过截断重要性采样比率，防止策略更新过大导致训练不稳定
对于上述公式里面优势函数$A_t$（用来衡量的是某个动作相对于平均水平的优势，也就是说，这个动作比平均情况好多少）具体计算公式为：$A_t=Q(s_t, a_t)-V(s_t)$，分别表示：1、$Q(s_t, a_t)$：在状态$s_t$下执行动作$a_t$得到的期望汇报；2、$V(s_t)$：状态$s_t$的平均累计期望。对于其计算可以通过GAE（广义优势估计）来进行计算。在实际优化过程中计算的loss是

PPO优化过程

对于PPO模型优化过程：

第一步 数据采样与 rollout（on-policy 生成）。从当前策略 $\pi_\theta$（通常是 SFT 后的模型，或者直接Lora处理的模型）采样一批 prompt $x$，然后让模型自回归生成完整的模型输出 $y \sim \pi_\theta(\cdot | x)$。记录每个 token 的 log-prob（用于后续 importance ratio 计算）和 entropy（可选）。此外，通常会生成多个响应（e.g. 4~64 条）来增加多样性以及更加稳定的优势估计。
第二步 前向计算 reward + advantage（使用 Reward Model + Critic + GAE）。对每条生成的响应 $y$。
用 Reward Model $r_\phi(x, y)$ 计算标量奖励 $r$，通常在序列末尾打分，或 process-level 每步打分，一般而言对于Reward Model会直接用一个独立的模型直接将我的prompt+模型输出丢给模型然后输出一个评分。
用参考模型 $\pi_{\rm ref}$（通常是冻结的 SFT 模型）计算 KL 散度（防止偏离过远）。
\(\tilde{r}_t = r_t - \beta \cdot \text{KL}\bigl(\pi_\theta(\cdot|s_t) \big\| \pi_{\rm ref}(\cdot|s_t)\bigr)\)
其中 $r_t = 0$（对于 $t < T$），$r_T = r$（序列末尾），$\beta$ 是 KL 系数（常见 0.01–0.05，可动态调整）。
用价值模型（Critic）$V_\psi(s)$ 估计状态价值。一般价值模型和策略模型（一般而言就是Lora分装的模型）共享大部分参数（transformer backbone），但在最后一层额外接一个线性头，输出 scalar value $V_\psi(s_t)$。计算GAE得到每一个token的优势估计 $\hat{A}_t$：

其中（$\gamma \approx 1.0$ 或 0.99，$\lambda \approx 0.95$）。$r_t$ 在第 t 步（生成第 t 个 token 后）获得的即时奖励即 Reward Model 给整个响应的分数。对于GAE过程可以这么理解：最开始模型对于prompt生成一条（多条）输出，也就是下面一个token序列

s_0 = prompt
a_0 → s_1 = prompt + token_0
a_1 → s_2 = prompt + token_0 + token_1
...
a_{T-1} → s_T = prompt + 全部生成 token（结束）

直接整个序列输入给 Critic 网络，得到每一个位置的价值估计：

states = [s_0, s_1, ..., s_T]          # 实际上是累积的 input_ids
values = critic(states)                # shape: [T+1] 或 [seq_len]

第三步 前向计算 PPO 损失并反向传播。分别使用当前策略 $\pi_\theta$ 和旧策略 $\pi_{\theta_{\rm old}}$（通常是 rollout 开始时的策略拷贝，或上一次更新的快照）计算每个 token 的 log-probability，得到重要性采样比率 $r_t(\theta)$：

基于这个比率和前面计算得到的优势 $\hat{A}_t$，构造 PPO-Clip 的代理目标（surrogate objective）：

然后计算 PPO 的完整损失函数（实际训练中最小化这个 loss）：

其中：

• 第一项：policy loss（负的 clipped surrogate，最大化它等价于鼓励好动作）
• 第二项：value loss（Critic 的 MSE 损失，$\hat{R}_t$ 是 GAE 计算的 discounted returns 或 bootstrapped target）
• 第三项：entropy bonus（鼓励探索，防止过早收敛）
• 第四项：KL 惩罚（可选，防止策略偏离过远，常见于 adaptive KL 或 early stopping）

对于上述过程中用到模型有：1、policy_model（一般而言就是SFT之后的模型，被Lora封装的，模型需要被训练）；2、value_model（一般就是在policy_model基础上额外补充一个处理头去计算每个token概率，模型一般需要训练）；3、ref_model（一般就是SFT之后的模型，模型不需要训练）；4、reward_model（模型不需要训练）。另外两个模型——reward_model 和 value_model——主要是用来一起算出“优势值”（Advantage），也就是告诉模型“这个选择到底比平均水平好多少”。 简单用开车比喻：
reward_model 就像路上的导航终点 + 路牌评分,它告诉你“往左拐这条路通向风景最好的山顶（高奖励）”，或者“直走这条路会掉进沟里（低/负奖励）”。它负责定义“什么叫好开、什么叫开砸了”。
value_model 就像车载仪表盘上的剩余路程 + 坡度提示.它实时估算：“你现在开到半山腰了，前面还有多陡的坡、多远的路、预计还能赚多少分（剩余价值）”。它帮你知道当前位置的“价值基准”，避免每次都靠运气猜。
把两者结合起来，就能算出优势值（δ_t ≈ r_t + γ V(s_{t+1}) - V(s_t)）：
相当于仪表盘告诉你：“刚才右转这个弯，比直走平均水平多省了 20 分钟油钱 + 风景更好（正优势），应该多学学这个动作！”或者：“刚才超车这个操作，虽然过了，但前面堵得更严重，实际比平均水平亏了（负优势），下次别这么干。”
一句话总结：

• reward_model：告诉你“哪条路是终极好路”（目标方向）
• value_model：告诉你“现在开到哪儿了，离好路还有多远、多陡”（当前基准）

缺了任何一个，车就只能瞎开——要么不知道终点在哪，要么不知道自己开得好不好，全靠蒙。

# 1. 计算重要性比率（importance ratio）
ratio = torch.exp(log_probs_theta - log_probs_old)   # shape: [bs, seq_len]

# 2. PPO-Clip 代理目标
clipped_ratio = torch.clamp(ratio, 1.0 - epsilon, 1.0 + epsilon)   # epsilon 通常 0.1~0.2
surrogate1 = ratio * advantages                                     # advantages: [bs, seq_len]
surrogate2 = clipped_ratio * advantages
policy_loss = -torch.min(surrogate1, surrogate2).mean()            # 负号：最小化 loss → 最大化 surrogate

# 3. Value loss（Critic 回归到 GAE target 或 returns）
# returns 可以是 GAE discounted sum，或 advantages + values
value_loss = F.mse_loss(values, returns, reduction='mean')

# 4. Entropy bonus（鼓励动作多样性）
# probs: 当前策略的 softmax 概率分布
entropy = -(probs * log_probs_theta).sum(dim=-1).mean()

# 5. 可选：KL 惩罚（per-token 或 sequence-level，防止崩坏）
# 实际中常使用 ref model 的 log_probs_ref 计算
kl = (log_probs_ref - log_probs_theta).mean()   # 近似 KL（或用更精确的无偏估计）

# 6. 组合总损失（典型权重：c1 ≈ 0.5, c2 ≈ 0.01, β ≈ 0.01~0.05）
loss = (
    policy_loss
    + c1 * value_loss
    - c2 * entropy
    + beta * kl
)

GRPO

GRPO是DPO的扩展形式，处理组级别的偏好优化问题，其核心公式：

$r^*$: 组内最优响应
$\mathcal{R}$: 包含k个响应的候选集
$q$: 问题, $o_i$: 对于问题生成的第 $i$ 个回答，$r_i$: 回答对应的奖励得分
KL项：防止模型过度偏离初始策略，缓解模式坍塌。对于上面的loss计算公式内部的平均（$\frac{1}{\vert o_i \vert}$）是对每条轨迹的token去计算平均值，而外部的平均是对每条轨迹去计算平均值，会带来一些小的问题以及一些小的tips：
1、模型的输出变长（对于错误输出格外明显）¹主要由如下两点导致：1、$\frac{1}{\vert o_i \vert}$ 偏差，在正确回答中 $A_i>0$ 那么在除token长度时候就更加倾向长度越短才能保证内部min，而错误回答 $A_i<0$ 则是相反会导致输出长度更加长。2、问题难度偏差，标准差较低的问题（例如，那些过于简单或过于困难，结果奖励几乎全部为 1 或 0 的问题），就会导致计方差很小但是最后优势值极大。针对这两种问题直接：1、去掉计算 $\frac{1}{\vert o_i \vert}$ ；2、不去计算 $\text{std}$

上述为 Dr.GRPO 论文中提出改进

2、模型奖励信号是0，这点问题其实就是如果模型回答后内容奖励函数进行打分发现结果都是相同的就会导致优势值为0进而导致模型无法更新。解决措施²：直接添加虚拟满分样本

rewards = [0.8, 0.8, 0.8, 0.8]
augmented = rewards + [1.0]  # 虚拟满分样本
mean = sum(augmented) / len(augmented)  # 0.84
std = sqrt(variance(augmented))          # 0.08
advantage = (r - mean) / std             # 非零！

GRPO 优化过程

上图中几个比较关键词：1、Policy Model：即我们需要通过强化学习优化的模型；2、Reward Model：奖励模型，即对模型做出的决策所给出的反馈（分类打分的）；3、Value Model：估计状态的价值，帮助指导策略优化（分类打分的）；4、Reference Model：提供历史策略的参考，确保优化过程中策略变化不过度。其模型优化过程为：
第一步数据采样与生成。对每个 prompt $x$，用当前旧策略（亦或者没有加Lora模型） $\pi_{\theta_{\rm old}}$ 生成 G 条完整响应 ${y_1, y_2, \dots, y_G} $（通常 G=16~64，采样时带 temperature >0 以增加多样性）。每条 $ y_i $ 都是自回归生成的完。同时记录每条响应的 per-token log-prob（用于后续 ratio 计算）。
第二步计算奖励 + 组相对优势。对每条生成的响应 $ y_i $ 计算标量奖励 $ r_i $（verifiable reward），然后在组内归一化得到相对优势：

（$ \epsilon $ 小常数防除零，通常 1e-8）

import torch

rewards = torch.tensor([r1, r2, ..., rG])   # shape [G]
mean_r = rewards.mean()
std_r = rewards.std() + 1e-8
advantages = (rewards - mean_r) / std_r     # shape [G]，每个响应的相对优势

这个 $A_i$ 会广播到该响应 $y_i$ 的所有 token 上（因为 reward 是 sequence-level），和PPO区别在于PPO中会通过模型（直接在Lora封装模型外接一层直接计算每一个token的状态估计值，而后通过GAE去估计最后的优势值）
第三步计算 GRPO 损失并反向传播。计算当前策略 $ \pi_\theta $ 和旧策略 $ \pi_{\theta_{\rm old}} $ 的 log-prob ratio（per-token）：

# ratio shape: [bs, seq_len] 或 per-response
ratio = torch.exp(log_probs_theta - log_probs_old)

clipped_ratio = torch.clamp(ratio, 1-ε, 1+ε)   # ε 通常 0.2

# surrogate objective（最大化这个，或最小化负值）
surrogate1 = ratio * advantages_i     # advantages_i 广播到该响应的所有 token
surrogate2 = clipped_ratio * advantages_i
policy_loss = -torch.min(surrogate1, surrogate2).mean()   # 平均过所有 token 和所有组
kl = ...  # 计算 π_θ 和 π_ref 的 KL（通常 per-token 平均，或无偏估计）
loss = policy_loss + β * kl   # β 通常 0.01~0.05

参考

Flow Matching基本原理

简单介绍

用基本例子进行理解，比如说给定一个全随机的橡皮泥（相当于纯噪声），将其慢慢捏成一个具体的雕像（比如一只猫图像）。传统扩散模型：先把雕像一点点加上各种小随机扰动，直到完全看不出是猫了（前向加噪）。然后训练一个神经网络学会“反过来一点点去掉扰动”，从乱泥巴慢慢还原成猫（反向去噪）。这个过程有很多随机性，每走一步都有点“抖动”，所以路径是弯弯曲曲的，采样时通常要走很多步（20–100步）。Flow Matching：直接跳过一条最平滑、最直接的路，让这团乱橡皮泥顺着这条路一直往前走，就能变成猫，其核心思想就是，学习一条从噪声到数据的连续“流动”路径（flow），并且这条路径是确定的。
对于其中所谓的“流动”路径，比如说生成过程从t=0（纯噪声数据）到t=1（真实数据），如果存在“速度场”，能够了解在每一个时刻 t、每一个位置x上，东西应该往哪个方向、以多大的速度移动，才能最终到达正确图像，也就是对于微分方程 $\frac{dx}{dt}=v_{\theta}(x,t)$相对于告诉每一个瞬时速度。模型训练过程中¹，在传统的SD模型训练过程中是去预测每一步的噪声（而后去减掉该步的噪声），而Flow Matching则是直接让模型去预测移动速度，比如下面代码

对于上图中数据直接就是MNIST数据集（x_1，y，x_0分别对应图像、标签、噪声）而上述黄色框中过程首先去生成时间步（正如上面描述的时间从t=0–>t=1）那么就对应每张图像都是$t\in [0,1]$，除此之外其中的path_sampler就对应上面提到的流动路径，返回的两个值：$x_t=t\times x_1+ (1-t)x_0$ 以及对应的速度 $dx_t=x_1-x_0$那么最后模型预测过程也就是去预测这个速度。在得到最后的优化模型之后就是直接去采样，采样过程：

对于上述的采样路径（$x_t=t\times x_1+ (1-t)x_0$）可以直接替换为其他的都可以，除此之外Flow Matching可能不能直接（效果不佳）去作用在SD1.5此类模型可以借鉴²中方法进行操作，主要是因为两者在寻览过程中预测内容就是不同的，前者是直接预测噪声，并且其采样路径是随机的，而FM路径是固定的。

深度介绍

ing……….

https://mlg.eng.cam.ac.uk/blog/2024/01/20/flow-matching.html#introduction
https://peterroelants.github.io/posts/flow_matching_intro/
https://federicosarrocco.com/blog/flow-matching
https://arxiv.org/pdf/2210.02747

参考

outputs = model(**batch_data)
loss = outputs.loss
accelerator.backward(loss)
if accelerator.sync_gradients:
    # 记录裁剪钱梯度值
    # grad_norm = torch.norm(torch.stack(
    #     [torch.norm(p.grad.detach(), p=2.0) 
    #      for p in model.parameters() if p.grad is not None])).item()
    # accelerator.clip_grad_norm_(model.parameters(), 
    #                             config.max_grad_norm)
    # 直接记录裁剪侯的梯度值
    raw_grad_norm = accelerator.clip_grad_norm_(model.parameters(), config.max_grad_norm)
    grad_norm = raw_grad_norm.item() if hasattr(raw_grad_norm, 'item') else raw_grad_norm
...
if accelerator.sync_gradients:
    progress_bar.update(1)
    global_step += 1
    if accelerator.is_main_process:
        accelerator.log(
            {'Train/Loss': loss.detach().item(), 
             'Train/lr': lr_scheduler.get_last_lr()[0],
             'Train/graid_norm': grad_norm}, 
            step=global_step)

通过上面方式去记录loss等变化情况得到最终图像如下：

loss以及Grad Norm理论简单分析

首先loss往往直接用来表示模型的拟合效果（loss下降代表拟合效果较好，部分震荡代表数据中部分样本很难较好的进行“拟合”）。Gradient（梯度）一般而言就是对于需要优化函数的导数，而Grad Norm一般就是表示所有参数梯度向量拼接（展平）后形成的超长向量的 L2 范数。在模型训练过程总一般而言主要关注两个指标比较多：1、loss；2、评估指标（ACC等），但是对于Grad Norm这个值相对讨论较少，简单对于Grad Norm过程指标（optimization dynamic 的诊断信号），区别loss它不直接衡量模型好坏，而是反映优化器当前“还能走多远、多快”、训练是否稳定、是否接近某种奇异点等中间状态。
那么理论上而言模型优化过程中应该是loss以及Grad Norm（越往后期模型理论上越接近“最优值”那么梯度理论越小）两个指标都一起下降，但是实际情况可能相反，下面就这种情况简单分析如下：

Grad Norm上升原因分析

在Github-issue¹中给出结论是：梯度范数大致与参数范数成正比（或者至少取决于参数范数）。作者直接给出了梯度与模型参数的变化情况分析：$\Vert \nabla f(\theta) \Vert ≈ \Vert \theta \Vert \cdot \Vert \nabla f(\theta / \Vert \theta \Vert)\Vert$，那么也就意味了如果模型 $\theta / \Vert \theta \Vert$ 大致逐渐收敛但是参数 $\Vert \theta \Vert$在增加就会导致最终的Grad Norm逐渐上升。
在论文中²作者给出解释是：权重衰减与学习率安排相互作用的结果，具体理论分析如下:

这样一来梯度$g$ 与权重 $x_t$ 之间关系就只与学习率 $\gamma$ 和参数 $\lambda$ 之间有关系。因此就可以得到：$\frac{\Vert g_t \Vert}{\Vert x_t \Vert}=\sqrt{\frac{2\lambda}{\gamma_t}}$ 当使用学习率warm up策略时候就会发生下降上升的情况。

参考

模型蒸馏

模型蒸馏是一种模型压缩和优化技术。简单来说，就是让一个小模型（学生模型）去模仿一个已经训练好的大模型（教师模型）的行为，从而用更小的体积、更低的计算量，尽量接近大模型的性能。比如说Qwen0.5B模型就是直接从一个较大的模型进行蒸馏得到。而对于蒸馏过程也有很多，最常见的就是直接通过数据进行蒸馏，比如说通过CahtGPT生成高质量数据而后将这部分高质量数据进行模型训练也可以达到蒸馏的目的。亦或者直接通过模型进行蒸馏，最简单的蒸馏例子（计算students的预测loss以及students和teacher模型之间的KD）：1、KD知识蒸馏过程：直接定义一个参数较小的学生模型而后对于相同的数据分别通过小模型以及大模型处理，再去计算“叠加loss”：$L=L_{student}+ L_{KD}$ 其中第一项是小模型的loss第二项是计算小-大模型之间的KD；2、DKD解耦知识蒸馏：$L=\alpha L_{TCKD}+ \beta L_{NCFD}$ 其中
\(\mathcal{L}_{TCKD} = \mathrm{KL} ( [p^S_t,\ 1-p^S_t]\ \Vert\ [p^T_t,\ 1-p^T_t] )\)
以及
\(\mathcal{L}_{NCKD} = \mathrm{KL} ( \frac{p^S}{\sum_{j\neq t} p^S_j},\ \frac{p^T}{\sum_{j\neq t} p^T_j} )\)
在实际应用过程中有一个比较重要参数：temperature使用方式和llm中的相同都是输出概率去除温度系数，比如说softmax中：$\frac{e^{x/t}}{\sum e^{x/t}}$$

对于两种简单的知识蒸馏代码：代码

分配匹配蒸馏（DMD）

对于DMD¹方法原理如下（DMD1的算法流程）：

对于上诉算法流程图简单描述在DMD蒸馏中主要是通过两个Loss实现，1、regression loss（回归损失）：对于教师模型生成过程中得到一批noise-image对（对应 $z_{ref}, y_{ref}$），对于蒸馏的学生模型生成器 $G_\theta$ 直接用初始化噪声以及noise-image中的噪声进行单步生成得到image分别得到：$x$ 以及 $x_{ref}$，而后对于noise-image中的噪声直接去计算LPIPS损失函数（主要是计算两组图像之间的相似度，代码实现）；2、diffusion loss：蒸馏过程中核心损失，在一般的蒸馏模型过程如LCM是去强迫学生模型模仿 teacher 的每一步去噪轨迹，而DMD则是去计算最终生成的图像分布是否和真实分布之间是否一致，具体的处理过程直接去计算distributionMatchingLoss：

从上面过程很容易知道处理过程，通过计算“真假两个扩散模型”在噪声预测上的偏差，产生一个指引梯度，推着学生模型去生成更符合真实统计规律的图像。
在DMDv2²中直接取消了回归损失（主要是在DMDv1中需要预先通过教师模型生成一个庞大的“文本/噪声-图像”对数据集，并且使用回归损失和分布匹配的核心思想相悖，限制了模型性能：回归损失强制学生模型模仿教师模型的具体采样路径，而不是匹配整体的输出分布。）但是直接取消会带来训练效果下降，因此在论文里面使用TTUR：在DMDv1中使用的loss处理思路和GAN相似，因此在v2中未来弥补取消回归损失影响对模型优化影响，对于生成器更新一次，而我的判别器会更新n次（论文中5次，在TTUR原始论文中是使用不同的学习率）。

除此之外引入GAN损失：
\(L_{GAN} = \mathbb{E}_{x \sim p_{real}, t \sim [0,T]} [\log D(F(x, t))] + \mathbb{E}_{z \sim p_{noise}, t \sim [0,T]} [-\log(D(F(G_\theta(z), t)))]\)
各项参数含义，D：GAN discriminator（分类器），通常作为 fake denoiser（μ_fake）的 bottleneck 上的一个分支。F(·, t)：forward diffusion process（在图像上加噪声到 timestep t），让 discriminator 在 noisy 版本上区分 real vs fake（这与 diffusion 的 noisy nature 兼容）。$G_θ(z)$：student generator 输出的图像（z 是纯噪声）。生成器 $G_θ$ 最小化损失（让 D 把 fake 判断成 real）；D 则学习区分 real 与 fake。简单总结上述loss计算过程，对于学生模型 $G_θ(z)$ 通过对其解析拆解构成判别器模型，在生成图像之后通过判别去判别（GAN的思路），总结而言就是将DMDv1中回归损失直接更换为GAN损失其他保持不变。

LCM蒸馏过程：训练过程可以简单理解为：对于输入图像 $x$，直接添加 $n$ 步的噪声得到 $x_n$，而后我的学生模型直接去预测 $t_0$ 时候的结果 $y_1$；同时，我的教师模型（预训练好的扩散模型）从 $x_n$ 出发，通过 DDIM 采样器向前走一步（跨越 $k$ 个时间步），得到 $t_{n-k}$ 时刻在轨迹上的观察点 $x_{n-k}$；而后再去用学生模型通过 $x_{n-k}$ 预测 $t_0$ 的结果得到 $y_2$。最后计算 $y_1$ 与 $y_2$ 之间的距离损失（Consistency Loss），迫使模型无论从哪个时间步出发，预测的终点都指向同一点。

模型剪枝

在一个训练好的大模型中，数以亿计的参数（权重）里，也存在大量冗余或贡献微弱的连接。模型剪枝的核心思想，就是识别并移除这些“不重要”的权重，从而得到一个更小、更高效的模型。在剪枝方法上主要两大类，1、非结构化剪枝，将单个权重值置为零。这会产生一个“稀疏”的权重矩阵，即矩阵中包含大量零值。2、结构化剪枝，移除整个结构单元，例如整个神经元（矩阵的行/列）、注意力头，甚至是整个网络层。模型剪枝过程必须剪枝->微调->剪枝->微调不断地重复这个过程。最简单的剪枝过程可以直接使用torch.nn.utils.prune来进行操作，在代码中torch提供多种剪枝条方法（一般后缀中有 _unstructured表示的是非结构化的剪枝，而_structured则是表示结构化的剪枝），非结构化剪枝代码

import torch.nn.utils.prune as prune
prune.global_unstructured(
    parameters_to_prune,
    pruning_method=prune.L1Unstructured,
    amount=10,
)

不过需要注意的是按照官方介绍：对于非结构化剪枝的区域回去添加一个名为name+’_mask’的命名缓冲区，对应于修剪方法对参数名称应用的二进制掩码（mask是一个0/1张量量化过程就是：weight = weight_orig * mask）。将参数名称替换为修剪后的版本，而原始（未修剪）参数存储在名为name+’_orig’的新参数中。也就意味着在 prune.global_unstructured不会改变模型大小只是添加mask让模型推理可以加速。结构化剪枝代码：

import torch.nn.utils.prune as prune
prune.ln_structured(module,...)

具体测试脚本：ModelPrune.py

参考

Ai-toolkit

Ai-toolkit安装介绍

环境准备

在autodl上的服务器进行的操作（GPU：VGPU-32G，CUDA Version: 13.0 ）

# 首先安装基本环境
source /etc/network_turbo  # autodl 上执行该命令进行代理
git clone https://github.com/ostris/ai-toolkit.git
cd ai-toolkit
conda create -n ai-toolkit python=3.12
conda activate ai-toolkit
pip3 install --no-cache-dir torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu126
pip3 install -r requirements.txt

# 安装 npm
curl -fsSL https://deb.nodesource.com/setup_lts.x | bash -
apt update
apt install -y nodejs

# 安装完毕之后直接测试，如果显示版本那么表示安装成功
node -v # v24.13.0
npm -v # 11.6.2
npm config set registry https://registry.npmmirror.com # 换npm源

# 由于启动了代理可以先使用下面代码之后再去执行 run 程序
npm config set strict-ssl false
export NODE_TLS_REJECT_UNAUTHORIZED=0

export HF_ENDPOINT=https://hf-mirror.com
# 建议取修改hf模型下载路径
vim ~/.bashrc
export HF_HOME="/path/to/you/dir"  # 替换为你想更改的目标路径
source ~/.bashrc

cd ai-toolkit/ui
export HF_ENDPOINT=https://hf-mirror.com
npm run build_and_start

上面运行代码运行之后出现：

可以直接访问上面地址进入 ai-toolkit

界面简单介绍

首先取配置自己hf token

配置完毕之后可以直接上传数据集/直接在本地数据集，不过数据集需要在路径：xxx/ai-toolkit/datasets（对应上面图像中的路径） 中除此之外还需要注意数据集的格式问题，以文生图任务为例，我的数据集必须满足：1、图像必须是：.jpg, .jpeg, .png；2、文本：txt。除此之外图片文本之间必须匹配：1.png 1.txt…..

可以直接将上面文件夹上传到xxx/ai-toolkit/datasets中


对于训练界面参数介绍：


1、模型路径尽量不要去修改就用默认的，如果要去修改可以参考：reddit上的方法
2、如果报错是和模型下载相关（如CAS报错、hf_transfer报错），可以直接重启任务就行（去Training Quene找到任务然后重新启动即可）
模型训练处理

Ai-toolkit模型微调

对于文生图/图生图微调训练很简单只需要将上面的数据进行修改即可，而后点击开始训练即可

值得注意的是，如果模型还需要去继续训练，比如说我在第一批数据得到一个lora但是又有另外一批数据需要继续去训练，在前端是不支持的，需要重新去建立一个训练任务（可以直接复制第一批数据的yaml文件）而后将其中的数据以及命名都改掉，修改yaml中的name: Flux-Klein-AID-Inpatient-2000-9B，而后将上一批数据中训练得到的最好的lora复制到新的文件夹中，而后启动训练即可（python run.py output/tmp/config.yaml）这个过程会在终端出现

#### IMPORTANT RESUMING FROM /root/autodl-tmp/xxx/ai-toolkit/output/xxx/xxx.safetensors ####
Loading from /root/autodl-tmp/xxx/ai-toolkit/output/xxx/xxx.safetensors

说明模型重新去加载了lora，具体代码在jobs/process/BaseSDTrainProcess.py中的函数get_latest_save_path就是去加载最新得到权重进行继续训练。

if latest_save_path is not None:
    print_acc(f"#### IMPORTANT RESUMING FROM {latest_save_path} ####")
    model_config_to_load.name_or_path = latest_save_path
    self.load_training_state_from_metadata(latest_save_path)

Ai-toolkit代码分析

在Ai-toolkit中模型微调整个流程如下：Googledrive-Drawio。对于上述流程图中只介绍了对于模型、数据都是如何处理的，对于具体如何处理没有介绍，这里简单做一些介绍数据以及模型处理过程进行初步介绍，对于数据处理过程：
对于dataset构建过程：

class AiToolkitDataset(LatentCachingMixin, ControlCachingMixin, CLIPCachingMixin, TextEmbeddingCachingMixin, BucketsMixin, CaptionMixin, Dataset):
  def __init__(self, ...):
    ...
    self.file_list: List['FileItemDTO'] = []
    # 其中 self.dataset_path 对应我的 yaml 文件中的 folder_path
    if os.path.isdir(self.dataset_path):
      extensions = image_extensions
      if self.is_video:
          extensions = video_extensions
      file_list = [os.path.join(root, file) for root, _, files in os.walk(self.dataset_path) for file in files if file.lower().endswith(tuple(extensions))]
    else:
        with open(self.dataset_path, 'r') as f:
            self.caption_dict = json.load(f)
            # keys are file paths
            file_list = list(self.caption_dict.keys())
    # 而后去对数据进行重复采样
    ...
    for file in tqdm(file_list):
      try:
      file_item = FileItemDTO(
          sd=self.sd,
          path=file,
          dataset_config=dataset_config,
          dataloader_transforms=self.transform,
          size_database=self.size_database,
          dataset_root=dataset_folder,
          encode_control_in_text_embeddings=self.sd.encode_control_in_text_embeddings if self.sd else False,
          text_embedding_space_version=self.sd.model_config.arch if self.sd else "sd1",
          te_padding_side=self.sd.te_padding_side if self.sd else "right",
          latent_space_version=latent_space_version,
      )
      self.file_list.append(file_item)
  def __len__(self):
    if self.dataset_config.buckets:
      return len(self.batch_indices)
    return len(self.file_list)
  def __getitem__(self, item):
    if self.dataset_config.buckets:
      if len(self.batch_indices) - 1 < item:
        idx_list = self.batch_indices[item]
        return [self._get_single_item(idx) for idx in idx_list]
    else:
        return self._get_single_item(item)

对于上面的FileItemDTO其实就是对于上面流程图中比如说LatentCachingFileItemDTOMixin这些父类都是定义了一些基础数据处理，比如说prompt、图像进行tensor转换等。对于loader过程，在ai-toolkit中会将数据都封装为：DataLoaderBatchDTO(toolkit/data_transfer_object/data_loader.py)对于里面定义了很多属性值需要关注的就是如下几个（batch = next(iter(data_loader))）：1、batch.tensor：对于目标图的tensor尺寸大小；2、batch.control_tensor：对应条件图的tensor尺寸大小；3、batch.get_caption_list()：获取整个batch中所有的提示词。在得到完整的laoder数据集之后就是直接进行模型训练。对于训练过程整体代码如下：

class BaseSDTrainProcess(BaseTrainProcess):
  ...
  # 预先定义好整个训练过程就和hf中trainer中一样

class SDTrainer(BaseSDTrainProcess):
  # 具体训练过程就和DPOTrainer一样都是继承一个小的trainer
  ...
  def __init__(...):
    ...
  def hook_train_loop(self, batch: Union[DataLoaderBatchDTO, List[DataLoaderBatchDTO]]):
    # 模型计算loss/梯度更新
    for batch in batch_list:
      ...
      loss = self.train_single_accumulation(batch) # 去vae等编码而后计算loss
      ...
      if total_loss is None:
          total_loss = loss
      else:
          total_loss += loss
      ...
    if not self.is_grad_accumulation_step:
      # 梯度累计 
      ...
      self.accelerator.clip_grad_norm_(...)
      ...
      with self.timer('optimizer_step'):
        self.optimizer.step()
        self.optimizer.zero_grad(set_to_none=True)
      ...
    with self.timer('scheduler_step'):
      self.lr_scheduler.step()
    loss_dict = OrderedDict({'loss': (total_loss / len(batch_list)).item()})
    self.end_of_training_loop()
    return loss_dict

对于训练过程中，主要是self.train_single_accumulation(batch)在这个函数中对于输入的batch会进行vae、text_encoder等进行编码然后计算loss整个过程如下：

def train_single_accumulation(self, batch: DataLoaderBatchDTO):
  with torch.no_grad():
    ....
    noisy_latents, noise, timesteps, conditioned_prompts, imgs = self.process_general_training_batch(batch)
    if self.train_config.do_cfg or self.train_config.do_random_cfg:
      # 如果要做文本的 cfg，如果有negative那么就使用否则直接用 '' 空字符串代替
      ....
    if self.adapter and isinstance(self.adapter, CustomAdapter):
      # 如果有 adapter 那么就用adapter去处理 conditioned_prompts
      conditioned_prompts = self.adapter.condition_prompt(conditioned_prompts)
    ...
    if self.train_config.short_and_long_captions_encoder_split and self.sd.is_xl:
      # 如果是 sdxl 模型会对prompt进行切断然后长/短分别交给不同编码器
      ...
    if self.train_config.single_item_batching:
      # 单样本逐个批处理模式，主要是为了处理显存不够情况，那么将数据进行按 bs进行chunk到list中
      batch_size = noisy_latents.shape[0]
      noisy_latents_list = torch.chunk(noisy_latents, batch_size, dim=0)
      ...
    else:
      noisy_latents_list = [noisy_latents]
      ...
    # 一次读取数据开始训练
    for noisy_latents, noise,... in zip(noisy_latents_list, noise_list, ...):
      with (network):
        # 专门处理“图像适配器”（adapter）的条件嵌入编码和注入，让模型在当前 batch 的去噪预测中能利用额外的图像条件（如 IP-Adapter 风格的 CLIP Vision 图像提示，或自定义的图像参考）。
        # TODO: 详细去了解一下如何使用 adapter 在ai-toolkit中
      with self.timer('encode_prompt'):
        prompt_kwargs = {}
        if self.sd.encode_control_in_text_embeddings and batch.control_tensor is not None:
          prompt_kwargs['control_images'] = batch.control_tensor.to(...)
        if self.train_config.unload_text_encoder or self.is_caching_text_embeddings:
          # 这部分参数在前端中就有选择
          # 如果卸载text_encoder 以及缓存text_embedding的时候需要处理
          ...
        elif grad_on_text_encoder:
          # 训练 text_encoder
          ...
        # TODO: 详细去了解一下如何使用 adapter 在ai-toolkit中
      if self.train_config.timestep_type == 'next_sample':
        # 获取 预测的noise
        ...
      if batch.unconditional_latents is not None or self.do_guided_loss:
        # 用差分引导损失（让 LoRA 专注“变化部分”，防过拟合/出血）
        ...
      elif self.train_config.loss_type == 'mean_flow':
        # 用 flow-matching 专属的平均流损失
        ...
      ...
        self.accelerator.backward(loss)
  return loss.detach()

数据后处理过程：对于process_general_training_batch过程需要去看BaseSDTrainProcess（jobs/process/BaseSDTrainProcess.py）代码对于这个过程简单总结如下：
1、prepare_prompt：对 prompts 进行系统性扩展和条件化处理，确保模型在不同配置（短/长 caption、refiner、embedding、trigger、prompt saturation）下，得到正确且一致的输入文本
2、prepare_latents：直接获取batch.tensor进行vae编码
3、prepare_scheduler：直接处理好调度器，比如说调度此要采样多少步，默认是num_train_timesteps=1000
4、prepare_timesteps_indices：选择时间步，比如说参数next_sample以及one_steps前面代表去随机选择(0,num_train_timesteps-2)或者直接就是一步（类似flow-matching）以及content_or_style参数主要是3个值：content：选择靠前的时间步（学习图像结构特征）、style：选择靠后的时间步（学习图像纹理）、balanced（默认）：选择中段时间步，之所以这样是因为df解噪声过程直接从1-1000越往后模型越体现的是细节内容
5、convert_timestep_indices_to_timesteps：将时间步添加到调度器中，self.sd.noise_scheduler.timesteps[timestep_indices.long()]
6、prepare_noise： 生成噪声
7、make_noisy_latents：将得到的noise添加到latents中。
通过上面过程最后返回：noisy_latents, noise, timesteps, conditioned_prompts, imgs，这样一来标准的输入数据格式就准备好了。

ai-toolkit 训练参数

值得注意的是除去ai-toolkit中前端默认参数还可以直接自定义参数（较多参数都在ai-toolkit/toolkit/config_modules.py文件中给了默认参数）：

• model 模块参数（直接去BaseSDTrainProcess.py看参数）

assistant_lora_path:str： lora模型路径（建议直接使用 hf地址）

• train 模块参数（直接去BaseSDTrainProcess.py看参数）

• decorator 模块参数（暂时只支持 flux 模型）（默认没有，参数方法和 train 中使用方法相同）

num_tokens:int 文本嵌入修饰器/适配器，专门用于在扩散模型的文本条件输入上额外拼接几个可学习的 token

• adapter t2i模块参数（默认没有，参数方法和 train 中使用方法相同）

对于这个模块参数可以参考配置。主要作用是实现图像到图像（image-to-image）条件适配器，主要功能是，让模型“看见”参考图像，然后根据文本提示 + 参考图像 来生成变体（variation）、风格迁移、细节保持等。

adapter:
  train: false                # adapter是否参与训练  
  type: "ip_adapter"          # 支持："t2i", "control_net", "clip", "ip" 也支持直接自定义  
  name_or_path: "h94/IP-Adapter"      # 上面4种参数直接会从 hf 上进行加载，对于自定义的值就回去加载custom
  weight_name: "ip-adapter_sd15.safetensors"
  scale: 0.8                  # 强度缩放（可选，默认 1.0）
  test_img_path:
    - "path/to/your/image.png"
    - "path/to/your/image2.png"

排错处理

• 1、加载数据过程中出现数据形状不匹配问题

对于上面截图报错在测试Klein9B模型过程中出现，主要是在测试batch_size>1就容易发生，可以直接将所有的数据都固定到相同形状可以解决

• 2、进程一直被killed

在运行代码（直接使用python run.py ...）有些适合就会在终端直接被killed（ai-toolkit默认的 torch=2.7可能版本不太合适）切换为 torch=2.10的版本 pip3 install --no-cache-dir torch==2.10.0 torchvision==0.25.0 torchaudio==2.10.0 --index-url https://download.pytorch.org/whl/cu126

• 3、hf_transfer/CAS 错误

An error occurred while downloading using hf_transfer. Consider disabling HF_HUB_ENABLE_HF_TRANSFER for better error handling.

启动命令前使用

export HF_HUB_ENABLE_HF_TRANSFER=0 # 处理hf_transfer报错
export HF_HUB_DISABLE_XET=1 # 处理CAS报错

• 4、端口占用错误

[UI] next start --port 8675 restarted
[UI]  ⨯ Failed to start server
[UI] Error: listen EADDRINUSE: address already in use :::8675
[UI]     at <unknown> (Error: listen EADDRINUSE: address already in use :::8675)
[UI]     at new Promise (<anonymous>) {
[UI]   code: 'EADDRINUSE',
[UI]   errno: -98,
[UI]   syscall: 'listen',
[UI]   address: '::',
[UI]   port: 8675
[UI] }
[UI] next start --port 8675 exited with code 1

保持npm运行另起终端

sudo apt install net-tools
sudo netstat -tunlp | grep ':8675'
kill -9 470457

Diffusion推理加速的方案，主要包括Cache、量化、分布式推理、采样器优化和蒸馏等。下面内容主要是去对Cache、计算加速框架以及量化技术进行介绍

SD模型加速方式：https://github.com/xlite-dev/Awesome-DiT-Inference?tab=readme-ov-file#Quantization

不过值得注意的是对于下面内容，首先介绍加速框架（这部分内容主要是介绍进行加速的一些小trick，主要是直接通过api去加速）、cache以及量化一般就会涉及到一些算法的基本原理。所有的测试代码：df_acceralate.ipynb

一般加速框架以及显存优化措施

下面介绍的 flash-attn、torch.compile属于通用的加速策略（llm、扩散模型都可使用）

这部分内容的话比较杂（直接总结huggingface内容），1、直接使用attn计算加速后端，比如说一般就是直接使用比如说flash_attn进行attention计算加速，比如说：

pipeline.transformer.set_attention_backend("_flash_3_hub") # 启用flash attn计算加速
pipeline.transformer.reset_attention_backend()             # 关闭flash attn计算加速

不过值得注意的是_flash_3_hub 只支持非hopper架构，因此可以直接就使用set_attention_backend("flash")。2、直接使用torch.compile进行加速（对于 compile 原理解释: pytorch使用-1：🔥Pytorch使用-1：Pytorch计算图概念），不过值得注意的是在开始使用过程中会比较慢，因为在执行时，它会将模型编译为优化的内核，所以相对会比较慢，但是如果对编译后模型进行批量测试在时间上就会有所提升比如说在代码df_acceralate.ipynb中测试结果使用compile在z-image上生成5张图片耗时：86.49s（平均生图时间4s）不使用compile：29.92（平均生图时间5s）；3、使用torch.channels_last去优化数据结构（torch文档）：最主要的一点是通过channel_last让 GPU 在计算卷积 / attention 时，内存访问更连续，比如说一般数据的输入是NCHW那么在内存访问中格式是：N0C0H0W0, N0C0H0W1, ..., N0C0H1W0, ...这个里面通道C变化最慢，使用channel_list数据格式变为NHWC在内存中访问顺序是：N0H0W0C0, N0H0W0C1, N0H0W0C2, ...值得注意的是两部分数据在shape上是一致的只是strid不一致。使用方式也比较简单：

# 修改模型
model = model.to(memory_format=torch.channels_last)
# 修改输入
input = input.to(memory_format=torch.channels_last)
output = model(input)
...
pipeline.unet.to(memory_format=torch.channels_last)

1、xFormers加速

项目地址：https://github.com/facebookresearch/xformers

在SD模型中对于xformers基本使用方式如下所示：

import torch
from diffusers import StableDiffusionXLPipeline

pipeline = StableDiffusionXLPipeline.from_pretrained(
    "stabilityai/stable-diffusion-xl-base-1.0",
    torch_dtype=torch.float16,
).to("cuda")
# 使用xformer加速
pipeline.enable_xformers_memory_efficient_attention()
# 关闭xformer加速
pipeline.disable_xformers_memory_efficient_attention()

xformers作用在于加速attention计算并降低显存，除此之外还提供了多种注意力实现方式，如casual attention等。根据官方文档中的描述，对于对于xformers.ops.memory_efficient_attention在使用上参数主要是：1、输入数据也就是QKV的格式上必须满足为：[B, M, H, K]分别表示的是其中B 为batch size, N为序列长度, num_heads为多头注意力头的个数, dim_head则为每个头对应的embeding size；2、attn_bias实际上充当为在使用mask attention时的mask；3、p也就是dropout对应值；4、op为Tuple，用于指定优化self-attention计算所采用的算子。基本使用方式如下：

import xformers.ops as xops
y = xops.memory_efficient_attention(q, k, v)
y = xops.memory_efficient_attention(q, k, v, p=0.2) # 使用dropout
y = xops.memory_efficient_attention(
    q, k, v,
    attn_bias=xops.LowerTriangularMask()
)# 使用casual 注意力

值得着重了解的就是其中attn_bias参数，简单直观的理解：用于控制注意力可见性和结构的统一接口，既可以表示 mask，也可以表示稀疏/局部/因果等高级注意力模式，并且以高性能方式融入 attention 内核。比如说：
1、xops.LowerTriangularMask()：常规的causal注意力也就是下三角mask
2、xops.LocalAttentionFromBottomRightMask：局部注意力，每个token只能看最近的window_size个token

2、显存优化

这部分内容直接总结：https://huggingface.co/docs/diffusers/en/optimization/memory?device-map=pipeline+level#reduce-memory-usage

对于模型的显存过大可以考虑根据自身的设备进行分配，比如说将模型卸载到CPU或者将VAE等放到其它显卡上，在diffusers就提供了这些方法（这块内容直接问AI进行总结）：
1、CPU卸载
它启用了一种极致级别的逐层（leaf-level / sequential）CPU offloading机制，核心思路是：把模型的计算图中最底层的参数（leaf modules，即最细粒度的子模块、层或权重块）默认放在 CPU 内存里存储。在前向传播（forward pass）过程中，只在真正需要计算某个具体层的时候，才把那一小块参数临时从 CPU 拷贝（onload）到 GPU。计算完这层之后，立刻把这块参数再 offload 回 CPU，释放 GPU 显存。然后再加载下一层，以此类推，一层一层顺序执行（sequential）。

2、设备分配
这部分主要是将生成模型中不同模型结构如VAE、CLIP去分配到其它显卡上：

import torch
from diffusers import AutoModel, StableDiffusionXLPipeline
pipeline = StableDiffusionXLPipeline.from_pretrained(
    "stabilityai/stable-diffusion-xl-base-1.0",
    torch_dtype=torch.float16,
    device_map="balanced" # 使用balance就可以实现不同设备分配
)
print(pipeline.hf_device_map)
{'unet': 1, 'vae': 1, 'safety_checker': 0, 'text_encoder': 0}

亦或者直接自己定分配：

import torch
from diffusers import AutoModel
device_map = {
    'pos_embed': 0, 'time_text_embed': 0, 'context_embedder': 0, 'x_embedder': 0, 'transformer_blocks': 0, 'single_transformer_blocks.0': 0, 'single_transformer_blocks.1': 0, 'single_transformer_blocks.2': 0, 'single_transformer_blocks.3': 0, 'single_transformer_blocks.4': 0, 'single_transformer_blocks.5': 0, 'single_transformer_blocks.6': 0, 'single_transformer_blocks.7': 0, 'single_transformer_blocks.8': 0, 'single_transformer_blocks.9': 0, 'single_transformer_blocks.10': 1, 'single_transformer_blocks.11': 1, 'single_transformer_blocks.12': 1, 'single_transformer_blocks.13': 1, 'single_transformer_blocks.14': 1, 'single_transformer_blocks.15': 1, 'single_transformer_blocks.16': 1, 'single_transformer_blocks.17': 1, 'single_transformer_blocks.18': 1, 'single_transformer_blocks.19': 1, 'single_transformer_blocks.20': 1, 'single_transformer_blocks.21': 'cpu', 'single_transformer_blocks.22': 'cpu', 'single_transformer_blocks.23': 'cpu', 'single_transformer_blocks.24': 'cpu', 'single_transformer_blocks.25': 'cpu', 'single_transformer_blocks.26': 'cpu', 'single_transformer_blocks.27': 'cpu', 'single_transformer_blocks.28': 'cpu', 'single_transformer_blocks.29': 'cpu', 'single_transformer_blocks.30': 'cpu', 'single_transformer_blocks.31': 'cpu', 'single_transformer_blocks.32': 'cpu', 'single_transformer_blocks.33': 'cpu', 'single_transformer_blocks.34': 'cpu', 'single_transformer_blocks.35': 'cpu', 'single_transformer_blocks.36': 'cpu', 'single_transformer_blocks.37': 'cpu', 'norm_out': 'cpu', 'proj_out': 'cpu'
}
transformer = AutoModel.from_pretrained(
    "black-forest-labs/FLUX.1-dev", 
    subfolder="transformer",
    device_map=device_map,
    torch_dtype=torch.bfloat16
)

cache策略概述

cache指的是：缓存通过存储和重用不同层（例如注意力层和前馈层）的中间输出来加速推理，而不是在每个推理步骤执行整个计算。它以更多内存为代价显着提高了生成速度，并且不需要额外的训练。主要详细介绍两种：1、DeepCache；2、FORA。对于更加多的cache策略可以看知乎，推荐直接使用CacheDit来进行加速。

DeepCache策略

Paper:https://arxiv.org/pdf/2312.00858
Code:https://link.zhihu.com/?target=https%3A//github.com/horseee/DeepCache

主要针对UNet架构的Diffusion模型进行推理加速。DeepCache 是一种Training-free的扩散模型加速算法，核心思想是利用扩散模型序列去噪步骤中固有的时间冗余来减少计算开销。

基于 U-Net 结构特性，发现相邻去噪步骤的高层特征具有显著时间一致性（Adjacent steps in the denoising process exhibit significant temporal similarity in high-level features.），比如说上图中作者在测试上采用block $U_2$的特征和其它所有的采样步之间相似性计算（图b），因此缓存这些高层特征并仅以低成本更新低层特征，从而避免重复计算。具体方法为：

比如说在官方的使用中有参数：helper.set_params(cache_interval=3,cache_branch_id=0,)表示是每3个时间步进行一次完成forward然后刷新cache，而其中参数cache_branch_id值得是一般而言在UNet中会定义branch 0 → early / down blocks等就是选择哪些层的输出。具体过程如下：t=1进行计算缓存，t=2,3都直接使用缓存，t=4完整计算得到缓存。

FORA

Paper: https://arxiv.org/pdf/2407.01425
Code: https://github.com/prathebaselva/FORA

主要是争对Dit架构的Diffusion模型进行推理加速。利用 Diffusion Transformer 扩散过程的重复特性实现了可用于DiT的Training-free的Cache加速算法。

FORA的核心在于发现Dit在去噪过程中，相邻时间步的Attn和MLP层特征存在显著重复性（如上图所示:在layer0、9、18、27这些层以及250步采样中，随后采样步约往后特征之间相似性也就越高。）。通过Caching特征，FORA 将这些重复计算的中间特征保存并在后续时间步直接复用，避免逐步重新计算。

具体而言，模型以固定间隔 N 重新计算并缓存特征：当时间步 t 满足 t mod N=0 时，更新所有层的缓存；在后续 N-1 步中，直接检索cached的 Attn 和 MLP 特征，跳过重复计算。这种策略利用了 DiT 架构在邻近时间时间步的特征相似性，在不修改DiT模型结构的前提下实现加速。例如，在 250 步 DDIM 采样中，当 N=3 时，模型仅需在第 3、6、9… 步重新计算特征，其余步骤复用Cache，使计算量减少约 2/3。实验表明，FORA对后期去噪阶段的特征相似性利用更为高效，此时特征变化缓慢，缓存复用的性价比最高。

FBCache

项目地址：https://github.com/chengzeyi/ParaAttention/blob/main/doc/fastest_flux.md

通过缓存变换器模型中变换器块的输出，并在下一步推理中重新使用它们，可以降低计算成本，加快推理速度。然而，很难决定何时重新使用缓存以确保生成图像的质量。最近，TeaCache 提出，可以使用时间步嵌入来近似模型输出之间的差异。AdaCache 也表明，在多个图像和视频 DiT 基线中，缓存可以在不牺牲生成质量的情况下显著提高推理速度。不过，TeaCache 仍然有点复杂，因为它需要重新缩放策略来确保缓存的准确性。在 ParaAttention 中，发现可以直接使用第一个transformer输出的残差来近似模型输出之间的差异。当差值足够小时，我们可以重复使用之前推理步骤的残差，这意味着我们实际上跳过了去噪步骤。我们的实验证明了这一方法的有效性，我们可以在 FLUX.1-dev 推理上实现高达 1.5 倍的速度，而且质量非常好¹。
简单来说就是上面提到的DeepCache/FORA在使用上太粗糙直接通过固定时间步去cache缓存这样忽视输出差异的非均匀性，因此后续的TeaCache发现模型输入与输出的强相关性，通过Timestep Emebdding（输入）来估计输出差异。而后FBCache又做了新的改进：

利用residual cache实现了一个基于First Block L1误差的Cache方案，误差小于指定阈值，就跳过当前步计算，复用residual cache，对当前步的输出进行估计。

CacheDit

cache-dit这个框架主要是适用于Dit结构的扩散模型使用，其具体模型框架如下：

对于上述框架首先了解CacheDit中几个概念：1、Fn：表示需要计算前n层transformer block在时间步t计算得到结果；2、Bn:表示进一步的融合后n层transformer block的信息去强化预测准确性。其中n=1时候就是FBCache。
因此对于CacheDit具体过程为：在t-1步时候，前n块block去计算他们的结果得到输出结果hidden state并且写入缓存中$C_{t-1}$，而后后几层进行完整结算。在t步时候，前n块block不完整计算，而是直接复用/近似 t-1 步的缓存$C_{t-1}$得到近似的结果，计算近似结果和缓存结果中差异（L1 范数），如果差异小于阈值直接复用缓存输入到后续的块中计算，反之就重新计算这n块结果。
其中具体使用如下：df_acceralate.ipynb

简单总结上面过程就是，通过在前几个block（或第一个block）计算一个probe残差，然后与上一步缓存的残差做L1（或相对L1）差异比较，来决定当前步是否可以复用/跳过后续block的完整计算，从而实现加速。

扩散模型生成加速总结

本文主要是介绍一些在SD模型中加快生图的策略，1、直接使用加速框架进行优化，比如说指定attention计算后端方式、通过torch.compile进行编译、使用torch.channels_last去优化内存访问方式等；2、cache策略，发现在生成过程中在某些层/时间布之间图像的特征比较相似，因此就可以考虑将这些计算结果进行缓存在后续n步中直接加载缓存好的特征来实现生成加速，主要介绍框架是cache-dit；3、量化技术概述。最后简单对比一下生成加速时间

测试模型为Tongyi-MAI/Z-Image-Turbo测试prompt: 超写实亚洲中年男性，年龄约45-55岁。面容坚毅、憔悴，带有生活阅历的痕迹（如眼角的细纹）。他穿着质感柔软的深灰色高领毛衣，外搭一件经典的卡其色风衣，站在寒风中周围是高楼大厦
从测试结果上图像的差异还是不大，时间的话从5.97–>5.48（不一定严谨！）还是有效的

正常生图	+使用channel+ flash_attn	+使用cachedit
5.97	5.67	5.48

通用加速策略

指的是在扩散模型、LLM中都可以使用道德加速策略，因为在扩散模型生成加速中介绍到了使用 flash-attn 以及 torch.compile 这两部分也属于通用的加速策略因为在扩散模型中介绍了下面不重复介绍。

基于量化加速策略

量化技术是一种模型压缩的常见方法，将模型权重从高精度（如FP16或FP32）量化为低比特位（如INT8、INT4）去实现降低显存+生成加速。量化过程的基本范式，量化过程：$Q=\frac{W}{S}$ 其中 $S$ 表示scale，反量化过程：$\hat{w}=QS$，因此对于量化只需要保存：1、量化后权重；2、scale值（不同量化模型计算方式不同）。比如说（对称量化过程）对于：1.21, -1.13, 0.22, 0.83, 2.11, -1.53, 0.79, -0.54, 0.84其中最大值为2.11那么可以计算出缩放系数为：$\frac{2.11}{127}=0.01661417$（127代表int8数值范围-127，127）那么可以对数据缩放（量化）得到：72, -69, 13, 49, 127, -93, 47, -33, 50反量化可以得到：1.19622024,....（直接乘scale即可）具体计算数字之间差异，都是存在误差的。

常见的量化策略可以分为PTQ和QAT两大类。量化感知训练（QAT）：在模型训练过程中进行量化，一般效果会更好一些，但需要额外训练数据和大量计算资源比如说qlora（对模型权重NF4冻结，前向传播过程将NF4权重反量化到BF16计算完毕后丢弃，而Lora则是使用BF16进行训练）。后量化（PTQ）：在模型训练完成后，对模型进行量化，无需重新训练。对于线性量化下，浮点数与定点数之间的转换公式如下：$Q=\frac{R}{S}+Z;R=(Q-Z)*S$，其中R 表示量化前的浮点数、Q 表示量化后的定点数、S（Scale）表示缩放因子的数值、Z（Zero）表示零点的数值。除此之外

比如说在LLM中常用的两种后量化技术（具体介绍：模型量化操作————GPTQ和AWQ量化）：1、GPTQ量化技术：通过量化——补偿——量化迭代方法，首先量化$W_{:,j}$，而后去计算误差并且补充到 $W_{:,j:(i+B)}$而后进行迭代实现所有参数的量化；2、AWQ量化技术：模型计算过程中只有关键参数起作用因此对于关键参数保持原来的精度(FP16)，对其他权重进行低比特量化，但是这样不同进度参数会导致硬件问题，因此在AWQ中对所有权重均进行低比特量化，但是，在量化时，对于显著权重乘以较大的scale，相当于降低其量化误差；同时，对于非显著权重，乘以较小的scale，相当于给予更少的关注。

补充一个小知识，一般量化看到比较多就是W4A4这个一般指的就是权重和激活的4bit量化，其中权重一般就是对应该层的模型权重，激活就是对应该层的输入

还会听到几个概念：1、非对称量化：是一种用于将浮点数转换为整数表示的量化方法。与对称量化不同的是，这种方法在数据具有偏移（即非对称分布）时更有效，因为它可以减少量化误差。非对称量化会分别找出浮点数的最小值和最大值，分别量化到目标整数范围的最小值和最大值，充分利用量化后的整数范围。这可以使用一个缩放因子（scale）和偏移量（zero-point）来实现²。
对于非对称量化在量化过程中首先计算量化值： scale 简单计算过程为：$\text{scale}=\frac{x_{\max}- x_{\min}}{q_{\max}- q_{\min}}$ 而后去计算零点（zero_point）：$\text{zero_point}=\text{round}(q_{\min}-\frac{x_{\min}}{\text{scale}})$，在计算得到两部分量化值之后直接计算：$\text{quant_value}= \text{round}(\frac{fp16_value}{\text{scale}}+zero_point)$，返量化 就直接对上量化公式返计算即可。

2、对称量化：对称量化的核心思想是将浮点数量化为整数，且量化后的分布是关于零对称的，对称量化过程中零点呗固定一次只需要去计算缩放因子（scale）：$\text{scale}=\frac{\max(\vert x_{\min} \vert, \vert x_{\max} \vert) }{(q_{\max}-q_{\min})/2}$

bitsandbytes 量化

通过使用 bitsandbytes量化 来实现8-bit（int8）或者4-bit（int4、Qlora中一般就会使用）量化，不过区别上面提到的AWQ以及GPTQ量化，bitsandbytes不需要对模型进行训练（AWQ、GPTQ可能需要输入数据然后计算误差进行量化），前者需要通过数据来保证量化精度（量化过程是离线、一次性过程），后者量化过程是即时的可逆的。其技术原理如下（以对称量化过程为例）：$w≈s q$ 其中w表示原始的FP16权重，q代表int4/int8权重，s缩放因子，其量化过程为对每一个block权重计算：$\max(\text{abs}(w))$ 而后去计算scale：$s=\frac{amx(| w|)}{2^{b-1}-1}$ 而后代入公式就可以得到量化后权重，不过值得注意的是，在使用 Bitsandbytes 进行量化过程中对于上述提到参数计算过程：将权重 tensor 按固定块大小分割（默认 block_size=64 或 128 元素一块），每个块独立计算量化参数，在推理过程中进行：反量化 + 矩阵乘法融合在一个 CUDA kernel 中完成：$Y=X(sq)$。因此对于其使用也很简单，比如说在代码中：cache_acceralate.py

# 在ZImagePipeline中参数为：
class ZImagePipeline(DiffusionPipeline, ZImageLoraLoaderMixin, FromSingleFileMixin):
    def __init__(,..,vae, text_encoder, tokenizr, transformer):
        ...
# 因此可以直接对里面的text_encoder使用量化处理

from diffusers import BitsAndBytesConfig as DiffusersBitsAndBytesConfig
quantization_config = DiffusersBitsAndBytesConfig(
    load_in_4bit=True,# 在模型加载阶段，将权重以 4-bit 量化形式加载
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,# 指定 反量化后参与计算的 dtype
    bnb_4bit_use_double_quant=True,#启用 Double Quantization（双重量化），也就是对block的scale在进行一次量化
    llm_int8_skip_modules=["transformer_blocks.0.img_mod"],# 指定 不参与 bitsandbytes 量化的模块
)
transformer = AutoModel.from_pretrained(
    model_name,
    cache_dir=cache_dir,
    subfolder="transformer",
    quantization_config=quantization_config,
    torch_dtype=torch.bfloat16,
    device_map="auto",
    mirror='https://hf-mirror.com'
)

对你的model_name里面的transformer进行量化处理，除此之外还有使用例子就是进行优化器量化，比如说

# 和使用adamw方式一样，使用qlora使用一般带上这个优化器
import bitsandbytes as bnb
optimizer_class = bnb.optim.AdamW8bit

量化支持，在bitsandbytes量化中主要支持两种量化精度：int4（主要是用来qlora训练）和int8（主要是用来推理）对于两种量化方式代码使用上：

from transformers import BitsAndBytesConfig
# 8 bit 量化
quantization_config = BitsAndBytesConfig(load_in_8bit=True)

# 4 bit 量化
quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",           # 4bit 量化数据类型
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True
)

torchao 量化

上述过程中提到的bitsandbytes量化，在pytorch中支持原生的量化过程tochao（支持llm、扩散模型，并且在使用上区别 bitsandbytes 更加精细）在使用上也比较简单，只需要对上面 Bitsandbytes 量化代码中将 quantization_config 改成torchao所对应的量化即可，比如说：

from transformers import TorchAoConfig
from torchao.quantization import Float8DynamicActivationFloat8WeightConfig, quantize_
quant_type = Float8DynamicActivationFloat8WeightConfig(activation_dtype=torch.float8_e4m3fn,weight_dtype=torch.float8_e4m3fn)
quantization_config = TorchAoConfig(quant_type= quant_type,)
model = AutoModel.from_pretrained(...,quantization_config=quantization_config)

# 除此之外对于自己的模型量化直接使用：
quantize_(model, Float8DynamicActivationFloat8WeightConfig(granularity=PerTensor()))

然后将 from_pretrained 里面的 quantization_config 修改即可，在 torchao 中支持的量化方式有：

而对于 TorchAO 的量化核心基于仿射量化和 分组/通道级粒度（值得是在量化过程中对于 “数据选择”决定“多少个权重/激活值共享同一个缩放因子”的粗细程度 比如说 bitsandbytes 量化过程中直接是选择 block_size 而在 torchao 中支持 block_size/granularity=PerTensor()/granularity=PerRow()），底层依赖自定义内核（CUDA/XPU/CPU）与 inductor 编译器融合。除去上述量化方式 torchao 支持QAT（量化感知训练），根据官方描述：

TorchAO的QAT支持包含两个独立步骤：prepare 和 converted。准备步骤“假”是在训练过程中量化激活和/或权重，这意味着高精度值（例如bf16）会映射到对应的量化值，但实际上不会将其投射到目标的低精度d类型（例如int4）。训练后应用的转换步骤，将模型中的“假”量化操作替换为执行dtype铸造的“真实”量化。比如说下面代码：

from torchao.quantization import quantize_
from torchao.quantization.qat import QATConfig, IntxFakeQuantizeConfig

class SimpleModule(nn.Module):
    def __init__(self, input_dim, output_dim):
        super().__init__()
        self.fc = nn.Sequential(
            nn.Linear(input_dim, 128),
            nn.Linear(128, output_dim)
        )
    def forward(self, x):
        return self.fc(x)

activation_config = IntxFakeQuantizeConfig(torch.int8, "per_token", is_symmetric=False,)
weight_config = IntxFakeQuantizeConfig(torch.int4, group_size=32, is_symmetric=True,)
qat_config = QATConfig(activation_config=activation_config,weight_config=weight_config,step="prepare",)
quantize_(simple_model, qat_config)
...
base_config = Int4WeightOnlyConfig(group_size=32)
quantize_(compile_simple_model, QATConfig(base_config, step="convert"))

我的模型权重变化过程如下：

# 最开始模型层为
(0): Linear(in_features=32, out_features=1024, bias=True)
# prepare 处理得到模型为
(0): FakeQuantizedLinear(
      in_features=32, out_features=1024, bias=True
      (activation_fake_quantizer): FakeQuantizer(IntxFakeQuantizeConfig(dtype=torch.int8, granularity=PerToken(), mapping_type=<MappingType.ASYMMETRIC: 3>, scale_precision=torch.float32, zero_point_precision=torch.int32, zero_point_domain=<ZeroPointDomain.INT: 1>, is_dynamic=True, range_learning=False, eps=None))
      (weight_fake_quantizer): FakeQuantizer(IntxFakeQuantizeConfig(dtype=torch.int4, granularity=PerGroup(group_size=32), mapping_type=<MappingType.SYMMETRIC: 1>, scale_precision=torch.float32, zero_point_precision=torch.int32, zero_point_domain=<ZeroPointDomain.INT: 1>, is_dynamic=True, range_learning=False, eps=None))
    )
# convert 处理得到模型为
(0): Linear(in_features=32, out_features=1024, bias=True, weight=Int4Tensor(shape=torch.Size([1024, 32]), block_size=[1, 32], device=cuda:0, activation_dtype=torch.bfloat16))

从上面模型变化过程可以看到，在 prepare 阶段，会将模型进行fake包裹，而后通过训练得到量化的模型权重，再通过 convert 处理，将模型中的权重和激活值都进行了量化

GGUF

HF文档：https://huggingface.co/docs/hub/en/gguf
https://unsloth.ai/docs/basics/inference-and-deployment/saving-to-gguf

GGUF格式是用于存储大型模型预训练结果的，相较于Hugging Face和torch的bin文件，它采用了紧凑的二进制编码格式、优化的数据结构以及内存映射等技术，提供了更高效的数据存储和访问方式。GGUF 本身支持多种量化级别（Q2_K ~ Q8_0、IQ2 ~ IQ4 等），这些量化方式属于后训练量化（PTQ），和bitsandbytes 4bit 一样，都是在预训练模型上直接执行量化（不需要重新训练）。在GGUF中可以实现量化方式有两类：

传统Q系列（按照权重逐层量化）	K-Quant系列（通过 block-wise + scale 优化）

其中传统Q系列主要是一整块权重共享一个 scale（缩放因子），每个权重用低 bit 整数表示，容易受到极端值的影响。 K-Quant系列一个 block 内，再分“子块”，每个子块有自己的 scale，其中S代表子块少、scale少；M代表子块多、scale多。

SVDQuant量化

https://github.com/nunchaku-ai/nunchaku

在扩散模型中，权重（Weights）和激活（Activations）往往包含大量异常值（极端大或小的值），这些值在低位量化（如4-bit INT4）时会引起严重误差，导致生成的图像失真或噪声增多。

a：权重和激活值中都存在异常值，b：将激活值的异常值移动到权重中，c：将权重进行分解低秩的$L_1L_2$以及残差
其中对于b过程就是常见的SmoothQuant³量化过程

因此对于SVDQuant过程描述如下，对于权重和激活值：$\mathbf{W}$ 以及 $\mathbf{X}$，在最初这两部分值都是存在大量异常值，因此首先通过平滑操作（主要是让减少异常值让量化不会造成太大误差）将激活$\mathbf{X}$中的异常值迁移到权重 $\mathbf{X}$中得到更新后权重 $\hat{\mathbf{W}}$，这部分数据表述为：$\hat{\mathbf{W}}=\mathbf{W}\odot S$其中S是平滑因子，用于转移异常（⊙表示逐元素乘法）。这部分操作主要是因为：将异常值集中到权重侧，因为权重是静态的，更容易后续处理。激活侧的异常值减少后，量化难度降低。

而后，进行SVD分解与低秩吸收，对更新后权重进行奇异值分解：$ \hat{𝑾} = 𝑼 \Sigma 𝑽^T $, 其中𝑼和𝑽是正交矩阵，$\Sigma$是奇异值对角矩阵。保留前k个最大奇异值（低秩r，通常r « min(m,n)，其中m,n是权重矩阵维度），形成低秩近似：$ 𝑳_1 𝑳_2 = 𝑼[:,:r] \cdot \Sigma[:r,:r] \cdot 𝑽^T[:r,:] $。然后，计算残差：$ 𝑹 = \hat{𝑾} - 𝑳_1 𝑳_2$，其中只对残差$𝑹$进行量化（$Q(𝑹)=\text{round}(\frac{𝑹}{S_𝑹})S_𝑹$，其中$S_𝑹$为缩放因子）处理。低秩分支$ 𝑳_1 𝑳_2 $使用高精度（16-bit float）运行，专门“吸收”异常值和主要信息，而残差𝑹中的异常值和幅度显著减少，只需量化到4-bit。量化误差界限分析（从论文中）：量化误差上界可通过F范数和奇异值控制，证明低秩吸收后残差的量化难度降低（误差 ≤ $ \frac{\sqrt{\log(\text{size}(𝑹)\pi)}}{q_{\max}} \mathbb{E}[|𝑹|_F] $，其中q_max是量化最大值），最后的整体近似计算：

对于低秩分支 $L_1 L_2$可以无损的去拼接其它lora，因为输入 $\hat{X}$ 被平滑了因此直接量化误差不大

第一项是16-bit低秩分解，第二项为4-bit残差分支。简而言之上述过程为：首先利用平滑因子 $S$ 将激活值的离群值转移至权重 $\hat{W}$ 中；随后对 $\hat{W}$ 执行奇异值分解（SVD），提取承载异常特征的低秩分支 $L_1 L_2$；最后计算并量化残差矩阵 $R = \hat{W} - L_1 L_2$（因为提取低秩矩阵之后权重就相对平滑，那么对残差量化误差就比较小）其中，残差矩阵为INT4类型，低秩矩阵$L_1 L_2$为FP16。在推理时，权重 $\hat{W}$ 就可以直接变成 $\hat{W} =R+ L_1 L_2$

这里简单介绍一下如何使用SVDQuant量化后模型，一般而言不会去主动通过SVDQuant去量化模型（比如说量化Flux）会直接去加载量化后的模型，可以去huggingface-nunchakus里面找量化后的模型，对于comfyui使用可以直接nunchakus的comfyui去选择自己模型即可，如果纯代码使用可以

import torch
from diffusers import FluxPipeline

from nunchaku import NunchakuFluxTransformer2dModel
from nunchaku.lora.flux.compose import compose_lora
from nunchaku.utils import get_precision

precision = get_precision()  # auto-detect your precision is 'int4' or 'fp4' based on your GPU
transformer = NunchakuFluxTransformer2dModel.from_pretrained(
    f"nunchaku-tech/nunchaku-flux.1-dev/svdq-{precision}_r32-flux.1-dev.safetensors"
)
pipeline = FluxPipeline.from_pretrained(
    "black-forest-labs/FLUX.1-dev", transformer=transformer, torch_dtype=torch.bfloat16
).to("cuda")

### LoRA Related Code ###
composed_lora = compose_lora(
    [
        ("aleksa-codes/flux-ghibsky-illustration/lora.safetensors", 1),
        ("alimama-creative/FLUX.1-Turbo-Alpha/diffusion_pytorch_model.safetensors", 1),
    ]
)  # set your lora strengths here when using composed lora
transformer.update_lora_params(composed_lora)
### End of LoRA Related Code ###

image = pipeline(
    "GHIBSKY style, cozy mountain cabin covered in snow, with smoke curling from the chimney and a warm, inviting light spilling through the windows",  # noqa: E501
    num_inference_steps=8,
    guidance_scale=3.5,
).images[0]
image.save(f"flux.1-dev-turbo-ghibsky-{precision}.png")

整个过程中还是比较简单的，只不过值得注意的是，假如我的模型是int4量化后的权重，对于量化后的模型权重不能进行lora训练（精度丢失严重）那么直接对fp16的模型进行加载（如果显存不够，from_pretrained过程中可以使用BitsAndBytesConfig进行量化）而后通过Qlora进行微调这样得到的 LoRA 权重是全精度（通常 float16）的，不是量化过的。在comfyui中可以直接加载这个lora权重（将lora放到models/loras/中然后使用Nunchaku Flux LoRA Loader进行加载即可）。但是对于其它权重需要进行量化将其转化为nunchakus可以使用权重：

python -m nunchaku.lora.flux.convert \
    --lora-path xx.safetensor \
    --base-model xxx.safetensors \
    --output-dir ./tmp/ \
    --lora-name xx

上面几个参数分别表示lora、模型权重。
对于上述过程简单总结如下：首先在量化过程中激活值以及权重都存在异常值，这个异常值会导致后续量化后模型效果较差，因此首先是将激活值的异常值移动到权重中，而后将得到权重$\hat{W}$进行分解低秩的$L_1L_2$进而可以计算残差$R$，因此对于模型输出过程：$Y=XW=\hat{X}\hat{W}=\hat{X}(L_1L_2+Q(\hat{W}-L_1L_2))$其中$\hat{X}$表示平滑后的激活值，$L_1L_2$表示16-bit的分解矩阵，$Q(\hat{W}-L_1L_2)$表示4-bit低精度值

使用vllm

在对llm进行推理加速过程中比较常见的就是直接使用vllm进行推理加速，简单介绍一下vllm使用方式，分为两种：1、在线推理（而后本地可以直接通过类似Openai调用方式使用）；2、离线推理（一般在模型训练比如说GRPOTrainer过程中就会使用去生成）。对于两种方式的使用代码如下：

# 在线推理
"""
启动服务
HF_ENDPOINT=https://hf-mirror.com HF_HUB_CACHE=/root/autodl-tmp/.cache vllm serve Qwen/Qwen3-0.6B --host 0.0.0.0 --port 8001 --gpu-memory-utilization 0.5 --max-model-len 16384 --max-num-seqs 256 --trust-remote-code --served-model-name qwen3-0.6B
1、Qwen/Qwen3-0.6B 可以直接改为自己的模型文件夹
"""
llm = OpenAI(base_url="http://127.0.0.1:8001/v1", api_key="EMPTY")
completion = llm.chat.completions.create(...) # 得到输出
# 离线推理

from vllm import LLM, SamplingParams
llm = LLM(model=model_name_path,...)
sampling_params = SamplingParams(...)
outputs = llm.generate([prompt], sampling_params)

vllm不仅仅对llm可以起作用，在diffuseion model中也可以起作用，可以直接使用 vllm-omni⁴进行扩散模型加速推理其内部逻辑为：

在对比omni和diffusers在生成图像效果如下，测试代码：

测试参数为（具体设备为 vGPU-32G）：Klein4B、超写实亚洲中年男性，年龄约45-55岁。面容坚毅、憔悴，带有生活阅历的痕迹（如眼角的细纹）。他穿着质感柔软的深灰色高领毛衣，外搭一件经典的卡其色风衣，站在寒风中周围是高楼大厦、random_seed=416，直接运行10次测试平均省图时间

生成方式	正常生图	时间	cache_dit+ compile	时间
diffusers		2.478		2.101
vllm-omni		2.368		2.143

参考

Page Attention也是一种优化方法（区别于MLA，page attention是对内存进行分配管理）。参考论文¹中描述，对于KV-cache存在3个问题：

1、预留浪费 (Reserved)：为将来可能的 token 预留的空间，这些空间被保留但暂未使用，其他请求无法使用这些预留空间；
2、内部内存碎片化问题（internal memory fragmentation）：系统会为每个请求预先分配一块连续的内存空间，大小基于最大可能长度(比如2048个token)，但实际请求长度往往远小于最大长度，这导致预分配的内存有大量空间被浪费。
3、外部内存碎片化问题（external memory fragmentation）：不同内存块之间的零散空闲空间，虽然总空闲空间足够，但因不连续而难以使用。

只有 20.4%-38.2% 的token是被使用的，大部分都被浪费掉了。Page Attention允许在非连续的内存空间中存储连续的 key 和 value 。具体来说，Page Attention将每个序列的 KV-cache 划分为块，每个块包含固定数量 token 的键和值。在注意力计算期间，Page Attention内核可以有效地识别和获取这些块。如何理解上面描述呢？还是借用论文中的描述：

比如说按照上面Prompt要输出（假设只输出这些内容）：“fathers brought a car”，一般的套路可能是：比如说：“Four score and seven years ago our xxxxx”（xxx代表预留空间）因为实际不知道到底要输出多少文本，因此会提前预留很长的一部分空间（但是如果只输出4个字符，这预留空间就被浪费了），因此在page attention里面就到用一种“分块”的思想处理，以上图为例，分为8个Block每个Block只能存储4个内容，因此就可以通过一个Block Table来建立一个表格告诉那些Block存储了多少，存储满了就去其他Blobk继续存储。整个过程如下：

上述过程描述如下：具体而言，Page Attention 首先将 Key/Value 的连续显存空间划分为固定大小的 Block（页），每个 Block 作为最小的内存分配与调度单元。随后，引入一个 Block Table（页表） 来维护逻辑序列位置与物理 Block 之间的映射关系，用于记录每个 Block 当前的存储状态与可用容量。
一个小问题：分块之后注意力计算过程，因为我的KV被存储在不同的block中，由于Block table存在可以直接去索引不同Blcok中KV值，这样一来对于Q、K、V三者计算不成问题，不过关键问题就是：Softmax 的分母需要全局信息，Block （不管是Flash Attn还是Page Attn都需要面对这个问题）是分开的，怎么办？
在softmax计算过程中：$\sigma= \frac{e^{z_i}}{\sum_{j=1}^K e^{z_j}}$ 由于分块可能导致值过小进而导致数值溢出问题，除此之外计算需要所有token的分数一起归一化，因此首先会对上面的公式改进为：$\sigma= \frac{e^{z_i-m}}{\sum_{j=1}^K e^{z_j-m}}$也就是将每块都去减去当前的最大值（避免溢出问题）。在处理全局问题上：只需要考虑两个值的更新：1、当前最大值；2、归一化因子（$\sum_{j=1}^K e^{z_j-m}$）因此这个过程就可以处理为：

这样一来就可以转化为：$l_{t+1}=l_t e^{m_t-m_{t+1}}+ \sum_{i\in B_{t+1}}e^{z_j- m_{t+1}}$

基本使用方式

在使用vllm上有两种方式：1、离线使用；2、在线使用（直接将使用过程转化为调用API方式）：

from vllm import LLM, SamplingParams
prompts = ["Hello, my name is",
           "The president of the United States is",
           "The capital of France is",
           "The future of AI is",]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
llm = LLM(model="facebook/opt-125m")
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")

vllm整体框架分析

基于：Version: 0.17.0

在vllm中主要是两种调用方式：1、离线调用；2、在线调用（这个就类似在本地启动一个服务，而后其他及其直接访问ip端口等进行访问处理）

上图中在线调用方式（Asy）和离线调用（Syn）

对于具体的LLMEngine的结构描述见后面的描述

以离线调用方式进行解释，直接使用官方代码为例：

from vllm import LLM, SamplingParams
prompts = ["Hello, my name is",
           "The president of the United States is",
           "The capital of France is",
           "The future of AI is",]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
llm = LLM(model="facebook/opt-125m")
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")

从上面代码分析发现感觉和平时使用Transformer框架和相似：加载模型–>编码输入–>输入模型–>模型输出并且解码。差异在于使用vllm首先会使用一个LLM去处理你的模型，而后你其他的方式都是在这个LLM中，因此了解一下在模型接受到我的prompt之前模型都在做什么。

vllm初始化过程

按照PPT²中对于模型加载的描述：

在模型进行输出之前主要是进行3步：1、初始化并且加载模型；2、预分配显存过程；3、将预分配的KV Cache加载到gpu上。

模型初始化过程

在vllm中定义一个llm过程为：

# vllm/entrypoints/llm.py
class LLM:
    ...
    self.llm_engine = LLMEngine.from_engine_args(...)

# vllm/v1/engine/llm_engine.py
class LLMEngine:
    def __init__(...):
      self.engine_core = EngineCoreClient.make_client(...)
    def generate(...):
        ...
    def add_request(...):
        ...
# /vllm/v1/engine/core_client.py 中 EngineCoreClient通过多种（异步/多进程，这也就意味这在linux有些可能需要使用`multiprocessing.set_start_method('spawn', force=True)`）方式进行加载模型

在LLMEngine代码中定义了基本所有函数功能，如生成等（后续解释具体过程）。

预分配显存过程

这个给过程的的话首先是去计算预分配的KV Cache大小，而后将预分配的KV Cache加载（一般就是初始化为0的向量）到gpu上

• 计算预分配的KV Cache

计算预分配的KV Cache³：可用显存大小×预分配vllm比率- 非kv cache占用大小得到kv cache的可用（字节）大小，而后通过总共可用大小计算可用分多少个block：可分配大小//KV cache block 的字节大小//所有 kv_cache_groups中层数的最大值

在调用代码LLM(model="facebook/opt-125m")实际过程中会使用load_model进行模型加载（代码：vllm/v1/worker/gpu_model_runner.py）在加载模型之后，模型会进行一个显存的预分配处理，这个过程（代码：vllm/v1/core/kv_cache_utils.py）描述如下：
1、计算需要分配多少显存给vllm：*可用显存大小初始化分配大小（self.requested_memory=self.init_snapshot.total_memory * self.cache_config.gpu_memory_utilization，比说24G（实际可能比24G要小，因为还有模型占用）显卡那么的第一项结果就是：24*1024^3，后面一下就是最开始的参数）
2、计算分配给kv cache的显存占用字节大小：可以显存大小-除去KV cache显存外其他大小（self.available_kv_cache_memory_bytes = self.requested_memory - profile_result.non_kv_cache_memory） 在计算完毕之后（以上面模型加载为例，得到KV cache大小为：20.44GiB）接下来就是计算GPU上 KV Cache 内总token数量*：num_tokens = num_blocks // len(kv_cache_groups) * min_block_size
num_blocks计算过程：int(available_memory // page_size // num_layers)，其中page_size代表是一个 KV cache block 的字节大小（page_size =(K+V)$\times$ block_size$\times$ num_kv_heads$\times$ head_size$\times$ dtype_bytes= 2 * 16 * 12 * 64 2(其中fp16对应2)=49152，里面num_kv_heads对应你的模型结构使用数量）；num_layers：所有kv_cache_groups中层数的最大值，比如说在模型facebook/opt-125m中总共有12层decode（即 12 层进行注意力计算）并且这些attn计算方式完全相同那么就是1个group分组（如果还有其他attn那么可能就是多个group但是最后还是取最大值：group_size = max(len(group.layer_names) for group in kv_cache_groups)。最后计算得到结果为：num_blocks = 21946158284//49152// 12=37207。min_block_size = min([group.kv_cache_spec.block_size for group in kv_cache_groups]) 计算得到:16。

实际调试过程中（直接在需要调试位置使用logger.info），输出kv_cache_groups看到的比如（其实这个参数也就是记录cache需要发生位置，一般就是attn计算，不过可能对于不同的attn存在差异，有些是常规有些有可能是window-attn等）：[KVCacheGroupSpec(layer_names=['model.decoder.layers.0.self_attn.attn', ..., 'model.decoder.layers.11.self_attn.attn'], kv_cache_spec=FullAttentionSpec(block_size=16, num_kv_heads=12, head_size=64, dtype=torch.float16, sliding_window=None, attention_chunk_size=None))] 除此之外这部分结果会直接存入KVCacheConfig中。在后续代码（vllm/v1/worker/gpu_model_runner.py）中对于initialize_kv_cache（具体解释见下面）还会为每一块model.decoder.layers.0.self_attn.attn取分配一个初始化（具体函数：initialize_kv_cache_tensors）为0的向量大小为：[2, num_blocks, block_size, num_kv_heads, head_size]

因此最后就可以直接得到：num_tokens = 37207// 1*16 = 595,312。

• 将预分配的KV Cache加载到gpu上

在上述步骤中计算得到了预分配的KV cache大小以及num blocks，接下来就是直接将其先放置到gpu上，实现显存的预分配，以后这块显存就是专门用来做KV Cache。具体过程中还是使用上面得到的kv_cache_groups这个参数

# vllm/v1/worker/gpu_model_runner.py
def initialize_kv_cache_tensors(self, kv_cache_config: KVCacheConfig):
    # Initialize the memory buffer for KV cache
    kv_cache_raw_tensors = self._allocate_kv_cache_tensors(kv_cache_config)
    # Change the memory buffer to the desired shape
    kv_caches = self._reshape_kv_cache_tensors(kv_cache_config, kv_cache_raw_tensors)
    ...
    num_attn_module = 2 if self.model_config.hf_config.model_type == "longcat_flash" else 1
    bind_kv_cache(kv_caches,
                  self.compilation_config.static_forward_context,
                  self.kv_caches, num_attn_module)
    return kv_caches

def _allocate_kv_cache_tensors(self, kv_cache_config: KVCacheConfig):
    kv_cache_raw_tensors: dict[str, torch.Tensor] = {}
    logger.info(kv_cache_config)
    for kv_cache_tensor in kv_cache_config.kv_cache_tensors:
        tensor = torch.zeros(kv_cache_tensor.size,
                             dtype=torch.int8,
                             device=self.device)
        for layer_name in kv_cache_tensor.shared_by:
            kv_cache_raw_tensors[layer_name] = tensor
    ...
    return kv_cache_raw_tensors

对于参数KVCacheConfig就是上面的kv_cache_groups结果，只不过还会取计算每层的大小也就是会更新为：KVCacheConfig(num_blocks=37207, kv_cache_tensors=[KVCacheTensor(size=1828798464, shared_by=['model.decoder.layers.0.self_attn.attn']), ..., KVCacheTensor(size=1828798464, shared_by=['model.decoder.layers.11.self_attn.attn'])], kv_cache_groups=[KVCacheGroupSpec(layer_names=['model.decoder.layers.0.self_attn.attn', ...,'model.decoder.layers.10.self_attn.attn', 'model.decoder.layers.11.self_attn.attn'], kv_cache_spec=FullAttentionSpec(block_size=16, num_kv_heads=12, head_size=64, dtype=torch.float16, sliding_window=None, attention_chunk_size=None))])
对于里面size计算：num_blocks × block_size × num_kv_heads × head_size × dtype_bytes × 2 (K + V)

不过值得注意的是对于上面KVCacheConfig定义了一个获取LLM中所有attn 层的 KV cache 该怎么组织、分组、分配内存的全局蓝图，还是用上面例子，num_blocks表示分配得到显存切分了多少个block，kv_cache_groups表示分层了多少组（如果有sliding-window这些可能又是新的一组），得到KVCache信息之后就可以对应的去初始化一些张量去占用显存，在函数self._allocate_kv_cache_tensors中很容易理解直接初始化一个全部为0的张量，而后再去通过函数_reshape_kv_cache_tensors将张量的形状改为[num_blocks, block_size, num_kv_heads, head_size]

vllm简单使用

vllm使用主要有两种主流方式：1、在线；2、离线两种对于这两种的代码如下：1、离线推理使用；2、在线推理使用，除此之外有些时候模型训练过程中可能需要进行模型lora测试，如果用transformers自己的生成框架速度很慢，可以考虑使用vllm来进行生成（就像GRPOTrainer中一样），不过需要注意显存的占用（特别是单卡下，多卡就可以专门用一张卡去做推理）消耗，因为vllm初始化过程对于显存占用会比较大，下面主要是争对单卡下的vllm离线使用，最简单方式可以直接使用下面代码（可以直接使用trl中vllm代码/或者直接自己定义），具体的代码位置：trl/generation/vllm_generation.py

from trl.generation.vllm_generation import VLLMGeneration
# 初始化vllm 参数配置可以参考 GRPOTrainer 中的过程
vllm_generation = VLLMGeneration(
    model=your_hf_model,               # 模型
    accelerator=xxx,
    is_fsdp_enabled=True/False,
    processing_class=xxx, # 编码器
    
    gpu_memory_utilization=0.35,       # 单卡关键，调低留空间给训练
    tensor_parallel_size=1,
    enforce_eager=True,                # 推荐单卡防冲突
    enable_lora=True,                  # 如果你用 LoRA
    max_loras=1,
    max_lora_rank=你的rank,
    distributed_executor_backend="external_launcher",  # colocate 必备
    enable_sleep_mode=True, # 启动sleep vllm生成完毕后就直接休眠避免显存占用
    # 生成参数设置
    repetition_penalty=xxx, # 重复度
    temperature=xxx, # 采样温度
    top_p=xxx,
    top_k=xxx,
    min_p=xxx,
    max_completion_length=xxx,
    logprobs=0,  # we only need the generated token logprobs for the importance sampling correction
    generation_kwargs=xxx,
)
# 同步lora效果
vllm_generation.sync_weights()
# 模型生成
outputs = vllm_generation.generate(prompts_or_messages, sampling_params)

除此之外对于

总结

本文主要是简单介绍了一些vllm的显存分配过程中，主要是记住几个关键参数：1、预分配显存：可用显存大小×预分配vllm比率- 非kv cache占用大小；2、在预分配的显存下可以分配出多少个block：int(available_memory // page_size // num_layers) 对于里面的page_size=(K+V) $\times$ block_size（这个参数一般是指定默认是16）$\times$ num_kv_heads$\times$ head_size$\times$ dtype_bytes，num_layers：所有kv_cache_groups中层数的最大值；3、而后就是直接去计算KV Cache中总token数量这部分计算过程是：num_tokens = num_blocks // len(kv_cache_groups) * min_block_size。
在获取预分配的显存大小之后，vllm对显存占用方式直接去获取llm结构中“所有的attention”中规则，比如说attention计算发生的层以及给该层预分配的大小最后再去初始化0的张量进行显存占用即可。

参考

SD WebUI 安装使用

SD WebUI官方地址：https://github.com/AUTOMATIC1111/stable-diffusion-webui里面关于安装的介绍不多，这里直接介绍在Linux上直接安装并且基础使用。
首先、克隆仓库到本地

# 直接从Github
git clone git@github.com:AUTOMATIC1111/stable-diffusion-webui.git
# 直接从 Gitee（f非官方）
git clone git@gitee.com:smallvillage/stable-diffusion-webui.git

在clone得到文件之后对Stable Diffusion WebUI文件夹基本介绍如下¹：
1、文本到图像的目录 (outputs/txt2img-images): 存储从文本描述生成的图像。这类目录通常用于保存用户输入文本提示后，系统生成的图像。
2、图像到图像的目录 (outputs/img2img-images): 存储基于现有图像进行修改或再创作后生成的新图像。这是用于图像编辑或风格迁移任务的输出位置。
3、附加或实验性质的输出目录 (outputs/extras-images): 可能用于存储实验性或不符合主要类别的其他图像生成结果。
4、文本到图像网格的目录 (outputs/txt2img-grids): 存储以网格形式展示的多个文本到图像的生成结果，这对于一次性查看和比较多个图像特别有用。
5、图像到图像网格的目录 (outputs/img2img-grids): 存储以网格形式展示的多个图像到图像的生成结果，同样便于比较和展示。
6、图像生成日志目录 (log/images): 存储与图像生成过程相关的日志信息，这对于调试和分析生成过程非常重要。
7、初始化图像的目录 (outputs/init-images): 用于保存在图像到图像转换过程中使用的初始图像或源图像。
根目录
.launcher：可能包含与项目启动器相关的配置文件。
__pycache__：存储 Python 编译过的字节码文件，以加快加载时间。
config_states：可能用于存储项目配置的状态或历史版本。
configs：用于存放配置文件，通常包含项目运行所需的参数设置。
detected_maps：可能存储自动生成的映射或检测结果。
embeddings：可能包含用于机器学习的嵌入向量数据。
extensions 和 ` extensions_builtin ：存储项目的扩展或插件。 git：通常是 Git 版本控制的相关目录。 html、 javascript ：存储网页前端相关的 HTML 文件和 JavaScript 脚本。 launcher：可能包含启动项目的脚本或可执行文件。 localizations：包含项目的本地化文件，如翻译或语言资源。 log：存储日志文件，记录项目运行时的活动或错误信息。 models：通常用于存储机器学习模型或项目中使用的数据模型。 modules：包含项目的代码模块或组件。 outputs：存储项目运行产生的输出文件，如生成的图像或报告。 py310：可能指 Python 3.10 版本的特定文件或环境。 repositories：可能用于存储与代码仓库相关的数据。 scripts：包含用于项目构建、部署或其他自动化任务的脚本。 tags：可能用于版本标记或注释。 test：存储测试代码和测试数据。 textual_inversion：可能是一个特定的功能模块，用于文本相关的处理或转换。 textual_inversion_templates：存储文本逆向工程或模板化处理的文件 tmp：临时文件夹，用于存储临时数据或运行时产生的临时文件。 得到内容之后直接去修改stable-diffusion-webui/modules/patches.py`里面的

# data_path = cmd_opts_pre.data_dir
# models_path = cmd_opts_pre.models_dir if cmd_opts_pre.models_dir else os.path.join(data_path, "models")
data_path = '/root/autodl-tmp/SDWebUIFile/data'
models_path = '/root/autodl-tmp/SDWebUIFile/models'

去避免文件直接都下载到本地环境，除此之外在webui.sh里面直接去第一行添加venv_dir="/root/autodl-tmp/SDWebUIFile/venv"（避免虚拟环境直接装在本地）准备工作做完之后就可以直接运行sh文件

cd stable-diffusion-webui/
# source /etc/network_turbo 如果使用 autodl 服务器
bash webui.sh -f # 加 -f 这个参数如果你是 root 用户使用这个参数避免

添加 -f 是因为他不支持ERROR: This script must not be launched as root, aborting...

安装完毕之后基本就可以直接访问本地地址http://127.0.0.1:7860/然后进行生成图片了。

SD WebUI 其他模型安装

执行上面操作之后 SD WebUI会默认安装一个模型，不过这个模型效果不是很好，那就需要去安装其他模型，具体操作如下：比如说我需要安装这两个模型：dreamshaperXL_sfwV2TurboDPMSDE.safetensors和 sdxl_vae.safetensors那么只需要去huggingface上去找到指定权重然后下载（可以直接将huggingface改为国内镜像地址，但是autodl可以直接 source /etc/network_turbo可以加速Github和Huggingface）即可：

建议直接使用镜像进行下载具体操作：huggingface镜像然后看方法三即可
./hfd.sh lllyasviel/ControlNet-v1-1 --include control_v11e_sd15_ip2p.pth control_v11e_sd15_ip2p.yaml --local-dir /root/autodl-tmp/SDWebUIFile/models/ControlNet
值得注意的是上面代码如果 include 是一个文件夹那么会直接带着文件夹一起下载，比如说
./hfd.sh lllyasviel/ControlNet --include annotator/ckpts/dpt_hybrid-midas-501f0c75.pt --local-dir /root/autodl-tmp/SDWebUIFile/data/extensions/sd-webui-controlnet/annotator/downloads/midas/
可能就需要去移动到指定目录：mv /root/autodl-tmp/SDWebUIFile/data/extensions/sd-webui-controlnet/annotator/downloads/midas/annotator/ckpts/dpt_hybrid-midas-501f0c75.pt /root/autodl-tmp/SDWebUIFile/data/extensions/sd-webui-controlnet/annotator/downloads/midas/

# 安装 huggingface-cli
pip install -U huggingface_hub
# 登录 下面操作可能因为 huggingface_hub版本不一致不用 可能直接使用 hug_cli 而不是 hf
hf auth login
# 下载所有权重
hf download Madespace/Checkpoint --local-dir ~/autodl-tmp/SDWebUIFile/models/Stable-diffusion/
# 下载部分权重
hf download Madespace/Checkpoint dreamshaperXL_sfwV2TurboDPMSDE.safetensors --local-dir ~/autodl-tmp/SDWebUIFile/models/Stable-diffusion/
hf download stabilityai/sdxl-vae sdxl_vae.safetensors --local-dir ~/autodl-tmp/SDWebUIFile/models/Stable-diffusion/

执行上面处理就可以在SD WebUI里面看到自己下载的权重了

SD WebUI 插件安装使用

对于SD WebUI插件主要介绍两种：1、汉化插件；2、ControlNext插件
安装汉化插件

项目地址：https://github.com/hanamizuki-ai/stable-diffusion-webui-localization-zh_Hans

操作步骤：第一步：安装插件

当下面出现：AssertionError: Extension directory already exists: /root/autodl-tmp/SDWebUIFile/data/extensions/stable-diffusion-webui-localization-zh_Hans时候就代表安装完毕，然后就可以直接去进行下面步骤

第二步：启用插件
然后就可以正常安装了，然后就需要去seeting–>User interface，然后在这个界面选择中文即可（一定要先点击Apply）

最后Reload UI即可，这样界面就变成中文了。
ControlNet 插件安装
基本安装步骤和上面的一样，只是不需要进行第二步：启用插件了。安装ControNet插件之后就只需要去安装对应的模型权重即可使用插件。如果按照上面步骤修改了地址那么：

(base) root@xxxx:~/autodl-tmp/SDWebUIFile/models# ls
Codeformer  ControlNet  GFPGAN  Lora  Stable-diffusion  hypernetworks

然后对于ControlNet权重就可以直接下载然后放到ControlNet中即可，比如说下载

就只需要：

hf download lllyasviel/sd_control_collection diffusers_xl_canny_full.safetensors --local-dir /root/autodl-tmp/SDWebUIFile/models/ControlNet
hf download lllyasviel/sd_control_collection diffusers_xl_depth_full.safetensors --local-dir /root/autodl-tmp/SDWebUIFile/models/ControlNet

具体使用可以见：https://zhuanlan.zhihu.com/p/692537570

SD WebUI API调用

执行完毕上面操作之后既可以直接调用API进行处理了（bash webui.sh -f --api启用API访问）然后可以直接使用 requests方式进行访问，具体例子比如说：用上面下面的control_v11e_sd15_ip2p.pth和 control_v11f1p_sd15_depth.pth进行测试实验，具体代码：code，值得注意的是：

最终得到效果如下

ComfyUI 基础使用

教程：https://www.bilibili.com/video/BV14w41167eZ/?vd_source=881c4826193cfb648b5cdd0bad9f19f0对于ComfyUI只需要了解如下几个点：1、如何API调用；2、如何自定义节点；3、工作流搭建（这个直接多看几个别人的就会了）

对于ComfyUI不需要看太多视频，简单总结使用就是：在ComfyUI中所有的运行过程都是在 工作流 上进行运行，而工作流中每一个“方框”就是我们的 节点（可以意见为一个函数有与输入和输出），不同节点之间输入接输出。

ComfyUI 自定义节点

自定义节点之前，先了解安装节点，直接进入ComfyUI里面的节点目录/root/autodl-tmp/ComfyUI/custom_nodes，然后找到你需要安装的节点 clone到这个文件夹里面，然后安装依赖，就可以完成一个节点的安装了，推荐安装节点：ComfyUI-LG_HotReload避免每次更新节点都需要去重启服务。自定义节点过程²。这里直接给出一个比较简洁的模板去自定义节点，首先在ComfyUI/custom_nodes文件中创建一个节点名称（名字任取）文件夹，而后再去创建一个__init__.py文件，以及你的节点功能文件，比如说sam_node.py，对于这两个文件，前者主要是用来将你的节点暴露给comfyui让他可以找到你的节点，后者则是你的节点的功能实现。比如说我要做一个onefromer+sam去图像分割的节点那么就可以按照下面过程进行。
首先，明确我的函数需要的输入和返回。对于图像分割那么输入就是原始图像，而输出一般就是mask图像。那么对于sam_node.py就可以这么定义：

class OneformerSAMNode:
def __init__(self):
  ....
@classmethod
def INPUT_TYPES(cls):
return {
"required": {
"image": ("IMAGE",),
"oneformer_model": (["oneformer_large", "oneformer_tiny"], {"default": "oneformer_large"}),
"sam_model": (["vit_b", "vit_l"], {"default": "vit_l"}),
"processor_resolution": ("INT", {"default": 512, "min": 256, "max": 1024, "step": 64}),
}
}
RETURN_TYPES = ("IMAGE", "MASK", "BOOLEAN")
RETURN_NAMES = ("mask_image", "mask", "is_empty")
FUNCTION = "detect"
CATEGORY = "image/empty_detect"

def detect(self, image, oneformer_model, sam_model, processor_resolution):
  ...
  return (mask_image, mask, is_empty)

对于上述函数，INPUT_TYPES里面定义了节点的输入，RETURN_TYPES定义了节点的输出，FUNCTION定义了节点的功能，CATEGORY定义了节点的分类。
而后，在定义函数之后就只需要让comfyui去找到这个节点，那么就需要在__init__.py文件中进行如下定义：

from .comfyui_node import NODE_CLASS_MAPPINGS as EMPTY_DETECT_MAPPINGS, NODE_DISPLAY_NAME_MAPPINGS as EMPTY_DETECT_DISPLAY

# 合并所有节点映射
NODE_CLASS_MAPPINGS = {}
NODE_CLASS_MAPPINGS.update(EMPTY_DETECT_MAPPINGS)

NODE_DISPLAY_NAME_MAPPINGS = {}
NODE_DISPLAY_NAME_MAPPINGS.update(EMPTY_DETECT_DISPLAY)

# ComfyUI 会自动导入这些映射
__all__ = ['NODE_CLASS_MAPPINGS', 'NODE_DISPLAY_NAME_MAPPINGS']

参考

量化：是一种模型压缩的常见方法，将模型权重从高精度（如FP16或FP32）量化为低比特位（如INT8、INT4）。常见的量化策略可以分为PTQ和QAT两大类。量化感知训练（Quantization-Aware Training）：在模型训练过程中进行量化，一般效果会更好一些，但需要额外训练数据和大量计算资源。后量化（Post-Training Quantization, PTQ）：在模型训练完成后，对模型进行量化，无需重新训练。
因此对于量化过程总结为：将数值精度进行“校准”（比如FP32转化到INT8，两种表述范围不同，因此就需要将前者校准到后者范围），对“校准”数据进行精度转化。对于线性量化下，浮点数与定点数之间的转换公式如下：$Q=\frac{R}{S}+Z;R=(Q-Z)*S$，其中R 表示量化前的浮点数、Q 表示量化后的定点数、S（Scale）表示缩放因子的数值、Z（Zero）表示零点的数值。

量化浮点数格式：FP64、FP32、FP16、BF16等
FP以及BF之间差异就在于尾数数量上差异，除此之外在混合精度训练中也有直接使用FP16精度进行模型训练，不过FP8一般在计算过程中进行使用，模型的存储等还是使用FP16，之所以使用FP8主要还是为了节约显存加速训练，除此之外在FP8格式设计上争对不同阶段有：E4M3（表示值±448）和E5M2（表示值±57344）前面一种更加适合前向传播后面更加适合反向传播。除此之外在训练过程中使用FP8在对最后模型质量的变化差异不大¹，在保证FP8训练过程中稳定：1、Per-tensor / per-block scaling（张量级 / 小块级缩放）：每个权重矩阵 / 激活张量都有自己独立的缩放因子（scale），让 FP8 的动态范围“对齐”当前数据的实际分布，最大限度减少量化误差。2、Delayed scaling / delayedamax：不实时计算 scale，而是累积几步历史最大值再更新，避免 scale 抖动太大导致不稳定

模型量化具体实现过程（直接使用：https://zhuanlan.zhihu.com/p/646210009中的描述）：
对称量化中，零点 Z = 0，一般不记录，我们只需要关心如何求解 Scale。由于 weight 几乎不存在异常值，因此我们可以直接取 Scale 为一个 layer 或 block 内所有参数的最大绝对值，于是所有的参数都在 [-1, 1] 的区间内。随后，这些参数将找到最近的量化格点，并转化成定点数。

推荐进一步阅读：https://www.big-yellow-j.top/posts/2025/12/29/SDAcceralate.html

GPTQ量化技术

GPTQ²是一种用于大型语言模型（LLM）的后训练量化技术。它通过将模型权重从高精度（如FP16或FP32）压缩到低比特（如3-4位整数）来减少模型大小和内存占用，同时保持较高的推理准确性。一般而言对于量化过程为：对于给定的权重矩阵$W\in R^{n\times m}$，量化过程就是需要找到一个低比特的矩阵$\hat{W}$使得：

其中$X$为输入向量，$\Vert. \Vert_F$为Frobenius范数。按照论文里面的描述GPTQ整个过程为：

实际使用LLMCompressor进行模型量化过程中，$\lambda$对应参数dampening_frac可能（$W8A8$）会出现：Failed to invert hessian due to numerical instability. Consider increasing GPTQModifier.dampening_frac, increasing the number of calibration samples, or shuffling the calibration dataset其主要原因是计算Hessian矩阵出现严重病态（ill-conditioned）或接近奇异/非正定时，Cholesky 分解就会失败，抛出数值不稳定错误。因此就可以根据里面建议：增加数据、增加$\lambda$的值

对于具体数学原理的描述参考文章³⁴（数学原理推荐直接看：GPTQ详细解读），简单总结一下上面过程就是：1、每行独立计算二阶海森矩阵。2、每行按顺序进行逐个参数量化，从而可以并行计算。3、按block维度进行更新，对剩余参数进行延迟更新弥补。4、对逆海森矩阵使用cholesky分解，等价消除迭代中的矩阵更新计算。它的核心流程其实就是量化-补偿-量化-补偿的迭代（具体过程见流程图中内部循环：首先量化$W_{:,j}$，而后去计算误差并且补充到 $W_{:,j:(i+B)}$），具体的代码实现过程（官方GPTQ-Github）主要是对其中LlamaAttention和LlamaMLP层中的Linear层权重进行量化。代码处理过程⁵：
首先、计算Hessian矩阵（因为后续计算损失和补偿权重需要，因此提前计算矩阵） 这个矩阵近似：$H_F=2X_FX_F^T$（$X$是经过前面几层神经网络之后，到达被量化层的激活）。实现方式是在每一层Layer上注册hook，通过hook的方式在layer forward后使用calibration data的input来生成Hessian矩阵，这种计算方式常见于量化流程中校准数据的处理

def add_batch(name):
    def tmp(_, inp, out):
        # 假设过程为：x → Linear(W) → ReLU
        # x →inp[0].data Linear层输出→out
        gptq[name].add_batch(inp[0].data, out.data)
    return tmp
handles = []
# 添加hook
for name in subset:
    handles.append(subset[name].register_forward_hook(add_batch(name)))
# 处理样本计算数据
for j in range(args.nsamples):
    outs[j] = layer(inps[j].unsqueeze(0), attention_mask=attention_mask, position_ids=position_ids)[0]
# 去除hook
for h in handles:
    h.remove()

在add_batch中具体为了利用所有的校准数据，这里通过迭代的方式将每组数据计算的Hessian矩阵值进行求和然后取平均，代码实现是迭代逐渐平均叠加的过程，Hessian矩阵求解公式：$H_F=2X_FX_F^T$

# 假设过程为：x → Linear(W) → ReLU
# x →inp[0].data Linear层输出→out
#gptq[name].add_batch(inp[0].data, out.data)
def add_batch(self, inp, out):
    ...
    if len(inp.shape) == 2:
        inp = inp.unsqueeze(0)
    tmp = inp.shape[0]
    if isinstance(self.layer, nn.Linear) or isinstance(self.layer, transformers.Conv1D):
        if len(inp.shape) == 3:
            inp = inp.reshape((-1, inp.shape[-1]))
        inp = inp.t()
    if isinstance(self.layer, nn.Conv2d):
        unfold = nn.Unfold(
            self.layer.kernel_size,
            dilation=self.layer.dilation,
            padding=self.layer.padding,
            stride=self.layer.stride
        )
        inp = unfold(inp)
        inp = inp.permute([1, 0, 2])
        inp = inp.flatten(1)
    self.H *= self.nsamples / (self.nsamples + tmp)
    self.nsamples += tmp
    inp = math.sqrt(2 / self.nsamples) * inp.float()
    self.H += inp.matmul(inp.t())

其次、逐层weight量化

for name in subset:
    gptq[name].fasterquant(
        percdamp=args.percdamp, groupsize=args.groupsize, actorder=args.act_order, static_groups=args.static_groups
    )
    quantizers['model.layers.%d.%s' % (i, name)] = gptq[name].quantizer
    gptq[name].free()

主要是通过逐层使用fasterquant方法作为入口来进行量化处理。fasterquant 用层的权重矩阵 W 和之前收集到的激活 Gram（或近似 Hessian）H 来做按列（按 block）贪心量化。它先把 H 经过阻尼并通过 Cholesky/逆操作得到用于投影/补偿的因子（称为 Hinv），然后按 block 内逐列量化：对第 j 列量化后计算误差 e_j，用 Hinv 的相应行/列把这个误差按 Schur 补方式投影/传播到该 block 内剩余列并在 block 外一次性传播到后续列，从而实现 GPTQ 的误差补偿策略。在fasterquant方法中主要进行了量化的计算过程，具体实现过程为（核心代码）：

def fasterquant(
    self, blocksize=128, percdamp=.01, groupsize=-1, actorder=False, static_groups=False
):
    W = self.layer.weight.data.clone()
    if isinstance(self.layer, nn.Conv2d):
        W = W.flatten(1)
    if isinstance(self.layer, transformers.Conv1D):
        W = W.t()
    W = W.float()

    tick = time.time()

    if not self.quantizer.ready():
        self.quantizer.find_params(W, weight=True)

    # self.H 是上一步中计算得到的Hessian矩阵
    H = self.H
    del self.H
    dead = torch.diag(H) == 0
    H[dead, dead] = 1
    W[:, dead] = 0

    ...
    # 初始化 losses 0矩阵
    Losses = torch.zeros_like(W)
    Q = torch.zeros_like(W)

    damp = percdamp * torch.mean(torch.diag(H))
    diag = torch.arange(self.columns, device=self.dev)
    H[diag, diag] += damp
    H = torch.linalg.cholesky(H)
    H = torch.cholesky_inverse(H)
    H = torch.linalg.cholesky(H, upper=True)
    Hinv = H
    # 逐Block处理
    # self.columns = W.shape[1]
    for i1 in range(0, self.columns, blocksize):
        i2 = min(i1 + blocksize, self.columns)
        count = i2 - i1

        W1 = W[:, i1:i2].clone()
        Q1 = torch.zeros_like(W1)
        Err1 = torch.zeros_like(W1)
        Losses1 = torch.zeros_like(W1)
        Hinv1 = Hinv[i1:i2, i1:i2]
        # Block内部量化
        for i in range(count):
            w = W1[:, i]
            d = Hinv1[i, i]

            if groupsize != -1:
                if not static_groups:
                    if (i1 + i) % groupsize == 0:
                        self.quantizer.find_params(W[:, (i1 + i):(i1 + i + groupsize)], weight=True)
                else:
                    idx = i1 + i
                    if actorder:
                        idx = perm[idx]
                    self.quantizer = groups[idx // groupsize]

            q = quantize(
                w.unsqueeze(1), self.quantizer.scale, 
                self.quantizer.zero, self.quantizer.maxq
            ).flatten()
            Q1[:, i] = q
            Losses1[:, i] = (w - q) ** 2 / d ** 2

            err1 = (w - q) / d
            W1[:, i:] -= err1.unsqueeze(1).matmul(Hinv1[i, i:].unsqueeze(0))
            Err1[:, i] = err1

        Q[:, i1:i2] = Q1
        Losses[:, i1:i2] = Losses1 / 2

        W[:, i2:] -= Err1.matmul(Hinv[i1:i2, i2:])
    torch.cuda.synchronize()
    ...

    if actorder:
        Q = Q[:, invperm]

    if isinstance(self.layer, transformers.Conv1D):
        Q = Q.t()
    self.layer.weight.data = Q.reshape(self.layer.weight.shape).to(self.layer.weight.data.dtype)

对于上面过程主要是看两个for循环的里面内容，首先第一个for循环去根据block去将权重矩阵W进行分块拆分（W1 = W[:, i1:i2].clone()），接下来第二个for循环依次去对第1块中每列进行量化，第i列进行量化（quantize）处理（q = quantize(...)），而后去计算loss并且去对其他的列（i:）计算W1[:, i:] -= err1.unsqueeze(1).matmul(Hinv1[i, i:].unsqueeze(0))，在处理完毕第1块之后再去将后面块的列进行误差补偿（W[:, i2:] -= Err1.matmul(Hinv[i1:i2, i2:])），这样整个过程就完成了。

# 量化函数
def quantize(x, scale, zero, maxq):
    if maxq < 0:
        return (x > scale / 2).float() * scale + (x < zero / 2).float() * zero
    q = torch.clamp(torch.round(x / scale) + zero, 0, maxq)
    return scale * (q - zero)

最后、量化模型保存 。之前的步骤中量化和反量化后计算lose都是浮点位数的，所以并没有生成wbit位format的数值内容，在llama_pack方法中通过model和之前得到的quantizer(scale, zero)来生成wbit位数表达格式的量化模型，其定义如下所示

def llama_pack3(model, quantizers):
    layers = find_layers(model)
    layers = {n: layers[n] for n in quantizers}
    make_quant3(model, quantizers)
    qlayers = find_layers(model, [Quant3Linear])
    for name in qlayers:
        quantizers[name] = quantizers[name].cpu()
        # 使用 Quant3Linear 进行pack处理
        qlayers[name].pack(layers[name], quantizers[name].scale, quantizers[name].zero)
    return model
# 将model中每一层都替换为 Quant3Linear
def make_quant3(module, names, name='', faster=False):
    if isinstance(module, Quant3Linear):
        return
    for attr in dir(module):
        tmp = getattr(module, attr)
        name1 = name + '.' + attr if name != '' else attr
        if name1 in names:
            setattr(module, attr, Quant3Linear(tmp.in_features, tmp.out_features, faster=faster))
    for name1, child in module.named_children():
        make_quant3(child, names, name + '.' + name1 if name != '' else name1, faster=faster)
...
if args.wbits < 16 and not args.nearest:
    quantizers = llama_sequential(model, dataloader, DEV)
if args.save:
    llama_pack3(model, quantizers)

其中quantizers来自量化后的返回，它是一个dict里面保存了每一个层和它对应的quantizer、scale、zero、group_idx等信息，其中quantizer是layer-level的，zero和scale是group-level的。

quantizers的结果为：quantizers['model.layers.%d.%s' % (i, name)] = (gptq[name].quantizer.cpu(), scale.cpu(), zero.cpu(), g_idx.cpu(), args.wbits, args.groupsize)

Quant3Linear具体处理过程（代码），通过qweight、zeros和scales、bias等属性来保存量化后的低比特信息。：

# qlayers[name].pack(layers[name], quantizers[name].scale, quantizers[name].zero)
class Quant3Linear(nn.Module): 
    def __init__(self, infeatures, outfeatures, faster=False):
        super().__init__()
        self.register_buffer('zeros', torch.zeros((outfeatures, 1)))
        self.register_buffer('scales', torch.zeros((outfeatures, 1)))
        self.register_buffer('bias', torch.zeros(outfeatures))
        self.register_buffer(
            'qweight', torch.zeros((infeatures // 32 * 3, outfeatures), dtype=torch.int)
        )
        self.faster = faster

    def pack(self, linear, scales, zeros):
        self.zeros = zeros * scales
        self.scales = scales.clone()
        if linear.bias is not None:
            self.bias = linear.bias.clone()

        intweight = torch.round((linear.weight.data + self.zeros) / self.scales).to(torch.int)
        intweight = intweight.t().contiguous()
        intweight = intweight.numpy().astype(np.uint32)
        qweight = np.zeros(
            (intweight.shape[0] // 32 * 3, intweight.shape[1]), dtype=np.uint32
        )

        i, row = 0, 0
        while row < qweight.shape[0]:
            # 把 32 个 3-bit 整数按位连续打包到 3 个 uint32
            ...
        qweight = qweight.astype(np.int32)
        self.qweight = torch.from_numpy(qweight) 

对于上述打包（3-bit打包）处理过程为：qweight = np.zeros((intweight.shape[0] // 32 * 3, intweight.shape[1]), dtype=np.uint32)每 32 个 intweight 的行使用 3 个 uint32 行来存储，不过值得注意的是以 int32 的形式存储量化权重，但这 并不代表每个权重占 32 bit。这里的 int32 是一个打包容器（bit-packing container），里面塞了多个低 bit（比如 3 bit）的权重值。

AWQ量化技术

AWQ量化⁶（逐层量化方法，需要每层的输入激活来计算 scale 和 clip 值）是一种基于激活值分布挑选显著权重进行量化的方法，其不依赖于任何反向传播或重建，因此可以很好地保持LLM在不同领域和模式上的泛化能力，而不会过拟合到校准集，属训练后量化大类，论文里面出发点就是模型的权重并不同等重要，仅有0.1%-1%的小部分显著权重对模型输出精度影响较大。因此如果能有办法只对0.1%~1%这一小部分权重保持原来的精度(FP16)，对其他权重进行低比特量化，就可以在保持精度几乎不变的情况下，大幅降低模型内存占用，并提升推理速度。

但是如果部分用FP16而其他的用INT3这样就会导致硬件上存储困难（图b情况），因此作者使用的操作就是：对所有权重均进行低比特量化，但是，在量化时，对于显著权重乘以较大的scale，相当于降低其量化误差；同时，对于非显著权重，乘以较小的scale，相当于给予更少的关注。因此代码关注点就是找到这个scale值

基于激活值分布挑选方法：激活值指的是与权重矩阵运算的输入值，比如说：$V=W_vX$其中的 $X$就是权重 $W_v$的激活值，按激活值绝对值大小由大到小排序，绝对值越大越显著，选择前0.1%~1%的元素作为显著权重。
具体代码过程（Github-Code）

首先是获取 模型第一层的输入激活值，供后续的逐层量化使用，代码整体流程如下（核心代码格式）：

@torch.no_grad()
def run_awq(model,enc,w_bit,q_config,n_samples=512,seqlen=512,auto_scale=True,mse_range=True,calib_data="pileval",):
    ...

    layers = get_blocks(model)
    samples = get_calib_dataset(...)
    # 得到第一层的激活值
    inps = []
    layer_kwargs = {}

    layers[0] = layers[0].cuda()
    ...
    class Catcher(nn.Module):
        def __init__(self, module):
            super().__init__()
            self.module = module

        def forward(self, inp, **kwargs):
            inps.append(inp)
            layer_kwargs.update(kwargs)
            raise ValueError
    layers[0] = Catcher(layers[0])
    try:
        if model.__class__.__name__ == "LlavaLlamaModel":
            model.llm(samples.to(next(model.parameters()).device))
        ...
    except ValueError:
        pass
    ...
    layers[0] = layers[0].module
    inps = inps[0]
    layers[0] = layers[0].cpu()
    ...

而后、逐层进行量化处理，在AWQ量化过程中需要记录两部分量化值scale（auto_sclae.py） 和 clip（auto_clip.py）两部分具体源码处理过程都是相似的先去计算scale值而后将scale值应用，在计算两部分值之前和GPTQ处理相似去记录forward过程，具体代码为：

for i in tqdm.tqdm(range(len(layers))):
    layer = layers[i]
    layer = layer.cuda()
    named_linears = get_named_linears(layer)
    
    # AWQ量化过程中，记录输入数据
    def cache_input_hook(m, x, y, name, feat_dict):
        x = x[0]
        x = x.detach().cpu()
        feat_dict[name].append(x)
        
    input_feat = defaultdict(list)
    handles = []
    for name in named_linears:
        handles.append(
            named_linears[name].register_forward_hook(
                functools.partial(cache_input_hook, name=name, feat_dict=input_feat)
            )
        )
        
    inps = inps.to(next(layer.parameters()).device)
    # 输入数据被 线性层 处理触发上面的 hook 去记录每层的输入 x
    inps = layer(inps, **layer_kwargs)[0]
    for h in handles:
        h.remove()
    input_feat = {k: torch.cat(v, dim=0) for k, v in input_feat.items()}

其中cache_input_hook过程就是直接记录每层layer中的linear层的输入值并且将其记录到input_feat中。scale处理过程（寻找最有因子过程）代码如下：

elif isinstance(module, (LlamaDecoderLayer, Qwen2DecoderLayer)):
    # attention input
    scales_list.append(
        _auto_get_scale(
            prev_op=module.input_layernorm,
            layers=[
                module.self_attn.q_proj,
                module.self_attn.k_proj,
                module.self_attn.v_proj,
            ],
            inp=input_feat["self_attn.q_proj"],
            module2inspect=module.self_attn,
            kwargs=module_kwargs,
        )
    )

'''
_auto_get_scale 中核心逻辑是使用 search_module_scale 并且其中4个参数分别对应
block = module2inspect=module.self_attn 
linears2scale = [module.self_attn.q_proj, module.self_attn.k_proj, module.self_attn.v_proj]
x = input_feat["self_attn.q_proj"]
'''
def _search_module_scale(block, linears2scale: list, x, kwargs={}):
    # block：对应block linears2scale：对应线性层
    x = x.to(next(block.parameters()).device)
    
    # 第一步，将数据数据用没有被量化的模型进行一次计算，并且计算 平均幅度（x_max）
    with torch.no_grad():
        org_out = block(x, **kwargs)
        ...
    x_max = get_act_scale(x) # x.abs().view(-1, x.shape[-1]).mean(0)

    best_error = float("inf")
    best_ratio = -1
    best_scales = None
    
    # 第二步，直接用网格搜索方法去寻找最优的 scale
    n_grid = 20
    history = []
    org_sd = {k: v.cpu() for k, v in block.state_dict().items()}
    for ratio in range(n_grid):
        ratio = ratio * 1 / n_grid
        # 计算当前比例的缩放因子，并且进行归一化处理
        scales = x_max.pow(ratio).clamp(min=1e-4).view(-1)
        scales = scales / (scales.max() * scales.min()).sqrt()
        
        # 进行一次模拟量化操作
        for fc in linears2scale:
            # 物理缩放权重：把激活值的压力转移到权重上
            fc.weight.mul_(scales.view(1, -1).to(fc.weight.device))
            # 模拟量化：量化后再除以 scales 还原回浮点域
            fc.weight.data = w_quantize_func(fc.weight.data) / (scales.view(1, -1))
        out = block(x, **kwargs) # 计算量化后的模型输出
        ...
        loss = ((org_out - out).float().pow(2).mean().item()) # 计算损失
        is_best = loss < best_error
        if is_best:
            ...
            best_scales = scales
        # 恢复到最初状态，去寻找下一个 ratio
        block.load_state_dict(org_sd)
    ...
    best_scales = best_scales.view(-1)
    ...
    return best_scales.detach()

对所有权重均进行低比特量化，但是，在量化时，对于显著权重乘以较大的scale，相当于降低其量化误差；同时，对于非显著权重，乘以较小的scale，相当于给予更少的关注

其实对于上面过程就是直接通过网格搜索策略通过得到的x_max=x.abs().view(-1, x.shape[-1]).mean(0)去不断尝试scales去让loss最小，从而得到scale值。对于其中的量化处理过程w_quantize_func，核心是计算 $q=clip(round(\frac{w}{s}​)+z,q_{min}​,q_{max}​)$：

'''
w_quantize_func(fc.weight.data) / (scales.view(1, -1))
w 对应 fc.weight.data) / (scales.view(1, -1)
'''
def pseudo_quantize_tensor(w, n_bit=8, zero_point=True, q_group_size=-1, inplace=False, get_scale_zp=False):
    org_w_shape = w.shape
    if q_group_size > 0:
        assert org_w_shape[-1] % q_group_size == 0
        w = w.reshape(-1, q_group_size)
    assert w.dim() == 2
    if zero_point: 
        max_val = w.amax(dim=1, keepdim=True)
        min_val = w.amin(dim=1, keepdim=True)
        max_int = 2**n_bit - 1
        min_int = 0
        scales = (max_val - min_val).clamp(min=1e-5) / max_int
        zeros = (-torch.round(min_val / scales)).clamp_(min_int, max_int)
    else:  ... # 对称量化
    ...
    if inplace:...
    else:
        w = (
            torch.clamp(torch.round(w / scales) + zeros, min_int, max_int) - zeros
        ) * scales
    assert torch.isnan(w).sum() == 0
    w = w.reshape(org_w_shape)
    if get_scale_zp:...
    else:
        return w

对于上面过程总结就是：把 w 线性映射到一个由 bit 位数（n_bit）决定的固定整数区间（q_min 到 q_max），其中scale 决定缩放比例，zero_point 决定映射偏移

总结

GPTQ量化技术总结：核心流程其实就是量化-补偿-量化-补偿的迭代，首先通过对模型权重$W$首先去对$W$进行分块拆分得到不同的block再去到每一个block里面去按照每i列进行量化（quantize）处理（q = quantize(...)），而后去计算loss并且去对其他的列（i:）计算W1[:, i:] -= err1.unsqueeze(1).matmul(Hinv1[i, i:].unsqueeze(0))，在处理完毕第1块之后再去将后面块的列进行误差补偿（W[:, i2:] -= Err1.matmul(Hinv[i1:i2, i2:])），这样就得到了scales, zeros这信息，在去使用这些信息去对模型权重进行转化intweight = torch.round((linear.weight.data + self.zeros) / self.scales).to(torch.int)，最后就是用32 个intweight的行使用 3 个 uint32 行来存储，推理过程的话：$y = Wx + b\rightarrow y≈x(s_j(q-z_j))+b$
AWQ量化技术总结：核心流程就是对所有权重均进行低比特量化，但是，在量化时，对于显著权重乘以较大的scale，相当于降低其量化误差；同时，对于非显著权重，乘以较小的scale，相当于给予更少的关注，对于这个scale值的寻找直接计算每一层的输入“激活值”（x.abs().view(-1, x.shape[-1]).mean(0)）而后对这个激活值通过网格搜索方法（scales = x_max.pow(ratio).clamp(min=1e-4).view(-1)其中ratio对应网格收缩）不断去尝试不同的scale，并且将这个scale去用到最初的模型权重上进行一次模拟量化处理，而后去计算 模拟量化后模型计算得到的损失和没有量化的模型之间损失，找到这个最佳scale即可。

代码操作

Github-code
模型ONNX部署技术

直接使用llmcompressor来量化模型（具体地址：llmcompressor）支持量化类型：

推荐进一步阅读：https://www.big-yellow-j.top/posts/2025/12/29/SDAcceralate.html

参考

QwenVL的基本使用

1、模板化模型输入

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "image",
                "image": "https://qianwen-res.oss-cn-beijing.aliyuncs.com/Qwen-VL/assets/demo.jpeg",
            },
            {"type": "text", "text": "Describe this image."},
        ],
    }
]

text = processor.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)

所谓模板化模型的输入，很容易理解（通过processor.apply_chat_template把对话 messages 转成模型能理解的 prompt，不过值得注意的是不同模型可能处理的方式不同），就是将我的内容“填充”到模板中模拟对话内容，比如说上面处理得到的一个简单结果就是：

<|im_start|>system
You are a helpful assistant.<|im_end|>
<|im_start|>user
<|vision_start|><|image_pad|><|vision_end|>Describe this image.<|im_end|>
<|im_start|>assistant

一般在data_loader里面就会提前将我们的模型需要的输入处理好，比如说我们定义如下的模板

def format_data(self, image, text, prompt):
    # self.SYSTEM_MESSAGE = """You are a helpful assistant."""
    return [
        {
            "role": "system",
            "content": [{"type": "text", "text": self.SYSTEM_MESSAGE}],
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "image": image,
                },
                {
                    "type": "text",
                    "text": prompt
                },
            ],
        },
        {
            "role": "assistant",
            "content": [{"type": "text", "text": text}],
        },
    ]
""" 
<|im_start|>system
You are a helpful assistant.<|im_end|>
<|im_start|>user
<|vision_start|><|image_pad|><|vision_end|>This is a prompt<|im_end|>
<|im_start|>assistant
This is a text<|im_end|>
<|im_start|>assistant
"""

对于上面内容输出理解，首先 <|im_start|>....<|im_end|>一般是一组“发言”的开始和结束标记，而后里面内容就是我们的文本/图像内容，user/ assistant/ system 则是分别代表：用户、模型、角色（告诉模型今天扮什么角色）。<|vision_start|>...<|vision_end|>：表示图像输入的占位符，告诉模型这里有一段视觉信息。<|image_pad|>：图像实际的 embedding 会在这里替换（填充），不是文字，而是图像编码后的向量。值得注意的是 assistant后面的内容就是 模型需要输出的文本内容。上面过程很容易理解，只不过需要注意如下问题，因为QwenVL2.5对于分辨率是存在处理（一般直接通过smart_resize处理，后续有介绍），因此如果涉及到目标识别，可能需要提前将坐标进行转换避免分辨率不同导致bbox对应不上的问题

2、编码模板输入

image_inputs, video_inputs = process_vision_info(messages)
inputs = processor(
    text=[text],
    images=image_inputs,
    videos=video_inputs,
    padding=True,
    return_tensors="pt",
)

编码模板输入就比较简单，因为我的输入都是文本/图片，此过程就是需要将这些内容转化为编码形式（比如tokenizer处理等），处理方式如下：

• 1、process_vision_info:返回我的图像/视频输出（都存储在list中）

首先是过extract_vision_info从我上面的内容中提取出图片/视频（[{'type': 'image', 'image': 'https://qianwen-res.oss-cn-beijing.aliyuncs.com/Qwen-VL/assets/demo.jpeg'}]）提取完毕之后就是交给处理图片/视频的函数进行处理
图片处理过程（fetch_image）此过程也会比较简单，首先去判断类型（是Image.Image对象/图片链接等）然后打开图片，而后就是确定图片分辨率尺寸，有两种smart_resize处理方式，第一种是直接通过：resized_height 和 resized_width来确定改变，另外一种直接通过 min_pixels 和 max_pixels 来处理图像尺寸。对于smart_rezie函数处理过程为：

def smart_resize(
    height: int, width: int, factor: int = IMAGE_FACTOR, min_pixels: int = MIN_PIXELS, max_pixels: int = MAX_PIXELS)
    # IMAGE_FACTOR= 28
    if max(height, width) / min(height, width) > MAX_RATIO:
        ...
    h_bar = max(factor, round_by_factor(height, factor)) # round(number / factor) * factor
    w_bar = max(factor, round_by_factor(width, factor))
    if h_bar * w_bar > max_pixels:
        beta = math.sqrt((height * width) / max_pixels)
        h_bar = floor_by_factor(height / beta, factor) # 按比例缩小并向下取整  math.floor(number / factor) * factor
        w_bar = floor_by_factor(width / beta, factor)
    elif h_bar * w_bar < min_pixels:
        beta = math.sqrt(min_pixels / (height * width))
        h_bar = ceil_by_factor(height * beta, factor) # 按比例放大并向上取整 math.ceil(number / factor) * factor
        w_bar = ceil_by_factor(width * beta, factor)
    return h_bar, w_bar

上面3个小的子函数表示：计算factor倍数、向上取整计算倍数、向下取整计算倍数，对于smart_resize（去实现动态分辨率）函数：通过四舍五入的方式，重新设置图片的 h 和 w 值，确保它们可以被28整除，这样一来就得到了图像的需要修改的尺寸了，比如说：
输入: 一张 1000x500 的图像
计算基础尺寸：round(1000/28)=36, round(500/28)=18 → 1008x504
检查像素数：1008504 = 508,032 > MAX_PIXELS(200,704)
计算缩放系数：beta = sqrt(1000500/200704) ≈ 1.58
最终尺寸：floor(1000/1.58)=632, floor(500/1.58)=316 → 616x308（28的倍数）
视频处理过程（fetch_video）对于视频处理和图像处理相类似打开–>改变尺寸。只不过在打开过程中QwenLV2.5处理过程为：

def fetch_video(ele: dict, image_factor: int = IMAGE_FACTOR, return_video_sample_fps: bool = False):
    if isinstance(ele["video"], str):
        video_reader_backend = get_video_reader_backend()
        try:
            video, sample_fps = VIDEO_READER_BACKENDS[video_reader_backend](ele)
        except Exception as e:
            logger.warning(f"video_reader_backend {video_reader_backend} error, use torchvision as default, msg: {e}")
            video, sample_fps = VIDEO_READER_BACKENDS["torchvision"](ele)
    ...

对于VIDEO_READER_BACKENDS设计了3中不同范式：1、_read_video_decord；2、_read_video_torchvision；3、_read_video_torchcodec。

• _read_video_decord

def _read_video_decord(
    ele: dict,
) -> (torch.Tensor, float):
    """read video using decord.VideoReader

    Args:
        ele (dict): a dict contains the configuration of video.
        support keys:
            - video: the path of video. support "file://", "http://", "https://" and local path.
            - video_start: the start time of video.
            - video_end: the end time of video.
    Returns:
        torch.Tensor: the video tensor with shape (T, C, H, W).
    """
    import decord
    video_path = ele["video"]
    st = time.time()
    vr = decord.VideoReader(video_path)
    total_frames, video_fps = len(vr), vr.get_avg_fps()
    start_frame, end_frame, total_frames = calculate_video_frame_range(
        ele,
        total_frames,
        video_fps,
    ) # 得到视频的开始 结束 总结多少帧
    nframes = smart_nframes(ele, total_frames=total_frames, video_fps=video_fps)
    idx = torch.linspace(start_frame, end_frame, nframes).round().long().tolist()
    video = vr.get_batch(idx).asnumpy()
    video = torch.tensor(video).permute(0, 3, 1, 2)  # Convert to TCHW format
    ...
    sample_fps = nframes / max(total_frames, 1e-6) * video_fps
    return video, sample_fps

对于其中的 calculate_video_frame_range函数处理过程也很简单（直接去计算视频开始、结束、总共多少帧），而后类似动态分辨率（smart_resize中成立相类似的）对于视频会通过智能视频帧数计算算法（smart_nframes），用于确定从视频中提取多少帧作为模型输入，处理过程为：第一种直接通过round_by_factor(ele["nframes"], FRAME_FACTOR)来得到帧数；第二种处理方式为（FPS_MIN_FRAMES = 4、FRAME_FACTOR = 2、FPS_MAX_FRAMES = 768、FPS = 2.0）：

fps = ele.get("fps", FPS)
min_frames = ceil_by_factor(ele.get("min_frames", FPS_MIN_FRAMES), FRAME_FACTOR)
max_frames = floor_by_factor(ele.get("max_frames", min(FPS_MAX_FRAMES, total_frames)), FRAME_FACTOR)
nframes = total_frames / video_fps * fps
nframes = min(min(max(nframes, min_frames), max_frames), total_frames)
nframes = floor_by_factor(nframes, FRAME_FACTOR)

"""
config = {"nframes": 24}
result = smart_nframes(config, total_frames=100, video_fps=30)
# 输出：24（直接使用配置值）

config = {"fps": 10, "min_frames": 16, "max_frames": 32}
result = smart_nframes(config, total_frames=100, video_fps=30)
# 计算：100/30*10 ≈ 33.33 → 约束到32 → 对齐到32（FRAME_FACTOR=8的倍数）
"""

• 2、processor：去将图片/文本进行编码

其中对于文本编码直接通过 self.tokenizer 来处理，而对于图像直接通过 self.image_processor来处理。首先在 代码中很容易看到使用的图像/文本处理方式image_processor_class = "AutoImageProcessor" 对于文本处理方式 tokenizer_class = ("Qwen2Tokenizer", "Qwen2TokenizerFast")。
对于图片处理方式的 Qwen2VLImageProcessor（代码）的处理思路：

class Qwen2VLImageProcessor(BaseImageProcessor):
    def __init(...):
        ...
    def _preprocess(self, images, ...):
        ...
        height, width = get_image_size(images[0], channel_dim=input_data_format)
        resized_height, resized_width = height, width
        processed_images = []
        # Step-1
        for image in images:
            if do_resize:
                resized_height, resized_width = smart_resize(
                    height,
                    width,
                    factor=self.patch_size * self.merge_size,
                    min_pixels=self.min_pixels,
                    max_pixels=self.max_pixels,
                )
                image = resize(
                    image, size=(resized_height, resized_width), resample=resample, input_data_format=input_data_format
                )
            if do_rescale:
                image = self.rescale(image,...)
            if do_normalize:
                image = self.normalize(image,...)
        # Step-2
        patches = np.array(processed_images)
        if data_format == ChannelDimension.LAST:
            patches = patches.transpose(0, 3, 1, 2)
        if patches.shape[0] % self.temporal_patch_size != 0:
            # 视频补帧处理
            repeats = np.repeat(patches[-1][np.newaxis], self.temporal_patch_size - 1, axis=0)
            patches = np.concatenate([patches, repeats], axis=0)
        # 计算不同 patch 网格大小
        channel = patches.shape[1]
        grid_t = patches.shape[0] // self.temporal_patch_size
        grid_h, grid_w = resized_height // self.patch_size, resized_width // self.patch_size

        patches = patches.reshape(
            grid_t,
            self.temporal_patch_size,
            channel,
            grid_h // self.merge_size,
            self.merge_size,
            self.patch_size,
            grid_w // self.merge_size,
            self.merge_size,
            self.patch_size,
        )
        patches = patches.transpose(0, 3, 6, 4, 7, 2, 1, 5, 8)
        flatten_patches = patches.reshape(
            grid_t * grid_h * grid_w, channel * self.temporal_patch_size * self.patch_size * self.patch_size
        )

        return flatten_patches, (grid_t, grid_h, grid_w)

对于上面处理过程中，首先对于 _preprocess主要是对图像进行一些预处理：1、do_resize：改变图片大小（直接通过smrt_resize进行处理）2、do_rescale：像素缩减到0-1之间；3、do_normalize：对图片进行归一化处理（通道维度）；而后直接对于预处理后的图像直接进行切割处理为不同的patch输入到Vit中。
回顾一下QwenVL2.5的图片处理过程：首先是去对图片进行改变尺寸（保证图片最后可以整除patch_size）/缩放/归一化。而后就是直接将图片处理为vit能够处理的“序列输入”得到的维度为：[grid_t * grid_h * grid_w, channel * temporal_patch_size(2) * patch_size(14) * patch_size(14)]。

补充一：图片输入具体例子说明
假设默认参数为：patch_size= 14, temporal_patch_size= 2, merge_size= 2
图像输入为（通过process_vision_info提前处理之后的维度）：(1092, 1568)
首先计算 resized_height, resized_width = smart_resize得到 812 1176
首先计算：grid_t=1，grit_h=812//14=58，grid_w=1176//14=84那么计算得到为 4872另外一项为 1176也就是最后图像处理得到的输出为：(1*58*84, 14*14*2*3)=(4872,1176)
补充二：对于 smart_resize快速估算最后大小：
先 round 到 factor 的倍数
如果超出 max_pixels → 除以 sqrt(HW/max_pixels)，floor → factor 倍数
如果小于 min_pixels → 乘以 sqrt(min_pixels/HW)，ceil → factor 倍数
其实也就是：首先将图像处理到为factor倍数的分辨率，而后去判断和max_pixels和min_pixels之间大小，大于前者就缩小，小于前者就放大

最后通过一系列编码之后得到输出：

inputs = processor(
    text=[text],
    images=image_inputs,
    videos=video_inputs,
    padding=True,
    return_tensors="pt",
)
"""
input_ids: torch.Size([1, 1243])
attention_mask: torch.Size([1, 1243])
pixel_values: torch.Size([4872, 1176])
image_grid_thw: torch.Size([1, 3])
"""

3、模型输入处理

generated_ids = model.generate(**inputs, max_new_tokens=128)

整体模型输入处理，输入模型也就是上面编码模板输入几个部分，只不过主要就是如下几个处理：首先是模型处理输入 input_ids 以及我的图像 pixel_values（inputs_embeds = self.model.embed_tokens(input_ids)代码），而后将输入进行位置编码处理（代码），最后输出模型结果（代码），对于QwenVL2.5完整模型结构：

Qwen2_5_VLForConditionalGeneration(
  (model): Qwen2_5_VLModel(
    (visual): Qwen2_5_VisionTransformerPretrainedModel(
      (patch_embed): Qwen2_5_VisionPatchEmbed(
        (proj): Conv3d(3, 1280, kernel_size=(2, 14, 14), stride=(2, 14, 14), bias=False)
      )
      (rotary_pos_emb): Qwen2_5_VisionRotaryEmbedding()
      (blocks): ModuleList(
        (0-31): 32 x Qwen2_5_VLVisionBlock(
          (norm1): Qwen2RMSNorm((1280,), eps=1e-06)
          (norm2): Qwen2RMSNorm((1280,), eps=1e-06)
          (attn): Qwen2_5_VLVisionAttention(
            (qkv): Linear(in_features=1280, out_features=3840, bias=True)
            (proj): Linear(in_features=1280, out_features=1280, bias=True)
          )
          (mlp): Qwen2_5_VLMLP(
            (gate_proj): Linear(in_features=1280, out_features=3420, bias=True)
            (up_proj): Linear(in_features=1280, out_features=3420, bias=True)
            (down_proj): Linear(in_features=3420, out_features=1280, bias=True)
            (act_fn): SiLU()
          )
        )
      )
      (merger): Qwen2_5_VLPatchMerger(
        (ln_q): Qwen2RMSNorm((1280,), eps=1e-06)
        (mlp): Sequential(
          (0): Linear(in_features=5120, out_features=5120, bias=True)
          (1): GELU(approximate='none')
          (2): Linear(in_features=5120, out_features=2048, bias=True)
        )
      )
    )
    (language_model): Qwen2_5_VLTextModel(
      (embed_tokens): Embedding(151936, 2048)
      (layers): ModuleList(
        (0-35): 36 x Qwen2_5_VLDecoderLayer(
          (self_attn): Qwen2_5_VLAttention(
            (q_proj): Linear(in_features=2048, out_features=2048, bias=True)
            (k_proj): Linear(in_features=2048, out_features=256, bias=True)
            (v_proj): Linear(in_features=2048, out_features=256, bias=True)
            (o_proj): Linear(in_features=2048, out_features=2048, bias=False)
            (rotary_emb): Qwen2_5_VLRotaryEmbedding()
          )
          (mlp): Qwen2MLP(
            (gate_proj): Linear(in_features=2048, out_features=11008, bias=False)
            (up_proj): Linear(in_features=2048, out_features=11008, bias=False)
            (down_proj): Linear(in_features=11008, out_features=2048, bias=False)
            (act_fn): SiLU()
          )
          (input_layernorm): Qwen2RMSNorm((2048,), eps=1e-06)
          (post_attention_layernorm): Qwen2RMSNorm((2048,), eps=1e-06)
        )
      )
      (norm): Qwen2RMSNorm((2048,), eps=1e-06)
      (rotary_emb): Qwen2_5_VLRotaryEmbedding()
    )
  )
  (lm_head): Linear(in_features=2048, out_features=151936, bias=False)
)

• 首先：对于视觉部分处理（Qwen2_5_VisionTransformerPretrainedModel）

对于视觉模型主要需要处理的就是 pixel_values，假设输入的 pixel_values信息为：[4872, 1176]，image_grid_thw为： [1, 84, 58]（就是对应grid_t、grid_h、grid_w这三个数值）

主要包括如下几个模块：
1、Qwen2_5_VisionPatchEmbed：主要进行处理通过一个 Conv3d处理，处理过程也就是说首先将输入的维度进行修改得到：view(-1, self.in_channels, self.temporal_patch_size, self.patch_size, self.patch_size) –> (4872,1176)–>(4872,3,2,14,14)而后再去通过卷积处理得到 (4872,1280,1,1,1)最后得到：(4872,1280)，也就对应着：(grid_t*grid_h*grid_w, hiddend_size)；
2、Qwen2_5_VisionRotaryEmbedding；
3、Qwen2_5_VLVisionAttention：首先去划分window_size这一步直接根据计算得到的：[grid_t, grid_h, grid_w]去划分windows，比如说在上述例子中，得到的cu_seqlens = [0,64,128,…,4872]，而后再去通过如下处理：

lengths = cu_seqlens[1:] - cu_seqlens[:-1]
splits = [
    torch.split(tensor, lengths.tolist(), dim=2) for tensor in (query_states, key_states, value_states)
]

去划分q、k、v（形状都为：[1, 16, 4872, 80]）然后计算注意力，而后通过Qwen2_5_VLPatchMerger将结果合并起来。
具体计算过程，首先是如何得到cu_seqlens，因为我们得到的gird_thw=(1, 84, 58)也就是说总共有84*58=4872个token去计算全局注意力，那么这就会导致计算注意力的消耗过大，因此可以先去切分成小的window然后小块内部注意力计算。因此首先计算“块”的大小：vit_merger_window_size = self.window_size // self.spatial_merge_size // self.patch_size得到结果为: 4（112/2/14）也就是说每块大小为：4x4=16，但是不一定我的grid_h和grid_w可能整除4，因此就需要去计算填充数量 vit_merger_window_size - llm_grid_h % vit_merger_window_size 分别得到 4和2因此填充后的h和w为：88,60这样一来计算得到window数量为：88//4 * 60//4=330每个窗口的tokens数量：16

4、图像处理过程总结

总结上述图像处理过程：对于任意输入图像首先通过smart_resize（首先将图像改变到 factor的倍数，然后去判断和min_pixels和max_pixels之间大小，然后进行扩大，缩小）进行处理保证都可以整除patch_size（14）然后丢到 processor中进行处理主要是对图像归一化、正则化、改变维度（还会通过smart_resize在处理一次），处理之后再去确定他的 grid_t, grid_h, grid_w（对于这3个参数确定：直接通过 第二次smart_resize处理之后的结果除 patch_size即可）也就是tokens数量，而后将图像内容通过 conv3d处理得到：(grid_t* grid_h* grid_w, hidden_size)，最后就是计算window_attention（首先确定widow_size索引，通过索引进行切分，最后计算注意力）

补充：对于window-attention可以用卷积的思路去理解，比如说我得到“图像”：(grid_t, grid_h, grid_w) 我提前计算我的“卷积核”大小（vit_merger_window_size = self.window_size // self.spatial_merge_size // self.patch_size）为了保证我的 “图像”可以被卷积核处理就需要做一部分填充，而后用这个“卷积核”去划分成不同“小块”在到这个小块里面计算注意力。

QwenVL的微调过程

所有的代码：https://github.com/shangxiaaabb/Docparse-QwenVL

补充一：节约显存可以进行的操作
1、使用gradient_checkpointing：model.gradient_checkpointing_enable()
2、使用 qlora进行优化
3、使用 AdamW8bit 而不是 AdamW
4、使用 xformers （model.enable_xformers_memory_efficient_attention()），不过需要注意的是 QwenVL2.5不支持使用 xformers（除此之外安装也比较复杂）
5、避免显存碎片（不要过度的去评估模型），可以使用 gc.collect() torch.cuda.empty_cache() 去适当的减小缓存压力，对于不需要的内容（中间值）直接通过 del xx 处理掉

SFT 处理

https://www.f22labs.com/blogs/complete-guide-to-fine-tuning-qwen2-5-vl-model/

SFT数据处理过程

首先假设数据（通过jsonl进行存储）输入格式为：

{"image": 
    "845c2f9b-0583-4127-82a6-47c4c1c3ceb7.jpg", 
"prefix": 
    "QwenVL HTML", 
"suffix": 
    "<body><h2 data-bbox=......"
}

构建data_loader只需要注意如下几个流程即可：
首先构建我的输入模板。这一步主要是将我的数据进行读取，然后去构建成QwenVL2.5（或者其他大模型的对话形式），比如说：

def format_data(self, image, entry, text, prompt):
    return [
        {
            "role": "system",
            "content": [{"type": "text", "text": self.SYSTEM_MESSAGE}],
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "image": image,
                },
                {
                    "type": "text",
                    "text": (
                        "Must output the layout of the image strictly in HTML format. "
                        "Must follow the example below:\n"
                        "<h2 data-bbox='x1 y1 x2 y2'>Text</h2>\n"
                        "<p data-bbox='x1 y1 x2 y2'>Text</p>")
                },
            ],
        },
        {
            "role": "assistant",
            "content": [{"type": "text", "text": text}],
        },
    ]

然后就只需要将参数丢到这个函数里面就可以自动化的将数据处理好（补充一点，对于上面几个参数，一般来说其中text就是我的模型需要输出的label，而后其他的内容就是模型的输入），其次就只需要将输入进行编码即可也就是说直接通过：

image_inputs, _ = process_vision_info(messages)
encoding = self.processor(
    text=[text],
    images= image_inputs,
    return_tensors="pt",
    padding= False,
    truncation=True,
    max_length= self.max_length
)

这样就会的得到模型的输入内容，一般来说得到的是：input_ids: 文本编码内容（一般来说会直接将 input_ids进行复制作为我们的 labels，当然也可以直接对与输入解析，只需要模型那部分作为labels），attention_mask，pixel_values: 图片像素编码结果image_grid_thw: 我的tokens数量（grid_t*grid_h*grid_w）。
不过上面处理过程只是针对一张图片进行处理去构建对话信息，如果需要处理多组图片同时进行输入（比如说3张图片进行排序，让QwenVL输出）那么处理过程只需要修改 content即可（在content里面指定多个图片即可）

"content": [
            {
                "type": "image",
                "image": "./tmp/7.png",
            },
            {
                "type": "image",
                "image": "./tmp/1.png",
            },
            {"type": "text", "text": "..."},
        ],

SFT模型处理

一般来说如果直接使用lora去对模型进行微调，处理也比较简答：

target_modules = ['q_proj', 'v_proj']
lora_config = LoraConfig(
    task_type= config.lora_task_type,
    target_modules= target_modules,
    r= config.lora_rank,
    lora_alpha= config.lora_alpha,
    lora_dropout= config.lora_dropout,
)
model = get_peft_model(model, lora_config)

这样一来模型就会被lora“包裹”，微调过程也就是优化lora的参数，不过如果需要使用qlora（lora量化版本）再模型加载过程中需要使用参数 quantization_config：

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_use_double_quant=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.float16
)
...
if model_name == 'Qwen/Qwen2.5-VL-3B-Instruct':
    model = Qwen2_5_VLForConditionalGeneration.from_pretrained(
        model_name, 
        torch_dtype= torch.bfloat16, 
        cache_dir= config.cache_dir,
        quantization_config= bnb_config if config.lora_type== 'qlora' else None,
    )

对于模型训练以及参数优化过程就比较简单：

for step, batch in enumerate(train_loader):
    outputs = model(**batch)
    loss = outputs.loss

得到的所有的内容可以直接全部丢到model里面，他会自动计算loss值，对于outputs = model(**batch)模型返回得到结果为：
loss: Optional[torch.FloatTensor]：模型计算得到的loss（直接计算交叉熵损失得到），如果输入内容中没有labels（就是模型输出那段文本）那么就不会去计算loss
logits: Optional[torch.FloatTensor]：模型输出结果
past_key_values: Optional[list[torch.FloatTensor]]：Transformer 解码器的 KV 缓存（每一层的注意力 key 和 value）
hidden_states: Optional[tuple[torch.FloatTensor]]：每一层的 hidden state (batch_size, seq_len, hidden_size)
attentions: Optional[tuple[torch.FloatTensor]]：每一层注意力权重 (batch_size, num_heads, seq_len, seq_len)
rope_deltas: Optional[torch.LongTensor]：旋转位置编码 RoPE（Rotary Position Embedding）的偏移量

RL 处理

强化学习框架很多，1、huggingface-trl: https://github.com/huggingface/trl；2、字节跳动-verl: https://github.com/volcengine/verl；3、OpenRLHF：https://github.com/OpenRLHF/OpenRLHF

强化学习处理过程（直接使用 trl（使用版本：0.22.1）库，它里面提供了多种脚本）对于多模态/大语言模型使用RL中比较常见的的数据类型：一般就是抛出问题，而后给出选项让模型进行选择。此类数据集一般格式为：

{"images": [], "prompt": [], "chosen": [], "rejected": []}
# 当然这个 images 也可以替换为文本问题 "question"

比如说数据集：HuggingFaceH4/rlaif-v_formatted他的数据结构如下：

直接看trl中如何实现QwenVL-DPO过程代码：

from trl import (
    DPOConfig,
    DPOTrainer,
    ModelConfig,
    ScriptArguments,
    TrlParser,
    get_kbit_device_map,
    get_peft_config,
    get_quantization_config,
)
...
dataset = load_dataset(
    script_args.dataset_name,
    name=script_args.dataset_config,
    streaming=script_args.dataset_streaming,
)
...
# ref_model 和 model 都是直接使用QwenVL
trainer = DPOTrainer(
    model,
    ref_model,
    args=training_args,
    train_dataset=dataset[script_args.dataset_train_split],
    eval_dataset=dataset[script_args.dataset_test_split] if training_args.eval_strategy != "no" else None,
    processing_class=processor,
    peft_config=peft_config,
)

初次之外，RL就和SFT一样需要让模型去按照我的数据进行输出，因此处理也就是直接logits=model(**model_inputs).logits得到模型最后输出（见相当于每个词的概率）

RL-DPO处理代码

首先在代码（DPOTrainer）主要是通过继承 Trainer（代码包裹好了各种处理过程比如数据加载模型评估等各项处理过程）直接看 DPOTrainer里面的 get_batch_loss_metrics（完整模型输入然后输出loss）：

def get_batch_loss_metrics(self, model, batch, train_eval):
    ...
    if ...:
        ...
    else:
        model_output = self.concatenated_forward(model, batch)
        if "ref_chosen_logps" in batch and "ref_rejected_logps" in batch:
            ref_chosen_logps = batch["ref_chosen_logps"]
            ref_rejected_logps = batch["ref_rejected_logps"]
        else:
            ref_chosen_logps, ref_rejected_logps = self.compute_ref_log_probs(batch)

        losses = 0
        chosen_rewards = 0
        rejected_rewards = 0

        for idx, loss_type in enumerate(self.loss_type):
            _losses, _chosen_rewards, _rejected_rewards = self.dpo_loss(
                model_output["chosen_logps"],
                model_output["rejected_logps"],
                ref_chosen_logps,
                ref_rejected_logps,
                loss_type,
                model_output,
            )

            weight = self.loss_weights[idx] if self.loss_weights else 1.0
            losses = losses + _losses * weight
            chosen_rewards = chosen_rewards + _chosen_rewards * weight
            rejected_rewards = rejected_rewards + _rejected_rewards * weight
    return losses.mean(), ...

对于DPOTrainer里面data_loader处理过程为，首先对于 dataset会通过 processing_class（一般来说也就是对于文本直接使用 tokenizer，亦或者直接使用 AutoProcessor.from_pretrained(...)）进行处理，也就是说会提前将数据processor处理（和SFT处理方式相同）那么就会得到 self.train_dataset，那么接下来就是直接去通过代码（加载train_loader数据），其中处理方式为：ref_chosen_logp, ref_rejected_logp = self.compute_ref_log_probs(padded_batch) 对于 compute_ref_log_probs里面处理过程为：直接去通过 model/ref_model去处理：self.concatenated_forward（代码）得到模型输出： model_output，而后再去使用 self.dpo_loss去计算损失。

• self.concatenated_forward处理过程 Github-代码（实际解释使用 trl:0.22.1版本代码和github有差异）

def concatenated_forward(model, batch, is_ref_model):
    concatenated_batch = self.concatenated_inputs(batch, padding_value=self.padding_value)
    prompt_input_ids = concatenated_batch["prompt_input_ids"]         # 问题文本
    prompt_attention_mask = concatenated_batch["prompt_attention_mask"]
    completion_input_ids = concatenated_batch["completion_input_ids"] # 回答文本 同时拼接了chosen_input_ids 和 rejected_input_ids
    completion_attention_mask = concatenated_batch["completion_attention_mask"]
    if self.is_encoder_decoder:
        labels = completion_input_ids
        labels[completion_attention_mask == 0] = self.label_pad_token_id
        outputs = model(
                    input_ids=prompt_input_ids,
                    attention_mask=prompt_attention_mask,
                    labels=labels,  # we need the labels for the logits to be returned
                    **model_kwargs,
                )
        logits = outputs.logits
        loss_mask = completion_attention_mask.bool()
    else:
        # Process-1
        input_ids = torch.cat((prompt_input_ids, completion_input_ids), dim=1)
        ...
        outputs = model(input_ids, **model_kwargs)
        logits = outputs.logits
    # Process-2

Process-1：首先是将文本和回答进行拼接，而后去判断如果指定 max_length那么就去根据 truncation_mode（掐头/去尾：保留序列末尾，移除开头多余部分）去裁减输入以及移除填充和限制计算范围来优化内存和性能最后丢到模型中进行处理。

掐头去尾过程
keep_start：保留序列开头。先调用 flush_left（所有有效的token左移动去除中间padding）。然后截断到 max_length（[:, :self.max_length]）。[0, 0, x, x, x, x] → flush_left 后 [x, x, x, x]，若 max_length=3，则截断为 [x, x, x]
keep_end：保留序列末尾。先调用 flush_right（将所有有效token向右移动，前面填充padding）。截断到最后 max_length 个 token（[:, -self.max_length:]）。再次调用 flush_left，确保左侧无填充。[0, 0, x, x, x, x] → flush_right 后 [0, 0, x, x]，截断后 [x, x]，flush_left 后保持不变。

回顾一下self.concatenated_forward（模型处理）整个过程：首先是将chosen_input_ids 和 rejected_input_ids两部分进行拼接（self.concatenated_inputs做的，于此同时对于其他内容也都会拼接成两部分）作为我们模型的回答。而后丢到模型中进行处理（对于 is_encoder_decoder 可以直接给模型处理，如果不是那么就通过截断裁剪等处理来节约存储在由模型处理）得到 logits，去通过logits, label得到每个token的对数概率：all_logps，而后再去判断是否进行优化策略： ipo 或者 ld_alpha（长度去敏化）去优化得到的 all_logps（对其直接切分就可以得到：chosen_logps 和 rejected_logps）

• self.dpo_loss计算损失过程 Github-代码（实际解释使用 trl:0.22.1版本代码和github有差异）

model_output = self.concatenated_forward(model, batch)
if "ref_chosen_logps" in batch and "ref_rejected_logps" in batch:
    # 直接使用数据里面的的结果
    ref_chosen_logps = batch["ref_chosen_logps"]
    ref_rejected_logps = batch["ref_rejected_logps"]
else:
    # 相对于直接在用模型处理一下得到结果
    ref_chosen_logps, ref_rejected_logps = self.compute_ref_log_probs(batch)
_losses, _chosen_rewards, _rejected_rewards = self.dpo_loss(
    model_output["chosen_logps"],
    model_output["rejected_logps"],
    ref_chosen_logps,
    ref_rejected_logps,
    loss_type,
    model_output,)

if "ref_chosen_logps" in batch and "ref_rejected_logps" in batch: 直接使用数据里面的结果过程一样的还是通过模型 self.compute_ref_log_probs(batch)（这个还是调用了 self.concatenated_forward）去得到chosen_logps 和 rejected_logps结果。
对于 dpo_loss 里面model_ 和 ref_ 这两部分理论上是两个不同的模型的输出结果，但是如果没有指定 ref_model 那么直接就都直接使用 model 即可

对于DPO的loss处理过程就比较简单，在trl中提供3种计算方式：
1、Alpha散度计算

2、KL散度计算

3、JS散度计算

在计算得到不同方式得到的结果：logits然后再去根据不同 loss_type去做处理（比如说：loss_type == "sigmoid" 处理过程为：losses = (-F.logsigmoid(self.beta * logits) * (1 - self.label_smoothing)- F.logsigmoid(-self.beta * logits) * self.label_smoothing)）

RL-DPO处理过程总结

首先对于我们的数据集（假设为3元组：[问题, 接受回答, 拒绝回答]）首先就是去通过 processor（比如Qwen2.5vl可以直接 load）去编码我的所有内容（这一步和SFT过程相似），而后就是去通过self.concatenated_forward这个函数将我们的3元组进行拼接得到：[问题,问题], [接受回答, 拒绝回答]而后得到模型的输入为：[问题+接受回答, 问题+拒绝回答]，将输入直接交给的模型（由于见内容直接拼接起来，可能会优化模型的输入/出长度过长导致爆显存，因此输入之前会由一些裁剪处理操作）去得到输出：logits，而后通过logits, label得到每个token的对数概率：all_logps，（通过对all_logps进行拆分）就可以得到接受回答的值（chosen_logps），以及拒绝回答的值（rejected_logps），最后在得到这两部分值之后就是直接去计算loss。
对于loss计算过程（假设为KL散度）：$\mathrm{loss}=-\frac{1}{N}\sum_{i=1}^{N}\log\sigma\left(\beta\cdot((\log\pi_{\theta}(y_{w}|x)-\log\pi_{\theta}(y_{l}|x))-(\log\pi_{\mathrm{ref}}(y_{w}|x)-\log\pi_{\mathrm{ref}}(y_{l}|x)))\right)$。对于里面两项相减过程代码：

chosen_logratios = chosen_logps.to(device) - (not self.reference_free) * ref_chosen_logps.to(device)
rejected_logratios = rejected_logps.to(device) - (not self.reference_free) * ref_rejected_logps.to(device)

反思：如果需要手搓一个DPO训练过程代码（需要借鉴concatenated_forward代码来辅助实现）

RL-GRPO处理代码

官方实现代码，对于DPO过程很容易发现一点在GRPO中直接不要ref_model 只是用一个model不过设计了一个reward_function。

• 数据处理过程

以官方代码为例（训练一个具有思考过程的多模态模型），在数据处理层面使用类似如下数据集

以为需要设计一个“输出”思考过程的模型因此设计设计具有“思考”过程的prompt，最后输入模型数据格式为：

# 原始文本
{'image': <PIL.PngImagePlugin.PngImageFile image mode=RGB size=147x86 at 0x7FF65C5776D0>,
 'original_answer': ...,
 'original_question': ...,
 'problem': ...
 'prompt': [{'content': 'system-content',
             'role': 'system'},
            {'content': 'user-content',
             'role': 'user'}],
 'solution': "<think>...</think>'
             '<answer>...</answer>'}
# 初步处理后文本
{'The prompt Text: '
'<|im_start|>system\n systen-content <|im_end|>\n'
'<|im_start|>user\n user-content <|im_end|>\n'
'<|im_start|>assistant\n'}
# 模型最后得到的输出
output = {
            "prompt_ids": prompt_ids,
            "prompt_mask": prompt_mask,
            "completion_ids": completion_ids,
            "completion_mask": completion_mask,
            "advantages": advantages,
            "num_items_in_batch": num_items_in_batch,
        }

不过在得到类似上面数据集之后，不是直接丢到模型里面进行处理，在DPOTrainer中首先会去由_prepare_inputs（代码）函数进行处理，对于测试直接通过函数 ` self._generate_and_score_completions(…)`处理，对于训练数据集

_generate_and_score_completions：
第一步、格式化数据。（对于多模态/只有文本）这个过程主要是争对我上面数据中的prompt直接通过模板进行处理得到prompts_text，而后就是直接再去通过 processing_claa（直接调用QwenVL的processor）处理得到prompt_inputs，而后就是如果self.max_prompt_length那么就会去对多模态（文字 + 图像）输入时，对 prompt_inputs["input_ids"]还原文本然后去除类似<pad>和一些重复/错误的 <image>得到干净的 prompts_text。
第二步、生成回答。在trl中使用了3种生成方式：1、直接用模型生成；2、使用vllm方式生成；3、使用use_transformers_paged方式。对于生成（直接通过模型）过程而言就比较简单直接将prompt_inputs["input_ids"] 和 prompt_inputs["attention_mask"] 丢到模型里面得到prompt_completion_ids再去将 prompt内容和回答截取出来得到 prompt_ids 和 completion_ids
第三步、计算奖励值。这个过程就比较简单，直接将模型的回答进行解码再去通过奖励函数计算回答的奖励值，而后归一化成优势函数（advantages），按 group（一次生成多个样本）算均值，计算每个样本的 相对优势（比如说两个回答打分为 [0.8, 0.5]那么减去 group 内均值，假设为[+0.15, -0.15]）
最后、返回输出。

在最后返回的输出中 old_per_token_logps 和 ref_per_token_logps处理直接通过函数_get_per_token_logps_and_entropies（就相当于把 第二步得到的 prompt_completion_ids在交给模型里面去计算每个token的概率）

• 奖励函数设计

GRPO没有使用ref_model转而使用奖励函数，对于奖励函数设计：think_format_reward， accuracy_reward。对于accuracy_reward很容易理解代码就是直接对比模型输出和答案之间是否正确（通过parse [from math_verify import LatexExtractionConfig, parse, verify] 去解析最后输出打答案然后对比两者之间是否正确）。对于think_format_reward：这个更加直接，直接去判断输出是不是有 <think>...</think> 包裹（有=1，无/缺失=0）
当然不一定要使用自定义的（这么粗糙的）在DPOTrainer中对于self.reward_funcs（代码）也可以直接去加载训练好的模型 AutoModelForSequenceClassification.from_pretrained(...)

• 模型处理过程

直接去看loss计算过程：

def compute_loss(self, model, inputs, return_outputs, num_items_in_batch):
    ...
    if self.use_liger_loss:
        unwrapped_model = self.accelerator.unwrap_model(model)
        return self._forward_redirection(model, unwrapped_model, self.compute_liger_loss, unwrapped_model, inputs)
    else:
        return self._compute_loss(model, inputs)

其中使用了两种loss处理过程：_forward_redirection 以及 _compute_loss。

• self._compute_loss 处理过程（Github-代码）（实际解释使用 trl:0.22.1版本代码和github有差异）

首先是将输入问题和回答拼接起来，然后直接丢到self._get_per_token_logps_and_entropies（直接将数据丢到模型中，而后去截取模型输出中“真正回答”的内容）中进行处理得到per_token_logps（每个token的概率），entropies（每个token的信息熵），而后就是通过高熵去过滤token只在高熵位置计算 loss，而后就是计算KL散度（torch.exp(inputs["ref_per_token_logps"] - per_token_logps) - (inputs["ref_per_token_logps"] - per_token_logps) - 1)），避免新策略漂移太远

self._get_per_token_logps_and_entropies处理过程（Github-代码）（实际解释使用 trl:0.22.1版本代码和github有差异）
其处理过程比较简单，直接将所有的数据都处理成模型输入（GRPO不想DPO那样需要将3元组进行拆开拼接）如：input_ids、pixel_values等然后直接logits = model(**model_inputs).logits在得到模型的输出之后后续就是对输出做一些截断处理（如只需要模型回答部分的输出logits[:, -logits_to_keep:, :]）而后去计算 logits / self.temperature（通过温度系数来确定输出内容多样化）最后再去通过：logps = selective_log_softmax(logits, completion_ids)（selective_log_softmax只去计算completion_ids部分的log_softmax值）就可以得到最后的值。

RL-GRPO处理过程总结

对于上面loss计算公式中主要就是如下几个值需要关注：1、advantage值；2、KL散度值。
因此简单总结一些GRPO代码处理过程¹，首先，对于数据处理，这块内容比较简单直接 模板化、编码内容即可，因为GRPO是“一个问题抛出多组回答然后评估回答”，因此在数据处理过程中通过模型生成回答 prompt_completion_ids=model.generate(...)而后需要做的就是将生成内容进行拆分得到prompt_ids和 completion_ids（得到这一部分值之后就只需要在去还原成text文本然后再去通过reward函数去计算reward值以及计算最后需要的 advantage值），除此之外还会去通过model和model_ref分别计算回答中每个token的logits值：old_per_token_logps 和 ref_per_token_logps

这个过程直接通过函数 _get_per_token_logps_and_entropies处理，他的处理思路简单直接将 model需要的内容再丢到model里面得到每个token的logits然后再去计算softmax值

最后得到一个完整的output如下：

output = {
    "prompt_ids": prompt_ids,    # 问题token
    "prompt_mask": prompt_mask,
    "completion_ids": completion_ids,    # 问题的回答token
    "completion_mask": completion_mask,
    "advantages": advantages,
    "num_items_in_batch": num_items_in_batch,
    "old_per_token_logps": old_per_token_logps  
    "importance_sampling_ratio": importance_sampling_ratio  
    "ref_per_token_logps": ref_per_token_logps   
    "pixel_values": prompt_inputs["pixel_values"]   
    "image_grid_thw": prompt_inputs["image_grid_thw"]   
    "pixel_attention_mask": prompt_inputs["pixel_attention_mask"]   
    "image_sizes": prompt_inputs["image_sizes"]   
}

而后，对于loss计算过程首先将上面output中的 问题+回答进行组合再丢到_get_per_token_logps_and_entropies中得到每个token概率以及熵的值：per_token_logps，entropies，而后就是：1、选择出高熵值的token（entropy_mask）；2、计算KL散度（torch.exp(ref_per_token_logps - per_token_logps) - (ref_per_token_logps - per_token_logps) - 1）；3、重要性采样权重：比较当前 log 概率和旧策略（per_token_logps - old_per_token_logps），得到 importance weight，做 clipping 限制。构造两个候选 loss（不裁剪和裁剪），取最小值，形成 per_token_loss再去乘上 entropy_mask和加上 KL 惩罚项就可以得到最后的loss值。

RL-PPO处理代码

借用huggingface中对于PPO过程描述图：

对于代码使用，相比较GRPO和DPO要简单很多（不过在使用模型上，DPO和PPO都需要加载model和ref_model而GRPO只需要加载一个model），按照上面的处理过程：
首先计算rollout输出，直接通过加载的模型然后模型对于“问题”去得到“回答”query_responses（完整的模型生成内容：prompt+模型的回答），logitss，接下来（代码）去计算model和ref_model中每个token的log概率值（这个过程和GRPO处理是一样的，将问题+回答拼接起来而后丢到模型中计算每个token的log概率值）最后分别得到模型的输出结果：logprobresponse（截取model回答内容） 和 ref_logprob。后面部分（代码）就是直接根据 response（model的回答） 以及 query（就是我们的问题）去计算reward的值scores。
接下来处理过程：1、处理 EOS 缺失惩罚：将socres中如果生成内容不含结束标记就从scores中减去数值；2、计算kl以及最后的rewards值，对kl直接首先通过mask去掩盖部分logprobs（ref_logprobs）然后直接通过 kl = -(ref_logprobs - logprobs) if args.kl_estimator == "k1" else ((ref_logprobs - logprobs).exp() - 1) - logr得到kl值；3、计算advantage值（代码）
最后就是迭代优化模型参数（代码）这个过程（对采样得到的一批序列数据做多轮（num_ppo_epochs）小批次更新，通过 ratio = πθ/π_old 和裁剪（clip）来构造策略损失，同时对价值函数做裁剪的 value loss）主要是进行如下处理流程：首先是直接将最上面得到的query_responses中选择部分例子丢到模型中去计算每一个token的logits（ new_logprobs = selective_log_softmax(logits, mb_responses) ） 而后计算策略损失值（pg_loss）以及vf_loss

回顾一下，对于加载的llm在使用generate时一般返回如下4个值：
sequences：生成的 token ids（跟默认返回一样）；
scores：每一步的 logits（如果 output_scores=True）
attentions：注意力矩阵（如果 output_attentions=True）
hidden_states：隐藏层表示（如果 output_hidden_states=True）
一般而言使用到的主要是上面两项，对于第一项sequences一般得到的完整的回答（prompt+模型生成的内容），所以一般会有一个截取处理（只需要记录inputs['input_ids'].shape[1]然后去截取即可）；对于第二项scores一般得到的是通常是logits（需要去通过softmax计算才能得到token概率）；因此在GRPO和PPO中为了得到每一个token的log概率值，logprob = selective_log_softmax(logits, response)直接通过这种方式去计算来节约显存。
除此之外也有直接通过 model(**model_inputs)这样处理一般得到的是

RL-PPO处理过程总结

第一阶段：首先是对于问题（query）通过丢到模型batch_generation中处理得到query_responses（完整问题+模型回答） 和logitss（每个token对应的概率），进一步将其得到回答token的概率值logprob（selective_log_softmax）同样的处理过程通过policy_model将query_response（从 query_responses挑选的）输入到模型进行处理同样的处理得到ref_logprob，最后就是通过reward_model去计算（torch.cat((query, postprocessed_response), 1)）得到奖励值。
第二阶段：kl值：直接计算ref_logprobs - logprobs（也就是计算上面阶段的ref_logprob和 logprob之间差值）；rewards值：直接copy计算的kl结果然后再序列的结尾补充上scores；advantage值：根据 reward 和 value，用 GAE 算 advantage。GAE计算过程：$\delta_t = r_t + \gamma V(s_{t+1}) - V(s_t)$ 和$A_t = \delta_t + \gamma \lambda A_{t+1}$最后计算advantages + values也就是 $R_t=A_t+V(s_t)$
第三阶段：进行迭代优化模型参数过程，优化过程首先是直接将小批次的query_responses 输入到模型中计算得到output, vpred_temp然后就是老操纵得到每个token的logits值new_logprobs，然后计算去计算vf_loss：计算loss1（torch.square(vpred - mb_return)）和loss2（torch.square(vpredclipped - mb_return)）的最大值。pg_loss：计算loss1（-mb_advantage * ratio）和loss2（-mb_advantage * torch.clamp(ratio, 1.0 - args.cliprange, 1.0 + args.cliprange)）的最大值然后取mean。最后得到loss为pg_loss + args.vf_coef * vf_loss

vpred、vpredclipped、mb_return分别通过从vpred_temp选择回答token、对vpred进行clamp裁剪、advantages + values

RL算法对比

对比一下GRPO和DPO的处理过程

DPO纯数据驱动过程，数据驱动：训练时需要标注好的偏好对：$[q, y^+], [q, y^-]$。计算流程：1. 输入同一个问题 $q$，分别拼接上正样本回答 $y^+$ 和负样本回答 $y^-$。2. 用当前模型和参考模型分别计算 $\log \pi_\theta(y^+|q), \log \pi_\theta(y^-|q), \log \pi_{\text{ref}}(y^+|q), \log \pi_{\text{ref}}(y^-|q)$。3. 基于这 4 个 log-prob，直接计算一个 logistic 回归式的 loss，强制模型在正样本上比分数更高，在负样本上比分数更低。
GRPO生成驱动过程，生成驱动：训练时只给定问题 prompt，模型自己 roll-out 多个回答。计算流程：1. 对每个问题生成 $G$ 个回答。2. 通过奖励函数（或打分器）给每个回答打分 $r_i$。3. 组内归一化奖励 → 得到 advantage 值 $A_i$（比组内平均好/差多少）。4. 用参考模型计算 ref_per_token_logps（使用ref_model生成没有的话直接用model代替ref_model）。5. 用旧策略（冻结一帧的当前模型）得到 old_per_token_logps（直接通过model生成）。6. 用当前模型得到 per_token_logps。7. 计算重要性比率和 KL 散度（使用per_token_logps和ref_per_token_logps计算）近似，再套 PPO 风格的剪切目标（使用old_per_token_logps和per_token_logp） → 最终 loss。

对于DPO、GRPO、PPO中KL计算差异

$KL(p||q)=\sum_x p(x)\log\frac{p(x)}{q(x)}=H(p,q)-H(q)$，交叉熵-熵
计算交叉熵的目的在于约束新策略不要偏离参考策略太多，类似的对于交叉熵损失（$H(p,q)=-\sum_x p(x)\log q(x)$）两者之间差异是交叉熵是让“q去拟合p”，而KL则是度量“q和p之间距离”

1、DPO中计算KL：在model_ref以及model分别输入“3元组”数据之后会去计算不同token的概率值，也就是model和ref都会生成 reject和choose的概率值，然后去计算：$\mathrm{loss}=-\frac{1}{N}\sum_{i=1}^{N}\log\sigma\left(\beta\cdot((\log\pi_{\theta}(y_{w}|x)-\log\pi_{\theta}(y_{l}|x))-(\log\pi_{\mathrm{ref}}(y_{w}|x)-\log\pi_{\mathrm{ref}}(y_{l}|x)))\right)$ 的sigmoid 损失优化相对偏好
2、GRPO中计算KL：通过model_ref对于问题Q以及模型生成的多组回答进而可以得到每组回答的token概率：ref_per_token_logps 而后我又通过model去生成多组回答以及token概率：per_token_logps接下来就是直接他们之间KL散度：

3、PPO中计算KL：通过model得到回答中的每一个token的概率logprobs，同样的再去通过model_rf也去计算每一个token的概率ref_logprobs然后去计算KL

DPO：通过“偏好差值”间接引入 KL 约束，偏重于 对比学习。
GRPO：显式计算 生成候选组的 token 级 KL，作为正则项，保证模型不偏离参考策略。
PPO：基于当前策略与参考策略（或旧策略）的 KL，常作为 正则或 early stopping 信号

对于GRPO以及PPO中优势值计算过程

GRPO优势值计算过程：对于给出多组回答直接通过奖励函数去计算每组回答的奖励值而后去上计算：$A_i = \frac{r_i- mean(r)}{std(r)}$
PPO优势值计算过程：一般直接通过广义优势估计方法GAE来计算优势值，首先通过奖励函数评估模型输出（问题+回答），而后计算GAE

对比DPO、GRPO、PPO中loss计算差异

DPO的loss计算：
\(\mathcal{L}_{\text{DPO}} = -\frac{1}{N} \sum_{i=1}^{N} \log \sigma\left( \beta \underbrace{\left[ \log \pi_\theta(y_w|x) - \log \pi_\theta(y_l|x) \right]}_{\text{model 之间差异}} - \underbrace{\left( \log \pi_{\text{ref}}(y_w|x) - \log \pi_{\text{ref}}(y_l|x) \right)}_{\text{隐含 KL 基准}} \right)\)
GRPO的loss计算：
\(\mathcal{L}_{\text{GRPO}} = -\mathbb{E}\left[ \frac{\pi_\theta(y|x)}{\pi_{\text{ref}}(y|x)} A(y) \right] + \lambda \, \mathrm{KL}\left( \pi_\theta \parallel \pi_{\text{ref}} \right)\)
PPO的loss计算：
\(r_t(\theta) = \exp\left( \log \pi_\theta(a_t|s_t) - \log \pi_{\text{ref}}(a_t|s_t) \right)\)

参考

QwenVL

在QwenVL¹中在论文里面作者提到的其模型的整个训练过程如下：

仅从提供的不同阶段还是很容易发现QwenVL还是是采用和BLIP相似的使用 learned-query来对齐模态信息
语言模型使用（7.7B）：Qwen-7B
视觉编码器（1.9B）：Vit-bigG
融合器（0.08B）：Learnable Query

不过论文里面对于模型细节介绍不是很多，从代码角度出发窥其模型结构：
模型视觉编码器：视觉编码器使用的是ViT架构（Vision Transformer），ViT的网络设置和初始化参数使用了OpenCLIP预训练好的ViT-bigG模型。具体的代码处理过程（代码），其中模型输出维度变化过程：1x3x448x448–>1x1664x32x32（首先卷积处理）–>1x1024x1664（拉平交换维度）
特征融合器：上述ViT处理后，对于$448\times 448$分辨率的图像，生成一个 [1024, 1664]的序列，也就是向量维度为1664的长度为1024的序列。为了压缩视觉token的输入长度，Qwen-VL引入了一个Adapter来压缩图像特征。这个Adaper就是一个随机初始化的单层Cross-Attention模块。该模块使用一组可学习的query向量，将来自ViT的图像特征作为Key向量。通过Cross-Attention操作后将视觉特征序列压缩到固定的256长度（也就是将视觉特征压缩到 256 1644）
此外，考虑到位置信息对于精细图像理解的重要性，Qwen-VL将二维绝对位置编码（三角位置编码）整合到Cross-Attention的 $q,k$中，以减少压缩过程中可能丢失的位置细节。随后将长度为256的压缩图像特征序列输入到大型语言模型中。

QwenVL-2

对于QwenVL-2²其模型的基本结构如下：

1、使用动态分辨率（也就是说输入图像不需要再去改变图像尺寸到一个固定值），于此同时为了减少 visual-token数量，将2x2的的相邻的token进行拼接到一个token而后通过MLP层进行处理。

动态分辨率处理如上，通过指定[mix_pixels, max_pixels]范围然后将图像保持原始的纵横比去缩减图像到上面的范围中（处理过程，首先计算原始图像的像素数量，而后判断和上面指标的范围，如果超出范围就去计算需要修改的比例，在将整个比例去处理到分辨率上）
在通过使用动态分辨率处理图像之后会在单一图片增加时间维度也就是将：CHW–>TCHW（这点是为了和视频处理过程进行对齐），在源码中T选择数值为2也就是将图片“复制一次”，而后对帧序列进行Patchification操作

def _preprocess(): 
    ......   
    channel = patches.shape[1]
    grid_t = patches.shape[0] // self.temporal_patch_size
    grid_h, grid_w = resized_height // self.patch_size, resized_width // self.patch_size
    patches = patches.reshape(
        grid_t,                            # 0
        self.temporal_patch_size, channel, # 1 2
        grid_h // self.merge_size,         # 3
        self.merge_size, self.patch_size,  # 4 5
        grid_w // self.merge_size,         # 6
        self.merge_size, self.patch_size,  # 7 8
    ) # self.merge_size=2 self.patch_size=14 self.temporal_patch_size=2
    ### 将2x2的邻域Patch放到一起，方便后续做领域的Patch过Projector层做聚合压缩
    patches = patches.transpose(0, 3, 6, 4, 7, 2, 1, 5, 8)
    ### Patch序列化，并保留Patch位置信息（时间，高，宽）
    flatten_patches = patches.reshape(
        grid_t * grid_h * grid_w, channel * self.temporal_patch_size * self.patch_size * self.patch_size
    )

上面过程也就是进行所谓的“2x2的相邻token拼接”，最后得到[grid_t * grid_h * grid_w, channel * temporal_patch_size(2) * patch_size(14) * patch_size(14)]（其中grid_h=resized_height // self.patch_size(14)）
2、多模态的旋转位置编码（M-RoPE）,也就是将原来位置编码所携带的信息处理为：时序（temporal）、高度（height）、宽度（width）。比如下图中对于文本处理直接初始化为：$(i,i,i)$。但是对于图片而言就是：$(i,x,y)$ 其中 $i$ 是恒定的，而对于视频就会将 $i$ 换成视频中图像的顺序
总结处理过程：动态分辨率处理–>复制时间维度–>将序列切割为patch。这样一来就会直接将图像处理为：[grid_t * grid_h * grid_w, channel * temporal_patch_size(2) * patch_size(14) * patch_size(14)]（其中grid_h=resized_height // self.patch_size(14)）除此之外而后去计算 3d-RoPE最后通过一层线性层处理就得到最后的视觉token。

QwenVL-2.5

在QwenVL2.5中³模型具体的代码处理过程参考Blog⁴具体模型结构：

在图像处理过程上和QwenVL2差异不大都是直接：动态分辨率处理–>复制时间维度–>将序列切割为patch，对比两个模型差异：

1、采用 RMSNorm 替换了所有 LayerNorm；2、ViT中每一个VisionBlock中的MLP换成了SwiGLU 结构。只从模型结构上差异不到，在QwenVL2.5中主要进行改动：1、在视觉编码过程中使用window-attention（对应上述结构中的Qwen2_5_VLVisionAttention）对于具体的划分window方法（代码）：根据输入的图像大小 (gird_t, grid_h, grid_w)去得到窗口索引 (window_index) 和 累积序列长度 (cu_window_seqlens)。具体例子如下：

# 数据数据特征
[ [ 0,  1,  2,  3,  4,  5],
  [ 6,  7,  8,  9, 10, 11],
  [12, 13, 14, 15, 16, 17],
  [18, 19, 20, 21, 22, 23],
  [24, 25, 26, 27, 28, 29],
  [30, 31, 32, 33, 34, 35] ]
# 保证可以被window_size划分需要进行填充
[ [ 0,  1,  2,  3,  4,  5, X, X],
  [ 6,  7,  8,  9, 10, 11, X, X],
  [12, 13, 14, 15, 16, 17, X, X],
  [18, 19, 20, 21, 22, 23, X, X],
  [24, 25, 26, 27, 28, 29, X, X],
  [30, 31, 32, 33, 34, 35, X, X],
  [ X,  X,  X,  X,  X,  X, X, X],
  [ X,  X,  X,  X,  X,  X, X, X] ]
# 而后直接更具window大小得到每个需要计算注意力的window
# window-0
[ 0,  1,  2,  3]
[ 6,  7,  8,  9] 
[12, 13, 14, 15]
[18, 19, 20, 21]
# 展平重新排列得到：
# window-0
[0, 1, 2, 3, 6, 7, 8, 9, 12, 13, 14, 15, 18, 19, 20, 21]
# window-1 
[4, 5, 10, 11, 16, 17, 22, 23]
# 计算累计长度
seqlens = (index_padded != -100).sum([2, 3]) # 计算有效长度：window-0：16 window-1：8.....
cu_seqlens_tmp = seqlens.cumsum(0) * 4 + cu_window_seqlens[-1]
cu_window_seqlens.extend(cu_seqlens_tmp.tolist())
# [0, 64, 96, 128, 144]
# 得到最后返回结果window_index, cu_window_seqlens

在得到window_index和cu_window_seqlens之后就是计算注意力过程

for i in range(1, len(cu_seqlens)):
  attention_mask[..., cu_seqlens[i - 1] : cu_seqlens[i], cu_seqlens[i - 1] : cu_seqlens[i]] = 0

q = q.transpose(0, 1)
k = k.transpose(0, 1)
v = v.transpose(0, 1)
attn_weights = torch.matmul(q, k.transpose(1, 2)) / math.sqrt(self.head_dim)
attn_weights = attn_weights + attention_mask
attn_weights = nn.functional.softmax(attn_weights, dim=-1, dtype=torch.float32).to(q.dtype)

QwenVL-3

在官方Blog⁵的介绍中

对于模型架构的更新简单总结为：1、MRoPE-Interleave: 改进位置编码，采用时间(t)、高度(h)、宽度(w)交错分布形式，提升对长视频的理解能力。2、DeepStack 技术: 融合 ViT 多层次特征，将视觉特征注入 LLM 的多层中，实现更精细化的视觉理解和图文对齐精度。3、文本时间戳对齐机制 (T-RoPE 升级): 采用“时间戳-视频帧”交错输入形式，实现帧级别时间信息与视觉内容的细粒度对齐，提升视频事件定位精度。整体模型结构在区别上一代QwenVL-2.5改进点在于：patch_embed的patch_size变大了（14->16），embed使用的三维卷积里加了bias，ViT的隐层维度hiddeen_dim从1280->1152，而后使用DeepStack、MRoPE-Interleave。

• DeepStack 技术原理

从最上面的模型结构图中可以发现DeepStack就是将视觉视觉编码器特征融入到LLM Block的每一层中，参考论文中的结构图⁶:

之所以要使用该技术是为了解决：计算与内存开销过高:传统LMMs将所有视觉visual tokens拼接成一维序列输入到语言模型的第一层，导致需要处理的输入序列长度显著增加，尤其在处理高分辨率图像或多帧视频时，计算和内存成本急剧上升。细粒度视觉信息丢失:现有方法通过压缩视觉Token(如空间池化、感知器重采样等)来平衡计算开销与信息保留，但会牺牲高分辨率图像中的细节信息。视觉与语言交互效率不足:现有方法仅通过第一层Transformer处理所有视觉Token，未能充分利用语言模型深层结构的层次化特征提取能力。

源码结构

对于具体源码（代码）分析整体模型处理过程如下（代码）

值得注意的是在输入数据预处理阶段QwenVL-3和2.5的处理是相同的通过smart_resize去修改分辨率

class Qwen3VLModel(Qwen3VLPreTrainedModel):
  ...
  def __iniit__(...):
    super().__init__(config)
    self.visual = Qwen3VLVisionModel._from_config(config.vision_config)
    self.language_model = Qwen3VLTextModel._from_config(config.text_config)
    self.rope_deltas = None  # cache rope_deltas here
    self.post_init()
  def forward(...):
    ...
    # 图像处理过程
    if pixel_values is not None:
      image_embeds, deepstack_image_embeds = self.get_image_features(pixel_values, image_grid_thw)
      image_embeds = torch.cat(image_embeds, dim=0).to(inputs_embeds.device, inputs_embeds.dtype)
      image_mask, _ = self.get_placeholder_mask(
          input_ids, inputs_embeds=inputs_embeds, image_features=image_embeds
      )
      inputs_embeds = inputs_embeds.masked_scatter(image_mask, image_embeds)
    ...
    outputs = self.language_model(...,inputs_embeds=inputs_embeds,...)

• get_image_features处理过程：通过Qwen视觉编码其处理并且获取特定层视觉编码特征

通过视觉编码处理得到image_embeds和 deepstack_image_embeds而后再去对 image_embeds进行裁剪，裁剪的逻辑为：split_sizes = (image_grid_thw.prod(-1) // self.visual.spatial_merge_size**2).tolist();image_embeds = torch.split(image_embeds, split_sizes) 回到self.visual中模型具体处理过程如下（代码）：

# https://github.com/huggingface/transformers/blob/0419ff881d7bb503f4fc0f0a7a5aac3d012c9b91/src/transformers/models/qwen3_vl/modeling_qwen3_vl.py#L701
class Qwen3VLVisionModel(Qwen3VLPreTrainedModel):
  def __init__(...):
    ...
    self.blocks = nn.ModuleList([Qwen3VLVisionBlock(config) for _ in range(config.depth)])
    self.merger = Qwen3VLVisionPatchMerger(...)
    self.deepstack_visual_indexes = config.deepstack_visual_indexes
    self.deepstack_merger_list = nn.ModuleList(
        [
            Qwen3VLVisionPatchMerger(
                config=config,
                use_postshuffle_norm=True,
            )
            for _ in range(len(config.deepstack_visual_indexes))
        ]
    )
  def forward(self, hidden_states: torch.Tensor, grid_thw: torch.Tensor, **kwargs):
    ... # 对图像数据通过 patch_embed 进行处理而后补充位置编码
    # Vit处理
    deepstack_feature_lists = []
    for layer_num, blk in enumerate(self.blocks):
        hidden_states = blk(...)
        if layer_num in self.deepstack_visual_indexes:
            deepstack_feature = self.deepstack_merger_list[self.deepstack_visual_indexes.index(layer_num)](hidden_states)
            deepstack_feature_lists.append(deepstack_feature)
    hidden_states = self.merger(hidden_states) # 直接通过两层fc进行处理
    return hidden_states, deepstack_feature_lists

patch_embed就是直接使用3维卷积（bias为True）：Conv3d(3, 1152, kernel_size=(2, 16, 16), stride=(2, 16, 16))（维度上对应：(grid_t*grid_h*grid_w, hiddend_size)），对于上述DStack过程中也比较好理解直接从需要处理的每层（通过Qwen3VLVisionBlock总共由27层叠加）中挑选出对应的处理后的特征，直接挑选[8, 16, 24]层处理后的特征。

在 ViT 模型的预训练阶段，通常使用固定的输入分辨率（例如 224×224），并将其划分为固定数量的 patch（例如 14×14，共 196 个 patch）。这意味着模型内部的 pos_embed 是一个固定长度的可学习参数矩阵，模型在训练过程中已经隐式地学习到了这些位置编码之间的空间关系。当推理阶段输入的分辨率发生变化时，如果直接重新计算或生成新的位置编码，就会破坏模型在预训练阶段学到的空间语义信息，从而导致性能下降。因此，QwenVL-3 等模型的做法是：固定一套在预训练阶段学习到的位置编码，在输入新的分辨率时，不重新生成编码，而是通过 双线性插值 将原始位置编码映射到新的空间尺度上，从而在保持预训练空间结构的前提下，适配不同输入尺寸。换句话说，新的 patch 位置不再重新计算 embedding，而是通过插值在原有位置编码上“找到”其对应的空间位置。

• llm处理过程：直接将视觉token位置上补充我的DeepStack特征

# https://github.com/huggingface/transformers/blob/0419ff881d7bb503f4fc0f0a7a5aac3d012c9b91/src/transformers/models/qwen3_vl/modeling_qwen3_vl.py#L760
class Qwen3VLTextModel(Qwen3VLPreTrainedModel):
    def __init__(self, config: Qwen3VLTextConfig):
        super().__init__(config)
        self.padding_idx = config.pad_token_id
        self.vocab_size = config.vocab_size

        self.embed_tokens = nn.Embedding(config.vocab_size, config.hidden_size, self.padding_idx)
        self.layers = nn.ModuleList(
            [Qwen3VLTextDecoderLayer(config, layer_idx) for layer_idx in range(config.num_hidden_layers)]
        )
        self.norm = Qwen3VLTextRMSNorm(config.hidden_size, eps=config.rms_norm_eps)
        self.rotary_emb = Qwen3VLTextRotaryEmbedding(config=config)
        self.gradient_checkpointing = False

    def forward(...,input_ids: Optional[torch.LongTensor] = None,
        attention_mask: Optional[torch.Tensor] = None,
        position_ids: Optional[torch.LongTensor] = None,...
        visual_pos_masks: Optional[torch.Tensor] = None,
        deepstack_visual_embeds: Optional[list[torch.Tensor]] = None,
    ):
        ...
        for layer_idx, decoder_layer in enumerate(self.layers):
            layer_outputs = decoder_layer(...) # 模型解码输出
            hidden_states = layer_outputs

            if deepstack_visual_embeds is not None and layer_idx in range(len(deepstack_visual_embeds)):
                hidden_states = self._deepstack_process(
                    hidden_states,
                    visual_pos_masks,
                    deepstack_visual_embeds[layer_idx],
                )
        hidden_states = self.norm(hidden_states)
        ...
    def _deepstack_process(
        self, hidden_states: torch.Tensor, visual_pos_masks: torch.Tensor, visual_embeds: torch.Tensor
    ):
        visual_pos_masks = visual_pos_masks.to(hidden_states.device) # 形状 batch_size, seqlen
        visual_embeds = visual_embeds.to(hidden_states.device, hidden_states.dtype)
        local_this = hidden_states[visual_pos_masks, :].clone() + visual_embeds
        hidden_states[visual_pos_masks, :] = local_this
        return hidden_states

其实从上面代码中很容易发现在DeepStack中QwenVL-3处理方式很简单直接选出所有视觉token位置而后将视觉特征进行补充，其中visual_pos_masks的形状是batch_size, seqlen

Qwen-3.5

简单总结模型主要亮点在于：1、使用linear-attention+full+attention的混合，其中整体的混合比例3：1（3层linear attention后叠加1层full attention）比如说

2、除此之外引入门控注意力计算（Gate-Attention⁷）主要过程式在计算QKV三部分的注意力之后引入Gate机制。在代码中的具体实现过程为代码为（图片来源知乎）：

对于上述过程中的QKV和常规的Attention中计算没差异，关键在于其引入了z、b、a这三组变量，其中b、a主要是用在Gate计算中而z则是在最后计算完attention之后再去self.norm(core_attn_out, z)，在计算门控过程中代码过程如下

core_attn_out = torch.zeros(batch_size, num_heads, sequence_length, v_head_dim).to(value)
last_recurrent_state = (
    torch.zeros(batch_size, num_heads, k_head_dim, v_head_dim).to(value)
    if initial_state is None
    else initial_state.to(value)
)
# q_t: (B, H, d_k) 
# g_t: (B, H, 1, 1)
# beta_t: (B, H, 1)
for i in range(sequence_length):
    q_t = query[:, :, i]
    k_t = key[:, :, i]
    v_t = value[:, :, i]
    
    g_t = g[:, :, i].exp().unsqueeze(-1).unsqueeze(-1)
    beta_t = beta[:, :, i].unsqueeze(-1)

    last_recurrent_state = last_recurrent_state * g_t
    
    kv_mem = (last_recurrent_state * k_t.unsqueeze(-1)).sum(dim=-2)
    
    delta = (v_t - kv_mem) * beta_t
    last_recurrent_state = last_recurrent_state + k_t.unsqueeze(-1) * delta.unsqueeze(-2)
    core_attn_out[:, :, i] = (last_recurrent_state * q_t.unsqueeze(-1)).sum(dim=-2)

上述代码整个计算对应下面过程：$S_{t}=\alpha_{t} S_{t-1}+\beta_{t}\left(v_{t}-\alpha_{t} S_{t-1} k_{t}\right) k_{t}^{\top}$ 计算公式中 $\alpha_t$ 对应代码中的 g_t而 $\beta_t$就对应beta_t。通过这部分计算可以实现注意力计算的复杂度降低为 $O(T · d_k · d_v)$ 而对于上述公式中 $\alpha_t$主要是遗忘系数用来控制历史保留和检索衰减，$\beta_t$学习率控制新信息的写入强度，内部的 $v_{t}-\alpha_{t} S_{t-1} k_{t}$主要是用来预测残差只更新”记错的部分”，而非全部覆盖。
对于上述之所以这么计算简单理解如下：首先在最开始的Attention计算中是这样的：$O_t=\text{Softmax}(Q_tK_{1:t}^T)V_{1:t}=\sum_1^t \text{softmax}(Q_tK_i^T)V_i$ 也就是说在生成过程中每进入一个新的词（$Q_t$）都需要去和前面所有的KV都进行计算，如果直接去掉内部的 $\text{softmax}$⁸那么就可以得到：$O_t≈\sum_1^t(Q_tK_i^T)V_i$ 此时这个等式可以满足交换运算顺序可以得到 $O_t=Q_t^T\sum_1^t K_iV_i^T$ 对于这个公式内部的 $\sum_1^t K_iV_i^T=S_{t-1}+K_tV_t^T$ 那么最后注意力计算过程（最朴素的线性注意力计算过程）为：
\(O_t=Q_t(S_{t-1}+K_tV_t^T))=Q_tS_{t-1}+Q_tK_tV_t^T\)
但是这个计算过程存在小问题：所有历史$S_{t-1}$都是平等重要，并且随着你推理长度变长新的信息就被淹没了，那么就可以直接 一次带遗忘 + 误差修正的外积更新，比如说对于最上面的公式可以直接写成：$\alpha_t(S_{t-1}-\beta_t K_tK_t^T)S_{t-1}+\beta_tV_tK_t^T$ 首先我的 $\alpha_t$ 就对应遗忘机制（对于我的$S_{t-1}$ 需要保存多少）而内部的就是一个误差更新机制（我的$t$对于历史状态有多少的影响）对于$\beta$也可以理解为新信息写入强度，最后回到代码里面这个 $S_{t-1}$就是我们缓存的KV-Cache。

简单解释一下里面 $\text{softmax}$ 作用：都知道计算 $QK^T$ 过程中我们相当于得到了token之间 “相似度”而后将整个相似度加权到 $V$上，而$\text{softmax}$在其中的作用就是去把原始相似度分数变成概率分布并且放大显著差异

总结

从QwenVL到QwenVL2.5视觉编码器处理过程：
QwenVL：将图像转化为固定的分辨率而后将输入到Vit-bigG进行处理得到视觉特征之后再去使用类似Q-former处理过程（QwenVL中使用的是一个随机初始化的单层Cross-Attention模块）使用learned-query（压缩到固定的256长度的token）将视觉token进行压缩而后输入到LLM中。
QwenVL2：首先使用动态分辨率（将图像除以固定的factor而后保持横纵比将其缩减到 [mix_pixels, max_pixels]中）去处理图像而后将其输入到视觉编码器中，而后将2x2的的相邻的token进行拼接（也就是将图像补充一个时间帧得到TCHW，而后再去在THW三个维度划分得到不同的patch：grid_t,grid_h,grid_w）到一个token而后通过MLP层进行处理。
QwenVL2.5：整体框架上和QwenVL2差异不大，区别在于使用了window-attention（主要是对数据进行切块而后在块内做注意力计算）以及2D-RoPE
QwenVL3：改进点在于使用DeepStack技术将Vit提取得到的视觉特征注入LLM Decoder的特定位置层中，而不是最开始只在输入层注入视觉信息
QwenVL3.5：改进点在于使用线性注意力机制$\alpha_t(S_{t-1}-\beta_t K_tK_t^T)S_{t-1}+\beta_tV_tK_t^T$主要参数 $\alpha$ 主要是控制历史信息重要性、$\beta$主要是控制当前信息重要性、内部计算 $KK^T$主要是进行方向引导

参考

DeepSeek v3.1

DeepSeek v3.1¹（简称DS）各类技术细节，对于DS在模型结构上和之前迭代版本的 DS-2无太大区别，还是使用混合专家模型，只是补充一个辅助损失去平衡不同专家之间的不均衡问题。

在结构上DS主要的创新点在于：1、Multi-Head Latent Attention；2、DeepSeekMoE。前者为优化 KV-cache 操作，通过一个低秩的$c_r^{KV}$代替原本占用较高的QV的值（首先通过降维方式降低原本维度，这样一来在显存占用上就会降低，而后通过升维方式，恢复到原本的维度），后者为混合专家模型，不过区别于常用的MoE方法，在DS中将专家模型分为两类：1、Routed Expert；2、Shared Expert，前者直接将隐藏层的输入进行传入，后者则是通过门控网络筛选而后隐藏层的输入进行传入。
除此之外，在DS中使用Multi-Token Prediction（MTP）技术

在DS中一个很耀眼的功能就是：DeepSeek-R1（一种思维链技术：CoT:Chain of Thought，在GPT-o1中也使用到这种技术）结合论文²中对 CoT技术的描述，可以简单的理解为：让LLM可以自主去思考问题，相较之直接让GPT输出答案，区别在于还要他给出推理过程，比如说在DeepSeek中对于思维链的prompt：

直接让模型去输出think内容，一般而言如果要训练一个具有思维链功能的模型可以简单按照如下过程进行处理：

# 数据集简单类型
{
  "instruction": "请一步一步思考并解答以下问题。",
  "input": "小明有5个苹果，给了小红3个，还剩多少？",
  "output": "<think>第一步：...\n第二步：...\n第三步：...</think>答案：2个"
}
# 微调模型过程中 prompt
你是一个严谨的推理助手，回答任何问题前必须先在 <think> 标签内进行完整逐步思考，再给出最终答案。

通过上面简单过程去“强迫”模型去输出思考过程而不是直接就给出答案。除此之外在DS-R1中模型的整体训练过程使用Group Relative Policy Optimization（GRPO）策略进行优化

对于上述优化过程理解：比如说对于一个数学问题：$8+5=?$，这就是上面公式中所提到的question $q$，按照上面的描述，将会生成一系列的输出：${o_1,…,o_G}$
Step-1：生成若干的回答。${o_1,…,o_G}$
Step-2：对于生成的回答进行评分。${r_1,…,r_G}$，而后计算$A_i=\frac{r_i- \text{mean}({r_1,…,r_G})}{\text{std}({r_,…,r_G})}$
Step-3：使用裁剪更新策略：$\text{clip}(\frac{\pi_{\theta}(o_i|q)}{\pi_{\theta_{old}(o_i|q)}},1-\epsilon,\epsilon)$比如说：如果新策略开始给o1分配过高的概率，裁剪机制确保不会过度强调这个响应。这种方式保证了即使在像推理这样复杂的任务中，策略优化也能保持稳定和可靠。通过clip函数将内部值限定在$(1-\epsilon, 1+\epsilon)$之间
Step-4：通过KL散度（用来度量两个概率分布相似度的指标）惩罚偏差

DeepSeek v3.2

论文中核心点就是Native Sparse Attention，在上一代的MLA中通过对KV-cache进行压缩（降维压缩升维还原）能够有效的节省KV-cache的缓存大小，但是计算复杂度上还是 $O(L^2)$因此在 v3.2中提出的Native Sparse Attention核心点就是去缩小计算的复杂度为 $O(LK)$，其核心计算过程如下：Native Sparse Attention主要是在MLA的基础上补充了一个 lighting indexer主要过程如下
\(I_{t,s} = \sum_{j=1}^{H^I} w_{t,j}^I \cdot \text{ReLU} \left( \mathbf{q}_{t,j}^I \cdot \mathbf{k}_s^I \right)\)
表示在完成 Q-K 点积之后，用于预测哪些 token 在当前上下文中最为重要。具体实现上，在每个注意力层前会增加一个轻量级索引头，该索引头使用低精度（FP8）计算当前 Query 与所有历史 Key 的粗略相似度分数。随后，从这些分数中选出 top-k 个最相关的历史位置，仅将这 k 个 Key/Value 输入后续的正式注意力计算。通过这种方式，可以显著降低注意力计算的 FLOPs 与内存占用，同时保持长序列的关键依赖关系。在代码实现过程整体的部分和MLA相似关键在于 Indexer 过程

qr = self.q_norm(self.wq_a(x))
q = self.wq_b(qr)
q = q.view(bsz, seqlen, self.n_local_heads, self.qk_head_dim)
q_nope, q_pe = torch.split(q, [self.qk_nope_head_dim, self.qk_rope_head_dim], dim=-1)
q_pe = apply_rotary_emb(q_pe, freqs_cis)
...
if mask is not None: # 训练阶段
 q = torch.cat([q_nope, q_pe], dim=-1)
 kv = self.wkv_b(kv)
 kv = kv.view(bsz, seqlen, self.n_local_heads, self.qk_nope_head_dim + self.v_head_dim)
 k_nope, v = torch.split(kv, [self.qk_nope_head_dim, self.v_head_dim], dim=-1)
 k = torch.cat([k_nope, k_pe.expand(-1, -1, self.n_local_heads, -1)], dim=-1)
 scores = torch.einsum("bshd,bthd->bsht", q, k).mul_(self.softmax_scale)

 # indexer
 topk_indices = self.indexer(x, qr, start_pos, freqs_cis, mask)
 index_mask = torch.full((bsz, seqlen, seqlen), float("-inf"), device=x.device).scatter_(-1, topk_indices, 0)
 index_mask += mask
 scores += index_mask.unsqueeze(2)

 scores = scores.softmax(dim=-1)
 x = torch.einsum("bsht,bthd->bshd", scores, v)
else: # 模型推理阶段
 if self.dequant_wkv_b is None and self.wkv_b.scale is not None:
  self.dequant_wkv_b = weight_dequant(self.wkv_b.weight, self.wkv_b.scale)
 wkv_b = self.wkv_b.weight if self.dequant_wkv_b is None else self.dequant_wkv_b
 wkv_b = wkv_b.view(self.n_local_heads, -1, self.kv_lora_rank)
 q_nope = torch.einsum("bshd,hdc->bshc", q_nope, wkv_b[:, :self.qk_nope_head_dim])
 scores = (torch.einsum("bshc,btc->bsht", q_nope, self.kv_cache[:bsz, :end_pos]) +
           torch.einsum("bshr,btr->bsht", q_pe, self.pe_cache[:bsz, :end_pos])) * self.softmax_scale

 # indexer
 topk_indices = self.indexer(x, qr, start_pos, freqs_cis, mask)
 index_mask = torch.full((bsz, 1, end_pos), float("-inf"), device=x.device).scatter_(-1, topk_indices, 0)
 scores += index_mask.unsqueeze(2)

 scores = scores.softmax(dim=-1)
 x = torch.einsum("bsht,btc->bshc", scores, self.kv_cache[:bsz, :end_pos])
 x = torch.einsum("bshc,hdc->bshd", x, wkv_b[:, -self.v_head_dim:])

在训练过程中：对于里面的 self.indexer(x, qr, start_pos, freqs_cis, mask) 输入的分别是原始的输入x以及通过压缩后的q，具体处理过程中，对于压缩后的q以及原始的输入x进行矩阵计算–>拆分（一部分去计算RoPE）–>两部分进行拼接分别得到Q、K的值对于这两部分的值，而后再去计算 Fast Walsh–Hadamard transform转换（让数值分布均匀），再去将q、k的值转换到fp8再去计算 index_score = fp8_index(q_fp8.contiguous(), weights, self.k_cache[:bsz, :end_pos].contiguous(), self.k_scale_cache[:bsz, :end_pos].contiguous()) 在得到index_score之后直接获取每一个token的重要性再去将其融入到最后的socre中即可。
在回过头去看模型解码过程中这个注意力方式是如何节约计算量的：传统的KV-cache操作中缓存大小是 $O(LHD)$ （分别表示序列长度、注意力头数、每个头维度） 通过MLA压缩得到 $O(LC)$ 在传统的QK计算中复杂度是 $O(L^2D)$ 使用MLA后计算量是 $O(L^2C)$，通过idnexer去选取top-k又可以降低到 $O(LkC)$。这是因为indexer 可以快速预测每个 query 对哪些历史 token 最感兴趣，只需要对这 k 个 token 进行正式的 Q-K 点积和 V 聚合，而不必对所有 L 个历史 token 计算，从而将 $O(L^2)$ 的复杂度降低到 $O(Lk)$。 在代码实现中，为了兼容 dense attention，通常会使用 mask 将非 top-k 的 token 对应的 score 设置为 $-\infty$。

很多人可能和我有一个疑问，你计算QK值而后通过topk获取需要关注的token而后将这个token作为一个mask叠加在score上，这一套下来计算量似乎和原始的没有差异？其实关键点就在这个mask上，我将socre通过mask（比如就是一个上三角矩阵）处理之后只有一半的socre了，那么这一半的socre就可以直接通过写算子去优化计算复杂度！！比如说可以直接测试 F.scaled_dot_product_attention(q, k, v, is_causal=False) 低于 is_causal 参数分别设置True/False去对比计算时间。

DeepSeek OCR

DeepSeek OCRv1

DeepSeek OCR³主要内容就是尝试使用视觉的方式去压缩长文本上下文，按照论文里面的描述就是：$f_{dec}:R^{n\times d_{latent}}\rightarrow R^{N\times d_{text}}, \hat{X}=f_{dec}(X)$
前面部分代表压缩的视觉tokens后面代表重构的文本表述。其实从上面公式就可以了解在DeepSeek OCR中做的就是：对于原始文本输入需要较长的tokens数量（比如说1w个字），但是如果这1w个文本都在图片上可能就是512个tokens。

但是作者只是在OCR邻域做测试，正如论文里面说的： It is reasonable to conjecture that LLMs, through specialized pretraining optimization, would demonstrate more natural integration of such capabilities.

对于传统多模态中的视觉结构：第一种使用多个视觉编码器进行编码处理，第二种：将图片切割为不同的patch而后进行处理，第三种：使用动态分辨率而后将图片去切割为不同patch进行编码。论文中使用的模型结构（为了实现：1、处理高分辨率；2、高分辨率小低激活；3、较少的视觉tokens；4、支持多分辨率输入；5、计算参数少）为：SAM-base（patch-size：16）+Conv（2层，kernel_size=3,strid=2, paddingg=1去对视觉token进行16倍下采样）+CLIP-large（去掉patch-embedding因为我的输入就是patch了），那么对于1024x1024首先划分为1024/16 × 1024/16 = 4096个patch token，在对4096个token进行压缩，数量变为4096/16 = 256。

在许多论文里面也用到了压缩技术（截至到：2025.10.23部分论文），比如说Glyph（Zhipu-清华）⁴和另外一篇论文⁵

对于这些内容核心的思路都是将文本转化为image来进行压缩tokens比如在论文[^11]中直接将text转化为latex格式的图片而后通过模型进行处理。

参考

只去对比整体¹框架，对所采用的激活函数，归一化处理，位置编码等参考：
1、位置编码：https://www.big-yellow-j.top/posts/2025/02/03/pos-embedding.html
2、归一化处理：https://www.big-yellow-j.top/posts/2025/01/05/dl-norm.html
3、分布式训练：https://www.big-yellow-j.top/posts/2025/01/03/DistributeTraining.html

GPT系列

1.GPT v1

对于大部分的深度学习任务，需要大量的标记数据（labeled data），但是如果使用大量的标记数据就会导致一个问题：构建得到的模型缺少适用性（可以理解为模型的泛化性能可能不佳）。那么就尝试使用非标记的数据（unlabelled data）但是这样一来又会有一个新的问题：时间消费大（time-consuming and expensive）。所以目前学者提出：使用预训练的词嵌入来提高任务性能。使用 未标注的文本信息（word-level information from unlabelled text）可能会：1、不清楚那种优化目标（optimization objective）在学习对迁移有用的文本表示时最有效；2、如何将这些学习到的表征有效的迁移到目标任务（target task）中。
作者提出：1、无监督的预训练（unsupervised pre-training）；2、监督的微调（supervised fine-tuning）
1、Unsupervised pre-training
给定一些列的的无标签的 token：$U={u_1,…,u_n}$，构建自回归的模型：

其中 $\theta$为模型的参数。作者在模型中使用 Transforme作为 decoder，在最后的模型上作者构建得到为：

其中$n$代表神经网路层的数目，$W_e$代表 token embedding matrix，$W_p$代表 position embedding matrix。对于无监督下的预训练：通过构建的数据集，去对模型的参数进行训练，得到模型的参数。

2、Supervised fine-tunning
作者在此部分提到：通过第一步得到的模型参数去对监督任务进行训练（采用的模型结构是没有变化的）。给定标签数据集$C$，给定输入：${x^1,…,x^m }$以及其标签$y$。将数据投入到预训练得到的模型参数里面得到：$h_l^m$，然后添加一个线性输出层（参数为：$W_y$）去对$y$进行预测。

对于上述两部分步骤直观上理解：人首先从外界获取大量信息：网络，书本等，把这些信息了解之后，然后去写作文或者去回答问题。
模型结构：

2.GPT v2

GPT v2区别前一个模型，区别在于将layer-norm 位置替换到每一个残差连接块的里面，也就是说在数据输入到 Multi-Head-Attention 以及 Feed-Forward 之前提前通过一层标准化处理。

3.GPT v3

GLM系列

GLM v1

训练过程任务大致如上描述²，用更加数学的描述是从输入文本$x=[x_1,…,x_n]$中随机采样多个文本片段${s_1,…,s_m}$ 对于每个片段都对应$x$ 中一系列的连续文本，对于采样的文本片段通过[MASK]进行标记这样一来我的输入就变为了 $x_{corrupt}$而后模型就通过自回归的方式去文本中预测缺失的词，这意味着在预测一个片段中的缺失词时，模型以自回归的方式从损坏的文本和之前预测的片段。为了充分捕捉不同片段之间的相互依赖关系，通过随机打乱片段的顺序，类似于排列语言模型，对应上面图中的b、c。除此之外模型还有的改进如下：
1、二维位置编码：第一个位置id用来标记Part A中的位置，第二个位置id用来表示跨度内部的相对位置。这两个位置id会通过embedding表被投影为两个向量，最终都会被加入到输入token的embedding表达中

Qwen模型系列

以Qwen2³为例用经过修改的 Transformer 架构，并采用了最近流行的大型语言模型（LLAMA）的训练方法，Qwen对架构的修改包括:
1、Embedding and output projection。根据初步实验结果，Qwen选择了非约束的嵌入方法，而不是将输入Embedding和输出projection的权重绑定在一起。为了在内存成本上取得更好的性能，Qwen做出了这个决定。
2、Positional embedding。Qwen选择Rotary Positional Embedding（RoPE，旋转位置编码）作为首选选项，以将位置信息纳入Qwen的模型中。RoPE已被广泛采用，并已在当今大型语言模型中取得了成功，尤其是PaLM和LLAMA。特别是，Qwen选择使用FP32精度来计算逆频率矩阵，而不是BF16或FP16，以便优先考虑模型性能并实现更高的准确性。
3、Bias。对于大多数层，Qwen遵循陈卓辉等人的做法删除偏差，但对于注意力中的QKV层添加了偏差，以增强模型的外推能力。
4、Pre-Norm& RMSNorm。在Transformer模型中，预归一化是最常用的方法，它已被证明比后归一化更能提高训练稳定性。此外，Qwen用RMSNorm取代了传统层归一化技术。这一改变带来了相同的表现水平，同时也提高了效率。
5、Activation function。Qwen选择了SwiGLU作为激活函数，它是Swish和门控线性单元的组合。Qwen的初始实验证明，基于GLU的激活函数通常优于其他基准选项，如GeLU。与以往研究常见的做法一样，Qwen将前馈网络（FFN）的维度从Hidden size的四倍减少到三分之八的Hidden size。

QWenLMHeadModel(
  (transformer): QWenModel(
    (wte): Embedding(151936, 4096)
    (drop): Dropout(p=0.0, inplace=False)
    (rotary_emb): RotaryEmbedding()
    (h): ModuleList(
      (0-31): 32 x QWenBlock(
        (ln_1): RMSNorm()
        (attn): QWenAttention(
          (c_attn): Linear(in_features=4096, out_features=12288, bias=True)
          (c_proj): Linear(in_features=4096, out_features=4096, bias=False)
          (attn_dropout): Dropout(p=0.0, inplace=False)
        )
        (ln_2): RMSNorm()
        (mlp): QWenMLP(
          (w1): Linear(in_features=4096, out_features=11008, bias=False)
          (w2): Linear(in_features=4096, out_features=11008, bias=False)
          (c_proj): Linear(in_features=11008, out_features=4096, bias=False)
        )
      )
    )
    (ln_f): RMSNorm()
  )
  (lm_head): Linear(in_features=4096, out_features=151936, bias=False)
)

DeepSeek系列

主要介绍DeepSeek v3⁴（简称DS）各类技术细节，对于DS在模型结构上和之前迭代版本的 DS-2无太大区别，还是使用混合专家模型，只是补充一个辅助损失去平衡不同专家之间的不均衡问题。

左侧结构和 GPT-2结构类似

在结构上DS主要的创新点在于：1、Multi-Head Latent Attention；2、DeepSeekMoE。前者为优化 KV-cache 操作，通过一个低秩的$c_r^{KV}$代替原本占用较高的QV的值（首先通过降维方式降低原本维度，这样一来在显存占用上就会降低，而后通过升维方式，恢复到原本的维度），后者为混合专家模型，不过区别于常用的MoE方法，在DS中将专家模型分为两类：1、Routed Expert；2、Shared Expert，前者直接将隐藏层的输入进行传入，后者则是通过门控网络筛选而后隐藏层的输入进行传入。
除此之外，在DS中使用Multi-Token Prediction（MTP⁵）技术

在DS中一个很耀眼的功能就是：DeepSeek-R1（一种思维链技术：CoT:Chain of Thought，在GPT-o1中也使用到这种技术）结合论文⁶中对 CoT技术的描述，可以简单的理解为：让LLM可以自主去思考问题，比如在论文⁶中对 CoT技术的描述。

相较之直接让GPT输出答案，区别在于还要他给出推理过程。结合在DS-R1⁴中的描述对于 DS-R1整体过程理解如下：

非常明显的一个强化学习过程，在论文里面提到的使用 Group Relative Policy Optimization（GRPO）⁷策略进行优化

在 DS-R1中作者提到的使用的模板

对于上述优化过程理解：比如说对于一个数学问题：$8+5=?$，这就是上面公式中所提到的question $q$，按照上面的描述，将会生成一系列的输出：${o_1,…,o_G}$
Step-1：生成若干的回答。${o_1,…,o_G}$
Step-2：对于生成的回答进行评分。${r_1,…,r_G}$，而后计算$A_i=\frac{r_i- \text{mean}({r_1,…,r_G})}{\text{std}({r_,…,r_G})}$
Step-3：使用裁剪更新策略：$\text{clip}(\frac{\pi_{\theta}(o_i|q)}{\pi_{\theta_{old}(o_i|q)}},1-\epsilon,\epsilon)$比如说：如果新策略开始给o1分配过高的概率，裁剪机制确保不会过度强调这个响应。这种方式保证了即使在像推理这样复杂的任务中，策略优化也能保持稳定和可靠。通过clip函数将内部值限定在$(1-\epsilon, 1+\epsilon)$之间
Step-4：通过KL散度（用来度量两个概率分布相似度的指标）惩罚偏差

PPO和 GRPO

上面提到的几个模型：
1、Policy Model：我们需要优化的模型
2、Value Model：估计状态的价值，帮助指导策略优化
3、Reference Model：提供历史策略的参考，确保优化过程中策略变化不过度
4、Reward Model：定义奖励信号，用于强化学习中的奖励反馈

GRPO实现，参考腾讯以及 Github上实现代码，对于复现可以直接用Huggingface中的 trl来进行复现

LLama系列

LLama v1

LLaMA⁸ 所采用的 Transformer 结构和细节，与标准的 Transformer 架构不同的地方包括采用了前置层归一化（Pre-normalization）并使用 RMSNorm归一化函数、激活函数更换为 SwiGLU，并使用了旋转位置嵌入（RoP），整体 Transformer 架构与 GPT-2 类似，大致模型结构如下：

image from: https://zhuanlan.zhihu.com/p/625775403

1、RMSNorm归一化函数：论文假设 LayerNorm 中的重新中心化不再是必须的（平移不变性不重要），RMSNorm 通过均方根（RMS）对每一层神经元的输入进行归一化，使模型具备重新缩放不变性和隐式学习率调整的能力。相比LayerNorm，RMSNorm计算更为简洁，大约可以节省 7% 到 64% 的运算。

和LayerNorm之间差异在于后者归一化处理计算就是常规的归一化（减均值然后除方差），但是在rmsenorm中直接除均方根，除此之外

2、SwiGLU激活函数：SwiGLU 激活函数与 GELU 激活函数类似，但 GELU 激活函数的计算速度更快，并且 GELU 激活函数的输出范围更广，因此 SwiGLU 激活函数被用于 LLaMA 模型。

其中a、b代表的就是两个线性变化输出（如$a=xW_1+b_1$），$Swish(a) = Sigmoid(\beta a) \cdot a$，和FFN结合代码为：

class FeedForward(nn.Module):
    def __init__(self, dim, hidden_dim):
        super().__init__()
        self.w1 = nn.Linear(dim, hidden_dim, bias=False)
        self.w2 = nn.Linear(hidden_dim, dim, bias=False)
        self.w3 = nn.Linear(dim, hidden_dim, bias=False)

    def forward(self, x):
        # SwiGLU: (SiLU(W1x) * W3x) @ W2
        return self.w2(F.silu(self.w1(x)) * self.w3(x))

3、RoPE旋转位置编码：文本序列是一种“顺序化”序列（文本字符之间排序对于文本的结果存在影响），因此通过位置编码去表示不同位置的输入，从而提高模型对长文本的生成效果。对于RoPE通俗的解释就是：就是对于输入调整向量乘以一个旋转矩阵（内积矩阵），但是为了使用绝对位置信息还会去补充参数m。在Llamav1中处理方式为：对于 token 序列中的每个词嵌入向量，都计算其对应的 query 和 key 向量；然后在得到 query 和 key 向量的基础上，对每个 token 位置都计算对应的旋转位置编码；接着对每个 token 位置的 query 和 key 向量的元素按照两两一组应用旋转变换；最后再计算 query 和 key 之间的内积得到 self-attention 的计算结果。

LLama v2

区别于上一代的LLama v1在LLama v2⁹中改进如下几点：
1、序列长度：由原来的2048 tokens变化为4096 tokens
2、使用GQA：通过使用KV-cache可以加快模型生成速度，但是也会造成过大的显存占用，因此LLama v2在decode阶段使用GQA来减少这个过程中的显存占用。

在LLama v2中对于GQA¹⁰实现如下：

def repeat_kv(x: torch.Tensor, n_rep: int) -> torch.Tensor:
  """torch.repeat_interleave(x, dim=2, repeats=n_rep)"""
  bs, slen, n_kv_heads, head_dim = x.shape
  # 根据n_rep，拓展KV
  if n_rep == 1:
      return x
  return (x[:, :, :, None, :].expand(bs, slen, n_kv_heads, n_rep, head_dim).reshape(bs, slen, n_kv_heads * n_rep, head_dim))

class Attention(nn.Module):
  def __init__(self, args: ModelArgs):
      super().__init__()
      ...
      self.n_local_heads = args.n_heads // model_parallel_size #Q的头数
      self.n_local_kv_heads = self.n_kv_heads // model_parallel_size  #KV的头数
      self.n_rep = self.n_local_heads // self.n_local_kv_heads 
      ...
      self.wq = ColumnParallelLinear(args.dim,args.n_heads * self.head_dim, # Q的头数* head_dim
                                     ...)
      self.wk = ColumnParallelLinear(args.dim,self.n_kv_heads * self.head_dim, # K的头数* head_dim
                                     ...)
      self.wv = ColumnParallelLinear(args.dim,self.n_kv_heads * self.head_dim,# V的头数* head_dim
                                     ...)
      self.wo = RowParallelLinear(args.n_heads * self.head_dim,args.dim,... )
​
      self.cache_k = torch.zeros((args.max_batch_size,args.max_seq_len,self.n_local_kv_heads, #KV的头数
              self.head_dim,)).cuda()
      self.cache_v = torch.zeros((args.max_batch_size,args.max_seq_len,self.n_local_kv_heads,#KV的头数         
                                  self.head_dim,)).cuda()
  def forward(
      self,
      x: torch.Tensor,
      start_pos: int,
      freqs_cis: torch.Tensor,
      mask: Optional[torch.Tensor],
  ):
      bsz, seqlen, _ = x.shape
      xq, xk, xv = self.wq(x), self.wk(x), self.wv(x)
​
      xq = xq.view(bsz, seqlen, self.n_local_heads, self.head_dim)
      xk = xk.view(bsz, seqlen, self.n_local_kv_heads, self.head_dim)
      xv = xv.view(bsz, seqlen, self.n_local_kv_heads, self.head_dim)

      xq, xk = apply_rotary_emb(xq, xk, freqs_cis=freqs_cis) #嵌入RoPE位置编码
      ...
      # 按此时序列的句子长度把kv添加到cache中
      # 初始在prompt阶段seqlen>=1, 后续生成过程中seqlen==1
      self.cache_k[:bsz, start_pos : start_pos + seqlen] = xk
      self.cache_v[:bsz, start_pos : start_pos + seqlen] = xv
      # 读取新进来的token所计算得到的k和v
      keys = self.cache_k[:bsz, : start_pos + seqlen]
      values = self.cache_v[:bsz, : start_pos + seqlen]
​
      # repeat k/v heads if n_kv_heads < n_heads
      keys = repeat_kv(keys, self.n_rep)  # (bs, seqlen, n_local_heads, head_dim)
      values = repeat_kv(values, self.n_rep)  # (bs, seqlen, n_local_heads, head_dim)

      xq = xq.transpose(1, 2)  # (bs, n_local_heads, seqlen, head_dim)
      keys = keys.transpose(1, 2)
      values = values.transpose(1, 2)
      #计算q*k
      scores = torch.matmul(xq, keys.transpose(2, 3)) / math.sqrt(self.head_dim)
      if mask is not None:
          #加入mask，使得前面的token在于后面的token计算attention时得分为0，mask掉
          scores = scores + mask  # (bs, n_local_heads, seqlen, cache_len + seqlen)
      scores = F.softmax(scores.float(), dim=-1).type_as(xq)
      output = torch.matmul(scores, values)  # (bs, n_local_heads, seqlen, head_dim)
      output = output.transpose(1, 2).contiguous().view(bsz, seqlen, -1)
      return self.wo(output)

LLama v3

模型¹¹参数细节：

BERT

BERT¹²训练主要分为如下阶段，预训练阶段任务：
1、Masked LM(MLM)
MLM是一种预训练任务，通过随机掩蔽输入序列中的部分词元，模型根据上下文预测被掩蔽的词元，从而学习双向语言表示。在模型中作者按照：80：10：10的比例进行处理（80：将词元替换为[MASK]；10：将词元替换为词汇表中随机选取的其他词。；10：保持原词元不变）
例子：
输入：“今天天气真好，我打算去[MASK]。”
模型的任务是根据上下文预测“[MASK]”应该是“公园”。
2、Next Sentence Prediction(NSP)
NSP是一种预训练任务，模型接收两个句子并预测第二个句子是否是第一个句子的后续。该任务帮助模型理解句子间的逻辑关系。
例子：
句子对：
句子1：“我喜欢去公园散步。”
句子2：“今天下午我会去跑步。”
模型的任务是判断第二个句子是否是第一个句子的自然延续，答案是“是”。

• 缺点
  1、BERT neglects dependency between the masked positions and suffers from a pretrain-finetune discrepancy（忽略了屏蔽位置之间的依赖性，并遭受预训练微调差异的影响）

这是因为在 BERT模型中，在预训练阶段会添加 [MASK]，但是在 下游任务(downsteram tasks)中并不会使用 [MASK]

参考

RORem

https://arxiv.org/pdf/2501.00740
https://github.com/leeruibin/RORem
基座模型：SDXL

数据集选择的是 RORD（通过视频帧中前后变化的物体就是mask进而构建高质量数据集）以及 Mulan数据集。对于输入到SDXL中的数据为：1、mask；2、原始图片；3、消除mask后的图片。而后将这三部分数据进行concat。
只通过上面过程微调的SDXL模型效果不佳，然后（上图的Human Annotation过程）再去从开源数据集中进行筛选（排除部分例子如：衣服、身体等）保证每种实体都有500种再得到数据之后然后就是人工筛选出高质量和低质量数据集。但是整个过程是消耗时间的因此会训练一个判别器网络结构（将SDXL-Inpainting中的下采样和中间层作为backbone而后通过Lora进行微调）通过人工筛选的数据集进行训练进而实现自动化过程（只有判别器得分>0.9的数据集才能算“合格”）。

本路文中（纯力大飞砖，通过构建大规模数据集去微调模型）对于模型改进不大，为例加速消除过程，再去通过蒸馏得到LCM模型来加速消除过程（从4s到0.5s）。

ObjectClear

https://arxiv.org/pdf/2505.22636
https://github.com/zjx0101/ObjectClear
基座模型：SDXL-Inpainting

本文出发点主要为两个：1、创建数据集；2、通过引入注意力机制（attention-mask）去引导模型消除，处理思路和论文：https://arxiv.org/pdf/2403.18818很相似

数据集构建

主要为两部分数据集（数据集构建方式上和SmartEraser论文里面处理方式相似：首先分割小实体是从图像中通过检查（DINO/YOLO等）加分割（SAM等）得到“小实体”而后将这些“小实体”去“合理”的贴到图像中）：1、拍摄数据集（2875张图片）；2、开源下载数据集。对于 拍摄数据集处理方式：首先将图片处理为512x512而后，直接通过DIBO+SAM去识别然后切割实体得到mask（$M_o$）然后去结合“mask相关的语义特征”（比如说阴影 $M_e$ 等）得到$M_{fg}=[M_o,M_e]$。除此之外对于下载得到的数据集首先是通过Mask2former（切割图像中的实体然后将一些特殊实体（比如说road等）作为背景）+DepthAnythin（通过整个算法去保证后续贴图的质量）后续就是直接将从相机拍摄照片里面抽取出来的小实体帖带开源数据集中。

模型结构

将基座模型（SDXL-Inpainting）的输入（1、噪声分布$z_t$；2、masked image $I_m$这个一般就是直接将mask从图中扣除；3、mask：$M_o$；4、文本prompt：$c$）中的mask image替换为原始的图像：$I_{in}$（这和之前的SmartEraser处理方式类似），除此之外对于输入DF模型中的处理思路和SmartEraser也是相似的：图像（需要消除的）和文本分别通过Clip不同编码器处理然后组合。而后输入到DF的Attention计算当中，对于特征组合部分代码处理方式为：

text_object_embed = self.fuse_fn(object_embeds)#两层mlp+norm
text_embeds_new = text_embeds.clone()
text_embeds_new[:, fuse_index, :] = text_object_embed.squeeze(1)

将得到的text_object_embed作为文本特征编码特征输入到unet中进行计算。除此之外论文中添加了一个mask loss计算。
除此之外使用Attention-Guided Fusion具体代码处理方式为：

def unet_store_cross_attention_scores(self, unet, attention_scores):
    from diffusers.models.attention_processor import (
        Attention,
        AttnProcessor,
        AttnProcessor2_0,
    )
    import types

    UNET_LAYER_NAMES = [
        "down_blocks.0",
        "down_blocks.1",
        "down_blocks.2",
        "mid_block",
        "up_blocks.1",
        "up_blocks.2",
        "up_blocks.3",
    ]

    start_layer = 0
    end_layer = 2
    applicable_layers = UNET_LAYER_NAMES[start_layer:end_layer]

    def make_new_get_attention_scores_fn(name):
        def new_get_attention_scores(module, query, key, attention_mask=None):
            attention_probs = module.old_get_attention_scores(
                query, key, attention_mask
            )
            attention_scores[name] = attention_probs
            return attention_probs

        return new_get_attention_scores

    for name, module in unet.named_modules():
        if isinstance(module, Attention) and "attn2" in name:
            if not any(layer in name for layer in applicable_layers):
                continue
            if isinstance(module.processor, AttnProcessor2_0):
                module.set_processor(AttnProcessor())
            module.old_get_attention_scores = module.get_attention_scores
            module.new_get_attention_scores = types.MethodType(
                make_new_get_attention_scores_fn(name), module
            )
            module.get_attention_scores = module.new_get_attention_scores

    return unet
....
fuse_index = 5
if self.config.apply_attention_guided_fusion:
    if i == len(timesteps) - 1:
        attn_key, attn_map = next(iter(self.cross_attention_scores.items()))
        attn_map = self.resize_attn_map_divide2(attn_map, mask, fuse_index)
        init_latents_proper = image_latents
        if self.do_classifier_free_guidance:
            _, init_mask = attn_map.chunk(2)
        else:
            init_mask = attn_map
        attn_map = init_mask
    self.clear_cross_attention_scores(self.cross_attention_scores)
...
attn_pils = []
if output_type == "pil" and attn_map is not None:
    for i in range(len(attn_map)):
        attn_np = attn_map[i].mean(dim=0).cpu().numpy() * 255.
        attn_pil = PIL.Image.fromarray(attn_np.astype(np.uint8)).convert("L")
        attn_pils.append(attn_pil)
    
    original_pils = self.image_processor.postprocess(init_image, output_type="pil")

    generated_pils = image

    fused_images = []
    for i in range(len(generated_pils)):
        ori_pil = original_pils[i]
        gen_pil = generated_pils[i]
        attn_pil = attn_pils[i]

        fused_np = attention_guided_fusion(np.array(ori_pil), np.array(gen_pil), np.array(attn_pil))
        fused_pil = PIL.Image.fromarray(fused_np.astype(np.uint8)).resize(ori_pil.size)

        fused_images.append(fused_pil)

    image = fused_images

首先对于unet_store_cross_attention_scores主要是处理如下两个步骤：1、搜集down_blocks.0和down_blocks.1中attn2模块的注意力分数；2、将down_blocks.0和down_blocks.1中attn2模块处理器从AttnProcessor2_0替换为AttnProcessor
而后在attention_guided_fusion设计中直接将三部分结果：1、原图 image；2、生成得到结果：generated_pils；3、将注意力得分转化为图像：attn_pil进行融合

总结

总得来说两个论文中都是通过构建数据集去训练模型，对与他们的数据集构建：Rorem中是直接通过“循环”方式去获得高质量数据（首先人工筛选高质量的消除数据集）然后去训练SDXL模型然后会有一个判别判断消除效果如何对于效果好的数据直接加到数据中再去训练模型循环上面过程，而再Object中的处理思路为切割实体然后再去将实体去贴到背景中。

flow-matching推荐文章
https://diffusionflow.github.io/

SDE以及ODE

在正式介绍之前简短了解一些SDE（随机微分方程）以及ODE（常微分方程），对于ODE一般定义就是：$\frac{dx_t}{dt}=f(x_t,t)$，对于SDE一般定义就是：$dx_t=f(x_t,t)dt+g(x_t,t)dW_t$。两者之间的差异就是SDE会比ODE多一个随机噪声项目，因为多了这个就会导致SDE的轨迹不在唯一每次的求解都是不同的，那么SDE/ODE和扩散模型之间联系在哪？

DDPM、DDIM

对于DDPM¹以及DDIM²在之前的博客有过简短介绍这里直接将两个放到一起进行介绍。扩散模型过程为：

通过对图片（$x_0$）不断添加高斯噪声最后得到 $x_T$而后通过反向去噪又得到新的图片。不过DDPM和DDIM之间存在一个很明显的差异就是：DDPM将加（去）噪视作一个马尔科夫链过程（简单理解为每一步 $t$都要依靠上一步 $t-1$），但是在DDIM过程中就会使用“跳步”来进行

DDPM生成过程：

但是对于DDPM存在一个最大的问题就是需要多步（一般选择T=1000）来生成图像，这样一来就会导致生成的速度很慢，因此后续就提出了DDIM其中DDIM生成过程为：

重点了解一下在diffusers库中如何处理这两个调度器的，以DDPM（源代码）为例，一般来说使用调度器无疑就是下面几个步骤：

from diffusers import DDPMScheduler
# 直接使用初始化的 调度器
noise_scheduler = DDPMScheduler(num_train_timesteps= config.num_train_timesteps,
                            beta_start= config.beta_start,
                            beta_end= config.beta_end,
                            beta_schedule= 'scaled_linear')
# 或则直接加载其他的模型的调度器
noise_scheduler = DDPMScheduler.from_pretrained("stabilityai/stable-diffusion-xl-base-1.0", cache_dir= config.cache_dir, subfolder="scheduler")
'''
不过值得注意的是在DDIM中会：noise_scheduler.set_timesteps(inference_steps) 来告诉用多少步进行推理（）
'''
# 将噪声添加到图片上
noise = torch.randn(image.shape, device= accelerator.device)
noise_image = noise_scheduler.add_noise(image, noise, timesteps)
...
# 将噪声进行剔除
noise = noise_scheduler.step(predicted_noise, t, noise).prev_sample

简短了解一下在DDPMScheduler中设计框架是如何的：

class DDPMScheduler(SchedulerMixin, ConfigMixin):
    @register_to_config
    def __init__(
        self, 
        num_train_timesteps: int = 1000, # 加噪的步数
        beta_start: float = 0.0001,      # \beta 起始数值
        beta_end: float = 0.02,          # \beta 最后数值
        beta_schedule: str = "linear",   # 线性加噪方式
        ...)
        ...
        if ...:
            ...
        elif beta_schedule == "linear":
            self.betas = torch.linspace(beta_start, beta_end, num_train_timesteps, dtype=torch.float32)
        # 1、初始化参数
        self.alphas = 1.0 - self.betas
        self.alphas_cumprod = torch.cumprod(self.alphas, dim=0)
        ...
        self.timesteps = torch.from_numpy(np.arange(0, num_train_timesteps)[::-1].copy())
    def add_noise(
        self,
        original_samples: torch.Tensor,
        noise: torch.Tensor,
        timesteps: torch.IntTensor,)
        # 2、加噪过程
        self.alphas_cumprod = self.alphas_cumprod.to(device=original_samples.device)
        alphas_cumprod = self.alphas_cumprod.to(dtype=original_samples.dtype)
        timesteps = timesteps.to(original_samples.device)

        sqrt_alpha_prod = alphas_cumprod[timesteps] ** 0.5
        sqrt_alpha_prod = sqrt_alpha_prod.flatten()
        while len(sqrt_alpha_prod.shape) < len(original_samples.shape):
            sqrt_alpha_prod = sqrt_alpha_prod.unsqueeze(-1)

        sqrt_one_minus_alpha_prod = (1 - alphas_cumprod[timesteps]) ** 0.5
        sqrt_one_minus_alpha_prod = sqrt_one_minus_alpha_prod.flatten()
        while len(sqrt_one_minus_alpha_prod.shape) < len(original_samples.shape):
            sqrt_one_minus_alpha_prod = sqrt_one_minus_alpha_prod.unsqueeze(-1)

        noisy_samples = sqrt_alpha_prod * original_samples + sqrt_one_minus_alpha_prod * noise
        return noisy_samples

    def step(
        self,
        model_output: torch.Tensor,
        timestep: int,
        sample: torch.Tensor,
        generator=None,
        return_dict: bool = True,):
        # 3、生成过程
        t = timestep
        prev_t = self.previous_timestep(t)
        # 首先计算 alpha等参数
        alpha_prod_t = self.alphas_cumprod[t]
        alpha_prod_t_prev = self.alphas_cumprod[prev_t] if prev_t >= 0 else self.one
        beta_prod_t = 1 - alpha_prod_t
        beta_prod_t_prev = 1 - alpha_prod_t_prev
        current_alpha_t = alpha_prod_t / alpha_prod_t_prev
        current_beta_t = 1 - current_alpha_t
        # 而后计算 预测结果 DDPM有3种计算过程 epsilon sample v_prediction
        if self.config.prediction_type == "epsilon":
            pred_original_sample = (sample - beta_prod_t ** (0.5) * model_output) / alpha_prod_t ** (0.5)
        ...
        # 裁剪预测值
        ...
        elif self.config.clip_sample:
            pred_original_sample = pred_original_sample.clamp(
                    -self.config.clip_sample_range, self.config.clip_sample_range
                )
        # important

1、初始化参数（DDPM和DDIM中没什么差异）。首先是根据 beta_schedule来生成在 num_train_timesteps下参数 $\beta$的值（比如说 linear那么在1000步下就会生成（直接通过torch.linspace）从 (1-beta_start)-(1-beta_end) 的1000个数字）而后就是定义好加噪比较重要的几个参数：$\alpha$ 以及迭代次数 $t$，对于self.alphas_cumprod则是直接计算累乘得到的结果。上面过程对应：

2、加噪过程（DDPM和DDIM中没什么差异）。这个整个过程也比较简单就是直接通过计算：$X_T=\sqrt{\bar{\alpha_T}}x_0+ \sqrt{1- \bar{\alpha_T}}\epsilon$
3、生成过程。输入三个参数分别表示：1、model_output：模型预测得到的噪声数值；2、timestep：时间步；3、sample：就是我们加载后的$x_t$（最开始就是一个纯噪声随着迭代逐渐“清晰”）。生成图像过程中无疑就是直接通过$t$去推导 $t-1$的图像结果，因此在DDPM生成过程中 首先是分别计算 $\alpha_{t}$以及 $\alpha_{t-1}$，不过生成过程有三种。

• epsilon：预测噪声 $\epsilon$（将上面加噪公司逆推得到$x_0$）
• sample：直接用 $x_0$就是模型的输出
• v_prediction：预测$v$（Stable Diffusion 2.x一般就是这个）

最重要的是后面的 important部分代码，在DDPM中需要计算：

代码中对应：

pred_original_sample_coeff = (alpha_prod_t_prev ** (0.5) * current_beta_t) / beta_prod_t
current_sample_coeff = current_alpha_t ** (0.5) *beta_prod_t_prev / beta_prod_t
pred_prev_sample = pred_original_sample_coeff *pred_original_sample + current_sample_coeff * sample

最后在模型里面会返回两部分内容：1、pred_prev_sample；2、pred_original_sample。对于这两个值分别表示的是：模型认为最终的干净图像（完全无噪声）（pred_original_sample）。采样一步后，预计在第 499 步应该长的样子（pred_prev_sample）。对比在DDIM中的差异，第一个就是时间步处理差异，在DDPM中直接用$t-1$来获取上一步就行，但是在DDIM中需要计算timestep - self.config.num_train_timesteps // self.num_inference_steps这是因为DDIM会使用“跳步”；2、在计算 $x_0$上两者之间不存差异，只是计算上一步在公式上存在差异（DDIM计算公式）：

variance = self._get_variance(timestep, prev_timestep)
std_dev_t = eta * variance ** (0.5)
if use_clipped_model_output:
    pred_epsilon = (sample - alpha_prod_t ** (0.5) * pred_original_sample) / beta_prod_t ** (0.5)
pred_sample_direction = (1 - alpha_prod_t_prev - std_dev_t**2) ** (0.5) * pred_epsilon
prev_sample = alpha_prod_t_prev ** (0.5) * pred_original_sample + pred_sample_direction

不同调度器生成对比

只是简单对比不同调度器在生成效果上的速度差异（SDXL模型）

不同调度器生成对比，从上面简单比较发现一般来说需要20-30步（建立在不适用LCM模型基础上）才能生成一个效果较好的图像，从测试过程发现基本（20-30步）一张图片消耗时间为0.2s左右（A100-80G以及使用float16）。从上面的测试结果上来看UniPCMultistepScheduler和 DPMSolverMultistepScheduler测试的效果最好（仅仅只从迭代步数上分析），借用ChatGPT对不同生成器的分析如下：

不过如果去仔细看生成图像的细节内容的话（单独对比了Unip、DPM、DDIM从10-50步使用的模型是SDXL并且使用float16）得到测试结果

此过程使用的prompt（直接GPT生成）：

validation_prompt = [
    # 1. 动态多主体 + 复杂光影
    "A fierce dog fighting a cat inside a Victorian living room, ultra realistic fur, dynamic cinematic lighting, motion blur, 8k hyper detail, dramatic shadows, volumetric fog",
    # 2. 科幻场景 + 光影/反射
    "A futuristic cyberpunk city skyline at sunset with flying cars, glowing neon signs, reflective glass skyscrapers, cinematic wide-angle shot, ultra realistic 8k textures, complex lighting, atmospheric haze",
    # 3. 写实人像 + 材质对比
    "A close-up portrait of an elderly woman with deep wrinkles, realistic skin texture, soft diffused lighting, cinematic depth of field, ultra detailed eyes, 8k hyper realism",
    # 4. 自然风景 + 微距细节
    "A crystal-clear mountain lake surrounded by pine trees, sunlight filtering through mist, hyper realistic reflections on water, ultra detailed rocks and moss, 8k cinematic composition",
    # 5. 奇幻场景 + 复杂材质
    "A medieval knight in silver armor standing in a glowing enchanted forest, bioluminescent plants, soft god rays, ultra detailed metallic reflections, cinematic epic fantasy lighting, 8k resolution",
    # 6. 室内物品 + 精细纹理
    "A rustic wooden table with a vintage pocket watch, spilled coffee, handwritten letters, soft morning sunlight, ultra detailed textures, shallow depth of field, 8k macro photography style"
]
negative_prompt = "blurry, low quality, distorted, extra limbs, deformed, low contrast, unrealistic lighting, bad anatomy, oversaturated"

参考

主要介绍基于Unet以及基于Dit框架的基座扩散模型以及部分GAN和VAE模型，其中SD迭代版本挺多的（从1.2到3.5）因此本文主要重点介绍SD 1.5以及SDXL两个基座模型，以及两者之间的对比差异，除此之外还有许多闭源的扩散模型比如说Imagen、DALE等。对于Dit基座模型主要介绍：Hunyuan-DiT、FLUX.1等。对于各类模型评分网站（模型评分仁者见仁智者见智，特别是此类生成模型视觉图像生成是一个很主观的过程，同一张图片不同人视觉感官都是不同的）：https://lmarena.ai/leaderboard

SD系列模型

SD1.5 vs SDXL

SDv1.5: https://huggingface.co/stable-diffusion-v1-5/stable-diffusion-v1-5
SDXL¹:https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0

两者模型详细的模型结构：SDv1.5–SDXL模型结构图，其中具体模型参数的对比如下：
1、CLIP编码器区别：
在SD1.5中选择的是CLIP-ViT/L（得到的维度为：768）而在SDXL中选择的是两个CLIP文本编码器：OpenCLIP-ViT/G（得到的维度为：1280）以及CLIP-ViT/L（得到维度为：768）在代码中对于两个文本通过编码器处理之后SDXL直接通过cat方式拼接：prompt_embeds = torch.concat(prompt_embeds_list, dim=-1) 也就是说最后得到的维度为：[..,..,1280+768]。最后效果很明显：SDXL对于文本的理解能力大于SD1.5
2、图像输出维度区别：
再SD1.5中的默认输出是：512x512而再SDXL中的默认输出是：1024x1024，如果希望将SD1.5生成的图像处理为1024x1024可以直接通过超分算法来进行处理，除此之外在SDXL中还会使用一个refiner模型（和Unet的结构相似）来强化base模型（Unet）生成的效果。
3、SDXL论文中的技术细节：

• 1、图像分辨率优化策略。

数据集中图像的尺寸图像利用率问题（选择512x512舍弃256x256就会导致图像大量被舍弃）如果通过超分辨率算法将图像就行扩展会放大伪影，这些伪影可能会泄漏到最终的模型输出中，例如，导致样本模糊。（The second method, on the other hand, usually introduces upscaling artifacts which may leak into the final model outputs, causing, for example, blurry samples.）作者做法是：训练阶段直接将原始图像的分辨率 $c=(h_{org},w_{org})$作为一个条件，通过傅里叶特征编码而后加入到time embedding中，推理阶段直接将分辨率作为一个条件就行嵌入，进而实现：当输入低分辨率条件时，生成的图像较模糊；在不断增大分辨率条件时，生成的图像质量不断提升。

• 2、图像裁剪优化策略

直接统一采样裁剪坐标top和cleft（分别指定从左上角沿高度和宽度轴裁剪的像素数量的整数），并通过傅里叶特征嵌入将它们作为调节参数输入模型，类似于上面描述的尺寸调节。第1，2点代码中的处理方式为：

def _get_add_time_ids(
        self, original_size, crops_coords_top_left, target_size, dtype, text_encoder_projection_dim=None
    ):
    add_time_ids = list(original_size + crops_coords_top_left + target_size)

    passed_add_embed_dim = (
        self.unet.config.addition_time_embed_dim * len(add_time_ids) + text_encoder_projection_dim
    )
    expected_add_embed_dim = self.unet.add_embedding.linear_1.in_features
    ...
    add_time_ids = torch.tensor([add_time_ids], dtype=dtype)
    return add_time_ids

推荐阅读：
1、SDv1.5-SDXL-SD3生成效果对比

SD3模型

SD3的diffusers官方文档：StableDiffusion3Pipeline

https://zhouyifan.net/2024/09/03/20240809-flux1/
SD3²、FLUX对于这几组模型的前世今生不做介绍，主要了解其模型结构以及论文里面所涉及到到的一些知识点。首先介绍SD3模型在模型改进上³：1、改变训练时噪声采样方法；2、将一维位置编码改成二维位置编码；3、提升 VAE 隐空间通道数（作者实验发现最开始VAE会将模型下采样8倍数并且处理通道为4的空间，也就是说 $512 \times 512 \times 3 \rightarrow 64\times 64 \times 4$，不过在 SD3中将通道数由4改为16）；4、对注意力 QK 做归一化以确保高分辨率下训练稳定。

其中SD3模型的整体框架如上所述:
1、文本编码器处理（代码），在text encoder上SD3使用三个文本编码器：clip-vit-large-patch14、 laion/CLIP-ViT-bigG-14-laion2B-39B-b160k 、 t5-v1_1-xxl ，对于这3个文本编码器对于文本的处理过程为：就像SDXL中一样首先3个编码器分别都去对文本进行编码，首先对于两个CLIP的文本编码处理过程为直接通过CLIP进行 prompt_embeds = text_encoder(text_input_ids.to(device)...) 而后去选择 prompt_embeds.hidden_states[-(clip_skip + 2)]（默认条件下 clip_skip=None也就是直接选择倒数第二层）那么最后得到文本编码的维度为：torch.Size([1, 77, 768]) torch.Size([1, 77, 1280]) 而T5的encoder就比较检查直接通过encoder进行编码，那么其编码维度为：torch.Size([1, 256, 4096])，这样一来就会得到3组的文编码，对于CLIP的编码结果直接通过 clip_prompt_embeds=torch.cat([prompt_embed, prompt_2_embed], dim=-1) 即可，在将得到后的 clip_prompt_embeds结果再去和T5的编码结果进行拼接之前会首先 clip_prompt_embeds=torch.nn.functional.pad(clip_prompt_embeds, (0, t5_prompt_embed.shape[-1] - clip_prompt_embeds.shape[-1])) 而后将T5的文本内容和 clip_prompt_embeds进行合并 prompt_embeds = torch.cat([clip_prompt_embeds, t5_prompt_embed], dim=-2)。由于使用T5模型导致模型的参数比较大进导致模型的显存占用过大（2080Ti等GPU上轻量化的部署推理SD 3模型，可以只使用CLIP ViT-L + OpenCLIP ViT-bigG的特征，此时需要将T5-XXL的特征设置为zero（不加载）⁴），选择不去使用T5模型会对模型对于文本的理解能力有所降低。

SD3使用T5-XXL模型。这使得以少于24GB的VRAM在GPU上运行模型，即使使用FP16精度。因此如果需要使用就需要：1、将部分模型下放到CPU上；2、直接取消T5的使用（StableDiffusion3Pipeline.from_pretrained("stabilityai/stable-diffusion-3-medium-diffusers",text_encoder_3=None,tokenizer_3=None,torch_dtype=torch.float16)）。
文本编码过程：1、CLIP编码分别得到：[1, 77, 768]和[1, 77, 1280]；2、T5编码得到：[1, 256, 4096]；3、CLIP文本编码拼接：[1, 77, 2048]在去将其通过pad填充到和T5一致得到最后CLIP编码器维度为：[1, 77, 4096]；4、最后文本编码维度：[1, 333, 4096]

2、Flow Matching模式（原理）；
3、MM-Dit模型架构（代码）：观察上面过程，扩散模型输入无非就是3个内容：1、时间步（$y$）；2、加噪处理的图像（$x$）；3、文本编码（$c$）。首先对于 时间步而言处理过程为：直接通过 Sin位置编码然后去和CLIP（两个合并的）进行组合即可对于另外两个部分直接通过代码进行理解：

def forward(
    self,
    hidden_states: torch.Tensor, # 加噪声的图片 (batch size, channel, height, width)
    encoder_hidden_states: torch.Tensor = None, # 条件编码比如说：文本prompt (batch size, sequence_len, embed_dims)
    pooled_projections: torch.Tensor = None, # 池化后的条件编码 (batch size, embed_dims)
    timestep: torch.LongTensor = None, # 时间步编码
    block_controlnet_hidden_states: List = None,
    joint_attention_kwargs: Optional[Dict[str, Any]] = None,
    return_dict: bool = True,
    skip_layers: Optional[List[int]] = None,
) -> Union[torch.Tensor, Transformer2DModelOutput]:
    ...
    height, width = hidden_states.shape[-2:]
    # Step-1 
    hidden_states = self.pos_embed(hidden_states) # 直接使用 2D的位置编码
    temb = self.time_text_embed(timestep, pooled_projections)
    encoder_hidden_states = self.context_embedder(encoder_hidden_states) # 一层线性映射
    ...
    # Step-2
    for index_block, block in enumerate(self.transformer_blocks):
        is_skip = True if skip_layers is not None and index_block in skip_layers else False
        if torch.is_grad_enabled() and self.gradient_checkpointing and not is_skip:
            ...
        elif not is_skip:
            encoder_hidden_states, hidden_states = block(
                hidden_states=hidden_states,
                encoder_hidden_states=encoder_hidden_states,
                temb=temb,
                joint_attention_kwargs=joint_attention_kwargs,
            )
        ...
    # Step-3
    hidden_states = self.norm_out(hidden_states, temb)
    hidden_states = self.proj_out(hidden_states)
    patch_size = self.config.patch_size
    height = height // patch_size
    width = width // patch_size

    hidden_states = hidden_states.reshape(
        shape=(hidden_states.shape[0], height, width, patch_size, patch_size, self.out_channels)
    )
    hidden_states = torch.einsum("nhwpqc->nchpwq", hidden_states)
    output = hidden_states.reshape(
        shape=(hidden_states.shape[0], self.out_channels, height * patch_size, width * patch_size)
    )
    ...
    if not return_dict:
        return (output,)
    return Transformer2DModelOutput(sample=output)

Step-1：首先去将图像 $x$使用2D 正弦-余弦位置编码进行处理，对于时间步直接sin位置编码，对于条件（文本prompt等）直接通过一层线性编码处理。
Step-2：然后就是直接去计算Attention：encoder_hidden_states, hidden_states = block(hidden_states=hidden_states,encoder_hidden_states=encoder_hidden_states,temb=temb,joint_attention_kwargs=joint_attention_kwargs,)，对于这个block的设计过程为：

def forward(
    self,
    hidden_states: torch.FloatTensor,
    encoder_hidden_states: torch.FloatTensor,
    temb: torch.FloatTensor,
    joint_attention_kwargs: Optional[Dict[str, Any]] = None,
):
    joint_attention_kwargs = joint_attention_kwargs or {}
    # Aeetntion Step-1
    if self.use_dual_attention:
        norm_hidden_states, gate_msa, shift_mlp, scale_mlp, gate_mlp, norm_hidden_states2, gate_msa2 = self.norm1(
            hidden_states, emb=temb
        )
    else:
        ...

    if self.context_pre_only:
        ...
    else:
        norm_encoder_hidden_states, c_gate_msa, c_shift_mlp, c_scale_mlp, c_gate_mlp = self.norm1_context(
            encoder_hidden_states, emb=temb
        )
    # Attention Step-2
    attn_output, context_attn_output = self.attn(
        hidden_states=norm_hidden_states,
        encoder_hidden_states=norm_encoder_hidden_states,
        **joint_attention_kwargs,
    )
    attn_output = gate_msa.unsqueeze(1) * attn_output
    hidden_states = hidden_states + attn_output
    ...
    norm_hidden_states = self.norm2(hidden_states)
    norm_hidden_states = norm_hidden_states * (1 + scale_mlp[:, None]) + shift_mlp[:, None]
    if self._chunk_size is not None:
        ...
    else:
        ff_output = self.ff(norm_hidden_states)
    ff_output = gate_mlp.unsqueeze(1) * ff_output
    hidden_states = hidden_states + ff_output
    if self.context_pre_only:
        ...

    return encoder_hidden_states, hidden_states

计算注意力过程中，首先 Attention Step-1：正则化处理（正如上面Dit中的一样将条件拆分为几个参数，观察SD3图中的MMDit设计，会将 加噪声处理的图片 和 条件编码都去（处理方式相同）通过 “正则化”，在SD3中处理方式为，直接 shift_msa, scale_msa, gate_msa, shift_mlp, scale_mlp, gate_mlp, shift_msa2, scale_msa2, gate_msa2 = emb.chunk(9, dim=1) 拆分之后去通过 LayerNorm处理之后得到 norm_hidden_states 而后在去计算 norm_hidden_states * (1 + scale_msa[:, None]) + shift_msa[:, None]）然后后面处理过程就比较简单和上面的流程图是一样的。
这样一来一个MMDit block就会返回两部分结果 encoder_hidden_states, hidden_states（区别Dit之间在于，MMDit是将image和text两种模态之间的信息进行融合二Dit只是使用到imgae一种模态）
Step-3就比较简单就是一些norm等处理。
总的来说MMDiT Block 的输入主要有三部分：时间步嵌入 $y$：通过一个 MLP 投影，得到一组参数，用于调节 Block 内的 LayerNorm / Attention / MLP（类似 FiLM conditioning）。图像 token $x$：由加噪图像 latent patch embedding 得到，并加上 2D 正弦余弦位置编码。文本 token $c$：来自文本编码器的输出，一般带有 1D 位置编码。Block 内部机制：将 $x$ 和 $c$ 拼接在一起，作为 Transformer 的输入序列。在自注意力层中，$x$ token 能和 $c$ token 交互，从而实现 跨模态融合。$y$（timestep embedding）通过投影提供额外的条件控制。

2D 正弦-余弦位置编码

左侧为一般的位置编码方式，但是有一个缺点：生成的图像的分辨率是无法修改的。比如对于上图，假如采样时输入大小不是4x3，而是4x5，那么0号图块的下面就是5而不是4了，模型训练时学习到的图块之间的位置关系全部乱套，因此就通过2D位置去代表每一块的位置信息。

简单补充介绍一下Flux.1模型（主要是文生图模型），对于FLUX.1模型而言其结构如下

区别SD3模型在于，FLUX.1在文本编码器选择上只使用了2个编码器（CLIPTextModel、T5EncoderModel）并且FLUX.1 VAE架构依然继承了SD 3 VAE的8倍下采样和输入通道数（16）。在FLUX.1 VAE输出Latent特征，并在Latent特征输入扩散模型前，还进行了 _pack_latents操作，一下子将Latent特征通道数提高到64（16 -> 64），换句话说，FLUX.1系列的扩散模型部分输入通道数为64，是SD 3的四倍。对于 _pack_latents做法是会将一个 $2\times 2$的像素去补充到通道中。

def _pack_latents(latents, batch_size, num_channels_latents, height, width):
    latents = latents.view(batch_size, num_channels_latents, height // 2, 2, width // 2, 2)
    latents = latents.permute(0, 2, 4, 1, 3, 5)
    latents = latents.reshape(batch_size, (height // 2) * (width // 2), num_channels_latents * 4)
    return latents

除去改变text的编码器数量以及VAE的通道数量之外，FLUX.1还做了如下的改进：FLUX.1 没有做 Classifier-Free Guidance (CFG)（对于CFG一般做法就是直接去将“VAE压缩的图像信息变量复制两倍” torch.cat([latents] * 2)，文本就是直接将negative_prompt的编码补充到文本编码中 torch.cat([negative_prompt_embeds, prompt_embeds], dim=0)）而是把指引强度 guidance 当成了一个和时刻 t 一样的约束信息，传入去噪模型 transformer 中。在transformer模型结构设计中，SD3是直接对图像做图块化，再设置2D位置编码PatchEmbed，在FLUX.1中使用的是 FluxPosEmbed（旋转位置编码）

# SD3
self.pos_embed = PatchEmbed(height=sample_size,width=sample_size,patch_size=patch_size,in_channels=in_channels,)
embed_dim=self.inner_dim,pos_embed_max_size=pos_embed_max_size,  # hard-code for now.)
# FLUX.1
self.pos_embed = FluxPosEmbed(theta=10000, axes_dim=axes_dims_rope)

Imagen

https://imagen.research.google/
https://deepmind.google/models/imagen/
非官方实现：https://github.com/lucidrains/imagen-pytorch
类似Github，通过3阶段生成：https://github.com/deep-floyd/IF

Imagen⁵论文中主要提出：1、纯文本语料库上预训练的通用大型语言模型（例如T5、CLIP、BERT等）在编码图像合成的文本方面非常有效：在Imagen中增加语言模型的大小比增加图像扩散模型的大小更能提高样本保真度和Imagetext对齐。

2、通过提高classifier-free guidance weight（$\epsilon(z,c)=w\epsilon(z,c)+ (1-w)\epsilon(z)$ 也就是其中的参数 $w$）可以提高image-text之间的对齐，但会损害图像逼真度，产生高度饱和不自然的图像（论文里面给出的分析是：每个时间步中预测和正式的x都会限定在 $[-1,1]$这个范围但是较大的 $w$可能导致超出这个范围），论文里面做法就是提出 动态调整方法：在每个采样步骤中，我们将s设置为 $x_0^t$中的某个百分位绝对像素值，如果s>1，则我们将 $x_0^t$阈值设置为范围 $[-s,s]$，然后除以s。

3、和上面SD模型差异比较大的一点就是，在imagen中直接使用多阶段生成策略，模型先生成64x64图像再去通过超分辨率扩散模型去生成256x256以及1024x1024的图像，在此过程中作者提到使用noise conditioning augmentation（NCA）策略（对输入的文本编码后再去添加随机噪声）

Dit

https://github.com/facebookresearch/DiT

Dit⁶模型结构上，1、模型输入，将输入的image/latent切分为不同patch而后去对不同编码后的patch上去添加位置编码（直接使用的sin-cos位置编码），2、时间步以及条件编码，对于时间步t以及条件c的编码而后将两部分编码后的内容进行相加，在 TimestepEmbedder上处理方式是：直接通过正弦时间步嵌入方式而后将编码后的内容通过两层liner处理；在 LabelEmbedder处理方式上就比较简单直接通过 nn.Embedding进行编码处理。3、使用Adaptive layer norm（adaLN）block以及adaZero-Block（对有些参数初始化为0，就和lora中一样初始化AB为0，为了保证后续模型训练过程中的稳定）

在layernorm中一般归一化处理方式为：$\text{Norm}(x)=\gamma \frac{x-\mu}{\sqrt{\sigma^2+ \epsilon}}+\beta$ 其中有两个参数 $\gamma$ 和 $\beta$ 是固定的可学习参数（比如说直接通过 nn.Parameter 进行创建），在模型初始化时创建，并在训练过程中通过梯度下降优化。但是在 adaLN中则是直接通过 $\text{Norm}(x)=\gamma(c) \frac{x-\mu}{\sqrt{\sigma^2+ \epsilon}}+\beta(c)$ 通过输入的条件c进行学习的
总结Dit训练过程：首先将图片通过VAE进行编码，而后将编码后的内容patch化然后输入到Ditblock（就是通过一些Attention结构进行堆叠）中去预测模型的噪声

Hunyuan-DiT

https://huggingface.co/Tencent-Hunyuan/HunyuanDiT

腾讯的Hunyuan-DiT⁷模型整体结构

整体框架不是很复杂，1、文本编码上直接通过结合两个编码器：CLIP、T5；2、VAE则是直接使用的SD1.5的；3、引入2维的旋转位置编码；4、在Dit结构上（图片VAE压缩而后去切分成不同patch），使用的是堆叠的注意力模块（在SD1.5中也是这种结构）self-attention+cross-attention（此部分输入文本）。论文里面做了改进措施：1、借鉴之前处理，计算attention之前首先进行norm处理（也就是将norm拿到attention前面）。
简短了解一下模型是如何做数据的：

PixArt

https://pixart-alpha.github.io/

华为诺亚方舟实验室提出的 $\text{PixArt}-\alpha$模型整体框架如下：

相比较Dit模型论文里面主要进行的改进如下：
1、Cross-Attention layer，在DiT block中加入了一个多头交叉注意力层，它位于自注意力层（上图中的Multi-Head Self
-Attention）和前馈层（Pointwise Feedforward）之间，使模型能够灵活地引入文本嵌入条件。此外，为了利用预训练权重，将交叉注意力层中的输出投影层初始化为零，作为恒等映射，保留了输入以供后续层使用。
2、AdaLN-single，在Dit中的adaptive normalization layers（adaLN）中部分参数（27%）没有起作用（在文生图任务中）将其替换为adaLN-single

Flux系列模型

对于Flux系列模型截至到2026-02-14，主要用的比较多的就是Context以及较新的Klein模型（都是文生图+图生图模型），这里简单介绍一下这两个模型。

Flux.1-Context模型

对于Flux-Context⁸模型在官方hf上开源了多种系列模型，主要流行的有3个版本：1、MAX和PRO：商用闭源；2、DEV：开源-12B，对于dev其官方权重地址为：https://huggingface.co/black-forest-labs/FLUX.1-Kontext-dev除此之外相对使用比较多的是其通过nunchakus量化后的模型权重：mit-han-lab/nunchaku-flux.1-kontext-dev。简单介绍一下其模型原理如下：

仅从上面模型架构很容易发现，在整体架构上还是采用的是DiT模型框架核心差异在于将原图进行补充输入，按照论文中的描述其生成过程为：$p(x\vert y,c)$：1、提示词文本输入，对应公式中的c，2、原图输入（这个主要是对于图像编辑任务而言需要的）对应公式中的y，如果是文生图那么$y=\phi$；3、噪声输入（将噪声转换为我的目标输入图像）。区别其他的图像编辑模型，一般而言会直接对原图进行vae编码而后添加噪声，在context上保持原图进行输入，对于这两部分输入都会去通过vae进行编码而后去对编码后的内容直接进行拼接，比如说：

if image_reference_latents is not None:
    latent_model_input = torch.cat([latents, image_reference_latents], dim=1)
elif image_latents is not None:
    latent_model_input = torch.cat([latents, image_latents], dim=1)

其中latents、image_reference_latents、image_latents分别表示添加噪声的原始图像、参考图像vae编码、原始图像vae编码。进一步对于其模型结构如下：

按照论文中第2章描述：从头训练的16通道VAE潜在空间里。它混合使用了19个double-stream（前期分离）和 38个single-stream（后期融合）的 Transformer 结构，用fused FFN 提效，用3D RoPE做位置编码。堆区其中提到的两种stream方式简单总结如下：所谓的double以及single无非就是对特征分别使用单独的linear去分别处理文本以及图像特征，而对于single则是将两部分特征拼接起来再用linear处理。3D rope：指的是在上述提到的2D位置编码上引入时间特征t。

Flux.2-Klein

对于Klein模型官方分别开源了：9B、4B两种版本以及所对应的蒸馏版本，其中4B可以被使用与商业用途。Klein模型在模型的推理以及显存占用上都是极大的改善

Qwen image系列模型

Qwen image

官方blog：https://qwenlm.github.io/zh/blog/qwen-image/
Qwen Image图片编辑：https://huggingface.co/Qwen/Qwen-Image-Edit
Qwen Image：https://huggingface.co/Qwen/Qwen-Image
Qwen Image Lora微调8步生图：https://huggingface.co/lightx2v/Qwen-Image-Lightning
Qwen Image图片编辑int4量化版本：https://huggingface.co/nunchaku-tech/nunchaku-qwen-image，代码

Qwen image⁹无论是多行文字、段落布局，还是中英文等不同语种，Qwen-Image都能以极高的保真度进行渲染，尤其在处理复杂的中文（logographic languages）方面，表现远超现有模型（不过目前：2025.08.29模型全权重加载的话一般设备很难使用，不过又量化版本可以尝试）模型整体结构：

整体框架上还是MMDit结构和上面的SD3都是一致的，不过模型的改进在于：1、区别之前的都是使用CLIP模型去对齐图片-文本之间信息，在Qwen Image中则是直接使用Qwen2.5-VL；2、对于VAE模型则是直接使用Wan-2.1-VAE（不过选择冻结encoder部分只去训练decoder部分）；3、模型的结构还是使用MMDit结构，知识将位置编码方式改为Multimodal Scalable RoPE (MSRoPE)，位置编码方式

大致框架了解之后细看他的数据是如何收集的以及后处理的：

对于收集到数据之后，论文里面通过如下操作进行后处理：1、阶段一过滤数据：模型预训练是在256x256的图片上进行训练的，因此，过滤掉256x256以外的图片还有一些低质量图片等；2、阶段二图片质量强化：主要还是过滤一些低质量图片如亮度纹理等；

Z-Image 以及 Z-Image-Turbo

对于两种模型权重地址如下：1、Z-Image HuggingFace；2、Z-Image-Turbo对于两种模型对比如下：

Turbo是对Z-Image进行蒸馏加速版本。对于Z-Image其具体模型结构如下所示（在模型结构上差异不大，关键点在于数据构建过程见：扩散模型数据构建）

对于上述模型结构，文本编码器：Qwen3-4B；VAE使用Flux VAE；位置编码上使用3D Unified RoPE编码方式，除此之外对于图像编辑任务上使用SigLIP2去提取图像特征。除此之外再上述结构中Q/K-Norm指的是在计算attention之前提前去对Q/K进行归一化处理（一般的注意力计算是对Q/K/V在计算attention之后进行归一化亦或者提前对3者都进行归一化）除此之外其在训练阶段使用策略是：

在预训练（pre-training）阶段都是使用flow-matching方法进行训练，对于上述过程中首先在低质量预训练（Low-Resolution Pre-training）中使用256分辨率图像进行训练，在Omni Pre-training中则是直接进行更加复制训练任意分辨率、文生图、图生图等预训练。后续的强化学习中先使用DPO做offline alignment在使用GRPO做online alignment。除此之外使用Distribution Matching Distillation（DMD分布匹配蒸馏方式）去蒸馏模型得到Turbo模型

FireRed-Image-Edit模型

基座模型对比效果分析

具体使用测试服务器为3090-24G进行测试，得到不同模型在文生图效果对比分析结果

VAE基座模型

对于VAE模型在之前的博客有介绍过具体的原理，这里主要就是介绍几个常见的VAE架构模型（使用过程中其实很少会去修改VAE架构，一般都是直接用SD自己使用的）所以就简单对比一下不同的VAE模型在图片重构上的表，主要是使用此huggingface上的进行比较（比较的数值越小越好，就数值而言 CogView4-6B效果最佳），下面结果为随便挑选的一个图片进行测试结果：

不同模型参数对生成的影响

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Features#stable-diffusion-20

• 参数 guidance_rescale对于生成的影响

引导扩散模型（如 Classifier-Free Guidance，CFG）中，用于调整文本条件对生成图像的影响强度。它的核心作用是控制模型在生成过程中对文本提示的“服从程度”。公式上，CFG 调整预测噪声的方式如下：

其中：1、$\epsilon_{\text{cond}}$：基于文本条件预测的噪声。2、$\epsilon_{\text{uncond}}$：无条件（无文本提示）预测的噪声。3、guidance_scale：决定条件噪声相对于无条件噪声的权重。得到最后测试结果如下（参数分别为[1.0, 3.0, 5.0, 7.5, 10.0, 15.0, 20.0]，prompt = "A majestic lion standing on a mountain during golden hour, ultra-realistic, 8k"， negative_prompt = "blurry, distorted, low quality"），容易发现数值越大文本对于图像的影响也就越大。

其中代码具体操作如下，从代码也很容易发现上面计算公式中的 uncond代表的就是我的negative_prompt，也就是说CFG做的就是negative_prompt对生成的影响：

if self.do_classifier_free_guidance:
    prompt_embeds = torch.cat([negative_prompt_embeds, prompt_embeds], dim=0)
    add_text_embeds = torch.cat([negative_pooled_prompt_embeds, add_text_embeds], dim=0)
    add_neg_time_ids = add_neg_time_ids.repeat(batch_size * num_images_per_prompt, 1)
    add_time_ids = torch.cat([add_neg_time_ids, add_time_ids], dim=0)
prompt_embeds = prompt_embeds.to(device)

Adapters

https://huggingface.co/docs/diffusers/tutorials/using_peft_for_inference

此类方法是在完备的 DF 权重基础上，额外添加一个“插件”，保持原有权重不变。我只需修改这个插件，就可以让模型生成不同风格的图像。可以理解为在原始模型之外新增一个“生成条件”，通过修改这一条件即可灵活控制模型生成各种风格或满足不同需求的图像。

ControlNet

https://github.com/lllyasviel/ControlNet
建议直接阅读：https://github.com/lllyasviel/ControlNet/discussions/categories/announcements 来了解更加多细节

ControlNet¹⁰的处理思路就很简单，再左图中模型的处理过程就是直接通过：$y=f(x;\theta)$来生成图像，但是在ControlNet里面会 将我们最开始的网络结构复制 然后通过在其前后引入一个 zero-convolution 层来“指导”（ $Z$ ）模型的输出也就是说将上面的生成过程变为：$y=f(x;\theta)+Z(f(x+Z(c;\theta_{z_1});\theta);\theta_{Z_2})$。通过冻结最初的模型的权重保持不变，保留了Stable Diffusion模型原本的能力；与此同时，使用额外数据对“可训练”副本进行微调，学习我们想要添加的条件。因此在最后我们的SD模型中就是如下一个结构：

在论文里面作者给出一个实际的测试效果可以很容易理解里面条件c（条件 𝑐就是提供给模型的显式结构引导信息，用于在生成过程中精确控制图像的空间结构或布局，一般来说可以是草图、分割图等）到底是一个什么东西，比如说就是直接给出一个“线稿”然后模型来输出图像。

补充-1：为什么使用上面这种结构
在github上作者讨论了为什么要使用上面这种结构而非直接使用mlp等（作者给出了很多测试图像），最后总结就是：这种结构好
补充-2：使用0卷积层会不会导致模型无法优化问题？
不会，因为对于神经网络结构大多都是：$y=wx+b$计算梯度过程中即使 $w=0$但是里面的 $x≠0$模型的参数还是可以被优化的

ControlNet代码操作

Code: https://github.com/shangxiaaabb/ProjectCode/tree/main/code/Python/DFModelCode/training_controlnet

首先，简单了解一个ControlNet数据集格式，一般来说数据主要是三部分组成：1、image（可以理解为生成的图像）；2、condiction_image（可以理解为输入ControlNet里面的条件 $c$）；3、text。比如说以raulc0399/open_pose_controlnet为例

模型加载，一般来说扩散模型就只需要加载如下几个：DDPMScheduler、AutoencoderKL（vae模型）、UNet2DConditionModel（不一定加载条件Unet模型），除此之外在ControlNet中还需要加载一个 ControlNetModel。对于 ControlNetModel中代码大致结构为，代码中通过 self.controlnet_down_blocks来存储ControlNet的下采样模块（初始化为0的卷积层）。self.down_blocks用来存储ControlNet中复制的Unet的下采样层。在 forward中对于输入的样本（sample）首先通过 self.down_blocks逐层处理叠加到 down_block_res_samples中，而后就是直接将得到结果再去通过 self.controlnet_down_blocks每层进行处理，最后返回下采样的每层结果以及中间层处理结果：down_block_res_samples，mid_block_res_sample

class ControlNetModel(ModelMixin, ConfigMixin, FromOriginalModelMixin):
    @register_to_config
    def __init__(...):
        ...
        self.down_blocks = nn.ModuleList([])
        self.controlnet_down_blocks = nn.ModuleList([])
        # 封装下采样过程（对应上面模型右侧结构）
        controlnet_block = nn.Conv2d(output_channel, output_channel, kernel_size=1)
        controlnet_block = zero_module(controlnet_block)
        self.controlnet_down_blocks.append(controlnet_block)
        for i, down_block_type in enumerate(down_block_types):
            # down_block_types就是Unet里面下采样的每一个模块比如说：CrossAttnDownBlock2D
            ...
            down_block = get_down_block(down_block_type) # 通过 get_down_block 获取uet下采样的模块
            self.down_blocks.append(down_block)
            for _ in range(layers_per_block):
                controlnet_block = nn.Conv2d(output_channel, output_channel, kernel_size=1)
                controlnet_block = zero_module(controlnet_block)
                self.controlnet_down_blocks.append(controlnet_block)
    @classmethod
    def from_unet(cls, unet,...):
        ...
        # 通过cls实例化的类本身ControlNetModel
        controlnet = cls(...)
        if load_weights_from_unet:
            # 将各类权重加载到 controlnet 中
            controlnet.conv_in.load_state_dict(unet.conv_in.state_dict())
            controlnet.time_proj.load_state_dict(unet.time_proj.state_dict())
            ...

        return controlnet
    def forward(...):
        ...
        # 时间编码
        t_emb = self.time_proj(timesteps)
        emb = self.time_embedding(t_emb, timestep_cond)
        if self.class_embedding is not None:
            ...
            class_emb = self.class_embedding(class_labels).to(dtype=self.dtype)
            emb = emb + class_emb
        # 对条件进行编码
        if self.config.addition_embed_type is not None:
            if self.config.addition_embed_type == "text":
                aug_emb = self.add_embedding(encoder_hidden_states)
            elif self.config.addition_embed_type == "text_time":
                time_ids = added_cond_kwargs.get("time_ids")
                time_embeds = self.add_time_proj(time_ids.flatten())
                time_embeds = time_embeds.reshape((text_embeds.shape[0], -1))

                add_embeds = torch.concat([text_embeds, time_embeds], dim=-1)
                add_embeds = add_embeds.to(emb.dtype)
                aug_emb = self.add_embedding(add_embeds)
        emb = emb + aug_emb if aug_emb is not None else emb     

        sample = self.conv_in(sample)
        controlnet_cond = self.controlnet_cond_embedding(controlnet_cond)
        sample = sample + controlnet_cond

        # 下采样处理
        down_block_res_samples = (sample,)
        for downsample_block in self.down_blocks:
            if ...
                ...
            else:
                sample, res_samples = downsample_block(hidden_states=sample, temb=emb)
            down_block_res_samples += res_samples
        # 中间层处理
        ...
        # 将输出后的内容去和0卷积进行叠加
        controlnet_down_block_res_samples = ()
        for down_block_res_sample, controlnet_block in zip(down_block_res_samples, self.controlnet_down_blocks):
            down_block_res_sample = controlnet_block(down_block_res_sample)
            controlnet_down_block_res_samples = controlnet_down_block_res_samples + (down_block_res_sample,)
        ...
        if not return_dict:
            return (down_block_res_samples, mid_block_res_sample)
        ...

模型训练，训练过程和DF训练差异不大。将图像通过VAE处理、产生噪声、时间步、将噪声添加到（VAE处理之后的）图像中，而后通过 controlnet得到每层下采样的结果以及中间层结果：down_block_res_samples, mid_block_res_sample = controlnet(...)而后将这两部分结果再去通过unet处理

model_pred = unet(
    noisy_latents,
    timesteps,
    encoder_hidden_states=encoder_hidden_states,
    down_block_additional_residuals=[
        sample.to(dtype=weight_dtype) for sample in down_block_res_samples
    ],
    mid_block_additional_residual=mid_block_res_sample.to(dtype=weight_dtype),
    return_dict=False,
)[0]

后续就是计算loss等处理。模型验证，直接就是使用 StableDiffusionControlNetPipeline来处理了。最后随机测试的部分例子（controlnet微调效果不是很好）：

T2I-Adapter

https://github.com/TencentARC/T2I-Adapter

T2I¹¹的处理思路也比较简单（T2I-Adap 4 ter Details里面其实就写的很明白了），对于输入的条件图片（比如说边缘图像）:512x512，首先通过 pixel unshuffle进行下采样将图像分辨率改为：64x64而后通过一层卷积+两层残差连接，输出得到特征 $F_c$之后将其与对应的encoder结构进行相加：$F_{enc}+ F_c$，当然T2I也支持多个条件（直接通过加权组合就行）

DreamBooth

https://huggingface.co/docs/diffusers/v0.34.0/using-diffusers/dreambooth

DreamBooth 针对的使用场景是，期望生成同一个主体的多张不同图像， 就像照相馆一样，可以为同一个人或者物体照多张不同背景、不同姿态、不同服装的照片（和ControlNet不同去添加模型结构，仅仅是在文本 Prompt）。在论文¹²里面主要出发点就是：1、解决language drif（语言偏离问题）：指的是模型通过后训练（微调等处理之后）模型丧失了对某些语义特征的感知，就比如说扩散模型里面，模型通过不断微调可能就不知道“狗”是什么从而导致模型生成错误。2、高效的生成需要的对象，不会产生：生成错误、细节丢失问题，比如说下面图像中的问题：

为了实现图像的“高效迁移”，作者直接将图像（比如说我们需要风格化的图片）作为一个特殊的标记，也就是论文里面提到的 a [identifier] [class noun]（其中class noun为类别比如所狗，identifier就是一个特殊的标记），在prompt中加入类别，通过利用预训练模型中关于该类别物品的先验知识，并将先验知识与特殊标记符相关信息进行融合，这样就可以在不同场景下生成不同姿势的目标物体。就比如下面的 fine-tuning过程通过几张图片让模型学习到 特殊的狗，然后再推理阶段模型可以利用这个 特殊的狗去生成新的动作。换言之就是（以下面实际DreamBooth代码为例）：首先通过几张 狮子狗 图片让模型知道 狮子狗张什么样子，然后再去生成 狮子狗的不同的动作。

在论文里面作者设计如下的Class-specific Prior Preservation Loss（参考stackexchange）¹³：

上面损失函数中后面一部分就是我们的先验损失，比如说$c_{pr}$就是对 “a dog”进行编码然后计算生成损失。在代码中：

if args.with_prior_preservation:
    model_pred, model_pred_prior = torch.chunk(model_pred, 2, dim=0)
    target, target_prior = torch.chunk(target, 2, dim=0)
    # Compute instance loss
    loss = F.mse_loss(model_pred.float(), target.float(), reduction="mean")
    # Compute prior loss
    prior_loss = F.mse_loss(model_pred_prior.float(), target_prior.float(), reduction="mean")
    # Add the prior loss to the instance loss.
    loss = loss + args.prior_loss_weight * prior_loss
else:
    loss = F.mse_loss(model_pred.float(), target.float(), reduction="mean")

DreamBooth代码操作

代码：https://github.com/shangxiaaabb/ProjectCode/tree/main/code/Python/DFModelCode/training_dreambooth_lora/
权重：https://www.modelscope.cn/models/bigyellowjie/SDXL-DreamBooth-LOL/files

在介绍DreamBooth代码之前，简单回顾DreamBooth原理，我希望我的模型去学习一种画风那么我就需要准备样本图片（如3-5张图片）这几张图片就是专门的模型需要学习的，但是为了防止模型过拟合（模型只学习了我的图片内容，但是对一些细节丢掉了，比如说我提供的5张油画，模型就学会了我的油画画风但是为了防止模型对更加多的油画细节忘记了，那么我就准备 num_epochs * num_samples 张油画类型图片然后通过计算 Class-specific Prior Preservation Loss）需要准备 类型图片来计算Class-specific Prior Preservation Loss。代码处理（SDXL+Lora）：
DreamBooth中数据处理过程：结合上面描述我需要准备两部分数据集（如果需要计算 Class-specific Prior Preservation Loss）分别为：instance_data_dir（与之对应的 instance_prompt）以及 class_data_dir（与之对应的 class_prompt）而后需要做的就是将两部分数据组合起来构成：

batch = {
    "pixel_values": pixel_values,
    "prompts": prompts,
    "original_sizes": original_sizes,
    "crop_top_lefts": crop_top_lefts,
}

模型训练过程首先是lora处理模型：在基于transformer里面的模型很容易使用lora，比如说下面代码使用lora包裹模型并且对模型权重进行保存：

from peft import LoraConfig
def get_lora_config(rank, dropout, use_dora, target_modules):
    '''lora config'''
    base_config = {
        "r": rank,
        "lora_alpha": rank,
        "lora_dropout": dropout,
        "init_lora_weights": "gaussian",
        "target_modules": target_modules,
    }
    return LoraConfig(**base_config)
# 包裹lora模型权重
unet_target_modules = ["to_k", "to_q", "to_v", "to_out.0"]
unet_lora_config = get_lora_config(
    rank= config.rank,
    dropout= config.lora_dropout,
    use_dora= config.use_dora,
    target_modules= unet_target_modules,
)
unet.add_adapter(unet_lora_config)

一般的话考虑SD模型权重都比较大，而且我们使用lora微调模型没必要对所有的模型权重进行存储，那么一般都会定义一个 hook来告诉模型那些参数需要保存、加载，这样一来使用 accelerator.save_state(save_path) 就会先去使用 hook处理参数然后进行保存。：

def save_model_hook(models, weights, output_dir):
    if accelerator.is_main_process:
        unet_lora_layers_to_save = None
      
        for model in models:
            if isinstance(model, type(unwrap_model(unet))):
                unet_lora_layers_to_save = convert_state_dict_to_diffusers(get_peft_model_state_dict(model))
            ...
            weights.pop() # 去掉不需要保存的参数

        StableDiffusionXLPipeline.save_lora_weights(
            output_dir,
            unet_lora_layers= unet_lora_layers_to_save,
            ...
        )
def load_model_hook(models, input_dir):
    unet_ = None

    while len(models) > 0:
        model = models.pop()

        if isinstance(model, type(unwrap_model(unet))):
            unet_ = model

    lora_state_dict, network_alphas = StableDiffusionLoraLoaderMixin.lora_state_dict(input_dir)

    unet_state_dict = {f"{k.replace('unet.', '')}": v for k, v in lora_state_dict.items() if k.startswith("unet.")}
    unet_state_dict = convert_unet_state_dict_to_peft(unet_state_dict)
    incompatible_keys = set_peft_model_state_dict(unet_, unet_state_dict, adapter_name="default")
    ...
accelerator.register_save_state_pre_hook(save_model_hook)
accelerator.register_load_state_pre_hook(load_model_hook)

其次模型训练：就是常规的模型训练（直接在样本图片：instance_data_dir以及样本的prompt：instance_prompt上进行微调）然后计算loss即可，如果涉及到 Class-specific Prior Preservation Loss（除了上面两个组合还需要：class_data_dir以及 class_prompt）那么处理过程为（以SDXL为例），不过需要事先了解的是在计算这个loss之前会将两个数据集以及prompt都组合到一起成为一个数据集（instance-image-prompt 以及 class-image-prompt之间是匹配的）：

# 样本内容编码
instance_prompt_hidden_states, instance_pooled_prompt_embeds = compute_text_embeddings(config.instance_prompt, text_encoders, tokenizers)
# 类型图片内容编码
if config.with_prior_preservation:
    class_prompt_hidden_states, class_pooled_prompt_embeds = compute_text_embeddings(config.class_prompt, text_encoders, tokenizers)
...
prompt_embeds = instance_prompt_hidden_states
unet_add_text_embeds = instance_pooled_prompt_embeds
if not config.with_prior_preservation:
    prompt_embeds = torch.cat([prompt_embeds, class_prompt_hidden_states], dim=0)
    unet_add_text_embeds = torch.cat([unet_add_text_embeds, class_pooled_prompt_embeds], dim=0)
...
model_pred = unet(...)
if config.with_prior_preservation:
    model_pred, model_pred_prior = torch.chunk(model_pred, 2, dim=0)
    target, target_prior = torch.chunk(target, 2, dim=0)
    ...
    prior_loss = F.mse_loss(model_pred_prior.float(), target_prior.float(), reduction="mean")
...
loss = F.mse_loss(model_pred.float(), target.float(), reduction="mean")
...
loss = loss + config.prior_loss_weight * prior_loss
accelerator.backward(loss)

在这个里面之所以用 chunk是因为如果计算 Class-specific Prior Preservation Loss里面的文本prompt是由两部分拼接构成的 torch.cat([prompt_embeds, class_prompt_hidden_states], dim=0)那么可以直接通过chunk来分离出两部分（这个过程和使用参数 guidance_rescale很相似）
最后测试的结果为（prompt: "A photo of Rengar the Pridestalker in a bucket"，模型代码以及权重下载）：

总结

对于不同的扩散（基座）模型（SD1.5、SDXL、Imagen）等大部分都是采用Unet结构，当然也有采用Dit的，这两个模型（SD1.5、SDXL）之间的差异主要在于后者会多一个clip编码器再文本语义上比前者更加有优势。对于adapter而言，可以直接理解为再SD的基础上去使用“风格插件”，这个插件不去对SD模型进行训练（从而实现对参数的减小），对于ControNet就是直接对Unet的下采样所有的模块（前后）都加一个zero-conv而后将结果再去嵌入到下采用中，而T2I-Adapter则是去对条件进行编码而后嵌入到SD模型（上采用模块）中。对于deramboth就是直接通过给定的样本图片去生“微调”模型，而后通过设计的Class-specific Prior Preservation Loss来确保所生成的样本特里不会发生过拟合。

参考

目标检测算法

基于卷积的目标检测算法如：R-CNN、FastRCNN、Yolo（部分版本）等，基于Attention如Vit等

R-CNN目标检测

算法原理¹如上面所述，主要过程为：1、区域候选框生成器（Region Proposal Extractor）；2、CNN特征提取器；3、SVM分类器根据特征进行分类；4、回归模型用于收紧边界框。其中主要需要着重介绍的 区域候选款生成器用像 Selective Search 这样的传统方法从输入图像产生大约 1–2k 个候选框（每个候选框可能包含一个物体或背景）。Selective Search 利用图像分割和层次合并产生高召回率的候选区域。

整体过程如上面描述一下，通过预训练的神经网络（AlexNet）等去获取CNN特征，然后再去通过选择性搜索算法（Selective Search）获取所有的可能的“目标”

对于选择性搜索算法的一个大致思路：大概的意思就是首先根据图像分割的算法来初始化划分区域，然后根据不同颜色模式、目标颜色、纹理、大小、形状等特征来计算相似度合并子区域。

在经过分类以及SVM分类之后直接再去收缩边界框，这个过程主要是通过非极大值抑制去剔除重叠的建议框。

非极大值抑制：对于每一个框都会有一个置信度，首选按照置信度进行排列得到最大的置信度框，然后去计算其他框和这个最大框的IoU，如果某个框与选取框的IoU大于我们设定的阈值（比如0.5），说明它们和选取框检测的是同一个目标，所以需要被抑制（删除）。如果某个框与选取框的IoU小于阈值，说明它们和框A检测的可能是另一个目标（或者只是重叠不多），予以保留。
$\text{IoU}=\frac{\text{Area}(A\cap B)}{\text{Area}(A\cup B)}$ 具体的代码实现如下

def bbox_iou(box1, box2):
    inter_x1 = max(box1[0], box2[0])
    inter_y1 = max(box1[1], box2[1])
    inter_x2 = min(box1[2], box2[2])
    inter_y2 = min(box1[3], box2[3])

    # 交集的宽高（注意要 clamp 为 >=0）
    inter_w = max(0, inter_x2 - inter_x1)
    inter_h = max(0, inter_y2 - inter_y1)
    inter_area = inter_w * inter_h

    # 各自面积
    area1 = (box1[2] - box1[0]) * (box1[3] - box1[1])
    area2 = (box2[2] - box2[0]) * (box2[3] - box2[1])

    # 并集面积
    union_area = area1 + area2 - inter_area

    # IoU
    iou = inter_area / union_area if union_area > 0 else 0.0
    return iou

Fast RCNN以及Faster RCNN目标检测

Fast RCNN²主要是依次解决上面模型存在的问题，其主要的原理如下：

在Fast RCNN中主要过程：输入是一张图片和多个proposal，经过卷积层计算之后，通过ROI pooling的方式归一到一个fixed size的feature map，最后通过FCs计算分类损失（softmax probabilities）和框回归损失（b-box regression offsets）。这种方法的好处是一张图片只需要经过一次CNN的推理，不再像RCNN那样根据Proposals把原图切成多个子图输入到CNN中再去由SVM处理，大大提升了效率。
而在Faster CNN³主要是为了解决前者依赖于外部候选区域方法，而在该论文中主要提出改进措施是通过使用设计一个RPN去替换外部候选区域，整体流程如下：

对于上面两个模型主要是需要关注两点：
1、RPN网络结构设计：在原图尺度上，设置了密密麻麻的候选Anchor。然后用cnn去判断哪些Anchor是里面有目标的positive anchor，哪些是没目标的negative anchor。算法思路为：在得到特征图之后再特征图上每个像素点都预设9个anchor（基本就覆盖需要识别的目标），但是对于这些anchor肯定有很多多余的，因此再RPN中就有两个分支：1、分类分支（上面流程图中上面部分）：直接通过(1, 1, 2k)（k=9）卷积去计算得到Objectness Score（标记框是目标还是背景）；2、回归分支（上面流程图中下面部分）：微调锚点框的位置和大小，使其更贴合真实目标。它不是直接预测坐标，而是预测偏移量（offsets）
2、RoI Pooling以及RoI Align⁴：两个RoI算法主要是将bbox映射到特征图上获取bbox中特征，后者是为了解决前者纯在的数据舍入问题。

YoLo算法

在Yolov1中其网络结构如下所示：

主要解决的是上面提到哪些检测算法需要用卷积核去“扫描”图像问题，在Yolo中直接将图像提前切割为 $S\times S$个格子而后就是按照上面的网络结构进行处理最后输出的张量为 $7\times 7\times 30$，可以理解为每一块都有30个特征值对于这30个特征值分别表示的含义是：$B\times 5+ C$ 其中B代表候选框数量（论文中选择2，具体的bbox坐标是直接通过模型训练得到），C代表类别，之所以用5表示的是 $(x,y,w,h,conf)$ 前面4个不解释后面一个指标代表的的是该框的 置信度水平，这样一来可以直接通过计算每个框属于哪个类别也就是计算执行都和类别C的乘积结果： $C\times \text{conf}$得到结果为 $20\times 1$这样一来每一个框都会这样计算那么最后得到 $7\times 7\times 2=98$，借鉴⁵中的PPT，那么我最后得到结果如下所述：

假设我的第一行是判断“狗”这个类别，那么第一行行都会有关于狗这个类别一个置信度，那么后续就可以直接去计算NMS来得到最后的bbox了。对于Yolo使用可以直接使用ultralytics来使用Yolo权重（Yolo11-SAM代码）

参考

Erase Diffusion

Erase Diffusion: Empowering Object Removal Through Calibrating Diffusion Pathways
https://github.com/longtaojiang/SmartEraser
CVPR-2025

1、模型结构

论文出发点主要为：1、动态图像组合：区别常规的图像去除实验target image就是我们的去除内容之后的图片，在该文中将其替换为：$x_t^{mix} = (1-\lambda_t)x_0^{ori}+ \lambda_t x_0^{obj}$ 也就是随着解噪过程（t逐渐减小）图片中所添加的实体（$x^{obj}_0$）所占的权重越来越小，同时将 input image也替换为动态的过程：$x_t^{min}=\sqrt{\alpha_t}x_t^{min}+ \sqrt{1- \alpha_t}\epsilon$；2、改变模型的预测过程：上面两部分公式处理之后那么得到的输入图像是一个“图像链”输出图像也是一个“图像链”，那么模型需要做的就是将对应“图像链”之间的loss进行计算。

3、改进注意力计算方式：这部分比较容易理解在计算注意力过程中将mask加入到计算也就是：$QK^T\bigodot Mask$

SmartEraser

SmartEraser: Remove Anything from Images using Masked-Region Guidance
CVPR-2025

1、数据集构建

合成数据集构建思路上使用思路是：实体过滤背景检测而后将两部分进行组合。Step-1：实体过滤：直接通过语义分割模型（如SAM等）分割出实体之后，通过CLIP计算实体的score并且过滤掉过大/小的分割实体（保留5%-95%）进而获得需要粘贴的实体；Step-2：过滤背景图片：直接通过计算分辨率等从COCONut 和SAM-1B数据集中挑选出合适图片背景；Step-3：图片组合：首先将实体和背景图像中相同实体大小保持一致，而后通过计算我分割实体$c_1$ 以及背景中的实体 $c_i$之间的IoU：$R_1$，以及保证需要粘贴实体在整个背景中的位置（保证不超出背景图片）：$R_2$而后取两部分交集得到图像应该插入的合理位置。最后通过 alpha blending将两部分图像（实体+背景）进行组合。

2、模型结构测试效果

论文主要就是将模型的输入进行改进：将模型图像输入由$[mask, image\bigodot (1-mask)]$ 改为 $[mask, image]$，除此之外将DF模型的condition改进（将图像编码嵌入到文本编码中）：$[\text{CLIP-TextEncoder(text)}, \text{MLP}(\text{Image}\bigodot \text{Mask})]$。除此之外就是将mask由“规则”（实体分割是规则的）变为“不规则”（将实体分割mask进行额外处理如膨胀处理等）最后测试效果是：

ME：将mask变不规则；RG：改变模型输入；VG：将图像编码嵌入到clip文本编码中

微调测试效果

值得注意的是，在其合成的数据里面，合成得到结果很粗糙（感觉就像是随机贴图），因此感觉数据可用性不高

OmniEraser

https://pris-cv.github.io/Omnieraser/

1、数据集构建

通过视频来获取（mask-image）数据集，具体操作流程如下：

首先获取一段视频 $\mathbf{V}$ 通过 混合高斯算法（MOG）去检查视频中移动的物体以及静止的物体这样一来就可以得到两部分内容：Background和Foreground而后通过计算两部分之间的MSE（$MSE(V_i^{fg}, V_j^{bg})$）就可以得到source-image和 target-image对。对于mask内容直接通过 GroundDINO+SAM2 算法来构建mask这样一来就可以得到：foreground-image，mask，background-image。模型算法这是直接去微调 FLUX.1-dev

2、模型结构测试效果

实际测试效果（使用prompt为：'There is nothing here.'）

原图	Mask	结果	测试细节

accelerate

推荐直接阅读官方文档：https://huggingface.co/docs/accelerate/index
pip install accelerate

介绍之前了解一下这个库是干什么的：这个库主要提供一个快速的分布式训练（避免了直接用torch进行手搓）并且支持各类加速方法：混合精度训练、Deepspeed、梯度累计等

一个基本使用场景

一般任务中一个常见的应用场景是：需要实现一个多显卡（这里假设为双显卡）分布式训练，并且使用梯度累计、混合精度训练，并且训练得到的结果通过tensorboard/wandb进行记录，除此之外还需要使用warm-up学习率调整策略，并且我的模型不同模块使用的学习率不同，训练完成之后所有的模型权重要进行保存/读取权重进行测试。那么可以直接通过下面代码进行实现（部分库的导入以及一些参数比如说config直接忽略）

from accelerate import Accelerator
kwargs_handlers=[DistributedDataParallelKwargs(find_unused_parameters=True)] # 不是必须的
# Step-1 首先初始化 accelerate
accelerator = Accelerator(mixed_precision= 'fp16', 
                            gradient_accumulation_steps= 2,
                            log_with= ['tensorboard', 'wandb'], # 一般来说用一个即可
                            project_dir=os.path.join(config.output_dir, "logs"),
                            kwargs_handlers= kwargs_handlers
                            )
# 仅在主线程上创建文件夹
if accelerator.is_main_process: 
    os.makedirs(config.output_dir, exist_ok=True)
    # 初始化一个实验记录器（此处内容需要注意⭐）
    # accelerator.init_trackers(f"Train-{config.training}")
    log_name = 'Model-Test'
    accelerator.init_trackers(
        project_name= f"Page-Layout-Analysis-{config.pred_heads}",
        init_kwargs={
            "wandb": {
                "name": log_name,
                "dir": os.path.join(config.output_dir, "logs"),
                "config": vars(config)
            }
        }
        )
 
# Step-2 初始化完成之后可以直接将我们需要的内容通过 accelerator.prepare 进行处理
optimizer = torch.optim.AdamW([
        {'params': model.image_model.parameters(), 'lr': 2e-5, 'weight_decay': 1e-4},
        {'params': model.text_model.parameters(), 'lr': 4e-5},
        {'params': [p for n, p in model.named_parameters() 
                    if 'image_model' not in n and 'text_model' not in n], 
        'lr': config.learning_rate, 'weight_decay': 1e-4}, 
    ])
total_steps = config.epochs * len(train_dataloader)
warmup_steps = int(0.15 * total_steps)

# Warmup 调度器：从 0.1*lr 线性增加到 lr
warmup_scheduler = torch.optim.lr_scheduler.LinearLR(optimizer, 
                                                        start_factor=0.1, 
                                                        total_iters=warmup_steps
)

# 余弦退火调度器：添加 eta_min 防止学习率过低
cosine_scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, 
                                                                T_max=total_steps - warmup_steps, 
                                                                eta_min=1e-6
)

cosine_scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, 
                                                                T_max=total_steps - warmup_steps)
lr_scheduler = torch.optim.lr_scheduler.SequentialLR(
    optimizer,
    schedulers=[warmup_scheduler, cosine_scheduler],
    milestones=[warmup_steps] 
)
dataloader, model, optimizer, scheduler = accelerator.prepare(dataloader, model, optimizer, scheduler)

# Step-3 模型训练以及模型优化
total_data = len(dataloader)
for i, batch in enumerate(dataloader):
    with accelerator.accumulate(model): # 梯度累计
        inputs, targets = batch

        # 下面两句可以不用，但是习惯还是直接使用
        inputs = inputs.to(accelerator.device)
        targets = targets.to(accelerator.device)

        outputs = model(inputs)
        loss = loss_function(outputs, targets)
        accelerator.backward(loss)
        if accelerator.sync_gradients: # 进行梯度裁剪
            accelerator.clip_grad_norm_(model.parameters(), 1.0)
        optimizer.step()
        scheduler.step()
        optimizer.zero_grad()

        # 记录一下实验结果
        logs = {
                "Train/loss": loss.item(),
                "Train/lr": optimizer.param_groups[0]['lr'], # 这里是假设模型使用的优化学习率不同 或者直接使用 scheduler.get_last_lr()[0]
                "Train/ACC": acc,
            }
            progress_bar.set_postfix(
                loss=loss.item(),
                acc=acc, f1=f1)
            accelerator.log(logs, step= epoch* total_data+ i)

# Step-3 同步不同进程
accelerator.wait_for_everyone()
if accelerator.is_main_process:
    model = accelerator.unwrap_model(model)
    model.save_pretrained(os.path.join(args.output_dir, "model"))
accelerator.end_training()

不过对于上面的代码需要注意如下几个内容
1、追踪器使用：一般多显卡使用过程中通过使用 accelerator.end_training() 去结束 tracker
2、tqdm使用：一般只需要主进程进行显示进度条，因此一般直接：tqdm(..., disable=not accelerator.is_local_main_process)

diffuser

推荐直接阅读官方文档：https://huggingface.co/docs/diffusers/main/en/index
pip install git+https://github.com/huggingface/diffusers

基本使用

对于Diffusion Model原理理解可以参考，以及直接通过下面训练一个Diffusion Model代码（代码不一定很规范）进行解释。

from diffusers import DDPMScheduler

noise_scheduler = DDPMScheduler(num_train_timesteps= config.num_train_timesteps,
                            beta_start= config.beta_start, # 两个beta代表加噪权重
                            beta_end= config.beta_end,
                            beta_schedule= 'scaled_linear')
...
# training
for epoch in range(config.epochs):
    for i, batch in enumerate(train_dataloader):
        image = batch["images"]
        ...
        timesteps = torch.randint(0, noise_scheduler.config.num_train_timesteps, 
                                    (image.shape[0],), 
                                    device=image.device, 
                                    dtype=torch.int64)
            
        noise = torch.randn(image.shape, device= accelerator.device)
        noise_image = noise_scheduler.add_noise(image, noise, timesteps)
        ...
        noise_pred = model(noise_image, timesteps)
        loss = F.mse_loss(noise_pred, noise)
        ...
# eva
def evaluate(..., noise_scheduler, ):
    ...
    noise = torch.randn((config.eval_batch_size, config.channel, config.image_size, config.image_size)) # 可以选择固定随机数种子
    for t in noise_scheduler.timesteps:
        t_tensor = torch.full((noise.shape[0],), 
                                t, 
                                dtype=torch.long, 
                                device= device)
        predicted_noise = model(noise, t_tensor, text_label)
        noise = noise_scheduler.step(predicted_noise, t, noise).prev_sample
    images = (noise.clamp(-1, 1) + 1) / 2
    ...

训练过程
1、加噪处理：通过选择使用DDPM/DDIM而后将生成的”确定的噪声”添加到图片上 noise_scheduler.add_noise(image, noise, timesteps)

2、模型预测：通过模型去预测所添加的噪声并且计算loss
生成过程
3、逐步解噪：训练好的模型逐步预测噪声之后将其从噪声图片中将噪声剥离出来

1、Scheduler

https://huggingface.co/docs/diffusers/api/schedulers/overview
更加详细的描述：https://www.big-yellow-j.top/posts/2025/07/06/DFscheduler.html

以DDPMScheduler为例主要使用两个功能：
1、add_noise（输入：sample、noise、timesteps）：这个比较简单就是直接：$x=\sqrt{\alpha}x+ \sqrt{1-\alpha}\epsilon$
2、step（输入：model_output、timestep、sample）：step做的就是将上面的add_noise进行逆操作。具体代码处理

• Step-1 首先计算几个参数：$\alpha、\beta$

alpha_prod_t = self.alphas_cumprod[t]
alpha_prod_t_prev = self.alphas_cumprod[prev_t] if prev_t >= 0 else self.one
beta_prod_t = 1 - alpha_prod_t
beta_prod_t_prev = 1 - alpha_prod_t_prev
current_alpha_t = alpha_prod_t / alpha_prod_t_prev
current_beta_t = 1 - current_alpha_t

• Step-2 根据计算得到参数反推$t-1$的计算结果（提供3种类，介绍“epsilon”）$x_0=\frac{x_T- \sqrt{1- \alpha_t}\epsilon}{\alpha_t}$

pred_original_sample = (sample - beta_prod_t ** (0.5) * model_output) / alpha_prod_t ** (0.5)

• Step-3：从数学公式上在上一步就可以计算得到，但是在论文中为了更加近似预测结果还会计算：

pred_original_sample_coeff = (alpha_prod_t_prev ** (0.5) * current_beta_t) / beta_prod_t
current_sample_coeff = current_alpha_t ** (0.5) * beta_prod_t_prev / beta_prod_t
pred_prev_sample = pred_original_sample_coeff * pred_original_sample + current_sample_coeff * sample

区别DDIM的处理过程将DDPM的马尔科夫链替换为非马尔科夫链过程而后进行采样，这样我们就可以每次迭代中跨多个step，从而减少推理迭代次数和时间：

std_dev_t = eta * variance ** (0.5)
pred_sample_direction = (1 - alpha_prod_t_prev - std_dev_t**2) ** (0.5) * pred_epsilon
prev_sample = alpha_prod_t_prev ** (0.5) * pred_original_sample + pred_sample_direction
 
prev_sample = prev_sample + variance

2、pipeline

所有支持的pipeline：Diffusers Pipelines

一般来说很多论文里面提出的模型，基本都是基于SD（StableDiffusion）等模型进行“微调”的，因此很多改进也都是去争对输入模型的参数进行调整（换言之就是搭积木讲故事），比如说改变输入图片内容、改变SD中条件等。除此之外分析一个pipeline直接通过分析里面的__call__即可，基本使用：

from diffusers import StableDiffusionPipeline
import torch

model_id = "runwayml/stable-diffusion-v1-5"
pipe = StableDiffusionPipeline.from_pretrained(model_id, torch_dtype=torch.float16)

if torch.cuda.is_available():
    pipe = pipe.to("cuda")

prompt = "A futuristic city at sunset, cyberpunk style, highly detailed, cinematic lighting"
image = pipe(prompt, num_inference_steps=50, guidance_scale=7.5).images[0]
image.save("output.png")

2.1 StableDiffusionPipeline

https://huggingface.co/docs/diffusers/v0.34.0/en/api/pipelines/overview#diffusers.DiffusionPipeline

很多论文里面基本都是直接去微调训练好的模型比如说StableDiffusion等，使用别人训练后的就少不了看到 pipeline的影子，直接介绍StableDiffusionPipeline的构建（文生图pipeline）。在代码中主要使用到的基础模型如下几个：1、VAE（AutoencoderKL）；2、CLIP（用于文本编码，CLIPTextModel、CLIPTokenizer）；3、Unet（模型骨架，UNet2DConditionModel）
Step-1：对输入文本进行编码（文生图直接输入文本）通过正、负编码对生成图像进行指导：

def encode_prompt(..., prompt, do_classifier_free_guidance,...,):
    # 1、判断文本编码器是否lora微调
    if lora_scale is not None and isinstance(self, StableDiffusionLoraLoaderMixin):
        self._lora_scale = lora_scale
        if not USE_PEFT_BACKEND:
            adjust_lora_scale_text_encoder(self.text_encoder, lora_scale)
        else:
            scale_lora_layers(self.text_encoder, lora_scale)
    # 2、通过prompt来确定需要生成多少图片
    ...
    # 3、对文本进行编码
    if prompt_embeds is None:
        ...
        text_inputs = self.tokenizer(...)
        text_input_ids = text_inputs.input_ids
            untruncated_ids = self.tokenizer(prompt, padding="longest", return_tensors="pt").input_ids
        ...
        # 会显示一个过长截断警告
        ...
        # 选择clip中倒数第几层作为文本编码输出
        if clip_skip is None:
            # 默认直接最后一层
            prompt_embeds = self.text_encoder(text_input_ids.to(device), attention_mask=attention_mask)
                prompt_embeds = prompt_embeds[0]
        else:
            # 倒数层
            prompt_embeds = self.text_encoder(
                text_input_ids.to(device), attention_mask=attention_mask, output_hidden_states=True
            )
            prompt_embeds = prompt_embeds[-1][-(clip_skip + 1)]
            prompt_embeds = self.text_encoder.text_model.final_layer_norm(prompt_embeds)
        # 改变形状得到 batch_size（对应prompt数量）, 77, 748 CLIP: CLIP-ViT-L
        ...
        prompt_embeds = prompt_embeds.view(bs_embed * num_images_per_prompt, seq_len, -1) 
    if do_classifier_free_guidance and negative_prompt_embeds is None:
        # 此部分和上面正常的编码处理方式相似直接对negative_prompt进行编码
        ...
    ...
    return prompt_embeds, negative_prompt_embeds

Step-2：获取推理时间步以及生成latent变量
Step-3：模型处理

# 首先通过unet逐步进行解码图像
with self.progress_bar(total=num_inference_steps) as progress_bar:
    for i, t in enumerate(timesteps):
        ...
        noise_pred = self.unet(...)[0]
        ...
        # 通过step来从t反推t-1
        latents = self.scheduler.step(noise_pred, t, latents, **extra_step_kwargs, return_dict=False)[0]
        ...
        # classifier_free_guidance
if not output_type == "latent":
    # 图片返回
    image = self.vae.decode(latents / self.vae.config.scaling_factor, return_dict=False,generator=generator)[0]
    image, has_nsfw_concept = self.run_safety_checker(image, device, prompt_embeds.dtype)
else:
    # 直接返回没被vae处理的结果
    image = latents
    has_nsfw_concept = None

if has_nsfw_concept is None:
    do_denormalize = [True] * image.shape[0]
else:
    do_denormalize = [not has_nsfw for has_nsfw in has_nsfw_concept]
image = self.image_processor.postprocess(image, output_type=output_type, do_denormalize=do_denormalize)
...
if not return_dict:
    return (image, has_nsfw_concept)

return StableDiffusionPipelineOutput(images=image, nsfw_content_detected=has_nsfw_concept)

补充-1：classifier_free_guidance（CFG） 以及 classifier_guidance（CG）
classifier_guidance¹：通过一个分类器来引导模型生成的方向，也就是使得模型按类进行生成。数学上描述为²：$\nabla p(x_t\vert y)=\nabla \log p(x_t)+ \nabla \log p(y \vert x_t)$ 也就是说前面部分代表unconditional score后面部分代表分类器的梯度，也就是添加一个分类器梯度来“指导”模型生成方向。
classifier_free_guidance³：对上面的改进版本，上面过程中会额外训练一个分类器进而增加训练成本。因此对于上面计算公式中：$\nabla \log p(y \vert x_t)= \nabla p(x_t\vert y)- \nabla \log p(x_t)= -\frac{1}{\sqrt{1- \alpha_t}}(\epsilon_\theta(x_t, t, y)- \epsilon_\theta(x_t, t))$ 最后得到梯度过程为： $(w+1)\epsilon_\theta(x_t, t, y)- w\epsilon_\theta(x_t, t)$

回到代码中，代码中具体操作过程为：1、文本编码过程中，这部分比较简单直接根据对negative_prompt进行CLIP text encoder处理即可（如果没有输入negative_prompt默认就是直接用空字符进行替代）如果进行CFG那么直接将两部分进行拼接（torch.cat([negative_prompt_embeds, prompt_embeds])） prompt_embeds；2、模型解码过程中，这部分处理过程比较粗暴，如果要进行CFG那么直接将latent扩展为两份（Uncond+Cond各一份）对应的text输出也是两份，通过一个模型处理之后再通过chunk分出无条件输出、有条件输出，最后计算两部分组合：$\epsilon(x,t)+ w(\epsilon(x,t,y)- \epsilon(x,t))$

if self.do_classifier_free_guidance:
    prompt_embeds = torch.cat([negative_prompt_embeds, prompt_embeds])
...
latent_model_input = torch.cat([latents] * 2) if self.do_classifier_free_guidance else latents
...
noise_pred = self.unet(latent_model_input, t, prompt_embeds, ...)[0]

if self.do_classifier_free_guidance:
    noise_pred_uncond, noise_pred_text = noise_pred.chunk(2)
    noise_pred = noise_pred_uncond + self.guidance_scale * (noise_pred_text - noise_pred_uncond)

if self.do_classifier_free_guidance and self.guidance_rescale > 0.0:
    noise_pred = rescale_noise_cfg(noise_pred, noise_pred_text, guidance_rescale=self.guidance_rescale)

2.2 StableDiffusionXLInpaintPipeline

https://github.com/huggingface/diffusers/blob/main/src/diffusers/pipelines/stable_diffusion_xl/pipeline_stable_diffusion_xl_inpaint.py

对于图像消除任务而言使用较多的也是此类pipeline（SDXL开源可以商用）具体使用代码如下：

from diffusers import StableDiffusionXLInpaintPipeline
from diffusers.utils import load_image, make_image_grid
import torch
from PIL import Image

device = "cuda" if torch.cuda.is_available() else "cpu"

# 加载基础模型
base = StableDiffusionXLInpaintPipeline.from_pretrained(
    "stabilityai/stable-diffusion-xl-base-1.0",
    torch_dtype=torch.float16,  # 使用半精度浮点数以减少显存占用
    variant="fp16",             # 使用 fp16 变体以优化性能
    use_safetensors=True        # 使用 safetensors 格式以提高加载速度
).to(device)

# 加载优化模型（refiner model）
refiner = StableDiffusionXLInpaintPipeline.from_pretrained(
    "stabilityai/stable-diffusion-xl-refiner-1.0",
    text_encoder_2=base.text_encoder_2,  # 共享基础模型的第二个文本编码器
    vae=base.vae,                        # 共享基础模型的变分自编码器
    torch_dtype=torch.float16,
    use_safetensors=True,
    variant="fp16",
).to(device)

img_url = "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo.png"
mask_url = "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo_mask.png"
init_image = load_image(img_url)
mask_image = load_image(mask_url)


prompt = "A majestic tiger sitting on a bench" 
negative_prompt = "distorted, blurry, low quality" 

num_inference_steps = 75 
high_noise_frac = 0.7

# 使用基础模型进行初步去噪（输出潜在表示）
base_output = base(
    prompt=prompt,
    negative_prompt=negative_prompt,
    image=init_image,
    mask_image=mask_image,
    num_inference_steps=num_inference_steps,
    denoising_end=high_noise_frac,  # 基础模型处理高噪声阶段
    output_type="latent"           # 输出潜在表示以供优化模型使用
).images

# 使用优化模型进行细节增强
refined_image = refiner(
    prompt=prompt,
    negative_prompt=negative_prompt,
    image=base_output,
    mask_image=mask_image,
    num_inference_steps=num_inference_steps,
    denoising_start=high_noise_frac,  # 优化模型处理低噪声阶段
).images[0]

# 可视化结果
grid = make_image_grid([init_image, mask_image, refined_image.resize((512, 512))], rows=1, cols=3)
grid.save("inpainting_result.png")
refined_image.save("refined_image.png")

首先模型输入主要为如下几个部分：1、文本输入；2、图片输入（正常图片以及mask图片）。首先对于文本编码。对于SDXL模型而言文本会通过两个clip的文本编码器进行编码（OpenCLIP-ViT/G：1280、CLIP-ViT/L：768）对于两个编码器代码处理思路为：

...
tokenizers = [self.tokenizer, self.tokenizer_2] if self.tokenizer is not None else [self.tokenizer_2]
text_encoders = (
    [self.text_encoder, self.text_encoder_2] if self.text_encoder is not None else [self.text_encoder_2]
)

if prompt_embeds is None:
    prompt_2 = prompt_2 or prompt
    prompt_2 = [prompt_2] if isinstance(prompt_2, str) else prompt_2

    prompt_embeds_list = []
    prompts = [prompt, prompt_2]
    for prompt, tokenizer, text_encoder in zip(prompts, tokenizers, text_encoders):
        ...
        text_inputs = tokenizer(prompt,...)
        text_input_ids = text_inputs.input_ids
        untruncated_ids = tokenizer(prompt, ...).input_ids
        ...
        prompt_embeds = text_encoder(text_input_ids.to(device), output_hidden_states=True)
        ...
        prompt_embeds_list.append(prompt_embeds)

    prompt_embeds = torch.concat(prompt_embeds_list, dim=-1)
...
if self.do_classifier_free_guidance:
    prompt_embeds = torch.cat([negative_prompt_embeds, prompt_embeds], dim=0)
    ...
  prompt_embeds = prompt_embeds.to(device)

最后得到的prompt_embeds为：[1, 77, 2048]（由[1, 77, 768] 和 [1, 77, 1280]）拼接得到，如果要使用CFG的话就需要输入negative_prompt以及参数guidance_scale，对于negative_prompt的处理方式和上面相同。除此之外再代码中会有added_cond_kwargs = {"text_embeds": add_text_embeds, "time_ids": add_time_ids}这个参数，一般作用是：作为一个“额外”的条件添加到时间编码中（emb = emb + aug_emb if aug_emb is not None else emb）。不过值得注意的是，很多论文里面都使用：将图像和文本编码组合作为“文本编码”输入（objectclear）如果要实现这个（objectclear）功能伪代码如下：

...
    masked_image = init_image
    # masked_image = init_image * (mask < 0.5)
    obj_only = init_image * (mask > 0.5)
    obj_only = obj_only.to(device=device)
    object_embeds = self.image_prompt_encoder(obj_only)
prompt_embeds = self.postfuse_module(prompt_embeds, object_embeds, 5)

其中prompt_embeds就是正常的文本编码，self.image_prompt_encoder一般就是使用clip image的文本编码器这样一来就会将文本和图片编码成向量，self.postfuse_module一般就是将两个向量进行融合（这个一般就是通过mlp对齐维度之后直接拼接即可）
而后再图像编码。这部分比较容易直接通过vae去编码即可

...
masked_image = init_image * (mask < 0.5)
...
mask = torch.cat([mask] * 2) if do_classifier_free_guidance else mask
masked_image_latents = self._encode_vae_image(masked_image, generator=generator)

对于图片一般做法是直接masked_image = init_image * (mask < 0.5)但是论文里面有些直接使用masked_image = init_image。在文本以及图像都编码之后就是模型处理，只不过如果使用CFG：

if self.do_classifier_free_guidance:
    noise_pred_uncond, noise_pred_text = noise_pred.chunk(2)
    noise_pred = noise_pred_uncond + self.guidance_scale * (noise_pred_text - noise_pred_uncond)

if self.do_classifier_free_guidance and self.guidance_rescale > 0.0:
    # Based on 3.4. in https://arxiv.org/pdf/2305.08891.pdf
    noise_pred = rescale_noise_cfg(noise_pred, noise_pred_text, guidance_rescale=self.guidance_rescale)

补充一点：如果要做CFG一般会将文本的prompt：negative_prompt_embeds（如果没有输入negative_prompt会直接用0代替）, prompt_embeds直接拼接起来，而后其他的就直接“拼接本体”

3、Lora微调

和大语言模型的处理方式相似，通过peft去微调模型，简单了解一下peft里面微调的处理思路（值得注意的是，使用peft来微调只适用于基于transformer库来搭建的模型对于自己的模型可能没那么好的适应性）：

unet = UNet2DConditionModel.from_pretrained(
        "stable-diffusion-v1-5/stable-diffusion-inpainting", 
        subfolder="unet",
        cache_dir= '/data/huangjie',
    )
unet.requires_grad_(False)
print(unet.down_blocks[0])

unet_lora_config = LoraConfig(
        r=2,
        lora_alpha=2,
        lora_dropout=0.2,
        init_lora_weights="gaussian",
        target_modules=["to_k", "to_q", "to_v", "to_out.0", "add_k_proj", "add_v_proj"],
    )
unet.add_adapter(unet_lora_config)
print("after Lora Model:", unet.down_blocks[0])

上面两个过程模型变化为：

仔细分析一下LoraConfig里面的具体原理，因为很多模型（基于attention）基本就是q、k、v三个，因此通过target_modules指定哪些模块的参数是需要通过lora进行调整的模块。init_lora_weights代表lora初始化参数分布策略，参数r以及 lora_alpha代表的含义是：
\(y=Wx+ \text{Dropout}(\text{B}_{out \times r} \text{A}_{r \times in}x) \times \frac{\text{lora\_alpha}}{r}\)

经典问题：1、lora里面参数里面之所以初始化为0是因为对于我们的llm/DF模型一般都是“优秀”的，而对于“陌生”的数据通过零初始化确保一切干净，从 0 开始稳步适配（在训练初期引入噪声，可能导致不稳定，尤其在微调少步数、低学习率时，收敛更慢）2、多个lora模型同时作用于一个SD模型，并配置他们的各自权重，并且不同lora参数对模型生成的影响⁴:

4、Adapters使用

lora也是Adapters（可以简单理解为对训练好的模型再去添加一个插件，通过这个插件让SD去生成其他的样式的图片）一种，具体见：深入浅出了解生成模型-6：常用基础模型与 Adapters等解析

5、自注意力技术（AttnProcessor、AttnProcessor2_0）

https://huggingface.co/docs/diffusers/v0.30.1/en/api/attnprocessor

• 1、AttnProcessor

此部分就是非常常规的注意力计算方式

• 2、AttnProcessor2_0

它调用了 PyTorch 2.0 起启用的算子 F.scaled_dot_product_attention 代替手动实现的注意力计算。这个算子更加高效，如果你确定 PyTorch 版本至少为 2.0，就可以用 AttnProcessor2_0 代替
参考知乎⁵中的描述，如何将自注意力进行修改，比如说如下代码：

from diffusers.models.attention_processor import (Attention,AttnProcessor,AttnProcessor2_0)
unet = UNet2DConditionModel()
for name, module in unet.named_modules():
   if isinstance(module, Attention) and "attn2" in name:
      print(f'name: {name}')
      print("*"*20)
      break

那么就会得到一个比如说：down_blocks.0.attentions.0.transformer_blocks.0.attn2比如说如果我需要将这个替换那么处理方式为：

for name, module in unet.named_modules():
   if isinstance(module, Attention) and "attn2" in name:
      print(f'raw name: {name} \n raw module: {module.processor}')
      print("*"*20)
      if isinstance(module.processor, AttnProcessor2_0):
         module.set_processor(AttnProcessor())
      print(f"change name: {name} \n change module: {module.processor}")
      print("*"*20)
      break

这样一来有最开始的：<diffusers.models.attention_processor.AttnProcessor2_0 object at 0x7ff392734eb0> 替换为<diffusers.models.attention_processor.AttnProcessor object at 0x7ff5b776bc40>。或者直接改成自定义的处理方式：

class CustonAttnProcessor(AttnProcessor):
    def __call__(self, attn, hidden_states, encoder_hidden_states=None, attention_mask=None):
        query = attn.to_q(hidden_states)
        encoder_states = hidden_states if encoder_hidden_states is None else encoder_hidden_states
        key = attn.to_k(encoder_states)
        value = attn.to_v(encoder_states)

        attn_scores = torch.baddbmm(
            torch.empty(query.shape[0], query.shape[1], key.shape[1], device=query.device),
            query,
            key.transpose(-1, -2),
            beta=0,
            alpha=attn.scale,
        )

        # 比如说对 attn_scores 取log
        attn_probs = torch.log(attn_scores) 
        attn_probs = attn_scores.softmax(dim=-1)

        hidden_states = torch.bmm(attn_probs, value)
        hidden_states = attn.to_out[0](hidden_states)
        hidden_states = attn.to_out[1](hidden_states)
        return hidden_states

attn_processor_dict = {}
for k in unet.attn_processors.keys():
    if "attn2" in k:
        attn_processor_dict[k] = CustonAttnProcessor()
    else:
        attn_processor_dict[k] = unet.attn_processors[k]
unet.set_attn_processor(attn_processor_dict)
for name, processor in unet.attn_processors.items():
   print(name, "=>", type(processor))

总的来说如果要去修改注意力处理方式，直接去便利unet.attn_processors.keys()然后去找到需要修改的层将其替换即可，只不过关键在于CustonAttnProcessor的定义方式。

数据合成

数据合成/标签算法汇总

参考

具体代码推导可以直接看最后对于LCM代码分析。介绍一致性模型之前需要了解几个知识：在传统的扩散模型中无论是加噪还是解噪过程都是随机的，在论文¹中（也就是CM作者宋博士的另外一篇论文）将这个随机过程（也就是随机微分方程SDE）转化成“固定的”过程（也就是常微分方程ODE），只有过程可控才能保证下面公式成立。

一致性模型（Consistency Model）

其中ODE（常微分方程），在传统的扩散模型（Diffusion Models, DM）中，前向过程是从原始图像 $x_0$开始，不断添加噪声，经过 $T$步得到高斯噪声图像 $x_T$。反向过程（如 DDPM）通常通过训练一个逐步去噪的模型，将 $x_T$逐步还原为 $x_0$ ，每一步估计一个中间状态，因此推理成本高（需迭代 T 步）。而在 Consistency Models（CM） 中，模型训练时引入了 Consistency Regularization，使得模型在不同的时间步 $t$都能一致地预测干净图像。这样在推理时，无需迭代多步，而是可以通过一个单一函数$f(x ,t)$ 直接将任意噪声图像$x_t$ 还原为目标图像$x_0$ 。这大大减少了推理时间，实现了一步（或少数几步）生成。

一致性模型（consistency model）在论文²里面主要是通过使用常微分方程角度出发进行解释的。Consistency Model 在 Diffusion Model 的基础上，新增了一个约束：从某个样本到某个噪声的加噪轨迹上的每一个点，都可以经过一个函数 $f$ 映射为这条轨迹的起点（也就是通过扩散处理的图像在不同的时间 $t$ 都可以直接转化为最开始的图像 $x_0$），用数学描述就是：$f:(x_t, t)\rightarrow x_\epsilon$，换言之就是需要满足： $f(x_t,t)=f(x_{t^\prime},t^\prime)$ 其中 $t,t^\prime \in [\epsilon,T]$，正如论文里面的图片描述：

要满足上面的计算关系，作者在论文里面定义如下的等式关系（下面等式关系就是CM中核心概念）：

其中等式需要满足：$c_{skip}(\epsilon)=1,c_{out}(\epsilon)=0$ （$c_{skip}(t)=\frac{\sigma_{data}^2}{(t- \epsilon)^2+ \sigma_{data}^2}$， $c_{out}(t)=\frac{\sigma_{data}(t-\epsilon)}{\sqrt{\sigma_{data}^2+ t^2}}$），随着解噪过程（时间从：$T \rightarrow \epsilon$ 其中 $c_{skip}$ 的值逐渐增大，也就是当前的解噪图像占比权重增加），其中我的 $F_\theta$ 就是我们的神经网络模型（比如Unet）。既然使用了神经网络那么必定就需要设计一个损失函数，在论文里面作者设计的损失函数为：两个时间步之间生成得到的图像距离通过最小化这个值（比如说 $\Vert x_{t+1} - x_t \Vert_2$）来优化模型参数。作者对于模型训练给出两种训练方式

直接通过蒸馏模型进行优化

通过直接蒸馏的方式对模型参数进行优化，其中设计的损失函数为：

其中 $d$代表距离（比如 $l_1$ 或者 $l_2$ ）对于上面公式代表的含义是：从样本集中得到一个样本，而后加噪得到 $x_{t_{n+1}}$ ，然后利用预训练的 Diffusion 模型去一次噪，预测到另外一个点 $\hat{x}{t_n}^{\phi}$ 然后计算这两个点送入后的结果，用特定损失函数约束其一致（也就是： 模型在两个时间步之间的预测结果是否一致 也就是 $f\theta(t_{n+k})=f_\theta(t_n)$，其他的DF模型一般学的是噪声是不是一致的）。其中预测过程就是使用ODE solver进行处理，比如说：

其中DDIM、DPM++就是ODE solver一种。

欧拉法： $y_{n+1}= y_n+h*f(t_n, y_n)$ 其中h代表时间步长，f代表当前导数估计。不过值得进一步了解的是，在DL中大部分函数都是直接通过神经网络进行“估算的”，也就是说对于上面的 $\nabla_{x_{t_{n+1}}}\log p_{t_{n+1}} \textcolor{red}{≈} s_\theta(x_{t_{n+1}},t_{n+1})$ 其中 $s_\theta$代表的是训练好的去噪网络。

那么这样一来整个过程就变成了：

直接训练模型进行优化

直接训练模型进行优化，其中具体的过程为：

LCM/LCM-Lora

潜在一致性模型（Latent Consistency Model）³以及LCM-Lora⁴（LCM的Lora优微调）通过再latent space中使用一致性模型（stable diffusion model通过VAE将图像进行压缩到latent sapce而后通过DF模型训练并且最后再通过VAE decoder输出），在LCM中主要提出两点：
1、Skipping-Step：因为在最开始的CM中计算两个相邻的时间步之间的loss由于时间步过于接近，就会导致loss很小，因此通过跳步解决这个问题，这样loss就会变成：$d(f(x_{t_{n+\textcolor{red}{k}}}, t_{n+\textcolor{red}{k}}), f(x_{t_n}, t_n))$。
2、引入Classifier-free guidance (CFG) 那么整个loss计算就会变成：$d(f(x_{t_{n+\textcolor{red}{k}}}, \textcolor{red}{w}+ \textcolor{red}{c}, t_{n+\textcolor{red}{k}}), f(x_{t_n}, \textcolor{red}{w}+ \textcolor{red}{c}+ t_n))$，公式中c代表文本，对于CFG而言其实就是一个改进的ODE solver（见下面算法流程中的蓝色部分）
对于LCD算法流程，其中蓝色部分为LCM所修改的内容：

对于最后得到的实验结果分析：

• 不同的k对结果的影响

在DPM-solver++和DPM-Solver中基本只需要 2000 步迭代，LCM 4 步采样的 FID 就已经基本收敛了

• 不同的Guidance Scale对结果的影响

LCM 作者用不同 LCM 的迭代次数与不同 Guidance Scale 做了对比。发现 $w$ 增加有助于提升 CLIP Score，但是损失了 FID 指标（即多样性）的表现。另外，LCM 迭代次数为 2、4、8 时，CLIP Score 和 FID 相差都不大，说明了 LCM 的蒸馏性能确实非常强悍，两步前向的效果可能都足够好了，只是一步前向的结果还差些。
总得来说，在LCM中主要是做了如下几点改进：1、使用skipping-step来“拉大”相邻点之间的距离计算；2、改进了ODE solver。

LCM蒸馏训练到底在做什么？

通过结合代码理解

首先直接使用我们使用我们训练好的unet模型（unet = UNet2DConditionModel.from_pretrained）作为函数$f_\theta$。因为在CM中基于ODE（常微分方程）保证“路径”一致，并且CM核心观点就是希望模型学习从一个“晚”的时间步（接近噪声状态）预测出一个“早”的时间步（接近干净图像）下的表示（让模型学习 $z_{t_{n+k}}$ 预测出 $z_{t_n}$）。那么在采样步数过程中代码处理方式如下：

bsz = latents.shape[0]
topk = noise_scheduler.config.num_train_timesteps // args.num_ddim_timesteps #noise_scheduler使用的DDPM topk=1000//50=20 也就是说将连续时间分为 20 段
index = torch.randint(0, args.num_ddim_timesteps, (bsz,), device=latents.device).long() # 得到 t_{n+k}，得到每一段的索引
start_timesteps = solver.ddim_timesteps[index] # 得到 t_{n}
timesteps = start_timesteps - topk #solver使用的DDIM
timesteps = torch.where(timesteps < 0, torch.zeros_like(timesteps), timesteps)

c_skip_start, c_out_start = scalings_for_boundary_conditions(start_timesteps,...)
...
c_skip, c_out = scalings_for_boundary_conditions(timesteps, ...)
...
noisy_model_input = noise_scheduler.add_noise(latents, noise, start_timesteps)

对于上述过程定量分析，比如说原始步骤1000步，如果蒸馏到50步LCM，那么计算步幅（topk）得到20，而后去进行随机采样（index）假设值为10，那么就可以得到起点（start_timesteps）:10*20=200，终点（timesteps）：200-20=180，进而计算系数在t=200时候（假设）c_skip、c_out=0.2，0.8，t=180时候c_skip、c_out=0.25，0.75。那么最终的任务中，学生模型过程拿着 $t=200$ 的噪声，试图预测 $t=0$ 的样子，教师模型过程：拿着 $t=200$ 的噪声，走一步 DDIM 到 $t=180$，告诉学生：“根据我的经验，在 $t=180$ 时图像的一致性终点应该是这个，你照着这个练。”

• 学生模型处理过程

在得到噪声之后直接输入到模型中也就是计算预测噪声（noise_pred = unet(noisy_model_input,...).sample）并且去反推预测结果 $F_\theta(x,t)$（pred_x_0 = get_predicted_original_sample()），LCM核心从某个样本到某个噪声的加噪轨迹上的每一个点，都可以经过一个函数映射为这条轨迹的起点，那么可以根据公式（$f_\theta(x,t)=c_{skip}(t)x+ c_{out}(t)F_\theta(x,t)$）就可以得到（学生模型）最后的输出model_pred=c_skip_start * noisy_model_input + c_out_start * pred_x_0。也就对应下面代码：

noise = torch.randn_like(latents)
noisy_model_input = noise_scheduler.add_noise(latents, noise, start_timesteps)
...
noise_pred = unet(noisy_model_input,start_timesteps,...).sample
pred_x_0 = get_predicted_original_sample(noise_pred,start_timesteps,noisy_model_input,noise_scheduler.config.prediction_type...)#计算反推样本起点x0
model_pred = c_skip_start * noisy_model_input + c_out_start * pred_x_0

• 教师模型处理过程

处理过程和上面的处理方式是相似的（让模型学习 $z_{t_{n+k}}$ 预测出 $z_{t_n}$）也就是对应下面的：

那么具体的代码操作如下：

noisy_model_input = noise_scheduler.add_noise(latents, noise, start_timesteps)
...
accelerator.unwrap_model(unet).disable_adapters() # 因为我用lora去微调我的模型因此教师模型首先将lora取消掉
with torch.no_grad():
  # 1. Get teacher model prediction on noisy_model_input z_{t_{n + k}} and conditional embedding c
  cond_teacher_output = unet(noisy_model_input,start_timesteps,...).sample
  cond_pred_x0 = get_predicted_original_sample(cond_teacher_output,start_timesteps,noisy_model_input,...)
  cond_pred_noise = get_predicted_noise(cond_teacher_output,start_timesteps,noisy_model_input,...)

  # 2. Get teacher model prediction on noisy_model_input z_{t_{n + k}} and unconditional embedding 0
  uncond_prompt_embeds = torch.zeros_like(prompt_embeds)
  uncond_pooled_prompt_embeds = torch.zeros_like(encoded_text["text_embeds"])
  uncond_added_conditions = copy.deepcopy(encoded_text)
  uncond_added_conditions["text_embeds"] = uncond_pooled_prompt_embeds
  uncond_teacher_output = unet(noisy_model_input,start_timesteps,encoder_hidden_states=uncond_prompt_embeds.to(weight_dtype),encoder_hidden_states=uncond_prompt_embeds.to(weight_dtype),added_cond_kwargs={k: v.to(weight_dtype) for k, v in uncond_added_conditions.items()},).sample
  uncond_pred_x0 = get_predicted_original_sample(uncond_teacher_output,start_timesteps,noisy_model_input,...)
  uncond_pred_noise = get_predicted_noise(uncond_teacher_output,start_timesteps,noisy_model_input,...)

  # 3. Calculate the CFG estimate of x_0 (pred_x0) and eps_0 (pred_noise)
  pred_x0 = cond_pred_x0 + w * (cond_pred_x0 - uncond_pred_x0)
  pred_noise = cond_pred_noise + w * (cond_pred_noise - uncond_pred_noise)
  # 4. Run one step of the ODE solver to estimate the next point x_prev on the
  # augmented PF-ODE trajectory (solving backward in time)
  # Note that the DDIM step depends on both the predicted x_0 and source noise eps_0.
  x_prev = solver.ddim_step(pred_x0, pred_noise, index).to(unet.dtype)

对于上述代码可以这么理解，我的学生模型使用了Lora进行处理，我的教师模型不使用Lora处理的模型那么直接disable_adapters，在LCM的训练过程中核心思想是把输入 $x$的一部分“直接跳过” （$c_{skip}$），剩下的部分用模型预测 $F_\theta$修正，对应计算过程：$f_\theta(x,t)=c_{skip}(t)x+ c_{out}(t)F_\theta(x,t)$，那么对应学生和教师模型处理方式是一致的，只不过在LCM中会使用CFG所以处理过程就比学生模型稍复杂一点在得到预测x_0以及噪声noise之后，通过x_prev = solver.ddim_step(pred_x0, pred_noise, index)让 教师模型为学生模型提供一条确定的去噪路径（这个过程直接通过ODE计算得到），从而让学生模型学习如何从噪声生成高质量样本，而后就是计算loss：

start_timesteps = solver.ddim_timesteps[index]
timesteps = start_timesteps - topk
...
accelerator.unwrap_model(unet).enable_adapters()
with torch.no_grad():
  target_noise_pred = unet(x_prev,timesteps,...).sample
  pred_x_0 = get_predicted_original_sample(target_noise_pred,timesteps,x_prev,)
  target = c_skip * x_prev + c_out * pred_x_0

if args.loss_type == "l2":
  loss = F.mse_loss(model_pred.float(), target.float(), reduction="mean")

对于上述loss过程简单理解为：在最开始我的模型直接从200步预测最后图像并通过公式 $f_\theta(x,t)=c_{skip}(t)x+ c_{out}(t)F_\theta(x,t)$ 反推最后的结果得到model_pred，而后我的教师模型直接根据200步（start_timesteps）的加噪图像去预测噪声，并通过DDIM采样器去计算20步后的结果（180）得到 x_prev 而后我的模型再去预测180步到最后图像并且还是通过上面跳步公式得到 target，最后根据“模型在两个时间步之间的预测结果一致”假设去计算loss。

总结

总的来说在LCM中核心概念：1、从某个样本到某个噪声的加噪轨迹上的每一个点，都可以经过一个函数 $f$ 映射为这条轨迹的起点，将随机过程变为确定过程；2、模型在两个时间步之间的预测结果一致，$f(x_t,t)=f(x_{t^\prime},t^\prime)$ 其中 $t,t^\prime \in [\epsilon,T]$。除此之外为了实现少的步骤（跳步）的生成发生，通过计算公式 $f_\theta(x,t)=c_{skip}(t)x+ c_{out}(t)F_\theta(x,t)$ 直接从 $t$步跳到 $0$ 步。
训练过程可以简单理解为：对于输入图像 $x$，直接添加 $n$ 步的噪声得到 $x_n$，而后我的学生模型直接去预测 $t_0$ 时候的结果 $y_1$；同时，我的教师模型（预训练好的扩散模型）从 $x_n$ 出发，通过 DDIM 采样器向前走一步（跨越 $k$ 个时间步），得到 $t_{n-k}$ 时刻在轨迹上的观察点 $x_{n-k}$；而后再去用学生模型通过 $x_{n-k}$ 预测 $t_0$ 的结果得到 $y_2$。最后计算 $y_1$ 与 $y_2$ 之间的距离损失（Consistency Loss），迫使模型无论从哪个时间步出发，预测的终点都指向同一点。

参考

PixelHacker

Code: https://github.com/hustvl/PixelHacker

模型整体框架和Diffusion Model相似，输入分为3部分：1、image；2、mask；3、mask image而后将这三部分进行拼接，然后通过VAE进行encoder，除此之外类似Diffusion Model中处理，将condition替换为mask内容（这部分作者分为两类：1、foreground（116种类别）；2、background（21种类别））作为condition（对于foreground直接通过编码处理，对于background的3部分通过：$M_{scene}+M_{rand}P_{rand}+M_{obj}P_{obj}$ 分别对于background的3部分）然后输入到注意力计算中。

注意力计算过程，对于通过VAE编码后的内容$L_{in}$ 直接通过 $LW$ 计算得到QKV，并且通过 2D遗忘矩阵 $G_t$计算过程为：

$L_t$计算过程：

PixelHacker实际测试效果

图像	mask	结果	问题
			背景文字细节丢失
			人物细节
			生成错误

分析：只能生成较低分辨率图像（512x512，Github），去除过程中对于复杂的图像可能导致细节（背景中的文字、图像任务）处理不好。

PowerPanint

A Task is Worth One Word: Learning with Task Prompts for High-Quality Versatile Image Inpainting
From: https://github.com/open-mmlab/PowerPaint
Modle：SD v1.5、CLIP

模型整体结构和DF模型相同，输入模型内容为：噪声的潜在分布、mask图像（$x \bigodot (1-m)$）、mask；在论文中将condition替换为4部分组合（微调两部分：$P_{obj}$ 以及 $P_{ctxt}$）：1、$P_{obj}$
1、增强上下文的模型感知：使用随机mask训练模型并对其进行优化以重建原始图像可获得最佳效果，通过使用$P_{ctxt}$（可学习的）让模型学会如何根据图像的上下文信息来填充缺失的部分,而不是依赖于文本描述，优化过程为：

2、通过文本增强模型消除：通过使用$P_{obj}$：训练过程和上面公式相同，不过将识别得到的物体bbox作为图像mask并且将 $P_{obj}$作为mask区域的文本描述，引导模型根据给定的文本描述生成对应的对象。

第1和第2点区别在于，第二点输入有文本描述，而第一点就是可学习的文本

3、物品移除：使用移除过程中模型很容易进入一个“误解”：模型是新生成一个内容贴在需要消除的内容位置而不是消除内容（比如下面结果），作者的做法是直接将上面两个进行加权：

4、通过形状增强模型消除：$P_{shape}$：使用精确的对象分割mask和对象描述进行训练，不过这样会使得模型过拟合（输入文本和选定的区域，可能模型只考虑选定区域内容生成），因此替换做法是：直接对精确识别得到内容通过 膨胀操作让他没那么精确，具体处理操作为：

于此同时参考上面过程还是进行加权组合

PowerPanint实际测试效果

只测试 Object removal inpainting，测试的权重：ppt-v1

图像	mask	结果	测试
			部分移除
			全部移除
			复杂布局全部移除
			复杂布局细小内容移除
			多目标内容移除
			多目标内容移除

总的来说：PowerPanint还是比较优秀的消除模型，总体移除效果“说得过去”（如果不去追求消除的细节，见下面图像，比如说消除带来的图像被扭曲等）不过得到最后的图像的尺寸会被修改（in：2250x1500 out：960x640，此部分没有仔细去检查源代码是否可以取消或者自定义），除此之外，参考Github上提出的issue-1：图像 resize 了，修改了分辨率，VAE 对人脸的重建有损失，如果mask没有完全覆盖掉人，留了一些边缘，模型有bias容易重建生成出新的东西。issue-2：平均推理速度20s A100 GPU。

Improving Text-guided Object Inpainting with Semantic Pre-inpainting

From: https://github.com/Nnn-s/CATdiffusion.
没有提供权重无法测试

由于DDM生成过程中是不可控的，本文提出通过text来提高模型可控。相比较之前研究（直接将图片通过VAE处理输入DF中，并且将文本作为条件进行输入），最开始得到的latent space和text feature之间存在“信息不对齐”。在该文中“提前”将text feature输入到模型中。具体做法是：

• 首先通过CLIP来对齐特征信息

将image通过clip image encoder进行编码得到特征而后通过SemInpainter：同时结合可学习的位置信息（PE）、可学习的mask图像特征（ME）、文本特征，整个过程为：

其中：SemInpainter（和CLIP的image encoder相似结构）根据视觉上下文和文本提示c的条件下，恢复CLIP空间中mask对象的ground-truth语义特征，说人话就是通过知识蒸馏方式来训练这个模块参数。对于两部分特征最后通过下采样方式得到最后特征：

• **reference adapter layer (RefAdapter) **

Attentive Eraser

Attentive Eraser: Unleashing Diffusion Model’s Object Removal Potential via Self-Attention Redirection Guidance
测试demo
AAAI-2025

模型结构：

模型出出发点：图像擦除过程中会生成随机伪影，以及在删除后无法用适当的内容重新绘制前景对象区域。主要改进：
1、Attention Activation and Suppres-sion (AAS)：是一种自我注意机制修改操作，专为应对物体移除任务的固有挑战而量身定制，旨在使前景物体区域的生成更加关注背景，同时消除物体的外观信息。此外，”相似性抑制”（SS）可抑制由于自我注意的固有特性而可能导致的对相似物体的高度关注。具体做法：计算得到注意得分：$S$；以及$A=softmax(S)\in R^{N^2 \times N^2}$。其中具体计算方式（对于上面流程图中对呀公式序号，其中$M_{l,t}$代表的是如果属于obg那么标记1否则0）：

对于公式13：强化obj信息（将$obj\rightarrow obj$设定为负无穷）；对于公式14：强化$obj\rightarrow bg$ 将其设为负无穷。
2、Self-Attention Redirection Guidance (SARG)：这是一种应用于扩散反向取样过程的引导方法，它通过 AAS 利用重定向自我注意引导取样过程朝物体移除的方向进行。

算法流程：

Attentive Eraser实际测试效果

原图	Mask	结果

总结

简单终结上面几篇论文，基本出发思路都是基于Stable diffusion Moddel然后通过修改Condition方式：无论为是CLip编码文本嵌入还是clip编码图像嵌入。不过值得留意几个点：1、对于mask内容可以用“非规则”（类似对mask内容进行膨胀处理）的方式输入到模型中来提高能力。2、在图像擦除中容易出现几个小问题：图像替换问题（理论上是擦除图像但是实际被其他图像给“替换”）、图像模糊问题（擦除图像之后可能会在图像上加一个“马赛克”，擦除区域模糊）对于这两类问题可以参考论文。
进一步阅读： 1、https://arxiv.org/pdf/2504.00996；2、RAD: Region-Aware Diffusion Models for Image Inpainting

前言

在pytorch中，选择优化器（torch.optim）一般在使用过程中直接通过这个去定义我们所需要的优化器，如adam等，因此对于其基础类（torch.optim.Optimizer(params, defaults)）一般就是直接输入模型的参数，而后可以直接通过这个类去做一些基本操作，如Optimizer.load_state_dict 加载优化器状态等。直接通过Adamw来解释（都是直接继承这个基础类的）

class AdamW(Optimizer):
    def __init__(
        self,
        params: ParamsT,
        lr: Union[float, Tensor] = 1e-3,
        betas: Tuple[float, float] = (0.9, 0.999),
        eps: float = 1e-8,
        weight_decay: float = 1e-2,
        amsgrad: bool = False,
        *,
        maximize: bool = False,
        foreach: Optional[bool] = None,
        capturable: bool = False,
        differentiable: bool = False,
        fused: Optional[bool] = None,
    ):

其中不同变量含义为：
1、params：一般就是网络结构的优化参数

对于这个参数可以多了解一些，一般使用过程中都是直接 model.parameters()，但是有些时候，比如模型结构复杂可能对于不同的网络结构选择不同的学习率等，可以直接 optimizer = torch.optim.AdamW([{'params': model.fc1.parameters(), 'lr': 1e-3},{'params': model.fc2.parameters(), 'lr': 1e-4, 'weight_decay': 0.01},],lr= 1e-5)

2、lr：学习率；3、betas：是一阶和二阶矩估计的指数衰减率；4、eps：为了防止除以 0 而加在分母中的一个非常小的数（epsilon）；5、weight_decay：权重衰减系数（L2 正则化强度）
了解其基本优化算法之后在 torch.optim 也有另外一个“大杀器”：torch.optim.lr_scheduler 直接去对学习率进行优化

学习率优化器

上面已经介绍了 torch.optim.lr_scheduler这里直接进一步解释其各类方法以及代码实战。其中在 torch.optim.lr_scheduler 中大部分调整学习率的方法都是根据epoch训练次数。直接总结如下所示：

对于不同的优化器实际测试代码见文件：learning_rate.ipynb。于此同时不同学习率优化得到的学习率变化曲线为：

值得注意的是，在使用lr_scheduler过程中，一般使用套路为：

# 定义学习率变化方式
lr_scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max= (page_layout_config.cos_warmup_t_max* len(train_dataloader)),eta_min= page_layout_config.cos_warmup_eta_min)
...
# 如果使用huggingface的并行训练框架
lr_scheduler = accelerator.prepare(lr_scheduler)
out = model(x)
loss = loss_function(out, label)
accelerator.backward(loss)
if accelerator.sync_gradients:
    accelerator.clip_grad_norm_(model.parameters(), 1.0)
optimizer.step()
lr_scheduler.step() # 更新策略是由讲究的，见下面括号中的描述
optimizer.zero_grad()
# 如果不使用框架
out = model(x)
loss = loss_function(out, label)
loss.backward()
optimizer.step()
lr_scheduler.step()
optimizer.zero_grad()

要获取学习率的当前值，可使用 scheduler.get_last_lr()[0]。不同调度器的更新方式存在差异，具体如下：1、基于步数的调度（再每一次dataloader处理之后都要进行更新）：CyclicLR 和 OneCycleLR 直接根据训练步数（step）更新学习率，适合在每个 batch 后调用 scheduler.step()。2、基于指标的调度：ReduceLROnPlateau 根据验证指标（如损失或准确率）动态调整学习率，需在 scheduler.step(metrics) 中传入指标值。3、基于 epoch 的调度（在结束一个epoch后再去更新学习率）：其他调度器（如 CosineAnnealingLR）通常基于 epoch 调整学习率。例如，CosineAnnealingLR(optimizer, T_max=10, eta_min=0) 以 10 个 epoch 为一个周期进行余弦退火调整。

参考

Clip

代表模型 CLIP¹，更加像一种 图像-文本对齐模型，按照论文里面他自己提到的计算范式：

# image_encoder - ResNet or Vision Transformer
# text_encoder - CBOW or Text Transformer
# I[n, h, w, c] - minibatch of aligned images
# T[n, l] - minibatch of aligned texts
# W_i[d_i, d_e] - learned proj of image to embed
# W_t[d_t, d_e] - learned proj of text to embed
# t - learned temperature parameter
# extract feature representations of each modality
I_f = image_encoder(I) #[n, d_i]
T_f = text_encoder(T) #[n, d_t]
# joint multimodal embedding [n, d_e]
I_e = l2_normalize(np.dot(I_f, W_i), axis=1)
T_e = l2_normalize(np.dot(T_f, W_t), axis=1)
# scaled pairwise cosine similarities [n, n]
logits = np.dot(I_e, T_e.T) * np.exp(t)
# symmetric loss function
labels = np.arange(n)
loss_i = cross_entropy_loss(logits, labels, axis=0)
loss_t = cross_entropy_loss(logits, labels, axis=1)
loss = (loss_i + loss_t)/2

在将 Image 和 Text 编码完成之后，直接计算它们之间的相似度，实现模态之间的对齐。优化过程的目标是让匹配的图文对的相似度尽可能大，同时让不匹配对的相似度尽可能小。换言之，CLIP 的对比学习机制本质上是在学习一种跨模态的相似度表示。其核心机制是通过对比学习和嵌入空间对齐，将图像和文本映射到一个共享的语义空间中。
尽管 CLIP 本身并不直接包含复杂的推理能力或任务特定的知识，但它通过大规模预训练，展现出了强大的通用性和零样本学习能力。在论文中，CLIP 表现出了不俗的零样本性能，但需要注意的是，CLIP 的主要目标是学习跨模态的对齐表示，这使得它能够胜任多种任务（如图文检索、零样本分类等）。相比于传统的目标识别模型，CLIP 更像是一个多模态的基础模型，具备更广泛的适用性和灵活性。