四台 Mac Studio 跑 Kimi K2.6：能点亮，不等于能生产
四台 512GB Mac Studio 确实跑起了万亿参数 Kimi K2.6，但原文没有公布速度、并发和稳定性。算完近 30 万元的硬件账后，普通人调用 API 依然便宜得多。
LM Studio 在 WWDC 后发了一段很有冲击力的原文：他们与苹果合作，使用预览版 LM Studio，把 1T 参数的 Kimi K2.6 跑在四台 Mac Studio 组成的集群上，还通过 LM Link，让 MacBook Neo 和 iPhone 安全地远程访问。
最后一句尤其诱人：
A glimpse of your own private, frontier-scale AI.
仿佛只要在桌上摆四台 Mac Studio，普通人也能拥有一套私有的前沿 AI。
我的看法没有这么乐观。
这场演示证明了 Kimi K2.6 能跑起来，但离“可以投入生产”还有一长串问题没有回答。
能跑，性能到底怎么样
先看 LM Studio 的官方原文。里面公布了模型规模、四机集群和远程访问，却没有公布最关键的性能数字：
- 首字延迟是多少？
- 每秒能生成多少 token？
- 256K 上下文下还剩多少速度？
- 能同时服务多少用户？
- 四台机器的利用率和功耗如何？
这些问题没有答案，就无法判断它是“流畅可用”，还是“等一会儿也能出字”。
Kimi K2.6 的官方模型信息显示，它总参数量约 1.06 万亿，每个 token 激活约 320 亿参数。Hugging Face 模型元数据显示公开仓库约 595GB，而官方 config.json表明它采用混合压缩方案，大量权重为 4bit。
所以，“运行完整的一万亿参数模型”不等于“使用 BF16 全精度运行”。如果按 BF16 粗算，光权重就需要约 2.12TB，四台 512GB Mac Studio 的物理内存合计也只有 2TB，还没给系统、运行时和 KV Cache 留空间。
这场演示很厉害，但目前最严谨的描述只能是：四台 Mac Studio 成功运行了完整模型架构，具体量化方式和实际性能没有公开。
预览版，离生产环境有多远
原文里还有一个容易被忽略的词：preview version，预览版。
生产系统看重的从来不只是“能生成答案”，还包括：
- 连续运行几天、几周是否稳定
- 一台机器掉线后能否自动恢复
- 是否支持健康检查、监控和告警
- 是否能滚动升级模型而不中断服务
- 高并发下 P95 延迟是否可控
- 是否有权限管理、审计日志和服务支持
目前公开内容没有给出长时间压力测试，也没有说明节点故障后的处理方式。
模型被切分到四台机器以后，任何一个节点、线缆或系统进程出问题，都可能影响整次推理。生产环境还需要负载均衡、冗余节点、自动拉起和容量规划，这些都不是一次现场演示能证明的。
所以，我会把它定义为一个很有价值的技术验证，适合研究、内部试验和概念验证；在完整基准和高可用方案公开前，还不应该直接承担关键生产业务。
四台机器到底怎么连
这里其实有两种“互联”，不能混为一谈。
第一种是四台 Mac Studio 之间的计算互联。
现场演示资料显示，这套集群利用 Thunderbolt 5 和 RDMA 能力，让多台 Mac 低延迟交换模型分片与中间数据。它解决的是分布式推理中最难的通信问题：单机内存装不下，就把模型拆到多台机器上运行。
但网络永远比片上内存慢。模型每生成一个 token，都可能产生跨节点通信。拓扑怎么接、数据怎么切、通信开销多大，最终都会反映在生成速度上。预览版 LM Studio 暂时没有公开这些实现细节和基准。
第二种是手机、笔记本到推理服务的访问互联。
这部分由 LM Link 负责。根据官方文档，它会基于 Tailscale 创建一张独立的端到端加密网络，设备自动发现彼此。LM Studio Hub 只帮助发现设备，后续聊天、模型列表和数据传输都走加密连接，设备不会直接暴露到公网。
在客户端看来，请求仍然可以发给 localhost:1234，LM Studio 会把请求路由到远程设备上的模型。这个设计比自己开放公网端口省心得多。
但 LM Link 解决的是安全访问，不等于解决了集群高可用。官方 FAQ 也提到，设备崩溃或服务没有运行时会显示 disconnected。至于四个计算节点中断一个后，分布式模型能否无感恢复，目前没有公开答案。
四台 512GB Mac Studio 要多少钱
现场演示资料显示，这次使用的是四台配备 512GB 统一内存的 M3 Ultra Mac Studio。这个配置已经从苹果官网停售，现在官网在售规格中 M3 Ultra 最高只有 96GB，无法照着演示重新下单。
按 2025 年的历史售价计算：
- 512GB 内存、1TB SSD：单台 74,249 元
- 512GB 内存、16TB SSD：单台 108,749 元
因此四台机器分别需要：
74,249 × 4 = 296,996 元
108,749 × 4 = 434,996 元
价格来源可以参考当时的历史报道。对推理来说，没有必要为每台机器都购买 16TB SSD，所以接近 30 万元是更合理的硬件起点。
这还没算雷雳 5 线缆、电费、备件、维护时间和可能需要的冗余节点。按照苹果官网标注的单机最大连续功率 480W 计算，四台合计可接近 2kW；真要长期满负载运行，电费也不是零。
和 API 相比贵多少倍
一次性硬件价格不能直接和一次 API 调用比较，必须先假设使用量和折旧周期。
Kimi 官方当前的 K2.6 API 定价是：
- 缓存命中输入：0.16 美元 / 100 万 token
- 缓存未命中输入：0.95 美元 / 100 万 token
- 输出：4 美元 / 100 万 token
假设一个使用量已经很大的个人用户，每月消耗 1000 万输入 token、生成 200 万输出 token，而且完全不计算缓存优惠：
10 × 0.95 + 2 × 4 = 17.5 美元 / 月
按 1 美元约合 7.2 元估算，大约 126 元 / 月，三年约 4536 元。
同样按三年使用期摊销：
- 29.7 万元集群：约 65 倍 API 成本
- 43.5 万元顶配集群：约 96 倍 API 成本
而且这个对比还没有给本地集群加入电费、维护和故障成本，也没有给 API 加上缓存折扣。
反过来说，只有当你的月使用量达到上述重度个人用户的约 65 到 96 倍，并且本地集群的实际吞吐量能够跟上时，单看硬件摊销才可能接近 API。
我的判断
四台 Mac Studio 跑起 Kimi K2.6，最大的意义不是“以后不用 API 了”，而是证明统一内存、雷雳互联和分布式推理可以把万亿参数模型搬进办公室。
对于必须离线处理数据、调用量极大、又有专人运维的企业，这条路线值得继续研究。数据不出本地，本身就可能比硬件成本更重要。
但对普通人、小团队，甚至大多数线上产品来说，API 仍然更现实。它提供的是按需使用的算力，不需要你提前买下四台稀缺的 512GB Mac Studio，也不需要你自己解决集群稳定性和扩容问题。
能点亮一个万亿参数模型，是技术突破；能稳定、便宜地服务真实用户，才是生产能力。
在 LM Studio 公布速度、并发、稳定性和故障恢复数据之前，我愿意为这场演示鼓掌，但不会拿它替换生产环境里的 API。