DeepSeek, Qwen and GLM: Check license, access and serving needs

DeepSeek-V3’s repository code is MIT-licensed; its Base and Chat weights have a separate Model License. That distinction matters before a commercial deployment: read the artifact’s terms, then check the runtime and access path. (DeepSeek-V3 documentation; DeepSeek-V3 model license)

DeepSeek, Qwen and GLM: Check license, access and serving needs

“Open-weight” is not a single legal status. Code, weights, model cards, hosted APIs, and deployment tooling can have different terms. A procurement review should read the license that applies to the artifact being used, not infer it from the lab, the model family, or a marketplace label.

Three named releases illustrate the distinction. These are release-specific examples, not a list of the latest checkpoints in each family:

(DeepSeek-V3 documentation; Qwen3-235B-A22B model card; Qwen3-235B-A22B license; GLM-4.5 model card)

The access column records paths named by the model card, not a tested hardware or binary compatibility matrix. Qwen’s local-application statement concerns the Qwen3 family; the exact 235B artifact still needs its own capacity and implementation check.

The DeepSeek row is especially easy to misread. An MIT license for repository code does not erase a separate model license for the weights. The commercial-use statement is useful, but it is not a substitute for counsel checking the full model-license text, downstream distribution terms, export and sanctions obligations, data-handling obligations, and a customer’s own procurement requirements. The original DeepSeek-V3 weight agreement includes use restrictions and redistribution terms; the repository’s commercial-use description should be read with that full text. (DeepSeek-V3 model license)

Separate downloadable weights from hosted access

An operator can often choose among several access paths for the same model family:

1. Run the released weights locally or in a controlled cloud account. This places runtime selection, capacity, patching, access controls, and evaluation with the operator.
2. Use a compatible inference service. This reduces some serving work but introduces the provider’s regions, authentication, data terms, rate limits, and price schedule.
3. Use the model publisher’s API. This can be the shortest path to a working integration, but the API model ID, endpoint, terms, and billing page, not a local model card, define the operating arrangement.

Qwen’s model card gives examples for local and server deployments with Transformers, vLLM, and SGLang. GLM’s model card documents local-library and server paths as well. Z.AI separately documents an API quick start, which is a useful reminder that downloadable weights and hosted API access are different choices, even when they share a family name. (Qwen3-235B-A22B model card; GLM-4.5 model card; Z.AI developer quick start)

Do not substitute a wrapper site, an unofficial chat front end, or an API-compatible proxy for the publisher’s documentation. Those services may add their own usage terms, model aliases, logging behavior, limits, and security boundaries. They do not establish the license or provenance of the weights they claim to expose.

Serving cost is a deployment question

Weights without an API bill are not weights without cost. The model-card parameter counts, precision artifacts, context length, concurrency target, runtime, and hardware all affect the capacity an operator must provision. “Total parameters” and “active parameters” are useful technical descriptions, but neither converts into a universal per-token cost without a measured workload and a chosen serving stack.

Use the following cost model instead of a headline comparison:

The model cards are a starting point for the first three rows, not a complete total-cost-of-ownership calculation. Measure the intended prompt sizes, output lengths, tool calls, cache behavior, and concurrency on the target hardware. Keep the test configuration alongside the numbers; a token-per-second result without that configuration cannot decide a deployment.

Keep one release record for approval

Put the deployment’s evidence in one record:

• Exact model identifier, artifact precision, revision, and download source.
• Applicable weight, code, tokenizer, and runtime terms, including redistribution and use restrictions.
• The selected runtime or hosted endpoint, account, region, and authentication arrangement.
• A held-out application evaluation, plus capacity and cost measurements for the intended context and concurrency.
• Ownership of updates, access review, monitoring, incident response, and rollback.

This is a proposed operating record, not a test completed for these three models. It connects the documented permissions and access paths to evidence that must come from the actual deployment. A publisher benchmark can help choose evaluation cases, but it cannot prove that a different prompt, tool configuration, or quantization meets the application’s requirements.

The comparison becomes useful when each row names an artifact, its terms, its access path, and the workload being measured. A low provider quote is not a saving if the candidate fails the task, and a permissive weight license is not the same agreement as a hosted API account. Keep those decisions explicit instead of turning a set of release facts into an unsupported explanation of worldwide adoption.