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 步
输入 Tokens
三台设备怎样协同？
本轮候选
三台 72%它们 17%首先 6%
正在返回
已生成 0 个 Token
一次处理整段输入
把系统提示、历史、用户问题一起读入并建立 KV Cache。输入越长，首字等待 TTFT 通常越长。
每轮只生成下一个 Token
不断复用已有 KV，追加新 Token。回答越长，Decode 轮数越多，用户看到的是逐字流式输出。
03 · 上下文管理
上下文像一只固定容量的行李箱
系统提示、工具说明、聊天历史、当前问题和回答空间都要装进同一个窗口。模型“支持 1M”不等于这套设备能稳定装下 1M。
示例输入预算2,048 tokens
服务硬窗口12,288 tokens
生产输入上限 8K硬窗口 12K
系统提示工具定义聊天历史当前输入回答余量未占用
- 先留回答空间不要把窗口全塞成输入，否则模型没有足够空间输出。
- 历史要做取舍保留最近和最相关内容，旧对话可摘要，不应无限累积。
- 生产卡在 8K4K、8K 冷启动长输入通过；12K 重复请求触发内存压力，16K 未通过安全测试。
04 · KV Cache
KV Cache 是模型的“计算草稿”，不是长期记忆
模型把已经读过 Token 的关键中间结果暂存起来。下一轮生成时直接复用，避免从头重算；代价是 Token 越多、并发越高，缓存占用越大。
同时在途：
上下文 Token
每个已处理 Token 留下一组可复用的 K / V →
KV Cache 块
概念占用1 个请求 × 4 个 Token
示意图只展示“随 Token 和并发增长”的关系；实际字节数取决于模型结构、精度和推理引擎，本项目未把概念图当作精确显存测量。
权重是模型长期固定的能力；KV Cache 是某次请求运行时产生的临时数据。
请求结束后可以释放，不能替代企业知识检索，也不是跨会话永久记忆。
少做重复计算，让逐 Token 生成可行；但也成为长上下文和高并发的核心容量瓶颈。
05 · 部署模式
“用了多台机器”，可能是四件完全不同的事
点击模式，观察模型怎么切、数据怎么走。当前项目采用 PP=3；其他模式用于理解取舍，不代表已在本项目全部实测。
容量扩展 ≠ 性能扩展 ≠ 高可用。PP 解决“装不下”；TP 用高频通信换取层内并行；双副本才真正增加实例数量并提供接管空间。
06 · 回到真实数据
看懂原理后，再看这套三机的实测边界
以下是资料包中的现场数据，不是动画推演，也不是厂商理论峰值。
主要拉长“首字等待”
Prefill 要先读完整段输入并建立 KV，所以 8K 的第一字比 4K 更慢。
总产出更高，单人尾部等待更久
C8 的短请求 TTFT p95 达 25.027 秒；C4 为 4.919 秒。吞吐档不等于体验档。
8K 是生产线，不是模型理论线
8K 已验证12K 压力区
12K 重复长请求因内存 PSI 失败，16K 未通过安全测试；因此生产输入封顶 8K。