Is Qwen 3.6 better than GLM-5.2 because it scores 77.2 vs 62.1?

No — those are different benchmarks. Qwen's 77.2 percent is SWE-bench Verified; GLM-5.2's 62.1 percent is SWE-bench Pro, which is harder. Comparing across benchmark variants produces confident nonsense.

Which is easier to self-host?

Qwen 3.6 27B, by a wide margin. It is dense and fits on a single accelerator when quantised. GLM-5.2 holds roughly 744B parameters and needs memory for all of them even though it activates about 40B per token.

What is GLM-5.2's 128K maximum output for?

Large generated artefacts — full migrations, big test suites, whole translated files. Most models cap output far below their input window, and you usually find the ceiling by hitting it mid-function.

GLM-5.2 vs Qwen 3.6: Sparse and Huge, or Dense and Small

These two are the closest thing the open-weight field has to a clean architectural experiment. Both are permissively licensed. Both are aimed at code. One is a 744B-parameter mixture-of-experts activating around 40B per token; the other is a dense 27B that fits on one GPU.

Which one you want depends almost entirely on where the model runs.

Sparse versus dense, concretely

GLM-5.2 holds roughly 744B total parameters and activates about 40B per token. You need memory for all 744B and compute for 40B. That is the mixture-of-experts bargain: cheap to compute, expensive to hold.

Qwen 3.6 27B holds 27B and activates 27B. Memory and compute scale together, and both are small.

The consequence is not subtle. GLM-5.2 is a serious deployment if you host it yourself. Qwen 3.6 27B, quantised, runs on a single rented accelerator. Mixture-of-experts explained covers the mechanism; quantization explained covers what compression costs you.

The capability difference

Qwen 3.6 27B reports 77.2 percent on SWE-bench Verified. GLM-5.2 reports 62.1 percent on SWE-bench Pro, which is a harder benchmark — the two numbers are not comparable and should not be read as Qwen winning.

That is worth dwelling on, because it is the most common mistake in model comparison. Benchmark names that look similar frequently are not. Verified and Pro have different task pools and different difficulty. Comparing across them produces confident nonsense. Why benchmarks disagree covers the general failure.

What can be said: GLM-5.2 is explicitly built for long-horizon coding, with 1M context, 128K maximum output and two reasoning effort levels. Qwen 3.6 27B is built to be small and good. Those are different goals and the models reflect them.

Output length is an overlooked axis

GLM-5.2's 128K maximum output is unusual and occasionally decisive.

Most models cap output well below their input window, which is fine until you ask for a large generated artefact — a full migration, a big test suite, a translated file. Then you discover the ceiling by hitting it, usually mid-function.

If your workload generates rather than analyses, check maximum output before context window. It is the constraint people forget until it truncates something.

Licensing is close but not identical

GLM-5.2 is MIT. Qwen ships under permissive terms across most tiers, though the exact licence varies by model size, so verify for the specific build you intend to ship.

Both are far more permissive than Kimi K3, which needs a separate agreement above a revenue threshold. If licence certainty is the driver, either of these is a safer foundation.

How to choose

Self-hosting on limited hardware — Qwen 3.6. GLM-5.2's memory footprint takes it out of contention.
Long unattended agent runs — GLM-5.2. It is explicitly designed for the horizon length, with effort levels to tune cost.
Large generated outputs — GLM-5.2, on the 128K output ceiling alone.
Air-gapped or data-residency constrained — Qwen 3.6, because it is the one that fits.

If you are using an API rather than hosting, Qwen's main advantage disappears and the comparison shifts to measured cost per completed task on your own work. How to benchmark LLMs on your own work covers building that measurement rather than trusting either vendor's chart.

Throughput behaves differently for each

A dense model has predictable throughput: every token costs the same compute, so tokens per second stays flat as load rises until you saturate the accelerator. Capacity planning is arithmetic.

A mixture-of-experts model routes different tokens to different experts, so throughput depends on how evenly traffic spreads across them. Skewed routing puts disproportionate load on a few experts and real throughput lands below the theoretical figure. This is why published tokens-per-second numbers for MoE models are harder to reproduce than for dense ones.

For an API user this is the provider's problem. For anyone self-hosting it is yours, and it is the sort of thing that looks fine in a benchmark and disappoints under production traffic patterns. Measure at your real concurrency, not with one request at a time.

A note on model families

Both labs ship frequently and both maintain several sizes. Whatever you conclude here has a shelf life measured in months, so write the comparison down as a repeatable evaluation rather than a decision. When the next release lands you re-run it in an afternoon instead of re-litigating from scratch.