模型学到的“知识旋钮”
DeepSeek V4 Flash 有 2840 亿总参数。参数越多通常能力越强，也意味着权重文件更大。
本项目权重索引：168.27 GB，46 个分片04 · 入门手册 · 从零学习
四步看懂大模型部署
依次看懂模型、内存、性能和容量四笔账，就不会被“1 PFLOP”“100 万上下文”“82 tok/s”这些孤立数字带偏。
本页解决什么从零建立大模型部署的完整概念推荐按 01 → 04 阅读；有具体疑问可直接看 FAQ
01 · Level 1 入门
四个最常见的词
先把“大模型有多大”和“跑起来有多快”分开。
模型读写文字的计量单位
Token 不等于汉字，也不等于单词。系统提示、工具定义、历史对话、用户输入和输出都消耗 Token。
因此“用户输入 8K”并不是完整请求只有 8K一次请求的“工作台”
模型卡标称最高 100 万 Token，是架构天花板；设备能否稳定承载，要看内存和运行时。
本项目当前沿用的受控输入 cap：8,192 Token每秒产出多少文字单位
它可能指单用户解码速度，也可能指整个服务总产出，还可能包含首字前的等待，必须先问口径。
历史 mem=0.50 C8 总输出：35.105 tok/s284B
全部专家
全部专家
每次只叫一部分
13B
实际激活
实际激活
MoE · 混合专家
像一家有 256 位专家的咨询公司
每个问题不会让所有专家同时工作。DeepSeek V4 每个 Token 从 256 个路由专家中选择 6 个，再加共享专家；因此总参数很大，但每次激活约 130 亿。好处是能力和计算量可以兼顾，代价是权重仍然都要存进内存，并且专家路由对软件内核要求高。
02 · Level 2 进阶
为什么 128 GB 的单机装不下 168 GB 权重
内存预算不是“权重大小小于内存”这么简单。
模型权重+操作系统+KV 缓存+计算中间量+CUDA / 通信=总内存压力
CPU、GPU 与系统共享，不是 128 GB 全部留给模型。
仅权重已经超过单机物理容量。
通过切分使用，不是一块透明共享内存。
NVFP4 · 量化
把最占空间的部分“压缩存储”
量化类似把高精度工程图压成更紧凑格式。本模型主要把 MoE 路由专家压成 NVFP4；注意力、共享专家、输出头等保留更高精度。它不是“整个模型都是 4-bit”。
按 NVIDIA 模型卡，NVFP4 在 GPQA、长上下文、工具调用、科学编程和指令遵循上的结果与基线非常接近；这说明压缩并未造成明显整体能力坍塌，但真实业务仍要单独评测。
NVFP4路由专家 · 占权重主体FP8 / 高精度注意力与其他线性层BF16输出头
问题→14 层→14 层→15 层→回答
PP3 · 流水线并行
三台机器像三段生产线
本项目把 43 层模型分成 14 / 14 / 15 三段。每个 Token 必须依次经过三台机器。它解决的是容量问题，不会让单个 Token 同时在三台上完成；任何一段停机，整条生产线都停。
与 TP 不同：TP 会把同一层的矩阵计算拆到多台，通常需要更频繁的跨机通信。本项目验证的是 TP=1、PP=3，不能把网上 TP=2 的性能直接搬过来。
TP 与 PP · 一句话看懂
TP 是“同一道菜一起做”，PP 是“每人负责一道工序”
TP（张量并行）把同一层计算切给多台设备，同时开工，但每一层里都要频繁汇总结果；它更依赖低延迟、高带宽网络。PP（流水线并行）把连续模型层分段，只在阶段交界传递中间结果，跨机同步次数较少，但后段必须等前段算完。
因此，ConnectX-7 可以把“交接”做快，却不能让 PP 的 Stage 2 跳过 Stage 1。分块 Prefill 和多请求调度可以让不同批次像多件产品一样同时占据不同工位，提高整条生产线吞吐；单个 Token 的因果顺序仍不变。
TP半层 A＋半层 B→每层汇合
PP前 14 层→中 14 层→后 15 层
PP前 14 层→中 14 层→后 15 层
03 · Level 3 专业
一次回答其实分成两段
用户体感差，往往不是“吐字慢”，而是“读题慢”。
Prefill · 先读完问题
把系统提示、历史、工具和用户输入一次性处理。输入越长，首字等待越明显。
本项目 4K：TTFT p95 29.18 秒本项目 8K：TTFT p95 44.37 秒
→
Decode · 再逐字回答
模型逐个生成 Token。TPOT 衡量相邻 Token 的平均间隔，比总 tok/s 更接近单用户吐字流畅度。
本项目 4K/8K：TPOT p95 约 78 ms从发出请求到看到第一个 Token。交互体验最敏感。
开始回答后，每个 Token 平均需要多久。
从请求进入到完整回答结束，包含读题和生成。
100 次请求里，大约 95 次不超过这个值。比平均数更能反映排队。
社区常说的 65/82 tok/s 往往是 Decode-only。
本项目展示的 35.105 tok/s 是 8 并发、256→128 合成请求的整个服务输出吞吐；两者模型版本、精度、并行方式、引擎、投机解码、输入长度和计时窗口都不同。先对齐口径，才有资格比较。
04 · Level 4 精通
真正的容量公式：活跃 Token、内存和队列共同决定
所有活跃请求的输入 + 已生成内容 + 运行时开销必须小于可用缓存与内存安全边界硬窗口 12,288
服务器拒绝超长序列的最后一道护栏。它不是推荐输入长度，也不是“12K 输入再加输出”。
受控输入 cap 8,192
给系统提示、工具定义、输出、推理和波动留出空间。4K/8K 与 NIAH 的通过记录来自历史 mem=0.50 配置。
历史突发并发 8
只表示旧配置测试过最多 8 个在途请求，不等于当前每秒 8 个请求，也不保证每个用户都低延迟。
Radix Cache
重复的系统提示和工具定义可以复用“已经读过的开头”，降低后续 Prefill；但缓存会被驱逐，不能当数据库。
实践：固定提示词顺序，把动态内容放后面。Chunked Prefill
长输入被切成多个小批次处理，避免一次性冲垮内存；代价是首字需要等更多批次。
本项目每批最多 4,096 Token。CUDA Graph
把常见解码形状提前录制，减少重复调度开销；图越大越占内存，不能无限提高。
本项目只捕获到 Decode batch 4。RoCE / NCCL
三台机器通过 200GbE ConnectX-7 Ring 传递模型中间结果。三节点 Ring 物理上是三角形，每两台都有直接链路；PP 的 0→1→2 是模型层依赖，不是 Spark 2 替 Spark 1 转发网络包。链路快不代表模型同样快，但链路异常会拖垮整个实例。
三条物理链实测约 183.50–185.22 Gb/s。专业验收不是“接口返回 200”
- 配置生效实际启动参数与目标一致，没有静默忽略。
- 模型完整46 个分片、索引、编码文件和三机哈希一致。
- 真实生成确定性问题、流式输出、Reasoning、工具调用都正确。
- 性能口径TTFT、TPOT、E2E、吞吐、并发和输入长度同时记录。
- 资源安全无 OOM、持续 Swap、PSI、重启、GPU/RDMA 硬错误。
05 · FAQ
老板最常追问的九个问题
为什么官方说单台能跑 200B，本项目 284B 却要三台？
200B 是官方面向多种模型和量化方式的产品定位，不是对任意模型的保证。本项目权重约 168.27 GB，单台物理内存只有 128 GB，权重本身已放不下。
为什么网上有人双机跑通，我们却用三机？
模型版本、权重精度、推理引擎、TP/PP 并行、缓存格式和安全余量都可能不同。双机“能启动”不等于符合本项目的内存、稳定性和协议验收要求；当前项目只对三机 PP3 路径负责。
模型标称 1M，为什么当前仍只开放 8K？
模型架构能接受与当前设备能稳定、重复、可控地承载是两件事。历史 mem=0.50 配置下，12K 重复测试在第 2 请求触发内存压力，16K 也越过安全门槛；当前大 KV 配置尚未完成同口径复验，因此继续沿用 8K 保守 cap。
三台机器能支持多少人？
不能只用“人数”回答，要看每个人的请求频率和输入长度。历史 mem=0.50 配置对 256→128 请求建议从 ≤0.10 req/s 起步；当前配置和真实业务需要重新压测。
请求到第一台后，能否用 ConnectX-7 同时发给另外两台？
物理网络可以让三台两两直连，但当前 PP=3 不能把同一份输入同时交给 Stage 1 和 Stage 2：Stage 2 所需的中间结果必须先由 Stage 1 计算产生。路径是 Rank 0 计算 → 直连 Rank 1 → Rank 1 计算 → 直连 Rank 2；这里没有额外的两跳网络转发，慢点主要来自计算依赖和阶段交接。
四台直接串联、不上交换机会不会一定更慢？
不一定。若专门做 PP=4，并让 A/B/C/D 正好对应相邻四段，三个阶段边界都能一跳直达；但 PP 多一段会增加流水线气泡，非相邻通信、TP collective、复制和运维流量也更容易受限，中间链路故障还会切断集群。四台长期集群、TP 或混合并行优先采用 NVIDIA 推荐的 200G QSFP 交换机；纯 PP4 直连环只能作为需要重新压测的实验方案。
为什么当前选择 SGLang，不直接换 vLLM 或 TensorRT-LLM？
因为推理引擎不只是 API 外壳，还决定模型结构、量化、Kernel、KV Cache、调度和多机通信。本项目只有 NVIDIA SGLang 26.07 固定栈完成了 DeepSeek V4、SM121、NVFP4 与 PP3 历史验收；当前大 KV 配置的性能和 Tool-call 仍待回归。vLLM 或 TensorRT-LLM 若替换现有引擎，也必须从兼容、正确性到性能全部重测。查看六种常见引擎对比 →
扩容是加到四台，还是再买三台？
如果目标是高可用和更多请求，优先增加第二套三机副本；把单实例继续拉长会增加故障域和通信复杂度，并不自然换来线性加速。
如何让长任务工作数小时？
不要把所有历史塞进一次请求。把任务状态、代码、测试和摘要保存在外部，每轮只携带当前需要的内容，在接近 8K 前压缩和续跑。