企业考虑把模型放到端侧，动因通常不是算力便宜，而是三条：数据不出内网、调用成本可控、离线可用。落到实施阶段，第一个卡住的往往是对容量的估算——尤其是 MoE 架构，很容易被"激活参数少"这句话带偏，把显存需求算小一半还不止。

这篇按实施顺序梳理：先把容量算对，再谈部署架构，最后落到验收与任务分级。

一、容量评估：先纠正一个常见误算

MoE 的机制是模型内挂载大量专家，每个 Token 只路由其中少数几个参与计算。计算量因此显著下降，这是它跑得快、也省电的原因。

但要明确一点：路由发生在运行时。下一个 Token 会命中哪几个专家，在请求到达前无法预知。所以未被激活的专家不能按需从远端拉取，必须保持在可访问状态。

因此 MoE 优化的是计算密度，不是存储占用。评估时必须把三笔账分开算：

• 总参数量——决定必须装下的权重大小
• 单 Token 激活量——决定算力与功耗开销
• 必须常驻的内存量——与总参数量基本等量

以 Qwen3-30B-A3B 为例：总参数 300 亿，每 Token 激活 30 亿，8bit 精度下权重约 30GB。一张 32GB 显存的设备装完权重后，留给 KV 缓存的空间已经非常紧张。

这一条如果算错，后续的硬件选型、并发规划都会连锁出错。建议把这三项写进方案模板，每次评估都填。

二、部署架构：三层放置与异构补位

容量不足时，解法不是换更大的卡，而是引入存储层次，把"必须常驻"降级为"必须可达"。

公开基准里有一份完整实测可作参照：32GB 显存的 RTX 5090 配 64GB 内存，运行两万四千多个专家的 Qwen3.8-Flash-Next，读入每秒四千余 Token，出字每秒 165 至 179 Token（单请求口径），引擎为开源分层推理引擎 Strata。

它的三层结构是：

• 显存（热层）：承载常驻计算部分，剩余额度做成专家缓存，存放高频专家。缓存随会话自适应，用得越久越清楚该留谁。
• 内存（温层）：全部两万四千多个专家钉住在此，不允许继续下坠。
• 固态盘（冷层）：存放 28.8GB 的短板表（词表），查词按行读取，访问放大低。

此外还有两项配套设计：

• 长上下文分层：KV 缓存同样分级。64K 以上只保留高频段在显存；长文按 8192 Token 分块读取；引擎预留在专家缓存中的三千余个位置，用于容纳预填充阶段的专家集合。
• 低比特量化：实测采用 IQ2_XS 档位。量化是三层结构成立的前提，但档位与生成质量存在权衡，需按业务验收标准确定，不能只看速度。

三、调度：用 CPU 补齐未命中

分层的必然代价是未命中。架构上的处理方式不是等待搬运，而是异构并行。

机制是：专家缓存未命中时，权重搬运来不及，直接交 CPU 就地计算；GPU 同时继续处理命中的部分，两者不互相阻塞；当前层注意力计算期间，下一层所需专家已通过 PCIe 预取进显存，用流水线掩盖搬运延迟。

这套设计的成败取决于命中率。实测数据如下：

• 显存专家缓存占 23.44GB，装载一万七千余专家，约占总量的七成
• 命中率 97.8% 至 99.7%，百次请求中不足三次需要 CPU 介入
• 内存侧钉住其余专家，CPU 侧 23 个线程待命

七成容量覆盖九成八以上请求，说明专家访问存在明显热区。这是整套架构的经济性来源：用容量换命中率，而不是追求全量常驻。

另有与存储无关的一层加速：模型自带草稿层（推测解码），按命中比例折算收益，官方口径整体提速 1.6 至 1.8 倍，实测中已启用。规划吞吐时可以把这层算进去，但要按实际命中率打折。

四、硬件选型的换算关系

端侧选型时，一个实用的比例是：显存每增加 1GB，约可多容纳 700 个专家。

公开基准里还有更极端的配置：12GB 显存配 46GB 内存，运行 257GB 一档模型，出字每秒 9 至 11 Token。这条记录的价值在于说明：在同一架构下，容量与速度是可调的连续区间，不是"能跑"与"不能跑"的二元判断。

配置建议按机器反向推导，而不是照抄别人的参数：

1. 先确定显存能给专家缓存的额度；
2. 按每 GB 约 700 个专家估算驻留规模；
3. 内存必须覆盖剩余全部专家，否则会向磁盘下坠，性能断崖式下降；
4. 再按业务要求的速度下限，反推可接受的硬件档位。

Mac 平台有同路径的开源实现：48GB 统一内存运行 104GB 模型，出字约每秒 12 Token。这类实现需要配套说明边界——适合后台批处理，不适合交互式对话；小内存设备还受散热限制。

五、验收规范：速度数字必须带口径

端侧吞吐数据最容易失真，因为口径差异极大。该实测报告写得很克制：九次测量，同一台已加载完成的机器，串行执行，贪心解码，输出上限 256 Token；并注明并发与长输出未作测试。

建议把口径写进验收单，至少覆盖三项：

• 是否单请求：并发下 CPU 补位资源被争抢，命中率不变但补位代价上升
• 输出长度：草稿层与预填充收益随输出长度摊薄
• 是否预热：冷启动与稳态差异极大

另有一项常见顾虑需要澄清：分层后固态盘被频繁读取，是否影响寿命。读取带来的磨损很小，真正需要关注的是写入；端侧推理主要是读操作。若同机还有高频写盘的业务（日志、缓存落盘），才需要单独评估。

六、任务分级：哪些活放端侧，哪些留云端

分层放置并没有减少成本，只是把成本从显存容量转移到了搬运、调度与部分 CPU 算力。因此任务划分应按特征重算，而不是一刀切。

• 适合端侧：高频、单次负载轻、数据不宜外传。典型如本地文档整理、内网知识问答、离线翻译、代码补全。这类任务对首字延迟不敏感，对隐私与调用成本敏感。
• 适合云端：需跨数十份材料做长链条推理、上下文需求大、要求高并发吞吐。端侧受容量与带宽限制，单位成本不占优。

从企业视角看，这个边界是可持续优化的：端侧承接轻量高频任务，长链任务收敛到云端托管推理服务，形成分层架构。在私有化环境里，端侧的模型与词表文件可放在对象存储（如 OBS）统一分发与版本管理，端侧只做增量更新；云端推理可跑在托管平台（如 ModelArts），两侧共用同一套验收口径。

七、落地清单

• 容量评估表必须分开列：总参数、单 Token 激活量、必须常驻内存量。
• 量化档位按业务验收标准确定，不要只按速度选。
• 显存额度按"每 GB 约 700 专家"反推，内存必须覆盖剩余全部专家。
• 长上下文场景单独规划 KV 缓存分层与预填充专家预留位。
• 验收单写明单请求/并发、输出长度、是否预热三项口径。
• 端侧与云端的任务边界按季度重算，随量化与调度方案迭代调整。

激活得少，不等于占得少——端侧卡内存、卡功耗、也卡算力，其中内存最紧。