企业官网建设流程全解析

• 后端
• 人工智能
• 模型推理服务
• 集群管理
• 可观测性

在 GPUStack 集群中部署 Qwen3-8B 时，选择正确的推理引擎并叠加合理的优化项，对吞吐量的影响远超想象。本文基于 GPUStack 官方性能实验室在单张 Ascend 910B NPU 上的实测数据，给出从引擎选型、W8A8 量化到前缀缓存（Prefix Caching）的完整调优路径：基线 vLLM 在 ShareGPT 数据集上总吞吐为 3143.94 tok/s，经三步优化后提升至 6256.39 tok/s（+99.0%）。读完本文，你将掌握 GPUStack 推荐的 MindIE 启动命令、vLLM bench 复现方法，以及每个优化项在源码层面的作用机制与适用边界。

结论速览：推荐的吞吐优化配置

GPUStack 官方在 docs/performance-lab/qwen3-8b/910b.md 中给出的推荐优化命令如下：

# 这是一个简化的 vLLM 风格命令。GPUStack 会将其中的参数映射为对应的 # MindIE JSON 配置，并通过 mindieservice_daemon 启动服务。 mindie serve vllm-ascend/Qwen3-8B-W8A8 --enable-prefix-caching

优化前后各基准用例的对比结果：

在采用这套配置之前，需要明确以下边界条件（原文档注记）：

1. 基准测试并未穷尽所有优化组合。例如，实验以默认配置下表现最优的推理引擎作为进一步调优的起点，这种剪枝方式得到的是局部最优解，未必是全局最优。
2. 还存在依赖具体用户场景的优化手段，包括 max batch size、调度配置、扩展 KV cache、CUDA graph、Torch Compile 等，本文结论可作为更精细化调优的起点。
3. 测试在特定硬件与软件栈上进行，推理引擎的演进可能带来新的结论。

优化目标

本次调优的核心目标非常明确：在高并发请求场景下实现高吞吐。它与 docs/performance-lab/qwen3-8b/h100-latency.md（H100 低并发低延迟优化）形成互补：本实验关注并发压力下的总 Token 吞吐（Total TPS），而非单请求延迟。

实验环境与基准方法

模型与硬件

• 模型：Qwen/Qwen3-8B（结论表中同时使用了 W8A8 量化权重vllm-ascend/Qwen3-8B-W8A8）
• 硬件：单张 Ascend 910B NPU
• 引擎版本：vLLM-Ascend v0.9.1、MindIE 2.1RC1

值得说明的是，GPUStack 的模型目录 gpustack/assets/model-catalog-modelscope.yaml 中已经为 Qwen3-8B 在 Ascend 910B 上预置了与本文结论一致的规格：mode: throughput时使用vllm-ascend/Qwen3-8B-W8A8、后端为 MindIE、后端参数为--enable-prefix-caching与--max-seq-len=32768（对应文件中第 74–85 行），这进一步印证了官方把该配置作为 Ascend 910B 上的默认吞吐优化方案。

基准数据集

1. ShareGPT（真实对话数据）；
2. 不同序列长度的随机数据集（固定随机种子保证可复现）：
   • Very long prompt：32000 输入 token、100 输出 token
   • Long prompt：4000 输入 token、200 输出 token
   • Medium prompt：2000 输入 token、100 输出 token
   • Short prompt：128 输入 token、4 输出 token

基准命令

使用vLLM bench CLI作为统一的压测工具：

# 准备 ShareGPT 数据集 wget https://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json # 在 ShareGPT 数据集上压测 vllm bench serve --model Qwen/Qwen3-8B --backend openai-chat --endpoint /v1/chat/completions --dataset-name sharegpt --dataset-path ShareGPT_V3_unfiltered_cleaned_split.json --num-prompts 1000 # 在随机数据集上压测（固定 seed 保证可复现） vllm bench serve --model Qwen/Qwen3-8B --backend openai-chat --endpoint /v1/chat/completions --dataset-name random --random-input-len 4000 --random-output-len 200 --num-prompts 500 --seed 42

其中--random-input-len与--random-output-len需按上面数据集清单中的各档长度分别调整，例如 Very Long Prompt 用例使用--random-input-len 32000 --random-output-len 100 --num-prompts 100。

实验一：推理引擎选型（vLLM vs MindIE）

vLLM 基线

启动命令：

vllm serve Qwen/Qwen3-8B

ShareGPT 压测结果：

============ Serving Benchmark Result ============ Successful requests: 1000 Benchmark duration (s): 133.23 Total input tokens: 217393 Total generated tokens: 201469 Request throughput (req/s): 7.51 Output token throughput (tok/s): 1512.21 Peak output token throughput (tok/s): 2821.00 Peak concurrent requests: 1000.00 Total Token throughput (tok/s): 3143.94 ---------------Time to First Token---------------- Mean TTFT (ms): 43963.16 Median TTFT (ms): 41177.19 P99 TTFT (ms): 91086.90 -----Time per Output Token (excl. 1st token)------ Mean TPOT (ms): 125.09 Median TPOT (ms): 122.07 P99 TPOT (ms): 269.65 ---------------Inter-token Latency---------------- Mean ITL (ms): 112.90 Median ITL (ms): 78.96 P99 ITL (ms): 280.07 ==================================================

MindIE 默认配置

启动命令：

# 这是一个简化的 vLLM 风格命令。GPUStack 会将其中的参数映射为对应的 # MindIE JSON 配置，并通过 mindieservice_daemon 启动服务。 mindie serve Qwen/Qwen3-8B

ShareGPT 压测结果：

============ Serving Benchmark Result ============ Successful requests: 1000 Benchmark duration (s): 74.36 Total input tokens: 217393 Total generated tokens: 201609 Request throughput (req/s): 13.45 Output token throughput (tok/s): 2711.10 Peak output token throughput (tok/s): 4588.00 Peak concurrent requests: 1000.00 Total Token throughput (tok/s): 5634.45 ---------------Time to First Token---------------- Mean TTFT (ms): 8242.22 Median TTFT (ms): 8298.00 P99 TTFT (ms): 18074.38 -----Time per Output Token (excl. 1st token)------ Mean TPOT (ms): 788.31 Median TPOT (ms): 204.41 P99 TPOT (ms): 6547.97 ---------------Inter-token Latency---------------- Mean ITL (ms): 155.96 Median ITL (ms): 45.35 P99 ITL (ms): 218.57 ==================================================

结论：MindIE（5634.4 tok/s）> vLLM（3143.94 tok/s），引擎切换本身带来了约+79.2%的吞吐提升。

从实现层面看，GPUStack 的 MindIE 后端并不是简单地把参数透传给mindieservice_daemon，而是在 gpustack/worker/backends/ascend_mindie.py 中完成了一整套"参数 → MindIE JSON 配置"的翻译与注入：

• 用户以mindie serve传入的 CLI 参数会进入AscendMindIEParameters.from_args_and_envs()（第 176 行起）解析，覆盖各项默认值；
• 服务器启动时（AscendMindIEServer._start()，第 1122 行起）从_get_mindie_config_json()读取 MindIE 服务模板配置（第 2063 行起），再把解析后的参数写入ServerConfig、BackendConfig、ModelDeployConfig、ScheduleConfig等区块，最后以mindieservice_daemon为入口在容器内启动服务（第 1642–1646 行）。

这解释了为什么文档中的命令都带有"GPUStack maps arguments to the corresponding MindIE JSON configuration"的注释——吞吐差异不仅来自引擎本身，也来自 GPUStack 启动时注入的默认环境变量，例如强制开启连续批处理（MINDIE_LLM_CONTINUOUS_BATCHING=1）、异步调度（MINDIE_ASYNC_SCHEDULING_ENABLE=1、TASK_QUEUE_ENABLE=1）、ATB 计算后端与 80% NPU 显存配额（NPU_MEMORY_FRACTION=0.8）等（第 1164–1210 行）。这些"默认就绪"的调度与内存配置正是 MindIE 在高并发下拉开差距的原因之一。

实验二：W8A8 量化（MindIE）

启动命令：

# GPUStack 会将参数映射为对应的 MindIE JSON 配置， # 并通过 mindieservice_daemon 启动服务。 mindie serve vllm-ascend/Qwen3-8B-W8A8

ShareGPT 压测结果：

============ Serving Benchmark Result ============ Successful requests: 1000 Benchmark duration (s): 69.32 Total input tokens: 217393 Total generated tokens: 201315 Request throughput (req/s): 14.42 Output token throughput (tok/s): 2903.93 Peak output token throughput (tok/s): 4799.00 Peak concurrent requests: 1000.00 Total Token throughput (tok/s): 6039.79 ---------------Time to First Token---------------- Mean TTFT (ms): 5834.61 Median TTFT (ms): 5648.87 P99 TTFT (ms): 11181.32 -----Time per Output Token (excl. 1st token)------ Mean TPOT (ms): 822.87 Median TPOT (ms): 188.93 P99 TPOT (ms): 7710.20 ---------------Inter-token Latency---------------- Mean ITL (ms): 148.97 Median ITL (ms): 45.31 P99 ITL (ms): 97.87 ==================================================

在 MindIE 默认配置之上，切换到 W8A8（权重-激活 8bit 量化）权重vllm-ascend/Qwen3-8B-W8A8后，总吞吐从 5634.45 进一步提升到 6039.79 tok/s，增量约+7.2%。这与性能实验室总览文档 docs/performance-lab/overview.md 中"量化是最大化吞吐的关键技术"的观察一致——W8A8 同时压缩了权重与激活的访存带宽，对 Ascend NPU 这类带宽敏感场景收益显著。

实验三：开启 Prefix Caching（前缀缓存）

启动命令：

# GPUStack 会将参数映射为对应的 MindIE JSON 配置， # 并通过 mindieservice_daemon 启动服务。 mindie serve vllm-ascend/Qwen3-8B-W8A8 --enable-prefix-caching

ShareGPT 压测结果：

============ Serving Benchmark Result ============ Successful requests: 1000 Benchmark duration (s): 66.96 Total input tokens: 217393 Total generated tokens: 201517 Request throughput (req/s): 14.93 Output token throughput (tok/s): 3009.64 Peak output token throughput (tok/s): 4985.00 Peak concurrent requests: 1000.00 Total Token throughput (tok/s): 6256.39 ---------------Time to First Token---------------- Mean TTFT (ms): 5320.32 Median TTFT (ms): 5159.10 P99 TTFT (ms): 10384.83 -----Time per Output Token (excl. 1st token)------ Mean TPOT (ms): 796.13 Median TPOT (ms): 183.35 P99 TPOT (ms): 7267.96 ---------------Inter-token Latency---------------- Mean ITL (ms): 141.91 Median ITL (ms): 43.55 P99 ITL (ms): 115.20 ==================================================

开启前缀缓存后总吞吐达到 6256.39 tok/s，比量化后继续提升约+3.6%，同时 P99 TTFT 从 11181.32 ms 下降到 10384.83 ms。前缀缓存对 ShareGPT 这类包含大量共享 system prompt / 多轮对话前缀的真实流量收益明显——相同前缀只需计算一次 KV，可复用给后续请求。

在源码层面，--enable-prefix-caching的生效路径清晰可见（gpustack/worker/backends/ascend_mindie.py）：

• 参数解析：parser.add_argument("--enable-prefix-caching", action=argparse.BooleanOptionalAction, ...)（第 509–514 行），支持--no-enable-prefix-caching显式关闭；
• 配置注入：当params.enable_prefix_caching为真时，写入schedule_config["enablePrefixCache"] = True并把plugin_params设为{"plugin_type": "prefix_cache"}（第 1466–1472 行）；
• 兼容性约束：_validate()中规定开启前缀缓存时不允许同时使用--rope-scaling（第 1088–1092 行），且数据并行--data-parallel-size > 1时禁止开启（第 1102–1105 行），这与 MindIE 调度器对缓存一致性的要求有关。

实验四：Batch Size 调优（MindIE）

启动命令：

# GPUStack 会将参数映射为对应的 MindIE JSON 配置， # 并通过 mindieservice_daemon 启动服务。 mindie serve vllm-ascend/Qwen3-8B-W8A8 --enable-prefix-caching --max-batch-size=400 --max-prefill-batch-size=200

ShareGPT 压测结果：

============ Serving Benchmark Result ============ Successful requests: 1000 Benchmark duration (s): 69.07 Total input tokens: 217393 Total generated tokens: 201424 Request throughput (req/s): 14.48 Output token throughput (tok/s): 2916.34 Peak output token throughput (tok/s): 6017.00 Peak concurrent requests: 1000.00 Total Token throughput (tok/s): 6063.89 ---------------Time to First Token---------------- Mean TTFT (ms): 6335.34 Median TTFT (ms): 5812.45 P99 TTFT (ms): 11260.65 -----Time per Output Token (excl. 1st token)------ Mean TPOT (ms): 581.93 Median TPOT (ms): 167.14 P99 TPOT (ms): 5501.66 ---------------Inter-token Latency---------------- Mean ITL (ms): 143.92 Median ITL (ms): 70.27 P99 ITL (ms): 281.16 ==================================================

将--max-batch-size从默认 200 提高到 400、--max-prefill-batch-size从默认 50 提高到 200 后，吞吐不升反降（6039.79 → 6063.89，反而低于实验三的 6256.39），TTFT 与 ITL 的 P99 也明显恶化。结论：在该硬件与并发模型下，batch size 调优无正向收益（汇总表中标记为 "-"），默认值反而更优。

这也提示了一个重要经验：batch size 并非越大越好，它与显存中 KV cache 的可用量、调度器预取策略以及实际并发度强相关。在 GPUStack 中，--max-batch-size的合法范围是 [1, 5000]，--max-prefill-batch-size必须落在 [1,--max-batch-size] 区间内（gpustack/worker/backends/ascend_mindie.py 第 823–833 行），同时 GPUStack 会做max_prefill_batch_size = min(max_prefill_batch_size, max_batch_size)的自动收敛（第 693–695 行）。此外，当--max-batch-size <= 50时，GPUStack 会自动关闭异步调度（MINDIE_ASYNC_SCHEDULING_ENABLE=0，第 1491–1492 行），说明小 batch 下异步调度收益有限。

优化项汇总

可以看到，引擎选型贡献了绝大部分收益，量化与前缀缓存是叠加的锦上添花，而 batch size 调优在本场景中并不适用。

其他基准用例：优化配置的泛化验证

为验证优化配置在不同负载下的泛化能力，GPUStack 用固定命令mindie serve vllm-ascend/Qwen3-8B-W8A8 --enable-prefix-caching（baseline 为vllm serve Qwen/Qwen3-8B）在长短不一的随机序列与低并发 ShareGPT 场景下做了对比。

随机 32K 输入（32000 in / 100 out）

Baseline：Total TPS 2890.64，Mean TTFT 559550.01 ms，Mean TPOT 344.18 ms Optimized：Total TPS 10830.52（约 +274.7%），Mean TTFT 147133.58 ms，Mean TPOT 242.08 ms

超长输入是 vLLM 基线的重灾区（P99 TTFT 超过 1096 秒），优化后虽仍存在较大 TTFT，但总吞吐几乎翻了近 4 倍，说明优化配置对极长序列同样有效。

随机 4K 输入（4000 in / 200 out）

Baseline：Total TPS 7677.41，Mean TTFT 132541.20 ms，Mean TPOT 99.26 ms Optimized：Total TPS 13362.49（约 +74.1%），Mean TTFT 70716.71 ms，Mean TPOT 130.97 ms

随机 2K 输入（2000 in / 100 out）

Baseline：Total TPS 9589.00，Mean TTFT 53978.52 ms，Mean TPOT 140.39 ms Optimized：Total TPS 15591.71（约 +62.6%），Mean TTFT 29078.68 ms，Mean TPOT 194.54 ms

随机 128 输入（128 in / 4 out）

Baseline：Total TPS 5834.79，Mean TTFT 18464.39 ms，Mean TPOT 125.55 ms Optimized：Total TPS 15040.15（约 +157.8%），Mean TTFT 4491.88 ms，Mean TPOT 1249.72 ms

短 prompt 场景（128 in / 4 out）是提升最显著的一档之一：请求吞吐从 44.28 req/s 提升到 113.94 req/s，说明优化配置对高频短请求的在线服务场景尤其友好。

ShareGPT 低并发（Batch Size 4）

Baseline：Total TPS 164.46，Mean TTFT 145.88 ms，Mean TPOT 47.28 ms Optimized：Total TPS 324.35（约 +97.2%），Mean TTFT 112.38 ms，Mean TPOT 25.42 ms

低并发小 batch 下，优化配置的总吞吐也接近翻倍，且 Mean TPOT 从 47.28 ms 下降到 25.42 ms，延迟同样受益。

综合各档用例，优化配置在 ISL/OSL 差异极大的负载上均呈正向收益（总吞吐提升 45%～275% 不等），但提升比例随输入长度与并发度明显分化——这与 docs/performance-lab/overview.md 中"优化配置在不同输入/输出序列长度下通常都有效，但提升比例可能差异显著"的观察完全吻合。

如何在 GPUStack 中落地该配置

除直接使用mindie serve命令外，GPUStack 还通过以下途径内置了这套优化：

1. 模型目录自动推荐：在 gpustack/assets/model-catalog-modelscope.yaml 中，Qwen3-8B 在 Ascend 910B 上的throughput规格默认使用vllm-ascend/Qwen3-8B-W8A8+ MindIE 后端 +--enable-prefix-caching --max-seq-len=32768，创建模型实例时即可一键选用；
2. MindIE 后端参数透传：在 GPUStack 创建模型时通过"后端参数"（backend parameters）字段填写--enable-prefix-caching等参数即可，GPUStack 的 AscendMindIEParameters 会完成解析、校验与 JSON 配置注入；
3. 参考关联文档：H100 上的低延迟优化方案见 docs/performance-lab/qwen3-8b/h100-latency.md，其他硬件/模型组合见 docs/performance-lab/overview.md 及其列出的各实验文档。

局限与后续优化建议

• 本实验的结论基于单张 Ascend 910B + 特定引擎版本（vLLM-Ascend v0.9.1、MindIE 2.1RC1），换卡、换版本或换引擎后需重新压测；
• 未覆盖的组合还包括：调度策略（--prefill-policy-type/--decode-policy-type/ split fuse）、扩展 KV cache（--kv-pool-config）、MindIE 的投机解码（memory decoding / lookahead）等，这些都可能进一步优化吞吐或延迟；
• 建议结合 docs/performance-lab/overview.md 中关于 deeper tuning 的提示，针对自身业务的 ISL/OSL 分布、前缀复用比例与并发度做定向微调——例如你的流量若以超长上下文为主，--max-seq-len与 KV cache 的权衡就是下一个调优点。

• 后端
• 人工智能
• 模型推理服务
• 集群管理
• 可观测性