有人真把 K3 塞进了 64G 的 Mac，代价是三个字等一分钟

哈喽，我是飞飞。

昨天我刚写过一篇 K3，今天又写它，我先把理由摆出来，免得你觉得我在炒冷饭。

昨天那篇的核心判断是一句话：权重开放、能自己部署、我这种规模的人部署得起，其实是三件事，得分开数。我当时说，前两样 K3 都做到了，剩下那样跟我没关系。

理由写得挺硬气。我那台 M1 的 Mac，装不下 594GB 的权重，原话是「这不是慢一点快一点的问题，是它根本装不进来」。

然后今天，有个叫 Deltafin 的项目，在一台 64GB 内存的 M1 Max 上，把这个 2.8T 参数的模型跑起来了。

所以今天这篇要干的事很具体：有人替我把那个实验做完了，结果摆出来了。而且结果跟我预想的不一样。

昨天我说它装不进来

先把旧账翻出来。

昨天我把自托管拆成三件事，那句「根本装不进来」是整篇的支点。我当时算得很简单：594GB 的权重文件，对着我那台机器的内存，超了就是超了，剩下的都不用聊。

我还顺手给了个建议，说想自托管的人，先去看一眼权重多大、参考配置几张卡，这一眼能替你省掉整个周末。

现在看，这个建议本身没问题。有问题的是我那个「装不进来」的判断。

有人真把它装进去了

Deltafin 这个项目干的事，我得先说声佩服。

它跑的机器是一台 M1 Max，10 核 CPU、32 核 GPU、64GB 内存，配内置的 NVMe。就是一台普通开发者会有的电脑，不是什么工作站。

装法有两种。完整装下来大约 1.7TB 磁盘，下载要花 5 到 10 个小时。还有个流式模式，本地只占约 215GB，半小时就能下完。

流式那个模式的机制挺巧，我一开始还以为是从本地磁盘按需加载。翻了说明才知道，它是按需从 HuggingFace 那边用 HTTP 范围请求把专家权重拉下来，每个专家一次 17.55MB，边拉边缓存。也就是说，它慢在网络那一头，不在磁盘。

量化上，专家权重走 MXFP4 原生格式，常驻的那部分和输出头压到 int8。它还提供了 OpenAI 兼容的接口，聊天和代码补全都能接。

所以我昨天那句话，字面上已经被推翻了。它装得进来，用两种方式都装得进来。

三个字要等一分钟

那它跑得怎么样？

中位速度 0.0687 token/s，换算过来是 14.6 秒吐一个字，波动区间是 0.0503 到 0.0779。

这个数字光看不够有感觉，我再给你几个具体的。

你给它一个只有 5 个词的提示，它憋出头一个字，中位要等 28 秒。生成三个字，总共要 56.5 秒，将近一分钟。

如果你走的是那个省磁盘的流式模式，速度掉到 3 分钟一个字，甚至更慢。

项目作者自己给用户的建议是：把客户端的超时设成小时级，别设成秒级。

我拿自己的机器对照了一下。我之前在 M1 上用 Ollama 挂 gemma4:e4b，上下文开到 32768，速度在 20 到 40 token 每秒之间晃。那是个几 GB 的小模型。

一秒二三十个字，和十四秒半一个字，中间差了大概三百到六百倍。

再往上比更夸张。官方那套跑在 8 张 GB300 上的配置能到 113 token/s，是这台 Mac 的一千六百多倍。

我还顺手算了笔更贴身的账。我写一篇稿子大概两千中文字，折三千个 token 左右。用这个速度写，得跑 12 个小时。

我那句话说错了一半

好，回来认账。

我昨天写的是「这不是慢一点快一点的问题，是它根本装不进来」。

现在证明：它装得进来，而且恰恰就是快慢问题。

方向我判对了，个人自托管这条路走不通。可理由我说错了一半。我以为卡在容量，实际上卡在速度。这两个卡点听着差不多，含义差很远。卡在容量意味着此路不通，卡在速度意味着路是通的，只是走完要一年。

这个错误值得我记一下。当时我是拿一个静态的数字，去推一个动态的结论。看到 594GB 大于我的内存，我就下了「装不进来」的判断，压根没想过还能有别的装法。真去做的人，比我这种坐在旁边算数的人，想得野多了。

还有一层，我昨天也没想到。我一直把磁盘当成那道门槛，可 Deltafin 的流式模式告诉我，磁盘那头 215GB 就够了，真正的瓶颈跑到网络和内存带宽上去了。门槛压根不在我以为的那个位置。

量出来的不行更值钱

说到这，得替这个项目说句公道话。

作者自己在说明里写得清清楚楚，这是个研究项目，不是拿来干活的方案。他也如实列了限制：只支持贪心解码，你传温度和 top_p 它收下但不理；一次只能处理一个请求，不支持并发；提示词一长代价就飙上去；流式装法下，一次聊天请求可能要跑好几个小时。

所以这压根不是一次失败的尝试，是一次成功的边界测绘。

我甚至觉得，这件事的价值比它的实用性大得多。

在这之前，「个人能不能自托管 2.8T 的模型」是个各说各话的开放问题。有人说不可能，有人说等等看，我自己昨天也只给了个基于容量的粗判断。现在有了确切答案：做得到，但慢三百到六百倍，而且作者把每一个数都量出来了、把限制一条条列清楚了。

一个被精确量出来的不行，比一个模糊的大概不行有用得多。前者能让你当场做决定，后者只会让你一直惦记着。

顺带说一句，这些数都是项目方自己报的，我没跑过，也没看到外部独立复测。项目还在迭代，那个 0.0687 是当前的中位数，不是刻在石头上的结论。

什么模型才值得自己跑

那到底什么规模的模型，才值得你在自己机器上跑？

我一直有把尺子，判据只有一句：这次是不是人在盯着屏幕等。

人坐在那儿等它吐码，那速度就值钱，慢一点都难受。要是活儿能挂后台异步跑、人早走了，速度慢点无所谓，省下的钱更实在。我以前拿这把尺子量过各家模型，都还管用。

可 14.6 秒一个字，把这把尺子直接量废了。它连异步这条退路都堵死了。挂后台跑一篇稿子要 12 个小时，这已经超出了「慢点没关系」的范围，你根本没法把它排进任何一天的工作里。

所以我的判断没变，只是理由换了个更准的：自托管这条路对我依然关着，可关门的不在容量，在速度。

给你一个今天就能用的估法，比看参数量靠谱：别看参数量，看激活参数量和你机器的内存带宽。K3 是 2.8T 总参数，可每次只激活 104B。真正折磨机器的，是这 104B 要在多快的带宽上流过去。你那台机器一秒能搬多少 GB，基本就框定了它能跑多大的模型。查一下你机器的内存带宽，再拿激活参数量除一除，比翻一晚上教程管用。

最后想问问你：你在自己机器上跑过最大的模型是多大？慢到什么程度你就放弃了？我的放弃线大概是等超过五秒就烦，所以 14.6 秒这个数我看一眼就知道自己扛不住。评论区聊聊你的线在哪儿。