GLM 5.1 算力告急：智谱服务几乎不可用，低价策略反噬开发者体验

After the launch of Zhipu GLM 5.1, it has continuously faced insufficient computing power, with many developers reporting that model requests freeze and are almost unusable. The low‑price strategy attracted users, but they weren’t prepared with enough GPUs — this debt will have to be repaid sooner or later.

Zhipu’s GLM 5.1 has recently run into trouble.

It’s not that the model’s capabilities are at fault — it’s that it’s basically unusable. Over the past week, developer communities have been flooded with complaints about GLM 5.1 “freezing” and “producing no tokens.” Some developers tested it continuously for days—during peak hours, off hours, weekdays, and weekends—and all reached the same conclusion: not a single complete request could finish.

This isn’t an isolated incident but a systemic computing power crisis.

What Exactly Happened

The story begins with the release of GLM 5.1. In February this year, Zhipu launched the GLM-5 series. Thanks to strong performance and an aggressively low pricing strategy, it quickly attracted a wave of developers. GLM 5.1, as a follow-up iteration, further improved its capabilities and carried high expectations from the community.

But problems soon followed.

Starting in mid-April, developer communities such as linux.do began seeing numerous feedback posts. One developer’s comment was especially representative:

“I’ve tested it for several days straight, peak hours or not, even on Sunday, and it’s unusable. Not exaggerating—can’t complete even a single request, it just freezes. I’ve given up on GLM.”

This isn’t simply a case of “a bit slower sometimes.” It’s effectively service unavailability. For developers who have integrated GLM 5.1 into production workflows, this means the entire pipeline is broken.

Screenshot of a developer community discussion thread about GLM 5.1 service unavailability

How Big Is the Compute Shortfall

Some technically-minded members of the community did the math — which quickly explains why Zhipu is in trouble.

A full-scale GLM 5.1 deployment requires at least 16 H200 GPUs. What does that mean? At current market prices, a single H200 costs around $30,000–40,000. Sixteen cards mean nearly $500,000 in hardware — and that’s for just one inference instance.

How many users can one instance serve? Developers estimate that for continuous, compute-heavy tasks like Vibe Coding, a single instance can handle only 10 to 20 users simultaneously. Supporting more concurrency requires scaling up exponentially.

Even if FP8 quantization is used to reduce memory footprint, it only saves the equivalent of one server (8 GPUs) — nowhere near a “50% cut.” In other words, quantization isn’t a silver bullet; the costs don’t fall much.

Let’s roughly estimate: if Zhipu wants to serve 1,000 active API users concurrently (a reasonable figure for an ambitious model platform), and each instance supports 20 users, that means 50 inference instances — 800 H200s in total. GPU purchase costs alone exceed $24 million USD (about 170 million RMB). And that’s not counting servers, networking, electricity, datacenter, and operations staff.

And you can’t just go out and buy H200s easily. In today’s global AI compute arms race, Nvidia’s high-end GPU supply chain remains tight. The combined capital expenditure of the tech “Big Four” is projected to hit $660 billion USD by 2026, with much of the available compute already locked up by top players — leaving little room for smaller companies.

The Sweet Trap of Low Pricing

Once you understand the deployment cost, Zhipu’s pricing strategy becomes clearly problematic.

As someone in the community put it bluntly: “It’s obviously a loss-making price. You know it’s unsustainable, and you know it’s just to rack up users and seek funding later.”

This is a typical playbook in China’s AI sector over the past two years — acquire users at below-cost pricing, grow the user base and API calls, then show investors the nice growth curve to raise money. The logic is sound, but the execution has one fatal prerequisite: you must have enough compute power to handle the incoming users.

Zhipu clearly underestimated this factor — or rather, made an overly aggressive tradeoff between “burning money for user acquisition” and “compute capacity reserve.” They spent more budget subsidizing prices instead of expanding GPU clusters.

The result: users came, and the servers couldn’t handle the load.

What frustrated developers even more was how Zhipu handled the aftermath. Some users reported that after the service issue occurred, Zhipu modified plan terms, which the community perceived as “baiting users with low prices and then changing the rules once the system collapsed.” One developer commented sharply: “It’s like scolding your users like dogs.”

For comparison, Kimi (from Moonshot AI) charges much higher prices than Zhipu, and its model is larger, but the community has seen almost no similar waves of complaints. The reason is simple: rational pricing brings in enough revenue to sustain compute, ensuring service stability. A pricier but usable model is always better than a cheap one that doesn’t work.

It’s Not Just Zhipu’s Problem

Taking a broader view, GLM 5.1’s compute crisis reflects a structural contradiction across China’s entire large model industry.

Over the past year, the domestic LLM race has seen a brutal price war. From Baidu’s Ernie, Alibaba’s Tongyi, to Zhipu, Moonshot AI, and DeepSeek — nearly every player has been competing on who can go cheaper. Some have gone fully free; others priced tokens so low they’re practically negligible.

But model inference isn’t software replication — its marginal cost never approaches zero. Every API call consumes real GPU compute; every token rendered burns power and memory. When prices drop below cost, more users mean deeper losses — and service quality inevitably suffers.

This differs fundamentally from the subsidy wars in ride-hailing or bike-sharing, where marginal costs shrink as scale grows. The cost curve for LLM inference flattens much more slowly. Engineering optimizations such as KV caching, speculative decoding, and batch optimization can shave costs, but not nearly enough to offset the losses of “90%-off promotions.”

Oracle’s recent layoff of 30,000 staff illustrates this point from another angle: AI infrastructure requires massive capital investment. Oracle plans to invest $156 billion USD in AI infrastructure — roughly equal to its total net profit over the past three years. If a $6 billion–a-year profit giant has to “clean house” to fund AI compute, imagine the pressure on domestic startups.

What Developers Should Do

If you’re using GLM 5.1’s API, or considering integration, here are some practical tips.

First, do not put your production environment on a single model. This is old advice but worth repeating — the GLM 5.1 incident proves why. Model service stability depends on many factors — compute, funding, operations strategy — and failure in any link can bring downtime. Prepare a fallback and at least one alternative model.

Second, beware of “too cheap” pricing. If an API is priced far below comparable models, it’s likely running at a loss. Such services usually end in one of two ways: a price hike or degraded performance — both are risks for dependent developers.

Third, assess actual usability, not just benchmarks. GLM 5.1 performs decently on benchmarks, but high scores aren’t the same as “can reliably finish a request.” When evaluating models, look not only at the capability ceiling but also at the service floor — can it still work in the worst case?

Fourth, consider using model aggregation services to spread risk. Through platforms that support multiple models, fluctuations in a single provider won’t hurt you as much. For example, platforms like OpenAI Hub allow a single key to access GPT, Claude, Gemini, DeepSeek, and other major models — you can quickly switch when one fails instead of being held hostage by one vendor.

Fifth, if you have self-hosting capability, the GLM series being open source means private deployment is an option. But as shown above, a full deployment isn’t cheap. For smaller teams, consider quantized versions or smaller-parameter variants to find a balance between cost and performance.

What Zhipu Might Do Next

Zhipu doesn’t have many options left.

The most direct route is scaling up — buying more GPUs and deploying more inference instances. But that requires both money and time; GPU procurement isn’t quick, and deployment/debugging also takes time. In the short term, service quality might not improve dramatically.

Another option is raising prices — adjusting rates to cover real costs, using revenue to fund compute expansion. But that risks user loss, especially those drawn in by low pricing. And judging from community sentiment, developers dislike “bait-and-switch” moves; Zhipu’s brand trust is already dented.

A third possibility is throttling — imposing stricter call limits on free or low-tier plans and prioritizing compute for paying customers. This makes business sense, but it demands very transparent communication; otherwise, it could further inflame community tensions.

Whichever route Zhipu takes, it faces the same fundamental challenge: under current funding and compute supply conditions, how to strike a sustainable balance between growth speed and service quality.

In Closing

The GLM 5.1 compute crisis isn’t an isolated event — it’s an inevitable result of China’s LLM price war entering deep waters. When everyone competes to be cheapest, the true race is about who has the deepest pockets and the largest compute capacity.

For developers, the biggest lesson may be this: when choosing an AI model service, stability and sustainability matter more than price. A cheap model that fails every few days costs far more in practice than a pricier but reliable one — because your time and your users’ patience are the most expensive resources.

Zhipu is a technically capable company, and the GLM series remains highly competitive among domestic LLMs. But technical strength and operational management are two different things. Hopefully, this compute crisis serves as a turning point — pushing Zhipu, and the entire industry, to seriously rethink one question: what’s the right path to commercializing large models?