llama.cpp 推理底座调优：从 KV Cache 到连续批处理的性能深潜

llama.cpp 推理底座调优：从 KV Cache 到连续批处理的性能深潜

一、大模型推理的吞吐瓶颈：不是算力不够，是调度不对

llama.cpp 作为轻量级 LLM 推理引擎，在单机部署场景下被广泛使用。但很多团队在部署后发现：单请求延迟尚可，并发吞吐却远低于预期。8 张 A100 的推理集群，QPS 只有个位数------GPU 利用率不到 30%，大量时间花在请求排队和内存拷贝上。

瓶颈不在计算，而在调度。LLM 推理的 Prefill 阶段是计算密集型（单次处理全部 Token），Decode 阶段是访存密集型（每次只生成 1 个 Token）。两种阶段的资源需求截然不同，如果调度器将它们混在一起执行，GPU 要么在 Prefill 时闲置显存带宽，要么在 Decode 时闲置计算单元。连续批处理（Continuous Batching）正是为了解决这个调度矛盾而设计的。

二、LLM 推理引擎的性能机制

2.1 Prefill 与 Decode 的资源特征

graph LR A[推理请求] --> B{阶段} B -->|Prefill| C[计算密集<br/>处理全部输入 Token] B -->|Decode| D[访存密集<br/>逐个生成输出 Token] C --> E[瓶颈：算力<br/>GPU 利用率 > 90%] D --> F[瓶颈：显存带宽<br/>GPU 利用率 < 30%] E --> G[需要：批量 Prefill<br/>合并计算] F --> H[需要：连续批处理<br/>合并访存]

2.2 KV Cache 的内存模型

KV Cache 是 LLM 推理中最大的内存消耗项。以 LLaMA-2-70B 为例，FP16 精度下模型权重约 140GB，而 2048 上下文长度的 KV Cache 每请求约需 5GB。8 个并发请求的 KV Cache 就达到 40GB，与模型权重争夺显存空间。

graph TD A[GPU 显存] --> B[模型权重<br/>~140GB FP16] A --> C[KV Cache<br/>~5GB/请求] A --> D[激活值缓冲<br/>~2GB] B --> E[静态分配<br/>启动时锁定] C --> F[动态分配<br/>随请求增减] D --> G[临时分配<br/>推理时使用] F --> H{显存不足时} H -->|策略1| I[拒绝新请求<br/>返回 429] H -->|策略2| J[驱逐低优先级请求<br/>释放 KV Cache] H -->|策略3| K[量化 KV Cache<br/>FP16→INT8]

2.3 连续批处理的调度流程

sequenceDiagram participant Q as 请求队列 participant S as 调度器 participant G as GPU Note over Q,G: 迭代 1 Q->>S: 请求 A (Prefill) Q->>S: 请求 B (Prefill) S->>G: 批量 Prefill [A, B] G-->>S: A→Decode, B→Decode Note over Q,G: 迭代 2 Q->>S: 请求 C (Prefill) S->>G: Continuous Batch [A:Decode, B:Decode, C:Prefill] G-->>S: A→Decode, B→完成, C→Decode Note over Q,G: 迭代 3 Q->>S: 请求 D (Prefill) S->>G: Continuous Batch [A:Decode, C:Decode, D:Prefill] G-->>S: A→完成, C→Decode, D→Decode

连续批处理的核心思想是：每个 Decode 迭代结束后，调度器检查是否有新请求可以加入。完成的请求立即移出，新请求立即加入，无需等待整个 Batch 完成。这与静态批处理（Static Batching）形成鲜明对比------静态批处理必须等所有请求完成后才能开始下一批。

三、llama.cpp 调优的生产级实践

3.1 KV Cache 量化与内存优化

// kv_cache_opt.c
// llama.cpp KV Cache 优化：INT8 量化减少显存占用
// 基于 ggml 的量化基础设施

#include "ggml.h"
#include <string.h>
#include <math.h>

// KV Cache 量化参数
typedef struct {
    float scale;     // 量化缩放因子
    int8_t zero_point;  // 量化零点
} kv_quant_params;

// 对 KV Cache 的 Key/Value 进行 INT8 对称量化
// 原理：将 FP16 的 K/V 向量量化为 INT8，减少 50% 显存占用
// 精度损失：PPL 上升约 0.1---0.3，在大多数场景下可接受
void quantize_kv_cache_row(
    const float* src,       // FP32 源数据
    int8_t* dst,            // INT8 目标数据
    int n_elements,         // 向量长度
    kv_quant_params* params // 输出：量化参数
) {
    // 第一步：计算绝对值最大值，确定量化范围
    float abs_max = 0.0f;
    for (int i = 0; i < n_elements; i++) {
        float val = fabsf(src[i]);
        if (val > abs_max) {
            abs_max = val;
        }
    }

    // 第二步：计算缩放因子
    // INT8 范围 [-127, 127]，缩放因子 = max / 127
    if (abs_max < 1e-6f) {
        // 全零向量，避免除零
        params->scale = 1.0f;
        params->zero_point = 0;
        memset(dst, 0, n_elements);
        return;
    }

    params->scale = abs_max / 127.0f;
    params->zero_point = 0;  // 对称量化，零点为 0

    // 第三步：量化
    const float inv_scale = 1.0f / params->scale;
    for (int i = 0; i < n_elements; i++) {
        float quantized = roundf(src[i] * inv_scale);
        // 裁剪到 INT8 范围
        if (quantized > 127.0f) quantized = 127.0f;
        if (quantized < -127.0f) quantized = -127.0f;
        dst[i] = (int8_t)quantized;
    }
}

// 反量化：INT8 -> FP32，用于注意力计算
void dequantize_kv_cache_row(
    const int8_t* src,          // INT8 源数据
    float* dst,                 // FP32 目标数据
    int n_elements,             // 向量长度
    const kv_quant_params* params // 量化参数
) {
    const float scale = params->scale;
    for (int i = 0; i < n_elements; i++) {
        dst[i] = (float)src[i] * scale;
    }
}

3.2 连续批处理调度器（Rust 实现）

// continuous_batching/src/scheduler.rs
// 连续批处理调度器
// 核心思路：每个 Decode 迭代后动态调整活跃请求集合

use std::collections::VecDeque;
use std::time::Instant;

/// 推理请求状态
#[derive(Debug, Clone, PartialEq)]
pub enum RequestState {
    /// Prefill 阶段：处理输入 Token
    Prefill { input_tokens: Vec<u32>, position: usize },
    /// Decode 阶段：逐个生成输出 Token
    Decode { generated_tokens: Vec<u32> },
    /// 已完成
    Completed,
}

/// 推理请求
pub struct InferenceRequest {
    pub id: u64,
    pub state: RequestState,
    pub max_tokens: usize,
    pub priority: u32,
    pub start_time: Instant,
}

/// 调度器配置
pub struct SchedulerConfig {
    /// 最大并发请求数（受显存限制）
    pub max_batch_size: usize,
    /// Prefill 的最大 Token 数（控制 Prefill 对 Decode 的干扰）
    pub max_prefill_tokens: usize,
    /// 单次 Decode 迭代的最大 Token 数
    pub max_decode_tokens: usize,
    /// KV Cache 总槽位数
    pub kv_cache_slots: usize,
}

/// 连续批处理调度器
pub struct ContinuousBatchScheduler {
    config: SchedulerConfig,
    /// 等待队列：尚未开始 Prefill 的请求
    waiting_queue: VecDeque<InferenceRequest>,
    /// 活跃集合：正在 Prefill 或 Decode 的请求
    active_set: Vec<InferenceRequest>,
    /// 已使用的 KV Cache 槽位数
    kv_cache_used: usize,
}

impl ContinuousBatchScheduler {
    pub fn new(config: SchedulerConfig) -> Self {
        Self {
            config,
            waiting_queue: VecDeque::new(),
            active_set: Vec::new(),
            kv_cache_used: 0,
        }
    }

    /// 添加新请求到等待队列
    pub fn enqueue(&mut self, request: InferenceRequest) {
        self.waiting_queue.push_back(request);
    }

    /// 调度一轮迭代：返回本轮需要执行的请求集合
    /// 核心逻辑：优先保证 Decode 请求的延迟，剩余资源分配给 Prefill
    pub fn schedule_iteration(&mut self) -> Vec<&mut InferenceRequest> {
        // 第一步：移除已完成的请求，释放 KV Cache
        let before_count = self.active_set.len();
        self.active_set.retain(|req| {
            let keep = req.state != RequestState::Completed;
            if !keep {
                // 释放该请求占用的 KV Cache
                self.kv_cache_used = self.kv_cache_used.saturating_sub(1);
            }
            keep
        });
        let completed = before_count - self.active_set.len();

        if completed > 0 {
            log::info!(
                "Completed {} requests, freed {} KV slots",
                completed, completed
            );
        }

        // 第二步：从等待队列中填充新请求
        while self.active_set.len() < self.config.max_batch_size
            && self.kv_cache_used < self.config.kv_cache_slots
        {
            if let Some(req) = self.waiting_queue.pop_front() {
                self.kv_cache_used += 1;
                self.active_set.push(req);
            } else {
                break;
            }
        }

        // 第三步：按优先级排序
        // Decode 请求优先于 Prefill 请求，确保生成延迟稳定
        self.active_set.sort_by(|a, b| {
            let a_is_decode = matches!(a.state, RequestState::Decode { .. });
            let b_is_decode = matches!(b.state, RequestState::Decode { .. });
            // Decode 优先
            match (a_is_decode, b_is_decode) {
                (true, false) => std::cmp::Ordering::Less,
                (false, true) => std::cmp::Ordering::Greater,
                _ => b.priority.cmp(&a.priority),
            }
        });

        // 返回活跃请求的可变引用
        self.active_set.iter_mut().collect()
    }

    /// 获取当前调度状态统计
    pub fn stats(&self) -> SchedulerStats {
        let prefill_count = self.active_set.iter()
            .filter(|r| matches!(r.state, RequestState::Prefill { .. }))
            .count();
        let decode_count = self.active_set.iter()
            .filter(|r| matches!(r.state, RequestState::Decode { .. }))
            .count();

        SchedulerStats {
            waiting: self.waiting_queue.len(),
            active_prefill: prefill_count,
            active_decode: decode_count,
            kv_cache_used: self.kv_cache_used,
            kv_cache_total: self.config.kv_cache_slots,
        }
    }
}

#[derive(Debug)]
pub struct SchedulerStats {
    pub waiting: usize,
    pub active_prefill: usize,
    pub active_decode: usize,
    pub kv_cache_used: usize,
    pub kv_cache_total: usize,
}

3.3 llama.cpp 推理参数调优配置

#!/bin/bash
# llama_cpp_server.sh
# llama.cpp 推理服务启动脚本，含关键调优参数

MODEL_PATH="/models/llama-2-70b-chat.Q4_K_M.gguf"

# 核心调优参数说明：
# -ngl 40:        GPU 层数（40 层全部卸载到 GPU）
# -c 4096:        上下文长度（影响 KV Cache 大小）
# -b 512:         批处理大小（Prefill 阶段一次处理的 Token 数）
# -ub 128:        微批大小（将大 Batch 拆分为小 Batch，减少 Prefill 对 Decode 的干扰）
# -np 4:          并行槽位数（同时处理的请求数）
# -ctk q8_0:      KV Cache Key 量化类型（INT8，减少 50% 显存）
# -ctv q8_0:      KV Cache Value 量化类型（INT8）
# -t 8:           线程数（匹配物理核心数）
# -sm row:        张量并行策略（按行切分，适合多 GPU）

./llama-server \
    -m "${MODEL_PATH}" \
    -ngl 40 \
    -c 4096 \
    -b 512 \
    -ub 128 \
    -np 4 \
    -ctk q8_0 \
    -ctv q8_0 \
    -t 8 \
    --port 8080 \
    --host 0.0.0.0

# 性能基准参考（A100 80GB × 2, LLaMA-2-70B Q4_K_M）：
# 单请求延迟：  Prefill ~800ms, Decode ~50ms/token
# 并发吞吐：    ~4 req/s (2048 context, 256 output tokens)
# 显存占用：    ~45GB (模型) + ~8GB (KV Cache, 4 并发, INT8)
# GPU 利用率：  ~70% (连续批处理) vs ~30% (单请求串行)

四、推理引擎调优的架构权衡

4.1 KV Cache 量化的精度代价

INT8 量化将 KV Cache 的显存占用减半，但引入了量化误差。在长上下文（> 4096 Token）场景下，量化误差会随注意力层数累积，导致 PPL 上升 0.2---0.5。对于代码生成和数学推理等精度敏感任务，建议保留 FP16 KV Cache；对于对话和摘要生成等容忍度较高的场景，INT8 量化是性价比最优的选择。

4.2 Prefill 与 Decode 的资源竞争

连续批处理中，Prefill 和 Decode 共享 GPU 资源。一个大的 Prefill 请求（如 2048 Token 的长输入）会占用大量计算单元，导致同时运行的 Decode 请求延迟飙升。-ub（micro-batch）参数将 Prefill 拆分为多个小批次执行，每个小批次之间插入 Decode 迭代，从而控制 Prefill 对 Decode 延迟的影响。代价是 Prefill 本身的耗时略有增加（约 10%---15%）。

4.3 多 GPU 并行的通信开销

张量并行（Tensor Parallelism）将模型按层切分到多张 GPU 上，每层的前向传播需要一次 AllReduce 通信。在 2×A100 配置下，单次 AllReduce 的延迟约 50---100μs，对于 70B 模型的 80 层结构，通信总延迟约 4---8ms，占单次 Decode 迭代的 8%---15%。当 GPU 数量超过 4 时，通信开销可能超过计算收益，此时应考虑流水线并行替代。

五、总结

llama.cpp 推理调优的核心在于理解 Prefill 与 Decode 的资源特征差异，并通过连续批处理实现两种阶段的协同调度。KV Cache 量化是最直接的显存优化手段，INT8 量化在大多数场景下精度损失可控；微批次拆分（micro-batch）是平衡 Prefill 与 Decode 延迟的关键参数，需要根据实际负载调整。

落地路径：先用默认参数跑通推理，建立单请求延迟基线；再开启连续批处理和 KV Cache 量化，测量并发吞吐提升；最后根据 GPU 利用率曲线微调 -b、-ub、-np 参数，找到延迟与吞吐的最优平衡点。每次调参后用标准 Benchmark（如 ShareGPT 数据集）验证，避免主观判断。