多机异构显卡组合推理

[NorthGod]

做了个项目，代码还在改，发出来是想听听各位的看法。

项目作用

我手头有几张不同型号的显卡，平时大部分时间都是闲着。想跑大模型，结果单张显存放不下，就想着能不能把它们拼起来用。

项目叫 织云 Loom，做的事情不复杂：就是把几张显卡在内网里连起来，变成一台机器跑大模型，对外接口兼容 OpenAI 的格式。如果某张卡突然挂了，服务也不会断。

仓库： https://gitee.com/NorthGod_BFDG/LoomNode

与其它项目的区别

我没在跟 vLLM 比。vLLM 解决的是确定硬件上怎么把模型跑快，做得很好，我们也经常看它的代码。和我想解决的问题不太一样：几张型号不同的卡，可能随时掉线，这种情况下怎么稳定把服务撑住。关注点不同，不冲突。

踩过的坑

一开始我是想做公网的。想法挺简单，把不同地方的卡凑一起用。跨省推理我确实跑通过，当时觉得这事有戏。

后来才发现不行。

公网上跨省的延迟是物理层面的，代码怎么都消不掉。这个延迟到了推理流水线里会被放大，我连着改了好几个晚上，能试的优化都试了，没用。最后认了，公网这条线整个砍掉，回到内网。

这个决定当时很难，但现在回头看是对的。

Token 生成速度

数字是我自己测的，不同阶段跑的，不是统一基准，各位看个大概就行：

• 单卡 5090 ，跑 80 亿参数模型，高并发情况大概 1850 tokens/秒。这个数我们测下来跟 vLLM 差不多；
• 同一张卡，开 int4 量化，把 300 亿参数模型塞进去，207 tokens/秒。同配置 128K 长上下文也能跑；
• 容错：跑的时候我把主力节点直接杀了，大概 6.7 秒 切到备用，请求没丢。

现在能用吗

还不能。源码没发，文档先公开了。发这个帖子就是想问问：你们觉得这东西有用吗？在你的场景下，最需要它解决什么问题？

请给我讲讲大家的需求，或者纯粹的评价一下项目——好话坏话都直说。我会认真考虑大家的问题的。

---

如果这个方向你踩过坑、或者刚好也在折腾类似的玩意—— 评论区说说你现在是怎么处理的，我都会认真回。

[coefu]

《 hands-on llm serving and optimization 》 看完过这本书没？

看完了你再想一下，你这个项目的难点在哪里，你准备怎么解决这些点。

[NorthGod]

感谢提醒，我大概了解了一下这本书，过后会仔细阅读的。

[NorthGod]

@coefu 大概理解了，我参考的更多是 vllm 、sglang 、llamacpp 等源码，还有公开的博客、论文等（虽然绝大部分是 AI 帮我实现的）。书中的内容大多也都有讲到，这样看倒是没什么区别了。而且我们项目最主要的异构多机书中并没有展示，你知道有这方面现成的资料或者文献吗

[coefu]

@NorthGod 你先看明白，单机的多卡推理先，然后才是多机多卡。然后搞明白，推理引擎最重要的是什么。

1 ，首先，你不可能再造一个 类 llama.cpp 的框架轮子了。为什么，每个 LLM 的架构都在演化，每次都要重新根据不同框架写架构算子，这一块，一个人不可能搞得定。上对 LLM 框架理论，下对 cuda/musa/rocm/vulkan... 。

2 ，单机多卡的通信，多几多卡的通信。在 pipeline / tensor parallelism / expert parallelism ，通信上的难度是不一样的。

3 ，以上的问题无法收敛，这也是为什么 llama.cpp 现在 多几多卡 也只有 rpc server 。

[NorthGod]

@coefu 我之前有考虑过 fork vllm 、sglang 等现有的引擎，但是没有任何一个引擎能够支持我“干净的底片工人”这个角色。它做不到喂中间层向量，再吐中间层向量，也做不到内网异构容错。没办法，我只能用 AI 自己写引擎和编排层。不过起码结果是好的，优化到现在已经和主流推理引擎速度相差不大了，再往下就是核工程我确实搞不了也没必要搞。

[xziar]

我没看懂，初始需求是“单张显存放不下”，结果测了“单卡 8B/30B 模型”和“容错热切换”？
这也没解决问题啊……怕不是 vibe coding 被模型忽悠了，代码 AI 写，测试 AI 做，文档 AI 总结，帖子 AI 发……

[coefu]

@NorthGod 看你这个回复，估摸着还没摸到门槛。你搞清楚了 microgpt 的每一个过程了吗？能从 0 开始训练一个 LLM 吗？你搞不清楚这些，怎么搞推理？推理就是训练的 once 。况且当前的 attention 的演化，导致 kvcache 分了不同的路线，这些你都不搞透彻，怎么把整个 LLM 切成多份？不管是横切，还是竖切。

最最主要的是，当前的 attention 加入 rnn 这种循环网络的动态机制之后，类似于 mamba ，混合 attention 连 llama.cpp 当前都没有完全搞定，就不要说 切分之后通信了。

你有想法是好的，但是不能太多的想当然了。

[coefu]

再多说几句：

1 ，你的问题，如果是 vllm 支持的 gpu ，那么 kuberay+vllm 早就能搞定 多机多卡分布式推理。如果是 vllm 不支持的 gpu ，llama.cpp 的 rpc server 支持多机多卡的 pipeline 模式即 layer split 的推理。tensor parallelism 即 llama.cpp 的 row split 目前还不能 多机多卡。

2 ，实际的，你的框架当前能单机多卡跑 Gemma4 系列，qwen3.5 系列 了吗，这是两种不同 attention 的模型，如果能跑通，benchmark 对比 llama.cpp 如何？如果跑不通，连走都还不行，就不要谈跑了。

3 ，cc 能让你搞一点 web 前后端，app 之类的，就不要以为能搞定这个 推理方向上最难的问题。

4 ，上半年号称要搞定单卡推理超出 gmem 参数容量的 LLM 的那哥们儿的项目，为什么熄火了？

[coefu]

最后，我依然对这种 有雄心壮志并且肯动手的人 此致敬礼！

[fcten]

依靠普通家用内网 10G/2.5G 的带宽是很难获得可用的推理性能的。如果能升级到 100G 以上，可能勉强还能用，不过这价格就不便宜了。

[NorthGod]

@fcten 切分方式不同，不需要大带宽的

[NorthGod]

@coefu
谢谢，这是我最近收到的最有含金量的质疑。你几个工具判断都是对的——kuberay+vLLM 面向同构数据中心、llama.cpp rpc-server 的 pipeline 层切、TP row-split 还上不了多机。我也承认我自己并非 AI 模型训练师，甚至只是简单了解的 AI 的原理，学的东西也甚为浅薄。以下是回答：

## 1. 关于"推理是训练的一次 forward"

这点我不同意。能从零训模型和能把推理做成生产服务是两条工程线——KV 分页、continuous batching 、调度、量化、分布式编排、容错，这些在训练里不存在。vLLM / SGLang / llama.cpp 也不是"会训模型的人"立项的。当然，不理解模型内部照样做不好推理。

## 2. 关于 KV cache 和 attention 变体

我们现在只吃 **GQA （ Qwen3 系）+ 稠密 + MoE**。MLA 明确推迟、Mamba / 混合 SSM 完全没做。混合注意力连 llama.cpp 都没完全搞定，这我清楚，所以它压根不在我当前 scope 里。

**2026 年的落地需求量还是集中在 transformer / MoE**（ Qwen3-30B 、V4-Flash 这一档），我先把这块吃透。如果市场真转向混合架构，这确实是我要暴露的风险。

## 3. 关于"这些已经被解决了"—— 最关键的一点

跨机层切分本身**不是我的创新**，llama.cpp rpc 早就能做，这是入场门槛不是护城河。我的赌注不在"能不能切模型"，而在别处：

- vLLM / kuberay 假设的是**同构、稳定、常开机**的数据中心卡，TP 要 NCCL 、要卡型一致；
- llama.cpp rpc 能层切，但**没有容错、没有调度、没有生产服务层**——一个节点掉了整条流水线就断。

我押的是**内网一堆随时会掉的杂牌消费卡（网吧场景）上，节点掉了服务不断**——层粒度冗余 + 故障转移 + 预测调度 + 计费 / SaaS 。这是 vLLM （要可靠同构）和 llama.cpp rpc （无容错无服务层）都不碰的问题。

## 4. 关于"跑通了吗、对比 llama.cpp 如何"

目前只支持 Qwen3 （稠密 + MoE ），真机 5090 有数（ 8B / 14B int8 / 30B-A3B MoE 单卡、跨机 PP=2 ）；**没做多架构、没发过 llama.cpp 头对头 benchmark**。所以我承认现在"能走"，还没到能拿数据跟 llama.cpp 拍桌子的程度。

补充：我们是**多机单卡 / 节点**模型，不做机内 TP ，跟你说的"单机多卡"是不同架构。head-to-head 先欠着，会补。

## 5. 关于用 AI 写代码

判产物别判工具——真机数、真代码摆在这。另外算子我是**刻意拎现成的**（ flash-attn / FlashInfer / vLLM 的 fused_moe ），自己写的是编排、调度、容错、byte-exact 的分布式协议这层。把已经很好的 attention / MoE kernel 重写一遍是浪费，这是工程判断不是遮掩。您似乎并没有分清楚算子和层片工人的边界，我只是自己写编排层和引擎，底层还是基于 CUDA 等架构，而且绝大部分代码都有现成的推理引擎参考——这方面 AI 很强势。

## 6. 关于那个熄火的单卡超显存项目

技术路子不一样——那类是单卡逐层换入换出（ AirLLM 式，慢，是演示不是生产）；我是多机层切分，权重常驻各节点合并显存，不落盘。

但你真正想说的"这类雄心项目会黄"，我接受这是最实在的警告——**技术能不能跑我有把握，真实需求和规模化可靠性能不能兑现，这是我诚实的未知数。**

---

再谢一次，这种质疑比夸有用。

[NorthGod]

@xziar 已经成功在 5090/5070/4060Laptop/V100 等显卡上聚合推理过了，关于跨机层您可以去 Gitee 看一下详细数据
https://gitee.com/NorthGod_BFDG/LoomNode

[NorthGod]

@xziar 目前因为我并没有对等算力的显卡，5090 配我现有的任何一张卡 4060Laptop/V100 （ 5070 是借同学的，已经还回去了）都是崴脚的，测试速度并不可信，所以目前只能说能够完成推理。生产路径多机聚合和单机是差不多的，几乎同一套代码，所以单机速度对比 vLLM 大概可以展示出目前的优化程度。等后面有机会买好显卡了会真正测试的。

[fcten]

多机 PP 的话首 token 延迟会爆炸，估计上下文稍微长点没个 5 分钟吐不出来字

搞多卡至少也得跑起来 ds v4 flash 这种模型吧，跑个 qwen3.6 27b 这种稍微量化一下就能在消费级显卡上跑起来的模型没啥意思。

[coefu]

1 ，我押的是**内网一堆随时会掉的杂牌消费卡（网吧场景）上，节点掉了服务不断**——层粒度冗余 + 故障转移 + 预测调度 + 计费 / SaaS 。这是 vLLM （要可靠同构）和 llama.cpp rpc （无容错无服务层）都不碰的问题。

这才是最难的。

2 ，诚如 fcten 所言，我之前也忽略了事情的意义。 既然是多机多卡分布式推理，那么起码也得是搞个 300B 以上的模型才有意义。也就是说在 1 里所描述的，很难像 llama.cpp /vllm/sglang 那样通用。你只能在几种特色模型做 定制。支持的模型多寡，和功能是否能通，性能优劣。只能做平衡取舍。你不可能做到支持所有的模型，又还能性能卓绝。

3 ，在功能上来说，推理就是训练的 once ，这不只 llm ，任何机器学习的模型就是这样。你说的那是 推理支持并发的性能问题。和 web 领域一样，是只要 10 个并发的 blog 和 10w 并发的门户网站的技术区分。

4 ，如果 1 的问题你不是 vibe coding ，我可能还有兴趣凑合一波，但是哥们儿看不了也不想细看 vibe coding 的这种 infra 代码。

@NorthGod

[xziar]

@NorthGod 你换个思路，拿 4060lp/v100 中任何一个配 5090 都不会“崴脚”啊，然而并没有看到性能数据。
多机运行是会有开销的，尤其是 tcp 协议栈就有一个延迟，所以 llama-rpc 的性能也很勉强，模型越小（越快）影响越大。
你就算只拿到一个不好看的数据，也该分析一下到底是硬件配置原因，还是存在实际不可避免的开销——这个开销决定了你这个特性实际的可用程度。

而且很多细节都根本看不到，比如 weights 存哪的，网关中心化分发还是每个节点都硬盘留一份？多卡 PP 要做容错，那一个节点掉了新节点怎么恢复 kvcache ？你还要做层冗余，那冗余节点间怎么保证版本同步不是也要考虑？

主要你这堆 markdown 都 AI 写的，甚至帖子正文和回复都要靠 AI ，就很让人怀疑你是真的亲手测过了，还是甩手让 AI 测，AI 说测通了。AI 在 md 里写套架构是手到擒来的，实际代码有没有写好是另一回事。

[Soulxe2v]

项目文档是 AI 写的，你知道你的文档问题有多好笑吗，我都怀疑你让 ai 跑出来结果之后，自己都没看过就上传了吧。
文档是到处都有不明所以的 markdown 引用块的，cpython 的 GIL 是不懂的，python 嵌到 go 语言的主程序里是会让项目更快的，修分布式的 bug 是可以在单机上模拟出多个进程来做多机替代的。

回复也是 AI 写的，连 markdown 格式都懒得删，装都不装一下。

我的建议是跟之前那个没事喜欢锤子找钉子憋了好多口气准备做 coding agent 的人坐一桌，vibe coding 弄多了给自己弄出幻觉了。

[NorthGod]

@fcten 感谢关注。
你把两件独立的事捆一起了：多机 PP 的延迟，和长上下文 prefill 的延迟。

多机 PP 本身几乎不增加首 token 延迟。PP 只在 stage 边界跨机传一次 hidden state ，我们的多机永远在同一个内网 LAN 内跑，RTT ~0.5ms ，PP=2 多传 0.5ms 、PP=8 也就 ~4ms——相对 prefill 计算完全可忽略。你说的"首 token 爆炸"确实存在，但那是公网深 PP：公网 RTT 25-50ms ，逐 token 累积才会爆。这正是我们放弃公网拼算力、转内网聚合的核心原因（ exo 也是独立得出同样结论后放弃公网的）。WAN 上我们只传"请求进、token 出"，逐 token 的流水线永远不碰 WAN 。

长上下文 prefill 慢是真的，但这是全行业 O(n²) 共性，跟单机多机无关。 单卡 vLLM 跑 128K 一样慢。我们实测单卡 30B-int4 128K prefill ~76-113s （ 5090 + Docker + vLLm ）。但"5 分钟"是把极端长上下文当常态了——普通几百到几千 token 的对话 prefill 是亚秒到秒级；而多机 PP 把层拆到多台，prefill 反而能并行摊（是我目前努力的方向）, 不会更慢。

持续吐字（ decode ）那头就更不是问题了：内网 PP 每 token 走一圈流水线是 ms 级，对流式无感。真机 5090+V100 PP=2 跑 30B-int4 ，decode 10~54 tok/s （看并发），字是正常往外蹦的。

"单卡量化能装下" 和 "能提供生产级服务" 是两回事。30B-int8 塞进单卡是能塞，但实测单卡 N=32/64 实际只跑得动 ~21 并发，上下文拉到 2048 就只剩 2 路并发——KV cache 直接饿死。多机不是为了"装得下更大模型"，是为了长上下文（ KV 分摊到多机）+ 高并发（更多显存喂 KV pool ）+ 容错（杀掉一个节点服务不断）。 这三样单卡都给不了，跟模型多大没关系。

至于 DS V4 那种 1.6T 的——它是招牌，不是我想做的主要目标。市场的真实量在中等模型这一档（ 2026 生产部署 ~80% 高频任务中小模型就够，成本差 10-30 倍）。当然，这个体量的后期会持续优化。

[NorthGod]

@coefu 感谢回复。

1 、它固然有它的难度，可是 vllm 和 llama 不做的原因是他们没有动力、没有理由做这些事情。他们面向的是同构服务器集群，并非我的项目所面向的场景。容错、服务并非不可实现，况且这已经在我的机器上跑通。

2 、您说的对。我不可能支持所有的模型、也不可能做到 vllm 的性能。但是，好用是建立在能用的基础之上的，而我做的是能够让很多本来跑不了 vllm ，跑不了大模型的卡能跑，然后才是优化的问题。

3 、其实原理都同第二点。我目前做的是从零到一的工作，目前的重心并不在您说的高并发、高速度等的优化上，我目前有且只有一个目标就是跑通中等体量的模型。至于，您说的推理就是训练的 once ，并非不对而是不准确。推理和训练的侧重点并不相同。

4 、诚然，您可以说 AI 写的代码烂、非常善于编造。我设置的门限是和 vllm 之类的引擎做的直接对比，而且我们自己会写的引擎吐出的文字并没有任何奇怪的说话方式或者行为等等。但是您不能把个人对于 AI 的看法加到 AI 能不能做成某件事的层面，它没有全局观，没有思考，没有架构方向。。。——当然和顶尖工程师差得远，它甚至只是一团数学概率预测模型，输出的东西对不对看的是你的提示词和模型训练的语料。

我目前没有余力自己完成所有的代码，推理引擎也是边学边实现的步骤，离您说的那个追求“完美”的项目差得很远，它只是我的目标。而我现在还离它很远，我只是想在我的能力、条件允许之内多学一点多做一点。这点您可以很清晰的看到——我一直表明的是，我们做的是一个从零到一的步骤，并非是在能用之上的优化（起码现在不是）。BUG 是可以改的，性能是可以修的，语法和风格以及代码的干净程度也是可以完善修复的；我跑出来的结果和已经完成的进度同样也是真实存在的。

如果有幸，还是希望到时候开源的时候您能指点一下代码问题。也希望，我这段话能改变一点您对 AI 的看法。如果您把它当做“项目的完成者”，那它只配一半。项目的架构是我设计的；冗余、服务、引擎、编排层是我想的；您能在项目中看到的所有的创新，任何一个 AI 都做不了；甚至如果我不去用 AI ，它自己不可能有任何“写这个项目”的想法（显而易见不是吗）。我贯穿始终的理念都是，AI 只是完成代码的好工具，并非赖以生存的必需品，有了它你可以在几天之内完成之前几周甚至几个月的工作，这绝对是极大的进步。

最后再次谢谢您的认真回复。