NorthGod

@Soulxe2v 谢谢你看了仓库。

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

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

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

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

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

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

@coefu 感谢回复。

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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