03 · 工作原理 · 零基础动画
从一个请求，
看懂三机大模型怎么工作
沿着“请求怎么跑 → 数据怎么存 → 模型怎么切 → 设备怎么连 → 引擎怎么选”逐层学习。关键路径都能播放、暂停和单步查看。
本页解决什么用动画回答“请求怎么跑、数据怎么存、机器怎么协作”建议按 01 → 08 顺序学习
01 · 先看完整请求
一个请求，如何经过三台设备？
当前实际方案是 PP=3：43 层模型切成 14 / 14 / 15 层。三台不是各自回答，而是像一条流水线依次加工。
用户 / 业务系统发来一段输入
返回一个 Token然后再跑下一轮
请求进入
问题先到第 1 台设备
Rank 0 接收 API 请求，把输入 Token 整理成模型能处理的批次。
关键理解：一次输出不是只穿过三台一次。输入阶段先走完整条流水线；之后每生成一个新 Token，三台还要再协作一轮。因此三台主要让模型“装得下”，不会让单次回答直接快 3 倍。
02 · Token 生产
模型不是一次写完，而是一个 Token 一个 Token 地猜
Token 可以是字、词、标点或词的一部分。模型每轮计算“下一个 Token 的可能性”，选出一个，再把它接回上下文继续计算。
示例问题“三台设备怎样协同？”
1切分输入文字 → Token
→
2Prefill读完输入，建立 KV
→
3预测概率计算下一个候选
→
4选中并追加再回到第 3 步
首个 Token1 → 2 → 3 → 4后续 Token3 ↔ 4 循环
输入 Tokens
三台设备怎样协同？
本轮候选
三台 72%它们 17%首先 6%
正在返回
已生成 0 个 Token
一次处理整段输入
把系统提示、历史、用户问题一起读入并建立 KV Cache。输入越长，首字等待 TTFT 通常越长。
每轮只生成下一个 Token
不断复用已有 KV，追加新 Token。回答越长，Decode 轮数越多，用户看到的是逐字流式输出。
03 · 上下文管理
上下文像一只固定容量的行李箱
系统提示、工具说明、聊天历史、当前问题和回答空间都要装进同一个窗口。模型“支持 1M”不等于这套设备能稳定装下 1M。
示例输入预算2,048 tokens
服务硬窗口12,288 tokens
沿用的准入 cap 8K硬窗口 12K
系统提示工具定义聊天历史当前输入回答余量未占用
- 先留回答空间不要把窗口全塞成输入，否则模型没有足够空间输出。
- 历史要做取舍保留最近和最相关内容，旧对话可摘要，不应无限累积。
- 试点继续卡在 8K历史 mem=0.50 配置下 4K、8K 冷长输入通过；当前大 KV 配置继续沿用该保守 cap，完整矩阵待重跑。
04 · KV Cache
KV Cache 是模型的“计算草稿”，不是长期记忆
模型把已经读过 Token 的关键中间结果暂存起来。下一轮生成时直接复用，避免从头重算；代价是 Token 越多、并发越高，缓存占用越大。
同时在途：
单个请求的 Token
每个已处理 Token 留下一组可复用的 K / V →
全部请求的 KV Cache
概念占用1 个请求 × 4 个 Token
示意图只展示“随 Token 和并发增长”的关系；实际字节数取决于模型结构、精度和推理引擎，本项目未把概念图当作精确显存测量。
权重是模型长期固定的能力；KV Cache 是某次请求运行时产生的临时数据。
请求结束后可以释放，不能替代企业知识检索，也不是跨会话永久记忆。
少做重复计算，让逐 Token 生成可行；但也成为长上下文和高并发的核心容量瓶颈。
05 · 再理解模型切分
“用了多台机器”，可能是四件完全不同的事
点击模式，观察模型怎么切、数据怎么走。当前项目采用 PP=3；其他模式用于理解取舍，不代表已在本项目全部实测。
同屏对比TP：同时计算后汇合；PP：按 Stage 顺序交接
TP · 张量并行
两个人同时切同一块“计算蛋糕”
第 17 层
设备 A计算左半设备 B计算右半
汇合 / Collective结果对齐后，才能进入下一层
第 18 层 · 再来一遍
网络特点：同一层被拆到多台，层内通常需要多次 All-Reduce / All-Gather 等集合通信。计算可以并行，但同步频繁；跨机延迟、带宽和拓扑会直接放大到每一层。
- 形象比喻
- 两位厨师合做每一道菜，每道菜出锅前都要对一次配方。
- 适合
- 低延迟、高带宽互联，且单层计算值得拆分的场景。
PP · 流水线并行
三个人各守一段生产线
Stage 01–14 层中间结果Stage 115–28 层中间结果Stage 229–43 层ABCA / B / C 是不同请求或分块；每一个仍按 0 → 1 → 2
网络特点：每台保存连续的一段层，只在阶段边界发送激活数据。跨机通信次数比多机 TP 少，但 Stage 2 必须等待 Stage 1 的输出；不同请求可以错峰占据三个工位，单个 Token 的依赖顺序仍不能靠更快网卡取消。
- 形象比喻
- 洗菜、炒菜、装盘各由一人负责，盘子必须按顺序流转。
- 适合
- 模型首先要“装得下”，并希望减少跨节点高频同步。
直接回答老板
为什么 PP 看起来“挨个遍历”？
不是 ConnectX-7 只能串行，而是后面一段的输入必须由前面一段算出来。网卡是高速公路，PP 是工序规则：把路修得再宽，也不能在“洗菜”完成前先“装盘”。SGLang 可以用分块 Prefill、异步发送和多请求调度让不同批次在三段上重叠，提升吞吐；但一个 Token 的因果依赖仍是 Stage 0 → Stage 1 → Stage 2。
先分清三个目标。PP 解决“模型装不下”；TP 用高频通信换取层内并行；多副本才增加独立实例数量和接管空间。
06 · 再看物理网络
模型怎么切是一回事，设备怎么连是另一回事
先比较两机和三机容量，再用动画分别观察当前三机三角直连，以及四机串链、直连环和交换机。
两台还是三台
少一台可能少一个阶段，但首先要确认内存安全
两台数据是容量均摊推算，未在本项目跑过；三台数据来自当前 PP3 实测。
2 台 DGX Spark
约 84.14 GB每台平均权重约 43.86 GB账面剩余 / 台
- 若做 PP=2，43 层可近似分成 21 / 22 层，只有 1 个阶段边界。
- 节点更少、逻辑路径更短、故障点更少。
- 但剩余空间还要容纳操作系统、计算工作区、KV Cache、通信缓冲和峰值波动。
- 若改做 TP=2，则不是“少一段 PP”，而是进入每层高频同步的另一种架构。
3 台 DGX Spark
约 56.09 GB每台平均权重约 71.91 GB账面剩余 / 台
- 实际 PP=3，43 层按 14 / 14 / 15 分段，有 2 个阶段边界；当前三 Rank health 正常。
- 4K/8K、典型并发与基础 Function-call 来自 mem=0.50 历史验收。
- 当前三 Rank 的 KV Token 池均为 1,579,520，但新配置完整性能与 Tool-call 仍待复验。
- 代价是多一个计算阶段和故障域，任一节点退出都会中断实例。
“平均权重”和“账面剩余”仅用 168.27 GB 权重除以节点数帮助理解；实际各层、Embedding、专家和运行时并不保证完全均匀，不能据此签署两机可行性。
三机请求路径
物理上两两直连，逻辑上仍按 Stage 顺序
当前三条 200G 直连组成三节点 Ring；三节点 Ring 在几何上就是一个三角形，每对设备之间都有直接物理链。
200G 直连
200G 直连
200G 直连
先看物理网络三根 200G 线组成三角形
0↔1、1↔2、0↔2 都有 ConnectX-7 直接链路，不需要借另一台设备做网络转发。
物理三角形
三节点 Ring 的每一对设备都直接连接。
逻辑流水线
Stage 2 的输入必须等 Stage 1 计算产生。
不是网络遍历
Spark 2 是计算工位，不是替 Spark 1 转发数据的路由器。
第三条线仍有用
可服务 NCCL collective、验证和其他通信算法。
四机怎么连
不经过交换机不一定“不能用”，但适用范围会变窄
NVIDIA 对四台及以上给出的正式玩法是 200Gbps QSFP 交换机。这里把直连串链、直连环和交换机三种路径分开看。
Stage 0A 先处理第 1 段模型层
此时只有 A 在处理当前 Token；下一台需要等待 A 产出的中间激活。
相邻阶段一跳直达，但扩展性、非相邻通信和故障恢复最弱。
比串链对称，适合 Ring collective；仍需新地址计划和 NCCL 压测。
每台一根 200G QSFP 接入同一二层桥域，适合 TP、混合并行和继续扩容。
“光交换机”不是唯一判断标准：真正要确认的是至少 4 个 200Gbps QSFP56-DD 端口、端口速率、同一二层桥域和 NCCL 验收。DAC 铜缆或光模块取决于交换机与距离；“有光口”不等于满足 DGX Spark 集群要求。
当前建议继续保留三机 PP=3 作为已验证基线。
若要验证“两机是否更快”，单独做 PP2/TP2 容量与性能试验；若增加第 4 台，不要仅凭“层更少”判断更快。纯 PP4 可先做直连 Ring 小试，但面向 TP、混合并行或长期四机集群，应按 NVIDIA 路径配置 200G QSFP 交换机。
07 · 最后选择推理引擎
同一模型换一个引擎，不只是换“启动命令”
推理引擎负责排队、批处理、KV Cache、并行通信、计算内核和 API。模型能被识别，不代表量化、内核、多机和工具调用都能正确工作。
业务应用聊天、Agent、知识库
请求推理引擎调度 · 缓存 · 并行 · API
计算模型与硬件权重 · Kernel · GPU / CPU
多个请求进入
高性能集群 ServingSGLang
Radix CachePP / TPOpenAI API
批次 1批次 2批次 3
| 引擎 / 工具 | 最适合 | 多机与服务能力 | 本项目结论 |
|---|---|---|---|
| SGLang当前实测 | 大模型、高吞吐、前缀复用、Agent 服务 | TP / PP、多节点、批处理、OpenAI API | 保留。26.07 固定栈已完成真实验收。 |
| vLLM主流 Serving | 广泛模型生态、通用 OpenAI 兼容服务 | PagedAttention、连续批处理、TP / PP / DP / EP | 可列入对照测试，但本 checkpoint + SM121 NVFP4 未验证。 |
| TensorRT-LLMNVIDIA 深度优化 | 追求 NVIDIA GPU 极致性能和可控编译优化 | In-flight batching、TP / PP / EP、多机 | 潜力高、适配成本也高；不能把其他 GPU 的成绩套到 DGX Spark。 |
| TGI维护模式 | 已有 Hugging Face TGI 存量服务 | 连续批处理、TP、流式输出、监控 | 官方已进入维护模式，新项目优先评估 SGLang 或 vLLM。 |
| llama.cpp轻量本地 | GGUF、CPU / GPU 混合、桌面和边缘设备 | 单机优先，也提供本地 OpenAI 兼容服务 | 适合更小的 GGUF 模型；不是本 NVFP4 三机方案的直接替代。 |
| Ollama易用入口 | 个人开发、本地模型下载与快速体验 | 安装和模型管理简单，集群调优不是核心定位 | 适合 PoC 和个人使用；不要与三机生产 Serving 直接比 tok/s。 |
选型原则
先验证“能正确跑”，再比较“谁更快”
同一个模型至少要对齐权重格式、量化路径、GPU 架构、并行方式、输入长度、并发、缓存状态和 API 功能后，才有资格横向比较。当前项目只有 SGLang 具备本设备历史验收证据；当前大 KV 配置和其他引擎都不能直接套用旧性能。
08 · 回到历史实测
看懂原理后，再看 mem=0.50 基线的实测边界
以下是 2026-08-15/16 现场数据，不是当前大 KV 配置，也不是厂商理论峰值。
主要拉长“首字等待”
Prefill 要先读完整段输入并建立 KV，所以 8K 的第一字比 4K 更慢。
总产出更高，单人尾部等待更久
C8 的短请求 TTFT p95 达 25.027 秒；C4 为 4.919 秒。吞吐档不等于体验档。
8K 是当前准入线，不是新配置签署线
8K 历史通过12K 历史压力区
历史配置下 12K 重复长请求因内存 PSI 失败、16K 未通过安全测试；当前入口继续封顶 8K，等待新配置复验。