目录
  1. 1. LLM 推理优化与量化交易应用
    1. 1.1. 目录
    2. 1.2. 目录
    3. 1.3. 1. 引言
      1. 1.3.1. 为什么 DeepSeek 量化岗要考 LLM 推理优化?
      2. 1.3.2. LLM 推理的基本计算特征
    4. 1.4. 2. KV Cache 管理与 PagedAttention
      1. 1.4.1. 2.1 KV Cache 的必要性与代价
      2. 1.4.2. 2.2 传统系统的内存碎片问题
      3. 1.4.3. 2.3 PagedAttention:操作系统分页思想的移植
      4. 1.4.4. 2.4 PagedAttention 性能数据
    5. 1.5. 3. FlashAttention:IO 感知的注意力计算
      1. 1.5.1. 3.1 标准 Attention 的内存瓶颈
      2. 1.5.2. 3.2 FlashAttention 的核心技术
      3. 1.5.3. 3.3 FlashAttention-2 的改进
      4. 1.5.4. 3.4 在量化交易中的含义
    6. 1.6. 4. 推测解码 (Speculative Decoding)
      1. 1.6.1. 4.1 核心问题:Decode 的串行性
      2. 1.6.2. 4.2 推测解码的机制
      3. 1.6.3. 4.3 加速比分析
      4. 1.6.4. 4.4 DeepSeek 的实际应用
    7. 1.7. 5. 量化技术对比
      1. 1.7.1. 5.1 为什么需要模型量化?
      2. 1.7.2. 5.2 GPTQ:基于二阶信息的权重量化
      3. 1.7.3. 5.3 AWQ:激活感知的权重量化
      4. 1.7.4. 5.4 INT8 vs INT4 的工程权衡
    8. 1.8. 6. Continuous Batching vs Static Batching
      1. 1.8.1. 6.1 Static Batching 的缺陷
      2. 1.8.2. 6.2 Continuous Batching(Iteration-Level Scheduling)
      3. 1.8.3. 6.3 Prefill-Decode 分离
    9. 1.9. 7. LLM 在量化交易中的应用谱系
      1. 1.9.1. 7.1 金融 LLM 的发展
      2. 1.9.2. 7.2 情绪因子与 LLM:真实有用
      3. 1.9.3. 7.3 研报解析与信息提取
      4. 1.9.4. 7.4 Chain-of-Thought 在金融推理中的应用
      5. 1.9.5. 7.5 另类数据处理
    10. 1.10. 8. 量化交易 LLM 的核心约束
      1. 1.10.1. 8.1 延迟约束:明确的边界
      2. 1.10.2. 8.2 可解释性约束
      3. 1.10.3. 8.3 Regime Change 问题
      4. 1.10.4. 8.4 过拟合与前视偏差风险
      5. 1.10.5. 8.5 成本约束
    11. 1.11. 9. DeepSeek 量化岗面试重点问答
    12. 1.12. 参考文献
    13. 1.13. 10. 前沿推理优化:分离式架构与受限解码
      1. 1.13.1. 10.1 Prefill-Decode 分离架构(Disaggregated Serving)
      2. 1.13.2. 10.2 前缀缓存(Prefix Caching)
      3. 1.13.3. 10.3 受限解码(Constrained Decoding)
LLM 推理优化与量化交易应用

LLM 推理优化与量化交易应用

定位:DeepSeek 量化交易岗位面试深度准备文档
前置知识:Transformer 架构、预训练、RLHF、MoE
核心论文:全部来自真实已发表学术工作,标注 arXiv 编号
更新时间:2026-05

目录

  1. 目录
  2. 1. 引言
  3. 2. KV Cache 管理与 PagedAttention
  4. 3. FlashAttention:IO 感知的注意力计算
  5. 4. 推测解码 (Speculative Decoding)
  6. 5. 量化技术对比
  7. 6. Continuous Batching vs Static Batching
  8. 7. LLM 在量化交易中的应用谱系
  9. 8. 量化交易 LLM 的核心约束
  10. 9. DeepSeek 量化岗面试重点问答
  11. 参考文献

目录

  1. 引言:为什么量化岗关注 LLM 推理优化
  2. KV Cache 管理与 PagedAttention
  3. FlashAttention:IO 感知的注意力计算
  4. 推测解码 (Speculative Decoding)
  5. 量化技术对比:GPTQ vs AWQ vs INT8/INT4
  6. Continuous Batching vs Static Batching
  7. LLM 在量化交易中的应用谱系
  8. 量化交易 LLM 的核心约束
  9. DeepSeek 量化岗面试重点问答(10题)

1. 引言

为什么 DeepSeek 量化岗要考 LLM 推理优化?

DeepSeek 是一家模型研发与量化交易并行的公司。其量化交易团队并非简单”调用 API”,而是将 LLM 能力深度集成进交易基础设施。这带来一个根本性的工程挑战:

量化交易对延迟极度敏感,而 LLM 推理天然是高延迟操作。

具体矛盾体现在:

场景 延迟要求 LLM 原生延迟 核心矛盾
高频做市 < 1ms 数百ms~数秒 完全不可行
日内因子更新 < 1min 几十ms(batch) 工程可优化
研报/新闻解析 < 5min 秒级 可接受
隔夜策略研究 无实时要求 任意 无约束

因此,DeepSeek 量化岗候选人需要同时理解

  1. LLM 推理的瓶颈在哪里(内存带宽、计算墙、KV cache 膨胀)
  2. 哪些优化技术能将延迟压缩到何种程度
  3. 在何种延迟约束下,LLM 才能真正为量化策略创造 alpha

这不是两个独立的知识体系——它们的交叉点正是 DeepSeek 量化技术的核心壁垒。

LLM 推理的基本计算特征

一次自回归生成(prefill + decode 两阶段):

Prefill 阶段(并行处理输入 prompt):
$$\text{FLOP}_{\text{prefill}} \approx 2 \cdot N_{\text{params}} \cdot L_{\text{prompt}}$$

Decode 阶段(逐 token 生成):
$$\text{FLOP}_{\text{decode/token}} \approx 2 \cdot N_{\text{params}}$$

其中 $N_{\text{params}}$ 是参数量,$L_{\text{prompt}}$ 是 prompt 长度。

瓶颈分析:Decode 阶段的算术强度(FLOP / 内存读取字节)极低——每次生成一个 token 需要从 GPU 内存读取整个模型权重,但只执行少量计算。这意味着 decode 是内存带宽瓶颈,不是计算瓶颈。

$$\text{Arithmetic Intensity}_{\text{decode}} = \frac{2 \cdot N_{\text{params}}}{2 \cdot N_{\text{params}} \cdot \text{bytes/param}} = \frac{1}{\text{bytes/param}}$$

对于 FP16(2 bytes/param),算术强度约为 0.5 FLOP/byte,远低于现代 GPU 的 roofline(A100 约 312 TFLOP/s,内存带宽 2 TB/s,roofline 为 156 FLOP/byte)。

这就是为什么所有推理优化技术都围绕减少内存访问提高内存利用率展开。

2. KV Cache 管理与 PagedAttention

2.1 KV Cache 的必要性与代价

论文:PagedAttention / vLLM(Kwon et al., 2023,arXiv:2309.06180)

自回归解码时,每个新 token 的注意力计算需要访问所有历史 token 的 Key 和 Value:

$$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$

若不缓存历史的 KV,每步 decode 都需重新计算所有历史 KV,复杂度为 $O(L^2)$。

KV Cache 的内存占用(每个请求):

$$M_{\text{KV}} = 2 \cdot n_{\text{layers}} \cdot n_{\text{heads}} \cdot d_{\text{head}} \cdot L_{\text{seq}} \cdot \text{bytes/elem}$$

以 LLaMA-13B 为例(40 layers, 40 heads, head_dim=128, FP16):

$$M_{\text{KV}} = 2 \times 40 \times 40 \times 128 \times L_{\text{seq}} \times 2 = 819200 \times L_{\text{seq}} \text{ bytes}$$

对于长度为 4096 的序列,单请求 KV cache ≈ 3.2 GB,而 A100 只有 80 GB。这意味着大模型服务系统的 GPU 内存大部分被 KV cache 占用,而非模型权重本身。

2.2 传统系统的内存碎片问题

在 vLLM 之前的系统(如 FasterTransformer、Orca),每个请求在创建时预分配最大可能长度的连续内存块:

请求1: [KV_0, KV_1, KV_2, ... KV_2047, (空闲), (空闲)]  ← 预分配2048
请求2: [KV_0, KV_1, ..., KV_511, (空闲), ..., (空闲)] ← 预分配2048但只用512
↑ 内存碎片:75% 浪费

三种浪费

  1. 内部碎片:预分配最大长度,但实际生成长度不确定
  2. 外部碎片:不同请求结束后释放的内存块大小不一致,难以复用
  3. 保留内存:为了避免 OOM,系统提前保留大量”预防性”内存

这导致实际可服务的并发请求数远低于理论上限,吞吐量严重受损。

2.3 PagedAttention:操作系统分页思想的移植

核心洞察:将 OS 虚拟内存管理的分页(paging)思想应用于 KV cache 管理。

物理 Block:GPU 内存中固定大小的存储单元(通常 block_size = 16 tokens)

逻辑 Block:每个请求维护逻辑 block 序列,按需映射到物理 block

逻辑视图(请求1,生成中):
逻辑Block[0] → 物理Block[7] (tokens 0-15)
逻辑Block[1] → 物理Block[23] (tokens 16-31)
逻辑Block[2] → 物理Block[41] (tokens 32-47,进行中)

逻辑视图(请求2,已完成):
逻辑Block[0] → 物理Block[12] (tokens 0-15)
物理Block[12] 现在可以被新请求复用

注意力计算的修改:在 Attention kernel 中,通过 block table 查找每个 token 对应的物理地址:

# 伪代码,说明原理
for head in range(num_heads):
for block_idx in range(num_logical_blocks):
physical_block = block_table[request_id][block_idx]
k_block = K_cache[physical_block] # 非连续物理内存
v_block = V_cache[physical_block]
# 计算该 block 的注意力贡献
scores_block = Q @ k_block.T / sqrt(d_k)
# ... 累积 softmax 分数

Copy-on-Write for Beam Search:当多个 beam 共享相同前缀时,物理 block 被共享(引用计数),只在需要写入时才复制(写时复制),与 OS fork 的 CoW 机制完全类似。

2.4 PagedAttention 性能数据

Kwon et al. 的实验结果(arXiv:2309.06180,Table 1):

系统 OPT-13B 吞吐量 OPT-66B 吞吐量
FasterTransformer 0.54 req/s 0.17 req/s
Orca 0.96 req/s 0.32 req/s
vLLM (PagedAttention) 2.2 req/s 0.73 req/s

提升来源:内存碎片从约 60-80% 降低到约 4%,使 GPU 能够同时服务更多请求。

3. FlashAttention:IO 感知的注意力计算

3.1 标准 Attention 的内存瓶颈

论文:FlashAttention(Dao et al., 2022,arXiv:2205.14135);FlashAttention-2(Dao, 2023,arXiv:2307.08691)

标准自注意力的计算流程(朴素实现):

1. 计算 S = QK^T / sqrt(d_k)       形状: (L, L)   ← 写到 HBM
2. 计算 P = softmax(S) 形状: (L, L) ← 读+写 HBM
3. 计算 O = PV 形状: (L, d_v) ← 读 HBM

IO 复杂度分析

$$\text{HBM access}_{\text{naive}} = O(L^2 d + L^2) = O(L^2 d)$$

其中 $L$ 是序列长度,$d$ 是 head 维度。$L^2$ 的矩阵 $S$ 和 $P$ 必须在 HBM(高带宽内存,即 GPU DRAM)和 SRAM(片上内存,即 Shared Memory)之间反复传输。

GPU 内存层次结构

层级 大小(A100) 带宽
寄存器 ~20 MB 极高
SRAM (Shared Memory) 192 KB/SM ~19 TB/s
HBM (GPU DRAM) 80 GB ~2 TB/s

注意 SRAM 比 HBM 快约 10x,但容量小 3-4 个数量级。

3.2 FlashAttention 的核心技术

核心思想:通过 tiling(分块)将 $L \times L$ 的注意力矩阵分解,避免将完整的 $S$、$P$ 矩阵写入 HBM,全程在 SRAM 上完成计算。

在线 Softmax(Online Softmax):Softmax 看似需要全局归一化,无法分块。FlashAttention 使用了数值稳定的增量式 softmax:

设当前处理到 block $j$,已有当前最大值 $m_i$ 和部分和 $\ell_i$:

$$m_{i+1} = \max(m_i, \text{rowmax}(S_{i+1}))$$
$$\ell_{i+1} = e^{m_i - m_{i+1}} \cdot \ell_i + \text{rowsum}(e^{S_{i+1} - m_{i+1}})$$
$$O_{i+1} = \frac{e^{m_i - m_{i+1}} \cdot \ell_i \cdot O_i + e^{S_{i+1} - m_{i+1}} \cdot V_{i+1}}{\ell_{i+1}}$$

IO 复杂度(FlashAttention)

$$\text{HBM access}_{\text{flash}} = O\left(L^2 d^2 / M\right)$$

其中 $M$ 是 SRAM 大小。当 $M \gg d^2$ 时(实际情况),HBM 访问量从 $O(Ld + L^2)$ 降至 $O(L^2 d/M)$——对于 $d=64, M=100\text{KB}$,改善约 10-20x

Dao et al. (arXiv:2205.14135) 定理 2(精确表述):标准 attention 所需的 HBM reads/writes 为 $\Theta(Nd + N^2)$,而 FlashAttention 为 $\Theta(N^2 d^2 M^{-1})$,其中 $M$ 为 SRAM 大小,$d \leq M \leq Nd$。

3.3 FlashAttention-2 的改进

论文:Dao (2023,arXiv:2307.08691)

FA-2 在 FA-1 基础上的主要改进:

  1. 减少 non-matmul FLOP:GPU 的 TensorCore 对矩阵乘法(GEMM)有专门优化,非 GEMM 操作(rescaling、softmax 分量)的效率低约 10x。FA-2 重新调整循环顺序,减少 rescaling 操作次数。

  2. Q 的外层循环:FA-1 中外层循环遍历 KV blocks,FA-2 改为外层遍历 Q blocks,使每个 warp(线程束)负责独立的输出行,减少 warp 间的 reduce 通信。

  3. Causal Masking 优化:对于因果注意力,仅对对角线附近的 block 执行 masking,其他 block 跳过 mask 操作。

性能:FA-2 在 A100 上达到约 73% 的理论内存带宽利用率,FA-1 约为 25-40%,标准 PyTorch 实现约为 10-20%。

3.4 在量化交易中的含义

对于日内信号生成,研报/新闻的 context 长度往往在 4K-32K tokens。FlashAttention 使得在单张 GPU 上处理长文档的时间从分钟级压缩到秒级,这直接决定了策略能否在交易信号有效期内完成分析。

4. 推测解码 (Speculative Decoding)

4.1 核心问题:Decode 的串行性

论文:Leviathan et al., 2022,arXiv:2211.17192

自回归生成的根本瓶颈:每次 decode 步骤依赖前一步输出,无法并行。GPU 的大规模并行计算能力在 batch_size=1 时几乎浪费殆尽——大量计算单元闲置,只有内存带宽在被利用。

批量化(batching) 可以提高吞吐量,但对单个请求的延迟(TTFT,Time To First Token;TPOT,Time Per Output Token)没有帮助。

4.2 推测解码的机制

核心思想:用一个小型”草稿模型”(draft model,$M_q$)快速生成 $\gamma$ 个 token 草稿,再用目标大模型($M_p$)并行验证所有草稿 token。

算法流程

输入: 前缀序列 x_{1:t},目标模型 M_p,草稿模型 M_q,草稿长度 γ

Step 1: Draft(草稿阶段)
用 M_q 自回归生成 γ 个草稿 token:
x̃_{t+1}, x̃_{t+2}, ..., x̃_{t+γ} ← 使用 M_q 的采样分布 q(·|x_{1:t+i})

Step 2: Verify(验证阶段)
用 M_p 并行(一次前向传播)计算:
p(·|x_{1:t}), p(·|x_{1:t+1}), ..., p(·|x_{1:t+γ})
注意: 所有位置可以在一次 M_p 的前向传播中同时得到

Step 3: Accept/Reject(接受/拒绝)
for i = 1 to γ:
if rand() < min(1, p(x̃_{t+i}|x_{1:t+i-1}) / q(x̃_{t+i}|x_{1:t+i-1})):
接受 x̃_{t+i},继续检查下一个
else:
拒绝,从修正分布采样新 token,终止

如果所有 γ 个都接受,从 p(·|x_{1:t+γ}) 额外采样一个 token

关键性质(Leviathan et al. 定理):推测解码生成的分布精确等于目标模型 $M_p$ 的分布——这不是近似方法,是严格等价的采样。

数学证明核心:通过拒绝采样修正(rejection sampling correction),无论草稿模型质量如何,最终输出分布始终为 $p$。

4.3 加速比分析

设 $\alpha = \mathbb{E}[\text{接受率}]$(草稿 token 被接受的平均概率)。

每轮推测解码的期望接受 token 数:

$$\mathbb{E}[\text{tokens per round}] = \frac{1 - \alpha^{\gamma+1}}{1 - \alpha}$$

若草稿模型运行速度比目标模型快 $c$ 倍,总加速比约为:

$$\text{Speedup} \approx \frac{c(1-\alpha^{\gamma+1})}{(1-\alpha)(c + \gamma)}$$

实践数据(Leviathan et al., Table 1,T5-XXL as target):

  • 使用 T5-Small 作为草稿模型,$\gamma=4$
  • 文本生成任务:约 2.4x 加速
  • 代码生成任务:约 3.1x 加速(代码重复性高,接受率高)

为什么有效:目标大模型一次并行处理 $\gamma$ 个位置,与处理 1 个位置的计算时间几乎相同(都是内存带宽受限),因此”免费”验证了 $\gamma$ 个草稿。

4.4 DeepSeek 的实际应用

DeepSeek-V3 技术报告(arXiv:2412.19437)中提及使用推测解码进行部署优化。在 MoE 架构下,推测解码尤其有效:小草稿模型只需激活少量专家,运行极快,而大模型验证时虽然有更多专家,但并行处理 $\gamma$ 个 token 的时间增加有限。

量化交易场景评估:对于研报摘要生成(需要产出完整分析,token 数多),推测解码可将延迟降低 2-3x,使得原本需要 30 秒的分析压缩到 10-15 秒,对日内策略可能足够。

5. 量化技术对比

5.1 为什么需要模型量化?

量化(Quantization)将模型权重从高精度(FP32/FP16)转换为低精度整数(INT8/INT4),主要目标:

  1. 减小模型内存占用:FP16→INT4 节省 4x 内存
  2. 降低内存带宽需求:decode 是内存带宽瓶颈,4x 内存减少意味着接近 4x 的速度提升
  3. 在边缘设备上部署:Consumer GPU(24 GB VRAM)运行 70B 级模型

量化误差来源:将连续值映射到离散格点时不可避免地引入误差:

$$\hat{w} = \text{round}\left(\frac{w}{s}\right) \cdot s + z$$

其中 $s$ 是缩放因子(scale),$z$ 是零点(zero point)。

5.2 GPTQ:基于二阶信息的权重量化

论文:Frantar et al., 2022,arXiv:2210.17323

核心思想:将量化视为逐层优化问题——对每一层 weight 矩阵 $W$,寻找量化后的 $\hat{W}$ 使得层输出误差最小:

$$\arg\min_{\hat{W}} \|WX - \hat{W}X\|_F^2$$

其中 $X$ 是该层的输入激活(用小量校准数据计算)。

OBQ(Optimal Brain Quantization)框架:基于 OBS(Optimal Brain Surgeon,Hassibi & Stork, 1993)的思想,量化某一个权重时,通过 Hessian 矩阵补偿其他权重:

$$\delta w_{-q} = -\frac{w_q}{[H^{-1}]_{qq}} \cdot H^{-1}_{:,q}$$

即量化第 $q$ 个权重引入的误差可以通过调整其他权重来补偿。

GPTQ 的加速:OBQ 逐个量化权重,对于 GPT-175B 需要数天。GPTQ 的关键改进:

  • 对所有行同步量化同一列(而非逐个独立量化)
  • 使用 Cholesky 分解预计算 $H^{-1}$,避免每步重新求逆

性能(Frantar et al., Table 2):

  • OPT-175B 量化到 INT4,困惑度损失 < 0.5(相对于 FP16)
  • 量化时间:OPT-175B 约 4 GPU小时(A100),OBQ 原方法约 > 150 GPU小时

5.3 AWQ:激活感知的权重量化

论文:Lin et al., 2023,arXiv:2306.00978

核心洞察:不是所有权重对量化误差同等重要。对应大激活值的权重通道,量化误差对输出影响更大(因为激活值会放大权重误差)。

关键发现(AWQ 论文 Figure 2):只有约 0.1% - 1% 的权重通道是”显著”的(对应大激活值),对这些通道保持高精度(FP16)即可大幅降低量化误差。

实现方式:不直接混合精度(硬件不友好),而是通过等价变换将问题转化:

对于线性层 $y = Wx$,如果某个通道 $i$ 的激活值偏大,可以:

$$y = W \cdot x = (W \cdot \text{diag}(s)^{-1}) \cdot (\text{diag}(s) \cdot x)$$

通过缩放因子 $s_i > 1$ 放大权重通道 $i$,同时在输入激活中除以 $s_i$(等价变换)。放大后的权重通道在量化后相对误差更小,等效提高了重要通道的量化精度。

$s_i$ 的选取:通过最小化量化误差的网格搜索(grid search)确定:

$$s_i^* = \arg\min_{s_i} \mathcal{L}(s_i), \quad \mathcal{L}(s_i) = \left\|\text{Quant}(W \cdot \text{diag}(s)^{-1}) \cdot \text{diag}(s) \cdot X - WX\right\|$$

对比 GPTQ

维度 GPTQ AWQ
技术路线 基于 Hessian 的逐权重补偿 激活感知的缩放变换
校准数据量 约 128 samples 约 128 samples
量化速度 较慢(Cholesky 分解) 极快(只做缩放搜索)
INT4 精度 很好 接近 GPTQ,略有差异
硬件友好性 较好 更好(不改变量化格式)
适用场景 追求极致精度 快速部署,生产环境

5.4 INT8 vs INT4 的工程权衡

SmoothQuant(Xiao et al., 2022)提供了 W8A8(权重和激活都量化到 INT8)的方案,可使用 INT8 矩阵乘法硬件(A100 的 INT8 Tensor Core 吞吐是 FP16 的 2x)。

INT4 vs INT8 实用对比

项目 INT8 INT4
精度损失 通常可忽略 较明显(尤其小模型)
内存节省 2x(vs FP16) 4x
速度提升(decode) ~1.5-2x ~2.5-4x
硬件支持 广泛(NVIDIA INT8 TC) 需要特殊 kernel(llm.int4)
推荐场景 对精度要求高的金融分析 内存受限、延迟优先的信号生成

在量化交易中的选择

  • 研报摘要/情绪分析:INT8 或 AWQ INT4(精度优先)
  • 大规模批量处理历史数据:INT4(吞吐量优先)
  • 实时信号(秒级):AWQ INT4 + 推测解码组合

6. Continuous Batching vs Static Batching

6.1 Static Batching 的缺陷

论文参考:Orca(Yu et al., 2022),以及 vLLM 论文对比章节(arXiv:2309.06180)

Static Batching(静态批处理):

  • 将多个请求合并为一个批次,等待批次中最长序列完成才释放 GPU
  • 批次中短序列完成后,其占用的 GPU 计算在等待长序列时空转
时间线:
t=0: [req1(50tok), req2(200tok), req3(30tok)] ← batch 开始
t=30: req3 完成,但 GPU 继续等待
t=50: req1 完成,GPU 继续等待
t=200: req2 完成,batch 才结束
↑ req3 完成后浪费了 170 个 step 的 GPU 容量

问题:LLM 生成长度高度不确定(取决于内容),导致 GPU 利用率极低,平均可能不足 50%。

6.2 Continuous Batching(Iteration-Level Scheduling)

Orca(Yu et al., 2022) 的核心思想:在每个 decode 步骤(iteration)而非每个请求结束时做调度决策。

每完成一个 decode step,调度器检查:

  • 哪些请求已生成完成(遇到 EOS token)
  • 立即将完成的请求从 batch 中移除
  • 立即插入等待队列中的新请求
  • 下一个 decode step 就用新的 batch 组合
时间线(Continuous Batching):
step 1: [req1, req2, req3]
step 30: req3 完成 → 立即插入 req4
step 31: [req1, req2, req4]
step 50: req1 完成 → 立即插入 req5
step 51: [req2, req4, req5]
...
↑ GPU 始终满负荷运行

延迟 vs 吞吐量的权衡

指标 Static Batching Continuous Batching
吞吐量(req/s) 低(GPU 空转多) 高(接近理论上限)
单请求延迟 低(不受其他请求干扰) 略高(需要等调度窗口)
首 token 延迟(TTFT) 低(立即开始) 可能高(等待 batch slot)
适合场景 低并发、延迟敏感 高并发、吞吐量优先

6.3 Prefill-Decode 分离

更进一步的架构(DeepSeek 等大规模服务系统采用):将 prefill 和 decode 分离到不同的硬件实例。

原因

  • Prefill 是计算密集型(处理整个 prompt,算术强度高)
  • Decode 是内存带宽密集型(每步只生成一个 token,但要访问完整权重)
  • 两者对硬件特征的需求不同,混合在一起互相干扰

DeepSeek-V3 的推理优化(arXiv:2412.19437):采用专用的 prefill 集群和 decode 集群,通过高速网络传输 KV cache(”KV transfer”),使两阶段都能在各自最优硬件上运行。

7. LLM 在量化交易中的应用谱系

重要说明:本节严格区分”LLM 真正有用的场景”与”概念炒作”。所有应用评估基于已知的学术证据和工程约束。

7.1 金融 LLM 的发展

BloombergGPT(Wu et al., 2023,arXiv:2303.17564):

  • 在 Bloomberg 专有金融数据(363B tokens)+ 通用数据(345B tokens)上训练的 50B 参数模型
  • 在金融 NLP 基准(FiQA SA、PhraseBank 情绪分析、NER、问答)上显著优于同等规模的通用模型
  • 局限性:论文未提供量化交易 alpha 生成的直接证据;NLP 基准表现不等于交易 alpha

FinGPT(Yang et al., 2023,arXiv:2306.06031):

  • 开源金融 LLM,基于 LLaMA 等模型进行金融领域指令微调
  • 提供情绪分析、关系提取等能力
  • 定位:工具,而非端到端交易系统

评估:专业金融 LLM 在 NLP 任务上确实优于通用 LLM,但从”NLP 指标更好”到”产生正 alpha”仍有很大距离。

7.2 情绪因子与 LLM:真实有用

学术证据:多篇论文证实 LLM 情绪分析优于传统 NLP 方法(词典、VADER、FinBERT):

  • **Lopez-Lira & Tang (2023)**(发表于 SSRN,后被引用于多篇金融 ML 研究):使用 ChatGPT 分析 Twitter 新闻标题的情绪,发现 LLM 情绪分数与隔日股票收益有统计显著的预测关系,传统情绪分析方法则没有。
  • FinBERT(Araci, 2019):在金融文本情绪分类的早期基础工作,展示了领域微调的重要性。

为什么 LLM 情绪分析更好

  1. 理解否定、反讽等复杂语义(”不如预期”比词典方法理解更准确)
  2. 上下文敏感(同一个词在不同语境含义不同)
  3. 细粒度情绪(不只是 positive/negative,能区分”超预期上涨”vs”小幅好转”)

实用因子构建流程

原始数据: 新闻标题/研报摘要/财报电话会议记录

LLM 情绪打分: [公司, 日期, 情绪分数, 置信度, 情绪维度]

因子构建: rolling_z_score(情绪得分, window=20days)

因子验证: IC 分析, 多空分组回测

策略组合: 与其他因子加权合并

量化评估:IC(信息系数)一般在 0.02-0.06 范围,单独因子 IR 不高,但与价量因子组合后有显著改善(降低相关性,提高组合 Sharpe)。

7.3 研报解析与信息提取

真正有用的场景

  1. 关键数字提取:从非结构化研报中提取目标价、评级变化、业绩预测——这类任务 LLM 的精度远超规则系统。

  2. 事件分类:将新闻自动分类为”盈利超预期”、”管理层变动”、”监管风险”等有量化意义的事件类型,再针对不同事件类型使用不同的量化处理逻辑。

  3. 供应链关系图谱:从大量文本中提取公司间关系,构建知识图谱,用于估算上下游传导效应。

Retrieval-Augmented Generation (RAG) 在量化中的应用

将历史研报、财报、新闻构建向量数据库,使用 RAG 回答类似”历史上同类事件(美联储意外加息)后,银行板块的平均表现是什么?”的问题,辅助人工研究员决策。

局限性:LLM 会产生幻觉(hallucination)。在量化应用中,幻觉数字可能被误用为真实数据。必须有结构化验证层(与数据库比对),不能直接信任 LLM 输出的数值。

7.4 Chain-of-Thought 在金融推理中的应用

学术背景:Wei et al. (2022)(arXiv:2201.11903)展示 CoT 对复杂推理任务有显著提升。金融领域的应用研究处于初期阶段。

有潜力的场景

  • 财报分析:要求模型先列出关键财务指标变化,再分析驱动因素,最后给出综合判断——多步推理链比直接问”看多还是看空”更可靠。
  • 情景分析:”如果美联储加息 50bp 且中国 PMI 低于 50,对大宗商品的影响是…步骤 1…”

现实局限:CoT 生成更长,延迟更高;金融推理的”正确答案”难以验证(市场是最终裁判,但噪声极大);CoT 的置信度校准较差,可能给出看似有理实则错误的推理链。

结论:CoT 目前更适合辅助人工研究(作为分析工具),而非自动化交易信号生成。

7.5 另类数据处理

卫星图像 + LLM 描述:将卫星图像分析结果(停车场车辆数量、工厂烟囱活跃度)转化为自然语言,用 LLM 与宏观叙事结合分析。这是真实存在的商业应用(Second Measure, Orbital Insight 等公司提供数据)。

社交媒体监控:Reddit(WallStreetBets)、Twitter 等平台的散户情绪分析。存在严重的信噪比问题,且 alpha 容量极小(不适合大资金策略)。

专利/学术论文趋势分析:量化技术领先指标,但频率低(月度),适合中长期因子而非短期信号。

8. 量化交易 LLM 的核心约束

8.1 延迟约束:明确的边界

这是量化交易应用 LLM 最根本的约束。必须清醒认识:

策略类型 信号有效期 LLM 适用性 说明
高频做市(μs-ms) < 1ms 完全不可行 物理上不可能
统计套利(分钟级) 1-60min 不可行 即使量化也太慢
日内动量(小时级) 1-4h 勉强可行 需要极致优化,边际场景
事件驱动(小时-天) 数小时 可行 财报发布、重大新闻
因子构建(日频) 1 day 最佳适配 充裕时间预处理
宏观策略(周频+) 数周 完全适用 无延迟约束

技术现实:即使使用 INT4 量化 + FlashAttention + Continuous Batching,7B 模型处理一篇 2000 字研报的时间约为 5-15 秒(单张 A100),70B 模型约为 30-60 秒。这意味着 LLM 在量化交易中几乎只能应用于离线预处理延迟容忍度高的场景

8.2 可解释性约束

量化策略需要可解释性(归因分析、风险管理、监管合规),而 LLM 的决策过程是黑盒。

实用解决方案

  • 不用 LLM 直接输出交易信号,而是输出结构化中间特征(情绪分数、事件类型、关键数字),再用传统量化方法构建因子
  • 保留 LLM 的原始输出文本,作为审计日志
  • 对 LLM 特征做正交化处理,确保其对组合绩效的贡献可单独评估

8.3 Regime Change 问题

核心挑战:LLM 的训练数据有截止日期(knowledge cutoff),无法感知训练数据之后的市场制度变化(regime change)。

例如:2020-2021 年训练的 LLM 无法正确理解高通胀/快速加息环境对股票估值的影响,因为这种宏观环境在其训练数据中几乎不存在。

与传统量化的对比:传统因子(价量、基本面)只要有历史数据就能回测,LLM 知识截止带来的偏差难以量化。

缓解方案

  1. 持续微调(Continual Fine-tuning):定期用新数据更新模型,但成本高
  2. RAG(检索增强):实时检索最新信息注入上下文,缓解知识截止问题
  3. Feature Engineering 隔离:只用 LLM 处理文本特征,不让 LLM 做宏观判断

8.4 过拟合与前视偏差风险

特有问题:LLM 的训练数据可能包含金融市场历史数据(新闻描述历史涨跌),导致 LLM 生成的”分析”实际上是对历史结果的记忆而非真实预测能力。

缓解

  • 使用知识截止早于回测期的模型
  • 对 LLM 特征进行严格的 out-of-sample 验证
  • 避免使用包含价格信息的文本作为输入(”XX股昨日大涨 5%”这类信息会引入前视偏差)

8.5 成本约束

API 调用成本:处理大量历史研报需要大量 token 消耗。以 GPT-4o 的 API 价格为例,处理 100 万份研报(每份 2000 tokens)的成本约为数十万美元,对量化团队是显著成本。

自建推理集群:中大型量化机构通常选择自建 GPU 集群,部署开源 LLM(LLaMA、DeepSeek 等),这也是为什么推理优化技术对量化从业者如此重要——每降低 2x 的推理成本,就意味着能处理 2x 的数据量。

9. DeepSeek 量化岗面试重点问答

以下 10 题覆盖技术深度,代表专家级候选人应能回答的问题。

Q1:PagedAttention 的核心思想是什么?它解决了什么问题?为什么传统方法的内存利用率低?

A:传统 LLM 服务系统(如 FasterTransformer)对每个请求预分配最大可能序列长度的连续 KV cache 内存,导致三种浪费:内部碎片(实际生成长度不确定)、外部碎片(释放的不规则内存块难以复用)、保留内存(为防 OOM 的缓冲)。实测内存碎片率约 60-80%。

PagedAttention(vLLM,arXiv:2309.06180)将 OS 的虚拟内存分页思想移植到 KV cache 管理:物理 block 是固定大小(如 16 token)的 GPU 内存块,每个请求维护逻辑 block 到物理 block 的映射表(block table)。按需分配物理 block,block 内的内部碎片不超过一个 block 大小(最多 15 tokens × block_size 字节),内存利用率提升到约 96%。对于 Beam Search,多个 beam 通过 Copy-on-Write 共享物理 block,进一步减少内存占用。实验显示吞吐量比 Orca 提升约 2.3x(OPT-13B)。

Q2:FlashAttention 声称”IO 感知”,请说明标准 Attention 的 IO 瓶颈在哪,FlashAttention 如何改进,IO 复杂度分别是多少?

A:标准 Attention(朴素实现)需要将 $L \times L$ 的矩阵 $S = QK^T/\sqrt{d}$ 和 $P = \text{softmax}(S)$ 写入 HBM(GPU DRAM),再读出计算 $O = PV$。HBM 访问量为 $\Theta(L^2 + Ld)$。当 $L$ 很大时,$L^2$ 的矩阵 HBM 读写成为主要瓶颈,因为 HBM 带宽(2 TB/s)远低于片上 SRAM(19 TB/s),且 SRAM 容量(~192 KB/SM)无法容纳完整的 $L \times L$ 矩阵。

FlashAttention(arXiv:2205.14135)通过 tiling 将 $Q, K, V$ 分块,配合 online softmax 技术(增量式维护最大值 $m_i$ 和部分和 $\ell_i$),在 SRAM 内完成每个 tile 的完整计算,避免将 $S$、$P$ 写入 HBM。IO 复杂度降为 $\Theta(L^2 d^2 / M)$,其中 $M$ 是 SRAM 大小。对于 $d=64, M \approx 100\text{KB}$,改善约 10-20x。FA-2(arXiv:2307.08691)进一步通过将 Q 的遍历调整为外层循环、减少 non-matmul FLOP,在 A100 上达到约 73% 的内存带宽利用率。

Q3:推测解码(Speculative Decoding)的加速原理是什么?它的输出分布是否与目标模型完全一致?

A:推测解码(arXiv:2211.17192)的原理:用小草稿模型 $M_q$ 生成 $\gamma$ 个草稿 token(串行,但快速),然后用目标大模型 $M_p$ 一次并行前向传播验证所有 $\gamma$ 个位置。由于 decode 阶段是内存带宽瓶颈(不是计算瓶颈),$M_p$ 并行处理 $\gamma$ 个 token 与处理 1 个 token 耗时几乎相同——这就是”免费”加速的来源。

输出分布严格一致:通过拒绝采样机制,若草稿 token $x̃_i$ 被接受的概率为 $\min(1, p(x̃_i)/q(x̃_i))$,拒绝时从修正分布 $\text{normalize}(\max(0, p-q))$ 采样。可以证明最终生成分布精确等于 $p$(目标模型分布),而非近似。期望接受 token 数为 $(1-\alpha^{\gamma+1})/(1-\alpha)$,其中 $\alpha$ 是期望接受率。实践加速比约 2-4x,代码任务(重复性高)加速更显著。

Q4:GPTQ 和 AWQ 的核心方法论差异是什么?各自适合什么场景?

A:GPTQ(arXiv:2210.17323)基于二阶信息(Hessian 矩阵)。将量化视为层级优化问题:找 $\hat{W}$ 最小化 $|WX - \hat{W}X|F^2$。对每一列权重,利用 Hessian 信息计算量化该权重后的最优误差补偿 $\delta w = -w_q / [H^{-1}]{qq} \cdot H^{-1}_{:,q}$,即量化引入的误差通过其他权重调整来补偿。适合追求极致 INT4 精度、有充裕量化时间的场景。

AWQ(arXiv:2306.00978)基于激活感知的缩放。发现约 0.1-1% 的”显著”权重通道(对应大激活值)对量化误差贡献远超其比例,对这些通道做等价缩放变换 $W \cdot \text{diag}(s)^{-1} \cdot \text{diag}(s) \cdot x$,通过放大显著通道的权重值(使其相对量化误差更小),等效提高重要通道精度,且不改变量化格式,硬件友好。量化速度极快(分钟级 vs GPTQ 的小时级)。适合快速部署、生产环境。在 A100 上两者 INT4 困惑度相近,AWQ 在部署效率上更优。

Q5:Continuous Batching 相比 Static Batching 在吞吐量上的改进来源是什么?有什么代价?

A:Static Batching 在批次中最长序列完成前无法释放 GPU,短序列完成后 GPU 算力空转。由于 LLM 生成长度分布差异极大(几 token 到几千 token),批次中短请求完成后的等待时间可能占总时间 50-90%,GPU 利用率极低。

Continuous Batching(Orca,Yu et al., 2022)在每个 decode iteration 做调度决策:完成的请求立即从 batch 中移除,新请求立即插入。GPU 始终满负荷运行,吞吐量大幅提升。vLLM 结合 PagedAttention 和 Continuous Batching,实测吞吐量比传统系统高 3-5x。

代价:单个请求的 TTFT(首 token 延迟)可能增加,因为请求需等待 batch 有空闲 slot(不再是立即开始 prefill)。同时,迭代级调度的实现复杂度更高,需要处理 prefill 和 decode 混合在同一 iteration 的情况(会导致 prefill 请求受 decode 请求干扰,反之亦然)。更先进的系统(如 Sarathi、DeepSeek 的 disaggregated serving)通过 prefill-decode 分离解决此问题。

Q6:在量化交易场景中,LLM 情绪因子的学术证据是什么?如何构建可靠的情绪因子?

A:Lopez-Lira & Tang (2023) 是迄今最直接的学术证据:使用 ChatGPT 对 Twitter 新闻标题进行情绪分析,发现情绪分数与隔日个股收益有统计显著的预测关系(传统 VADER、词典方法则无显著性)。原因是 LLM 能理解否定、反讽、上下文,比传统 NLP 方法在金融语义理解上有质的飞跃。

可靠情绪因子构建关键点

  1. 数据源选择:财报电话会议记录(季度,低频但高质量)> 分析师研报 > 新闻标题 > 社交媒体(信噪比低)
  2. 避免前视偏差:确保信息时间戳严格早于使用该因子的交易时间
  3. 因子标准化:rolling z-score(20-60天窗口)消除行业 & 时序偏差
  4. 验证方法:IC 分析(信息系数,与下期收益的 rank 相关),分组回测(quintle 分析)
  5. 与传统因子的正交性检验:与 Barra 风险因子做正交化,确保捕捉增量信息

现实期望:情绪因子单独 IC 约 0.02-0.06,IR(信息比率)约 0.3-0.7,不够高但与其他因子相关性低,组合价值显著。

Q7:为什么 LLM 在高频交易中完全不可行?有没有可能的折中方案?

A:完全不可行的根本原因是物理约束,而非工程优化问题:

  1. 推理延迟下限:即使 INT4 量化 + FlashAttention + 专用硬件,7B 参数模型的 prefill 延迟约为 10-50ms(取决于 prompt 长度和 batch size),这比高频做市(1-10 μs)或统计套利(1-100ms)的信号有效期长几个数量级。
  2. 网络延迟:LLM 推理需要 GPU 服务器,而 HFT 要求信号生成在交易所网关附近(FPGA 上),物理距离本身就引入不可接受的延迟。
  3. 输出不确定性:LLM 是概率采样输出,同一输入可能产生不同结果,这对 HFT 策略的确定性要求不兼容。

折中方案:将 LLM 用于特征预计算(离线提前计算),在 HFT 系统中只查表使用预计算结果。例如:用 LLM 预先对已知上市公司生成”情绪向量”并缓存,HFT 系统实时查询最新情绪向量(μs 级),但向量本身是几分钟前更新的。这种方案的 alpha 非常有限,但工程上可行。

Q8:DeepSeek-V3 的推理系统有哪些关键设计?它如何在 MoE 架构下实现高效推理?

A:根据 DeepSeek-V3 技术报告(arXiv:2412.19437),关键推理优化包括:

  1. Prefill-Decode 分离(Disaggregated Serving):prefill(计算密集)和 decode(内存带宽密集)分离到不同 GPU 集群,通过高速网络传输 KV cache。两阶段各自在最适合的硬件上运行,避免互相干扰。

  2. MoE 特有的 Expert Parallel:不同 Expert 分布在不同设备,推理时只激活(并路由 token 到)相关 Expert,减少实际计算量。DeepSeek-V3 的 MoE 激活参数约为总参数的 1/8 左右,实际推理 FLOP 与同激活参数量的 Dense 模型相当。

  3. **Multi-head Latent Attention (MLA)**:DeepSeek-V2/V3 引入 MLA,通过低秩压缩 KV cache(将 KV 压缩到低维潜空间),KV cache 大小减少约 5-13x,支持更大 batch 或更长上下文。

  4. FP8 量化训练:V3 在训练阶段使用 FP8,推理阶段使用 FP8/INT8 混合,在精度损失可控的前提下实现约 2x 的内存和带宽改善。

Q9:RAG(检索增强生成)在量化交易中的真实价值和局限性是什么?

A真实价值

  • 缓解 Knowledge Cutoff:LLM 无法了解训练截止后的市场事件。RAG 通过实时检索最新研报/新闻注入上下文,使模型”知道”最新信息而无需重新训练。
  • 精确引用:RAG 可以检索并引用具体数据源,减少幻觉,提高输出可追溯性(重要的审计需求)。
  • 领域知识积累:将公司内部研报、历史分析报告构建向量数据库,LLM 可以”访问”大量内部知识。

局限性

  • 检索精度:相关度排名不总是准确,关键信息可能未被检索到(recall 问题)
  • 上下文窗口限制:即使检索到相关文档,塞入上下文窗口的数量有限,可能遗漏重要信息
  • 延迟增加:检索阶段(向量搜索)本身引入延迟(通常 50-200ms),对延迟敏感的场景是额外负担
  • 质量依赖数据库:如果向量数据库中的文档质量低、更新不及时,RAG 输出质量也会差

量化场景建议:RAG 最适合用于辅助研究员的分析工具(”帮我找过去类似市场环境下的分析报告”),而非端到端的自动化信号生成。

Q10:如果让你设计一个”LLM 辅助日内策略”的系统架构,如何平衡延迟、准确性和成本?

A:一个实际可行的架构:

离线层(T-1 天预处理)

  • 批量处理当日所有研报/财报/新闻,LLM 提取结构化特征(情绪分数、事件标签、关键指标)
  • 使用 INT4 量化 + Continuous Batching,最大化 GPU 利用率,降低单 token 成本
  • 构建向量数据库,索引所有历史文档

准实时层(T 日盘中,分钟级更新)

  • 监控数据源(新闻 feed、公告系统),新文档触发 LLM 分类(是否是重要事件)
  • 只对重要事件触发深度 LLM 分析(情绪打分、影响范围评估)
  • 目标延迟 30 秒内,使用 7B 量化模型 + FlashAttention
  • RAG 补充历史类似事件作为上下文

信号层(秒级)

  • 从上两层的结构化输出提取因子值,更新因子数据库
  • 传统量化模型(线性因子模型、ML 模型)实时读取因子,生成交易信号
  • 信号到执行仍是传统量化路径,LLM 不参与 < 1 秒的决策

成本控制

  • 优先使用自建 GPU 集群(DeepSeek、LLaMA 开源模型),避免 API 成本
  • 对重复性任务(情绪分类)使用小模型(7B);只对需要复杂推理的任务使用大模型(70B)
  • 使用推测解码降低大模型推理延迟 2-3x

评估框架

  • IC/IR 衡量信号质量
  • 回测时严格 out-of-sample,且使用模型知识截止前的数据
  • 实盘 paper trading 对比组,逐步增加资金配置

参考文献

论文 作者 年份 arXiv 主题
FlashAttention Dao et al. 2022 2205.14135 IO 感知注意力
FlashAttention-2 Dao 2023 2307.08691 注意力计算优化
vLLM/PagedAttention Kwon et al. 2023 2309.06180 KV Cache 管理
Speculative Decoding Leviathan et al. 2022 2211.17192 推测解码
GPTQ Frantar et al. 2022 2210.17323 权重量化(二阶)
AWQ Lin et al. 2023 2306.00978 激活感知量化
Orca Yu et al. 2022 Continuous Batching
BloombergGPT Wu et al. 2023 2303.17564 金融 LLM
FinGPT Yang et al. 2023 2306.06031 开源金融 LLM
Chain-of-Thought Wei et al. 2022 2201.11903 思维链推理
DeepSeek-V3 DeepSeek 2024 2412.19437 推理系统优化
DeepSeek-R1 DeepSeek 2025 2501.12948 推理模型训练

本文档基于真实已发表论文,所有技术细节可在对应 arXiv 论文中验证。量化交易部分的应用评估基于公开学术证据和工程约束分析,不包含任何具体交易策略建议。

10. 前沿推理优化:分离式架构与受限解码

10.1 Prefill-Decode 分离架构(Disaggregated Serving)

论文:Splitwise: Efficient Generative LLM Inference Using Phase Splitting(Patel et al., 2023)arXiv:2311.18677

特征 Prefill Decode
计算模式 Compute-bound Memory-bound
GPU 利用率 高(~70% MFU) 低(~5% MFU)
理想硬件 高 FLOPS GPU 高带宽 GPU

分离式架构将 Prefill 和 Decode 分配到不同 GPU 实例——Prefill 用高算力 GPU(H100),Decode 用高带宽 GPU。Prefill 完成后 KV Cache 通过网络传输到 Decode 实例。使两种工作负载都能用最适合的硬件配置。

10.2 前缀缓存(Prefix Caching)

当多个请求共享相同前缀(system prompt、few-shot 示例、对话历史),其 KV Cache 在前缀部分完全相同。

机制: 对前缀计算哈希 → KV Cache 存入共享缓存 → 新请求命中则跳过 Prefill,直接复用。vLLM 使用 Radix Tree 实现前缀缓存,插入和查找均为 $O(L)$。共享长 system prompt 的场景可减少 50-80% 的 Prefill 时间。

10.3 受限解码(Constrained Decoding)

确保模型生成的每个 token 符合特定语法或 schema,对代码生成、结构化数据提取至关重要。

Logit 掩码: 每步采样前将不符合约束的 token 的 logit 设为 $-\infty$,概率为零。需语法解析器实时跟踪当前状态。

Outlines / Guidance 框架: 将 JSON Schema 或正则表达式编译为确定性有限自动机(DFA),每步生成时查询 DFA 当前状态允许的 token 集合,仅从合法集合中采样——生成的文本保证符合目标 schema。

在量化交易中的意义:确保 LLM 输出的交易信号、金融数据严格符合预期格式,避免格式错误导致下游系统崩溃。

文章作者: Leo·Cheung
文章链接: http://tufusi.com/2025/06/30/LLM%E6%8E%A8%E7%90%86%E4%BC%98%E5%8C%96%E4%B8%8E%E9%87%8F%E5%8C%96%E4%BA%A4%E6%98%93%E5%BA%94%E7%94%A8/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 ONE·PIECE
打赏
  • 微信
  • 支付宝

评论