bug404

bug404

cv、深度学习、模型部署

llama.cpp 服务端揭秘：连续批处理与请求调度

1 minute read

Published:

背景与目标

在生产环境中部署大语言模型（LLM）推理服务时，一个核心挑战是如何在有限的 GPU 或 CPU 资源下同时服务大量并发请求。传统的“静态批处理”要求等待凑齐一批请求后才调用模型前向计算，这在高并发时会造成头部阻塞（head-of-line blocking），严重拖慢延迟敏感的应用。近年来，以 vLLM 为代表的“连续批处理”（continuous batching）技术通过动态维护请求槽位（slot）、即时加入新请求并淘汰已完成请求，显著提升了吞吐和响应速度。llama.cpp 的服务器组件 llama-server 同样需要应对这一场景，其设计目标是在 C/C++ 栈上实现轻量、高性能的连续批处理与调度，同时保持与多种硬件后端的兼容性。本文将深入其源码，解析请求调度、动态批处理和并发管理的底层实现，重点关注内存布局、原子操作及缓存复用等工程细节。

核心设计与实现

整体架构与主循环

llama-server 将 HTTP 收发与模型推理严格解耦。在 tools/server/server.cpp 中，主函数完成参数解析后，创建两个核心对象：server_http_context 负责网络 I/O，server_context 负责推理与批处理（文件:91-93）。后者通过 load_model 加载模型，然后调用 start_loop 进入阻塞的推理主循环，期间不断从任务队列取出请求、组织批次并执行前向计算。这种设计使得 HTTP 线程可以完全无锁地接收请求，而推理线程则能专注于密集计算，避免上下文切换开销。

所有 HTTP 路由处理器都经过 ex_wrapper 统一包裹（server.cpp:29-50），将 C++ 异常转换为结构化的 JSON 错误响应，避免任何一个请求的异常导致服务器线程崩溃。虽然这与批处理无直接关系，但为高并发下的稳定性奠定了基础。

并发请求的承载：n_parallel 与统一 KV 缓存

服务器需要同时服务多个请求，每个请求对应一个生成序列。llama-server 通过 n_parallel 参数控制最大并行序列数。在 server.cpp:79-83 中，若用户未显式设置（负值），代码会自动将其设为 4 并启用统一 KV 缓存（kv_unified = true）：

// tools/server/server.cpp:79-83
if (params.n_parallel < 0) {
    SRV_TRC("n_parallel is set to auto, using n_parallel = 4 and kv_unified = true\n");
    params.n_parallel = 4;
    params.kv_unified = true;
}

这意味着在缺省情况下，服务器可以同时处理 4 个并发生成。kv_unified 标志直接影响底层 KV 缓存的内存组织方式。该设计使新手部署时无需调参即可获得基本并发能力，虽然硬编码的 4 可能并非所有硬件的最优值，但避免了额外的配置负担。

多流 KV 缓存：序列隔离与零拷贝

KV 缓存是批处理的核心数据结构。在 src/llama-kv-cache.cpp 的构造函数中，K 和 V 张量被分配为三维张量，第一维即“流”（stream）维度，对应不同的序列（文件：构造函数 3D tensor allocation）：

// src/llama-kv-cache.cpp（构造函数简化）
// K and V 张量为形状 [n_stream, n_kv_head, head_dim] 或类似布局
// 当 kv_unified 为 false 时，每个序列分配一个独立的 stream，即完整的 KV 缓存副本。
// 当 kv_unified 为 true 时，多个序列可共享同一个 stream，
// 但此时需要额外的偏移计算来定位各自的缓存段。

每个序列拥有自己的 KV 缓存流，操作（如 seq_cp 复制序列状态）通过后端张量拷贝实现，避免了数据手动搬运。统一缓存则通过共享底层内存区域加上偏移量实现，减少了多请求下的总内存占用，但需要更精细的分配与回收策略。

序列的槽位分配由 find_slot 函数完成。它结合滑动窗口注意力（SWA）特性，检查某个单元是否处于当前注意力窗口之外；如果是，则可视为空闲并被回收。这种 SWA 感知的槽位复用实现了一种隐式的 LRU 淘汰策略（src/llama-kv-cache.cpp:find_slot SWA check），在有限的 KV 缓存容量下支持理论上无限的上下文长度。

动态批处理的工作流

尽管 server_context 的具体调度算法并未在本系列的模块分析中展开（其实现位于 server-context.cpp），但从其对外接口和配套的数据结构可推断出典型的连续批处理流程：

  1. 请求入队：HTTP 处理器将新到达的生成请求封装为 task，并加入推理线程可见的任务队列。
  2. 分批：start_loop 的每次迭代会收集所有待处理的 task，将它们与当前活跃的 slot 合并，形成一个批次。新请求会分配空闲 slot（通过 find_slot），而不再需要继续的请求（如遇到终止符）立即释放槽位。
  3. 推理：调用 llama_decode 或 llama_eval 处理整个批次。底层计算图利用多流 KV 缓存，将不同序列的查询、键值计算融合到一次前向传递中，充分利用 GPU 的张量核心或 CPU 的 SIMD。
  4. 采样与后处理：对批次中每个序列生成下一个 token，并更新 KV 缓存位置。若某序列结束，通知 HTTP 线程返回结果。

这种“动态”特性体现在：请求可以在任意时刻加入或离开，无需等待固定批量大小。批次的大小随并发请求数自然波动，既避免了静态批处理的启动延迟，又维持了高吞吐。

优化技术细节

Hadamard 旋转：量化 KV 缓存的保真之道

为了节省内存，KV 缓存通常采用低精度量化（如 Q8_0）。但直接对量化后的 K 和 V 计算注意力点积会累积量化噪声，损害生成质量。llama.cpp 引入了一种巧妙的 Hadamard 旋转技术（src/llama-kv-cache.cpp:ggml_gen_hadamard）：

// src/llama-kv-cache.cpp（ggml_gen_hadamard 函数附近）
// 生成 n x n 的 Walsh-Hadamard 矩阵 H，满足 H^T H = I
// 在存储 K/V 到缓存前，对其进行 H 矩阵变换，使量化噪声去相关
// 注意力计算时再通过逆变换恢复

其原理是：Hadamard 矩阵是一个正交矩阵，可将数据旋转到一组新的基底上，使得量化误差在不同维度上均匀分布，减少对点积结果的影响。在 llama.cpp 中，该过程通过给 matmul 操作添加 GGML_HINT_SRC0_IS_HADAMARD 提示来透明执行。虽然增加了一次矩阵乘法开销，但相较于直接使用全精度缓存所节省的内存带宽，这个代价完全值得。

上下文移位：O(1) 的时间轴管理

当对话长度超过预设上下文长度时，传统的做法是将整个 KV 缓存向后物理拷贝一块，时间复杂度为 O(N)。llama.cpp 实现了“逻辑位置移位”：每个缓存单元记录一个移位值 delta，代表其位置需要前移多少（src/llama-kv-cache.cpp:seq_add）。当积累的移位达到阈值，批量通过 RoPE（旋转位置编码）对 key 进行旋转变换，一次性将所有 key 的位置更新到位，避免了频繁的内存搬移。这一设计将单次溢出的处理复杂度降为接近 O(1)，极大地降低了长上下文滚动时的延迟抖动。

批处理中嵌入式的特殊处理

服务器还包含一些针对特定场景的批处理约束。例如，当启用嵌入（embeddings）模型时，代码检查 n_batch（物理批量大小）是否超过 n_ubatch（微批大小），若超过则自动缩小 n_batch（server.cpp:69-77）。这是因为后端要求嵌入中的所有 token 必须在单个微批中完成，否则会导致断言失败。这种运行时调整保障了批处理的正确性，但可能降低嵌入服务的吞吐。

性能与权衡

连续批处理在提高 GPU 利用率的同时，也带来了一系列设计折衷：

  • 延迟 vs. 吞吐：动态批次大小虽然消除了静态批处理的启动等待，但批次大小变化可能导致 GPU 内核启动的额外开销。llama.cpp 通过 n_ubatch 物理限制和算子融合来缓解，但仍需用户根据 GPU 特性微调。
  • 内存开销：多流 KV 缓存在非统一模式下按序列复制，内存消耗与并行度线性增长。统一缓存（kv_unified）缓解了这一问题，然而它需要更复杂的碎片整理和分配回收策略，可能引入碎片化导致的提前刷写。
  • 调度复杂度：槽位的动态分配和 SWA 感知回收增加了代码复杂度，但在常规负载下这些开销可以忽略。然而，高并发下 find_slot 的查找效率可能成为瓶颈，目前该函数未见锁竞争，因为所有调度发生在单一推理线程中。
  • 可配置性：自动设置 n_parallel=4 简化了使用，但可能不适合显存充足的服务器（如 A100），此时用户可手动调大以获得更高并发度。开放参数给予了调优空间，同时也要求运维人员能够理解底层含义。

从工程健壮性角度看，llama-server 通过信号安全的原子标志、异常包装和路由模式复用等措施，做到了在异常负载下的稳定服务。这些看似与批处理无关的细节，实际上构成了高并发服务的基石。

相关论文

尽管 llama.cpp 并未显式引用外部论文，但其设计理念与以下工作遥相呼应：

  • Orca: A Distributed Serving System for Transformer-Based Generative Models (Yu et al., 2022) — 提出了迭代级调度和连续批处理的概念，影响了后续推理服务架构。
  • vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention (Kwon et al., 2023) — 将 PagedAttention 与连续批处理结合，通过块式内存管理提高吞吐。llama.cpp 中 KV 缓存的流式设计可看作一种更简单但高效的替代方案。
  • QuaRot: Outlier-Free 4-Bit Inference in Rotated LLMs (Ashkboos et al., 2024) — 将 Hadamard 变换用于移除激活值中的离群值，与 llama.cpp 中 Hadamard 旋转量化 KV 缓存的思想异曲同工。

总结

llama-server 的连续批处理与调度系统充分利用了 C/C++ 的性能优势，通过简洁的“slot + 多流 KV 缓存”模型实现了动态请求管理。其自动化的并发配置、SWA 感知的槽位复用、Hadamard 旋转量化以及低开销的上下文移位等设计，均体现了实用至上的工程原则。虽然部分调度算法细节仍有待深入分析（如加权公平策略），但现有代码已经为实现“高吞吐、低延迟”的本地 LLM 服务提供了一个扎实且可扩展的基础。对于希望在边缘设备或低预算 GPU 上部署 LLM 服务的工程师而言，这些技术细节具有直接的借鉴价值。