企业官网建设流程全解析

前几天，技术社区出现了一个很难让人忽略的标题：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 --subnet=192.168.10.0/24 ps3lab for i in $(seq 1 8); do docker run -d --name node$i \ --cpus=2 --memory=512m \ --network ps3lab \ alpine sleep 3600 done

这个网络里的每个节点都是只有 512MB 内存、2 个 CPU 的弱节点。你可以再通过 tc 或容器网络插件限制带宽，模拟 PS3 那套“算力尚可但通信很弱”的环境。

然后在一台节点里启动一个小模型，或者一个随机权重网络，分别尝试按层切分和按张量切分。不必一上来就跑 Kimi K3，先用几十 MB 到几百 MB 的模型验证流程。

3.2 记录四个指标，不看热闹看门道

做实验时，不要只记录“能不能跑通”。我建议至少记录四项指标。

这四个指标能帮你快速定位问题。尤其是通信占比，如果一台 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 把这次讨论沉淀成一个“推理瓶颈检查单”

如果下次再看到类似“拿奇怪硬件跑大模型”的项目，你可以直接用下面这张清单做判断：

1. 模型权重 + KV Cache 总量是多少，能不能装进总内存。
2. 单节点内存带宽够不够支撑每个 Token 的权重读取。
3. 节点间双向带宽能不能支撑层间激活值的同步。
4. 串行链路有多少层，单请求端到端延迟是否可接受。
5. 节点故障时，检查点、重试和恢复机制是否已经存在。
6. 单位 Token 的总体成本，是否真的低于成熟方案。

这六项未必都需要完全跑通才叫值得。但如果你想把这当成一次学习实验，那每一项都是很好的功课。尤其是“为什么 GPU 集群能赢”这件事，很多人觉得自己懂了，实际上只有在亲手尝试过弱节点集群之后，才会真正理解显存带宽和互连速度对推理有多重要。

看完这个 Show HN 项目，我不会去嘲讽它。相反，我会把它当作一次提醒：工程师很容易被显卡参数和框架默认配置养懒，忘了去问那些最基础的物理约束。偶尔用一个看起来不靠谱的方案把所有限制条件重新摊开，反而能逼出很多平时看不到的问题。

如果真有人用十万台 PS3 完成了 Kimi K3 的推理，哪怕慢得离谱，我都会觉得这件事比又跑通一个 GPU benchmark 有意思得多。只是在那之前，我建议你先从 8 个容器节点开始。