摘要：MoE把模型容量与单Token计算量拆开，也把显存、KV Cache、路由通信和设备利用率带入成本核算。本文结合dots3-note与Qwen3.8-27B分析本地部署的完整账单。
在本地部署的语境里，“参数量”曾经是一把尚可用的尺子：参数越多，权重占用越大，单个 token 的计算量也通常越高。MoE 把这两件事拆开了。dots3-note preview 的官方模型卡给出 280B 总参数、16B 激活参数；同一时期的 Qwen3.8-27B 则是 27B 级稠密模型。前者每个 token 只调用一小部分专家，后者每层都使用全部稠密权重。若只看激活量，dots3-note 似乎比 Qwen3.8-27B 还“轻”；若准备把模型装进显存，结论立即倒转。
这组对照很适合说明新成本公式：计算看激活参数，容量看总参数，长上下文看 KV cache，生成速度还要加上显存带宽、路由效率和跨卡通信。最后付出的成本，则由完成任务所消耗的全部 token 和成功率决定。
16B激活量从哪里来
Dots 官方配置显示，语言模型含 1 个稠密层和 45 个 MoE 层；每个 MoE 层有 256 个路由专家、1 个共享专家，每个 token 选择 8 个路由专家。路由器先根据当前 token 的隐藏状态为专家打分，再取 top-8，将专家输出按权重合并。不同 token、不同层可以走不同路径。
8/256 只有 3.125%，但不能据此把 280B 直接乘出激活量。注意力、词嵌入、稠密层、共享专家始终参与。官方所称 16B 是语言骨干单次前向的口径，包含这些公共部分；视觉和音频输入还会另行调用各自编码器。MoE 节省的是每个 token 的矩阵乘法规模，同时保留一个更大的参数库供路由选择。
Qwen3.8-27B 提供了清晰的稠密基线。其官方仓库记录约 27.78B 参数，64 层语言模型中的 FFN 均为稠密结构。粗略比较单 token 算术量时，16B 对 27B 有参考价值；它无法直接推导 tokens/s。MoE 还要执行路由、token 重排、分组矩阵乘法，并处理专家冷热不均。小批量时，每个专家分到的 token 太少，GPU 算力利用率容易偏低；批量增大后，同一专家的 token 可以合并计算，吞吐才更容易拉起来。
还有一个容易漏掉的“专家并集”问题。单个 token 每层只选 8 个专家，一批 token 合在一起却可能覆盖几十甚至上百个专家。解码批量越大、路由分布越分散，当步需要触达的专家权重越多。单用户低延迟与服务器高吞吐因此会出现不同最优点：前者关心一次路由的尾部时间，后者希望为每次权重读取聚集足够多的 token。激活参数描述逻辑计算路径，实际内存流量还受批量、路由熵和专家缓存命中率影响。
显存账单仍按总参数结算
权重驻留的近似式很简单：
权重显存 ≈ 总参数量 × 每参数字节 + 量化比例尺、索引与运行时开销
Hugging Face 的仓库元数据显示，dots3-note preview 检查点实际收录约 288.44B 参数，差额来自多模态组件及统计口径；BF16 索引权重约 576.9GB。官方 vLLM 配方为 FP8 版本要求 8 张至少 80GB 的 NVIDIA GPU。这里的“本地”已经接近单机八卡服务器，而非一张消费卡。
激活参数不会让未选中的专家从显存里消失。下一层、下一个 token 随时可能选中它们，低延迟服务通常需要让全部权重保持可访问。把专家放进系统内存或 NVMe、按需换入可以降低 GPU 容量门槛，却会把延迟交给 PCIe 和存储带宽，交互式体验常常先被数据搬运拖垮。
Qwen3.8-27B 的 BF16 仓库约 55.6GB，和 27.78B×2 字节相符。FP8 大致把主体权重减半，4bit 又可继续压缩；实际文件会高于“参数×位宽”，因为部分张量保留高精度，还需比例尺和元数据。vLLM 的 Qwen3.8 配方列出一个 NVFP4 构建，显存占用为 24.6GiB，但它是配方引用的第三方量化检查点，不能等同于 Qwen 官方原始权重。量化也不会自动带来同倍数加速，收益取决于硬件是否有对应低精度单元、内核能否高效解码，以及精度损失是否导致更多重试。
长上下文的第二块显存：KV cache
标准 GQA 注意力的 KV cache 可估为：
2 × 层数 × KV头数 × 头维度 × 上下文token数 × 批量 × 每元素字节
前面的 2 代表 K 和 V。它随上下文和并发线性增长，与 MoE 专家总数关系很弱。权重量化到 4bit 后，KV cache 仍可能使用 BF16 或 FP8；长会话里，它会逐渐成为显存预算的主角。
Qwen3.8-27B 使用混合注意力：64 层中只有 16 层为全注意力，这些层采用 4 个 KV 头、256 维头；另外 48 层采用 Gated DeltaNet 线性注意力，以固定大小的循环状态处理历史。只计算 16 个全注意力层，BF16 KV 约为每 token 64KiB，262,144 token、单序列约 16GiB，尚未计入线性状态、分页碎片和运行时空间。它的 262K 原生上下文因此不能理解为“任意显卡都能开满 262K”；扩展到 1M 还需 RoPE/YaRN 配置，并承担更大的缓存、预填充时间及可能的质量变化。
并发会把这笔数再乘一次。一个 256K 会话与十六个 16K 会话的累计 token 相同，调度难度却不同：长会话持续占用大块缓存，短会话更容易结束并释放页面。Paged Attention 能减少预留和碎片浪费，无法消除每个有效 token 的状态。前缀缓存适合大量请求共享系统提示词或文档前缀；各自独立的聊天记录仍需单独保存。评估显存时，应使用线上输入长度分布和并发分位数，少用“最大上下文×最大并发”或单条空载演示替代真实负载。
Dots 也专门压低长上下文成本。官方配置含 13 个 DSA/全注意力层和 33 个滑动窗口层，窗口为 513；同时采用 MLA 式压缩表示。SGLang 为它分别管理全注意力与滑窗 KV 池，官方 vLLM 配方虽然允许模型配置中的 524,288 token 上限，验证命令先设为 262,144，并明确要求根据 KV 预算再增加。上下文上限只是请求边界，能否承载还取决于并发数和实际缓存池。
tokens/s不能单独代表便宜
本地测试常贴一个生成速度数字，但至少应拆成三项：预填充首 token 延迟、单用户解码速度、服务器总吞吐。预填充会并行处理输入，更容易吃到算力；逐 token 解码经常受显存带宽约束。稠密模型在低批量解码时近似反复读取整套活跃权重，MoE 读取被选专家的权重，却增加不规则访存和调度。多用户批处理能复用权重、提高算术强度，也会拉高单个请求的排队和 token 间延迟。
任务成本还应使用“完成一次工作所需的总 token”。可写成：
单任务时间 ≈ 预填充时间 + 输出token数 ÷ 单用户解码速度 + 工具调用与重试时间
推理模型会生成隐藏思考，Agent 还会重复读取观察结果、调用工具、纠错。Qwen3.8 模型卡直接提醒：较低 reasoning effort 虽能缩短单轮响应，也可能因分析不足造成失败和重试，最终增加总延迟与 token。一个 80 tokens/s、需要生成两万 token 的方案，可能输给 45 tokens/s、三千 token 就完成任务的方案。对本地部署者，更实用的指标是“每小时成功完成的任务数”，再结合答案质量和人工返工率。
把硬件成本放进来，可以再写一层：每小时成本由设备折旧、电力、机房与运维构成；每任务成本等于每小时成本除以同期成功任务数。MoE 若让八卡节点在低并发下长期空闲，即使单 token 浮点运算较少，折旧仍按整台机器计时。稠密 27B 若能在单卡持续服务，峰值能力可能低一些，利用率和维护复杂度却更友好。团队内部离线批处理通常能积累大批量，MoE 的优势较容易兑现；个人交互、请求稀疏且长度波动大时，低固定成本往往更重要。
多卡MoE把互连写进成本公式
总权重放不进单卡后，部署方式会改变速度。张量并行把矩阵切到多卡，层内需要集合通信；专家并行把不同专家分给不同 GPU，token 经路由后执行 dispatch，计算完成再 gather。Dots 的官方单机方案同时使用 TP=8、EP=8，并采用 DeepEP/DeepGEMM 一类专用后端。vLLM 配方还指出，DP+EP 会在各数据并行 rank 复制非专家权重，吞吐可能提高，容量占用也更高。
专家并行在每个 MoE 层都可能触发 all-to-all。热门专家集中到某张卡会形成尾部延迟，PCIe 拓扑、NVLink 带宽、NUMA 配置和通信内核都会进入结果。八张卡的显存总和只回答“装不装得下”，无法保证高效运行。消费级多卡机器缺少高速卡间互连时，16B 激活量带来的算力优势可能被通信吃掉。
因此，MoE 改写后的本地推理成本可以概括为四本账：总参数决定最低容量，激活参数影响前向计算，注意力结构和上下文决定 KV cache，路由与互连决定多卡利用率。再往上还要计算设备折旧、电费、软件维护和失败重试，并除以并发下成功完成的任务数。
Dots3-note 展示了一条鲜明路线：用 280B 级参数库换取 16B 级稀疏计算，同时借助混合注意力、FP8 和专家并行控制服务成本。它没有把 280B 模型变成单卡 16B 模型。Qwen3.8-27B 的路线更适合工作站：参数库小得多，全部激活，但通过线性注意力、GQA、量化和 MTP 缩减长上下文与解码开销。选型时先问四个问题：权重能否常驻，目标上下文能开多少并发，单任务会消耗多少 token，现有互连能否承受路由通信。回答完这些，参数规模才会重新变成一个有用的数字。
来源
- dots studio，dots3-note Preview 模型卡与
config.json：https://huggingface.co/dots-studio/dots3-note-prev - dots studio，官方代码仓库：https://github.com/studio-dots-ai/dots3-note-prev
- vLLM Recipes，dots3-note-prev 部署配方：https://recipes.vllm.ai/dots-studio/dots3-note-prev
- SGLang，Dots3-Note 部署说明：https://github.com/sgl-project/sglang/blob/main/docs/cookbook/autoregressive/RedNote/Dots3-Note.mdx
- Qwen，Qwen3.8-27B 模型卡与
config.json：https://huggingface.co/Qwen/Qwen3.8-27B - vLLM Recipes，Qwen3.8-27B 部署配方：https://recipes.vllm.ai/Qwen/Qwen3.8-27B
- Mistral AI，Mixtral of Experts：https://arxiv.org/abs/2401.04088
- NVIDIA，Large MoE Expert Parallelism 技术文章：https://developer.nvidia.com/blog/scaling-large-moe-models-with-wide-expert-parallelism-on-nvl72-rack-scale-systems/