如果你正在用 7B、8B 这类小型模型做实际业务大概率遇到过同一个问题模型加载起来很容易推理却慢得让人怀疑是不是服务器借来的。GPU 利用率不高CPU 和内存也没占满但生成一个 token 就是快不了。在一些自动生成、代码补全、客服摘要场景里这种“等一个字”的体验往往比模型结果准不准更影响最终效果。Nvidia LPX 系统正是冲着这个痛点来的。它不是一个单纯靠堆算力的方案而是围绕 NVIDIA 硬件、驱动、运行时和推理引擎组成的一整套高速解码方案。尤其是针对小型模型它把“模型能跑”和“模型跑得快”这两件事彻底拉开了距离。这篇文章会从解码原理讲起接着给出一套可落地的环境搭建、部署示例、优化手段和排错路径。读完你会明白同样一张显卡为什么别人能让小型模型跑出接近实时的生成速度而你还在被 token 延迟卡住。1. 这篇文章真正要解决的问题先说一个反直觉的现象模型越小解码速度不一定越快。很多人都以为7B 模型一定比 70B 模型快十倍。实际上当单卡显存足够放得下模型时小模型确实有优势但如果推理配置不对、低精度没有生效、KV Cache 没有被有效管理小模型的生成速度也会被系统瓶颈拖到不可接受。大型语言模型生成文本时不是一次性算完一整段话而是一个 token 一个 token 地蹦出来。每个 token 都依赖之前生成的 token这个串行过程在推理里叫 decode。decode 阶段的瓶颈主要不在计算的 FLOPs而在显存带宽。举个例子一个 7B 模型假设权重和做一次 token 生成需要读取的中间状态加起来有 20GB 左右。GPU 的显存带宽如果是 2TB/s那么理论上每秒最多能访问多少次完整状态这个数字直接决定了 token 生成速度的上限。更麻烦的是decode 阶段每个 step 读取的数据量巨大但实际计算量又很小。GPU 的计算单元大部分时间在等数据从显存搬过来这跟训练阶段“计算密集”的特征完全不同。所以小型模型高速解码的真正问题不是“显卡不够强”而是“显存带宽和分析次数”被浪费了。Nvidia LPX 系统想解决的恰恰就是这两层问题怎么让 decode 阶段对显存带宽的依赖变小。怎么让 GPU 的计算单元在解码时真正忙起来。如果你已经在用 PyTorch HuggingFace Transformers 跑推理这篇文章里提到的很多优化点会直接改变你的服务吞吐和响应延迟。如果你是做模型服务化、边缘部署或算子优化的这套思路也值得收藏。2. 高速解码背后的核心原理要把 LPX 系统看明白先要弄懂 decode 阶段为什么慢。这里不展开数学推导只讲工程上必须理解的两个周期prefill 和 decode。prefill 是模型看到整段输入提示词的阶段。这个阶段输入是并行的计算密集GPU 利用率可以被拉得很高。decode 是生成阶段的每个 step。输入只有一个新 token但要跟之前所有 token 的 KV Cache 一起计算。模型权重和 KV Cache 都必须从显存读一遍然后只产生一个 token。这个阶段是访存密集计算量很小。大部分普通推理框架都会把这两个阶段混在一起。系统里同时有 prefill 阶段的请求和 decode 阶段的请求时GPU 调度的效率会下降。而高速解码方案一般会做两件事优化显存读取方式或者对预填充和解码进行动态资源拆分。KV Cache 是另一个关键角色。推理时为了不重复计算历史 token会把每一层的 Key 和 Value 缓存下来。模型越长KV Cache 越大。当多路请求同时进来显存常常被 KV Cache 占满而不是被模型权重占满。如果 KV Cache 没有做分页管理显存里就会出现大量碎片。请求结束后块没有及时回收新请求进来又申请一块更大显存。最后的结果是显存看着不够用实际上很多空间都是碎片化的。低精度量化则是从另一个维度解决问题。把 FP16 的权重降到 FP8 甚至 INT4模型占用显存变小decode 阶段需要从显存读取的数据量也变小。带宽不变的情况下读取量越少速度越快。这里需要区分一个概念训练阶段压缩精度主要影响收敛效果。推理阶段压缩精度直接影响显存占用、带宽压力和 decode 速度。所以小型模型高速解码核心思路就是减少每次 decode step 需要搬运的数据量提高 GPU 计算单元的实际使用率。LPX 系统可以理解成把这些优化策略在 NVIDIA 硬件和软件栈上整合成一套可复用的系统方案。3. 从“能跑”到“高速”Nvidia LPX 系统的工程拆解LPX 在公开资料里的明确定义不算多NVIDIA 官方也还没有一套独立的完整文档来单独介绍它。但这并不影响工程上的使用更好的理解方式是把它拆成几个层第一层是硬件层。NVIDIA GPU 里的 Tensor Core 对低精度矩阵乘法的支持很不相同。越新的架构对 FP8、INT8、INT4 的支持越完善。高速解码方案一定要选对硬件代际否则软件层做了再多的优化也无法发挥低精度计算的优势。第二层是驱动和运行时层。CUDA 驱动、NVIDIA Container Toolkit、CUDA runtime 是否匹配决定了 GPU 能不能被容器和外部进程正常使用。很多号称已经部署了加速方案的项目实际卡在驱动版本不匹配上。第三层是推理引擎层。直接使用 PyTorch 的generate()方法当然也能跑但它很难把 page attention、continuous batching、KV Cache 量化这些高级优化全部发挥出来。这时候要用 TensorRT-LLM、vLLM 等推理引擎。第四层是部署层。模型做成了什么服务暴露什么协议用什么方式上线。NVIDIA NIM 这类预构建微服务就是把模型、推理引擎、运行环境打包好的产物。它降低的是工程团队的部署门槛而不是模型本身的计算成本。把四层放在一起看你就会发现LPX 系统不是某一个开关而是一条完整的链路硬件层决定算力上限。驱动和运行时决定显卡能不能被用起来。推理引擎决定 decode 效率。部署层决定服务稳定性。所以排查“模型跑不快”的问题时不能只调一个环节。很多人把量化配置改了发现没有明显提速就以为是量化没用。实际上可能是驱动层没有启用正确的精度支持也可能是推理引擎没有真正加载量化后的权重。4. 环境准备驱动、CUDA 与 NVIDIA Container Toolkit以下操作以 Ubuntu 22.04 为例顺便覆盖几个最容易踩坑的地方。NVIDIA 驱动的安装方式有很多种这里推荐一种适合服务器环境的组合系统包管理器安装驱动 Docker 中提供 CUDA 运行时。第一步确认显卡型号和当前驱动。lspci | grep -i nvidia nvidia-smi如果系统里已经装过驱动nvidia-smi会显示驱动版本和显卡型号。如果没有输出说明驱动还没装好。第二步安装驱动。Ubuntu 上最简单的办法是通过 Ubuntu 官方源安装。sudo apt update sudo apt install nvidia-driver-535安装完成后重启。sudo reboot重启后再次运行nvidia-smi确认驱动版本和 CUDA 版本。不同显卡对驱动版本的最低要求不同版本号请以实际硬件和官方支持矩阵为准。第三步安装 Docker 和 NVIDIA Container Toolkit。Docker 安装不展开这里重点说 Container Toolkit。curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit第四步配置 Docker 使用 NVIDIA runtime。sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker第五步验证容器能不能看到 GPU。docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi如果容器里能正常输出显卡信息说明 GPU 已经被 Docker 正确暴露。这时再跑推理框架就不会出现“容器里看不到 GPU”的问题。一个常见坑是宿主机驱动版本太老容器里的 CUDA 镜像版本太高导致容器启动时报驱动不兼容。这个问题的最快解决方法是把 CUDA 镜像版本降到驱动支持的范围内。另一个常见坑是安装 Container Toolkit 后没有 restart Docker导致--gpus参数无效。在继续下面的步骤之前先确认这一条。5. 用真实推理引擎搭建一个高速解码服务环境准备好之后不要急着写 PyTorch 推理脚本先用一个成熟推理引擎把基线跑通。这里以 vLLM 为例因为它的安装简单API 友好而且可以很快验证解码性能。首先确认 Python 版本和虚拟环境。python3 -m venv vllm-env source vllm-env/bin/activate pip install --upgrade pip然后安装 vLLM。由于安装包体积较大建议在 Python 3.10 以上的环境里安装具体版本请以官方 PyPI 页面为准。pip install vllm接下来编写一个最简推理脚本。from vllm import LLM, SamplingParams # 模型名称可以替换成你实际使用的模型 model_name Qwen/Qwen2.5-7B-Instruct llm LLM( modelmodel_name, tensor_parallel_size1, dtypefloat16, max_model_len8192, ) prompt 写一段关于高速解码原理的简短介绍 outputs llm.generate([prompt], SamplingParams(max_tokens512)) for output in outputs: print(output.outputs[0].text)这段代码中的tensor_parallel_size1表示单卡推理。如果你的显存足够大不需要多卡并行如果后续希望开多卡再调整为 2 或 4。跑通生成后下一步是提高性能。vLLM 支持命令行方式直接启动一个兼容 OpenAI 协议的 HTTP 服务。python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9启动后可以通过 curl 做一个快速请求验证。curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, prompt: 请用一句话解释高速解码, max_tokens: 200 }如果返回了 JSON 格式的choices字段说明服务已经正常工作。这一步看起来简单但它已经完成了 prefill 和 decode 的分离、KV Cache 管理、显存池化等一系列优化。注意这里的dtypefloat16是一个很安全的配置。如果在你的硬件上支持 FP8也可以尝试dtypefloat8或者通过量化配置加载 FP8 权重。但不要一开始就在所有模型上都用最低精度先跑通再量化和优化。6. 小型模型高速解码的关键优化手段当一个服务能跑之后下面这些优化手段就值得依次测试。它们是“高速解码”的真正来源。6.1 权重量化与激活量化对小型模型来说FP8 或 INT4 权重量化能把模型体积压缩到原来的一半甚至四分之一。decode 阶段需要读取的权重数据量随之减少显存带宽压力也随之下降。但要注意量化不是免费的。过度量化可能造成明显的精度下降。工程上的推荐做法是先用量化感知评估脚本测试代表性数据集确认指标在可接受范围内再上线。6.2 KV Cache 管理与量化推理引擎会为每一条请求分配 KV Cache 空间。如果请求较长KV Cache 会占掉大量显存。vLLM 这类引擎已经内置 PagedAttention显存碎片问题会好很多。更高阶的做法是压缩 KV Cache。常见方案包括 KV Cache 量化、更节省的缓存策略、以及针对长上下文场景的调参。对小型模型来说把 KV Cache 省下来的显存留给更大 batch size通常能直接提高整体吞吐。6.3 Continuous Batching传统批处理方式会让同一批请求必须一起完成短请求要等长请求。连续批处理则允许在 token 级别动态插入和退出请求GPU 的空闲窗口被填补整体吞吐能明显提高。这个优化主要是推理框架的职责。vLLM、TensorRT-LLM 都支持类似机制不需要业务代码做额外改动。如果你的服务框架是自研的那么这里可能是收益最大的改造点。6.4 Prefill 和 Decode 分离当系统同时有长提示词请求和短提示词请求时prefill 的高计算需求与 decode 的低计算需求会互相干扰。部分生产系统会拆成 prefill 节点和 decode 节点分离部署各自按特点做资源配置。这个方案更适合已经有一定并发规模的项目。如果只是单机服务先不必急着拆把 batch size 和显存分配调好收益可能更直接。6.5 Speculative Decoding推测解码是一种用“小型草稿模型先猜大模型再验证”的加速方案。如果草稿模型一次性猜出多个 token而主模型验证后全部接受那么一次解码步骤可以产生多个 token用户感知速度会大幅提升。这个方案对 tokenizer 一致性有要求草稿模型和主模型需要共享词表。对部署能力要求也比较高但在代码生成、聊天回复这类场景里收益通常很可观。7. 运行结果与验证方法光看生成文本没有意义必须用量化指标评估解码速度。这里提供一个简单的 Python 测速脚本。import time from vllm import LLM, SamplingParams model_name Qwen/Qwen2.5-7B-Instruct llm LLM(modelmodel_name, dtypefloat16, max_model_len8192) prompt 高速解码对 LLM 服务的重要性是什么 max_tokens 1024 start time.time() outputs llm.generate([prompt], SamplingParams(max_tokensmax_tokens)) cost time.time() - start generated_text outputs[0].outputs[0].text token_count len(outputs[0].outputs[0].token_ids) print(f耗时: {cost:.2f} s) print(f生成 token 数: {token_count}) print(f平均速度: {token_count / cost:.2f} tokens/s)由于脚本里包含了 prefill 和 decode 的完整时间所以它测的是端到端速度不代表纯 decode 速度。要看纯 decode 性能需要把 prefill 耗时拆出去或者用不同长度的 max_tokens 做多组测试再对比增速。判断结果有一个简单的经验值在 7B 参数、单卡 A 系列或 RTX 4090 级别硬件上如果端到端速度只有个位数 tokens/s说明配置还有优化空间如果达到几十 tokens/s说明基本发挥了硬件能力。具体数值因显卡、显存、模型格式和量化方式差异很大不能一概而论。除了脚本测速生产环境还需要记录三个关键指标TTFTTime to First Token用户感受到的首 token 延迟。TPOTTime Per Output Token每个输出 token 的间隔时间。Throughput整个服务每秒能处理的请求数。这三个指标对应不同的优化方向。TTFT 高可能要优化 prefill 和队列调度TPOT 高要重点看 decode 和显存带宽吞吐低则要调整 batch size 和并发策略。8. 常见问题与排查思路问题现象可能原因排查方式解决方案容器内无法使用 GPUNVIDIA Container Toolkit 未安装或未重启 Docker在容器外运行nvidia-smi在容器内再运行一次安装 toolkit执行sudo nvidia-ctk runtime configure --runtimedocker并重启 docker模型加载后显存不足并发请求太多KV Cache 占用过大查看nvidia-smi显存占用检查推理引擎的显存分配配置调低gpu-memory-utilization限制并发数启用 KV Cache 量化量化后精度下降严重量化精度选择不当或未做校准在代表性数据集上对比量化前后输出改用 FP8 替代 INT4或做带校准数据的训练后量化生成速度依然很慢仍然使用默认 PyTorchgenerate()接口确认是否通过 vLLM / TensorRT-LLM 加载换用成熟推理引擎再验证速度驱动版本与 CUDA 版本不匹配宿主机驱动过旧运行nvidia-smi查看 CUDA 版本升级驱动或降低容器 CUDA 镜像版本推理引擎启动后卡住正在编译 CUDA kernel首次加载耗时查看日志和 CPU 占用首次启动等待即可生产环境可提前预热这里特别提醒一个常见误区只看 GPU 利用率是不够的。如果nvidia-smi显示 GPU 利用率 90%不代表 decode 已经最优。decode 阶段的利用率高有可能是计算单元在低效地等待数据。所以一定要以 tokens/s 和首 token 延迟作为核心指标。9. 最佳实践与生产建议最后一章整理几条值得长期坚持的工程建议。第一所有优化必须有基线。没有基线就无法判断改动是否有效。建议把模型名称、量化精度、批大小、GPU 型号、输入长度、输出长度、tokens/s 这七个字段记录下来作为性能档案长期维护。第二不要同时改多个变量。比如先只改精度测一轮再只改批大小测一轮。如果同时改了精度和批大小出问题后很难定位是哪个变量导致。第三量化前先确认硬件支持。不是所有 GPU 都支持 FP8。如果硬件不支持强行使用 FP8 格式会非常慢。更稳妥的做法是先查官方特性表再决定精度方案。第四安全边界要提前处理。模型服务如果暴露在公网必须做鉴权。建议把模型服务放在内网由业务服务统一对外。涉及模型文件、用户数据、日志时遵循最小权限原则不要把所有用户数据写进同一个日志文件。第五生产环境变更前先从测试环境验证。驱动升级、CUDA 版本变化、推理引擎版本升级都可能影响已调好的性能。建议在测试环境先运行同一套基线脚本确认性能没有回退再发布到生产。第六模型权重和代码要分离。不要把模型文件散落在业务代码仓库里。用模型目录、版本号、清单文件统一管理既能追踪来源也能在异常时快速回滚。最后一点提醒小型模型高速解码的收益最终是综合结果。硬件选型、驱动版本、推理引擎、量化策略、KV Cache 管理、并发调度每一个环节都可能成为短板。与其执着于某一个“神器”开关不如把整条链路纳入监控让每次优化都有依据。10. 收尾一个值得立刻执行的动作如果你现在手里正好有一个小型模型在跑别急着换框架或换卡。先做三件事把当前 tokens/s 测出来把当前推理引擎和精度格式记录一份再按本文的步骤跑一遍 vLLM 基线。多数情况下你会很快发现在“预填充和生成混合”、“KV Cache 分配不合理”、“量化没有真正生效”这些环节里至少有一个是明显的瓶颈。把它们逐个解决之后再回到开头说的那个问题为什么同样的显卡别人能让小型模型跑得更快答案其实很简单——别人把访存瓶颈、显存管理、调度策略都当成系统问题来处理了而不是只靠加一张更好的卡。 
长河君 · 2026/8/29 2:22:07 · 阅读 1.2k 小型模型推理速度慢？Nvidia LPX 系统与高速解码优化实战
如果你正在用 7B、8B 这类小型模型做实际业务大概率遇到过同一个问题模型加载起来很容易推理却慢得让人怀疑是不是服务器借来的。GPU 利用率不高CPU 和内存也没占满但生成一个 token 就是快不了。在一些自动生成、代码补全、客服摘要场景里这种“等一个字”的体验往往比模型结果准不准更影响最终效果。Nvidia LPX 系统正是冲着这个痛点来的。它不是一个单纯靠堆算力的方案而是围绕 NVIDIA 硬件、驱动、运行时和推理引擎组成的一整套高速解码方案。尤其是针对小型模型它把“模型能跑”和“模型跑得快”这两件事彻底拉开了距离。这篇文章会从解码原理讲起接着给出一套可落地的环境搭建、部署示例、优化手段和排错路径。读完你会明白同样一张显卡为什么别人能让小型模型跑出接近实时的生成速度而你还在被 token 延迟卡住。1. 这篇文章真正要解决的问题先说一个反直觉的现象模型越小解码速度不一定越快。很多人都以为7B 模型一定比 70B 模型快十倍。实际上当单卡显存足够放得下模型时小模型确实有优势但如果推理配置不对、低精度没有生效、KV Cache 没有被有效管理小模型的生成速度也会被系统瓶颈拖到不可接受。大型语言模型生成文本时不是一次性算完一整段话而是一个 token 一个 token 地蹦出来。每个 token 都依赖之前生成的 token这个串行过程在推理里叫 decode。decode 阶段的瓶颈主要不在计算的 FLOPs而在显存带宽。举个例子一个 7B 模型假设权重和做一次 token 生成需要读取的中间状态加起来有 20GB 左右。GPU 的显存带宽如果是 2TB/s那么理论上每秒最多能访问多少次完整状态这个数字直接决定了 token 生成速度的上限。更麻烦的是decode 阶段每个 step 读取的数据量巨大但实际计算量又很小。GPU 的计算单元大部分时间在等数据从显存搬过来这跟训练阶段“计算密集”的特征完全不同。所以小型模型高速解码的真正问题不是“显卡不够强”而是“显存带宽和分析次数”被浪费了。Nvidia LPX 系统想解决的恰恰就是这两层问题怎么让 decode 阶段对显存带宽的依赖变小。怎么让 GPU 的计算单元在解码时真正忙起来。如果你已经在用 PyTorch HuggingFace Transformers 跑推理这篇文章里提到的很多优化点会直接改变你的服务吞吐和响应延迟。如果你是做模型服务化、边缘部署或算子优化的这套思路也值得收藏。2. 高速解码背后的核心原理要把 LPX 系统看明白先要弄懂 decode 阶段为什么慢。这里不展开数学推导只讲工程上必须理解的两个周期prefill 和 decode。prefill 是模型看到整段输入提示词的阶段。这个阶段输入是并行的计算密集GPU 利用率可以被拉得很高。decode 是生成阶段的每个 step。输入只有一个新 token但要跟之前所有 token 的 KV Cache 一起计算。模型权重和 KV Cache 都必须从显存读一遍然后只产生一个 token。这个阶段是访存密集计算量很小。大部分普通推理框架都会把这两个阶段混在一起。系统里同时有 prefill 阶段的请求和 decode 阶段的请求时GPU 调度的效率会下降。而高速解码方案一般会做两件事优化显存读取方式或者对预填充和解码进行动态资源拆分。KV Cache 是另一个关键角色。推理时为了不重复计算历史 token会把每一层的 Key 和 Value 缓存下来。模型越长KV Cache 越大。当多路请求同时进来显存常常被 KV Cache 占满而不是被模型权重占满。如果 KV Cache 没有做分页管理显存里就会出现大量碎片。请求结束后块没有及时回收新请求进来又申请一块更大显存。最后的结果是显存看着不够用实际上很多空间都是碎片化的。低精度量化则是从另一个维度解决问题。把 FP16 的权重降到 FP8 甚至 INT4模型占用显存变小decode 阶段需要从显存读取的数据量也变小。带宽不变的情况下读取量越少速度越快。这里需要区分一个概念训练阶段压缩精度主要影响收敛效果。推理阶段压缩精度直接影响显存占用、带宽压力和 decode 速度。所以小型模型高速解码核心思路就是减少每次 decode step 需要搬运的数据量提高 GPU 计算单元的实际使用率。LPX 系统可以理解成把这些优化策略在 NVIDIA 硬件和软件栈上整合成一套可复用的系统方案。3. 从“能跑”到“高速”Nvidia LPX 系统的工程拆解LPX 在公开资料里的明确定义不算多NVIDIA 官方也还没有一套独立的完整文档来单独介绍它。但这并不影响工程上的使用更好的理解方式是把它拆成几个层第一层是硬件层。NVIDIA GPU 里的 Tensor Core 对低精度矩阵乘法的支持很不相同。越新的架构对 FP8、INT8、INT4 的支持越完善。高速解码方案一定要选对硬件代际否则软件层做了再多的优化也无法发挥低精度计算的优势。第二层是驱动和运行时层。CUDA 驱动、NVIDIA Container Toolkit、CUDA runtime 是否匹配决定了 GPU 能不能被容器和外部进程正常使用。很多号称已经部署了加速方案的项目实际卡在驱动版本不匹配上。第三层是推理引擎层。直接使用 PyTorch 的generate()方法当然也能跑但它很难把 page attention、continuous batching、KV Cache 量化这些高级优化全部发挥出来。这时候要用 TensorRT-LLM、vLLM 等推理引擎。第四层是部署层。模型做成了什么服务暴露什么协议用什么方式上线。NVIDIA NIM 这类预构建微服务就是把模型、推理引擎、运行环境打包好的产物。它降低的是工程团队的部署门槛而不是模型本身的计算成本。把四层放在一起看你就会发现LPX 系统不是某一个开关而是一条完整的链路硬件层决定算力上限。驱动和运行时决定显卡能不能被用起来。推理引擎决定 decode 效率。部署层决定服务稳定性。所以排查“模型跑不快”的问题时不能只调一个环节。很多人把量化配置改了发现没有明显提速就以为是量化没用。实际上可能是驱动层没有启用正确的精度支持也可能是推理引擎没有真正加载量化后的权重。4. 环境准备驱动、CUDA 与 NVIDIA Container Toolkit以下操作以 Ubuntu 22.04 为例顺便覆盖几个最容易踩坑的地方。NVIDIA 驱动的安装方式有很多种这里推荐一种适合服务器环境的组合系统包管理器安装驱动 Docker 中提供 CUDA 运行时。第一步确认显卡型号和当前驱动。lspci | grep -i nvidia nvidia-smi如果系统里已经装过驱动nvidia-smi会显示驱动版本和显卡型号。如果没有输出说明驱动还没装好。第二步安装驱动。Ubuntu 上最简单的办法是通过 Ubuntu 官方源安装。sudo apt update sudo apt install nvidia-driver-535安装完成后重启。sudo reboot重启后再次运行nvidia-smi确认驱动版本和 CUDA 版本。不同显卡对驱动版本的最低要求不同版本号请以实际硬件和官方支持矩阵为准。第三步安装 Docker 和 NVIDIA Container Toolkit。Docker 安装不展开这里重点说 Container Toolkit。curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit第四步配置 Docker 使用 NVIDIA runtime。sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker第五步验证容器能不能看到 GPU。docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi如果容器里能正常输出显卡信息说明 GPU 已经被 Docker 正确暴露。这时再跑推理框架就不会出现“容器里看不到 GPU”的问题。一个常见坑是宿主机驱动版本太老容器里的 CUDA 镜像版本太高导致容器启动时报驱动不兼容。这个问题的最快解决方法是把 CUDA 镜像版本降到驱动支持的范围内。另一个常见坑是安装 Container Toolkit 后没有 restart Docker导致--gpus参数无效。在继续下面的步骤之前先确认这一条。5. 用真实推理引擎搭建一个高速解码服务环境准备好之后不要急着写 PyTorch 推理脚本先用一个成熟推理引擎把基线跑通。这里以 vLLM 为例因为它的安装简单API 友好而且可以很快验证解码性能。首先确认 Python 版本和虚拟环境。python3 -m venv vllm-env source vllm-env/bin/activate pip install --upgrade pip然后安装 vLLM。由于安装包体积较大建议在 Python 3.10 以上的环境里安装具体版本请以官方 PyPI 页面为准。pip install vllm接下来编写一个最简推理脚本。from vllm import LLM, SamplingParams # 模型名称可以替换成你实际使用的模型 model_name Qwen/Qwen2.5-7B-Instruct llm LLM( modelmodel_name, tensor_parallel_size1, dtypefloat16, max_model_len8192, ) prompt 写一段关于高速解码原理的简短介绍 outputs llm.generate([prompt], SamplingParams(max_tokens512)) for output in outputs: print(output.outputs[0].text)这段代码中的tensor_parallel_size1表示单卡推理。如果你的显存足够大不需要多卡并行如果后续希望开多卡再调整为 2 或 4。跑通生成后下一步是提高性能。vLLM 支持命令行方式直接启动一个兼容 OpenAI 协议的 HTTP 服务。python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9启动后可以通过 curl 做一个快速请求验证。curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, prompt: 请用一句话解释高速解码, max_tokens: 200 }如果返回了 JSON 格式的choices字段说明服务已经正常工作。这一步看起来简单但它已经完成了 prefill 和 decode 的分离、KV Cache 管理、显存池化等一系列优化。注意这里的dtypefloat16是一个很安全的配置。如果在你的硬件上支持 FP8也可以尝试dtypefloat8或者通过量化配置加载 FP8 权重。但不要一开始就在所有模型上都用最低精度先跑通再量化和优化。6. 小型模型高速解码的关键优化手段当一个服务能跑之后下面这些优化手段就值得依次测试。它们是“高速解码”的真正来源。6.1 权重量化与激活量化对小型模型来说FP8 或 INT4 权重量化能把模型体积压缩到原来的一半甚至四分之一。decode 阶段需要读取的权重数据量随之减少显存带宽压力也随之下降。但要注意量化不是免费的。过度量化可能造成明显的精度下降。工程上的推荐做法是先用量化感知评估脚本测试代表性数据集确认指标在可接受范围内再上线。6.2 KV Cache 管理与量化推理引擎会为每一条请求分配 KV Cache 空间。如果请求较长KV Cache 会占掉大量显存。vLLM 这类引擎已经内置 PagedAttention显存碎片问题会好很多。更高阶的做法是压缩 KV Cache。常见方案包括 KV Cache 量化、更节省的缓存策略、以及针对长上下文场景的调参。对小型模型来说把 KV Cache 省下来的显存留给更大 batch size通常能直接提高整体吞吐。6.3 Continuous Batching传统批处理方式会让同一批请求必须一起完成短请求要等长请求。连续批处理则允许在 token 级别动态插入和退出请求GPU 的空闲窗口被填补整体吞吐能明显提高。这个优化主要是推理框架的职责。vLLM、TensorRT-LLM 都支持类似机制不需要业务代码做额外改动。如果你的服务框架是自研的那么这里可能是收益最大的改造点。6.4 Prefill 和 Decode 分离当系统同时有长提示词请求和短提示词请求时prefill 的高计算需求与 decode 的低计算需求会互相干扰。部分生产系统会拆成 prefill 节点和 decode 节点分离部署各自按特点做资源配置。这个方案更适合已经有一定并发规模的项目。如果只是单机服务先不必急着拆把 batch size 和显存分配调好收益可能更直接。6.5 Speculative Decoding推测解码是一种用“小型草稿模型先猜大模型再验证”的加速方案。如果草稿模型一次性猜出多个 token而主模型验证后全部接受那么一次解码步骤可以产生多个 token用户感知速度会大幅提升。这个方案对 tokenizer 一致性有要求草稿模型和主模型需要共享词表。对部署能力要求也比较高但在代码生成、聊天回复这类场景里收益通常很可观。7. 运行结果与验证方法光看生成文本没有意义必须用量化指标评估解码速度。这里提供一个简单的 Python 测速脚本。import time from vllm import LLM, SamplingParams model_name Qwen/Qwen2.5-7B-Instruct llm LLM(modelmodel_name, dtypefloat16, max_model_len8192) prompt 高速解码对 LLM 服务的重要性是什么 max_tokens 1024 start time.time() outputs llm.generate([prompt], SamplingParams(max_tokensmax_tokens)) cost time.time() - start generated_text outputs[0].outputs[0].text token_count len(outputs[0].outputs[0].token_ids) print(f耗时: {cost:.2f} s) print(f生成 token 数: {token_count}) print(f平均速度: {token_count / cost:.2f} tokens/s)由于脚本里包含了 prefill 和 decode 的完整时间所以它测的是端到端速度不代表纯 decode 速度。要看纯 decode 性能需要把 prefill 耗时拆出去或者用不同长度的 max_tokens 做多组测试再对比增速。判断结果有一个简单的经验值在 7B 参数、单卡 A 系列或 RTX 4090 级别硬件上如果端到端速度只有个位数 tokens/s说明配置还有优化空间如果达到几十 tokens/s说明基本发挥了硬件能力。具体数值因显卡、显存、模型格式和量化方式差异很大不能一概而论。除了脚本测速生产环境还需要记录三个关键指标TTFTTime to First Token用户感受到的首 token 延迟。TPOTTime Per Output Token每个输出 token 的间隔时间。Throughput整个服务每秒能处理的请求数。这三个指标对应不同的优化方向。TTFT 高可能要优化 prefill 和队列调度TPOT 高要重点看 decode 和显存带宽吞吐低则要调整 batch size 和并发策略。8. 常见问题与排查思路问题现象可能原因排查方式解决方案容器内无法使用 GPUNVIDIA Container Toolkit 未安装或未重启 Docker在容器外运行nvidia-smi在容器内再运行一次安装 toolkit执行sudo nvidia-ctk runtime configure --runtimedocker并重启 docker模型加载后显存不足并发请求太多KV Cache 占用过大查看nvidia-smi显存占用检查推理引擎的显存分配配置调低gpu-memory-utilization限制并发数启用 KV Cache 量化量化后精度下降严重量化精度选择不当或未做校准在代表性数据集上对比量化前后输出改用 FP8 替代 INT4或做带校准数据的训练后量化生成速度依然很慢仍然使用默认 PyTorchgenerate()接口确认是否通过 vLLM / TensorRT-LLM 加载换用成熟推理引擎再验证速度驱动版本与 CUDA 版本不匹配宿主机驱动过旧运行nvidia-smi查看 CUDA 版本升级驱动或降低容器 CUDA 镜像版本推理引擎启动后卡住正在编译 CUDA kernel首次加载耗时查看日志和 CPU 占用首次启动等待即可生产环境可提前预热这里特别提醒一个常见误区只看 GPU 利用率是不够的。如果nvidia-smi显示 GPU 利用率 90%不代表 decode 已经最优。decode 阶段的利用率高有可能是计算单元在低效地等待数据。所以一定要以 tokens/s 和首 token 延迟作为核心指标。9. 最佳实践与生产建议最后一章整理几条值得长期坚持的工程建议。第一所有优化必须有基线。没有基线就无法判断改动是否有效。建议把模型名称、量化精度、批大小、GPU 型号、输入长度、输出长度、tokens/s 这七个字段记录下来作为性能档案长期维护。第二不要同时改多个变量。比如先只改精度测一轮再只改批大小测一轮。如果同时改了精度和批大小出问题后很难定位是哪个变量导致。第三量化前先确认硬件支持。不是所有 GPU 都支持 FP8。如果硬件不支持强行使用 FP8 格式会非常慢。更稳妥的做法是先查官方特性表再决定精度方案。第四安全边界要提前处理。模型服务如果暴露在公网必须做鉴权。建议把模型服务放在内网由业务服务统一对外。涉及模型文件、用户数据、日志时遵循最小权限原则不要把所有用户数据写进同一个日志文件。第五生产环境变更前先从测试环境验证。驱动升级、CUDA 版本变化、推理引擎版本升级都可能影响已调好的性能。建议在测试环境先运行同一套基线脚本确认性能没有回退再发布到生产。第六模型权重和代码要分离。不要把模型文件散落在业务代码仓库里。用模型目录、版本号、清单文件统一管理既能追踪来源也能在异常时快速回滚。最后一点提醒小型模型高速解码的收益最终是综合结果。硬件选型、驱动版本、推理引擎、量化策略、KV Cache 管理、并发调度每一个环节都可能成为短板。与其执着于某一个“神器”开关不如把整条链路纳入监控让每次优化都有依据。10. 收尾一个值得立刻执行的动作如果你现在手里正好有一个小型模型在跑别急着换框架或换卡。先做三件事把当前 tokens/s 测出来把当前推理引擎和精度格式记录一份再按本文的步骤跑一遍 vLLM 基线。多数情况下你会很快发现在“预填充和生成混合”、“KV Cache 分配不合理”、“量化没有真正生效”这些环节里至少有一个是明显的瓶颈。把它们逐个解决之后再回到开头说的那个问题为什么同样的显卡别人能让小型模型跑得更快答案其实很简单——别人把访存瓶颈、显存管理、调度策略都当成系统问题来处理了而不是只靠加一张更好的卡。