先看用户的处境
本地硬件上限本地设备跑不动真正想用的模型，用户自然会转向云端。
笔记本可以运行小模型，但模型规模、上下文长度和生成速度很快会碰到硬件上限。
从用户困境读到实验边界
问题先出现，方案随后才有意义。
- 01
- 02云端解决了一半
云端执行可见云端提供了更强的算力，也通常要在服务端读取和计算完整请求。
Prompt、历史对话和相关资料必须变成后端能够读取和计算的内容，否则模型无法完成推理。
- 03HTTPS 不是终点
传输 ≠ 执行加密传输保护了数据在路上的安全，却没有隐藏模型正在读取的内容。
请求到达推理服务以后，服务端通常仍能看到可计算的明文状态。问题从网络传输转移到了执行环境。
- 04现在缺少的桥
精确推理 · 非单点状态能否借用外部算力完成精确推理，却不让单个节点持有完整执行状态？
Fusion Compute 把这件事收窄成一个可以被实验推翻的系统问题，而不是先承诺已经实现隐私推理。
- 05Transformer 留下的切口
DECODE · KV CACHE生成下一个 Token 时，模型不会重新计算整段历史。
历史主要留在各层 KV Cache，也就是供当前 Token 查询的 key/value 记忆；逐层向前流动的是当前 Token 的状态。
- 06换一种物理表示
Sₜ → A · B把历史记忆和当前状态拆成互补片段，完整状态就不必集中在一个节点。
完整状态在逻辑上仍然存在；实验要检查的是，在声明的执行区间里，它能否始终由这些片段共同表示。
- 07每个节点怎么计算
LOCAL → REDUCESCATTER → SHARD节点只算局部贡献，再交给负责相应输出片段的节点。
ReduceScatter 在这里负责相加局部贡献，并只把每段结果发给对应节点，不先交给中心节点拼成完整 Tensor。
- 08真正困难的地方
NO HIDDEN ALLGATHER难点不是把 Tensor 切开，而是让下一算子直接使用分片结果。
如果中途隐藏地调用 AllGather，完整状态就会重新出现。只有真实后继算子直接读取 shard，这段计算才算闭合。
05–08 · 把执行路径放在一张图里 这段计算的关键，不是切分，而是分片能被下一算子接住。
节点 A L4 · 同一 Pod历史KV Cache 片段 A当前 Tokenhidden shard A只用自己的片段计算局部贡献 A
节点 B L4 · 同一 Pod历史KV Cache 片段 B当前 Tokenhidden shard B只用自己的片段计算局部贡献 B
ReduceScatter相加两侧贡献，把输出 shard 交给对应节点节点 A 持有输出 shard A节点 B 持有输出 shard B真实后继算子下一层 Q/K/V 直接读取两侧 shard已验证区间没有隐藏 AllGather边界之后下一层真实 Q/K/V 消费完成后：显式 AllGather，恢复后续未改动 Layer 所需布局。
- 09目前已经做到哪里
2× L4 · 250/250Qwen2.5-1.5B 的一个完整 decode Layer 已在同一 Pod 的两张 L4 上闭合。
分片状态经过 Attention、SwiGLU MLP（门控非线性）和 residual add（把结果加回当前状态），随后被下一层真实 Q/K/V 投影读取；250/250 个受审计 step 闭合。
- 10不要越过证据
机制证据 ≠ 隐私产品当前证据证明了执行结构，不提供完整隐私保证。
结论只到这里：在已验证边界内，完整状态并非单点执行的必要条件。下一层 Q/K/V 后仍会显式恢复兼容布局；连续多 Layer、Secret Sharing、TEE、MPC、恶意 worker、节点合谋和跨云生产都尚未证明。
09–10 · 把事实和结论分开 当前证据只覆盖这段执行边界。
模型Qwen2.5-1.5B位置同一 Pod硬件2× NVIDIA L4执行深度1 个完整 decode Layer闭合边界下一层真实 Q/K/V审计结果250 / 250 decode steps这组证据支持在已经验证的执行边界内，完整状态并非单点执行的必要条件。证据尚未覆盖- 连续多个 Layer 不恢复完整状态
- 三节点及更一般拓扑
- 跨 Pod、数据中心或供应商
- Secret Sharing、TEE 或 MPC
- 恶意 worker 与节点合谋
- 11接下来要回答什么
深度 · 拓扑 · 信任边界后续验证必须拆成三条互不替代的线。
分别验证：状态片段能连续经过多少算子和 Layer；同一套片段归属规则能扩到多少节点、适应哪些通信拓扑；这套结构能否跨 Pod、数据中心和供应商运行。