本文作者：实践哥MinLi（@MinLiBuilds）。版权归作者所有，未经授权禁止转载。
部署本地模型，是选 NVIDIA DGX Spark，还是选两张魔改 48G 的 RTX 4090？
这两台机器是极度的偏科生。一台内存大得离谱但带宽窄，一台带宽宽得离谱但显存要靠魔改。
选择模型的第一要素是，尽量压榨这两台机器的显存以及算力。因此，选的这两个都装不进一张卡。Qwen3.8-27B 全精度 55.56 GB，Ling-3.0-flash 已经压到 INT4 了，还是有 77.01 GB——哪怕是魔改到 48G 的 4090，单张也塞不下，何况装完权重还得给上下文留地方。这种体积的模型，要么靠多卡拼显存，要么靠统一内存的整机。而这两条路，我手上刚好各有一台。
第二个理由是它们本身也是两个极端：一个是 Dense 的 Qwen3.8-27B，每生成一个 token 都要把 27.78B 参数完整过一遍；一个是极端稀疏 MoE 的 Ling-3.0-flash-int4，总参数 127B，但每次只激活约 5B。
两台偏科的机器，两个偏科的模型，四个组合，我全测了一遍。
读完这篇文章，你会拿到测试的真实数据、显存配置怎么看，以及怎么买。
术语第一次出现的地方我都会解释，没有基础顺着读也没卡点。
先看结论
导读
- 基础概念，看第 1 章，看完你就知道 dense、moe、带宽等什么意思
- 想知道"能同时服务多少人"由什么决定：看第 3 章，那是全文最有用的一章。
- 想看四个组合的完整数据，和真实环境的 benchmark：第 2～5 章。
- 我是土豪，我有两台机器、想让它们分工：看 5.4 节。
- 只想知道该买什么：硬件看第 6 章。
1. 四个偏科生
1.1 Dense 和 MoE 到底差在哪
Dense 就是稠密模型。 27B 参数，每生成一个 token，都要经过这 27B 参数的完整计算。总参数 27B，激活也是 27B。
MoE 是专家混合模型。 它可能总共有几百 B 甚至几 T 参数，但内部分成很多个"专家"，每次只叫醒其中几个干活。Ling 内部有 512 个专家，每个 token 只挑 8 个出来，其余全部闲置。
MoE 的好处是可以用巨大的总参数量去冲能力上限，代价是这些专家平时也得全部待在显存里。
两个模型体积接近，但这只是因为一个用 16 位存、一个用 4 位存。论参数量，Ling 是 Qwen 的 4.6 倍；但每次干活，Qwen激活是 Ling 的 5.4 倍。
1.2 两台机器
Spark 最大的特点是大，121 GiB 统一内存，装什么都不费劲。双 4090 是另一条路线：官方单卡只有 24G，华强北把它改成 48G，带宽和算力都足，但我这台没有 NVLink，跨卡还得走 PCIe。
1.3 算力和带宽：为什么只看后者
买显卡时参数表上有两个数最容易混：
- 算力（TFLOPS）：每秒能做多少次运算，衡量算得多快。
- 显存带宽（GB/s）：每秒能把多少数据从显存搬到计算单元，衡量搬砖有多快。
大模型生成文字的时候，衡量的是显存带宽，非常反直觉。但如果是训练，对于算力要求会高很多。
每生成一个 token，GPU 要把参与计算的权重从显存完整读一遍，读完算一下，吐一个字出来。矩阵乘法本身对现代 GPU 轻而易举，几毫秒就算完了；但把几十 GB 的权重搬过来要花掉几十毫秒。时间几乎全花在搬运上，算力再高也帮不上忙。
生成速度上限 ≈ 显存带宽 ÷ 每个 token 要读取的权重体积
所以两台机器的带宽差距，直接决定了速度差距：
模型装不进一张卡时要切成两半分别放，这叫张量并行。好处是两张卡同时读，等效带宽翻倍；坏处是每算完一层都要跨卡对一次账，而我这台没有 NVLink，只能走 PCIe。
双 4090 对 Spark，带宽差 7.4 倍。
再看模型这一侧：Qwen 每个 token 要读 27.8 GB，Ling 只读约 1.3 GB。所以在同样的带宽下，Ling 应该比 Qwen 快一个数量级。
以上两个数字，带宽和 Ling 快很多，都会在第二章实测呈现。
1.4 草稿和投机
大家都知道模型在推理的时候，一次计算一个 token，下一个 token 会根据前面的那些 token 再去推理。
一个一个的蹦出来，太慢了，能不能多蹦一些？
这就涉及到投机解码，也叫打草稿。在主模型动手前，用廉价的方法白嫖下一个 token，甚至接下来三个 token。
如果全部命中，速度会提升 1 倍或者 3 倍。
具体是这么发生的：主模型照常做一次前向计算，这一次本来只能产出一个 token，但它顺便把草稿猜得对不对也一起验证了。于是：
- 猜对了：这一步吐出两个 token，自己算的那个，加上被确认的那个
- 猜错了：吐出一个，猜的那个丢掉
关键在于，验证一个猜测和生成一个 token，读的是同一份权重，花的是同一次搬运。所以猜对就是白赚，猜错也只是浪费了一点本来就闲着的算力，不亏。
不过"同一份权重"这句只对 Dense 完全成立。MoE要拆开看：注意力层和共享专家确实是所有位置共用的一份，验几个位置都只读一遍；但路由专家是每个 token自己从 512 个里挑 8 个，两个位置挑中的几乎不重叠，要读的专家就从 8 份变成约 16 份。2.3节会详细计算，算完之后 Ling 的成绩反而更好看。
而且这个过程是无损的：输出和不开投机解码完全一致，它不是拿质量换速度。
MTP（Multi-Token Prediction，多 token 预测）是实现这个猜测的一种方式。传统做法要额外跑一个小模型当草稿，MTP 则是在模型内部多训练一个头，专门预测下下一个 token：猜测直接从模型自己身上出，成本更低。本文两个模型都带 MTP：Ling-3.0-Flash 的实现叫 bailing_hybrid_v3_mtp，Qwen3.8 的叫 Qwen3_5MTP，都配置成每步猜 1 个。
猜中率决定收益。每步平均吐出的 token 数叫接受长度，服务端日志可以直接读到：
每步猜 1 个的话，接受长度的理论最大值是 2.00。接受的意思是推理出来的 token 都接受，第一个 token 是无条件接受，第二个 token 有概率拒绝。 所以接受长度会介于 1-2 之间。两个模型都落在 1.8–1.9，说明这个技术在真实的编程提示词上相当有效：它直接把生成速度抬高了近一倍。
最后一点很重要：猜中率取决于下一个字好不好猜。代码这种高度模式化的文本容易猜中，随机字符则几乎猜不中。同一个模型、同一台机器，只换测试数据，速度能差出一倍以上：所以本文所有 benchmark 都固定用同一条真实的编程提示词。不过第 4 章是一次真实会话，也建议你看任何一份 benchmark 时都先问一句它用的什么输入。
1.4.1 一次猜几个，是可以调的
猜几个是个参数。前面用的是最保守的 1，调大就是一次往后连猜好几个，主模型一次前向把它们全部验证掉。猜 k 个，接受长度的上限就是 k+1，也就是前面说的提升 1 倍或者 3 倍。
但收益掉得很快，因为这是一串连乘：第二个 token 算不算数，前提得是第一个先猜对了。假设每个位置猜中的概率都是 p，一步平均能吐出的 token 数就是 1 + p + p² + … + pᵏ。把实测的接受长度反推成猜中率代进去（Ling 0.90，Qwen 0.80）：
从猜 1 个加到猜 3 个，草稿的工作量翻了三倍，Ling 的产出只涨 1.81 倍，Qwen 更少，1.64 倍。而且这还是乐观估计——真实情况下越往后越难猜，p 会一路衰减，不会像这里假设的一直稳在 0.90。
单流的时候，对 Dense 这几乎是白送的，反正读的是同一份权重，算力本来就闲着；对稀疏 MoE 要打个折，k+1 个位置意味着要读近 k+1 份路由专家（猜 3 个就是近 4份）。人一多，批量已经把算力占上了，多猜的那部分就变成真实开销。所以这个参数没有普适最优值，取决于你是一个人用还是拿来做服务。
顺便提一下这个领域的另外两条线。一条是猜得更宽：每个位置都备好几个候选，拼成一棵树，主模型一次把整棵树验证掉，走通哪条算哪条，Medusa 和 EAGLE 走的就是这条路。另一条是草稿从哪来：可以额外挂个小模型，跟主模型共用词表，可以完全不用模型、直接在上下文里找重复片段来抄（对代码几乎零成本），也可以像本文这两个模型一样用 MTP，把草稿头训进模型自己身上。
本文全程每步只猜 1 个。这是后面想补k 调大之后实际能拿到多少，对 Ling 尤其值得。2.3 节会看到它只兑现了硬件理论上限的18%，带宽和算力都还空着。要注意的是对稀疏MoE，多猜的代价不只是算力，路由专家的访存也要成比例地涨。
1.5 本文想解答的三个问题
- 同一个模型，换一台机器，能差多少？
- 同一台机器，Dense 换成只激活 4% 的 MoE，又能差多少？
- 如果今天真让你掏钱，你应该怎么买？
本文会进入四轮测试：
2. 第一轮和第二轮：四个组合的单会话速度
我给所有测试统一设了一条体验线：单用户生成速度 ≥ 20 tok/s
这是我认为交互式 AI 助手比较舒服的下限。
这条线直接决定了我测到哪为止。 越过它之后，服务器总吞吐还能继续涨，但那是拿用户体验换报表好看。所以我没把并发压到很高：不是压不上去，是再往上已经不是在测一个可用的系统了。
2.1 DGX Spark 测试
Ling 背后是一个 127B 级别的大模型，但真正生成时只激活很小一部分，所以它对内存带宽的压力，和一个 127B 的 Dense 模型完全不是一回事。
Qwen3.8-27B 在 Spark 上只有 6.7 tok/s，基本没法用。而且这一轮它是开着投机解码跑的：该给的加速都给了，还是这个数。原因大概率是这个模型发布没多久，Spark 上的适配还没跟上：同一台机器上 Qwen3.6 可以轻松跑到 30+，需要等待社区优化。
所以 Test ① 到这里就结束了。
2.1.1 但换个量化格式，这台机器完全是另一副样子
上面那两个数字都是各自的默认部署。后来我把同一台 Spark 上能跑的几种量化格式都用同一个 bench.py、同一条提示词测了一遍，结果差得离谱：
Spark 上跑不动全精度的 dense 模型，但是非常适合跑 MoE。 如果是Dense 全精度，要提速只能靠推理引擎和投机草稿这条路子。 或者做量化缩小模型提速。
但是 Moe 的模型Ling，在 MTP 下达到了惊人的39.2 和 54.9。同样是 Ling，INT4 配 vLLM 是 39，MXFP4 配 SGLang 是 54.9，差 41%，说明推理引擎和配套的量化都很重要。
看到这里，对Spark 能否跑动大模型有结论了。它跑不动的是全精度 dense 模型，要么换 moe，要么缩小精度。
2.2 RTX 4090 48G * 2
直接看测试结果：
两者速度都比 Spark 快很多。不过相差稀疏，145 对 50.4，差 2.9 倍。
两边的数字我都做了交叉验证。Ling 用两套完全不同的客户端各测一次，得到 146.0 和 145.0，误差不到 1%；换成并发测试脚本再测一次是 144.9，仍然对得上。Qwen 也是同一套脚本量出来的，口径一致。
同样两张卡，127B 的 Ling 把 27B 的 Qwen 甩开了近 3 倍。原因在参数量和激活量两个数字。参数量就是模型有多大，激活量是计算 token 时要多少带宽算力。对 Dense，两个数字一致。但对 MoE 来说，这里 Ling 只激活5B。
2.3 哪个硬件榨干了自己？
我把两个模型各自和物理极限比了一下。理论上限根据 1.3 节那条公式：每步要读的权重体积除以显存带宽，得到一个 token 的最短耗时，再取倒数。
两个模型都开着投机解码，所以理论上限要这么算：每步读一遍权重的时间取倒数，再乘上每步实际吐出的 token 数，也就是接受长度。
Qwen 全精度 55.56 GB，切成两半后每卡读 27.8 GB：
27.8 GB ÷ 1008 GB/s = 27.6 毫秒/步 1.80 个 token ÷ 27.6 毫秒 → 上限约 65 tok/s
Ling 每个 token 只激活约 5B 参数，且以 INT4 存放，单个 token 每卡只要读约 2.5GB（1.3 GB*2）。但它开着MTP，一步要验 2 个位置：共享的那部分一步只读一遍，路由专家却要读近两份。Ling 那 2.5GB里绝大部分是专家，所以一步实际要读约 2.5 GB：
约 2.5 GB ÷ 1008 GB/s ≈ 2.5 毫秒/步 1.90 个 token ÷ 2.5 毫秒 → 上限约 800 tok/s
放在一起：
要说明两句：Qwen 那行的 27.8 GB 是确定的，全部 BF16、全部激活；Ling 那 2.5 GB（1.3GB*2） 是估算，它的注意力层和共享专家并没有量化，仍是 BF16，精确算得逐层拆开。另外两边的理论上限都没有扣除草稿模型自身的开销，所以都偏乐观，Ling 那一栏尤其只能看个量级。
Qwen 拿到了约 77%，考虑到跨卡通信的开销，这个成绩很正常。
Ling 理论上能跑 800，实际只有 145。那 80% 去哪了？跟我两张卡走 PCIe 有关，也跟 MoE 的稀疏方式有关。512 个专家里挑 8 个，要做路由计算、要在显存里东一块西一块地取数。
还有一点对它更有利：专家访存跟 token 数成正比，只在小 batch 下成立。并发一上来，512 个专家很快被撞满饱和，一次搬运摊给一整批人，这笔 MTP的税就摊没了——它只存在于单流跑分这一格，而单流恰好不是我推荐 Ling 的那个场景。这本来就是一种空间换时间的哲学。
2.3.1 顺便介绍两个指标，解码速度和端到端速度
前面一直在区分「解码速度」和「端到端」，看着有点啰嗦。后来在 Spark 上遇到一个例子，说明这个区分是必要的。
那台机器上有个 SGLang 部署，我对它测了一次，同一份数据算出来是这样的：
解码速度（1000/TPOT）= 254 tok/s 端到端（总token÷墙钟）= 50.3 tok/s
差 5 倍。原因是它的首字延迟高达 8.2 秒：请求发出去憋了 8 秒不吭声，然后 512 个 token 在两秒内一次性吐完。算 TPOT 时只统计首字之后的间隔，自然快得离谱；而用户真实等待的是 10 秒。
这不是测量出错，两个数都对，而且「首字延迟 + 解码时间 = 端到端」严丝合缝。它们只是回答了两个不同的问题。
所以看任何一份 benchmark，除了问它用什么输入（1.4 节那条），还得问一句它报的是哪个指标。只报解码速度而不报首字延迟的数字，可以虚高好几倍。 本文所有跨机器的对比都用「聚合吞吐 ÷ 并发」，因为它不受这个扭曲影响。
3. 最有用的一章： 模型吞吐量，由什么决定
这一章是我这轮实验最大的收获，也是超出我认知的地方。本章依然用实验数据来进行压测。所有数字都来自同一条固定的编程提示词：一问一答，五百个 token 就结束。为了反馈理想情况。
3.1 先看结果
双 4090 上，把并发一路往上压：
按 20 tok/s 那条线：Qwen 到 36 个用户为止，Ling 到 72。
有意思的是 Qwen 撞线的方式：32 和 36 两档几乎持平（20.9 和 20.8），它贴着红线走了一段才掉下去，不是陡降。
两边在各自上限处的服务器总吞吐：Qwen 642.8 tok/s，Ling 1553.7 tok/s，首字延迟 392 毫秒。
所以同一台机器：Ling 能服务的人数是 Qwen 的 2.0 倍，总吞吐是 2.42 倍。
3.2 一个趋势：人越多，Ling 的优势越小
把每一档的倍数单独拉出来看：
单用户时 Ling 快 2.88 倍，到并发 20 就掉到 1.8 倍左右，之后基本不动了。
这个形状是有道理的。低激活 MoE 省的是"每个 token 要搬多少权重"，而这份便宜在单流时最值钱；人一多，两个模型都进入批处理状态，一次搬运摊给很多个用户，MoE 的相对优势就被稀释了。
3.3 那条公式
为什么 Ling 能多扛这么多人？答案不在架构里，在显存的分配方式上。
每一个正在对话的用户，都要在显存里占一块地方存他的上下文，这块地方叫 KV 缓存。人越多占得越多，而显存里能划给 KV 的总量是固定的：权重装完之后剩多少，就是多少。所以：
能同时服务的人数 = KV 缓存区容量 ÷ 每条对话的固定占用
这不是经验规律，就是一个除法。
顺带说一句，这个空间是要自己去要的。推理引擎默认给的值往往比显卡实际能腾出来的少一大截，我第一次跑的时候就只拿到了一半多一点，白白少接了三十几个人。部署的时候值得专门确认一下这个参数。
所以当有人问"这台机器能同时服务多少人"，答案不在参数量里，也不在算力里，而在权重装完之后还剩多少显存，以及你有没有真的把它要过来。
买卡的时候看的是算力，用起来决定并发的是剩下的那点显存。
3.4 Spark 那边呢
Spark 在 4 个人的时候每人已经掉到 19.6，刚好落在红线下方。所以它的可用人数是 3–4 个。
但这里我必须说一句实话。 Spark 那组数据是在比较保守的配置下测的，而 KV 空间没配满这件事：同样极可能存在于 Spark 那一侧。Spark 有 121 GiB 统一内存，装完 77 GB 的 Ling 之后余量比 4090 更宽裕，如果把满配 KV 的手法用上去，它能服务的人数可能远不止 3–4 个。
所以后面表格里 Spark 那一行，请理解为当前配置下的实测，而不是这台硬件的上限。
4. 真实任务里，这些倍数还剩多少
前面所有数字都来自同一条固定的编程提示词：一问一答，五百个 token 就结束。真实的编程会话不长这样：几十轮来回，上下文一路往上滚，中间还要读文件、跑命令、返工。
那 benchmark 的倍数在这种场景里能兑现多少？我拿同一个任务，在同一台双 4090 上，让两个模型各做了一遍。
任务是一组网页动画：四版骑自行车的动画、三个风扇、一个展示页，中途还追加了一轮"应该是鹈鹕骑自行车"的返工。两边都是完整的 agent 会话，能读写文件、能执行命令，都开着投机解码。
当然，Ling 是纯文本模型，这里相当于测试它不擅长的项目。
4.1 同样的活，一个 133 分钟，一个 69 分钟
先看第一行。两个模型写出来的代码量几乎一模一样，96,151 对 95,889，差 0.3%。同一个任务、两条完全独立的路径，产出量对得这么齐，后面的时间对比才有意义：不是一个偷懒一个啰嗦，是同样的活，一个干了 133.5 分钟，一个干了 68.7 分钟。
1.94 倍。
而在短提示词 benchmark 上，这两个模型的差距是 145.0 对 50.4，2.88 倍。
如果把工具执行、来回等待也算进去，按整段会话的平均吐字速率算，差距还会再缩到 1.45 倍。真实体感落在这两个数之间。
4.2 少掉的那一半倍数去哪了
把两边的时间拆成两段：读上下文那段叫 prefill，往外吐字那段叫 decode。第 1.3 节说"生成是搬运活"，说的是后者；prefill 反而是实打实的算力活。
按各自实测的速率折算：
两边都能对上实测，说明这个拆法站得住。
于是差距的来源就清楚了：Ling 省下来的 65 分钟里，有 45 分钟省在读上下文上：这一段是算力活，5B 激活对 27.8B 激活，稀疏在这里是真占便宜。而真正的吐字只快了 1.43 倍。
把 benchmark 的数字并排放，看得更直接：
两个模型进了真实会话都会掉速，但 Ling 掉得更狠：Qwen 还剩原来的 42%，Ling 只剩 21%。
原因和 3.2 节是同一个。那一节说的是人越多 Ling 的优势越小，这里是上下文越长 Ling 的优势越小：机制完全一样：稀疏激活省的是权重搬运那一份钱，而处理上下文的那部分开销，跟稀不稀疏没有关系。这次会话最长的一轮输入是 131,233 个 token，到那个量级，权重搬运在总账里已经不是大头，省它省不出多少。
benchmark 用几百 token 的提示词测出来的倍数，是这个模型能拿到的最好成绩。你的会话有多长，它就打多少折。
4.3 缓存为什么重要
这轮实验，两个模型累计吃进 359 万～486 万输入 token。
这不是因为提示词有多长，而是每一轮都要把整段对话从头重读一遍：第二轮重读第一轮，第三轮重读前两轮，一直滚下去。前面那 13 分钟的 prefill，绝大部分花在重复预填已经读过的内容上。
按理说这件事有解，叫input cache：把读过的上下文在显存里留一份，下一轮接着用。但因为本地部署，所以缓存机制都没有。
所以大家就知道为什么存储很贵，cache 很贵，缓存命中很便宜了。
5. 实验总结
写到这里我才意识到，这张表还可以换一个读法。
开头我说这两台机器是极度的偏科生。测完才发现，这两个模型也是：
于是那四个组合，其实就是四种配对方式：
- Spark 配 Qwen：窄带宽撞上大搬运量，两个短板叠在一起，6.7 tok/s，直接废掉。
- Spark 配 Ling：Spark 的容量兜住 Ling 的体积，Ling 的低激活绕开 Spark 的带宽：两个短板互相避开，38.7 到 54.9，能用。
- 4090 配 Qwen：宽带宽喂大搬运量，50.4，正常发挥。
- 4090 配 Ling：两个长板叠在一起，145.0，全场最快：代价是只兑现了硬件理论上限的 18%（2.3 节）。
所以偏科本身不是缺点，它是一种需要配对的属性。真正会出事的只有一种情况：把两个短板放在一起。
5.1 翻译成真实任务
tok/s 是工程师的语言，产品经理只问两句：我等多久？这台机器够我们团队用吗？
按一问一答生成 500 个 token 算，大约是一个完整函数加几个测试用例：
换算成要买几台：如果一个团队 70 个人要同时用，2×4090 + Ling 一台刚好够，换成 Qwen 要 2 台，换成 Spark 要 18–23 台。 而这三种配置里用户感受到的速度是一样的。
需要说明的是，这套推算基于我全程使用的极短提示词，真实的多轮编程会话里第二轮要把第一轮全部重读一遍，这些数字会全面变差：第 4 章那次真实会话就是这个折扣的实测。它是相对关系，不是你生产环境的绝对值。
5.2 一个人用、或者小团队，主要做编程 ： 我会选千问
先把话说在前面：这个选择不是因为 Ling 不够快，恰恰相反。
速度正是 Ling 优势最大的场景：145 对 50.4，快 2.88 倍。
那为什么我还是会选千问？因为选它就是主动拿速度换另外三样东西：
质量的确定性。 Dense 每次把 27.78B 参数全部过一遍，全精度 BF16，没有专家路由这一层。同一个问题问两次，性能形态是可预测的。而 Ling 是 4 位量化的 MoE，路由结果和量化误差都是变量。写代码这件事，一次错误的输出浪费的时间，远超过几十秒的等待。
生态成熟度。Dense 这条路走的人多，工具链、量化方案、各家推理框架的适配都最齐。
它还有明显的余量没用。 这一轮我只给 Qwen 补上了投机解码，量化还没做。若压到 INT4，权重从 55.56 GB 掉到约 14 GB，一张卡就装得下，读取量少四分之三：按 1.3 节那条公式，速度还有很大空间。
换算成实际体验：500 token 的一次回答，Ling 3.4 秒，Qwen 9.9 秒。都在"问完等一下就出来"的范围内，没有跨过体验的质变门槛。如果这 6 秒能换来更稳的输出和更省心的部署，我认为划算。
一句话：本地小钢炮、人不多、主要写代码，用千问：但你要清楚自己是在花速度买确定性。
5.3 做面向多人的服务，比如一个类豆包的前端应用 ： 我会选 Ling-3.0-flash
人一多，游戏规则就变了。
这时候 3.3 节那条公式开始主导一切：你的成本不是某个工程师多等三秒，而是同一台服务器能养活多少个账号。
同一台双 4090，Qwen 到 36 人就撞线了，Ling 可以推到 72：正好两倍。而且这时候 Ling 的相对优势虽然从单用户的 2.88 倍缩到 1.78 倍，但它体现的方式变了：不再是"每个人更快"，而是"能多接一倍的人"。
按 5.1 那张表，70 个人的团队，这就是买一台还是买两台的差别。
Ling 这类低激活 MoE 天生就适合这个场景：每个 token 只唤醒 4% 的参数，意味着在同样的带宽预算下能塞进更多并发对话。它牺牲的是硬件利用率（只有 18%），换来的是绝对速度和并发密度：对做服务的人来说，这笔交易很划算。
一句话：做给很多人用的产品，选 Ling flash 这类稀疏 MoE。
5.4 编程第三条路：不选，让两台机器分工
上面两节都是二选一。但如果你手上两台机器都有，还有第三种答案：让它们各干一段：一个负责想，一个负责干。
这个思路最近有篇论文给了不错的证据。
《AI4AI at Test-Time》路由逻辑、提示模板、确定性的求解代码、格式校验、验证环节。弱模型的参数一个字节都没动，成绩从 0.49 涨到 0.91。
而这件事，恰好和我这轮实验测出来的东西接上了。
benchmark 上 Ling 快 2.88 倍，只要每次调用的上下文足够短，Ling 就能拿回它的 2.88 倍。
而"把大任务拆成一堆边界清楚的小任务"，正是把长上下文变成短上下文。所以这套做法对稀疏 MoE 的收益是双份的：既让它少犯错，又让它跑在自己最快的那个区间里。4.3 节那 359 万重复预填的 token 也是同一回事：几十轮滚下来的长会话每轮都要重读前文，换成一堆独立的小任务，这笔开销直接消失。
两个模型加起来 132 GB，同一台机器装不下，所以必须分开放。Qwen 当规划者、Ling 当执行者。
6. 到底怎么买
Spark VS 4090 48G X2
121 GiB 统一内存最大的价值不是跑分，是省心地把东西装进去：更大的模型、更高精度的权重、单机开发、模型研究、不想折腾多卡拓扑。双 4090 虽然是 96 GB，但权重装完还得留出 KV 的空间，实际能舒服跑的模型上限大概在 80G 左右；Spark 能撑到 100G 上下。所以模型超过 80G，就只能选 Spark 了。
但是一旦能把模型装到显卡里，我会选 4090双卡，毕竟快了不少。
不过 Spark 的短板可以补回来一部分。同一台机器换成 MXFP4 + SGLang，单会话从 39 提到 54.9，达到双 4090 的 38%：不再是"慢一个数量级"。代价是要自己折腾量化格式和推理引擎的适配，这件事在 Spark 上比在 4090 上麻烦得多。
但是价格上，Spark 比 4090 双卡要便宜 3 万。
还有一种情况这篇文章前面一直没提：两台都买。
两台机器是偏科生，两个模型也是，只要想好用途，两个都能买。
看本地推理硬件，不要看 TFLOPS 了，而是按这个顺序问四句：
第一，装不装得下。
第二，每个 token 要激活多少参数。
第三，显存带宽多大。
第四，是一个人用，还是几十个人用。
这四个问题问完，该怎么买基本就出来了。
7. 最后
诚实起见列一下，这几处补完之前我不会把结论说死：
- 每步多猜几个。 全文用的都是最保守的每步猜 1 个。1.4.1 那张表是按等比数列算出来的估计，不是实测，而且真实的猜中率会随深度衰减，实际能拿到多少必须测过才算数。
写到这里我突然想到，如果把这两个模型、两台机器拿去开咖啡店，好像也挺合理。
咖啡第二杯半价，token 无限供应。
完美闭环。
如果你也在折腾本地模型部署，欢迎关注 @MinLiBuilds。
