月之暗面放出 Kimi K3 完整权重后，Deltafin 项目很快展示了在 Apple Silicon Mac 上运行这个 2.8 万亿参数模型的可能性。真正值得关注的不是约 0.3 token/s 的速度，而是一个更具体的工程问题：当模型规模远远超过机器内存时，推理系统怎样利用稀疏激活、量化、统一内存与外部存储，把一次原本“不可能装下”的推理变成可以执行的流水线。
2.8 万亿参数不等于每个 token 都计算 2.8 万亿参数
讨论超大模型时，最容易混淆的是“总参数量”和“单次推理实际参与计算的参数量”。
如果模型采用稀疏专家架构，路由器会为每个 token 选择少量专家。全部专家共同构成总参数量，但一次前向传播只激活其中一部分。于是，模型可能同时具备极大的参数容量和相对有限的单 token 计算量。
需要强调的是，来源摘要没有给出 Kimi K3 的专家数量、每 token 激活参数量、量化格式或 Deltafin 的完整内存调度细节。因此，不能仅凭“2.8 万亿参数”推断实际 FLOPS。合理的判断框架是：
- 总参数量决定完整权重至少需要多少存储空间。
- 激活参数量更直接地影响单 token 的矩阵计算成本。
- 权重放置策略决定数据要从内存还是 SSD 读取。
- KV Cache 会随着上下文增长，持续消耗内存。
- 实际速度取决于计算、内存带宽和存储 I/O 中最慢的一环。
即使只用 2 bit 保存 2.8 万亿个参数，理论权重体积也约为 700 GB；4 bit 则约为 1.4 TB。这还没有计算量化元数据、缓存、运行时缓冲区和文件系统开销。对一台 M1 Max 来说，完整权重显然不可能全部常驻统一内存。
Mac 为什么仍然能够启动推理
Apple Silicon 的 CPU、GPU 和 Neural Engine 共享统一内存，减少了传统独立显卡环境中 CPU 内存与显存之间的显式复制。这个设计对本地模型推理很有帮助，但统一内存并不会凭空扩大容量：64 GB 仍然只有 64 GB。
当权重大于物理内存时，可以这样理解 Deltafin 一类研究项目可能采用的执行路径。以下是工程分析，不代表摘要披露了其具体实现：
- 权重经过低比特量化，以减少磁盘占用和传输量。
- 模型文件通过内存映射或分块读取，而不是一次性载入。
- 路由器确定当前 token 需要哪些专家。
- 运行时只把必要权重页送入内存，并尽量缓存热点专家。
- CPU、GPU 或其他可用后端执行当前激活部分。
- 内存压力上升时，冷权重页被操作系统或运行时淘汰。
这种方案解决的是“能否运行”，并没有自动解决“能否交互”。如果每生成一个 token 都触发大量随机 SSD 读取，系统就会从计算受限变成 I/O 受限。约 0.3 token/s 意味着生成一个 token 需要三秒以上，适合架构实验和离线任务，却很难承担日常对话、代码补全或实时 Agent 循环。
先在自己的 Mac 上做容量与吞吐量估算
在下载数百 GB 权重前，可以先检查统一内存、芯片型号和可用磁盘空间：
system_profiler SPHardwareDataType | grep -E 'Chip|Memory'
df -h /
sysctl -n hw.memsize
还可以用下面的脚本估算权重体积，并计算在给定生成速度下，每个 token 最多能从存储层搬运多少数据。这里明确采用一个简化假设：忽略 KV Cache、量化分组元数据、文件系统缓存和计算时间，仅用于判断数量级。
cat > model_feasibility.py <<'PY'
#!/usr/bin/env python3
import argparse
parser = argparse.ArgumentParser(description="Estimate local LLM storage and I/O limits")
parser.add_argument("--params-trillion", type=float, default=2.8)
parser.add_argument("--bits", type=float, default=2.0)
parser.add_argument("--tokens-per-second", type=float, default=0.3)
parser.add_argument("--disk-gbps", type=float, default=5.0)
parser.add_argument("--active-percent", type=float, default=2.0)
args = parser.parse_args()
params = args.params_trillion * 1e12
weight_bytes = params * args.bits / 8
active_bytes = weight_bytes * args.active_percent / 100
bytes_per_token_budget = args.disk_gbps * 1e9 / args.tokens_per_second
print(f"Quantized weight size: {weight_bytes / 1e9:,.1f} GB")
print(f"Active weight share: {active_bytes / 1e9:,.1f} GB/token")
print(f"I/O budget at target: {bytes_per_token_budget / 1e9:,.1f} GB/token")
if active_bytes > bytes_per_token_budget:
print("Result: target speed is impossible from disk alone under these assumptions.")
else:
headroom = bytes_per_token_budget / active_bytes
print(f"Result: raw sequential bandwidth leaves about {headroom:.1f}x headroom.")
print("Random reads, cache misses and compute will reduce this substantially.")
PY
python3 model_feasibility.py \
--params-trillion 2.8 \
--bits 2 \
--active-percent 2 \
--disk-gbps 5 \
--tokens-per-second 0.3
运行前应按实际情况修改 --bits、--disk-gbps 和 --active-percent。最后一个参数尤其关键：摘要没有给出 Kimi K3 的实际激活比例，示例中的 2% 只是用于容量规划的假设，不能当作模型规格。
脚本同样揭示了一个边界：SSD 标称的顺序读取速度并不等于专家权重的实际读取速度。大量小块随机读取、文件映射缺页、解量化和内存回收都可能显著降低吞吐量。若系统开始频繁交换，其他应用也会出现明显卡顿。
0.3 token/s 仍然有研究价值
把这类项目仅仅评价为“太慢所以没用”，会错过它真正验证的能力。
它证明了超大模型部署可以从“整个模型必须放进加速器内存”转向分层存储：热点权重留在统一内存，冷专家停在 SSD，需要时才调入。这个方向类似数据库缓冲池和操作系统虚拟内存，核心指标也不再只有峰值算力，而包括专家命中率、预取准确率、读取粒度、缓存淘汰策略和 SSD 写入寿命。
这类本地运行方式适合：
- 验证模型文件、分词器和推理图是否完整可用。
- 研究专家路由、权重缓存及低比特量化。
- 执行不要求实时返回的离线生成任务。
- 在不上传数据的前提下做少量敏感样本实验。
它暂时不适合高并发服务、交互式编码、长链 Agent，以及任何对首 token 延迟有严格要求的场景。上下文越长，KV Cache 的额外压力也越值得警惕。
采用前检查四件事
准备复现实验时，不要只看“支持 M1 Max”这一行。更可靠的检查顺序是：确认量化权重的实际磁盘体积；确认运行时是否支持断点下载和文件校验；为系统和 KV Cache 留出足够统一内存；持续观察内存压力、SSD 读取量与温度。
Kimi K3 在 Mac 上跑起来，并不意味着消费级设备已经能高效驱动 2.8 万亿参数模型。它说明的是另一件更有工程含量的事：只要模型具有可利用的稀疏结构，运行时又能精确调度权重，存储容量、内存容量和计算吞吐量就可以被拆开规划。“能跑”与“好用”之间仍有很长距离，但这条路径已经从架构推演变成了可测量的系统实验。