微信小微如何從聊天助手走向生態系統的 AI 操作層？

微信小微值得關注的地方，不在於它又多了一個聊天機器人，而在於它被放進了微信原本的使用情境之中：使用者可用文字或語音呼叫小微，與聯絡人溝通，並啟動小程序，而不必離開微信、另開一個獨立 AI 應用程式。15

換句話說，微信想做的可能不是再打造一個與 Yuanbao 等獨立 AI 應用競爭的入口，而是讓 AI 成為連接人、服務與小程序的自然語言介面。

從 2022 年 WeLM，到驅動小微的 80B 模型

WeLM 的技術脈絡可追溯至 2022 年發表的 100 億參數中文模型。相關資料稱，早期模型在 18 項任務上有不錯表現，建立了 WeLM 的發展起點；不過，本文未能從已取得的來源獨立核實這些具體基準測試數字。

目前較明確的產品化進展是 WeLM-80B。這個模型共有 800 億參數，但每個 token 推理時約啟用 30 億參數；模型以少於 14 兆個 token 的資料訓練，並被報導具備推理、多語言理解與 128K 上下文能力。711

據報導，WeLM-80B 已部署於微信原生 AI 助手「小微」，支援對話、搜尋、呼叫微信原生功能，以及啟動各類小程序服務。89 目前小微仍處於小範圍灰度測試階段，並非所有使用者都能使用。

WeLM-617B：更大的模型，但尚未全面部署

WeLM-617B 延續了稀疏 MoE 的基本思路，總參數達 6170 億，但每個 token 約啟用 230 億參數。它目前仍被描述為開發中，不能視為已經完整部署到小微的正式版本。8912

其定位也不只是提升一般問答能力，而是處理微信生態系統內更複雜的工作，包括更強的通用理解與邏輯推理、智能小程序開發，以及為小微自動生成配套工具。8912

這代表 WeLM 可能形成一種按任務分工的模型層級：WeLM-80B 負責頻繁、即時、相對標準化的互動；更大型的 WeLM-617B，則瞄準多步驟規劃、程式生成與工具建構等高複雜度工作。

為什麼「總參數」不是唯一重點？

稀疏混合專家（Mixture of Experts，MoE）模型可以想像成一個由多組專家組成的模型庫。路由器會依據每個 token 的內容，只選出少數專家參與運算，而不是每次都啟用整個模型。

因此，WeLM-80B 雖然擁有 800 億參數的容量，單一 token 的主要計算路徑卻更接近 30 億個啟用參數；WeLM-617B 也不需要在每個 token 上完整執行 6170 億參數。這種設計可在保留較大模型容量與專業化能力的同時，降低每次推理的運算量。78

對微信這類需要處理大量日常請求的平台而言，這一點尤其關鍵。搜尋、傳訊息、尋找服務、呼叫工具等任務，單獨看未必需要最昂貴的模型，但請求頻率可能非常高。較低的啟用計算量，有助於提升吞吐量、降低延遲與服務成本，讓 AI 更有機會支撐大規模使用。

不過，「每次只啟用 30 億參數」不代表 800 億參數的 MoE 模型，成本就與一個稠密 30 億參數模型完全相同。全部專家權重仍需要儲存與部署，路由、記憶體配置，以及不同裝置之間的通訊，也會帶來額外成本。稀疏化主要降低的是每個 token 的算術運算量，讓高流量推理更可行，而不是讓運算變成零成本。

Hidden Decoding：不把 Transformer 做得更深或更寬

除了擴大模型參數規模，微信 AI 團隊也在探索另一條提升能力的路線：Hidden Decoding。

傳統做法往往是增加 Transformer 的層數或寬度，但這會提高模型的參數、記憶體與運算負擔。Hidden Decoding 則把一個輸入 token 擴展成多個具有獨立嵌入的內部串流，並保留這些中間串流的鍵值（KV）狀態作為後續上下文。如此一來，每個外部生成的 token 都能獲得更多潛在計算，而不必擴大主要 Transformer 骨幹。213

在配對實驗中，團隊表示，採用四路 Hidden Decoding 的 WeLM-HD4-80B 與 WeLM-HD4-617B，都優於各自未採用 Hidden Decoding 的基準模型。112 這並不等於小微已經全面使用這些 HD 版本，而是顯示該方法在超大規模 MoE 模型上具備提升能力的潛力。

Stream-Factorized Attention 解決了什麼問題？

如果把每個 token 複製成 (n) 個串流，並讓所有串流彼此進行完整注意力運算，跨串流的注意力成本大致會隨 (n) 呈二次增長。當模型本身已達到 100B 以上的 MoE 規模時，這種額外成本很快會變得難以負擔。

Stream-Factorized Attention 的做法，是讓大部分層只在各自的串流內進行注意力計算，只在少數層允許不同串流互相混合。這讓額外注意力成本由接近二次增長，降至更接近線性增長。騰訊表示，這項系統設計是讓 Hidden Decoding 能在 100B 以上 MoE 規模下訓練與服務的關鍵之一。5

簡單來說，Hidden Decoding 增加了模型在潛在空間中的「思考步數」，而 Stream-Factorized Attention 則試圖避免這些額外步驟帶來失控的注意力成本。兩者結合，提供了不同於單純堆疊參數的擴展方向。

從 AI 應用程式，走向微信的操作層

稀疏 MoE 與 Hidden Decoding 放在一起看，可能指向一種分層運作模式：日常且高頻的互動由效率較高的 80B-A3B 級模型處理；較複雜的規劃、工具選擇、多步驟工作流程，則交由更強的模型或額外的潛在計算處理。

對使用者來說，理想情況不是「與 AI 聊完後，再自己打開另一個服務完成工作」，而是直接說出意圖，讓系統依序完成「尋找、判斷、呼叫、完成」。這些動作可以發生在既有的微信介面中，並連接其社交關係、原生功能與小程序網絡。

若權限管理、身分驗證、支付流程、小程序 API、可靠性控制與使用者同意機制都能妥善設計，小微就可能成為微信生態系統上方的一層自然語言操作介面，而不只是另一個獨立的 AI 超級應用程式。

但這最後一層是根據目前模型定位與產品整合方向作出的策略推論，並不是騰訊已確認的完整產品路線圖。小微目前仍在測試，WeLM-617B 也仍在開發中；真正能否把「理解意圖」穩定轉化為跨服務行動，仍取決於產品權限、工具可靠性、延遲、成本與安全設計。