Shard 是一个用于大模型跨机器、跨 GPU 的流水线并行推理引擎。它将 Transformer 模型按连续层切分到多张 GPU 上，每个节点只加载自己负责的层块，请求通过网络在各阶段之间传递激活值完成推理。项目重点展示了在公网 WAN 环境下，将超大模型如 GLM-5.2 744B、gpt-oss-120B 分布到多台消费级或准专业 GPU 上进行可用速度推理的能力，并通过 speculative decoding、异步流水线、direct-return ring、CUDA Graph draft 等技术降低公网延迟影响。
适用领域
大语言模型推理 / 分布式推理 / 流水线并行 / 跨机器 GPU 计算 / 推测解码 Speculative Decoding / 去中心化 GPU 网络 / 模型服务基础设施 / 高性能计算 / 公网 WAN 分布式系统
配置难度
高。该项目涉及 LLM 推理、模型分层切分、CUDA/PyTorch、KV cache、speculative decoding、CUDA Graph、加密网络传输、多节点部署和 WAN 调优。适合有分布式系统和大模型推理经验的高级开发者或研究团队，不适合初学者直接上手。
商业价值
商业价值较高但成熟度仍需验证。Shard 解决的是超大模型无法被单张 GPU 承载的问题，并进一步探索将分散 GPU 资源组织成可用推理网络。如果技术稳定，可用于去中心化 GPU 算力平台、低成本大模型推理服务、闲置 GPU 变现、企业跨地域 GPU 资源池化等场景。其可验证 receipt 和加密传输设计有助于建立可信推理网络。不过，隐私保护、恶意节点防护、网络稳定性、自动调度、容错和易部署性仍是商业化落地前必须解决的关键问题。
01
技术亮点
- 支持将模型按连续层切分到不同机器的 GPU 上，单个节点不需要持有完整模型
- 重点优化公网 WAN 场景，而不仅是同机多卡或数据中心内网
- 通过 speculative decoding 将一次网络往返摊销到多个 token 上
- 通过 async pipelining 让多个 verify chunk 同时在 pipeline 中飞行，降低端到端延迟对吞吐的限制
- direct-return ring 设计让尾节点直接返回 coordinator，减少回传跳数
- CUDA Graph 优化小 draft 模型，README 中声称 GLM-4-9B draft 单 token decode 从 49.7ms 降至 13.1ms
- 提供可验证 receipt，包含 GPU UUID、公网 IP、地区、RTT、输出 hash、优化一致性检查等
- 通信层采用 pickle-free framing，并使用 ChaCha20-Poly1305 基于 SHARD_PSK 进行认证加密，降低远程代码执行和被动窃听风险
- Apache-2.0 许可证，便于商业和研究使用
- 项目定位清晰，面向去中心化 GPU 推理网络与 c0mpute 基础设施
02
目标用户
- 需要运行超大参数模型但单卡显存不足的 AI 工程师
- 研究分布式 LLM 推理架构的开发者和研究人员
- 拥有多台分散 GPU 机器、希望组合算力的团队
- 构建去中心化 GPU 算力网络的平台方
- 关注推测解码、流水线并行、WAN 推理优化的系统工程师
- 希望在消费级显卡上运行 100B 级以上模型的高级玩家或实验团队
03
配置要求
- Python 环境，项目主要语言为 Python
- NVIDIA GPU，运行大型模型时需要高显存 GPU，例如 RTX 4090、RTX PRO 6000 等
- CUDA 与兼容的深度学习框架环境
- 每个节点需要能够加载自己负责的模型层块和 KV cache
- 多节点之间需要公网或内网可达，当前阶段可能需要开放端口
- 需要配置共享密钥 SHARD_PSK 来启用加密认证传输
- 运行 GLM-5.2 744B 级别模型需要多张高显存 GPU，README 示例为 6 张 RTX PRO 6000 加 coordinator
- 运行 gpt-oss-120B 示例需要多张 24GB 级消费卡，README 示例为 3 张 RTX 4090 加 coordinator
- 需要模型权重、分片策略、节点拓扑、ring 顺序等配置
- 如果使用 CUDA Graph draft，需要支持 CUDA Graph 的稳定推理环境，并保证静态 KV cache 与 speculative rollback 正确
04
适用场景
- 将一个无法装入单张 GPU 的大模型切分到多台机器上进行推理
- 在公网环境下跨地区组织 GPU 节点，进行大模型推理实验
- 研究 speculative decoding 在高延迟 WAN 场景中的吞吐优化效果
- 构建去中心化、可验证的 LLM 推理网络
- 验证超大模型在异构 GPU 集群上的分层加载与执行能力
- 为 GPU 算力共享、按 token 计费、志愿者 GPU 网络等业务形态提供底层原型
05
部署与配置
- 克隆仓库：git clone https://github.com/leyten/shard.git
- 进入项目目录：cd shard
- 建议创建 Python 虚拟环境：python -m venv .venv && source .venv/bin/activate
- 安装项目依赖。README 未明确给出 requirements 文件或安装命令，需查看仓库中的 pyproject.toml、requirements.txt 或相关脚本后执行对应安装命令。
- 准备可用的 NVIDIA GPU、CUDA、PyTorch 或相关推理依赖环境。
- 在各个 GPU 节点上放置对应模型分片或允许节点只加载分配到的层。
- 配置节点之间的网络连通性，目前 README 提到直接开放端口是当前方案，NAT hole-punching 和 relay fallback 仍属于后续阶段。
- 设置共享密钥 SHARD_PSK，用于节点之间 ChaCha20-Poly1305 加密认证通信。
- 根据 phase0/ 或 research/ 下的启动脚本运行 coordinator 和 stage 节点。
- 使用 receipt/proof 工具验证运行结果、GPU UUID、IP、RTT、输出 token hash 等信息。
06
风险与注意事项
- 项目仍处于较前沿和实验性质阶段，README 中 Phase 1、Phase 3 的多个能力尚未完成，例如 NAT hole-punching、relay fallback、动态层分配、容错、per-token payouts 等
- 运行门槛很高，需要多台 GPU 机器、模型权重、网络配置和较强系统调试能力
- 公网推理对网络稳定性、RTT、带宽、丢包、节点可用性高度敏感
- 虽然传输层加密，但参与节点必须解密并处理激活值，中间激活仍可能泄露部分用户输入信息，隐私问题尚未完全解决
- README 中展示的高性能结果依赖特定硬件、拓扑、模型格式和优化路径，普通用户复现难度可能较高
- 当前似乎更偏研究和基础设施原型，生产化 API、监控、部署文档、错误处理和运维工具可能不足
- 如果节点来自不可信参与者，存在恶意节点返回错误结果、窃取激活、拒绝服务等风险
- 超大模型权重获取、许可、存储和加载本身可能是重大障碍
- 跨地区公网传输可能带来合规、数据安全和成本问题
2026-06-21
第23名
新收录 · github_search
