Chinese open-weight models in production: hosting and compliance

Several of the most discussed model families of the past two years come from Chinese labs and publish their weights. That has made them a regular item on engineering shortlists — and a regular item in security reviews. Both conversations tend to go wrong the same way: they treat "the model" as one thing with one price, one quality level and one data path. With open weights, none of those is true.

This guide leaves quality rankings out on purpose; they depend on your task. It gives each lab's own API rates with the date they were read, because they change monthly and other hosts set their own. Most of it covers what stays true: what open weights change, why the host matters, how the labs' pricing actually works, what to check before production, and how to evaluate.

What "open weights" changes

A model with published weights can be downloaded and run by anyone the license permits: large inference providers, specialized hosts, cloud platforms, or your own servers. Three consequences follow.

1. The lab and the host are different parties. Where a lab is headquartered says nothing about where your prompts are processed. That is decided by the host you send requests to.
2. Several hosts can serve the same model. They compete on price, capacity and speed, and they make different engineering choices while doing so.
3. You can run it yourself. Self-hosting puts the whole data path inside infrastructure you control, at the cost of operating inference.

The families, as published

Each of the labs below publishes models on its Hugging Face organization page. The examples are models listed there on 13 October 2026, not recommendations.

The table contains no quality ranking. Quality depends on your task and must be measured on it. Price depends on the host, and on whether you host at all; the next section gives the labs' own API rates as one reference point.

The labs' own API rates, and how they are charged

Every lab above also sells its models through its own API. Those first-party rates are a useful reference for estimating, but they are one host's price among several, and each lab attaches conditions that change what a request actually costs. The table gives standard rates in US dollars per million tokens as each lab's pricing page showed them on 13 October 2026.

Four mechanics on those pages matter more than the headline numbers:

• Time of day. DeepSeek bills peak hours at the rates above and everything else at half of them. Peak is 01:00–04:00 and 06:00–10:00 UTC, Monday to Friday, excluding Chinese public holidays; weekends and those holidays are off-peak in full⁶. A batch job moved outside those windows halves its rate with no change of model, and an estimate that ignores the clock will read high or low depending on which rate it assumed.
• Input length. MiniMax prices M3 in two tiers split at 512K input tokens, the upper tier at twice the lower⁹. Long-context agents can cross that line mid-conversation.
• Cache writes. Kimi K3 lists a charge for writing to the cache, with a longer lifetime costing more; MiniMax lists one for M2.7⁷⁹. A cache that is written and rarely read costs more than no cache.
• Retired ids and priority tiers. DeepSeek still accepts the retired id deepseek-v4-flash, serves it with DeepSeek-V4.1-Flash and bills it at the Flash price⁶, so the same request string now reaches a newer model. MiniMax offers M3 on a priority tier at 1.5 times standard⁹. Both change behaviour or cost without a change in your code.

Other hosts serving the same weights publish their own rates, and the spread between hosts can be wider than the spread between models. Compare per host, at the context lengths and hours you actually run.

Why the host matters as much as the model

Two endpoints serving a model of the same name can behave differently. The usual reasons:

• Quantization. Labs and hosts publish lower-precision variants — an FP8 variant appears among the examples above — and a host may serve one to fit more traffic per accelerator. Lower precision can change output on the margin.
• Configured limits. A host can serve a shorter maximum context or output length than the model supports.
• Tool calling and structured output. The model produces text; the serving stack parses it into tool calls or JSON. Parsers differ, and so does their reliability on your schemas.
• Capacity and latency. Throughput and time to first token vary by host, region and time of day.

So evaluate a model on the host you will use, and repeat the evaluation if you change hosts. A worked method for checking whether two hosts serve the same weights the same way is in same open-weight model, different hosts.

Questions to answer before production

• Model origin in contracts. Do any customer, government or partner agreements restrict the origin of models you use, independent of where inference runs?
• Data path. Which host processes the requests, in which region, and what does that host retain?
• License. What license is attached to the exact model and version you deploy, and does it permit your use? Licenses differ between families and can differ between models in one family.
• Provenance. Are the weights you or your host run the ones the lab published, from the lab's own organization page?
• Behavioural review. Have you evaluated refusals, safety behaviour and tone on your own sensitive cases, not only accuracy?
• Exit. Is a tested alternative model or host ready if a policy or supply change removes this one?

Treat these as part of your AI risk management rather than a one-off procurement step; frameworks such as NIST's AI Risk Management Framework are designed for exactly this kind of recurring assessment¹⁰.

Evaluate per model and per host

Use the same method as for any model — a sample of real tasks, a pass criterion per task, repeated runs, and cost per successful task — described in how to evaluate LLMs on real workloads. Add three host-specific checks:

1. Schema reliability. Run your tool and JSON schemas many times; a small malformed-output rate at high volume is an operational cost.
2. Long inputs. Test at the context lengths you actually send, on the host's configured limits.
3. Latency under load. Measure time to first token at your real concurrency, in your region.

Hosted API or your own servers

Open weights give you a choice most closed models do not: call a host's API, or run the model yourself. The decision is mostly about who carries which cost and which risk.

Two patterns follow from those trade-offs. Spiky or modest volume favours a host's API, because paying per request avoids idle accelerators. Steady high volume, strict data-path requirements or a need to fine-tune can justify moving a workload in-house once its traffic is measured. The two also combine: a self-hosted deployment as the primary, and a host's API as the standby for capacity spikes.

A rollout plan for a first open-weight workload

1. Pick a low-risk, high-volume workload with a programmatic pass criterion — classification or extraction rather than customer-facing prose.
2. Run the evaluation on the incumbent model and on the open-weight candidate, on the host you intend to use, with your real schemas.
3. Clear the checklist above with the people who own contracts and security, in writing.
4. Send a small share of traffic to the candidate while the incumbent keeps serving the rest, and compare success rate, malformed output and latency.
5. Widen gradually, keeping the incumbent configured as the standby so a reversal is immediate.
6. Re-evaluate on every model or host change, including a host switching quantization without announcing it.

Keep the choice reversible

A decision to use an open-weight model should be easy to undo. Keep the model behind a stable name in your application, keep a second host or a different model evaluated and ready, and make moving between them a configuration change. When a host degrades or a customer's policy changes, you want to change a route, not rewrite a service.

Running open-weight hosts through INFRO

INFRO connects each lab's own API directly — DeepSeek, Moonshot AI (Kimi), Z.ai (GLM), MiniMax and Alibaba Cloud Model Studio, in the Singapore or Virginia region your key was created in — as well as hosts that serve open-weight models, such as Together AI, Fireworks AI, Groq and Cerebras, and any OpenAI-compatible endpoint, including a server you run yourself. Each is a connection on your own account, billed to you by that provider; INFRO's subscription is separate and takes no share of model spend.

• Two hosts behind one name. A route puts a self-hosted endpoint and a host's API behind one model name with a priority order or weights. Its if-rules can read hour_utc and weekday_utc, so a route can, for example, send batch traffic to DeepSeek's API outside its peak hours and elsewhere during them; they can also read input_tokens, INFRO's upper-bound estimate of the prompt size, which is how a request heading past a tier boundary such as MiniMax M3's 512K can go to another target. Rules are described in routing rules and failure rules.
• Keeping a family out. A model allowlist takes block entries: !deepseek/* keeps DeepSeek's catalog models out of a project whose contracts forbid them, including models added to the catalog later.
• Estimates. POST /v1/estimates and usage.cost on every response estimate what your provider will bill, from your own entered rate or the vendor's list rate, and say "unpriced" rather than $0 when none is known. INFRO's catalog carries DeepSeek's peak rate, so an estimate for off-peak traffic reads high, never low; DeepSeek's own invoice is the authority. The method is in estimating LLM cost before the request.
• A retired id that moved. Every request records the model you asked for, the model the provider says answered (served_model) and the provider and connection that served it. Traffic changes raises a finding when a model on a connection starts being answered by an id the provider had not reported in the previous 14 days and carries at least 20% of the day's successful requests. That catches a retired id being served by a newer model, provided the provider's response names the model that answered.