货拉拉海豚平台-大模型推理加速工程化实践

货拉拉技术
0 阅读16分钟

一、背景

随着大模型在货拉拉客服、邀约、安全等核心业务场景的规模化落地，模型推理已进入高并发、长上下文和低延迟约束并存的真实生产环境。在业务持续增长的背景下，如何在保障服务稳定性、控制成本和提升效率的前提下，实现大模型推理的高效工程化，成为亟需解决的核心问题。

针对以上挑战，货拉拉海豚平台通过系统化的工程实践，实现了在保障业务规模和服务质量的前提下，将整体机器资源成本降低50%-60%，显著提升大模型应用的经济性与可扩展性。

本文将围绕海豚平台的大模型推理架构与关键能力，介绍其在资源分配、推理优化与性能评测等方面的实践经验，展示如何在真实业务场景下实现稳定、高效、低成本的推理工程化。

二、方案设计

2.1 海豚平台介绍

海豚平台是货拉拉面向算法与工程团队的一站式云原生机器学习平台，在大模型推理方向构建了完整加速工程体系。

平台自上而下包括业务层、AI能力层、AI引擎层与基建层，通过统一接入与能力抽象，将复杂推理过程转化为可调度、可优化、可运维的系统。在AI能力层整合资源分配、推理加速与模型评测，引擎与基建层负责多引擎适配、算力配置与运行时治理，保障高并发、多业务场景下的稳定运行。

以下为平台整体架构。

whiteboard_exported_image (4).png

三、关键能力拆解

3.1 资源分配策略

线上场景中，核心挑战之一在于如何在有限的GPU算力与显存约束下，对不同模型、请求和推理阶段进行资源分配。资源分配的合理性直接影响了性能延迟、并发能力和资源利用效。针对该问题，海豚平台通过系统化的资源分配策略，在保障服务稳定性的前提下，持续提升 GPU 资源利用效率，显著降低整体推理成本。

大模型推理显存占比主要由三部分组成，如图所示：

screenshot-20260224-143719.png

其中，模型权重属于常驻显存，大小保持不变；系统和中间激活开销随并发和上下文变化产生，但占比相对较小，我们通常会额外预留不超过 5%的显存冗余，用于应对流量波动和调度峰值；而KV Cache则随并发和上下文长度动态增长，是显存的主要开销，也是资源分配与推理优化的核心关注点。KV Cache通过缓存Attention的Key/Value避免重复计算，其占用随上下文长度、模型层数、KV Head 数量、Head 维度及并发请求数线性增加。

在明确显存构成与增长机制后，GPU资源分配核心是为不同模型和请求动态划定合理的显存与算力边界。

围绕该目标，海豚平台构建了一套以业务画像驱动的资源分配策略：

基于线上统计的负载刻画
持续采集模型的上下文长度分布、并发峰值与请求结构，聚焦主流负载区间和稳定峰值，而非孤立的理论最大值，为资源建模提供真实依据。

基于 KV Cache 的显存硬下限计算
在业务画像基础上，通过KV Cache显存模型反推单实例在目标并发下的最小显存需求，并将其作为资源分配的硬约束，确保高并发场景下的稳定性。

避免按理论上限配置资源
以显存硬下限而非最大可用显存作为配置基准，根据不同GPU 机型（如 A10、L20、H20）的显存容量与性能特性，结合单卡、多卡或分布式部署，动态规划每个模型实例的显存和并发上限。在保障服务稳定运行的前提下，显著减少闲置显存，为多模型混部和整体成本优化提供空间。

3.2 推理优化体系

完成基础的资源分配后，大模型推理优化才刚刚开始。前者解决的是算力资源能否有效使用，而后者更关注的是在既定资源约束下，推理效率还能提升多少。在生产环境中，仅依靠增加GPU或限制并发，无法从根本改善延迟、吞吐和成本问题，反而会扩大算力浪费。

基于此，海豚平台的推理优化主要聚焦于模型层与框架层两个方向，共同定义推理性能与成本的边界。

模型层

模型量化

大模型量化通过降低参数计算精度，显著降低显存占用和带宽压力，在配置不动的情况下，并发和吞吐量直接翻翻。

海豚平台在量化落地过程中，采用多量化方案并行的工程策略，根据不同业务负载和性能目标，按需引入FP16、FP8及INT4（GPTQ / AWQ）等量化方法。以下是各量化方法对比。

screenshot-20260306-112116.png

其中，FP16作为基线，具备最优精度但资源成本最高，通常只为核心场景FP16无损部署；FP8在H系列如H20、H800上实现了性能和精度的平衡，这也是我们线上模型部署采纳最多的量化方案；而以GPTQ、AWQ等为代表的INT4量化，更进一步极限压缩了模型显存占用，但生成方面需要严格测试是否符合业务效果预期，以免对线上产生影响。

模型蒸馏

除模型量化以外，模型蒸馏从另一个角度为大模型"瘦身"，通过以大模型作为教师模型，将其能力迁移到参数规模更小、推理更快的学生模型中，显著降低模型规模和推理成本的同时，尽可能保持目标任务上的效果表现。

image (1).png

示例：从通用大模型到业务专用轻量模型

以客服司机助手场景为例，原始线上模型是70B量级通用模型，具备较强泛化能力，但推理成本高、延迟压力大。通过蒸馏过程：

1) 在原始模型上跑真实业务指令，生成高质量响应；

2) 利用该数据集对小量级模型进行指令对齐，复现原始大模型的决策能力；

3) 在核心业务指标（命中率、满意度）保留90%以上能力的表现下，实现模型规模缩小数倍，具体取决于选取小模型的量级。

模型层收益

通过量化、蒸馏及其组合策略，海豚平台减少了大模型推理对高端GPU的依赖，提升了显存利用效率，使A10、L20 等中端算力具备规模化承载能力，在不影响业务效果的前提下，实现 20%～50% 的算力成本优化，并显著降低了系统部署与运维复杂度。

框架层

PD分离

传统大模型推理过程中，Prefill（上下文编码）与 Decode（逐Token生成）都在同一实例内执行。但两者的运转方式完全不同，其中，Prefill以大规模矩阵计算为主，呈计算密集型；而 Decode则高度依赖KV Cache的频繁访问，呈存储密集型。最直接的问题就是GPU利用率很难打满，整体效率受限。

为解决上述问题，海豚平台在部分场景下引入Prefill-Decode分离架构，将推理过程拆解为两个独立的执行单元：

Prefill Instance：

上下文编码与KV Cache生成，优先采用张量并行策略来满足低延迟的TTFT。

Decode Instance：
基于Prefill传输过来的KV Cache，逐Token生成，优先采用数据并行来提升总体吞吐量。

架构图如下所示：

image (2).png

示例：基于vllm的PD分离部署方案

Prefill节点部署

Prefill节点负责处理完整Prompt，并将KV Cache通过P2P的方式发送给Decode节点。

# 使用 GPU 0 启动 Prefill 节点
export CUDA_VISIBLE_DEVICES=0
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 20003 \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --trust-remote-code \
  --kv-transfer-config '{
    "kv_connector": "P2pNcclConnector",
    "kv_role": "kv_producer",
    "kv_port": "21001",
    "kv_buffer_size": "1e1",
    "kv_connector_extra_config": {
      "proxy_ip": "0.0.0.0",
      "proxy_port": "30001",
      "send_type": "PUT_ASYNC",
      "nccl_num_channels": "16"
    }
  }'

Decode节点部署

Decode节点负责消费Prefill节点传来的KV Cache，执行逐Token解码。

# 使用 GPU 1 启动 Decode 节点
export CUDA_VISIBLE_DEVICES=1

vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 20005 \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.7 \
  --trust-remote-code \
  --kv-transfer-config '{
    "kv_connector": "P2pNcclConnector",
    "kv_role": "kv_consumer",
    "kv_port": "22001",
    "kv_buffer_size": "8e9",
    "kv_connector_extra_config": {
      "proxy_ip": "0.0.0.0",
      "proxy_port": "30001",
      "send_type": "PUT_ASYNC",
      "nccl_num_channels": "16"
    }
  }'

Proxy服务启动

Proxy服务负责实例节点注册、负载、调度等功能，支持XPYD等多种配对方式。

# 启动 Proxy 服务
# examples/online_serving/disaggregated_serving_p2p_nccl_xpyd/disagg_proxy_p2p_nccl_xpyd.py
python3 disagg_proxy_p2p_nccl_xpyd.py

测试

验证请求成功返回

curl http://localhost:30001/v1/completions \  
-H "Content-Type: application/json" \  
-d '{
        "model": "meta-llama/Llama-3.1-8B-Instruct",
        "prompt": "请简要介绍一下大模型推理中的 Prefill 和 Decode 阶段。",
        "max_tokens": 100,
        "temperature": 0.7, 
        "stream": false  
}'

效果收益和经验收获：

在试验与性能压测中，我们发现在Decode阶段，得益于KV Cache独占与负载稳定，Token生成效率显著提升，TPOT降低约30%--50%；随着并发规模扩大，优势进一步放大，整体吞吐提升约1.5--2倍。

需要注意的是，PD分离并不会改善TTFT。由于引入了KV 传输与额外调度开销，TTFT相比合并式架构通常略有上升，在部分场景下P95增加约10%--25%。

PD分离更适用于高并发、长上下文且流量相对稳定的实时场景。对存在突发流量的业务，Decode侧可能出现OOM风险。因此，最终PD分离技术的应用上线还需要配合节点注册、负载均衡、故障检测、节点快速恢复等机制以保障业务稳定性。

投机采样

投机采样通过以计算换时间的方式，缓解自回归解码的串行瓶颈。

核心思想是用一个小量级的草稿模型预测多个Token，再由目标大模型并行验证这些Token，修正不一致的结果，在不影响最终输出分布与效果的前提下，降低端到端生成延迟。投机采样也是当前工程可落地性最高的解码级加速方案之一。

架构图如下所示：

image (3).png

实现步骤：

投机采样采用Draft → Verify → Accept/Reject 的三段式流程：

  • Draft（草稿生成）
    由轻量草稿模型一次性生成多个候选Token。

  • Verify（并行验证）
    由目标大模型对这些Token进行并行验证，避免逐Token解码。

  • Accept / Reject（一致性控制）
    按一致性规则依次接受草稿结果，一旦出现不一致即回退，并由大模型继续生成。

通过该机制，既跑得更快，也不改变真实答案。

示例：基于sglang的投机采样部署样例

通过设置--speculative-algorithm EAGLE3 并选择合适的模型来启用 EAGLE-3 解码

python3 -m sglang.launch_server \    
    --model meta-llama/Llama-3.1-8B-Instruct \    
    --speculative-algorithm EAGLE3 \    
    --speculative-draft-model-path jamesliu1/sglang-EAGLE3-Llama-3.1-Instruct-8B \    
    --speculative-num-steps 3 \    
    --speculative-eagle-topk 4 \    
    --speculative-num-draft-tokens 16 \    
    --mem-fraction-static 0.65

效果收益和经验收获：

海豚平台在多个大模型（如DeepSeek R1/V3、Qwen3-235B）上采用投机采样技术，保证效果不影响的前提下显著降低解码延迟。

在线上高频长文本生成场景下，Decode速度可提升1.3-2倍，端到端生成延迟降低30%-60%，主要取决于草稿模型的命中率，如果想进一步提升命中率，也可以结合真实业务数据构造数据集去微调草稿模型。

显存和算子层优化

在线上推理中，性能瓶颈往往不在算力，而是显存碎片严重、Attention访存路径低效。前者限制并发与上下文长度，后者拖慢生成速度。

显存与算子层优化的核心目标主要解决"显存怎么用"和"Attention怎么算"两类问题，以下是两类核心技术介绍：

显存碎片优化：PagedAttention

image (4).png

PagedAttention最早被vLLM引入推理引擎内部，为解决"KV Cache如何存、如何用" 的问题。

传统推理中，KV Cache要求连续显存分配，随请求长度和并发增加，直接导致碎片化问题严重。

而PagedAttention借鉴了操作系统的虚拟内存机制，通过：

  • 将KV Cache划分为固定大小的 Page；

  • 解耦逻辑显存和物理显存，允许非连续显存分配；

  • 按需分配与回收KV Page。

使KV Cache的分配和管理更高效、更可控，避免传统显存浪费的现象。

Attention 路径优化：FlashAttention

Attention是模型推理中最核心、也是最昂贵的算子路径。

在Prefill阶段，常规Attention需要处理规模为 O(n²) 的注意力计算，并伴随大量HBM读写，这导致在长上下文场景下，直接成为了最主要的性能瓶颈。

image (5).png

FlashAttention对常规Attention计算方式进行重构：

  1. 将QK MatMul、Scale、Mask、Softmax、Dropout等多个算子融合为单一Kernel，减少Kernel启动和中间结果开销；

  2. 采用分块计算，将KV Block尽可能在片上完成局部计算；

  3. 避免中间Attention矩阵写回HBM，降低显存带宽压力。

效果收益和经验收获：

海豚平台引入PagedAttention对KV Cache的分页化管理后，线上服务中显存利用率提升至95%以上，单机可承载的最大并发BatchSize显著提升。在此基础上，结合FlashAttention对Attention执行路径的 Kernel Fusion 与访存优化，长上下文（8k 及以上）场景下，整体推理延迟降低10%-40%，伴随吞吐能力实现大幅提升；在基于Hopper架构的 H系列显卡上可启用FlashAttention 3以获得最佳性能，如果是其他中端GPU机型也可以采用FA2等。

3.3 模型测评能力

推理加速是否有效，最终必须由实测数据验证。

实践中，我们经常会发现一个现象，很多"性能提升"并非来自优化，而是压测方法本身不真实。

大模型性能评测的核心价值，在于用客观指标量化优化收益，为算力规划与服务调优提供可落地、可追溯的依据，让每一次优化都有明确的数据标尺。

下面将介绍评测核心指标、异常排查与落地方法。

性能评测指标

screenshot-20260227-160312.png

其中，性能评测重点关注 P90 / P95 / P99，忽略极端值如P99.9，在大模型性能要求的业务中，P90--P99 已能稳定覆盖核心体验区间。

场景化指标权重分配

不同业务关注点不同，指标也需要有侧重：

  • 客服问答场景：重点关注TTFT和E2EL，确保用户尽快看到回复，并在高并发下避免长尾等待。

  • 长文本生成场景：重点关注TPOT和E2EL，保证持续输出速度和整体生成时长可控，避免用户等待过久。

压测实践中的指标异常排查

在性能压测中，指标异常往往暴露了配置或场景匹配问题，以下是两类典型异常的排查思路：

1. 请求堆积与 QPS 过载

  • 现象：压测中频繁出现请求队列阻塞、延迟分位值突增。

  • 根因：通常是压测 QPS 设置过高，超出了并发处理能力，导致请求在队列中堆积。

  • 解决方案：采用梯度施压、稳态判定思路，从低负载逐步提压，每轮压测等待运行状态充分稳定后，再定位真实性能。

2. 前缀缓存命中率异常偏高

  • 现象：Prefix Cache命中率、可支撑QPS 虚高，但实际业务场景下性能无法达标。

  • 根因：压测数据集的用户输入部分高度重复。由于随机数据集的生成依赖伪随机算法，若未动态传递种子参数，会默认使用固定种子（如默认值 0），导致每次输入完全一致，缓存过度复用。

  • 解决方案：规范数据集随机策略，保证请求输入多样性，结合业务前缀复用特征校准缓存区间，对齐真实业务场景，从根源规避数据虚高，保证性能指标真实可信。

大模型性能评测落地

性能评测流程

海豚平台压测体系采用业务特征对齐、梯度QPS压测、阈值临界判定的标准化方式，具体步骤：

  • 明确业务输入输出长度特征，拆分固定前缀与用户输入，设定符合业务预期的输出长度；

  • 选用场景化数据集，灵活配置前缀、输入及输出长度，实现压测请求与业务1:1匹配；

  • 梯度提升QPS，以业务核心阈值（如P99 E2EL ≤2s）为标准，确定显卡可支撑的最大QPS，为算力规划提供依据。

示例：vLLM-Benchmarks

该命令用于模型性能测试，指定OpenAI Chat后端与Qwen3-32B模型，可调整请求速率、数据集、输入输出长度等参数适配自身测试场景。

python3 vllm/benchmarks/benchmark_serving.py \
--backend openai-chat \
--endpoint /v1/chat/completions \
--model /models/qwen3-32b \
--tokenizer /models/qwen3-32b \
--host 0.0.0.0 \
--port 8000 \
--num-prompts 200 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 90,95,99 \
--request-rate 3 \
--dataset-name sonnet \
--dataset-path vllm/benchmarks/sonnet.txt \
--sonnet-input-len 4900 \
--sonnet-output-len 10 \
--sonnet-prefix-len 4500 \
--seed 1772174119 \
--trust-remote-code

四、展望

未来，货拉拉海豚平台将继续以工程化推理能力为核心底座，持续释放大模型在业务效率、服务体验与成本优化上的长期价值。

作者简介：货拉拉/技术中心/智能平台部

邱雨墨、姚天航、蔡高兴

avatar
文章
阅读
粉丝