WeChat Unveils the 617B-Parameter WeLM

Tencent’s WeChat team today announced the latest progress on its in-house large language model, WeLM: WeLM-80B, with 80 billion total parameters and 3 billion parameters activated per inference, has been deployed in WeChat’s native AI assistant, “Xiaowei.” The larger WeLM-617B is under development, with 617 billion total parameters but only 23 billion activated per inference.

The latter uses a Mixture of Experts (MoE) architecture. Its goal is not merely to upgrade the chat experience, but to handle more complex tasks within the WeChat ecosystem, including intelligent Mini Program development and “Xiaowei tool” generation.

This is the first time the WeChat team has presented WeLM’s product deployments and model scale to the public in such a comprehensive way. It is worth noting that WeLM is not a new model that appeared out of nowhere: the WeChat team has previously disclosed research on technologies including sparse MoE, post-training, and Hidden Decoding. What is new today is that the 80B version has moved beyond papers and technical blogs into a real product, while the 617B version now has a clearly defined role.

Two Versions for Two Tiers of Tasks

The WeLM specifications officially confirmed this time can be summarized as follows:

| Model | Total Parameters | Activated Parameters | Current Status | Primary Use Cases | | --- | ---: | ---: | --- | --- | | WeLM-80B | 80B | 3B | Deployed | Chat, search, invoking native WeChat features and Mini Program services | | WeLM-617B | 617B | 23B | In development | General understanding, logical reasoning, intelligent Mini Program development, and tool generation |

The most important figures for these two models are not 80B and 617B, but 3B and 23B.

WeLM-80B activates only about 3.75% of its total parameters per inference, while WeLM-617B has a similar activation ratio of approximately 3.73%. This means that as the WeChat team expands the models’ knowledge capacity, it is not allowing per-inference compute to grow linearly with total parameter count.

MoE can be thought of as a general hospital with a large number of medical specialists. The hospital may have many experts in total, but when a user asks a question, not all of them need to participate in the consultation. A router determines whether the task involves code, knowledge, mathematics, or tool use, then assigns each token to a small number of suitable experts. This allows the model to maintain a larger parameter pool while keeping the compute required for each inference relatively manageable.

Of course, “activating only 23B” does not mean its deployment cost is the same as that of a conventional 23B dense model. All 617 billion parameters still need to be stored, loaded, and distributed across multiple accelerator cards. MoE also introduces engineering challenges involving expert parallelism, inter-card communication, load balancing, and routing stability. Activated parameters determine most of the computational overhead, but total parameter count still affects memory usage, cluster size, and scheduling complexity.

A more accurate way to understand 617B-A23B, therefore, is that it uses active compute roughly equivalent to a 23B model to access an expert system with far more capacity than a 23B model—not that it somehow turns 617B into 23B.

The 80B Model Is Already Deployed—and That Matters More Than Yet Another Model Launch

WeLM-80B is already being used in Xiaowei, supporting chat and search, the use of native WeChat features, and calls to Mini Program services.

These three capabilities may sound ordinary, but within WeChat they are fundamentally different challenges.

Chat only requires the model to generate a reasonable piece of text. Search requires it to understand user intent, formulate queries, and process retrieved results. Invoking WeChat features and Mini Programs requires the model to reliably convert natural language into structured actions. If a user says, “Find the meeting address my colleague sent last week, then check whether there is parking nearby,” the task may involve searching chat history, identifying a location, using map services, and summarizing the results. A single incorrect parameter could cause the entire task to fail.

Xiaowei is therefore closer to an agent embedded in a super app than merely a chatbot. For this type of product, benchmark scores are not the only metric—and may not even be the most important one. What truly determines the user experience is:

• Whether intent recognition is reliable and can distinguish conversational requests from operational commands;
• Whether tool selection is accurate and avoids overusing external services for simple questions;
• Whether parameter generation is rigorous and complies with the field constraints of internal APIs;
• Whether multi-turn state is controllable and does not retain incorrect parameters after the user changes the requirements;
• Whether latency and cost can support WeChat-scale concurrent calls;
• Whether permission boundaries are clear and sensitive operations cannot be performed without confirmation.

The combination of 80 billion total parameters and 3 billion activated parameters is clearly designed for these high-frequency, low-latency tasks. Judged solely by activated parameter count, it is far less computationally “heavy” than some reasoning models released over the past two years. But WeChat does not need every request to “open a certain Mini Program” to trigger tens of seconds of long-chain reasoning.

From a product perspective, the approach taken with WeLM-80B is highly pragmatic: first cover high-frequency tasks with a sufficiently small activation footprint to keep response times and per-call costs under control, then hand truly complex reasoning, coding, and tool-generation tasks over to a larger model.

617B Is Not Simply a Scaled-Up 80B

The WeLM-617B model under development has approximately 7.7 times as many total parameters as the 80B version, while its activated parameter count rises from 3B to 23B—also an increase of roughly 7.7 times. The tasks assigned to it by the WeChat team have changed as well: it moves beyond invoking features to generating them.

There is an entire software engineering workflow separating “invoking a Mini Program” from “generating a Mini Program tool.”

The former involves choosing from a list of existing tools, much like finding the right app in an app store. The latter requires understanding requirements, planning interactions, generating code, connecting APIs, handling exceptions, and determining whether the resulting product can actually run. This demands stronger capabilities in long-horizon planning, code generation, logical reasoning, and tool validation.

Suppose a user asks: “Build a group event registration tool limited to 30 participants, with a waitlist and automatic reminders after registration.” The model must do more than create the interface. It must also define registration states, handle concurrent claims on limited slots, promote users from the waitlist, send notifications, and manage permissions. If any of these aspects is handled carelessly, the result will be only a demo rather than a genuinely usable Mini Program.

This is also what makes WeLM-617B more noteworthy. It targets the next layer of access within the WeChat ecosystem: instead of first searching for an existing service, users can directly describe what they need and have AI temporarily assemble or even generate a tool. If this approach works, Mini Programs could shift from a model in which “developers create them in advance and users search for them as needed” to one in which “users express a need and the model builds one on demand.”

However, WeChat has not yet disclosed WeLM-617B’s completion date, context window, training data scale, inference speed, benchmark results, open-weight plans, or API strategy. At this stage, all that can be confirmed is that it is under development. Its research goals should not be treated as product capabilities that have already been delivered.

Why WeChat Is Not Using One Model for Everything

The progression from WeLM-80B to WeLM-617B shows that WeChat is building a tiered model system rather than trying to make its largest model handle every request.

The reason is practical: given WeChat’s traffic scale, the cost of large-model inference cannot be evaluated solely in terms of an individual user’s experience. Even if a feature consumes only a small amount of additional GPU time per call, multiplying that by an enormous daily active user base and request frequency produces substantial infrastructure costs.

A more sensible architecture generally uses model routing:

1. Simple chat, rewriting, and straightforward feature calls are sent to a low-activation model;
2. Search summarization and multi-step operations receive a moderate compute budget;
3. Code generation, complex reasoning, and tool construction are escalated to the flagship model;
4. Sensitive permissions or high-risk operations introduce rule-based systems, confirmation mechanisms, and human fallback.

This is similar to how database systems do not send every query to the most expensive compute node. Requests that can be served from cache use the cache; simple queries go to standard instances; only complex analytical tasks enter high-performance clusters.

WeLM’s focus on resource efficiency is therefore well aligned with WeChat’s practical needs. For a super app, the best model may not be the one with the highest score on public leaderboards, but the one that achieves the right balance among cost, latency, accuracy, and tool-use success rate.

Hidden Decoding: Adding Compute Beyond “More Parameters”

The WeChat team has also disclosed a scaling approach this year called Hidden Decoding. Its core idea is not simply to increase the depth or width of the main Transformer architecture, but to expand each token into multiple hidden streams in latent space, enabling additional internal computation.

Traditional scaling commonly takes three forms: increasing parameters, increasing training data, and increasing the amount of reasoning performed at inference time. Hidden Decoding attempts to provide a fourth control: giving each token multiple hidden representations inside the model, then using those representations for subsequent computation.

This is somewhat like maintaining multiple lines of internal reasoning in parallel instead of keeping only one sheet of scratch paper for a problem, then consolidating them into the final output. The number of tokens visible to the user may not increase, but the model allocates more internal compute to each token.

WeChat previously presented research results for standard and HD4 variants, with HD4 indicating that hidden computation was expanded into four streams. It is important to emphasize that today’s announced specifications for the 617B product do not explicitly state whether the final deployed version will use HD4, nor do they provide product-level test data. Hidden Decoding represents a technical direction being explored by the WeLM team and should not be equated directly with capabilities already available in production.

Even so, this approach is particularly interesting when considered alongside MoE: MoE expands the “pool of available experts,” while Hidden Decoding increases the “internal computation per token.” The former addresses model capacity, while the latter attempts to deepen the reasoning performed for each token. The WeChat team clearly intends to do more than simply keep increasing parameter counts—it wants to allocate more effective computation within a limited inference budget.

The Real Test Lies in the System, Not the Parameter Table

WeLM-617B’s 617 billion parameters are certainly eye-catching, but WeChat’s greatest challenge is not training a large model. It is integrating that model into a complex ecosystem encompassing chat, payments, Mini Programs, Official Accounts, Channels, and enterprise services.

A model may generate the correct function call, but that does not mean the system should execute it immediately. Operations involving sending messages, creating group chats, submitting forms, accessing location data, or making payments require explicit permission controls and user confirmation. Once an agent gains the ability to perform real actions, an incorrect output is no longer merely a “wrong answer”; it can become a real-world erroneous operation.

Generating Mini Program tools also raises issues involving code security, dependency governance, and runtime isolation. Whether model-generated code calls unauthorized APIs, contains injection vulnerabilities, or can pass static analysis and sandbox testing must all be handled by engineering systems outside the model itself.

Our assessment of WeLM is therefore that its direction is sound and better aligned with WeChat’s strengths than simply releasing a general-purpose chat model. But whether 617B proves genuinely useful will depend on whether it can achieve a high success rate on complex tasks—not on whether its total parameter count exceeds those of competing models.

The next things developers should watch are not another set of leaderboard rankings, but these four issues:

• WeLM-617B’s actual activation latency and inference throughput;
• Whether Mini Program generation includes a closed loop for testing, debugging, and automatic repair;
• Whether WeChat will open model or agent interfaces to third-party developers;
• How permissions, auditing, and sandboxing will be designed for tool use.

WeChat has not yet announced a WeLM API for external developers, nor has it announced plans to release the weights of the 80B or 617B models. This announcement is therefore more of a disclosure of product and technical direction than a model launch that developers can immediately integrate. Teams hoping to call WeLM directly will still need to wait for WeChat to provide details on interfaces, pricing, quotas, and service agreements.

WeChat Is Building Its Own Model Foundation

Tencent already has Hunyuan as its general-purpose model brand, but WeChat has nevertheless chosen to continue developing WeLM. This indicates that the requirements a super app places on a model are not entirely the same as those of a general-purpose cloud service.

Hunyuan serves a broad range of industries and external customers and must cover many standardized scenarios. WeLM, by contrast, can be deeply optimized around WeChat’s internal tools, users’ communication habits, and product workflows. It does not necessarily need to lead on every public benchmark, but it must better understand which capabilities are available within WeChat, when to invoke them, and how to complete tasks at the lowest possible cost.

The 80B version is already live, demonstrating that WeLM has at least completed the crucial journey from training to product deployment. The 617B version represents WeChat’s bet on more sophisticated agent capabilities.

The real signal in this announcement is not that “WeChat also has a 600B model,” but that WeChat is turning large models into its own operational layer: the 80B model understands and invokes existing services, while the 617B model aims to understand, combine, and even generate new services.

If the end result is merely that Xiaowei becomes better at chatting, the significance of 617B will be limited. If it can reliably transform a natural-language request into a runnable, auditable Mini Program tool, then WeChat’s investment in AI will truly have entered deep waters.

References

• ITHome: Tencent WeChat Unveils WeLM Models; 80B Version Already Used in Xiaowei, 617B Version Under Development — A summary of the model specifications, deployment status, and target application scenarios announced by the WeChat team on August 13, 2026.