祝融说。

法不净空，觉无性也。

第8章：推理加速与服务化

2025.11.29

经过预训练、微调和严格的算力核算，我们终于得到了一个性能优异的大模型。然而，一个躺在硬盘里的模型文件本身并不产生价值。真正的挑战现在才开始：如何将这个庞大的模型部署成一个能够同时服务成千上万用户、响应速度快如闪电、并且成本可控的在线服务？

这就是大模型推理（Inference）所要解决的问题。与训练不同，推理场景对延迟（Latency）和吞吐量（Throughput）的要求极为苛刻。用户无法忍受与聊天机器人对话时，每回复一句话都要等待几十秒。同时，对于企业而言，每一块用于推理的GPU都必须尽可能地服务更多用户，以摊薄昂贵的硬件和电力成本。

本章，我们将聚焦大模型推理的全栈优化。我们将首先深入当今推理引擎的“三国争霸”，对比分析vLLM、TensorRT-LLM和华为MindIE这三大主流方案的优劣。接着，我们将深入这些引擎的“黑魔法”内核，揭示PagedAttention、Continuous Batching等革命性技术的原理。最后，我们将拿起压测工具，亲手对一个部署好的模型服务进行“烤机”，学习如何科学地度量和评估其性能。掌握本章，你将具备构建企业级大模型服务的能力，打通从模型到商业的“最后一公里”。

8.1 推理引擎争霸：vLLM、TensorRT-LLM、MindIE（昇腾）对比

直接使用PyTorch或TensorFlow等训练框架进行在线推理，是一种非常低效的做法。训练框架为了灵活性和易用性，包含了大量在推理时并不需要的组件（如自动求导、优化器），并且其内存管理和执行模型都未针对推理场景的特点进行优化。

为了解决这个问题，一系列专为大模型推理设计的“推理引擎”应运而生。它们就像是为F1赛车专门打造的比赛引擎，舍弃了所有不必要的功能，将性能压榨到极致。

8.1.1 朴素推理的困境：低效的显存与计算

让我们先看看不使用推理引擎，直接用transformers库进行推理会发生什么。

  • KV Cache的显存灾难：

    • Transformer模型在生成每个新Token时，都需要依赖前面所有Token的Key和Value（即KV Cache）。
    • 朴素的实现会为每个请求（Request）预先分配一个巨大的、能够容纳其最大可能长度（如4096）的KV Cache空间。
    • 问题： 如果一个用户只输入了10个Token，后面4086个Token的KV Cache空间就被闲置和浪费了。对于大量短请求的场景，这种浪费是惊人的。一个80GB的A800，可能因为显存被这些“空置”的KV Cache占满，实际上只能同时服务寥寥数个请求。

  • 静态批处理（Static Batching）的低效：

    • 为了利用GPU的并行计算能力，一个自然的想法是将多个请求打包成一个批次（Batch）进行处理。
    • 问题： 传统的静态批处理要求批次内的所有序列同时开始、同时结束。这意味着，即使某个请求已经生成完毕，它也必须在原地等待，直到批次内最长的那个请求也生成完毕，才能释放资源并返回结果。这导致GPU在大量时间内处于“等待”状态，计算资源被严重浪费，用户的等待时间也被人为拉长。

推理引擎的核心目标，就是解决上述两大痛点。

8.1.2 vLLM：为Python而生的“易用之王”

vLLM是加州大学伯克利分校的研究者发起的开源项目，它凭借其革命性的PagedAttention技术和极佳的易用性，迅速成为学术界和许多初创公司的首选。

  • 核心技术：PagedAttention（我们将在8.2节详述）

    • vLLM的“杀手锏”。它借鉴了操作系统中虚拟内存和分页的思想，将KV Cache从连续的内存块，切分为非连续的、固定大小的“块（Block）”。
    • 这使得KV Cache的管理变得极其灵活，实现了近乎零浪费的显存使用。它还允许在请求间高效地共享KV Cache（例如，对于有相同前缀的多个请求），进一步节省显存。
    • 其结果是，在相同的硬件与典型负载下吞吐量显著提升：vLLM论文报告的口径是相比当时的SOTA系统（FasterTransformer、Orca）最高2-4倍；vLLM官方博客另给出相比未优化的HuggingFace Transformers基线最高14-24倍（即约一个数量级，长序列场景）的数字，具体倍数依赖负载与参数设置。

  • 架构特点与生态：

    • Python原生，易于集成： vLLM完全使用Python编写，可以与HuggingFace生态无缝集成。你几乎不需要修改模型代码，只需要几行Python代码就可以启动一个高性能的推理服务。
    • OpenAI兼容的API Server： vLLM内置了一个兼容OpenAI API格式的HTTP服务器。这意味着，你可以像调用OpenAI API一样，调用自己部署的模型服务，极大地简化了上层应用的开发。
    • 分布式推理： 支持张量并行（Tensor Parallelism），可以将一个大模型部署到多张GPU上。
    • 流式（Streaming）输出： 支持Token流式生成，可以快速响应并改善用户体验。

  • 选型考量：

    • 优点：
      • 性能卓越： PagedAttention带来的吞吐量提升是实打实的。
      • 极易上手： 对Python开发者非常友好，学习曲线平缓。
      • 开源活跃： 社区非常活跃，对新模型、新硬件（如AMD GPU）的支持跟进很快。
    • 缺点：
      • 量化支持相对滞后： 相比TensorRT-LLM，vLLM在低比特量化（如INT4）等更极致的优化上支持稍慢。
      • CUDA Kernel优化： 虽然其PagedAttention的Kernel性能很好，但在其他算子的深度优化上，可能不如NVIDIA亲手操刀的TensorRT-LLM。

8.1.3 TensorRT-LLM：NVIDIA的“性能核武”

TensorRT-LLM是NVIDIA官方推出的、专为大模型推理设计的解决方案。它建立在成熟的TensorRT（NVIDIA的高性能深度学习推理SDK）之上，是追求极致性能和低延迟的“终极选择”。

  • 核心技术：深度编译优化 + In-Flight Batching

    • 编译期优化： TensorRT-LLM的核心思想是“先编译，后运行”。它会将你的模型（如PyTorch模型）转换成一个高度优化的TensorRT Engine。在这个编译过程中，它会进行一系列“黑魔法”操作：
      • 算子融合（Operator Fusion）： 将多个小的CUDA Kernel（如MatMul + Bias + ReLU）融合成一个大的Kernel，减少Kernel启动开销和内存读写。
      • 精度校准与量化： 支持FP16、INT8甚至INT4等低精度推理，并能自动进行校准，在保持精度的同时最大化性能。
      • 硬件特定的Kernel选择： 根据你当前的GPU型号（如H800），自动选择最优的CUDA实现。
    • In-Flight Batching： 这是TensorRT-LLM对标vLLM Continuous Batching的实现。它允许在推理过程中动态地向批次中添加新的请求、并从中移出已完成的请求，从而最大化GPU的利用率。

  • 架构特点与生态：

    • C++核心，性能至上： 其核心运行时是C++编写的，性能开销极低。
    • 与Triton Inference Server集成： TensorRT-LLM通常与NVIDIA的Triton推理服务器一起部署。Triton提供了企业级的服务管理功能，如动态批处理、多模型部署、HTTP/gRPC接口、性能监控等。
    • 复杂的构建流程： 使用TensorRT-LLM需要一个明确的构建步骤。你需要从HuggingFace等下载模型，然后使用TensorRT-LLM提供的Python API将其编译成Engine文件，最后再用Triton加载这些Engine文件来提供服务。

  • 选型考量：

    • 优点：
      • 极致性能： 在低延迟和低比特量化方面，通常是业界标杆。
      • 企业级特性： 与Triton的结合提供了非常完善和稳定的服务化能力。
      • NVIDIA官方支持： 可以最大化地利用NVIDIA硬件的新特性（如FP8）。
    • 缺点：
      • 使用复杂： 学习曲线陡峭，需要理解编译、构建Engine等概念，排查问题更困难。
      • 灵活性差： 模型一旦被编译成Engine，就固定了。如果想改变某些参数（如最大Batch Size），可能需要重新编译。
      • 生态相对封闭： 紧密绑定NVIDIA硬件和软件栈。

8.1.4 MindIE（MindSpore Inference Engine）：昇腾生态的推理利器

MindIE是华为昇腾生态中，对标TensorRT-LLM的推理引擎。它作为CANN软件栈的一部分，旨在为昇腾芯片（如Ascend 310, 910）上的大模型推理提供极致的性能优化。

  • 核心技术：图优化 + 昇腾硬件亲和

    • 图级协同优化： MindIE会从上层框架（如MindSpore或PyTorch for Ascend）接收计算图，并进行一系列针对昇腾达芬奇架构的深度优化，如算子融合、内存复用、数据格式转换等。
    • 硬件算子加速： 它能将计算图中的关键算子（如矩阵乘法）直接映射到达芬奇架构的3D Cube上执行，最大化硬件利用率。
    • 动态Batching支持： 同样支持类似Continuous Batching的机制，以提升吞吐量。
    • 量化支持： 支持权重量化等技术，以在昇腾芯片上实现更低延迟的推理。

  • 架构特点与生态：

    • 与CANN深度集成： MindIE是昇腾软件栈的原生组件，能够最直接、最有效地利用底层硬件能力。
    • 服务化部署： 提供服务化部署工具，可以将优化后的模型封装成易于调用的在线服务。
    • 适配主流模型： 华为正在积极地将MindIE适配到Llama、GLM、Qwen等主流的开源大模型上，并提供官方的转换和部署脚本。

  • 选型考量：

    • 优点：
      • 昇腾平台最优性能： 在昇腾硬件上，MindIE通常能提供比其他第三方框架（如直接用PyTorch for Ascend）更好的推理性能。
      • 官方支持： 作为官方解决方案，可以获得华为的技术支持和持续的性能优化。
    • 缺点：
      • 生态绑定： 仅适用于华为昇腾平台。
      • 社区和文档： 相比vLLM和TensorRT-LLM，其开源社区的广度和活跃度、以及第三方文档和教程的丰富度，可能还有待发展。

对比总结：

对比维度vLLMTensorRT-LLMMindIE (昇腾)
核心优势易用性、吞吐量 (PagedAttention)极致性能、低延迟 (编译优化)昇腾平台最优性能 (硬件亲和)
使用门槛低，Python友好，快速上手高，需要编译构建，C++核心中，需熟悉CANN生态
性能特点吞吐量极高，延迟良好延迟最低，吞吐量优秀昇腾芯片上的最佳实践
生态系统开源、活跃，与HuggingFace深度集成NVIDIA官方，与Triton深度集成华为官方，与CANN深度集成
适用场景快速原型验证、学术研究、对吞吐量要求极高的在线服务对延迟极度敏感的企业级应用（如搜索、对话）、追求极致性能的场景所有基于昇腾硬件的推理部署

给AI Infra工程师的建议： 在NVIDIA平台上，vLLM是快速启动和迭代的最佳选择，而TensorRT-LLM是追求极致商业化性能的终点。 一个常见的实践是：在开发和实验阶段使用vLLM，当模型和业务逻辑稳定后，再投入工程资源将其迁移到TensorRT-LLM以获得最终的性能和稳定性。在昇腾平台上，MindIE则是当然不让的首选。

8.2 核心技术：KV Cache、PagedAttention、Continuous Batching 原理

推理引擎的性能提升并非凭空而来，而是源于对大模型推理过程中资源瓶颈的深刻洞察和巧妙的算法设计。本节，我们将深入这些引擎的内核，理解它们是如何解决显存和计算效率问题的。

8.2.1 KV Cache：记忆的代价

  • 原理回顾： Transformer的自注意力机制是“上下文相关”的。在生成第i个Token时，模型需要回顾并计算当前Token与前面所有i-1个Token之间的注意力关系。为了避免每次都重复计算前面i-1个Token的Key和Value向量，一个标准的优化是：将它们缓存起来。这个缓存就是KV Cache。
  • 显存占用公式： Memory_KV_Cache (GB) ≈ 2 * L * h * s * b * 2 (字节/FP16) / 10^9 其中，L是层数，h是隐藏层维度，s是序列长度，b是批次大小。
  • 痛点：
    • 浪费： 如前所述，为每个请求预分配最大长度的KV Cache，导致大量显存被浪费。
    • 碎片化： 不同请求的KV Cache大小不一，在动态分配和释放时，容易在显存中产生大量无法利用的“小碎片”。

8.2.2 PagedAttention：像管理CPU内存一样管理KV Cache

vLLM的PagedAttention技术，是解决KV Cache问题的优雅方案。

核心思想

  1. 空间离散化（分页）： 不再为KV Cache分配连续的大块内存，而是将其划分为许多个固定大小的、较小的块（Block）。每个Block可以存储几十个Token的Key和Value。
  2. 逻辑连续化（页表）： 为每个请求维护一个“页表（Page Table）”。这个页表记录了该请求的Token序列，在逻辑上应该对应哪些物理上的Block。
  3. 按需分配： 当一个请求开始时，系统只为其分配一个Block。当它生成的Token填满了这个Block后，系统再从一个全局的“Block池”中，为它分配下一个Block，并更新其页表。

革命性优势

  • 显存利用率显著提升： 由于是按需分配小块内存，内部碎片几乎被消除。vLLM论文报告其KV Cache显存浪费可降至4%以下（即利用率96%以上，数据来自其论文的对比实验，实际效果取决于负载形态）。
  • 高效的共享（Copy-on-Write）： 当多个请求有相同的前缀时（例如，多个用户都以“请帮我总结一下《三体》这本书”开头），PagedAttention可以让它们的页表指向相同的、存储了该前缀KV Cache的物理Block。只有当某个请求开始生成与众不同的后续内容时，系统才会为它复制并分配新的Block。这在并行采样、Beam Search等场景下，可以极大地节省显存和计算。
  • 灵活的内存管理： 就像操作系统的虚拟内存一样，可以轻松地实现Block的交换（Swap）等高级操作。

PagedAttention的出现，几乎凭一己之力，将大模型推理的吞吐量提升了一个台阶，是近年来AI Infra领域最重要的创新之一。

8.2.3 Continuous Batching：让GPU“永不停歇”

解决了显存问题后，下一个目标是提升计算效率。Continuous Batching（连续批处理）正是为此而生。vLLM, TensorRT-LLM, MindIE等现代推理引擎都实现了这一技术，虽然名字可能不同（如In-Flight Batching）。

思想演进

  1. 静态批处理 (Static Batching)：
    1. 流程： 凑齐一批请求 -> 并行计算一步 -> 所有请求都生成一个Token -> 重复。
    2. 缺点： “木桶效应”。必须等待批次内最慢（最长）的那个请求完成，快的请求只能干等。GPU在后期大量空闲。
  2. 连续批处理 (Continuous Batching)：
    1. 流程： 维护一个持续运行的、动态的批次。
    2. 迭代循环： 在推理服务器的每一次迭代循环中：
      1. 检查完成： 检查当前批次中，有哪些请求已经生成完毕（例如，生成了结束符[EOS]，或达到了最大长度）。将这些已完成的请求立即从批次中移除，并将其结果返回给用户。
      2. 添加新请求： 查看等待队列中是否有新的请求。如果GPU的计算和显存资源有空余（因为刚刚移除了已完成的请求），就将新的请求动态地添加到当前批次中。
      3. 执行一步： 对这个“更新后”的动态批次，执行一步前向传播，为批次内的所有请求生成下一个Token。
      4. 回到a。

价值

  • GPU利用率最大化： 通过“即来即走、动态增删”的策略，确保GPU在每个计算步长中，都尽可能地在处理一个“满载”的批次。空闲时间（“气泡”）被大大减少。
  • 平均延迟降低： 短请求不再需要等待长请求，可以很快完成并返回，从而显著降低了用户的平均等待时间。

总结： PagedAttention从“空间”维度优化了显存，Continuous Batching从“时间”维度优化了计算。这两项技术的结合，构成了现代大模型推理引擎的性能基石。

8.3 压测实战：使用Locust测试TTFT与TPOT

部署好一个推理服务后，我们如何科学地评估它的性能？“感觉很快”是不可靠的。我们需要用数据说话。压力测试是检验推理服务性能、发现瓶颈、进行容量规划的核心手段。

8.3.1 核心性能指标

在LLM推理场景，我们需要关注两个核心指标：

  • TTFT (Time To First Token，首字延迟):
    • 定义： 从用户发送请求，到接收到第一个生成Token所花费的时间。
    • 意义： 直接影响用户的“即时响应感”。对于对话应用，一个低的TTFT至关重要，它让用户感觉系统“活”了过来。TTFT主要包含了网络延迟、请求在队列中的等待时间、以及模型处理输入（Prompt Processing）的时间。
  • TPOT (Time Per Output Token，每输出Token时间) / Tokens per Second (TPS):
    • 定义： 生成后续每个Token的平均时间（TPOT），或者其倒数——每秒能生成多少个Token（TPS）。
    • 意义： 反映了模型的“生成速度”。对于需要生成长文本的任务，高的TPS意味着用户能更快地看到完整结果。TPS主要由模型单步解码（Decoding）的计算速度决定。

除此之外，我们还会关注吞吐量（Throughput），它可以用每秒处理的请求数（RPS）或每秒生成的总Token数来衡量。

8.3.2 压测工具：Locust

Locust是一个用Python编写的、开源、易于使用的分布式压力测试工具。它非常适合用来测试LLM服务，因为我们可以用Python灵活地模拟用户的行为。

  • 优点：
    • 用Python写测试脚本： 非常直观，易于编写复杂的测试逻辑。
    • 分布式： 可以轻松地从多台机器发起压力，模拟大量并发用户。
    • Web UI： 提供一个漂亮的Web界面，可以实时查看QPS、响应时间、失败率等统计数据。

8.3.3 压测实战步骤

场景： 我们已经用vLLM部署了一个Llama 3-8B模型，其API服务地址是http://127.0.0.1:8000/v1/completions。

安装Locust

pip install locust

编写压测脚本 (locustfile.py)

这个脚本定义了“虚拟用户”的行为。

import time
from locust import task, FastHttpUser
import random
import json

# 模拟一些用户输入
PROMPTS = [
    "你好，请做个自我介绍。",
    "请写一首关于春天的五言绝句。",
    "Explain the theory of relativity in simple terms.",
    "What are the top 5 tourist destinations in Japan?",
]

class LLMUser(FastHttpUser):
    # host = "http://127.0.0.1:8000" # 可以在启动时指定

    @task
    def generate_text(self):
        prompt = random.choice(PROMPTS)
        output_len = random.randint(50, 200) # 随机生成长度

        payload = {
            "model": "Llama-3-8B",
            "prompt": prompt,
            "max_tokens": output_len,
            "temperature": 0.7,
            "stream": True # 使用流式接口来测量TTFT
        }

        headers = {"Content-Type": "application/json"}
        
        start_time = time.time()
        first_token_received = False
        total_tokens = 0
        
        with self.client.post("/v1/completions",
                                json=payload,
                                headers=headers,
                                stream=True,
                                name="/v1/completions/stream",
                                catch_response=True) as response:
            
            if response.status_code != 200:
                response.failure(f"Request failed with status {response.status_code}")
                return

            try:
                for chunk in response.iter_lines():
                    if chunk:
                        # 解析流式返回的JSON
                        decoded_chunk = chunk.decode('utf-8')
                        if decoded_chunk.startswith("data: "):
                            data = json.loads(decoded_chunk[6:])
                            
                            # 记录TTFT
                            if not first_token_received:
                                ttft = (time.time() - start_time) * 1000 # ms
                                self.environment.events.request.fire(
                                    request_type="POST",
                                    name="TTFT",
                                    response_time=ttft,
                                    response_length=0,
                                )
                                first_token_received = True

                            # 统计Token数量
                            if "choices" in data and len(data["choices"]) > 0:
                                total_tokens += 1
            
            except Exception as e:
                response.failure(str(e))
        
        # 压测结束后，可以计算TPOT/TPS，但Locust本身不直接支持
        # 通常需要将数据导出后分析
        # 这里我们主要通过Locust的UI关注TTFT和RPS

关键点： 我们通过捕获流式响应的第一个数据块来精确测量TTFT，并将其作为一个自定义的请求类型上报给Locust。

启动Locust

locust -f locustfile.py --host http://127.0.0.1:8000

开始压测

  • 打开浏览器，访问 http://localhost:8089。
  • 设置并发用户数和增长速率： 例如，模拟100个并发用户，每秒增加10个。
  • 点击“Start swarming”。

分析结果

  • 在Locust的Web UI中，你将能实时看到：
    • RPS（Requests per second）： 你的服务每秒能处理多少个新请求。
    • 响应时间统计： 在“Charts”标签页，你可以看到名为TTFT的请求的响应时间分布图，包括平均值、中位数、99百分位等。99百分位的TTFT是衡量服务稳定性的重要指标。
  • 计算TPS：
    • 在服务端，你需要通过监控（如Prometheus）来抓取vLLM暴露的指标，例如vllm_generation_tokens_total。
    • TPS = rate(vllm_generation_tokens_total[1m])，即每秒生成的总Token数。
    • 吞吐量 = TPS * RPS （在不同场景下选择合适的吞吐量定义）

压测中的瓶颈分析

  • TTFT过高：
    • 高并发下升高： 意味着请求在队列中等待时间过长。需要增加GPU卡数或优化Prompt处理性能。
    • 低并发下就很高： 可能是模型加载或Prompt处理本身就很慢。
  • TPS低：
    • 意味着单步解码慢。可以尝试使用更低的精度（如INT8量化），或更换更强的GPU。
  • RPS上不去：
    • 在达到某个RPS值后，TTFT急剧上升或错误率增加，这通常就是你服务的性能拐点。
    • 此时需要结合服务端的GPU利用率、显存占用等监控来分析瓶颈：
      • GPU利用率已满： 恭喜，你的服务优化得不错，瓶颈在算力本身。想提升RPS，只能加卡。
      • GPU利用率不高但RPS上不去： 瓶颈可能在CPU（如Python的GIL、API服务器的I/O）、网络或调度逻辑上。

通过这样一轮完整的压测->分析->优化的循环，你才能真正地将一个大模型推理服务，打磨成能够应对真实世界复杂流量的企业级应用。

书稿