很大胆！花50万，16台英伟达小盒子组集群，本地跑Kimi K3

如果人有钱，还有技术，还大胆，玩起AI来，会是什么样子？

最近有个哥们，花小50万，买16台英伟达小盒子，组成集群，誓把Kimi K3拉下马。

英伟达AI小盒子——DGX Spark，大家都不陌生了吧。

一台巴掌大的小盒子，拥有128GB统一内存，现在售价4699刀。

Kimi K3的参数达到2.8万亿，小小DGX Spark是不可能装下的，我们来看这位土豪博主是怎么玩的。

2.8T权重怎么装得下？

先看16台Spark的集群是怎么组的。

他用了MicroTik的一款4端口交换机，每个端口速率都是400G。

然后用一分四线缆，把每个400G端口，分成4个100G端口，这样就有了16个100G，正好能连16个Spark。

16台Spark总共是2TB内存，但满血版Kimi K3的权重是2.8T，这2TB的内存还是不够。

所以这位博主用了MXFP4量化版本，相比满血版，权重少了一半，只有1.4T了。

这个，整个集群吃下权重就ok了。

用推测解码来提升速度

模型装进去以后，新的麻烦出现了。

Kimi K3被拆到16台机器上，每生成一个token，16个节点都要交换中间计算结果，卡得一批。

于是DSpark推测解码框架被加入进来，提升效率。

DSpark是DeepSeek联合北京大学在今年6发布的一个推测解码框架。

推测解码本身不是新技术，它的原理就是先用一个小模型打草稿，主模型对草稿进行审核，从而减轻主模型负担，提升推理效率。

DSpark进一步改进了传统推测解码框架，兼顾效率与前后连贯性，更符合生产环境的要求。

这个博主在实验中，采用了红帽AI发布的Kimi K3专用DSpark草稿模型。

红帽这个小模型有50亿参数，包含5层草稿网络，一次可以打6至8个token的草稿。

也就是说小模型负责先响应请求，快速打草稿，最终结果由Kimi K3负责验证。

来看看最终成果

权重吃下了，优化加速方案确定了，效果怎样呢？

博主透露，首次测试中，平均生成速度超过20token/s，峰值达到38 token/s。

这个测试最早是8月4号披露的，截止到9月7日，方案已经从V1迭代到V3生产版。

V3版本更加稳定，可以支持4个并发请求分别使用50万token上下文，在4K上下文深度下，平均吞吐为19.83 token/s。

注：V3版本是16路张量并行（TP16），8路解码上下文并行（DCP8），启用红帽AI发布的推测解码草稿模型。pp行代表模型阅读输入的速度，tg代表模型输出答案的速度。第二列为平均吞吐，第三列为峰值吞吐。

这套mini集群成本几何？

这句戳到肺管子上了。

如果按照英伟达官方最新的调价，一台DGX Spark的价格是4699刀，16台就是75000多刀，折合人民币小50万呢。

这还不算交换机钱，据博主说，这套系统运行功耗是2.3kW。

另外一位用户说↓

他跑通一周后，认可Kimi K3的稳定性和能力，却没有继续让16台机器全部服务K3。
改成8台运行GLM-5.3、4台运行GLM-5.3-Flash，另外4台运行Qwen3.8-Flash-Next。

也许，这才是正经DGX Spark玩家的正常操作，平时拆成多个小集群，同时处理多种需求，测试前沿模型的时候，在把节点重新合并。

网友们的这些玩法，都很大胆，也很“暴力”。

不过，随着各大厂商纷纷应景推出统一内存的暴力AI终端，这种奇葩玩法会越来越多。

英伟达有DGX Spark和RTX Spark，AMD有Razen AI Halo，苹果最新的Mac Studio也推出了512G统一内存版本。

也许，未来的个人工作室，真的可以本地化运行万亿级参数的前沿模型，预算只需要50万。

这也让我想起前两周，一个群友要采购公司产品演示用机，需求就是本地化跑一个小模型，然后支撑公司AI产品去客户侧演示。

他在DGX Spark和Mac Studio之间犹豫不决，最终选了DGX Spark。

原因之一就是Spark对模型的原生适配更好，而Mac的适配还要等社区野生发布。

而看完这个16节点集群，我又有一点想法，DGX Spark的网络吞吐比Mac有明显优势（200Gbs ConnectX-7网卡），而Mac只有10G网卡。

虽然Mac有80Gpbs级的雷雳5，但是大规模组集群还是不够用。

所以，对专业AI玩家来讲，还是DGX Spark这种专业设备更好玩、耐折腾；

如果要兼顾娱乐、办公、装x，同时还想本地化试试小尺寸模型，尤其是作为智能体的载体，那么优先Mac。