#DeepSeek-V4-Flash (W4A8)

deepseek_v4 架构模型——一个 256-expert MoE，结合 MLA + DSA 稀疏注意力 和原生 MTP speculative head，以 W4A8 形式提供（~151 GB 权重，43 层）。 已在 Ascend 910B4（32 GB/卡） 上通过 Alauda AI 的 InferNex 接口 使用 vLLM-Ascend nightly 引擎完成验证。由于权重需要占用全部 8 张卡， 拓扑为 1 个实例 × TP=8（+ expert parallel），两个 benchmark 场景还分别通过 内部 KServe ingress 和 MaaS gateway（API-key） ingress 进行了驱动。

#模型标识

#已验证硬件 × 栈

#模型配置

#部署规格

仅以 agg-base 方式提供——aggregation，hermes-router 策略为 random。在单个 TP=8 实例下， router 只有一个 endpoint（无实际作用）；保留该结构仅为一致性。跨实例 KV store / KV-cache-aware routing （agg-mc-kv）不适用：~151 GB 权重会占满全部 8 张卡，因此只能放下一个副本，也没有第二个实例可供共享 KV。

#部署

自包含的 InferNex manifest（engine 内联在 LLMInferenceService + hermes-router preset 中，1 个副本 × TP=8）：

base=https://raw.githubusercontent.com/alauda/aml-docs/master/docs/en/plan/validated_models/assets/deepseek-v4-flash-w4a8
# edit namespace / model.uri registry / image tag first, then:
kubectl apply -f $base/deepseek-v4-flash-w4a8-agg-base-llmisvc.yaml

# Internal KServe ingress (no auth):
curl -s http://<gateway>/<namespace>/deepseek-v4-flash-w4a8-agg-base/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"gdydems/DeepSeek-V4-Flash-w4a8-mtp","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":"gdydems/DeepSeek-V4-Flash-w4a8-mtp","messages":[{"role":"user","content":"hello"}]}'

#Benchmark 结果

闭环 aiperf 0.7.0，TP=8 × 1 个副本（8 × 910B4），并发 4，agg-base。 两个场景——① 8k system-prompt 复用和 ② 17.5k multi-turn——各发送 240 个请求， 输出固定为 128 个令牌，n=3（所有运行均为 240/240，零错误）。每个场景都通过两个 ingress 进行驱动： 内部 KServe Service（无认证）和产品 MaaS gateway（Envoy + API-key 认证 + 令牌速率限制——面向客户的 OpenAI endpoint）。 TTFT / E2E 以 ms 计，ITL 以 ms 计，TPS = 总令牌/s。

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

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