前几天技术社区出现了一个很难让人忽略的标题Show HN: Kimi K3 inference on about 100k PS3 nodes。Kimi K3 是模型PS3 是十几年前的游戏机中间再塞一个 10 万节点规模的集群。看到这个标题的第一反应是这是认真的还是一个有点浪漫的思想实验我盯着这个标题看了很久。不是因为我相信十万台 PS3 能打赢一枚 H100而是因为它逼着人重新回答一个问题大模型推理到底卡在哪里如果只要显存总量足够就能推理那这种跨节点堆硬件的思路确实有吸引力但如果真正的瓶颈不是总量而是带宽、延迟、通信和可靠性那么十万台 PS3 更像一个昂贵的教学实验。下面聊聊我自己的判断以及如果真有人想动手应该从哪里开始。1. 这个标题值得停下来但它不是“便宜算力”的答案1.1 先算一笔账100k 节点到底意味着什么先做最基础的算术100k 就是 10 万个节点。一台 PS3 的系统内存加显存总量在 512MB 这个量级十万台加起来大约 50TB。如果 Kimi K3 是一个需要数 TB 权重显存的重量级模型从纯容量上看这个规模似乎不是不可能。但真正的关键不在总量而在分布方式。这 50TB 不是一块连续的高速显存而是被切成 10 万个独立小格子每个格子之间的通信链路只是一块普通千兆网卡。让一个大模型在这堆小格子里协同推理和在一台 GPU 服务器上的推理完全是两个物种。功耗也会放大规模问题。一台 PS3 满载功耗在 200W 上下十万台就是 20MW 量级。20MW 是什么概念这已经接近一座小型数据中心的基本盘不是某个爱好者在地下室能长期养得起的。就算用模拟器或虚拟节点代替实物十万个虚拟实例的调度、网络和采购成本也不会比真机少多少。先把结论放在前面这个项目的价值不在“用旧游戏机替代 GPU 跑 Kimi K3”而在它把分布式推理的物理约束重新摆到桌面上逼你算清楚一些平时被显卡藏起来的问题。1.2 模型参数能塞进去不代表能正常推理“总内存够”和“能推理”之间隔着一整条链路。大模型推理不是把权重一次性放进内存然后原地按回车。自回归模型每生成一个 Token都要把模型权重读一遍同时在层与层之间传递张量。 GPU 推理时权重在显存里显存带宽可以做到每秒 TB 级别权重如果分散到十万个普通节点上读取权重的速度受限于每个节点的内存带宽和网卡带宽而层与层之间的同步延迟会进一步拖慢端到端速度。你可以把十万个节点想象成十万个只负责一小步计算的人。让他们合写一道大题不是不行但每写一步都要把中间结果传给下一个人。传第一千个人时还可以忍传到第十万个人时前面的人已经等得完全没有耐心了。1.3 如果节点来自模拟器问题会更复杂还有一种可能这些 PS3 节点不是真机而是用 PS3 模拟器在普通主机上起的十万个进程。那样的话模拟器本身会产生额外 CPU 开销网络行为也和真实硬件不完全一致。用模拟器做分布式实验可以验证调度逻辑、通信协议和切分方式但不能证明真实 PS3 网络的性能。换句话说这个项目最后真正能留下的很可能不是“跑通了 Kimi K3”而是“在没有 GPU 的环境里如何重新发现分布式推理的瓶颈”。2. 把大模型拆到十万个节点里真正卡住的是什么2.1 切分方式按层切还是按张量切分布式推理通常有两种切分思路。第一种是按层切分把模型的不同层放到不同节点。这种方式会形成一条很深的流水线一个 Token 必须从第一层传到第一百层串行延迟非常高。第二种是按张量切分把同一层的矩阵切到多个节点上并行算。这种方式能摊薄单层计算但每一步都需要做 all-reduce 或 all-gather对节点间带宽要求极高。切分方式适合场景对网络要求故障影响按层切分层数多、每层计算集中的流水线串行延迟高带宽要求中等断掉任何一层整条链都停按张量切分单层计算量很大的并行推理极高每次前向都要频繁通信单个节点失效整层都无法计算把这两种方式放到 PS3 集群里看都不太乐观。按层切会制造极端延迟按张量切会让普通千兆网变成最大瓶颈。十万个节点听起来把算力摊开了但摊开的同时也把每一次计算之间的依赖关系放大了。2.2 每生成一个 Token都要重走一遍整个集群自回归生成有一个容易被忽略的性质每一步生成的 Token都依赖之前所有 Token。这意味着前向链路必须严格串行执行。你可以通过提高 batch size 来提升整体吞吐也就是同时处理很多请求但单个请求的延迟不会因为你多买一批 PS3 而变短反而会因为需要跨越的节点更多而变得更长。在线推理服务既要吞吐也要延迟用十万个低速节点做在线服务延迟这一关几乎过不去。如果目标是离线跑一批文本生成延迟也许能忍但吞吐和成本依然不划算。GPU 集群之所以能把延迟压在百毫秒级并保持高吞吐靠的是单节点极快的显存读取和节点间极快的数据通路。PS3 集群一样都不占。2.3 失败的节点不是一个而是必然出现的一堆十万个节点组成的分布式系统故障不是异常而是常态。按照保守估算一台游戏机一年可能重启好几次十万台设备的日故障数量会非常可观。推理又不是 MapReduce 那种跑完就结束的离线任务它需要持续在线的状态。只要有少数节点失联正在生成中的请求就可能被中断。要在这个规模下做检查点、故障转移、请求重放和一致性协同工程复杂度会远超推理本身。这也是我觉得这类项目最容易被低估的部分。很多人第一眼看见的是“十万台 PS3 好有冲击力”但真正落地时最先让你崩溃的往往不是内存不够而是节点失联、网络抖动、训练日志缺失和永远对不齐的软件版本。3. 如果真的要动手先跑 8 个节点而不是十万个3.1 用容器模拟“弱节点 低带宽”如果你被这个项目激发了实验冲动我的建议不是去闲鱼扫货而是先在容器里复刻它的核心约束弱 CPU、小内存、低网络带宽。只有把这个约束模型复现出来你才能知道分布式推理里的哪些问题来自模型本身哪些问题来自硬件限制。更关键的是你不需要十万台 PS3也能在 8 个容器节点上看到同样的现象。# 示意用 Docker 创建 8 个资源受限节点组成一个自定义网络 docker network create --driver bridge --subnet192.168.10.0/24 ps3lab for i in $(seq 1 8); do docker run -d --name node$i \ --cpus2 --memory512m \ --network ps3lab \ alpine sleep 3600 done这个网络里的每个节点都是只有 512MB 内存、2 个 CPU 的弱节点。你可以再通过 tc 或容器网络插件限制带宽模拟 PS3 那套“算力尚可但通信很弱”的环境。然后在一台节点里启动一个小模型或者一个随机权重网络分别尝试按层切分和按张量切分。不必一上来就跑 Kimi K3先用几十 MB 到几百 MB 的模型验证流程。3.2 记录四个指标不看热闹看门道做实验时不要只记录“能不能跑通”。我建议至少记录四项指标。指标怎么测代表什么单 Token 延迟从输入发起到第一个 Token 返回在线服务的基本体验吞吐每秒生成 Token 数整体产能通信占比网络读写总耗时 / 总耗时瓶颈是不是出在通信故障恢复时间杀掉一个节点后多久恢复系统能不能长期存活这四个指标能帮你快速定位问题。尤其是通信占比如果一台 GPU 服务器上可能只占个位数百分比到了 PS3 集群上大概率会变成 70% 以上。到那时你就会明白真正卡住任务的不是计算核心而是节点之间那条细得可怜的链路。3.3 最容易踩的坑从小规模实验开始反而是最不容易迷路的路。实际动手时有四个坑比较常见资源限制还没生效就测性能最终测的是宿主机而不是弱节点。一上来就跑大模型导致整个实验被参数加载时间淹没根本看不到通信瓶颈。网络限速之前没有先确认 IP、端口和防火墙限速没生效却以为已经生效了。把大量请求一次性打进去结果无法区分是并发问题还是模型切分问题。我更建议的顺序是先单请求跑通再小批量压一下最后才把并发数拉起来。每一步都先看日志再调参数不要凭感觉改配置。4. 判断“大量旧硬件推理集群”是否值得先回答四个问题4.1 四问评估法以后如果你再看到类似的方案不管是十万台 PS3还是一堆旧手机、旧路由器、旧矿机都可以先用下面四个问题做一次快速判断。问题一模型参数真的能装下吗这里要算的不只是权重总量还要算推理过程中的 KV Cache、激活值和临时缓冲。如果连内存都装不下后面的方案再漂亮也是空谈。问题二每个 Token 需要多少内存带宽和通信带宽权重不是存进去就结束了每个 Token 都要读一遍。单节点内存带宽越低节点间通信越慢整体推理效率就越差。问题三延迟要求是多少如果是离线批处理延迟不是第一优先级如果要做在线对话或 API 服务那么单个 Token 超过几秒体验就已经不可用了。问题四你愿意投入多少运维成本十万个节点的集群日常维护成本极高。故障恢复、日志采集、监控告警、版本更新、节点淘汰每一项都需要专门工具和专人维护。很多实验项目死在这道坎上。4.2 把“灵光一闪”拆成可证伪的假设面对一个看起来很酷的想法最好的处理方式不是立刻否定也不是立刻拥抱而是把它写成一个可以被实验推翻的假设。假设可以是这样如果十万台 PS3 集群的每 Token 总成本低于一台 GPU 服务器那这个方案在经济上值得继续研究。或者如果把一个模型的权重切到 100 个节点上端到端延迟仍然能控制在 1 秒内那这个路径就有进一步优化的价值。把大判断拆成小实验之后很多问题会变得非常清晰。你不需要跑十万节点只需要先跑 8 节点、16 节点、64 节点然后画出延迟或吞吐随节点数量的变化曲线。如果曲线在 16 节点时就已经开始失衡那 100k 节点大概率只是灾难的平方。4.3 什么时候它反而是合理的我并不是说这类项目不值得做。如果核心目标不是部署生产服务而是教学、研究调度算法、验证极端约束下的通信协议那么 PS3 集群反而是一个非常合理的载体。在这种场景里Kimi K3 是不是真的完整跑完反而不重要了。重要的是它逼你面对几个真实存在的工程问题如何在低带宽环境下切分模型如何设计故障恢复如何在一个并不稳定的集群里维持在线推理。这些问题不会因为你用的是 PS3 就变得无意义反而会训练出比“调参跑 GPU”更强的系统思维。所以我的判断是它是一个有价值的思想实验但不是一个有价值的推理方案。把这两件事分开很多争议会瞬间消失。5. 这个 Show HN 真正的价值是让我们重新理解 GPU 集群的赢法5.1 GPU 赢在显存带宽、高速互连和软件栈现代 GPU 不是靠单点算力赢的而是靠高带宽显存、高速互连和成熟软件栈一起赢的。同样是做大规模并行计算如果节点之间只靠千兆网和普通交换机连接那么哪怕每台机器都有一块很强的 CPU整体效果也会非常差。PS3 的 Cell 处理器在当年确实很超前SPU 的并行思路也惊艳过不少人但把它放到大模型推理场景里第一缺的是统一内存寻址第二缺的是高带宽互连第三缺的是生态。vLLM、TensorRT-LLM、DeepSpeed 这些框架做了大量调度、显存管理、通信和推理优化。要给 PS3 重写一套类似的软件栈不是几个人业余时间能完成的事。硬件差距可以靠规模补一部分软件生态差距才是最难补的。5.2 一个反直觉的成本结论如果只是为了让一个模型的参数“凑够内存总量”十万台 PS3 的总体拥有成本很可能远超一台 GPU 服务器。二手 PS3 的单价确实不高但十万台的采购、运输、组装、散热、电费、网络改造和人工运维成本会迅速放大。即使从零开始攒一台 GPU 算力服务器前期投入可能很高但长期维护成本远比管理十万个弱节点低。这背后的逻辑是算力成本不取决于硬件单价而取决于单位 Token 的最终成本。你买一百台便宜主机每台只能发挥 5% 的利用率那它的单位成本可能比一台贵但利用率 80% 的 GPU 还要高。5.3 把这次讨论沉淀成一个“推理瓶颈检查单”如果下次再看到类似“拿奇怪硬件跑大模型”的项目你可以直接用下面这张清单做判断模型权重 KV Cache 总量是多少能不能装进总内存。单节点内存带宽够不够支撑每个 Token 的权重读取。节点间双向带宽能不能支撑层间激活值的同步。串行链路有多少层单请求端到端延迟是否可接受。节点故障时检查点、重试和恢复机制是否已经存在。单位 Token 的总体成本是否真的低于成熟方案。这六项未必都需要完全跑通才叫值得。但如果你想把这当成一次学习实验那每一项都是很好的功课。尤其是“为什么 GPU 集群能赢”这件事很多人觉得自己懂了实际上只有在亲手尝试过弱节点集群之后才会真正理解显存带宽和互连速度对推理有多重要。看完这个 Show HN 项目我不会去嘲讽它。相反我会把它当作一次提醒工程师很容易被显卡参数和框架默认配置养懒忘了去问那些最基础的物理约束。偶尔用一个看起来不靠谱的方案把所有限制条件重新摊开反而能逼出很多平时看不到的问题。如果真有人用十万台 PS3 完成了 Kimi K3 的推理哪怕慢得离谱我都会觉得这件事比又跑通一个 GPU benchmark 有意思得多。只是在那之前我建议你先从 8 个容器节点开始。