Alauda AI
  • 简体中文

    • Qwen3-32B

    标准 Qwen3 dense 模型，32B 参数，以 BF16 提供服务（4 张卡合计约 ~62 GB）。已在 Ascend 910B4（32 GB/卡） 上，使用 vLLM-Ascend v0.18.0，并通过 Alauda AI 的 InferNex 接入层完成验证。已验证的 8 卡拓扑为 TP=4 × 2 个副本，在 两个部署规格 下进行了基准测试——agg-base（负载均衡）和 agg-mc-kv（跨实例 KV cache 存储 + 感知 KV-cache 的路由）。

    目录

    模型标识已验证硬件 × 栈模型配置部署规格部署基准测试结果

    模型标识

    字段值
    发布方Qwen (Alibaba)
    架构Qwen3 dense（标准 attention，无 MTP）
    参数32B
    原生 dtypeBF16 (~62 GB)
    模型来源https://huggingface.co/Qwen/Qwen3-32B

    已验证硬件 × 栈

    平台引擎版本 / 配置状态
    Ascend 910B4 32 GB × 8（TP=4 × 2 个副本）vLLM-Ascendv0.18.0-openeuler（V1 engine）✅ 闭环，2 场景性能测试，两个部署规格（agg-base + agg-mc-kv）

    模型配置

    定义服务边界的 vLLM-Ascend 引擎标志（两个部署规格完全相同）：

    参数值
    Tensor parallelism (tensor-parallel-size)4
    副本（实例）2（= 8 张卡）
    max-model-len40960
    max-num-batched-tokens40960
    gpu-memory-utilization0.8
    block-size128
    max_tokens（输出，基准测试固定）128
    Prefix caching已启用（--enable-prefix-caching）

    部署规格

    两个规格都通过 InferNex 运行在同一组 8 张卡（2 × TP=4）上（KServe LLMInferenceService + InferNex-Bridge + hermes-router）。agg-mc-kv 在 agg-base 的基础上增加了跨实例 KV cache 存储和感知 KV-cache 的路由：

    组件agg-baseagg-mc-kv
    hermes-router (EPP)✅ 已启动✅ 已启动
    路由策略random（负载均衡）kv-cache-aware
    cache-indexer—✅
    mooncake KV store (AscendStoreConnector)—✅
    tokenizer sidecar—✅
    跨实例 KV 复用否是

    部署

    独立的 InferNex 清单（每个都打包了 engine + hermes-router LLMInferenceServiceConfig 和 LLMInferenceService，2 个副本 × TP=4）：

    规格文件
    agg-base（负载均衡）qwen3-32b-agg-base-llmisvc.yaml
    agg-mc-kv（KV store + 感知 KV-cache 的路由）qwen3-32b-agg-mc-kv-llmisvc.yaml
    base=https://raw.githubusercontent.com/alauda/aml-docs/master/docs/en/plan/validated_models/assets/qwen3-32b
# edit namespace / model.uri registry / image tag first, then:
kubectl apply -f $base/qwen3-32b-agg-base-llmisvc.yaml

    基准测试结果

    闭环 aiperf 0.7.0，TP=4 × 2 个副本（8 × 910B4），并发 4。两个 场景——① 8k system-prompt 复用和 ② 17.5k 多轮对话——每个 240 个请求， 输出固定为 128 tokens。TTFT / E2E 的单位为 ms，ITL 的单位为 ms，TPS = 总 tokens/s（输入 + 输出）。

    场景 ① — 固定长度 system-prompt 复用（ISL ~8k / OSL 128）

    部署规格TTFT avg (ms)ITL avg (ms)E2E avg (ms)TPS (in+out)
    agg-base132871.4103913120
    agg-mc-kv44568.791653558

    场景 ② — 多轮对话（ISL ~17.5k / OSL 128）

    部署规格TTFT avg (ms)ITL avg (ms)E2E avg (ms)TPS (in+out)
    agg-base461295.9167914270
    agg-mc-kv166377.3114816498
    NOTE

    如何解读这些结果。 所有运行都以每个实例稳定 2 个在途请求完成了 240/240， 且没有任何错误。agg-base 的数据来自一次具有代表性的运行；agg-mc-kv 是 3 次运行的平均值。

    agg-mc-kv 的价值主要体现在 TTFT（首 token 延迟）上：跨实例 KV 存储允许 一个请求复用其他实例已经计算好的前缀 KV，从而跳过一次重新 prefill。该效果在 多轮对话 场景中最明显（TTFT 4612 → 1663 ms，E2E 16.8 → 11.5 s，TPS +52%）， 因为每一轮都共享一个持续增长的长前缀。在这 3 次运行中，场景 ② 的冷/热态差异 很大：第一次（冷态）运行 需要完整完成 16k base 的 prefill（TTFT ~3.5 s），而 热态运行 的 TTFT 可达到 ~0.76 s、E2E ~9.9 s——上面的均值同时包含了两者， 而热态稳态才是持续服务中的实际运行点。decode step 延迟（ITL）在两个规格之间 基本相同——KV store 并不会加速这一部分。

    在当前 2 实例规模下，agg-mc-kv 的大部分收益来自 KV store；若要单独隔离 路由带来的贡献，需要额外做一组 A/B 测试，而 store 的价值会随着实例数量增加而 提升（跨实例复用机会更多）。这些是半规模数据（8 张卡）；总体吞吐量会随实例数 扩展。