微信Agent「小微」的成本账，到底算不算得过来？

作者按：这篇文章试图回答一个具体问题——微信把 AI 助手铺开到十亿用户量级，这笔推理成本在商业上是否站得住脚。答案不只是"能"或"不能"，而是要搞清楚它为什么能，以及这个方案背后有什么真实代价。

一、先破一个常见误解

讨论 AI 成本，很多人下意识往最强模型上靠——似乎不用 GPT-5.5、不用 Claude Code 就算"凑合"，用了才算认真。这个直觉在研究场景里可能没错，但放到产品部署里，就容易出问题。

现实中，任务本身的复杂度差异极大。查快递单号、询问今日天气、让 AI 帮忙拟一句回复，这类请求对模型能力的要求，跟"帮我做一套完整的财务分析报告"完全不在同一个量级。前者不需要大脑，后者才需要。人类社会里，公司不会让首席分析师去接前台电话；模型调度也一样，用什么模型干什么活，本身就是一个工程判断问题，不是"谁强用谁"。

微信 Agent 的技术路线，正是建立在这个判断上的。

二、WeLM 是什么，以及为什么是它

WeLM 不是通用大模型，它是腾讯专门为微信生态打造的模型，设计目标很明确：低延迟、低成本、在微信场景下准确理解用户意图。它不对外开放，不参与通用模型的能力评测排行，也不打算跟 GPT 或 Claude 卷谁的推理更强。

这个定位听起来像妥协，但实际上是个清醒的工程选择。

场景决定需求。 微信里的 AI 交互有几个特殊约束，别的产品不一定有：

第一，用户在微信里不接受等待。 你可以忍受 Perplexity 或者 WorkBuddy 处理复杂问题时转几秒，但如果微信的"小微"回复你一条消息要思考 8 秒，体验就崩了。这不是主观感受问题，是微信作为即时通讯产品的产品基线。

第二，微信天然是长上下文场景。 群聊历史、朋友圈动态、公众号收藏、好友对话记录——用户问小微"帮我总结一下最近群里讨论了什么"，这个上下文是自动存在的，不需要用户去上传、授权或者手动喂材料。通用模型要做到这点，需要接外部工具；WeLM 生长在这个环境里，上下文已经是它的一部分。

第三，微信的日活决定了成本敏感性没有上限。 日活超 10 亿，AI 功能如果全量开放，每天的推理请求量是天文数字。单次成本哪怕高出一点点，乘以量级之后账就完全不同了。

WeLM V4 的架构选择，是混合专家（MoE），总参数 80B，但每次推理实际激活的参数量约 3B。这个数字是理解整个成本结构的关键。

三、Hidden Decoding：既要质量，又不让用户看见过程

大模型的推理质量通常跟"思考过程"正相关——让模型把中间步骤展示出来（Chain-of-Thought），答案往往更准。但展示思考过程有两个成本：时间成本和 token 成本。在微信场景里，这两个成本都是不可接受的。

WeLM 的解法叫 Hidden Decoding：模型在内部走推理过程，但不把这个过程呈现给用户，用户看到的是直接输出的结果。

这个设计的取舍值得说清楚：Hidden Decoding 不是"不推理"，它是"推理但不展示"。它保留了一部分推理质量的提升，同时把用户侧的等待时间压缩下来。代价是，推理过程本身的深度受到约束——如果一道题真的需要很长的思维链才能做对，Hidden Decoding 的收益是有天花板的。

这也是为什么需要 DeepSeek 来兜底——后文会讲。

四、成本账是怎么算的

MoE 架构的推理成本，业内通常用激活参数量作为粗略标尺：模型每次推理时实际用到多少参数，大致决定了算力消耗。WeLM V4 的激活参数约 3B，对比几个主要模型：

注：MoE 模型的显存占用取决于总参数（需要加载所有专家权重），但推理算力消耗和实际吞吐主要由激活参数决定。WeLM V4 的 80B 总参数，比 DeepSeek-V3 的 671B 小得多，所以显存压力也更低。

换一个角度看：同样一批 GPU，WeLM V4 能撑起的并发请求量，大约是混元 Hy3 的 7 倍，是 DeepSeek V4 Flash 的 40 倍以上。

对于一个日活十亿的产品，这个差距不是性能参数，是账单的数量级差距。

五、DeepSeek 兜底：这个决策比表面看起来更重要

前面说到 WeLM 在复杂推理上有天花板，小微的方案是：对这部分任务，路由给 DeepSeek 做兜底。

这个决策值得多想一层。

为什么选 DeepSeek？ 首先是能力。DeepSeek 系列在长文本、复杂推理任务上的表现有目共睹，放在国内模型里算第一梯队。其次是成本——这一点经常被忽略。

DeepSeek 自身的推理成本，在业内就是出了名的低。DeepSeek-V3 在发布时，API 定价相比同期主流模型低了一到两个数量级；DeepSeek-R1 的推理成本，比 OpenAI o1 便宜了约 96%。DeepSeek 的成本优势来自两个地方：一是 MoE 架构的稀疏激活；二是工程层面对 KV Cache 和并行推理的深度优化，使得单位算力能处理的 token 量远高于同代产品。

也就是说，小微在兜底这条路上，选的是"本身就是成本杀手"的模型。用 DeepSeek 做兜底，不是无奈之举，而是在接受更高单次成本的同时，把这个成本控制在业内已知最低的那个方案上。

频率控制是关键变量。 兜底逻辑能不能成立，核心要看有多少比例的请求会真正触发 DeepSeek。如果 80% 的请求都走 DeepSeek，那整体成本还是起来了。WeLM 的路由设计是：简单意图（占绝大多数）走 WeLM，只有长文本、多轮深度推理、需要较强外部知识整合的场景，才上 DeepSeek。从日常微信使用场景的分布来看，真正属于"复杂推理"的请求，在全量请求中占比应该是少数——大多数用户和小微的交互，还是停留在信息查询、内容摘要、简单问答这些层面。

当然，这个比例的实际数字，腾讯内部有准确监控，外部无从得知。这也是整个成本分析里不确定性最大的部分。

六、这套架构的结构性风险

上面的分析总体上支持"成本可控"的判断，但有几个地方值得留意，不应该被乐观情绪遮掉。

用户行为的漂移。 随着小微功能的推广，用户的使用习惯会变。早期用户可能只是"试试"，后期深度用户可能真的把小微当工作工具用，拿来做复杂文档分析、跨多轮对话的推理任务。如果这类用户比例增长，DeepSeek 路由的触发频率也会随之上升，整体成本结构会改变。这不是假设，是用户增长的一般规律。

WeLM 能力边界带来的体验风险。 WeLM V4 在简单任务上够用，但"够用"本身是一个会随时间变化的标准。今天用户觉得"回答质量可接受"，六个月后，当他们用过更强的模型之后，标准会拉高。届时 WeLM 处理的任务范围可能需要收窄，或者 WeLM 本身要迭代。这不是威胁，但是个需要持续投入的成本。

路由判断本身的失误成本。 一个任务该走 WeLM 还是 DeepSeek，这个判断本身有出错的概率。如果路由系统把一个需要 DeepSeek 的请求错判给了 WeLM，用户得到的是质量不达标的回答，体验受损；如果反过来，把本该 WeLM 处理的任务路由给了 DeepSeek，成本就白白高了一截。路由准确率是这套混合系统的隐性成本中心。

七、结论

微信 Agent 的成本方案，逻辑上是自洽的。核心思路是：用激活参数极低的专属模型（WeLM V4）处理绝大多数请求，用 Hidden Decoding 在不牺牲用户体验的前提下压缩推理延迟，再用 DeepSeek 这个业内成本最低的强模型处理真正复杂的少数情况。

这个方案不是"便宜没好货"，也不是"能力打折换来的低成本"。它是基于微信场景特性，对任务分布做了正确判断之后的一个工程结论——大多数任务不需要最强的模型，那就不用最强的，把钱省在该省的地方，把能力留给真正用得上的地方。

更值得注意的一点：这套方案的核心竞争力不在于 WeLM 本身有多强，而在于它扎根微信生态的信息优势——群聊、朋友圈、收藏夹这些上下文，是任何外部模型接入都无法轻易复制的，而这恰好是准确理解用户意图的关键。

成本可控，但前提是用户的使用深度不要大幅偏离当前假设，路由系统足够准确，WeLM 的迭代跟得上用户预期的变化。这三个条件目前基本成立，未来是否持续成立，要看产品和技术团队的持续投入。