大模型推理加速实战：从延迟瓶颈到吞吐量优化的调优路径

一、推理延迟对业务的影响

在线推理场景中，延迟直接影响用户体验。一个70B参数的大模型，单次推理延迟可能达到数秒。用户无法忍受高延迟，业务也难以承受。在一次线上压测中，P99延迟从800ms飙升至12s，导致服务熔断。这次经历让我认识到，模型训练效果再好，推理性能跟不上也无法落地。

推理性能主要受三个指标影响：首字延迟（TTFT）、生成吞吐量（Tokens/s）和显存利用率。这三个指标相互制约，调优过程就是在约束条件下寻找最优解。这不是理论推导，而是需要实际验证的工程问题。

二、推理加速的核心机制

大模型推理采用自回归解码方式。每生成一个Token，都需要将完整的KV Cache与当前Token进行注意力计算。随着序列长度增加，计算量和显存占用都会显著增长。

graph TD
    A[请求输入] --> B[Tokenize & Embedding]
    B --> C[Prefill 阶段: 并行处理所有输入Token]
    C --> D[生成 KV Cache]
    D --> E[Decode 阶段: 逐Token自回归生成]
    E --> F{是否达到终止条件?}
    F -->|否| G[更新 KV Cache]
    G --> E
    F -->|是| H[返回推理结果]

这个流程包含两个关键阶段。Prefill阶段是计算密集型任务，能够充分利用GPU并行计算能力。Decode阶段则是访存密集型任务，每次只处理一个Token，导致GPU算力大量闲置。因此，推理加速的核心在于解决Decode阶段的显存带宽瓶颈问题。

KV Cache的显存占用公式为：2 × num_layers × seq_len × hidden_dim × dtype_size。以LLaMA-70B为例，4096序列长度的KV Cache需要约16GB显存。这直接限制了单卡能够承载的并发请求数量。

三、生产级推理加速方案与代码实践

3.1 Continuous Batching：提升吞吐量

Static Batching会因为等待最慢请求而浪费资源。Continuous Batching允许请求按粒度动态进出，显著提高GPU利用率。

import torch
from typing import List

class ContinuousBatchScheduler:
    """连续批调度器：以Token粒度管理请求生命周期"""

    def __init__(self, max_batch_size: int, max_tokens_per_batch: int):
        self.max_batch_size = max_batch_size
        self.max_tokens_per_batch = max_tokens_per_batch
        self.active_requests: List[dict] = []

    def can_add_request(self, new_seq_len: int) -> bool:
        """判断是否还能接纳新请求"""
        if len(self.active_requests) >= self.max_batch_size:
            return False
        current_tokens = sum(req["current_len"] for req in self.active_requests)
        return (current_tokens + new_seq_len) <= self.max_tokens_per_batch

    def schedule_step(self) -> List[dict]:
        """执行调度步骤，移除已完成请求"""
        self.active_requests = [
            req for req in self.active_requests
            if not req.get("finished", False)
        ]
        return self.active_requests

    def add_request(self, request_id: str, input_ids: torch.Tensor) -> bool:
        """添加新请求到调度队列"""
        seq_len = input_ids.shape[-1]
        if not self.can_add_request(seq_len):
            return False
        self.active_requests.append({
            "request_id": request_id,
            "input_ids": input_ids,
            "current_len": seq_len,
            "finished": False,
        })
        return True

3.2 KV Cache 优化：PagedAttention 实践

PagedAttention借鉴操作系统虚拟内存的分页思想，将KV Cache切分为固定大小的Block进行按需分配。这种方法解决了显存碎片化问题，将显存利用率从60%提升到95%以上。

class PagedKVCacheManager:
    """分页KV Cache管理器：以Block为粒度管理显存"""

    BLOCK_SIZE = 16

    def __init__(self, num_blocks: int, block_size: int = 16):
        self.block_size = block_size
        self.free_blocks: List[int] = list(range(num_blocks))
        self.request_blocks: dict = {}

    def allocate(self, request_id: str, num_tokens: int) -> List[int]:
        """为请求分配Block"""
        num_needed = (num_tokens + self.block_size - 1) // self.block_size
        if len(self.free_blocks) < num_needed:
            raise RuntimeError(
                f"显存不足: 需要{num_needed}个Block, 仅剩{len(self.free_blocks)}个"
            )
        allocated = self.free_blocks[:num_needed]
        self.free_blocks = self.free_blocks[num_needed:]
        self.request_blocks[request_id] = allocated
        return allocated

    def release(self, request_id: str) -> None:
        """释放请求占用的Block"""
        if request_id in self.request_blocks:
            self.free_blocks.extend(self.request_blocks.pop(request_id))

3.3 Speculative Decoding：小模型辅助大模型

核心思路是用小模型快速生成候选Token，大模型并行验证。猜测正确则直接采用，错误则回退，整体开销很小。

import torch
import torch.nn.functional as F

def speculative_decode_step(
    draft_model,
    target_model,
    input_ids: torch.Tensor,
    num_spec_tokens: int = 5,
    temperature: float = 1.0,
) -> torch.Tensor:
    """投机解码单步：小模型猜测 + 大模型验证"""
    draft_tokens = []
    current_ids = input_ids
    for _ in range(num_spec_tokens):
        logits = draft_model(current_ids).logits[:, -1, :]
        next_token = torch.argmax(logits, dim=-1, keepdim=True)
        draft_tokens.append(next_token)
        current_ids = torch.cat([current_ids, next_token], dim=-1)

    target_logits = target_model(current_ids).logits

    accepted = 0
    for i in range(num_spec_tokens):
        draft_prob = F.softmax(
            draft_model(input_ids).logits[:, -1, :], dim=-1
        ).gather(1, draft_tokens[i])
        target_prob = F.softmax(
            target_logits[:, input_ids.shape[-1] + i - 1, :], dim=-1
        ).gather(1, draft_tokens[i])
        accept_prob = torch.min(
            torch.ones_like(target_prob),
            target_prob / (draft_prob + 1e-10)
        )
        if torch.rand(1, device=accept_prob.device) < accept_prob:
            accepted += 1
        else:
            break

    accepted_tokens = torch.cat(draft_tokens[:accepted], dim=-1)
    corrected_token = torch.argmax(
        target_logits[:, input_ids.shape[-1] + accepted - 1, :], dim=-1
    ).unsqueeze(-1)
    return torch.cat([accepted_tokens, corrected_token], dim=-1)

四、方案选型的边界与权衡

每种加速方案都有其适用场景，不存在通用解决方案。

Continuous Batching 增加了调度复杂度。请求的动态进出要求KV Cache管理支持非连续存储，否则显存碎片会抵消收益。当请求长度差异较大时，短请求释放的Block可能无法被长请求有效复用，需要调整PagedAttention的Block Size。

Speculative Decoding 的效果取决于草稿模型与目标模型的分布匹配程度。如果小模型猜测的接受率低于60%，反而会增加推理时间。实测数据显示，7B模型为70B模型做草稿时，接受率约75%，加速比约2.1x；而1B模型为70B做草稿时，接受率仅50%，加速比不足1.3x。选择草稿模型需要平衡速度和准确性。

量化 是另一种优化方向。INT8量化通常带来1.5-2x的吞吐提升，但在敏感任务中精度损失需要谨慎评估。建议先进行基准测试，如果量化后精度下降超过2%，需要考虑混合精度方案，对关键层保留FP16。

五、总结

推理加速需要综合运用多种技术。Continuous Batching优化并发调度，PagedAttention改进显存管理，Speculative Decoding降低单请求延迟，量化提升计算密度。实际生产中，这些方案通常需要组合使用，但组合方式和参数调优直接影响最终效果。

我的实践顺序是：先通过量化建立基础性能，再部署Continuous Batching提升并发能力，最后使用Speculative Decoding进一步优化延迟。每一步都需要通过基准测试验证效果，用数据指导决策。性能优化是一个持续迭代的过程，需要不断逼近硬件极限。