文章目录
- [01 硬件选型与 llama.cpp 部署：4× RTX 5880 Ada 跑 DeepSeek-V4-Flash](#01 硬件选型与 llama.cpp 部署：4× RTX 5880 Ada 跑 DeepSeek-V4-Flash)
-
- [1. 官方路线为什么走不通](#1. 官方路线为什么走不通)
- [2. 模型与权重](#2. 模型与权重)
- [3. 启动脚本逐参数解读](#3. 启动脚本逐参数解读)
- [4. 基线性能实测（2026-08-14）](#4. 基线性能实测（2026-08-14）)
- [5. 显存核算](#5. 显存核算)
01 硬件选型与 llama.cpp 部署：4× RTX 5880 Ada 跑 DeepSeek-V4-Flash
《DeepSeek-V4-Flash 本地部署与公网服务化》系列 · 第 ① 篇 / 共 5 篇
① 硬件选型与 llama.cpp 部署（本篇） ｜ ② API 鉴权与腾讯云公网桥接 ｜ ③ 多协议支持：Anthropic 与 Responses API ｜ ④ 稳定性与性能调优实录 ｜ ⑤ 客户端接入：pi 与各类 SDK
本篇讲清楚：为什么这台机器不用官方 vLLM/SGLang 路线、GGUF 怎么选怎么下、启动脚本每个参数的含义、以及基线性能。
1. 官方路线为什么走不通
官方模型卡只给了两条推理路线：vLLM 和 SGLang，示例硬件都是 4×GB300（单卡 ~288GB HBM，整机 ~1.1TB 显存）。对照我们的机器（4× RTX 5880 Ada，共 192GB，sm_89）：
- 容量 ：官方 fp8 safetensors 共 166.9GB（48 个分片），装进 192GB 后只剩 ~25GB 给 KV cache + 激活 + CUDA graph + MoE 工作区，512K 上下文想都别想。
- 内核 ：vLLM 的
--moe-backend deep_gemm_mega_moe和use_fp4_indexer_cache（DSA 索引器 FP4 缓存）、SGLang 的flashinfer_mxfp4，全部面向 Hopper(sm_90)/Blackwell(sm_100)；Ada(sm_89) 没有 FP4 硬件单元，这些内核一个都跑不起来。 - llama.cpp 恰好绕开了这两点 ：unsloth 的 UD-Q8_K_XL GGUF 把 MoE 专家权重存成 MXFP4（llama.cpp 自己实现 MXFP4 计算，不依赖 Blackwell），DSA/闪电索引器也有通用实现。这是该硬件上目前唯一可行的路线。
2. 模型与权重
| 文件 | 大小 | 用途 | 来源 |
|---|---|---|---|
DeepSeek-V4-Flash-0731-UD-Q8_K_XL-0000{1..5}-of-00005.gguf |
~162GB | 主模型（注意力等敏感层 Q8，MoE 专家 MXFP4 动态量化） | ModelScope（国内 CDN）/ HF |
dspark-DeepSeek-V4-Flash-0731-Q8_0.gguf |
10.9GB | DSpark 投机解码草稿模型 | 同上仓库根目录 |
下载经验（完整坑清单见部署手册 DEPLOY.md）：
- huggingface.co 直连被墙；hf-mirror 对 xet 大文件会 401。ModelScope 国内 CDN 是首选，自写并发分片下载脚本（10--45MB/s）比官方 SDK（1--2MB/s）快得多。
- GGUF 分片
00001只有 5.25MB 是该仓库惯例（header 分片），不是损坏。 - curl
-C -续传 +-r分段组合有 bug（重试时 seek+write 叠加，3.37GB 段实际写 9.5GB），分段 part 必须整段重下。 - 下载后按仓库清单逐分片校验 sha256。
3. 启动脚本逐参数解读
最终版 serve.sh（用法 ./serve.sh [port] [ctx] [n_cpu_moe] [dspark] [np]）核心 exec 行：
bash
exec "${NUMA_CMD[@]}" "$LLAMA" \
"${KEY_ARGS[@]}" \
-m "$MODEL" \
-ngl 999 \ # 全部层 offload 到 GPU
-sm layer \ # split mode: 按层切分到 4 卡（流水线式）
-ncmoe "$N_CPU_MOE" \ # 前 N 个 MoE 专家层放 CPU（显存/速度调节阀）
-fa on \ # flash attention
-ctk q8_0 -ctv q8_0 \ # KV cache 量化为 q8_0
-c "$CTX" \ # 总上下文（所有槽位平分）
-np "$NP" \ # 并发槽位数
--cache-reuse 256 \ # ≥256 token 的公共前缀跨请求复用 KV
-b 4096 -ub 1024 \ # 逻辑/物理 batch
-t 64 -tb 64 \ # CPU 线程
--host 0.0.0.0 --port "$PORT" \
--load-mode mmap \ # 权重 mmap（热启动 ~33s 全靠 page cache）
"${FIT_ARGS[@]}" \
--reasoning on \
--reasoning-format deepseek关键点：
-
-sm layer而非-sm row：本机 CUDA 构建不支持 row 模式的 split buffers，用 row 会直接报错。layer 模式把层和 KV 按卡切分，是 4 卡流水线的正确姿势。 -
DSpark 投机解码 （
dspark=1时）：bashFIT_ARGS=(--fit off -md "$DSPARK_MODEL" --spec-type draft-dspark \ --spec-draft-n-max 5 -ngld 99)- 必须
--fit off：--fit on不会把草稿模型 ~11GB 计入显存预算，显存紧张时必 OOM。 - 不要传
-devd/--spec-draft-device：drafter 借用目标模型的 embedding/输出头，必须与目标模型跨同样的卡。 --spec-draft-n-max上限为 5（草稿训练块大小；官方 vLLM 用 7，见 模型卡）。
- 必须
-
numactl --interleave=all（ncmoe>0 时）：双路 EPYC NPS4 共 8 个 NUMA 节点、每节点仅 ~64GB，CPU 专家每 token 从 mmap 读；interleave 把页面均匀散布所有节点，吃满聚合内存带宽，避免单节点热点/耗尽。 -
--api-key-file：API 鉴权，见 02 篇。
4. 基线性能实测（2026-08-14）
| 配置 | ctx | decode | prefill | 显存/卡 |
|---|---|---|---|---|
基线 serve.sh 8080 1048576 0 |
1M | 35.8 tok/s | ~98 tok/s | 44.5--47.3 GB |
DSpark serve.sh 8081 524288 0 1（n_max=3） |
512K | 45.9 tok/s（1.28×） | ~92 tok/s | 43.1--48.2 GB（余量仅 ~2GB） |
| DSpark + ncmoe=4（n_max=3） | 512K | 25.3 tok/s | --- | 36/46/43/40 GB |
| DSpark + ncmoe=4 + np=2 + n_max=5（现网配置） | 2×256K | 34.1 tok/s | 370--485 tok/s（随上下文递减） | 26/39/39/37 GB（余量最大 13GB） |
- DSpark 草稿接受率：n_max=3 时 36.8%（DEPLOY 基线）/ 70%（pi 会话样本）；n_max=5 时 44% 但每步净接受更多（mean len 3.75），wall-clock +35%。
- 模型从 page cache 热加载仅 ~33s；冷启动（首次）明显更慢。
- 官方基准（模型卡）：
max思考档 +temperature=1.0, top_p=0.95评测；high/max 档建议最大输出 384K tokens。
5. 显存核算
权重 ~162 GB（MXFP4 原生存储，不反量化膨胀）
KV cache ~8--25 GB（MLA + DSA 128× 压缩 + q8_0 量化；1M ctx 口径）
激活/中间 ~5 GB
DSpark +~11 GB（草稿模型）
合计 175--190 GB / 192 GB任何时刻只跑一个 llama-server 实例------192GB 刚好用完，这是所有调优的硬约束。ncmoe（专家上 CPU）是最有效的显存调节阀，代价是 decode 降速（详见 04 篇）。
下一篇 ：02 API 鉴权与腾讯云公网桥接