Xiaohongshu’s 280B Model Runs on Ascend on Day One

Xiaohongshu’s newly open-sourced multimodal large model was already running on Ascend the day it was released.

On August 14, Xiaohongshu’s dots model lab released the first open-source version in the dots3 series, dots3-note preview. Huawei then announced on August 15 that its Ascend Atlas 800 A3 and Atlas 900 A3 SuperPoD systems had completed full adaptation for the model, with deployment and inference support provided through vLLM Ascend.

This adaptation goes beyond simply enabling the language model backbone to load. According to information disclosed by Huawei, the text, image, and audio processing pipelines for dots3-note preview are all operational. The vision encoder, audio feature extraction module, and LLM backbone can perform end-to-end inference in an Ascend environment. Dedicated optimizations have also been implemented for MoE communication and incremental decoding.

For developers, what truly matters is not another slogan about “adapting a domestic model to domestic chips,” but two more specific questions: Can a 280B-parameter multimodal MoE model be deployed reliably, and is the vLLM ecosystem on Ascend beginning to keep pace with new model releases?

280B Total Parameters, but Only 16B Activated per Token

dots3-note preview is an MoE model with 280B total parameters, approximately 16B of which are activated during each forward pass. It supports text, vision, and speech inputs. The model offers a context window of up to 512K and is optimized for complex reasoning, agents, and long-horizon open-ended tasks.

The 280B/16B figures can easily be misunderstood.

Having 16B activated parameters means that each token does not pass through all 280B parameters. Instead, the router selects only a subset of experts to participate in the computation. Its theoretical compute per token is therefore closer to that of a dense model in the tens-of-billions-of-parameters range than to a full 280B dense model.

However, this does not mean that a card capable of running a 16B model can also hold dots3-note preview.

The model weights still need to be placed in device memory or distributed across multiple compute nodes. Deployment teams must still address the storage, loading, expert parallelism, and inter-device communication challenges associated with hundreds of billions of parameters. MoE reduces “how much is computed each time”; it does not directly reduce “how many weights must be stored” to 16B.

This is also why the Ascend adaptation focuses heavily on communication and fused operators. For a model of this kind, matrix computation is not the only bottleneck. Once experts are distributed across different devices, token routing, dispatch, aggregation, and synchronization under tensor parallelism can all leave chips waiting on the network.

Put simply, MoE is like a company with 2,800 employees that assigns only 160 people to each task. The challenge is not merely how quickly those 160 people work, but also how to find them, deliver the necessary materials, and collect their results in time.

The Key to This “Full Adaptation” Is Preserving Multimodality

Hardware adaptation for large models typically comes in multiple levels.

At the most basic level, the weights can be loaded and text input can produce output. The next level optimizes commonly used operators so that the model can run reliably at acceptable throughput. For models such as dots3-note preview, adaptation must go further by addressing the vision and audio encoders, cross-modal projection, long-context caching, and MoE parallelism strategies.

Huawei is emphasizing end-to-end, all-modality adaptation in this release. Based on vLLM Ascend, the current inference pipeline can be summarized as follows:

Text ───────────────────────────────┐
Images / video frames → Vision encoder ─┼→ Multimodal representations → MoE LLM backbone → Output
Audio → Audio feature extractor ────────┘

This is more valuable than merely having the language backbone up and running.

Multimodal model deployments often face an awkward situation: the official model supports images and audio, but a third-party inference backend implements only the text interface, or the vision encoder still has to run on a separate set of devices. As a result, the model may technically be considered adapted, while the actual product must maintain multiple runtimes, with data transfers and interface conversions adding even more latency.

This Ascend adaptation places visual encoding, audio processing, and LLM inference within the same vLLM Ascend deployment pipeline. At the very least, this shows that it is not a “partially adapted version” intended only to demonstrate text-based question answering. For applications such as content moderation, video understanding, voice notes, and multimodal search, this is more practical than a few additional points on text benchmarks.

FlashComm: Reducing Redundant Work Across Devices

The first core optimization disclosed by Huawei is FlashComm.

In multi-device tensor parallelism, AllReduce aggregates partial computation results from different devices. A conventional pipeline often completes the full AllReduce first, after which every device performs operations such as RMSNorm, dynamic quantization, or MLA QKV dimensionality reduction. The issue is that some of these operations are independent along the column dimension, meaning that each device may redundantly process data that has already been synchronized.

vLLM Ascend addresses this by splitting AllReduce into two stages—ReduceScatter + AllGather—and moving column-wise independent operators between the two communication stages.

This changes the original process from “everyone first copies the complete set of materials from one another and then processes it independently” to “each person first handles their assigned portion, and the pieces are assembled at the end.” The mathematical result remains unchanged, but redundant computation across devices is reduced, while creating room to overlap communication with computation.

For a 280B MoE model, optimizations of this kind are often more important than simply increasing the peak performance of a matrix multiplication operator. Once a model spans multiple machines and devices, end-to-end latency becomes increasingly affected by the communication topology. Even with ample compute capacity, a poorly arranged communication pipeline can still leave devices stalled while waiting for data.

FUSED_MC2: Compressing the Fragmented MoE Pipeline into One Large Operator

The second optimization is FUSED_MC2 communication-compute fusion.

An MoE layer typically includes token dispatch, expert matrix multiplication, activation functions, a second matrix multiplication, and result combination. Without fusion, these steps invoke multiple kernels separately and continuously generate and read intermediate tensors.

Huawei has enabled the dispatch_ffn_combine fused operator, combining previously separate stages such as dispatch, gmm1, swiglu, gmm2, and combine into a larger execution unit.

This delivers three main benefits:

• Fewer kernel launches, reducing scheduling overhead for large numbers of small tasks;
• Deeper pipelining of communication and computation, preventing devices from repeatedly sitting idle;
• Keeping intermediate tensors on-chip or within the compute pipeline wherever possible, reducing repeated writes to and reads from high-bandwidth memory.

This kind of fusion does not change the model’s capabilities, but it directly determines whether the model can provide online services at a reasonable cost. In latency-sensitive agent scenarios with small batch sizes in particular, the overhead of fragmented kernels cannot easily be amortized across a large batch, making operator fusion more effective.

MTP Addresses the Latency of Generating Output One Token at a Time

The third optimization is native support for MTP speculative decoding.

During generation, large models usually operate autoregressively, one token at a time: they first generate one token, then use it as input to generate the next. Even after the initial prompt has been processed, the model must still perform a forward pass for every output step.

MTP proposes multiple candidate future tokens in a single forward pass, then verifies them and reuses the accepted candidates. If the candidate acceptance rate is sufficiently high, the model no longer needs to perform a complete decoding pass for every token.

This primarily improves TPOT, or time per output token. For long responses, code generation, and agents that need to invoke tools repeatedly, TPOT often has a greater impact on the overall experience than time to first token.

However, speculative decoding does not guarantee acceleration under all conditions. Actual gains depend on candidate acceptance rates, concurrency levels, sequence lengths, and scheduling strategies. Huawei has stated only that generation efficiency has improved, without disclosing specific throughput, latency, or test configurations. The engineering direction is therefore sound, but the available information is not yet sufficient to determine how much faster an Ascend deployment is than other hardware solutions.

Why Xiaohongshu Is Building a Long-Horizon Agent Model

dots3-note preview is not positioned as yet another general-purpose chatbot. Instead, it focuses on long-horizon, open-ended tasks such as travel planning, wedding preparation, business decision-making, game strategy, and end-to-end software engineering.

These tasks differ from math problems. Math problems usually have clear answers, making it relatively easy to determine whether a model is right or wrong. Travel planning, by contrast, requires simultaneous consideration of budgets, schedules, transportation, preferences, and real-time information. The plan may also need to be revised repeatedly as the user adds new constraints.

Such tasks test more than one-off reasoning ability. They also examine:

1. Whether the model can break down an ambiguous objective into executable steps;
2. Whether it can retain context and state over extended runs;
3. Whether it can replan after a tool call fails;
4. Whether it can build a unified understanding of images, speech, and web content;
5. Whether it can continuously check its intermediate conclusions instead of proceeding ever further down the wrong path.

Xiaohongshu has previously open-sourced text, OCR, and visual understanding models. dots3-note preview adds the complex agent layer. Given Xiaohongshu’s large volume of image-and-text posts, videos, and lifestyle decision-making content, this direction is unsurprising. Compared with simply chasing code and math benchmark scores, travel, consumer decisions, local business discovery, and lifestyle planning are also more closely aligned with its own data and product scenarios.

Long-horizon agents, however, represent one of the most difficult model capabilities to evaluate today. A model completing a complex task once in a demonstration does not mean it can operate for hours in production with a consistently high success rate. The longer the task, the more likely any intermediate misjudgment, tool failure, or context contamination is to be amplified in subsequent steps.

The official claim that the model is “on par with excellent larger models” should therefore be viewed for now as a preview of its capabilities rather than a settled product conclusion. The “preview” suffix also indicates that the model is still awaiting community validation and further refinement.

Day-Zero Adaptation Matters, but a Performance Table Is Still Missing

Completing adaptation on the same day as the model’s release suggests that Xiaohongshu, Huawei, and vLLM Ascend had likely coordinated in advance. It also indicates that Ascend’s software stack is beginning to proactively keep pace with new models instead of adding the necessary operators months after release.

This is a positive signal.

In the past, the most common problem when deploying new models on domestic compute hardware was not that the chips were entirely incapable of running them. Rather, new attention architectures, quantization formats, MoE routing mechanisms, or multimodal components had not yet been integrated into the inference framework. Development teams had to modify model code, implement missing operators, and tune parallelism strategies themselves, potentially making the deployment cycle longer than the business validation cycle.

Same-day adaptation through vLLM Ascend at least lowers the engineering barrier for Ascend users wishing to test new models. Enterprises that have already purchased Atlas 800 A3 or Atlas 900 A3 SuperPoD systems, in particular, do not need to maintain a completely separate inference service merely to evaluate dots3-note preview.

But “day zero” proves only speed—not performance.

The currently available materials do not provide the following key data:

• Time to first token and TPOT under different parallel configurations;
• Throughput scaling across a single device, a single server, and SuperPoD-scale deployments;
• Device memory usage for text, image, and audio inputs;
• KV cache capacity and concurrency limits with a 512K context;
• Accuracy loss under BF16, FP8, or other quantization schemes;
• Apples-to-apples comparisons of performance, power consumption, and cost against other hardware and inference backends.

Without these figures, developers can confirm that “it runs,” but they still cannot determine whether “it is worth running.” For production deployments, the latter question is often more important.

A Preview Worth Testing—but Not Judging by Parameter Count Alone

Overall, the most compelling aspect of dots3-note preview is not the eye-catching total parameter count of 280B, but the fact that a 16B-active MoE architecture, multimodal input, a 512K long context, and long-horizon agent positioning have all been combined in a single open-source model.

Ascend’s same-day adaptation addresses the other side of the equation: after the model is open-sourced, domestic compute users do not have to build the multimodal and MoE inference pipelines from scratch. FlashComm, FUSED_MC2, and MTP also target real bottlenecks rather than stopping at basic compatibility that merely allows the model to load.

Our assessment is: This is an adaptation with meaningful engineering depth, but it is not yet a performance showcase with a clear winner.

What is truly worth watching next is whether Xiaohongshu releases more complete training and evaluation details, whether the community can reproduce its long-horizon agent performance, and whether Huawei provides benchmark data across different cluster scales. Only if its throughput, latency, and stability can withstand production traffic will dots3-note preview have the potential to evolve from an ambitious open-source preview into a multimodal agent foundation that enterprises are willing to deploy for the long term.

References

• ITHome: Huawei Announces Day-Zero Ascend Adaptation for Xiaohongshu’s Latest Open-Source Large Model, dots3-note preview — Includes details on model parameters, supported hardware, and optimizations such as FlashComm, FUSED_MC2, and MTP.
• Hugging Face: dots3-note preview Model Repository — Access point for model weights, configuration, and community deployment information.