分布式LLM推理撞上开放互联网的硬天花板

Hacker News May 2026
来源:Hacker Newsdecentralized AI归档:May 2026
在全球志愿者节点网络上运行大语言模型推理的梦想,正撞上残酷的工程现实。AINews分析表明,开放互联网异步、尽力而为的本质,与LLM推理对同步、低延迟执行的严苛要求根本冲突,在延迟、带宽和信任三大维度上形成了难以逾越的瓶颈。

分布式LLM推理——即任何人都可以贡献算力协作运行大语言模型——是一个令人振奋的AI民主化愿景。但开放互联网,这个为文件共享和网页浏览而设计的网络,在结构上根本无法满足现代LLM推理的实时性要求。核心矛盾在于互联网异步、尽力而为的数据包投递机制,与张量并行和流水线并行所要求的同步、低延迟特性之间的根本对立。异构节点间的延迟抖动会以不可预测的方式叠加放大,而家庭宽带的上行带宽(通常仅10-50 Mbps)在传输模型激活值时成为严重瓶颈。更糟糕的是,验证远程节点是否正确执行了分配的计算任务,需要依赖密码学证明或冗余计算,这进一步加剧了开销。

技术深度解析

分布式LLM推理与开放互联网之间的根本性矛盾,可以拆解为四个相互关联的工程约束:延迟抖动、带宽不对称、同步开销和信任验证。

延迟抖动与同步税

LLM推理,尤其是自回归解码,本质上是顺序执行的。每个token的生成步骤都依赖于前一个token。当使用张量并行(将单层计算拆分到多个设备)或流水线并行(将不同层拆分到多个设备)将推理分布到多个节点时,每一次前向传播都需要多次all-reduce或点对点通信。在配备InfiniBand(延迟1-10微秒)的专用集群上,这尚可管理。但在开放互联网上,节点间的往返时间(RTT)可能从10毫秒到超过500毫秒不等,而抖动(延迟的标准差)往往超过均值的50%。

以70B参数模型为例,使用4节点张量并行。每个Transformer层需要两次all-reduce操作(一次用于注意力机制,一次用于前馈网络)。80层意味着每个token需要160次all-reduce。如果每次all-reduce增加20毫秒的网络延迟(对于跨洲链路已属乐观估计),那么每个token的总延迟将超过3.2秒——这对于交互式应用完全不可接受。落后节点效应(straggler effect)会进一步放大问题:一个慢节点迫使所有其他节点等待,而在开放互联网上,最慢的节点往往比中位数节点慢一个数量级。

带宽不对称

家庭互联网连接本质上是非对称的。典型的FTTH(光纤到户)提供1 Gbps下行,但上行仅50-100 Mbps。有线电视网络更差:200 Mbps下行,10-20 Mbps上行。对于分布式推理,上行带宽是关键路径,因为节点必须向对等节点发送激活值和梯度。对于70B模型,隐藏维度为4096,使用FP16精度,单个Transformer层的隐藏状态大小为每个token 8 KB。80层、4节点的情况下,每个节点每个token需要上传约160 KB。以50 Mbps上行带宽计算,仅数据传输就需要25毫秒——这还不包括任何计算或同步开销。

| 网络类型 | 下行速度 | 上行速度 | 延迟(RTT) | 每层每token延迟(4节点) |
|---|---|---|---|---|
| 专用集群(InfiniBand) | 200 Gbps | 200 Gbps | 1 μs | 0.1 ms |
| 家庭光纤 | 1 Gbps | 100 Mbps | 10 ms | 25 ms |
| 家庭有线电视 | 200 Mbps | 20 Mbps | 20 ms | 80 ms |
| 移动5G | 100 Mbps | 20 Mbps | 30 ms | 100 ms |

数据要点: 专用基础设施与家庭互联网之间,每个token的延迟差距高达250倍到1000倍,这使得在开放互联网上进行实时分布式推理对交互式应用而言完全不切实际。

信任验证开销

在去中心化网络中,如何确保远程节点确实正确执行了矩阵乘法?朴素的方法——在多个节点上冗余执行——会使计算成本翻倍或三倍。zk-SNARKs或zk-STARKs等密码学方法可以证明正确执行,但为单个Transformer层生成证明目前需要GPU运行数分钟,远超实际计算所需的毫秒级时间。乐观验证(随机抽查部分节点)降低了开销,但引入了概率性保证,不适用于安全关键型应用。Petals项目通过使用信誉系统和冗余来规避这个问题,但这仅适用于小型、可信的网络。

值得关注的GitHub仓库:
- Petals (github.com/bigscience-workshop/petals):一个去中心化平台,用于在志愿者节点上运行BLOOM等LLM。采用流水线并行并具备容错能力。4.5k星。近期工作聚焦于改进落后节点处理。
- Hivemind (github.com/learning-at-home/hivemind):Petals所使用的底层去中心化深度学习库。实现了去中心化平均和容错all-reduce。2.1k星。
- FlexGen (github.com/FMInference/FlexGen):专注于将模型卸载到CPU/NVMe进行单节点推理,但其调度见解同样适用于分布式场景。1.8k星。

关键参与者与案例研究

Petals(BigScience Workshop)

开放互联网分布式推理最著名的尝试。Petals允许用户贡献GPU算力来服务176B参数的BLOOM模型。在实践中,它在理想情况下为单个用户实现每秒1-2个token的生成速度——远低于实时聊天所需的每秒50+ token。项目自身的基准测试表明,节点数超过4个后,通信开销会导致吞吐量下降。

Together AI 与 Fireworks AI

这些公司也运营分布式推理,但使用的是受控的高带宽基础设施(配备RDMA的专用数据中心)。它们通过专有调度和模型并行优化实现了有竞争力的延迟,但它们并非开放互联网——它们是私有集群。

更多来自 Hacker News

一条推文代价20万美元:AI Agent对社交信号的致命信任2026年初,一个在Solana区块链上管理加密货币投资组合的自主AI Agent,被诱骗将价值20万美元的USDC转移至攻击者钱包。触发点是一条精心伪造的推文,伪装成来自可信DeFi协议的智能合约升级通知。该Agent被设计为抓取社交媒体Unsloth 联手 NVIDIA,消费级 GPU 大模型训练速度飙升 25%专注于高效 LLM 微调的初创公司 Unsloth 与 NVIDIA 合作,在 RTX 4090 等消费级 GPU 上实现了 25% 的训练速度提升。该优化针对 CUDA 内核内存带宽调度,从硬件中榨取出每一丝性能——此前这些硬件被认为不足Appctl:将文档一键转化为LLM工具,AI代理的“最后一公里”终于打通AINews发现了一个名为Appctl的开源项目,它成功弥合了大语言模型与现实系统之间的鸿沟。通过将现有文档和数据库模式转化为MCP工具,Appctl让LLM能够直接执行操作——例如在CRM中创建记录、更新工单状态或提交网页表单——而无需定查看来源专题页Hacker News 已收录 3034 篇文章

相关专题

decentralized AI49 篇相关文章

时间归档

May 2026784 篇已发布文章

延伸阅读

Kestrel开源框架:从科技巨头手中夺回AI Agent主权Kestrel,一款新兴的开源AI Agent框架,正以“Agent主权”为核心挑战行业现状——它允许开发者在私有硬件上部署自主Agent,完全无需依赖集中式云API。这一设计直击数据锁定与平台控制痛点,为当前主流的云依赖型Agent生态提UNIMATRIx 构建AI社会:自主代理协作、竞争与解决复杂问题开源项目UNIMATRIx正在开创一个AI代理社会,这些代理通过去中心化协调自主互动、谈判并解决复杂问题。这标志着从单一模型工具向协作式AI生态系统的范式转变,有望彻底改变各行各业的自动化进程。单二进制Linux AI代理:悄然发生的智能去中心化革命一个全新的开源项目,将完整的LLM驱动代理——包括规划、代码执行、网页浏览和文件管理——压缩进一个可在任何Linux系统上运行的单一二进制文件中。这一突破消除了云API成本、数据泄露风险和网络延迟,有望重新定义边缘设备、个人服务器和企业基础WebLLM:浏览器变身AI引擎,去中心化推理时代正式到来WebLLM正在重新定义AI的边界——无需服务器支持,直接在浏览器内实现高性能大语言模型推理。借助WebGPU与激进优化,该引擎在消费级硬件上达到接近原生的速度,标志着从云端集中式AI向去中心化、隐私优先计算的范式转移。

常见问题

这篇关于“Distributed LLM Inference Hits the Open Internet's Hard Limits”的文章讲了什么?

Distributed LLM inference—the idea that anyone can contribute compute to run a large language model collaboratively—is an inspiring vision for democratizing AI. But the open intern…

从“Why Petals distributed inference is slow”看,这件事为什么值得关注?

The fundamental tension between distributed LLM inference and the open internet can be broken down into four interconnected engineering constraints: latency jitter, bandwidth asymmetry, synchronization overhead, and trus…

如果想继续追踪“Open internet latency jitter impact on AI”,应该重点看什么?

可以继续查看本文整理的原文链接、相关文章和 AI 分析部分,快速了解事件背景、影响与后续进展。