本地跑不动的模型，
能不能由多个外部节点共同完成推理，
同时不让其中任何一个持有完整执行状态？
手机和笔记本往往无法稳定运行用户真正想用的模型。转向云端后， Prompt、历史对话和相关资料通常要在服务端变成可读取、可计算的状态。 Fusion Compute 先验证一个基础前提：执行状态切成片段后， 接着执行的真实算子能否直接读取这些片段；审计同时检查这段计算中 是否发生过完整状态重建。
一次推理需要保存的历史信息和当前计算状态St
把执行状态按坐标切开：片段互不重叠，合起来覆盖完整状态。 在已验证区间内，两个节点分别持有其中一片。
当前验证只覆盖同一 Pod 内两张 L4 上的一个完整 decode Layer， 并继续执行到下一层真实 Q/K/V 直接读取这些片段。随后明确执行一次 AllGather，把状态恢复为后续未改动 Layer 所需的完整状态布局。 这不等于跨云部署或完整隐私保证。
01 / 本地运行与普通云端推理
本地设备跑不动所需模型时，转向普通云端推理往往意味着让执行方读取请求内容。
资料不交给外部推理服务，模型能力仍受本地硬件限制。
设备能提供的内存有限。模型权重和随上下文增长的推理状态， 合起来可能超过这部分容量；即使能够运行，内存带宽和持续功耗预算 也会限制生成速度。
?
借用外部算力可以避开本地硬件限制，但在普通明文执行中， 推理执行方仍能读取计算内容。
在普通明文执行中，推理执行方通常能够访问输入和中间状态。
请求进入普通云端推理环境后，Prompt、历史对话和相关资料通常会被编码为 Token ID（词元编号）和模型能够计算的张量；模型算子随后在推理环境中 读取这些张量，并写出新的中间状态。
HTTPS 保护请求抵达服务端之前的传输过程，却不阻止推理执行方读取 已经解密并参与计算的内容。传输安全与执行状态由谁持有，是两个不同的边界。
能否借用外部计算能力完成精确推理，同时避免任何单一计算节点成为完整执行状态的持有者？
这一步不提供完整隐私保证。实验只检查下面的执行条件： 在明确标出的区间内，状态被切成互不重叠的片段，这些片段合起来 恰好覆盖完整执行状态；后继算子能够直接读取片段，而不先把它重新拼回去。
02
Decode 不会重算全部历史：历史留在各层 KV Cache，当前 Token 的状态逐层向前流动。
各层 KV Cache：保存历史 Token 的 key/value，供当前 Token 查询
Layer 04 · K/V
Layer 03 · K/V
Layer 02 · K/V
Layer 01 · K/V
当前 Token 的 residual：逐层传递的 hidden state
当前正在计算的 Tokenxt
Attention 读取本层历史residual add 更新当前状态MLP 变换后再次加回更新后的状态交给下一层
在 autoregressive decode（逐 Token 生成）中，模型不会为每个新 Token 重算此前 Token 的整段前向过程。各层 KV Cache 保存历史 Token 计算得到的 key/value，供当前 Token 的 Attention 查询。
当前 Token 的 residual 是逐层传递的 hidden state。每一层先用 Attention 查询本层 KV Cache；Attention 和 MLP 的输出分别通过 residual add 写回这份状态，再交给下一层。
历史信息保存在各层，当前状态逐层移动，因此可以在每个算子边界 分别记录它们由谁持有。当前实验只检查明确标出的执行区间内， 分片状态能否被下一算子直接读取，而不先恢复完整状态； 它没有验证 KV Cache 在整个模型中的分片生命周期。
03
每个节点先算局部贡献；ReduceScatter 相加并分发结果后，下一算子直接读取自己负责的输出 shard。
进入受审计区间时，执行状态已经分片每个节点只持有其中一片；这不表示原始请求从未集中出现
→各节点计算局部贡献使用自己的状态片段和对应权重块，计算对输出的部分贡献
→ReduceScatter 求和并定向分发相加各节点的贡献，再把每个输出 shard 交给负责持有它的节点
→后继算子直接读取输出 shard计算继续向前，不先恢复完整状态
从局部贡献到输出 shard
局部矩阵乘法 → ReduceScatter 求和并定向分发 → 后继算子读取输出 shard输入 shard 与输出 shard 的关系
yq = Σr Wq,rxr + bq公式中，r 表示输入 shard 及其持有节点，q 表示输出 shard 及其持有节点。 节点 r 计算 Wq,rxr；ReduceScatter 对所有 r 的贡献求和并把结果交给节点 q，节点 q 再加入一次 bq， 得到 yq。
在 Qwen2.5-1.5B 的一个完整 decode Layer 中，分片状态先经过 RMSNorm（归一化当前状态）、Q/K/V 投影（为 Attention 生成 query、key 和 value）与 Attention；Attention 输出通过第一次 residual add 写回当前状态。随后，SwiGLU 门控 MLP 处理状态，down projection 把结果映射回 hidden size，第二次 residual add 再次写回。最后， 下一层真实 Q/K/V 直接读取这些片段。
所有片段合起来必须正好覆盖完整状态
不能遗漏任何坐标，也不能让这段受审计状态中的同一片段被多个节点重复持有。
在明确标出的受审计区间内，任何单一节点都不得持有或恢复完整状态
节点只取得完成局部计算所需的状态片段和权重块。 任何把分片收集成完整状态的隐藏 AllGather，都会违反这项条件。
验证必须继续到后继算子直接读取分片
只记录 Tensor 曾被切分，不足以证明计算能够保持分片。 后继算子必须直接读取这些片段；如果在受审计区间内通过 AllGather 恢复完整状态，这项验证就不成立。验证边界后的显式兼容性 AllGather 不属于这项结论，必须另行标明。
04
判断一条 Tensor Parallel 执行路径是否符合当前实验命题，需要检查三件事： 状态片段由哪个节点持有，后继算子是否直接读取分片，以及受审计区间内是否恢复过完整状态。
比较项以容量或性能为目标的 Tensor Parallel 实现Fusion Compute 当前实验的额外检查
算子边界状态布局由具体实现选择；有些路径会在特定边界复制或恢复完整中间状态记录每个状态 shard 在该边界由哪个节点持有
后继算子可以根据实现与性能目标读取完整状态或分片状态在受审计区间内，直接读取前一步得到的输出 shard
验收内容检查数值等价、可容纳的模型规模、吞吐和延迟在精确输出之外，检查受审计区间内是否出现完整状态重建
记录用途profiler 与通信日志用于定位吞吐、延迟和通信瓶颈执行记录用于核对 shard 持有者、归约过程和后继算子的直接读取
回答的问题模型能否跨多张加速卡容纳或更高效地运行在明确的执行区间内，单个计算节点是否必须持有完整执行状态
05
当前证据覆盖 Qwen2.5-1.5B 在同一 Pod 内两张 L4 上的一个完整 decode Layer，并延伸到下一层真实 Q/K/V 读取分片状态。
分片状态走完整个 Layer 后，下一层真实 Q/K/V 直接读取输出 shard。
实验从已经分片的输入状态开始。状态依次经过 RMSNorm、Q/K/V 投影、 Attention、第一次 residual add、SwiGLU MLP、down projection 和第二次 residual add；下一层真实 Q/K/V 随后直接读取输出 shard。 在 250 个受审计 decode step 中，这段区间都没有出现 AllGather 或完整状态重建。
当前证据支持的结论是：在已经验证的执行边界内，完整状态并非单点执行的必要条件。下一层 Q/K/V 之后，程序会显式执行兼容性 AllGather，把状态恢复成 后续未改动 Layer 需要的完整布局；所以这还不是多 Layer 连续分片证明。
250 / 250受审计 decode step
5组独立冷启动
Qwen2.5-1.5B · 同一 Pod · 2 × L4 · 1 个完整 decode Layer受审计区间止于下一层真实 Q/K/V 直接读取分片状态。
区间结束后，程序显式执行兼容性 AllGather，让后续未改动 Layer 继续使用完整状态布局。因此，区间内没有完整状态重建，不代表整个模型 都保持分片，也不能作为多 Layer 连续分片证明。
- 模型
- Qwen2.5-1.5B
- 物理环境
- 同一 Pod 内两张 L4
- 执行深度
- 一个完整 decode Layer，再到下一层真实 Q/K/V
这次实验没有验证以下事情
跨 Pod、数据中心或供应商的生产部署
Secret Sharing、TEE 或 MPC 的实现与安全性质
恶意 worker 的检测或阻止
多个节点合谋时能够重建哪些信息
分片状态连续穿过多个完整 Layer
所以，现在不能说“任何节点永远看不到用户数据”，也不能把这项结果称为 已经完成的隐私产品。实验只说明：在当前受审计区间内，真实算子可以直接 处理分片状态，完整状态不必由一个节点单独持有。
06
后续实验分成执行深度、节点数量和部署边界三条方向； 每一轮只推进其中一项，才能判断结果由哪项变化引起。
分片状态能连续穿过多少个真实算子和 Layer？
已经验证一个完整 Layer
→下一项实验连续多个 Layer
把受审计区间继续向后延伸，检查每个后继算子是否直接读取 shard；在区间终点之前，不允许通过 AllGather 恢复完整状态。
相同的持有规则能否扩到三个或更多节点？
已经验证两个 GPU 节点
→下一项实验三个 GPU 节点
节点增加后，需要重新验证状态片段如何分配、局部贡献如何归约，以及每个输出 shard 交给哪个节点。下一步先从两个 GPU 节点扩到三个。
这套执行结构能否跨 Pod、数据中心和供应商运行？
已经验证同一 Pod
→下一项实验多个 Pod / 数据中心
离开同一 Pod 后，通信、身份、授权、故障恢复和状态迁移都要重新验证。当前实验尚未跨过这些边界。
模型与运行参数需要另行记录
模型规模、上下文长度（Context）、批大小（Batch）、数值精度和硬件 会改变内存占用、通信量与运行速度，但这些变化本身不表示状态已经穿过 更多算子、更多节点或更大的信任边界。
07
当前证据只回答一个问题：在已验证区间内，后继算子能否继续读取分片状态； 跨边界部署、加密与隔离、恶意参与者防护和用户授权，都需要另外验证。
- 当前证据分片状态走完一个完整 decode Layer 后，下一层真实 Q/K/V 直接读取这些片段
结果来自 Qwen2.5-1.5B 在同一 Pod 内两张 L4 上的执行； 受审计区间结束后仍会显式执行兼容性 AllGather。
- 部署范围验证在节点数量增加，或执行跨越 Pod、数据中心和供应商后， 是否仍能遵守相同的状态持有规则
离开当前的两节点、同一 Pod 环境后，需要重新验证通信、身份、 故障恢复、参与者选择和状态迁移。
- 安全机制逐项测试 Secret Sharing、TEE、MPC 和恶意 worker 防护
Secret Sharing 和 MPC 需要检验单个参与者或合谋方能够重建哪些信息； TEE 需要说明隔离执行实际保护了什么；恶意 worker 防护则要验证 偏离协议的行为能否被发现或阻止。当前分片结构不能替代这些安全证明。
- 尚未验证让用户能够选择哪些节点参与计算、撤销授权，并把状态迁移到新的执行环境
当前证据尚不支持这些产品能力；它们仍需要独立的部署与安全验证。