Guide
Chinese Open-Weight Models: What an MSP Needs to Know Before Saying Yes
A client reads a headline about a frontier model at a fraction of the price and asks whether you can use it. This is the short answer, the long answer, and the checklist that stops you giving the wrong one.
- The answer is almost never yes or no. It is which route. The same weights are blocked through the vendor's own API and permitted self-hosted or through a hyperscaler, and that distinction is the entire conversation.
- Cost is rarely the deciding factor. These models are cheap, and the reason to decline is jurisdiction, evidence or hardware. Leading with price loses the argument you actually need to win.
- Saying no on principle costs you credibility. For public marketing copy a China-hosted model is fine. An MSP who blocks everything is a gatekeeper, not an advisor.
"A client saw that a Chinese model beats the expensive ones at a tenth of the cost. Can we use it, and what do I say if not?"
Dan Whitfield, vCIO at a 40-client MSP
How to think about it
- Start with the route, not the model. There are four, and they have different answers: the vendor's own hosted API, a US managed host running the same weights, deployment on your client's existing AWS or Azure agreement, and self-hosting on infrastructure they control.
- Only the first is usually blocked. The jurisdiction problem attaches to where the endpoint runs, not to who trained the weights. Moving the weights moves the answer.
- Then check whether the mitigation is real. Self-hosting is the standard advice and is frequently unavailable: a frontier mixture-of-experts model can need over a terabyte of accelerator memory, which is not a procurement decision for a 200-seat client.
- Then check the licence. Downloadable weights are not the same as a commercial licence, and 'open weight' is not 'open source'.
The findings
DeepSeek, captured 2026-07-26
- No trust portal at all. The API docs navigation carries Quick Start, API Guides, Reference, News, FAQ and Change Log. No security or compliance section exists. Verified absent, not merely unchecked.
- No SOC 2, no ISO 27001, no ISO 42001, no HIPAA, no BAA. Nothing published on any of them.
- Data residency is fixed. There is no US or EU option for the hosted API. Prompts, responses and metadata process in China.
- Reported to train on customer data by default, which is the opposite of Anthropic. UNVERIFIED from a single secondary source, and the single most important field to confirm from their own privacy policy before quoting it.
- Weights are genuinely open, which is what makes the other three routes possible.
- They publish an Anthropic-compatible endpoint. Claude Code, GitHub Copilot or OpenCode can be pointed at DeepSeek by changing one base URL, with no code change. This is the clearest shadow-AI path in the whole landscape.
- Model lifecycle moves fast. deepseek-chat and deepseek-reasoner were deprecated on 2026-07-24 in favour of v4-flash and v4-pro. Check the slug before quoting a price.
Kimi and Moonshot, captured 2026-07-26
- No trust portal found. Everything recorded is secondary-sourced and marked low confidence.
- No SOC 2 and no BAA published. Not a candidate for PHI on the evidence available.
- Kimi K3 is 2.8 trillion parameters, mixture-of-experts. Frontier scale, and frontier hardware to host.
- Weights were promised by a date and had not shipped when trackers were checked. Independent trackers still listed the model as proprietary. Plan against the file, not the announcement.
- The predecessor shipped under a Modified MIT licence carrying an attribution obligation above roughly 100 million monthly users or 20 million dollars monthly revenue. Unlikely to bite an internal MSP deployment, but read it rather than assume.
- Moonshot's own notes warn the model can show excessive proactiveness and make unexpected decisions on the user's behalf without explicit constraints. For a regulated workflow that is a governance flag, not a quirk.
The four routes, and what each changes
- Vendor hosted API. Cheapest and simplest. Blocked for regulated data on jurisdiction. Fine for public and usually fine for internal.
- US managed host. A third party runs the same weights on US infrastructure and may hold SOC 2 and offer a BAA. The compliance posture is theirs, not the model vendor's, so capture them separately.
- Hyperscaler marketplace. Deploy the weights inside the client's existing AWS, Azure or Google agreement. Usually the fastest compliant path, because the BAA and data boundary already exist and no new vendor agreement is needed.
- Self-hosted. Total control, and the compliance burden moves entirely to the client. Only viable if the memory maths works and the licence permits it.
Where the medical and regulated line falls
- No BAA exists from either vendor, so the hosted API cannot lawfully carry protected health information.
- The hyperscaler route can carry PHI where the client already holds a BAA with that cloud provider, because the agreement governing the data is the cloud provider's.
- Self-hosting can carry PHI, and the client owns every control: encryption, access logging, retention, and the validation work.
- Self-hosting does not by itself satisfy GxP or 21 CFR Part 11. It removes the data-transfer problem; it does not constitute computer system validation.
Risks that have nothing to do with the model
- Auto-routers pick the cheapest qualifying model, and that is frequently a China-hosted one. Nobody chose it and the request still succeeded.
- An undocumented flow breaks your client's own attestation. A SOC 2 auditor asks where AI data is processed; an incomplete answer can produce a qualified opinion.
- A blocklist cannot work. New endpoints appear in router catalogues continuously. Only a deny-by-default allowlist closes it.
- Search your codebase for the family names, not just the vendor: DeepSeek, Qwen, Yi, Moonshot, GLM.
Reading the result
- DeepSeek, hosted API. No SOC 2, no ISO, no HIPAA, no trust portal, verified absent 2026-07-26. Processing in China with no residency option, and the residency is fixed. Blocked for regulated data.
- DeepSeek, other routes. Weights are downloadable, so a US managed host, a hyperscaler deployment or self-hosting all change the answer. The hyperscaler route is usually fastest, because the client's existing cloud agreement already covers it.
- Kimi K3, Moonshot. Frontier scale at 2.8 trillion parameters. No trust portal found. Weights were promised and, at the time of capture, independent trackers still listed the model as proprietary. Announced is not shipped.
- Qwen, GLM, Yi. Same shape as DeepSeek and worth the same four-route treatment. They appear in router catalogues by default, which matters more than whether you chose them.
Benchmarks
- Cost: Chinese open-weight models commonly run 3 to 10 times cheaper per token than a Western frontier model, but the newest are not always cheap. Kimi K3 launched at $3 in and $15 out per 1M, the most expensive Chinese release to date.
- Self-host memory, 4-bit: a 70B dense model is about 35 GB. A 1.6T mixture-of-experts is about 800 GB. A 2.8T is about 1,400 GB, roughly 37 professional cards.
- Realistic self-host ceiling for an SMB: one to two professional GPUs, so dense models up to about 70B. Frontier MoE is rented, hyperscaler-hosted, or not happening.
For and against
- For: genuine cost advantage, often 3 to 10 times cheaper per token
- For: open weights mean no vendor lock-in and a self-host escape hatch
- For: frontier-class capability is now available in the open-weight tier
- For: the mitigation routes are real, and the hyperscaler one is often easy
- Against: no compliance evidence published, so unknown rather than negative
- Against: fixed China residency on the hosted API, with no regional option
- Against: training on customer data is reported as default-on, unverified
- Against: self-hosting frontier scale is out of reach for most SMB clients
- Against: export policy is unstable in both directions
- Against: your client's auditor has probably read a news article about this
Checklist
- Which DATA CLASS will this workload touch? Answer before anything else.
- Does the client hold an attestation that an undocumented flow would break?
- Which ROUTE are we actually proposing? Name it. Hosted API, US host, hyperscaler, or self-hosted.
- If hyperscaler: does the client already hold a BAA or agreement with that cloud?
- If self-hosted: have the weights actually SHIPPED, not been announced?
- If self-hosted: does the licence permit this commercial use, including any revenue threshold?
- If self-hosted: does the memory maths work on hardware the client has or would rent?
- Is an enforced model allowlist in place on every router this client uses?
- Have we checked the router usage logs for traffic already going somewhere nobody approved?
- Is the compliance verdict recorded with a DATE, so it can be re-checked rather than assumed?
- Have we written down what we told the client, in language their auditor could read?
Limitations
- Compliance evidence for these vendors is thin by Western standards, so much of this is recorded as VERIFIED ABSENT on a date rather than as a negative claim. That distinction matters if a client challenges it.
- Export policy moves in both directions. A promised weight release can be delayed, narrowed or restricted to domestic use, and Western export controls have restricted access to frontier models in the other direction.
- Third-party host claims are about the HOST, not the model vendor. If you route through a US managed host, that host becomes its own vendor needing its own compliance record.
- Nothing here is legal advice. Whether a specific flow breaches a specific regulation is a question for the client's counsel.
Method
- Compliance verdicts come from captured vendor material with the capture date shown. Where nothing is published, the record says VERIFIED ABSENT on a date rather than asserting a negative.
- Memory figures are parameters multiplied by bytes per parameter at the chosen precision, plus a runtime multiplier. Weights only: KV cache, activations and long context add materially.
- Anything marked UNVERIFIED came from a secondary source and must be confirmed from the vendor's own page before it reaches a client.
Take this further