背景

在上周的文章中，我们演示了 GPUWorks 在一台 B300 上测试的数据，在上周的直播中我们也提到了我们希望尽快发出在国产卡上的测试数据，今天，GPUWorks 的推理模板已经内置 Kimi-K3.1-Pro 的昇腾 910C 档位，我们在两台 910C 上做完了真机验证。选模板、点部署，两台节点就以 TP16 × PP2 拉起一个 32 die 的实例；对话、推理过程、工具调用都正常，随机 2048/512、Agentic 80K、Agentic 200K 三组压测共 836 个请求全部成功。本文给出完整的测试过程和测试数据。

Kimi-K3.1-Pro 是 2.8T 总参数、约 104B 激活的原生多模态 MoE，上下文 1M token。昇腾上用的是社区发布的 W4A8 量化权重 Eco-Tech/Kimi-K3.1-Pro-w4a8，约 1.47 TB，镜像是 vLLM-Ascend 官方随模型发布的 quay.io/ascend/vllm-ascend:kimi-k3.1-pro-a3。

测试环境

项目	配置
节点	2 台昇腾 910C 服务器，每台 16 个 die（每 die 64 GiB），共 32 个
互联	节点间 HCCS 负责计算通信
并行	每节点 TP16，跨节点 PP2，world size 32
模型	Eco-Tech/Kimi-K3.1-Pro-w4a8 ，revision bc632341a53fb72bcb65fe7c1aab24a3a5990ada，346 个 safetensors 分片，1,466,844,769,783 字节
镜像	quay.io/ascend/vllm-ascend:kimi-k3.1-pro-a3 （模板钉住 digest sha256:e7c67329…96b7）
平台	GPUWorks nightly，压测从 server 发起、经平台网关到实例

GPUWorks 的 server 和 agent 各是一个静态单二进制，agent 在节点上主动外连 server，控制、监控、日志和推理流量复用同一条隧道。昇腾节点和 NVIDIA 节点的接入方式完全一样：在控制台复制一条安装命令到机器上执行，节点就带着 NPU、网卡和存储信息上线。

准备：节点、网络与权重

1. 接入节点：在「计算节点 → 添加节点」生成安装命令，在两台 910C 上执行。平台自动识别每台 16 个 910C die。

2. 参数网络：昇腾多机走加速器网络。在「网络」里把两台节点的 HCCS 加入同一个参数网络，平台会做卡间连通性检查，部署时按这个网络自动挑选节点。

   

1. 下载权重：在「模型」里选择 ModelScope 来源，下载到第一台节点。第二台节点不用再走一遍公网，用「复制到…」从第一台节点直传：同一份 1.47 TB 权重，公网下载约 50–57 MB/s，节点间直传约 490 MB/s，快了近 10 倍。两边下完后平台都会逐文件校验。

   

   模型：两台节点各有一份完整权重，第二台来自节点间直传

部署：双机 TP16 × PP2

在「推理模板」里打开 Kimi-K3.1-Pro，选昇腾档位「910C (A3) · INT4 W4A8 · 每节点 8 卡（16 NPU） · 多机」（w4a8-vllm-ascend-a3-multinode-16npu），点「部署」，不用改任何参数。部署表单按参数网络自动挑出两台节点：节点内的 16 个 die 组成 TP16，每台节点一个流水线阶段，--nnodes、--node-rank 和 leader 地址都由平台填好。

模板里的关键参数：

vllm serve /model --quantization ascend --trust-remote-code \  --tensor-parallel-size 16 --pipeline-parallel-size 2 \  --max-model-len 210000 --max-num-seqs 64 --max-num-batched-tokens 8192 \  --kv-cache-dtype int8 --block-size 768 --gpu-memory-utilization 0.90 \  --enable-prefix-caching --enable-expert-parallel \  --tokenizer-mode kimi_k3 --reasoning-parser kimi_k3 \  --tool-call-parser kimi_k3 --enable-auto-tool-choice

这些值都是实测定下来的：--max-model-len 210000 刚好容纳 200K Agentic 负载的最长一轮（输入加输出峰值 208,618 token）；--max-num-seqs 64 覆盖随机负载的最高并发；显存利用率 0.90 是 200K 长上下文下稳定运行的取值。推理过程、工具调用依赖 --tokenizer-mode 和两个 parser 同时打开，模板已经一并配好。

启动过程：

阶段	耗时	备注
权重加载	385 s / 442 s（两个流水线阶段）	每 die 约 42.8 GiB 权重
图捕获	65 s / 68 s	FULL_DECODE_ONLY
KV cache	—	共 468,750 token，可同时容纳约 2.2 个 210K 请求

就绪后，部署详情里能看到两个实例：rank 0 是 leader，对外提供 API；rank 1 是 follower。

部署详情：leader / follower 两个实例，各占一台节点的 16 个 die

调度分析里，两台节点的 32 个 die 全部服务于这个实例：

调度分析：两台 910C 的 32 个 die 全部提供服务

对话、推理与工具调用

经平台 /v1 网关、用 API 令牌发起流式请求，问「用一句话介绍你自己，并计算 17*23」，回答「我是 Kimi，由 Moonshot AI（月之暗面）开发的 AI 助手；17×23 = 391。」。在「试验场」里，推理过程可以展开查看，和最终回答分开显示：

试验场：展开 Kimi-K3.1-Pro 的推理过程

工具调用返回结构化的 get_weather(city="上海")，finish_reason 为 tool_calls，可以直接接 Agent 框架。

我们还单独发了一个真实的 200K 请求：服务端输入 200,188 token、输出 64 token，首 token 38.6 秒，端到端 42.3 秒。

压测

三组压测和 B300 文章用的是同一套负载矩阵：同样的输入预设、并发点、每点会话数、13 轮结构和输出预算，同样从 server 发压、经网关访问实例。这次三组都直接用 Kimi 原版 tokenizer 生成负载。

负载	设计输入 / 输出	实测平均输入	并发点	请求（成功）
随机定长	2,048 / 512（ignore_eos）	2,182	1 / 8 / 32 / 64	420（420）
Agentic 80K	13 轮，每轮输出 220	80,740	1 / 2 / 4 / 8	260（260）
Agentic 200K	13 轮，每轮输出 220	203,438	1 / 2 / 4	156（156）

另外还跑了多长度扫描、OASST1 真实多轮对话和 Agentic 10K，共 92 个请求，全部成功。

随机 2048/512

并发	输出 tok/s	总 tok/s	单用户输出 tok/s	TTFT P50 ms	TPOT P50 ms
1	16.4	86.4	20.5	1,344	48.7
8	51.9	273.0	8.9	5,395	112.2
32	157.2	827.0	6.9	9,230	145.6
64	219.8	1,156.8	5.1	13,817	197.7

输出吞吐随并发一路上升，C64 时还没到拐点。TTFT 是到第一个 token 的时间，包含推理（reasoning）阶段。

评测报告：随机 2048/512，4 个并发点、运行曲线与 Pareto

Agentic 80K 与 200K

负载	并发	输出 tok/s	总 tok/s	TTFT P50 ms	TPOT P50 ms	后续轮缓存命中
80K	1	14.1	5,176	1,822	57.4	98.6%
80K	2	13.9	5,097	3,701	117.8	98.6%
80K	4	22.8	8,372	3,835	137.2	98.6%
80K	8	5.4	1,975	129,375	586.2	0%
200K	1	11.0	10,155	2,623	58.8	99.4%
200K	2	12.4	11,518	4,300	119.4	99.4%
200K	4	3.3	3,015	197,630	349.3	0%

长上下文的表现取决于 KV cache 能不能装下所有在途会话。这套配置的 KV cache 共 468,750 token：80K 在 C4 以内、200K 在 C2 以内，所有会话的前缀都留在缓存里，后续轮次命中率 98–99%，单轮只需 prefill 新增的几百个 token，总吞吐 8K–11K tok/s。并发再往上，在途会话的总上下文（80K × 8、200K × 4）超过了 KV 容量，前缀被挤出缓存，每一轮都要重新 prefill 整段上下文，吞吐明显下降，但所有请求仍然成功完成。

监控中心：200K 压测期间的 TTFT、并发与 KV cache 使用率、命中率

与单台 B300 对比

我们把同样的负载矩阵和 8×B300 单机 的结果放在一起：

两台 910C 与单台 8×B300 的吞吐对照

负载	并发	2 × 910C	1 × 8 B300	910C / B300
随机 2048/512，输出 tok/s	1	16.4	97.7	17%
	8	51.9	484	11%
	32	157.2	1,080	15%
	64	219.8	1,473	15%
Agentic 200K，总 tok/s	1	10,155	60,785	17%
	2	11,518	88,207	13%

在这个模型上，两台 910C 的吞吐大约是单台 8×B300 的 1/7 到 1/6；单用户解码速度约 20 tok/s，B300 约 110 tok/s。读这组数字时要考虑几个条件差异：

• 权重与内核：B300 用 MXFP4 原生权重，路由专家走 Blackwell 原生 FP4 内核；910C 用社区 W4A8 量化权重和首发的 vLLM-Ascend 镜像，昇腾侧的内核还在快速迭代。

• 拓扑：B300 是单机 NVLink TP8；910C 每 die 64 GiB，装下 1.47 TB 权重至少要两台机器，跨节点流水线并行会带来额外的气泡和通信。

• 显存与 KV 容量：B300 每卡 275 GB，KV cache 约 197 万 token；910C 双机约 47 万 token。长上下文下能同时保持在缓存里的会话数因此更少，并发上限也更低。

• 输入长度：B300 的随机负载当时用代用 tokenizer 生成，按 Kimi tokenizer 实际输入约 3,180 token，比 910C 这次的 2,182 更长；200K 两边都用 Kimi 原版 tokenizer，是最直接的对照。

• 每个并发点只跑一次，数字是单次观测。

所以这组对比不是硬件排名，而是给同时手里有国产算力和 NVIDIA 算力的团队一个参照：同一个模型、同一套负载、同一个平台，两边的部署、监控和评测流程完全一样，切换硬件不用换工具。

监控与评测

部署跑起来后不用自己搭 Prometheus / Grafana：引擎指标由 agent 采集，「监控中心」按集群、服务、实例三层展示 TTFT / TPOT 分位数、并发与排队、KV cache 使用率和命中率、prefill / decode 吞吐；「用量分析」区分缓存命中输入、未命中输入和输出 token；「调度分析」显示每张卡被谁占用。

每组压测在「评测」里都是一份完整报告：判定点位、运行曲线、吞吐与单用户速度的 Pareto 曲线、逐点位结果，以及计划 / 实际发起 / 成功 / 失败的请求与会话对账，可以下载逐请求 JSONL、导出报告或一键「再跑一次」。

经验与建议

• 第二台节点用节点间直传：1.47 TB 权重从公网下要七八个小时，第一台下完后用「复制到…」直传第二台，约 50 分钟。

• 部署前预热权重：两台节点各自把权重并行读一遍进页缓存，能明显缩短加载时间：

  ls $MODEL_DIR/*.safetensors | xargs -P 32 -I{} dd if={} of=/dev/null bs=16M status=none

• 显存利用率保持 0.90：模板的 0.90 是 200K 长上下文下验证过的值，调高会在长 prefill 时 OOM。

• 按 KV 容量规划长上下文并发：双机 KV cache 约 47 万 token，200K 会话建议并发不超过 2，80K 不超过 4，这样前缀缓存命中率能保持在 98% 以上。需要更高并发，可以加节点或多部署一个副本。

• 压测直接用 Kimi 原版 tokenizer：Kimi 的 tokenizer 是 tiktoken 格式，nightly 的评测在 tokenizer「自动」下会直接用推理服务自己的 tokenize 接口，或读取节点上的 tiktoken.model，不需要再手动转换。

用哪个版本

建议使用 GPUWorks nightly。 Kimi-K3.1-Pro 的推理模板（包括 910C、B300 等全部档位）、Kimi tokenizer 的自动识别、超大模型的节点间直传都在 nightly 里；当前最新的正式版 v26.11.2 还不包含这些，下一个正式版会带上。

新安装：

GPUWORKS_CHANNEL=nightly bash <(curl -fsSL https://dl.gpuworks.ai/get.sh)

已有安装：在「设置 → 版本与更新」把渠道切到 nightly，一键升级 server，再升级各节点的 agent；推理模板目录随新版本一起更新。

欢迎试用

GPUWorks 是一个轻量的 GPU 集群管理平台，两个静态二进制就能把 NVIDIA、昇腾、AMD、平头哥等异构算力统一管起来，内置主流大模型在各类硬件上的推理模板，部署、监控、评测和 OpenAI 兼容网关开箱即用。

• 项目地址：https://github.com/flitai-io/gpuworks

• 文档：https://gpuworks.readthedocs.io

如果你手里有 910C、B300 或其他加速卡，欢迎下载试用，用模板部署 Kimi-K3.1-Pro 跑一跑；遇到问题或想要新的模型、硬件档位，欢迎提 issue。觉得有用的话，请给我们点个 Star ⭐，这对我们很重要。

接下来我们会持续验证新的模型、发布对应的模板，欢迎加入我们的微信群参与讨论！