Sluke的夹生饭

欲生还熟

DSpark 底层采用"空间换时间"的设计，通过预测、并行执行、验证、回滚四个步骤，将串行 Token 生成转换为块级并行执行；在预测和验证阶段，利用 KV Cache 对 Transformer 的中间状态进行复用，实现增量计算，从而进一步提升执行速度。

以下是对 DSpark（及整个 Speculative Decoding 架构）的理解：

层次核心机制核心作用
第一层空间换时间 (Memory → Compute)增加缓存与中间状态存储，减少重复计算
第二层预测 + 并行 + 验证 + 回滚将串行生成转化为并行执行流
第三层KV Cache 复用支撑预测和验证阶段的高速增量计算

这三层共同作用，缺一不可。

第一层：空间换时间 (Space for Time)

这是整个系统设计的根本基石，究竟增加了哪些“空间”？

  • Draft Model（草稿模型）
  • Draft KV Cache（草稿缓存）
  • Target KV Cache（目标缓存）
  • Hidden State（隐藏状态）
  • Confidence State（置信度状态）

这些都是额外占用的 GPU Memory。而它们换来的是什么？

  • 更少的 Forward 调用
  • 更少的 Attention 计算
  • 更高的 Token/s 吞吐

因此，从系统设计的宏观视角来看，其逻辑链条十分清晰：

更多 Memory (空间)
    ↓
更少 Compute (计算)
    ↓
更低 Latency (延迟)

这就是典型的以空间换时间策略。

第二层：预测 + 并行 + 验证 + 回滚

真正让推理性能发生数量级跃迁的是这一层。

对比传统 Decoder 与 DSpark 的执行流差异：

传统 Decoder（串行的囚徒）：

Predict ──↓── Forward ──↓── Predict ──↓── Forward ...

每一步都等待上一步的结果，无法并行。

DSpark（并行的突围）：

Predict 8 Tokens
    ↓
一次 Parallel Verification
    ↓
Accept / Rollback（按需修正）

在此过程中，Forward 的次数发生了本质变化：

8 次 Serial
    ↓
缩减为 2 次 Batch

GPU 不再不断等待单个 Token 的产出，而是转为一次性处理整个 Token Block。这里的核心贡献在于：把串行依赖改造成块级（Block-level）的并行执行。

第三层：KV Cache 的角色定位

KV Cache 在整个流程中承担的是加速器的角色，而非并行机制本身。

以 Draft 模型预测一个序列 ABCDEFGH 为例：

如果没有 KV Cache：

A —— 重新算 Prompt
B —— 重新算 Prompt+A
C —— 重新算 Prompt+A+B

每一步都在空转过去的计算。

如果有 KV Cache：

Prompt ——→ KV
    ↓
A ——→ KV+
    ↓
B ——→ KV+

它解决的问题非常具体且关键：

每生成一个 Token，不需要重新计算前面的 Attention。

因此，它的加速范围是明确的：

  • Draft Prediction（草稿预测）
  • Target Verification（目标验证）

但它并不直接决定：

  • Prediction Accuracy（预测准确率）
  • Parallelism Capability（并行能力）

需要特别强调的是：
严格来说，KV Cache 加速的是“状态复用”，而不是“并行”本身。并行来自于 Speculative Decoding 的算法设计。即使完全没有 KV Cache，理论上仍然可以进行并行预测和验证，只是每一步都会重复计算 Attention，导致性能急剧下降。

超越 LLM：一种预测驱动的并行范式

结合近期对 Token Factory 的探索，我们可以将上述机制抽象为一种更通用的基础设施优化范式：

State (状态)
    ↓
Prediction (预测)
    ↓
Parallel Execution (并行执行)
    ↓
Verification (验证)
    ↓
Commit / Rollback (提交或回滚)

在这个通用框架下：

  1. State： 对应 KV Cache、Workspace、Business Memory、Ontology 等可复用的上下文状态。
  2. Prediction： 用于提前推测未来的执行路径或结果。
  3. Parallel Execution： 将原本线性的流程转换为块级并行处理。
  4. Verification： 保证最终结果与原始基准完全一致。
  5. Rollback： 处理预测失败的局部修正机制。

这套“预测驱动的并行执行”范式已经超出了 LLM 推理本身的范畴。CPU 的分支预测、数据库的事务执行、现代 AI 推理优化，甚至未来 Agent 的工作流编排，都可以归纳到这一套逻辑中，将业务流程中的“预测、验证、状态复用”构建为统一的优化模型。

标签：infra, ai

你的评论