# Chinese open-weight models in production: hosting and compliance

URL: https://infro.io/blog/chinese-open-weight-models-guide-2026
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-08-11
Last modified: 2026-10-13
Last reviewed: 2026-10-13 (next review due 2026-11-12)
Topic: Evaluation and models
Format: Guide

> Open-weight models from labs such as DeepSeek, Alibaba's Qwen team, Moonshot AI, Z.ai and MiniMax can be run by many hosts or on your own infrastructure, so where your data goes depends on the host, not the lab. As of 13 October 2026 the current releases include DeepSeek V4.1 Flash, Kimi K3, GLM-5.3, Qwen3.8 and MiniMax M3; the labs' own APIs price them per token with mechanics worth reading closely, such as DeepSeek's off-peak rate at half its peak rate. Evaluate each model on each host you would use, read each model's license, confirm what your customer contracts say about model origin, and keep a tested alternative ready.

Key takeaways:
- Open weights separate the lab that trained a model from the host that runs it; your data path is the host's.
- The same model name can behave differently on different hosts because of quantization, context limits and tool-call handling.
- The labs' own APIs price by the token, but not uniformly: DeepSeek charges half its peak rate off-peak, MiniMax M3 doubles its rate above 512K input tokens, and Kimi K3 charges for cache writes. Read the mechanics, not only the headline rate.
- Licenses differ between model families and sometimes between models in one family. Read the one attached to the exact model you deploy.
- Some customer contracts restrict model origin regardless of where inference runs. Check before you build, not during a security review.
- Evaluate per model and per host, and keep a tested alternative so a host or policy change is a routing change.

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.

| Lab | Publishes as | Current releases listed on 13 October 2026 |
| --- | --- | --- |
| DeepSeek | deepseek-ai[1] | DeepSeek-V4.1-Flash, DeepSeek-V4-Pro-0813, DeepSeek-V4-Flash-Vision-Exp |
| Alibaba (Qwen team) | Qwen[2] | Qwen3.8-2.4T-A95B, Qwen3.8-27B, Qwen3.8-Flash-Next, each with an FP8 variant |
| Moonshot AI | moonshotai[3] | Kimi-K3, Kimi-K2.7-Code, Kimi-K2.6 |
| Z.ai | zai-org[4] | GLM-5.3, GLM-5.3-Flash, GLM-5.2, with BF16 and FP8 variants |
| MiniMax | MiniMaxAI[5] | MiniMax-M3, MiniMax-M3-MXFP8, MiniMax-M2.7 |

Table: Where each family publishes weights. Check the page for the current list before choosing a model.

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.

| Model (API id) | Input | Cached input | Output | Condition on the page |
| --- | --- | --- | --- | --- |
| DeepSeek `deepseek-flash` (V4.1 Flash) | $0.30 | $0.006 | $1.20 | Peak rate; half of it off-peak[6] |
| DeepSeek `deepseek-v4-pro` | $1.32 | $0.044 | $3.96 | Peak rate; half of it off-peak[6] |
| Moonshot `kimi-k3` | $3.00 | $0.30 | $15.00 | Cache writes $3.00 (5 min) or $6.00 (1 h)[7] |
| Moonshot `kimi-k2.6` | $0.95 | $0.16 | $4.00 | —[7] |
| Z.ai `GLM-5.3` | $1.40 | $0.26 | $4.40 | —[8] |
| Z.ai `GLM-5.3-Flash` | $0.15 | $0.03 | $0.50 | —[8] |
| MiniMax `MiniMax-M3` | $0.30 | $0.06 | $1.20 | Up to 512K input tokens; $0.60 / $0.12 / $2.40 above[9] |
| MiniMax `MiniMax-M2.7` | $0.30 | $0.06 | $1.20 | Cache writes $0.375[9] |

Table: First-party API rates per million tokens, read on 13 October 2026. Alibaba's Model Studio pricing page did not render that day, so Qwen3.8 rates are not shown; read them for your region before estimating.

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[6]. 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[9]. 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[7][9]. 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[6], so the same request string now reaches a newer model. MiniMax offers M3 on a priority tier at 1.5 times standard[9]. 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](https://infro.io/blog/open-weight-model-hosting-consistency).

## 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[10].

## 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](https://infro.io/blog/evaluate-llms-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.

|  | A host's API | Self-hosted |
| --- | --- | --- |
| Data path | The host's infrastructure and its retention policy | Infrastructure you control |
| Cost structure | Per token or per request, with no idle cost | Fixed accelerator and operations cost, whether traffic arrives or not |
| Capacity | The host's allowance for your account | What you have provisioned, and how fast you can add more |
| Model versions | The host decides when a new version or quantization is served | You decide, and you do the upgrade |
| Operations | Monitoring the host's availability | Serving stack, scaling, patching, on-call |
| License compliance | Shared with the host, per its terms | Entirely yours |

Table: The trade-offs that usually decide between an inference host and self-hosting.

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](https://infro.io/docs/routes) 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](https://infro.io/blog/llm-routing-rules-failure-rules).
- **Keeping a family out.** A [model allowlist](https://infro.io/docs/org/model-allowlists) 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](https://infro.io/blog/estimate-llm-cost-before-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](https://infro.io/docs/observability/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.

## Sources

1. deepseek-ai organization — Hugging Face. https://huggingface.co/deepseek-ai (accessed 2026-10-13)
2. Qwen organization — Hugging Face. https://huggingface.co/Qwen (accessed 2026-10-13)
3. moonshotai organization — Hugging Face. https://huggingface.co/moonshotai (accessed 2026-10-13)
4. zai-org organization — Hugging Face. https://huggingface.co/zai-org (accessed 2026-10-13)
5. MiniMaxAI organization — Hugging Face. https://huggingface.co/MiniMaxAI (accessed 2026-10-13)
6. Models & Pricing — DeepSeek API Docs. https://api-docs.deepseek.com/quick_start/pricing/ (accessed 2026-10-13)
7. Chat model pricing — Kimi API Platform (Moonshot AI). https://platform.kimi.ai/docs/pricing/chat (accessed 2026-10-13)
8. Pricing — Z.ai Developer Docs. https://docs.z.ai/guides/overview/pricing (accessed 2026-10-13)
9. Pay-as-you-go pricing — MiniMax API Docs. https://platform.minimax.io/docs/guides/pricing-paygo (accessed 2026-10-13)
10. AI Risk Management Framework — NIST. https://www.nist.gov/itl/ai-risk-management-framework (accessed 2026-10-13)

## Revision history

- 2026-10-13: Reviewed against every source. Updated the examples to the current releases (DeepSeek V4.1 Flash and V4 Pro, Kimi K3, GLM-5.3, Qwen3.8, MiniMax M3). Added each lab's own API rates as published on 13 October 2026, with the pricing mechanics that change an estimate: DeepSeek's peak and off-peak hours, MiniMax M3's long-input tier and priority tier, cache-write charges, and retired model ids that are now served by a newer model. Updated the INFRO section: Moonshot AI, Z.ai, MiniMax and Alibaba Cloud Model Studio are now direct connections, and it now covers estimates and snapshot-change findings.
- 2026-09-11: Rewritten and retitled. The previous version's price table, context-window sizes, cost comparison and per-model quality impressions were removed because they were unsourced and time-sensitive. Replaced with dated, cited model availability and guidance on hosting, licensing, compliance and per-host evaluation.