让用户决定谁参与计算,
谁能持有什么状态。

目标路径与验证边界

从数据进入模型,到结果回到用户。

  1. 01
    本地为何不够本地硬件上限

    本地设备无法持续承载能力更强、上下文更长的模型。

    模型能力继续提高时,显存容量、内存带宽和功耗不会同步增长。用户越需要更强的模型,本地硬件上限就越早出现。

  2. 02
    云端留下另一半问题TOKEN 供应方可见

    云端补足了算力,也让推理服务方能够读取完整请求。

    Prompt、历史对话和相关资料到达服务端后,必须成为模型能够读取和计算的状态。HTTPS 保护传输过程,不能阻止推理执行方读取正在计算的内容。

  3. 03
    文本怎样进入计算TEXT → NUMERIC STATE

    在目标架构中,文本先在用户可控的一侧变成模型能够计算的数值状态。

    Tokenizer 把文本转成 Token ID(词元编号),模型再映射出 embedding 和逐层更新的 hidden state。这是表示转换,不是哈希或加密;数字仍然承载输入信息。

  4. 04
    我们真正要解决的问题精确推理 · 非单点状态

    能否借用外部算力完成精确推理,却不让单个节点持有完整执行状态?

    Fusion Compute 不是把数据换一种编码再交给同一个服务方,而是要重新安排状态由谁持有、计算在哪里发生、完整结果在哪里重建。

  5. 05
    Transformer 提供了入口HISTORY · CURRENT STATE

    Decode 把历史留在各层 KV Cache,当前 Token 的状态逐层向前流动。

    KV Cache 是历史 Token 的 key/value 记忆;hidden state 是当前 Token 正在向下一层传递的计算状态。两者不必每一步都恢复为一份集中状态,这给了分片执行一个结构入口。

  6. 06
    先设计所有权拓扑OWNERSHIP → TOPOLOGY

    先规定谁能持有什么,再拆分状态和计算需求。

    这里的数据主权首先意味着:由用户决定谁参与计算,以及每个参与方可以持有什么状态。单个外部参与方只获得自己的 shard;跨供应商仍是目标,不是当前证据。

  7. 07
    拓扑怎样完成计算LOCAL → REDUCESCATTER → SHARD

    每个节点只算局部贡献,网络只把对应的输出 shard 交给它的持有者。

    ReduceScatter 负责归约局部贡献,并把每段结果发给负责该段的节点。真正的后继算子随后继续读取 shard,而不是先在某个供应商侧拼回完整 Tensor。

  8. 08
    完整状态在哪里出现用户定义重建边界

    输出贡献最终回到用户可控的一侧,汇合生成结果,再把 Token ID 解码为文本。

    具体汇合什么状态、在哪里汇合、采用什么协议,仍是后续工程问题。中途任何一次隐藏 AllGather 或完整状态恢复,都会让前面的分片失去意义;用户侧汇合与解码当前尚未验证。

  9. 目标架构 · 从用户输入到用户重建

    计算可以来自外部,完整结果在哪里汇合应由用户决定。

    用户可控侧 · 输入与切分文本 → 数值状态 → shard A / shard B

    用户先定义参与方和持有规则,再把计算状态分配给外部节点。

    外部节点 A目标拓扑 · 参与方 A
    持有状态 shard A计算局部贡献 A

    不独自持有完整执行状态

    外部节点 B目标拓扑 · 参与方 B
    持有状态 shard B计算局部贡献 B

    不独自持有完整执行状态

    分布式拓扑归约局部贡献,继续传递输出 shard
    输出贡献 A 返回输出贡献 B 返回
    用户可控边界汇合生成结果 → Token ID → 解码为文本
    阅读边界

    这张图表达目标架构,不代表当前部署拓扑。跨供应商隔离、用户侧 汇合与密码学保护仍待验证。

  10. 09
    目前已经做到哪里2× L4 · 250/250

    Qwen2.5-1.5B 的一个完整 decode Layer 已在同一 Pod 的两张 L4 上闭合。

    分片状态经过 Attention、SwiGLU MLP(门控非线性)和 residual add(把结果加回当前状态),随后被下一层真实 Q/K/V 投影读取;250/250 个受审计 step 闭合。

  11. 10
    不要越过证据机制证据 ≠ 隐私产品

    当前证据证明了执行结构,不提供完整隐私保证。

    结论只到这里:在已验证边界内,完整状态并非单点执行的必要条件。端到端输入、KV Cache 全生命周期、连续多 Layer、跨供应商、用户侧解码、Secret Sharing、TEE、MPC、恶意 worker 和节点合谋都尚未证明。

  12. 09–10 · 把事实和结论分开

    当前证据只覆盖这段执行边界。

    模型Qwen2.5-1.5B
    位置同一 Pod
    硬件2× NVIDIA L4
    执行深度1 个完整 decode Layer
    闭合边界下一层真实 Q/K/V
    审计结果250 / 250 decode steps
    受审计区间起点分片 hidden state
    一个完整 LayerAttention → SwiGLU → residual
    真实后继算子下一层 Q/K/V 继续读取 shard
    边界之后显式 AllGather 恢复兼容布局

    受审计区间内没有隐藏 AllGather;边界后的显式恢复不属于当前闭合结论。

    这组证据支持在已经验证的执行边界内,完整状态并非单点执行的必要条件。
    证据尚未覆盖
    • 从原始文本开始的端到端输入路径
    • KV Cache 的完整生命周期
    • 连续多个 Layer 不恢复完整状态
    • 三节点及更一般拓扑
    • 跨 Pod、数据中心或供应商
    • 用户可控侧汇合与解码
    • Secret Sharing、TEE 或 MPC
    • 恶意 worker 与节点合谋
  13. 11
    怎样走向生产深度 · 拓扑 · 信任 · 所有权

    shard 能走多远、扩到多少节点,又能否跨过供应商和信任边界?

    这三个问题要分别验证,不能互相替代。用户侧重建、加密、隔离执行、可撤销授权、状态迁移和审计,则是其后的产品化工作。

模型能力来自外部,参与权和重建权留给用户。

第三条路径不是换一家云,
而是重新决定谁持有、谁计算、谁能重建。

用户选择谁参与计算、何时撤销授权、状态迁移到哪里。分片执行先提供 结构基础,加密、隔离执行和审计随后逐层叠加。

继续阅读完整技术说明 →回到开头 ↑