Where to Actually Run Kimi, GLM, DeepSeek and Qwen

Yes, it matters which host you call an open-weight model from. The same model name arrives at different quantizations and often with less context than the model advertises: two hosts serve GLM-5.3 at a quarter of its published window, one host caps DeepSeek V4 Pro’s output at 4.3% of the vendor’s documented maximum, and DeepInfra serves Qwen3.8’s open flagship at fp4 — a 4-bit precision format — with 262,144 tokens of context, 26% of its extended ceiling.

Almost nobody self-hosts a model this size, so “open weights” means, in practice, a rental decision across competing hosts. The census in §04 is the fast path: each row is a model-times-provider pair, setting what a host serves — quantization, context, price — beside the vendor’s advertised figures, with every field this pull did not capture marked rather than dropped.

We made this argument once before for a single model — the Qwen3.8 Flash weights-vs-hosted split showed that the checkpoint on Hugging Face and the API sold under the same name are not the same thing. This page is the class-level version of that finding, with numbers, across four model families and every provider endpoint OpenRouter lists for them. It is also deliberately narrower than our catalog-literacy guide: that post teaches how to read a catalog row — prices, dates, surfaces. This one measures what the row actually delivers once a host serves it.

The data source that makes the measurement possible is OpenRouter’s public endpoints API, which reports a structured quantization, context-length and price field for every provider serving a given model — what each provider reports to OpenRouter, published per endpoint. Cross-reference those fields against each vendor’s own model card and the gaps appear immediately.

None of this is hidden. The figures come from published fields — endpoint listings, vendor model cards, first-party docs pages — with derived cells marked where they appear. What does not exist anywhere we could find among the sources reviewed for this pull is the cross-referenced view: the served figure next to the advertised one, per host, per model, in one table. That is the gap this page exists to close.

A serving census is only as good as its denominators. Every percentage on this page is scoped to its named model and computed from figures quoted in the same row, and every undisclosed field is kept visible rather than dropped.

Quantization is the numeric precision a model’s weights are stored and served at — bf16 at the heavy end, fp8, then 4-bit formats like fp4 and mxfp4. Lower precision means cheaper, faster serving, and potentially different outputs from the same weights. The twist this census surfaces: for two of the four families, low precision is not a downgrade — it is the factory setting. Moonshot trained Kimi K3 natively at MXFP4 weights with MXFP8 activations, per its own model card, and DeepSeek V4 ships at a native “FP4 + FP8 Mixed” precision. “Full precision” for these models is already a 4-bit-class format, and Alibaba goes a step further: it publishes its own pre-quantized FP8 checkpoint of the Qwen3.8 flagship rather than leaving quantization entirely to hosts.

Served context vs advertised context is the gap between the window on the model card and the window a specific endpoint accepts. A host serving less than the advertised figure is not lying — it is making a capacity decision — but nothing on the price sheet announces it. Distill vs full model is the third check: a distill is a smaller model trained to imitate a larger one’s outputs, sold under a confusingly similar name. The naming trap in this census takes a different form — sibling models sharing one family name, which §07 takes apart for Qwen.

Rows are grouped by model family. Each group header carries the vendor’s advertised context — the denominator for that group’s percentage column — and the endpoint count from the full pull. Rows shown are the census’s curated cut from that pull: price extremes, throughput extremes, context truncations and vendors’ own listings, where this pull captured them. Undisclosed fields are kept in as “undisclosed” — deleting them would turn a host’s silence into our omission.

The Qwen rows expose a mechanism most coverage flattens into one number. Qwen’s own model card states context two ways: “262,144 natively and extensible up to 1,010,000 tokens” — a native window the model was trained at, and an extended ceiling reached through scaling techniques. A headline “1M context” for this model is the extended figure. A host serving 262,144 is not lying; it is quietly serving the un-extended model. The census’s job is to tell you which one your endpoint is.

Even where a host serves the full model at the full window, the commercial terms scatter. Kimi K3’s input price runs from $2.55 to $6.00 per million across its 17 endpoints — a 2.35× spread for identical weights. DeepSeek V4 Flash spans $0.068 to $0.44, a 6.5× spread, the widest in this census. GLM-5.3 is the counterexample that proves price and speed are separate axes: 14 of its 21 hosts converge on $1.40/$4.40, and at that single price point throughput still spans 5.1×. Our frontier-model price index tracks list prices across vendors; this page is the reminder that for open weights, the list price is only one of the fields that varies.

OpenRouter itself published the single-model version of this finding in July, for DeepSeek — and its July snapshot counted 16 providers where our later pull found 17, a reminder that even the host count is a moving figure. The two numbers are different snapshots, not a contradiction.

One caution on the output column of any endpoint listing: a published max-completion figure is the number the API will accept, not a benchmarked promise of what the model reliably generates in one turn. Twelve of GLM-5.3’s third-party endpoints publish an output ceiling of 943,718 tokens — more than seven times the 128K maximum Z.ai itself documents. Only the vendor’s own listing is directly tied to a vendor-stated limit. Read high ceilings as generous parameter defaults; read low ones — like the 16,384-token DeepSeek V4 Pro cap — as the binding constraint they are. What a usage aggregator’s charts can and cannot tell you about any of this is its own topic — see what OpenRouter’s usage charts actually measure.

“Qwen3.8” is not one product. It is at least three distinct models with three different serving postures. Qwen3.8 Max is closed-weight and single-host — exactly one provider, Alibaba Cloud International, serves it. That is the census’s control case: with no open weights there is no host choice, no quantization spread and no context-truncation risk to shop around; the entire renting-not-running problem collapses to a single row. Qwen3.8-2.4T-A95B is the open flagship — 2.4T total parameters, 95B active — described by Alibaba as the open-weight variant of Max, served by seven hosts with the full spread of cuts documented above. And Qwen3.8-27B is a small open dense model, the one Groq serves at 131,042 tokens.

The licences split the same three ways, and the split broke a pattern. Every earlier Apache-licensed Qwen open release used Apache-2.0; the Max-class flagship instead ships under a bespoke “qwen3.8-max” licence — the first Qwen open weight to do so — while the 27B keeps Apache-2.0, the only Apache licence anywhere in this census. Kimi K3 ships under its own bespoke licence, GLM-5.3 under a bespoke licence that is not MIT, and DeepSeek V4 under MIT. Four families, four different answers to what you may do with the weights you are nominally free to run.

The catalog-side consequence is visible at Groq: its documented model catalog, in this census’s collection pass, listed no Kimi K3, no GLM-5.3 and no DeepSeek V4 of any variant — its open-weight lineup at this size class is Llama, GPT-OSS, MiniMax-M2.7 and two dense Qwen3.x models. That is a claim about one documentation page in one pull, not about Groq’s roadmap; but it means the fastest-inference host many builders reach for first simply does not carry three of these four families. This generation’s spread also has precedent: the same host-by-host variance was visible for GLM-5.2 in our provider price comparison and its companion on what self-hosting actually takes — the hardware reality that makes this whole census a rental decision in the first place.

The census supports a short pre-flight routine. None of it requires tooling beyond the endpoint listing and the vendor’s model card.

The limitation to hold onto: this is a census of published serving fields, not a probe of live endpoints. We did not measure quality deltas between quantizations here, and the fields themselves move — hosts join, reprice and requantize continuously. If model selection and host selection sit between your team and a workload that has to ship — an agent pipeline sized to a context window that one candidate host quietly does not serve — that is the kind of decision our AI transformation engagements exist to de-risk.