本地大模型能扛多少并发？测到达率、首 Token 与排队

模型装进一张显卡，团队仍可能等到无法使用。显存预算只检查必要的内存条件；4-bit 对照检查缩小权重后任务质量是否还合格。本页要回答另一件事：**在固定的模型与服务配置下，请求以多快速度持续到来，系统开始无法满足响应目标？**把实测边界带进本地与云 API 部署决策，不要写成“某个 8B 模型支持 N 个用户”的通用数字。

任务质量与服务性能也要分开。回答很快但内容错误，仍不能交付。以下负载试验以候选模型已通过固定任务案例为前提，再验证它能否以预期流量持续交付这些合格回答。

先分清四个数字

数字	记录什么	不能据此推出什么
提供的到达率	每秒计划到来的请求及实际发出的速率	服务已经完成这些请求，或压测器足够快
在途并发	已接入但未结束的请求；可见时拆为运行和等待	固定的每秒服务容量；每条请求占用时间不同
完成吞吐	每秒结束并成功返回的请求	延迟达标，或队列没有持续积压
服务合格吞吐	同时满足预设服务目标的完成请求数 ÷ 测量秒数	回答本身已通过业务质量复核

入口并发上限可以把等待从服务器移到压测客户端。vLLM 的 --request-rate 设置目标到达过程，--max-concurrency 限制压测器同时发出的未完成请求。上限一旦触发，必须把客户端等待与从计划到达到最终完成的时间一起记录。完成吞吐变高而待处理请求逐窗口增长，不能叫可持续容量。

提高负载前先写服务目标

明确任务与流量切片，固定模型修订版、权重文件、tokenizer 与模板、服务及驱动版本、GPU 数、是否完整驻留 GPU、上下文上限、KV 和前缀缓存、批量策略、实例数及入口限流。任一条件变化，都可能移动容量边界。

请求样本应覆盖输入与输出 token 的常见长度和长尾，并单独记录共享前缀比例。若要测首 Token，客户端必须使用流式输出。先写预热方式、测量窗口、失败处理和服务目标，例如 P95 首 Token 时间（TTFT）、P95 逐输出 token 时间（TPOT）、P95 完整响应时间、允许的拒绝比例、不得 OOM，以及等待队列不能持续增长。阈值属于你的产品要求，不是服务框架的默认保证。

对至少生成两个 token 的请求，vLLM 将 TPOT 定义为“完整响应耗时减 TTFT，再除以输出 token 数减一”。逐输出间隔 ITL 则记录相邻流式事件之间的时间；一个事件可能带多个 token，所以 ITL 与 TPOT 不总相等。写清目标采用哪一种口径。只输出一个 token 的请求没有有意义的请求级 TPOT，不能悄悄以零参与分位数。

跑到达率阶梯，再复现突发

1. 先验压测器。 用低到达率发送少量请求，对照计划与实际发送时间、状态码、token 数和时间戳。若客户端自身无法按计划发出流量，先修压测器。
2. 把冷加载与稳定运行分开。 记录一次冷加载和预热，再按多个时间窗口观察预热后的请求。若生产环境经常卸载模型，应把冷请求按真实比例加入正式流量，不能只展示热运行。
3. 一次只调到达率。 保持模型、请求混合、上下文、缓存状态和客户端并发上限不变，分档提高有限的每秒到达数。每档保留发送、完成、失败、取消与拒绝数，并在进入下一档前让在途请求排空。
4. 回测通过边界。 在第一档失败与上一档通过之间细分，并重放真实到达轨迹或代表性突发。单一平均速率会漏掉长请求集中到来的时刻。

vLLM 的 vllm bench serve 可设置有限的 --request-rate，报告 TTFT、TPOT、ITL 与端到端分布。先用随机输入输出长度确认采集正常，容量结论则必须换成获准使用的代表性请求。默认无限到达率会尽快把请求全发出去，测的是饱和情况。重复 Prompt 或固定随机种子也可能预热前缀缓存，让吞吐虚高；把缓存状态写入记录，若真实流量不重复前缀，就换种子或重置缓存。

同时读取 vLLM 的 /metrics：运行与等待请求数、服务端排队时间、vllm:kv_cache_usage_perc、TTFT、TPOT 和完整响应直方图。KV 指标是已用缓存块的 0 到 1 比例，不是物理显存百分比。另记设备显存峰值、适用时的抢占或 CPU 卸载、OOM 与 HTTP 错误。客户端 TTFT 从实际发出请求起算，包含服务内部等待，却不包含压测器发出前自行排队的时间。服务端队列是解释 TTFT 来源的指标，不要与 TTFT 简单相加。

Ollama 提供的证据不同。Generate API 返回加载、Prompt 处理、生成时长与 token 数；流式压测客户端仍需给“计划到达、实际发送、首个输出、最终完成”分别打时间戳，才能算用户等待。ollama ps 或 /api/ps 给出已加载模型、实际上下文与 size_vram，但后者不是逐请求 KV 块占用率。显式记录 OLLAMA_NUM_PARALLEL、OLLAMA_CONTEXT_LENGTH 与 OLLAMA_MAX_QUEUE：并行请求会扩大上下文内存需求，队列满时可返回 HTTP 503。503、OOM 与回答质量失败应分别统计。

案例一：短 FAQ 请求先被排队拖慢

团队用固定模型回答公开商品问题，每条输入约 500–1000 token，输出上限 120 token。运行前先写一组用于教学的候选 SLO：P95 TTFT 不超过 1 秒、P95 TPOT 不超过 80 毫秒、P95 客户端等待不超过 200 毫秒、P95 服务端排队不超过 300 毫秒、无 OOM 与 503、等待数不持续上升。这些是预先设定的目标，不是硬件实测结果。

团队将 0.5、1、2 请求/秒作为分开的稳定负载档，观测单元格在真正运行前保持空白。如果 2 请求/秒时完成吞吐继续上升，但等待数逐窗口增加且 P95 TTFT 超线，即使 KV 仍有余量、没有 OOM，这档也失败。工作表只写“上一档已测且通过”，随后在该档与 2 请求/秒之间细测；不能把它直接叫最大用户并发数。

案例二：相同均值掩盖长文档突发

某文档助手在一段工作时间内平均每秒收到一个请求，其中一些带约 8000 输入 token、最多生成 600 输出 token，并在审核截止前集中到来。团队保持相同平均到达率，比较均匀到达与真实突发轨迹；服务配置和任务构成保持一致。测试前分别设 TTFT、完整响应、错误率和排队门槛，不凭显卡型号预填结果。

若候选服务是 Ollama，记录实际上下文长度与 OLLAMA_NUM_PARALLEL。把并行数从一改为四，应作为另一轮配置试验：眼前可能少排队，但上下文内存需求随之增大；突发也可能占满 OLLAMA_MAX_QUEUE 后返回 503。发生哪一种必须实测。均匀流量通过不能为突发背书。若突发未达标，可试入口接纳规则、为长文档单独排队或增加服务容量，再用同一轨迹与质量案例复测。

填写服务负载试验表

下方工作台可以填写、复制与导出。每个到达率或突发阶段都复制一行，保留原始计数、单位和判断依据。未运行的表格应保持空白，不要写成通过：

分组	最少要留下的证据
固定条件	模型与文件修订版、服务版本、GPU 驻留、上下文、KV 与缓存策略、客户端与服务端接纳上限
流量形状	任务切片、输入输出 token 分布、前缀复用、目标与实际到达率、突发方式、预热及测量时长
逐档观测	发送/完成/拒绝/失败/OOM；P95 TTFT、TPOT、完整响应；客户端与服务端分别排队；运行和等待趋势、KV 比例、设备峰值
最终决定	预设门槛、每秒满足服务目标的完成请求、最后通过的持续到达率、失败维度、负责人和复测触发

计算到达请求中有多少满足用户目标时，拒绝、超时与取消仍留在原始到达批次的分母里。若工具只按完成请求报告合格吞吐，又没有包括客户端等待，须把缺少的等待与失败数单列。压测器真实达到目标速率、有足够请求观察尾部、队列不持续堆积，才可判定某档可持续。

常见问题

能用剩余显存算最大并发吗？ 不能。余量没有说明 Prompt 预处理算力、输出速度、请求长度、调度方式或可接受等待。它只能帮助选一组需要实测的起步配置。

该看请求/秒，还是 token/秒？ 两者都留。请求到达和完成说明供需；输入与输出 token 分布解释为什么同样条数会带来不同工作量。只看输出 token/秒，还可能奖励任务不需要的冗长回答。

平均延迟很好，可以直接上线吗？ 仍需检查约定分位数、失败请求、客户端等待和队列变化。总体平均数可能变好，最慢的关键任务切片却已不可用。

不适用边界

最后通过的一档只对记录中的硬件、模型、软件、上下文、流量组合、缓存状态和服务目标有效。不同突发、多模态输入、CPU 卸载、增加实例或更新模型，都要重测。低流量服务需要更长时间才可能估计尾部延迟。压测器、网络或客户端连接数也可能先到瓶颈；购买硬件或公布容量结论前，应核对实际到达并从合适的客户端复跑。上线后若模型 API 限流或中断，另用服务降级阶梯规划重试、排队与接管。