过去一周，AI 硬件圈同时出现了两个方向相反的数字。

一边是 2.4 万亿参数。Qwen 发布新一代 Max 模型，采用大规模混合专家架构，把模型总参数继续往上推。

另一边是 4.3GB。开源项目 Swiftlet 宣称，可以在普通 Mac 上以大约 4.3GB 内存运行 80B 级 Qwen 混合专家模型，还能把 35B 级模型放进 iPhone。

模型越来越大，运行它的设备看起来却越来越小。

这很容易导向一个兴奋的结论。以后每个人的手机都能装下前沿模型，昂贵的 AI 云和 GPU 集群要失去护城河了。

工程细节给出的答案更有意思。容量、速度和并发是三件事。新方法正在拆掉「模型必须完整塞进显存」这堵墙，同时把成本转移到存储、带宽、延迟和调度上。

云的护城河仍在，形状已经开始变化。

2.4万亿参数，不等于每个字都调用2.4万亿参数

Qwen3.8-Max 公布的总参数规模为 2.4 万亿，采用 MoE，也就是混合专家架构。据发布信息，每次处理 token 时激活的参数约为 95B。

可以把它想成一所拥有大量专科医生的医院。医院的总专家人数很大，一位病人不会同时看遍所有科室。路由系统会为当前问题选择少量专家参与诊断。

MoE 让模型扩大知识容量时，不必让每次推理的计算量按总参数同比增长。代价是所有专家权重仍要存放在某处，路由和通信也会产生开销。训练这样的大模型依旧需要庞大集群，服务大量用户还要同时处理并发、缓存和容错。

Qwen 在 8 月 3 日发布模型时宣布开放权重计划。权重是否已经按承诺完整提供、许可证与部署工具是否到位，需要以实际仓库状态为准。把「宣布将开放」写成「任何人已经可以在家部署」，会跨过一个很大的工程空档。

2.4 万亿这个数字说明开放模型仍在追赶前沿规模。95B 激活参数则提醒我们，模型的总容量和每次回答实际动用的计算量已经分开。

4.3GB内存，靠的是不把80B一直留在内存里

Swiftlet 采用另一种拆分方法。

它是一个基于 Swift 和 Metal 的本地推理运行时，面向 Qwen 的 MoE 模型。系统只让较小的稠密部分常驻内存，再根据路由结果，从 SSD 按需读取当前 token 需要的专家权重。

项目给出的数据是，4 位量化的 Qwen3-Next-80B-A3B 在 Mac 上约占 4.3GB 内存，Qwen3.6-35B-A3B 在 Mac 和 iPhone 上约占 2.5GB 至 2.6GB。

「运行 80B」在这里指模型权重可以被逐步调用并完成推理，不等于 80B 参数同时驻留在 4.3GB 里。大部分权重待在存储设备上，内存保存当前计算所需的部分。

这种设计把问题从容量变成带宽。SSD 读取速度、专家命中方式、缓存策略和每个 token 需要搬运的数据量，会直接决定生成速度。设备内存终于够了，用户仍可能在等下一批权重从硬盘赶来。

对需要离线、隐私和低并发的任务，这个交换很有价值。手机上的个人资料不必上传云端，Mac 可以运行过去装不下的模型。对实时语音、多人服务和高吞吐 API，频繁读取存储的延迟又可能难以接受。

「4GB跑70B」早就成立，实用速度一直是另一道题

AirLLM 是一个更早的例子。它从 2023 年开始用逐层加载与内存优化，让 70B 模型在单张 4GB 显存 GPU 上完成推理，不必为了装进显存而先做蒸馏或剪枝。后续版本也支持量化和更多模型。

它证明了模型无需整体驻留 GPU。项目文档同时暴露了交换成本。模型要先被拆分并占用大量磁盘空间，推理时不断在存储、系统内存和 GPU 之间移动权重。社区测试常见的生成速度远低于把模型完整放进高带宽显存的方案。

所以，「能跑」是一个严格的工程事实，也可能是一个误导普通用户的产品描述。

能输出第一个 token，能以每秒几 token 持续对话，能支撑十个人同时使用，能在长上下文下保持速度，分别是四个验收标准。显存数字只回答第一个问题的一部分。

本地推理的进步依然改变了可达性边界。以前物理上装不下，现在可以用时间换空间。对于批处理、夜间任务、研究验证和高隐私场景，慢一些也可能值得。

单卡也有两种完全不同的单卡

本周另一个开源项目展示了 DeepSeek-V4-Flash 在单颗 AMD MI300X 上的部署配置。模型约 304B 参数，MI300X 提供 192GB 高带宽显存。项目报告在不额外量化或卸载权重的配置下，单流解码达到 168.6 token/s，8 路并发的聚合吞吐达到 542 token/s，并验证了 256K 上下文。

这也是「单卡运行大模型」，经济模型却与 4GB 消费级显卡差异巨大。

MI300X 是面向数据中心的加速卡，192GB HBM、显存带宽和软件栈共同换来了实用吞吐。Swiftlet 和 AirLLM 通过存储流式加载降低常驻内存，MI300X 则用昂贵的高带宽内存把模型关键部分留在计算附近。

两条路线都在压缩部署规模。一条追求最低容量门槛，一条追求单设备生产性能。把它们放进同一个「单卡」标签里比较，会丢掉最关键的成本结构。

云的护城河从装得下，转向跑得稳

本地推理会拿走一部分过去只能交给云端的任务。个人知识库、离线写作、代码检索、设备内语音和企业敏感文档，都有动力留在本地。开放权重与新的运行时，也会让开发者更容易针对自己的设备和数据做优化。

云平台仍然拥有几项本地设备很难替代的能力。

它可以把昂贵加速卡保持在高利用率，为大量用户分摊成本；可以在多个设备之间切分模型，用高速互联维持吞吐；可以统一处理故障、版本升级、批处理和弹性并发；也可以提供本地设备拿不到的最新闭源模型。

因此，护城河将从「我有一张能装下模型的卡」移向速度、并发、稳定性和治理。模型能被流式加载、量化和按需激活以后，单纯的显存容量会越来越难构成壁垒。云厂商需要证明，在真实工作负载下，它能以更低的总成本交付这些能力。

对普通用户来说，选择也会更清楚。

需要隐私、离线和完全控制，可以接受等待，本地流式推理正在变得可用。需要实时响应、多人共享和稳定服务，云端仍然更合适。团队评估方案时，应同时记录模型质量、首 token 延迟、持续生成速度、并发吞吐、磁盘占用、功耗和硬件价格。一张显存占用图远远不够。

模型越大，部署越小，这个趋势是真的。

算力成本仍然存在，工程师获得了更多地方存放这笔成本。显存不够，可以放到内存；内存不够，可以放到 SSD；设备不够快，可以用等待时间偿还。

谁能把这几笔账组合得最适合具体任务，谁才会得到下一阶段的部署优势。

参考资料

/ 作者，钟懿