模域 ModelSphere 是生产级算力部署与推理优化开源平台。现已全面支持信创算力，模型目录已收录昇腾系列模型优化方案近 20 个，覆盖 910B4 与昇腾 950 等型号，均支持一键部署。

本文以模域 ModelSphere 对 DeepSeek-V4.1-Flash 在昇腾 910B4 上的优化为例，将 vLLM Ascend 官方部署示例作为基线，在单机 8 卡、每个请求都是全新长文本的场景下，整机吞吐达到原来的 2.75 倍，首字延迟从约 6 分钟缩短至约 54 秒，降至原来的 1/6.7。

同一套设备上，没有增加服务器和加速卡情况下，可支撑的并发由 32 提高到 48。两台机器共 16 卡跑多轮对话，再叠加自研的缓存感知路由，处理量达到原来的 4.73 倍，缓存命中率从 22.1% 升至 81.0%。

本案例的昇腾 910B4 w4a8 基线和优化方案已收入模型目录，即单机 8 卡长文本测试中的引擎配置。同时，我们也对两台机器共 16 卡进行多轮对话、并叠加自研缓存感知路由进行了实测。

以下是此次实测的详细解读：

01 推理性能优化方案

本次优化围绕推理引擎和多实例请求分配展开，两类场景优化均在不增加服务器与加速卡数量的情况下开展：

• 长报告分析和知识问答场景，用户更关注首字延迟；

• 持续咨询类业务，更关注服务器在繁忙时能处理多少文本。

1.1 测试部署方案

• 单实例部署：一台服务器使用 8 张昇腾 910B4 加速卡运行一个推理实例，验证长文本请求完全无法复用历史缓存时的处理能力；

• 多实例部署：两台服务器各使用 8 张加速卡，各运行一个独立的 TP8 实例，共 16 张卡。通过缓存感知路由分配请求，验证真实多轮对话中的历史复用效果。

1.2 优化方向

• 提高处理能力：针对实际部署形态优化推理引擎，使相同设备在同样时间内能够处理更多输入与输出文本；

• 缩短首字延迟：在长文本测试中，同时提高整体处理量，让用户更早看到模型开始输出；

• 复用对话历史：将后续问题优先送到已保存相关历史计算结果的实例，减少反复处理相同内容。例如，用户围绕同一份报告连续提问时，可以复用此前处理过的历史。模域 ModelSphere 用自研的推理网关 CART（缓存感知路由）来完成这一步。

系统真实部署截图

02 测试结果

2.1 测试口径与结论边界

本文两组数据来自参数调优后的端到端复测，基线采用 vLLM Ascend 官方文档的 910B4（A2）部署示例，仅按测试部署形态做必要适配。

取得条件如下：

• 同一场景下：基线和优化方案跑在相同硬件（长文本场景为同一台物理机，多轮对话场景为同两台）、同一容器镜像、同一压测客户端上，除参数与路由外没有差异；每轮测试前后都核对加速卡占用，确保全程独占、无其他任务干扰。每项参数都从运行中的实例回读确认生效，没生效的测试作废重测。全部配置与原始结果已归档，每个数字都能追溯到产生它的那次部署。

• 长文本场景：单机单实例，每个请求输入约 5 万 token、输出 1,500 token，输入互不相同，无前缀缓存命中。两套配置各跑在自己能支撑的最大并发上：基线 32，优化方案 48。数字取自长窗口稳态，两臂窗口长度略有不同：优化方案为 2,742.1 秒（约 45.7 分钟），基线为 2,646.1 秒（约 44.1 分钟）；这份负载呈锯齿状，10 分钟短窗口会落在半个周期里，同一轮实测会比长窗口高估 1.80 倍，短时压测不作为结论依据。

• 多轮对话场景：两台机器各部署一个 TP8 实例，64 条对话、每条 17 轮，共 1,088 个请求，平均输入 34,380 token，并发固定为 128。基线与优化方案均从空缓存开始，使用同一份数据和同一并发，全部 1,088 个请求成功返回。本组按固定 1,088 个请求全部回放跑完取值，不是按固定时长切窗口。吞吐按输入与输出 token 合计，单位为 tok/s，指标定义见各表下方的指标说明。

上述结论适用于昇腾 910B4、w4a8 量化权重、vLLM Ascend 0.30.0rc2 与本文所列负载形态。换硬件、模型版本、量化方式、部署拓扑或负载分布，参数组合需要重新标定。

2.2 优化调整项

相对官方示例，一共调整了八项参数（含一项环境变量），另有一项分块预填充维持不变。每一项都经过单独或分组的对照实测。

调整项与依据见下表：

需要先说明的有两点：

• 官方示例是按双机写的，单机不要整段复制那组跨机开关；

• 并发上限和显存比例必须一起调：显存决定能坐下多少请求，并发上限决定放多少人进来，只改其中一个没有收益。

场景二虽然用了两台机器，但它们是两个独立的单机实例，每个仍是 8 个并行单元，不是跨机的 16 个，所以上面关于跨机开关的结论同样适用。

2.3 单实例长文本测试

2.3.1 测试环境

• 【设备】：昇腾 910B4，单台服务器，共 8 张卡

• 【模型】：DeepSeek-V4.1-Flash，w4a8 量化；引擎为 vLLM Ascend 0.30.0rc2

• 【负载】：每次输入约 5 万 token、输出 1,500 token，输入互不相同，无前缀缓存命中

两套配置各跑在自己能支撑的最大并发上——基线 32，优化方案 48。优化方案的 48 并发同时受缓存池容量限制，本次显存配比下缓存池可容纳约 49.6 个请求。

本组数字取自长窗口稳态：优化方案 2,742.1 秒（约 45.7 分钟），基线 2,646.1 秒（约 44.1 分钟）。

2.3.2 测试结果

2.3.3 指标说明

• 总吞吐：每秒处理的输入与输出 token 总量，反映整体文本处理能力。token 是模型处理文本时使用的计量单位；

• 输入 / 输出吞吐：这份负载输入远大于输出，总吞吐主要由输入构成，所以输入和输出分开列出。输出吞吐反映用户实际看到的内容产出速度

• 首字延迟：从提交请求到收到第一个输出所花的时间；完整回答还需继续生成。363.3 秒约为 6 分 3 秒，优化后为 54.2 秒

2.3.4 结果分析

• 在本次长文本实测中，首字延迟由约 6 分 3 秒缩短到约 54 秒，降至原来的 1/6.7，相同设备在同样时间内的总文本处理量达到原来的 2.75 倍。通常这两个指标会此消彼长，能同时变好，说明基线配置下大量请求堆在排队，而不是算力已经跑满；

• 显存配比与并发上限是同步放宽的：显存比例从 0.90 提到 0.95 后，缓存池可容纳的请求从约 36.8 个增至约 49.6 个，这才撑得住 48 并发。

这组单机对照也写在模型目录的配方页里，数字与上表一致。该页只覆盖单机 8 卡长文本测试中的引擎配置，不含后文双机多轮对话与缓存感知路由的结果。

2.4 多实例多轮对话测试

真实对话中，用户会围绕同一份资料持续追问，后续轮次包含此前的历史内容。本轮测试验证缓存感知路由能否将相关请求送到已保存历史计算结果的实例，提高多台服务器共同服务时的处理效率。

2.4.1 测试环境

• 设备：两台昇腾 910B4 服务器，每台 8 张卡，各运行一个独立的 TP8 实例，共 16 张卡；

• 负载：64 条对话、每条 17 轮，共 1,088 个请求，平均输入 34,380 token，并发固定为 128。本组按这 1,088 个请求全部回放跑完取值，不是按固定时长切窗口；

• 基线与最终优化方案：均从空缓存开始，使用相同数据和同一并发，全部 1,088 个请求成功返回。软件、镜像与引擎参数口径同 2.3.1 节，每轮测试前后核对加速卡占用，确认测试期间设备独占。

2.4.2 对照测试结果

2.4.3 指标说明

• 本表总吞吐是两台服务器合计的输入与输出文本处理量；

• 缓存命中率衡量的是：有多少已经算过的历史被真正复用，不用再从头处理一遍。命中率按实际复用前缀的输入 token 计算，可复用上限由引擎侧 token 计数得出，不是估算。

2.4.4 结果分析

• 相同两台服务器、相同测试并发下，最终方案的总文本处理量达到基线的 4.73 倍。该收益来自引擎优化与缓存感知路由的共同作用：引擎优化先达到基线的 2.60 倍，加入路由后，在前一步基础上又到了 1.82 倍；

• 表里的顺序也是实际上线顺序：先定引擎参数，再加缓存路由。一句话分工——引擎参数主要提升吞吐，路由主要提升命中率；

• 缓存命中率由 22.1% 升至 81.0%，是原来的 3.66 倍，达到这份负载可复用前缀上限 92.2% 的 88%。基线下，相邻两轮落到同一实例的比例和随机分配差不多（随机分配的理论值为 50%）。加上路由后，这一比例到了 97.8%（1,024 个相邻轮次中，只有 23 次因负载被改投）。两个实例实际接到的请求量为 51.1% / 48.9%，没有为了复用历史把一台压垮。

2.5 结果怎么用

两组数据的部署形态、负载和取值方式不同：

• 前面是单机 8 卡、每条都是全新长文本，按约 45 分钟的长窗口取稳态；

• 后面是双机 16 卡、带着对话历史，按固定 1,088 个请求全部回放。

取用时按场景对应——长文本看处理量和首字延迟，多轮对话看处理量和历史复用得怎么样。倍数只在同一张表内比较，不要将两张表的绝对吞吐放在一起比，文本处理量的提升，也不等同于能同时服务的用户数或请求数同步增加。

03 开始使用

欢迎访问 ModelSphere 模型目录浏览部署方案，查看本案例的昇腾 910B4 优化配置与模型元数据。

欢迎通过 ModelSphere GitHub 仓库了解项目并参与社区贡献。

关于我们

模域 ModelSphere 是由范式智能（PHANCY）与睿思智联（RiseUnion）共同发起，面向大模型推理的开源生产级基础设施社区，打通异构算力适配、云原生集群调度与极限性能调优，让大模型从“实验室能跑”直通“生产好用”。