#DeepSeek-V4-Flash (W8A8)

deepseek_v4 架构模型 — 256 专家 MoE，采用 MLA + DSA 稀疏注意力 以及原生 MTP speculative head，作为 W8A8 提供服务（int8 attention + expert， ~280 GB 权重，70 个 shard，43 层）。由于 ~280 GB 的权重无法装入单个 8 × 32 GB 节点，因此它在 Ascend 910B3（64 GB/卡）跨两个 节点 = 16 张卡 上进行了验证，作为一个单一聚合的 DP2 × TP=8 + EP16 服务， 通过 Alauda AI 的 InferNex 界面，使用 vLLM-Ascend nightly 引擎提供服务。它增加了一个 mooncake 跨 rank KV 存储，使两个数据并行 rank 共享前缀 KV；两种基准场景都通过 MaaS gateway（API-key）入口 以并发扫测方式驱动（8 / 16 / 32）。

#模型标识

#已验证硬件 × 软件栈

#模型配置

#部署规格

作为 agg-mc-kv 提供服务——一个单一的 DP2 × TP=8 聚合 加上 由两个 DP rank 共享的 mooncake KV store。DP2 的随机路由会将每个用户不断增长的历史分散到两个 rank 上，因此每个 rank 的本地多轮命中率只有约 ~41 %；mooncake store 允许一个 rank 拉取另一个 rank 已经计算出的 prefix KV，将合并后的有效 prefix 复用率提升到约 ~84 %。路由器保持为 random，cache-indexer 关闭：单个聚合 endpoint 不需要全局 KV 索引或感知 KV-cache 的路由—— 这与 GLM-5.2 / Qwen3-8B 的聚合范式一致（store 共享 KV；router 保持 random）。

#部署

自包含的 InferNex manifest（engine 内联在 LLMInferenceService 的 leader + worker templates + hermes-router preset 中，跨两个节点的 DP2 × TP=8，并使用 mooncake store）：

base=https://raw.githubusercontent.com/alauda/aml-docs/master/docs/en/plan/validated_models/assets/deepseek-v4-flash-w8a8

# 1. Import the ModelCar (OCI Image Layout tar) into your own registry once — the cluster
#    pulls an OCI image, not the tar. skopeo does the multi-arch (amd64+arm64) push in one go:
curl -sO http://<model-package-host>/packages/aml-models-oci/v0.1.0/DeepSeek-V4-Flash-w8a8-mtp/DeepSeek-V4-Flash-w8a8-mtp.oci.tar
skopeo copy --all \
  oci-archive:DeepSeek-V4-Flash-w8a8-mtp.oci.tar:v0.1.0 \
  docker://<your-registry>/modelcar-deepseek-v4-flash-w8a8-mtp:v0.1.0

# 2. Edit the manifest: set the namespace, set model.uri to the registry ref you just
#    pushed, and the image tag (match your CANN / host driver). Then apply — the
#    storageInitializer pulls the ModelCar to /mnt/models in each DP rank.
#    (Alternative: stage the weights on a node-local PVC per node — see the manifest header.)
kubectl apply -f $base/deepseek-v4-flash-w8a8-agg-mc-kv-llmisvc.yaml

# Internal KServe ingress (no auth):
curl -s http://<gateway>/<namespace>/deepseek-v4-flash-w8a8-agg-mc-kv/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"deepseek-v4-flash-w8a8","messages":[{"role":"user","content":"hello"}]}'

# Product MaaS gateway (OpenAI-compatible, API-key auth + token rate limiting):
curl -s http://<maas-gateway>/v1/chat/completions \
  -H "Authorization: Bearer $MAAS_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"deepseek-v4-flash-w8a8","messages":[{"role":"user","content":"hello"}]}'

#基准测试结果

闭环 aiperf 0.7.0，DP2 × TP=8（16 × 910B3 64 GB），通过产品 MaaS gateway 驱动。并发扫测 8 / 16 / 32，每档 480 次请求（所有档位均为 0 error / 0 mismatch）。这些核心数字对应的是生产级 agg-mc-kv 配置——FULL_DECODE_ONLY graph + mooncake 跨 rank KV store，也就是上方 manifest 部署的 精确配置——场景 ②（多轮嵌套长上下文），也就是该 store 所针对的 agent 风格工作负载。TTFT / E2E 的单位为 s，ITL 的单位为 ms；decode = 仅输出 tok/s（实测），TPS = 总 token/s（输入 + 输出，计算得到；以 prefill 为主）。

场景 ② — 多轮对话，生产级 agg-mc-kv（ISL ~17.5k / OSL 128）

mooncake 跨 rank KV store 正是让这一方案变快的关键：它将多轮 prefix 复用率从约 ~41 %（每个 rank 本地）提升到约 ~84 %（合并后有效）。在并发 32 下，将同一 场景 ② 按部署演进的各个配置依次跑一遍，可以看出收益来自哪里：

配置演进 — 场景 ②，并发 32

→ graph + store 共同作用，相比相同并发下的基础聚合，TTFT 约提升 5.3× / E2E 约提升 4.8× / TPS 约提升 4.8×。

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

8k 固定 prompt 场景仅在基础聚合配置上进行了测量（graph

• mooncake 没有为它单独复跑），因此请将这些结果视为下限——生产配置会像场景 ② 那样显著提升它们：