多机异构显卡组合推理

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

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

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

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

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

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

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

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

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

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

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

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

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

再多说几句：

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 的那哥们儿的项目，为什么熄火了？

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

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

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

@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 式，慢，是演示不是生产）；我是多机层切分，权重常驻各节点合并显存，不落盘。

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

---

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

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

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

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

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

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

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

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

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

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

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

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

@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 倍）。当然，这个体量的后期会持续优化。

@coefu 感谢回复。

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

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

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

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

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

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

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

@xziar 我不公布性能数据的原因就是，就算是按照极其离谱的比例（比如 10:1 ）分割模型，4060lp 仍然占用率 100%，5090 堪堪 10%。同样的模型我能做到和 vllm 一个速度，而到了 PP 这种数据显然是硬件的原因。

受限于目前没钱的条件，我无法得出准确的性能答复。不过，我的调优思路是埋点看耗时，只能说尽量模拟真实情况吧。

至于您说的网络栈开销、项目具体细节、甚至是有没有亲自测过，我无法回答这个自证陷阱。我只能说的是，本人刚进行完期末考试，继续做完专利和软著的申报，就可以发布源代码了。到时候欢迎到仓库指点任何问题，我对于 AI 写的这一坨代码是有心理预期的——它现在只是能跑而已。

@Soulxe2v 谢谢你看了仓库。

md 文档是由 AI 写的不错，但是这也并不影响你理解项目对吧。

至于 python 串行锁、go 嵌套这两个问题我是清楚的，只是当时为了测试到底能慢多少所以才这样子做的。至于分布式的 BUG ，我认为单机几乎可以完全复现，多机联调费时费力，况且我还没有好用的成套设备。但是这并不代表我没有进行过真的多机测试，我完全不理解你的疑问从何而来。

首先，我承认我只是一个学生，没有导师也没有任何人教我，AI 和网页是我获取知识的唯一途径，我也是边做边学。我的项目有且肯定有很多低级的、看了让人招笑的 BUG ，这些问题如果可以还请你在我开源后一一指出，我都会进行修改。但是，我只欢迎理性、关于技术向的讨论，我也相信这是 V2EX 论坛的意义。如果你只是想纯粹的情感输出，我是不会进行回复的。

@NorthGod 有决心有信心就好好搞，希望你能成功。我目前重心不在这块，等我有余力了再给你助力。加油，fighting ！！

@NorthGod

1 、我先说我之前提出的问题。
1 ）“单机可以复现分布式的 bug”，这本身就很荒谬。你可以说你刚开始写的时候不需要一定要在多机跑，但是你都要明确修一个属于是分布式的 bug 了还不需要多机跑，那真的有点说不过去。你修 bug 不需要尽量原环境下复现，然后打日志，再根据日志修的吗？
要么就是你跑的模型根本不需要多机，单机就能完美甚至多开几个来运行，那你分布式的目的是什么？只是为了热备就没有必要做成这样，大可以所有节点都跑同一个模型，节点看情况上下线，然后写一个请求的路由，哪个节点在线，就跑在哪个上面就得了。
要么就是根本就没跑模型，只是 AI 让你感觉自己跑了，那更离谱了，连实测都不算，根本就是在臆想。
还是说你修 bug 就是跟 AI 说出了什么问题，让 AI 猜多几遍？
2 ）学生身份不是万能金牌，没人教你那就老老实实看一楼给你推荐的书，光靠 AI 和网页只会害了你，AI 是能编出来看起来合理但实际上不通的结果，网页也能找到许多错误的内容。就目前我对这个项目和这个帖子的理解，你完全就是跟 cc 说要做我要做一个什么什么项目，然后 AI 给你梳理出框架之后，你也不知道框架对不对，就让 AI 硬跑，出了问题就让 AI 硬修，最终得出了这一个全靠 AI 的项目，但是自己都不知道里面写了些什么。
3 ）你的代码行数注水的简直离谱，文档里的原文“核心代码量 八万余行（控制面 Go + 推理引擎 Python 的生产代码；连测试与桌面客户端计逾 14 万行）”。我原本也对代码行数没什么概念，但是当我拉下来 llamacpp 、vllm 两个同类型流行项目用"git ls-files | xargs wc -l"统计了一下总行数后，我就知道你这代码量简直扯的离谱，llamacpp 项目总行数 191615 ，vllm 项目总行数 117300 ，你的意思是你一个人凭借 AI 用两个月时间就做出来了能对标两三千人社区做了三年的成果的项目吗。

2 、我提出对 #19 的质疑：
1 ）首先你不是只有 4 张卡吗，为什么能得出 PP=8 的时候 RTT≈4ms ？又是 AI 帮你编的吧。其次多机 PP 慢的原因不只是因为 RTT ，模型在单张卡上的 prefill 过程是不用时间吗？下一张卡的 prefill 过程不用时间吗？更别说你还是混用不同算力的卡。PP 只有在最后一张卡 prefill 完了才会出首个 token ，请问你为什么会得出卡越多但是却几乎不增加首 token 延迟？你自己难道不清楚 PP 是什么东西吗？
2 ）我不用 vllm ，但就我自己用 llamacpp 实测来看，qwen3 30bA3b 这个模型上下文只能到 32768 ，开不了 131072 ，除非用其他技术手段硬开，当然你也可以说你用的 30b 不是这个，只是我也不知道你还能用哪个 30b 了。
3 ）“30B-int8 塞进单卡是能塞“，我就想问了，你知道 qwen3 30bA3b int8 的模型有多大吗，31.98G 的大小怎么塞进 5090 ？还跑上并发了？这个时候就不考虑 prefill 时间会爆炸了？当然你也可以说你用的 30b 不是这个，只是我也不知道你还能用哪个 30b 了。
4 ） DeepSeek V4 有两种，一个是 flash 一个是 pro ，flash 是 284bA13b ，pro 是 1.6tA49b ，就算 pro 部署不了，你也应该把目标放在尽可能部署出一个 flash 版上，否则做 PP 的意义何在呢。
5 ）“（ 2026 生产部署 ~80% 高频任务中小模型就够，成本差 10-30 倍）”。谁给你的数据？中小模型是有多小？是你文档里写的 Qwen3-8B 还是 Qwen3-0.6B ？你真用过这两个模型吗，一个虽然智商不足还算勉强能用，另一个根本就是幻觉严重不微调完全没法用，谁会在生产环境部署这些模型？如果没有私密性需求，用这种模型真不如直接调官方 api 或者中转站。

3 、我提出对 #20 的质疑：
”而且我们自己会写的引擎吐出的文字并没有任何奇怪的说话方式或者行为等等“。希望你自己再次看完这句话没有笑出声来，这还是中文吗？ AI 生成就算了，你就不能多跑几次选个通顺点的吗？

4 、我提出对 #21 的质疑：
1 ）文档里不是说”按算力分配工作量“吗，4060laptop 和 5090 之间各种标称性能都差了接近十倍，laptop 版还会受各厂商的温度墙、功耗墙限制，差距只会拉的更大，出现 1:10 的模型层分割比例很离谱吗？你不会连这两张卡的参数都不知道吧。
2 ）什么叫作”受限于目前没钱的条件，无法得出准确的性能答复“？ 5070 还回去了，那你不是还有 4060lp 、v100 、5090 吗，我就当你 v100 也不是你自己的，那你 4060lp 和 5090 两张卡也能跑啊。调优不用实际跑的话术都来了，你不实际跑你怎么知道瓶颈在哪，是卡与卡之间算力差太多还是卡与卡之间显存速度差太多，或者是其他的各方面的因素，你总得把实验做了才能得出结果吧。
3 ）人家让你回答网络栈开销怎么解决、项目细节是什么、是不是真测了，又说是自证陷阱。那你自己也得有点可信度啊，AI 发贴、AI 回复，我都怀疑项目本身是不是也全是 AI 帮你建、AI 帮你写、AI 装模做样帮你测试、最后 AI 帮你提交。

这次给大家回复倒是学会删 markdown 格式了，但是莫名其妙的比喻加上没必要的解释括号，你如果还是只会用 ai 写回复，你的项目可信度只会继续大大降低。