FengHe ships a 106B weather-service model, not the warning stack

Visitors gather outside the China Meteorological Administration headquarters during its March 18, 2023 open day in Beijing. Photograph by N509FZ.[6] FengHe comes from the agency's Public Meteorological Service Center, and its intended setting is an institutional data and warning chain rather than a standalone consumer chatbot.[1][3]

On July 17, 2026, the China Meteorological Administration published the FengHe checkpoint and launched a global open-source initiative at the World Artificial Intelligence Conference in Shanghai.[1][2] At the checkpoint level, the opening is concrete. The official model card declares MIT licensing, and the repository contains configuration and tokenizer files plus 43 weight shards whose index totals 213.7 GB. This is a runnable model release, not a landing page with weights promised later.[1]

But the more important boundary is in the name. FengHe is a meteorological service language model. It is not an atmospheric forecast engine that turns observations into tomorrow's pressure, wind, and precipitation fields. It sits farther downstream, where authoritative forecasts and warnings must be retrieved, interpreted for a particular audience, converted into plain language, and sometimes connected to an operational tool.

That distinction is the release's organizing fact. As of July 22, 2026, the checkpoint is technically substantial, while the service around it still depends on data, tools, review, and publication authority that are not contained in the weights.[1]

What actually shipped

FengHe is built on GLM-4.5-Air. Its model card describes a mixture-of-experts causal language model with 106 billion total parameters, about 12 billion activated per token, 46 layers, 128 routed experts, and a 128K-token context window. The released checkpoint is predominantly BF16. The supplied examples cover Transformers, vLLM, and SGLang; the vLLM and SGLang recipes both propose eight-way tensor parallelism.[1]

The published eight-way recipe gives a rough raw-memory reference. Evenly dividing 213.7 GB of weights across eight ranks leaves roughly 26.7 GB of weights per rank before the key-value cache, activations, framework overhead, and uneven allocations. That is not a proven minimum: the model card does not publish latency, throughput, or memory measurements, so the examples are starting commands rather than a capacity plan.[1]

The domain adaptation is more revealing than the parameter count. The Public Meteorological Service Center says it added more than 50 million tokens from meteorological books, standards, warning translations, service reports, and news, then used 490,000 manually annotated, scenario-oriented instruction examples. The target abilities are requirement understanding, service-content generation, meteorological reasoning and decision support, and tool calling.[1]

The official chronology is not internally consistent on that training volume. A September 2025 registration report said 550 billion tokens, while an October 2025 agency history, the July 2026 launch report, and the current model card say roughly 50 million.[1][2][3][5] The public documents do not reconcile the figures, so this digest uses the released model card's description rather than treating corpus size as a reproducibility claim.

That is a curriculum for service work. A model asked to explain a typhoon warning to a port operator needs different language and a different action boundary from one answering a schoolchild's weather question. FengHe's release is designed around that last-mile variation.

The forecast and the service are different products

The China Meteorological Administration began the FengHe development effort in 2024 and described the system in 2025 as “1+1+N”: one domain language model, one agent platform for data access and tool use, and many scenario-specific applications. The applications named in the agency's account include public information, warning delivery, energy, tourism, and transport.[3]

The middle “1” is the key. The agent platform is meant to call upstream systems and authoritative data rather than ask the language model to invent the weather. A 2025 implementation report listed six connected data classes: current city conditions, city forecasts, warning signals, lifestyle indices, climate extremes, and global city forecasts. It also said FengHe could call the agency's FengLei nowcasting system and FengQing medium-range forecast system.[5]

In other words, the FengHe checkpoint supplies the language component of a larger translation-and-orchestration system around forecast products. A conventional weather model estimates a future atmospheric state. FengHe can take a weather state or warning produced elsewhere, combine it with a user and a task, and turn that evidence into a briefing, a risk explanation, a tool request, or suggested action; the separate agent platform supplies the live connections and workflow.

The agency's own road-trip example makes the handoff visible: given a family driving from Shanghai to Baiyangdian, the system could connect thunderstorm timing and waterlogging risk to route avoidance and an indoor alternative.[5] The language model adds audience-specific framing. The upstream forecast and risk data supply the facts.

This division of labor is also the safety boundary. A fluent answer is not evidence that the precipitation input was current, that the correct warning zone was selected, or that a local authority had issued an alert. Those facts must arrive through the surrounding data and tool layer. The open checkpoint can help write the message; it cannot authenticate its inputs by itself.

The model is open; the national service stack is not

The repository is unusually clear about the model artifact. It contains all 43 weight shards for a predominantly BF16 checkpoint, architecture configuration, tokenizer, chat template, generation settings, model card, and evaluation images. The card and repository metadata designate MIT terms, although the repository does not include a standalone LICENSE file with the full text. An outside team with sufficient hardware can inspect and serve the checkpoint; legal due diligence should preserve that documentation distinction.[1]

The same file list also shows what is outside the release. It does not contain the domain corpus, the 490,000 instruction examples, training code, the MetsEval question set, the production tool schemas, connectors to live official data, or the agent applications used by the meteorological service. The public package can reproduce inference from the model; it cannot reproduce FengHe's training run or the integrated national service system.[1][3]

That is not a semantic complaint about “true” open source. It is the practical adoption boundary. A developer can place a prompt in front of the weights today. To make a credible weather service, the developer still needs data lineage, freshness checks, geographic resolution, tool-error handling, escalation rules, and an authorized publication path.

The distinction matters internationally too. The July launch linked FengHe to the MAZU early-warning solution and described Chinese- and English-language weather queries and risk analysis for global users.[2] Model portability does not make warning authority portable. Each country and service has its own source hierarchy, alert terminology, geographic codes, and rules for who may publish what.

Read MetsEval as directional evidence

The model card evaluates FengHe on MetsEval-1k, a 1,076-question suite spanning four dimensions: service-requirement understanding, service-content generation, reasoning and decision support, and tool calling. An accompanying table reports a higher overall score for FengHe than for a set of general-purpose models.[1]

That result is directionally useful: FengHe appears well aligned with the tasks it was designed to perform. It is not yet an independently reproducible benchmark. The release does not provide the question set, prompts, judge design, model-specific inference settings, sampling policy, scoring code, or per-item outputs. Without those boundaries, the table cannot separate domain knowledge from prompt effects, judge preference, test leakage, or different tool assumptions.[1]

The next evaluation should follow the service chain rather than stop at answer quality. Does a generated advisory cite the correct source timestamp? Does the model abstain when a tool returns stale or geographically mismatched data? Can a reviewer see which observation, forecast, warning, and rule produced each recommendation? Does the system preserve the difference between an official alert and a model-generated interpretation of risk?

Those tests are harder than asking whether the prose sounds meteorological. They are also closer to the cost of a real error.

Governance is part of the architecture

China's Measures for Artificial Intelligence Meteorological Application Services took effect on June 1, 2025. They require providers to obtain meteorological data legally with identity metadata, label AI-generated content, maintain traceability, improve accuracy and reliability, and apply lifecycle risk controls. They also prohibit providers from distributing public forecasts, severe-weather alerts, or meteorological-disaster warnings that originate from stations not belonging to the meteorological authorities.[4]

That rule turns provenance into a system component. A production FengHe deployment needs more than a retrieval plugin. It needs to preserve who supplied the weather datum, what it covers, when it expires, and whether the current output is information, advice, a draft, or an authorized warning. The model card's own usage statement reinforces the line by prohibiting fake warnings and misleading meteorological information.[1][4]

For engineers, a prudent integration would separate three lanes. A conversational lane can explain official information while displaying its source and time. A decision-support lane can draft tailored guidance for a qualified reviewer. A publication lane would remain subject to the relevant authority's approval and distribution controls. Blurring those lanes would turn the language model's fluency into false institutional authority.

What would make the release easier to audit and deploy

FengHe already clears most of the basic artifact test: public weights, declared MIT terms, standard loaders, named architecture details, and a model card.[1] The next evidence should make the surrounding handoffs just as inspectable.

First, the team could release MetsEval prompts, items, judge instructions, and a replayable harness. Second, a reference agent could show the schemas for forecast retrieval, warning lookup, provenance, tool failure, and human approval without exposing sensitive production systems. Third, deployment profiles could report memory, throughput, and tail latency for the recommended tensor-parallel configuration and for any future quantized variants.

The most valuable example would be an end-to-end trace: one authoritative forecast enters with a timestamp and geographic scope; tools add a verified warning and risk layer; FengHe produces different drafts for a commuter, a school, and an emergency manager; and the system records who can approve each output. That trace would demonstrate what a benchmark score cannot—the preservation of authority as information becomes action.

FengHe's open release matters because it makes a checkpoint from a state meteorological service's language layer portable. It does not make the integrated service system portable by itself. Success should not be measured by whether the model can sound like a forecaster. The harder proof is whether every useful sentence can stay connected to the forecast, tool call, rule, and human responsibility that made it safe to say.

cronfeed.work