Coolseek AI Lab - 探索智能，酷在前沿

"模型在思考"——这句话背后，究竟发生了什么？

理解LLM的推理过程，不只是技术好奇心的满足，更是优化AI应用性能、控制成本的必要基础。

一、什么是 Token？

在深入推理过程之前，必须先理解模型的"原子单位"——Token。

Token 的本质

Token 是LLM处理文本的最小单元，不等同于字符或单词：

文本：  "Hello, world!"
Token： ["Hello", ",", " world", "!"]  →  [15496, 11, 995, 0]

文本：  "人工智能"
Token： ["人", "工", "智", "能"]  →  [人工, 智能]  （取决于词表）

Token 与字符的对应关系（近似）：

英文：1 token ≈ 4 个字符 ≈ 0.75 个单词

中文：1 token ≈ 1-2 个汉字

代码：通常比自然语言消耗更多 token

上下文窗口（Context Window）

模型单次处理的最大 token 数。超出则需要截断或滑窗处理：

模型	上下文窗口
GPT-3	4,096
GPT-4 Turbo	128,000
Claude 3.7	200,000
Gemini 1.5 Pro	1,000,000

二、推理全流程

输入阶段（Prefill / Encoding）

用户输入文本
    ↓ Tokenizer（分词）
Token ID 序列：[15496, 11, 995, 0, ...]
    ↓ 输入到 Transformer
所有 token 并行处理（可完全并行化）
    ↓ 计算并缓存所有层的 KV（Key-Value）值
Prefill 完成 → 生成第一个输出 token

Prefill 阶段是计算密集型（Compute-bound）：所有输入 token 同时处理，GPU 利用率接近峰值。

生成阶段（Decode / Autoregressive Generation）

第一个输出 token（如 "The"）
    ↓ 追加到序列末尾
    ↓ 再次输入模型（但新 token 只需做一步推理）
    ↓ 利用 KV Cache 避免重复计算
第二个输出 token（如 " answer"）
    ↓ 循环直到遇到 <EOS> 或达到最大长度
完整输出序列

Decode 阶段是内存带宽密集型（Memory-bound）：每次只生成一个 token，GPU 利用率较低，是推理性能的主要瓶颈。

三、KV Cache：推理性能的核心

为什么需要 KV Cache？

自注意力机制在处理 token t 时，需要与所有前序 token 做注意力计算：

Attention(Q_t, K_{1..t}, V_{1..t})

如果没有缓存，每生成一个新 token，都要重新计算前面所有 token 的 K 和 V，计算量随序列长度平方增长。

KV Cache 的解决方案：将历史 token 的 K、V 矩阵缓存在内存（显存）中，新 token 只需计算自己的 K、V 并追加。

第1步：处理 token [A, B, C]
  → 缓存 K[A], V[A], K[B], V[B], K[C], V[C]
  → 生成 token D

第2步：处理新 token [D]
  → 复用缓存的 K[A..C], V[A..C]
  → 只新增计算 K[D], V[D]
  → 生成 token E

计算量：O(n) 而非 O(n²)  ✓

KV Cache 的内存开销

这是大模型推理中内存占用最大的部分之一：

KV Cache 大小 = 2 × num_layers × num_kv_heads × head_dim × seq_len × batch_size × dtype_bytes

以 LLaMA 3 70B 为例（BF16，seq_len=4096，batch=1）：
= 2 × 80 × 8 × 128 × 4096 × 1 × 2 bytes
≈ 42 GB

这解释了为什么长上下文推理对显存的需求远超模型本身。

缓存命中（Cache Hit）与前缀缓存

前缀缓存（Prefix Caching / Prompt Caching） 是一个重要优化：

当多个请求共享相同的前缀（如相同的 System Prompt），可以复用已计算的 KV Cache：

[System Prompt: "你是一个专业的AI助手..."]   ← 所有请求共用，只计算一次
[用户A: "解释量子纠缠"]                      ← 追加计算
[用户B: "什么是Transformer"]                 ← 追加计算

缓存命中率（Cache Hit Rate） 直接影响推理成本：

高命中率 → 显著减少计算量 → 降低延迟、降低费用

Anthropic Claude API 的 Prompt Caching 可将缓存部分的成本降低 90%

四、解码策略

模型输出的是每个 token 的概率分布，如何从中选择？

贪心解码（Greedy Decoding）

每次选择概率最高的 token
优点：确定性、快速
缺点：容易陷入重复，创造性不足

温度采样（Temperature Sampling）

P'(token) = softmax(logits / T)

T = 0.0 → 等同贪心（选最高概率）
T = 1.0 → 原始概率分布
T > 1.0 → 更随机、更有创造性
T < 1.0 → 更保守、更集中

Top-p 采样（Nucleus Sampling）

只从累积概率达到 p 的最小 token 集合中采样
top_p = 0.9：选择概率之和恰好超过 90% 的最小 token 集

Top-k 采样

只从概率最高的 k 个 token 中采样。

在实际应用中，通常将 Temperature + Top-p 组合使用，CreativeWrite 场景用高温度，精确问答用低温度。

五、推理性能关键指标

指标	定义	典型值
TTFT	Time to First Token，首个token延迟	0.3-2s
TPS / TGS	Tokens per Second，生成速度	30-150 TPS
Throughput	单位时间总token产出（多并发）	取决于批次大小
Latency	完整响应时间	2-30s

六、推理优化技术

连续批量处理（Continuous Batching）

传统批处理需等最长请求完成才能释放资源。连续批处理（vLLM 的核心技术）允许动态插入新请求，GPU 利用率从 30% 提升至 70%+。

PagedAttention

受操作系统分页内存管理启发，vLLM 将 KV Cache 切分为固定大小的"页"，按需分配，消除内存碎片，大幅提升并发能力。

量化（Quantization）

将模型参数从高精度（FP16/BF16）转为低精度（INT8/INT4），减少内存占用和带宽需求：

量化方式	显存节省	精度损失	代表工具
INT8	~50%	极低	bitsandbytes, GPTQ
INT4	~75%	低-中	GGUF/llama.cpp, AWQ
FP4	~87.5%	中	NF4, GGUF Q4_K_M

投机采样（Speculative Decoding）

用小模型（Draft Model） 快速生成候选 token 序列，再用大模型（Target Model） 并行验证，被接受的 token 直接使用：

小模型快速生成：["The", " answer", " is", " 42"]
大模型并行验证：["The"✓, " answer"✓, " is"✓, " 42"✓]
输出4个token，只花了约1次大模型推理的时间

提速幅度通常在 1.5x-3x，在输出高度可预测的场景下效果更显著。

Flash Decoding

针对解码阶段的注意力计算优化，通过并行化序列维度的 softmax 计算，在长上下文场景下显著提升解码速度。

七、推理基础设施

工具/框架	特点	适用场景
vLLM	PagedAttention, 高吞吐	生产部署首选
llama.cpp	CPU/边缘推理, GGUF量化	本地部署
TensorRT-LLM	NVIDIA官方, 极致性能	企业级NVIDIA部署
Ollama	易用性第一, 本地运行	开发者体验
SGLang	高效Prefill+结构化输出	复杂Agent场景

总结

LLM 推理的核心是自回归 token 生成 + KV Cache 加速。理解 KV Cache 的机制和成本，是优化 LLM 应用性能的关键。随着上下文窗口不断扩展，内存管理和缓存命中率将越来越成为系统设计的核心议题。

探索智能，酷在前沿