多机异构显卡组合推理

《 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 弄多了给自己弄出幻觉了。