vllm-ascend 性能优化

用昇腾卡起 vllm 服务，最容易卡在两种状态：一是能跑通但吞吐上不去，二是并发一加就 OOM 或报错，却不知道是参数问题还是算子问题。这篇不讲概念，直接给一套按顺序走的排查路径：先量基线，再分显存、并行、调度三层逐项验，每层告诉你动哪个参数、看什么指标、什么情况下别硬调。

用昇腾卡起 vllm 服务，最常见的两种卡壳状态：一种是一切正常但吞吐死活上不去，另一种是并发一加就 OOM 或直接报错，你却不知道是参数配错了还是算子没适配。这两种问题的排查路径完全不同，混着查只会浪费时间。

下面给一套按顺序走的流程：先量基线，再分显存、并行、调度三层逐项验，每层说清楚动哪个参数、看什么指标、什么情况下别硬调。别跳步，跳步之后你看到的所有数字都没法归因。

先量基线，再谈优化

优化这件事最大的坑是「凭感觉」。没有基线，你改完一个参数之后看到的吞吐变化，可能只是这次请求恰好短了一点。基线要固定一份输入长度分布和并发档位，跑出延迟与吞吐两组数，作为后续每一次对比的参照。

1. 固定测试条件选定一批请求，记录各自的输入长度与输出长度分布；同一并发档位、同一批次配置反复跑三次，看波动范围，波动大的话先把环境因素排掉。
2. 拆开记两类延迟首 token 延迟和单 token 输出速度分开记录。前者主要受排队和预填充影响，后者受解码与显存带宽影响，混成一个平均值会掩盖真实瓶颈。
3. 量链路底线到 /tools/speed-test 先测出你的网络与端到端延迟底线，再判断慢是出在模型侧还是链路侧；如果链路本身就慢，后面调模型参数收益会很有限。
4. 留可复现记录把请求批次、并发、批次大小、启动参数写在一起存档。换任何一项条件都得重测，旧基线不再可比。

显存层：先解决占满与碎片

显存问题要拆成三块看：权重、KV 缓存、中间激活。哪块顶格就先压哪块，一上来就降批量往往压错了地方，还顺带把吞吐砍掉一截。用昇腾卡跑长上下文时，KV 缓存经常是真正的占用大头。

• 显存没满却报分配失败，多数是碎片问题，可以试调显存预留比例后重启服务，而不是继续降批量。
• 量化能省权重显存，但会换掉一部分精度；精度敏感的任务要单独做质量回归再决定，别直接上生产。
• 长上下文场景优先限住最大长度，比降并发更划算，因为并发直接影响吞吐。
• 每次只调一个显存相关参数，记录峰值占用和是否报错，方便定位是哪一项真正起效。

并行层：卡数、切分方式与落点

多卡不是万能药。先确认真实瓶颈是显存不够还是算力不够，算力不够时加卡不一定提速，甚至可能因为通信开销变慢。这个判断错了，后面所有并行配置都是白调。

• 张量并行切分越细，卡间通信开销越大；小模型多卡往往比单卡慢，这类情况下加卡方案不适用。
• 多机多卡要额外关注网络带宽与拓扑，跨机通信常常吃掉一半收益。
• 多模态或长序列任务里非均匀负载明显，均匀切分可能让某张卡一直等，需要按实际负载再看切分策略。
• 加卡之前先确认服务启动参数里的并行度是否和实际卡数匹配，配置写错比硬件不够更常见。

调度层：批量、并发与请求侧

连续批处理是吞吐的主要来源，但它不是越高越好。排队不设上限，延迟会被拖长，用户端体验反而变差。调度层的核心动作是分流和限额，而不是把所有请求塞进同一个队列。

1. 给排队设上限限制等待队列长度，超出的请求直接返回，避免长尾延迟把整体指标拖垮。
2. 按长度分流短请求走一路、长请求走一路，避免长任务把短任务堵在后面，这是提升尾延迟最直接的一招。
3. 请求侧先动手限制输出长度、减少重复提示、复用前缀，这些往往比调服务端参数见效更快，而且不占显存。
4. 一次只动一个参数记录前后指标，多个参数一起改，出问题会分不清是谁的锅。到 /rankings 或 /price-watch 对照当时的公开数据，判断你的配置是否偏离同规模服务的常见区间。

哪些情况调参救不了

有些问题从现象上很像参数没配好，其实是适配或硬件层面的硬限制。把这类情况识别出来，比在参数里反复试要省时间得多。

最后提醒一句：别把调优当成无限堆参数。配置越复杂，出问题时越难回滚。建议留下一个最小可用参数集，每一项都写清楚为什么加、什么时候可以去掉。想了解同类服务当下的公开参数区间，可以到 /sites 和各官方 API 资料页核对当时的数字。