一个仍在验证中的推理架构
本地跑不动的模型，
能不能借云端算力，
又不交出完整会话？
今天，敏感数据要么留在本地，接受模型和硬件的上限；要么交给云端， 在服务端以可计算的形式被读取。Fusion Compute 在研究第三种路径： 让多个计算节点共同完成一次推理，但每个节点只拿到自己负责的状态片段。
一次推理所依赖的完整会话状态St
物理上拆成互补片段，分别交给不同节点
当前已验证形态：同一 Pod、两张 L4、一个完整 Layer完整状态在逻辑上仍然存在；实验检查的是，在声明的执行区间里， 它能否只由互补片段共同表示。这不是已经完成的跨云隐私产品。
01 / 用户现在面对的问题
今天的选择仍然很别扭：把敏感数据留在本地，或者把可读内容交给云端模型。
内容留在本地，能用什么模型却受硬件限制
客户对话、研发资料或医疗记录不离开自己的设备，控制权最清楚。 但显存、速度和部署成本会直接决定能使用多大的模型。
现在缺少的桥?
能不能只借用计算能力，而不把完整会话交给任何一个计算方？
模型能力更强，后端却必须接触可计算的内容
HTTPS 能保护数据在传输途中不被第三方窃听。但请求进入推理环境后， 服务端通常仍要读取 Prompt、上下文和中间状态。
HTTPS 解决的是数据在路上的保护。我们关心的是：模型开始计算以后， 是否仍然必须由某一个服务方完整看见会话。
我们把问题收窄到一项可以被实验推翻的判断能否借用外部计算能力完成精确推理，同时避免任何单一计算节点成为完整执行状态的持有者？
第一阶段先不承诺隐私。我们先验证一个更基础的前提： 在声明的执行区间内，完整 Tensor 能否只由互补片段共同表示和继续计算。
02 / Transformer 留下的技术切口
Decode 不会重算全部历史：历史留在各层 KV Cache，当前 Token 的状态逐层向前流动。
历史留下的记忆（KV Cache）
Layer 04 · K/Vhistorical tokens
Layer 03 · K/Vhistorical tokens
Layer 02 · K/Vhistorical tokens
Layer 01 · K/Vhistorical tokens
当前正在计算的 Token
当前 Token 的 residual 状态xt
读取历史 · Attention更新当前状态 · Residual加工特征 · MLP交给下一层
在 autoregressive decode 里，历史 Token 已经完成了前向计算。 它们主要以每一层的 KV Cache——供当前 Token 查询的历史 key/value 记忆—— 留在显存里。
当前 Token 的 residual，也就是承载当前 hidden state 的残差流， 才会依次穿过每个 Layer。更直观地说，它像一个计算光标：带着当前状态向前走，并在每一层读取对应的历史记忆。
这给了我们一个实际切口：分布式系统不必只会拆分“请求”， 还可以直接拆分 residual、KV 和矩阵乘法产生的中间状态。
03 / 我们正在验证的计算方式
每个节点先算局部贡献；ReduceScatter 相加并分发结果后，下一算子直接读取自己负责的输出 shard。
每个节点持有一段状态输入从一开始就没有集中在同一台设备上
→各自算出局部贡献节点只使用自己拿到的状态片段和权重
→ReduceScatter 把贡献交给负责相应输出片段的节点相加局部贡献，并只发送各节点负责的输出片段
→下一算子直接使用这些片段计算继续向前，不必先恢复完整状态
如果你熟悉分布式训练，计算主干并不陌生
局部矩阵乘法 → 定向归约 → 下一算子继续消费分片给 MLE 的一行公式
yq = Σr Wq,rxr + bq在 Qwen2.5-1.5B 的实验里，这条路径穿过 RMSNorm、Q/K/V、Attention， 经过 residual add 把新结果加回当前 Token 状态，再进入 SwiGLU（Qwen MLP 的门控非线性）和 down projection； 最后，下一层真实 Q/K/V 开始使用这些片段。
所有片段合起来必须正好覆盖完整状态
不能遗漏任何坐标，也不能让同一段受保护状态被多个节点重复持有。
声明的受保护区间内，不出现完整状态的单点持有者
节点可以拿到完成局部计算所需的数据，但不能在这段计算中恢复全量状态。
闭环必须等到下一真实算子使用这些片段
只证明 Tensor 被切开过没有意义。下一算子直接消费分片后， 这段计算才真正闭合。
04 / 为什么普通的并行切分还不够
差别不在使用哪种 collective，而在于把“后继算子直接消费 shard、不得隐藏重建”写成正确性条件。
系统边界不少 Tensor Parallel 路径我们的做法
算子边界常在边界恢复或复制完整中间状态明确记录这一刻每个状态片段归谁
后继算子下一步可能重新使用完整 hidden state下一步必须直接读取状态片段
正确性主要检查最终输出是否一致还要证明中间没有偷偷拼回完整状态
审计通常关注性能日志或 profiler记录要说明切分、归约和后继消费是否按规则发生
想解决的问题让一个集群跑得更快让外部算力和完整数据不必交给同一方
05 / 目前真正成立的工程事实
当前证据只覆盖同一 Pod 内两张 L4 上的一个 Qwen2.5-1.5B decode Layer。
分片状态走完整个 Layer，下一层 Q/K/V 直接接着使用
输入从一开始就是分片的。它经过 Attention、SwiGLU MLP 和两次 residual add， 最后由下一层真实 Q/K/V 投影直接读取这些片段。250/250 个受审计 decode step 闭合；在这段执行边界内，没有隐藏的 AllGather 或完整状态重建。
这支持一条有限结论：在已经验证的执行边界内，完整状态并非单点执行的必要条件。下一层 Q/K/V 之后仍有明确声明的兼容性 AllGather，所以它还不是多 Layer 连续分片证明。
250 / 250audited decode steps
5组独立冷启动
1.0受审计步骤闭合率
Qwen2.5-1.5B · 2× L4 · one complete Layer一个 Layer 的闭合，不能直接外推成完整隐私或生产能力
测试在下一层 Q/K/V 消费 shard 后结束；随后使用声明过的兼容性 AllGather，恢复成后续未改动 Layer 所需的完整布局。这个边界必须保留，否则读者会把 “区间内没有隐藏重建”误解成“整个模型都不重建”。
- 模型
- Qwen2.5-1.5B
- 物理环境
- 同一 Pod 内两张 L4
- 执行深度
- 一个完整 decode Layer，再到下一层真实 Q/K/V
这些结果没有提供完整隐私保证
尚未证明跨 Pod、数据中心或供应商的生产部署
尚未加入 Secret Sharing、TEE 或 MPC，也没有相应的安全证明
尚未证明恶意 worker 会被发现或阻止
尚未证明多个节点合谋时无法重建信息
尚未让分片状态连续穿过多个完整 Layer
因此现在不能声称“任何节点永远无法看到用户数据”。分片执行是后续隐私与所有权机制的结构基础， 不等于这些机制已经成立。
06 / 后续实验如何推进
后续实验分成三条独立的线：状态持续多久、拓扑扩大多少、信任边界跨多远。
状态能连续走过多少层
现在一个完整 Layer
→下一步连续多个 Layer
状态片段能连续穿过多少个真实算子和 Layer，而不被完整拼回去。
同一套结构能扩到多少节点
现在两个 GPU 节点
→下一步三个 GPU 节点
从两张卡扩到三张、四张和更多拓扑时，片段分配和通信还能不能成立。
一次推理能跨过多大的信任边界
现在同一 Pod
→下一步多个 Pod / 数据中心
从同一 Pod 走到多数据中心、多供应商时，授权、传输和失败恢复该怎么处理。
模型变大，不等于架构就更正确
模型规模、Context、Batch、精度和硬件只是实验条件
07 / 分片执行通过后，安全与授权机制才能接上来
如果分片执行继续通过验证，加密、隔离执行与可撤销授权才有明确的接入边界。
- 已验证先证明算子边界不必拼回完整状态
为每片状态指定负责节点，并证明真实算子可以沿着这种布局继续执行。
- 更远的部署验证验证跨 Pod、数据中心和供应商的运行条件
处理通信、失败恢复、参与者选择和状态迁移，而不是把同一 Pod 的结果直接外推到生产。
- 后续安全层叠加加密、隔离执行、审计与恶意 worker 防护
评估 Secret Sharing、TEE、MPC 等方法，以及合谋时的信息暴露边界。
- 长期目标把参与计算的决定权交还给用户
目标是让用户选择谁参与、何时撤销授权，并把状态迁移到新的执行环境。
我们想补上本地小模型与明文云 API 之间的那条路