Meituan’s LongCat-2.0 is a hardware story disguised as a trillion-parameter model launch

Meituan announced LongCat-2.0 on 30 June and followed with an open-source release on 6 July. The current repository describes a 1.6-trillion-parameter model with about 48 billion activated per token, trained and deployed at scale on alternative AI accelerator systems. The wider story is the attempt to make architecture, software and hardware work as one design.[1][2][3]

That matters because a model does not run on a specification sheet. Its parameters must be stored somewhere; information must move between memory and processors; requests arrive at different lengths and in different numbers. A theoretical reduction in arithmetic can be valuable, but it does not automatically reduce every source of waiting time.

Sparse computation still needs a large library

The distinction between total and active parameters is easiest to see through storage arithmetic. Using the published headline size, 1.6 trillion values at two bytes each would occupy 3.2 trillion bytes, or 3.2 decimal terabytes. That is a simplified weight-only calculation, not a measured installation footprint. It excludes additional tensors, caches, working space and software overhead.

Performing the same multiplication on 48 billion active parameters gives 96 billion bytes. That smaller number does not mean the whole model can be served from a 96-GB weight store. Different tokens can require different parts of the model. Those parts must remain available somewhere, with a strategy for moving or distributing them.

Meituan’s open-release description highlights a 135-billion-parameter n-gram embedding component alongside the expert architecture. This provides another form of sparse capacity. It is a reminder that two models with the same total parameter count need not organise, access or use those parameters in the same way.[2]

The attention mechanism is also a memory-access design

The repository describes three ingredients in LongCat Sparse Attention: selecting information in a way that favours hardware-friendly access, sharing indexing work across layers, and narrowing candidates through a coarse-to-fine selection process. These address how information is found and moved, rather than merely adding more computational units.[3]

The general engineering intuition is straightforward. Reading a sequence of adjacent locations can be easier to organise efficiently than collecting many scattered pieces. Reusing a selection can avoid recomputing it. A preliminary search can reduce the candidates that need expensive examination. Whether these savings translate into faster service depends on the actual request pattern and implementation.

A long-context batch of document analyses is therefore not the same workload as a stream of short interactive chats. The first may spend substantial effort processing the initial input; the second may be dominated by repeated output steps or queueing. A deployment report should separate those phases instead of presenting one throughput number as the experience every user will receive.

Open weights do not erase systems engineering

The current repository links a GPU deployment cookbook and an NPU serving implementation. It releases weights under MIT and notes that the model has not been comprehensively evaluated for every downstream use. Those are concrete starting points for experimentation, not a guarantee that a particular organisation can operate the model economically.[3]

The SGLang cookbook supplies model-specific serving guidance. That specificity matters: a recognised architecture, suitable kernels and matching software versions can determine whether a checkpoint loads correctly and runs efficiently. Having the weights is one requirement. Having a working, maintained execution path is another.[4]

For many teams, a hosted evaluation is the sensible first experiment. It can answer whether the model performs useful work before anyone commits to a large serving installation. A self-hosted trial becomes more meaningful once the target workload, required data controls and acceptable response time are already known. That is a proposed sequence of decisions, not a claim that one commercial arrangement is cheapest.

The important competition is over usable alternatives

Our reading of LongCat-2.0 is that its architectural ambition extends beyond another large open checkpoint. The release demonstrates a concrete effort to support frontier-scale development and deployment through a broader hardware ecosystem. The durable question is whether that produces reliable, maintainable options for real workloads, rather than an isolated demonstration.

A buyer should ask for completed work, measured latency, observed memory use and the operational effort required to keep the service healthy. A trillion-parameter label is a description of scale. A functioning alternative is a system that continues delivering correct results when the queue is busy, the context is long and the next software update arrives.

Report an error or suggest a correction