How do you choose between Alibaba's hosted Qwen API and running Qwen weights yourself?

## Why this is a real decision for Qwen specifically Most model families force the choice: either the vendor hosts it or you do. Qwen is one of the few broad families available **both** ways — Alibaba Cloud Model Studio serves it as an API, and much of the line-up ships as downloadable weights. That means the decision is genuinely reversible, and the right answer changes as a product matures. Treat it as a decision you revisit, not one you make once. ## Axis 1: the data path A hosted call sends the prompt to Alibaba's infrastructure, processed in the region whose endpoint you called. Two consequences dominate: - **Residency.** The endpoint you choose determines the jurisdiction. For some organisations that is a hard constraint that eliminates one region, or the hosted option entirely. - **Confidentiality and moderation.** Content passing through a hosted platform is subject to that platform's policies, including content filtering that can refuse or interrupt a generation. If your corpus is sensitive, or contains material a general-purpose filter mishandles, self-hosting removes both concerns. When either applies, stop — economics do not override a compliance constraint, and a principal is expected to lead with this axis rather than discover it in review. ## Axis 2: economics and the utilisation crossover Hosted billing is per token with no floor: an idle service costs nothing. Self-hosting is the inverse — GPUs cost the same whether you serve one request an hour or saturate them, so the unit cost is your fixed spend divided by realised throughput. That gives a clean way to reason. Self-hosting is cheaper only above a **utilisation crossover**, and the crossover is high because it must also absorb the engineering cost of running the stack. Two failure modes to name: - Teams model the crossover on **peak** traffic and then run at 15% average utilisation, paying for idle silicon. - Teams model it on hardware rental alone and forget the on-call rotation, upgrade work, capacity headroom for spikes, and the multi-GPU redundancy that any serious availability target requires. Bursty, seasonal, or still-being-discovered traffic belongs on the hosted API almost regardless of the sticker price per million tokens. ## Axis 3: operations, quota and change Hosted means someone else owns capacity and uptime — but you inherit their limits. The hosted API meters your account, and a traffic spike beyond your quota returns throttling errors you cannot fix by adding hardware; you fix it by backing off, requesting more quota, or degrading. Quota is also per region and does not pool, so a multi-region deployment plans capacity twice. You also inherit **change**. Hosted catalogues gain and retire model ids, and moving aliases shift behaviour under you. That is a benefit when you want the newest model without redeploying a serving stack, and a liability when you have contracted behaviour to defend. Pinning dated snapshot ids mitigates it; only local weights eliminate it. Self-hosting inverts every line: unlimited internal throughput up to your hardware, no vendor-side deprecation, and full ownership of every failure at 3am. ## Axis 4: control over the model Some requirements only weights satisfy: pinning an exact build for years, serving a fine-tune whose adapter you own and do not wish to upload, or auditing behaviour reproducibly. If any of those is a stated requirement, hosted is out for that workload — though not necessarily for the others. ## The strategy most teams should actually run 1. **Prototype hosted.** Discover whether the product works before capitalising a serving stack. Wrong-product risk dwarfs unit-cost risk at this stage. 2. **Instrument from day one** — tokens per request, requests per second, p95 latency, throttling rate. These are the inputs to every later decision and cannot be reconstructed retroactively. 3. **Keep the call behind an interface.** The reason this migration is cheap for Qwen is that self-hosted servers commonly expose an OpenAI-compatible endpoint too, so the switch can be a base-URL change — but only if you did not scatter vendor specifics through the codebase. 4. **Re-evaluate on a trigger, not a calendar** — sustained utilisation above your modelled crossover, a residency requirement arriving with a new customer, or a control requirement landing from legal. 5. **Consider a split.** High-volume, low-sensitivity, stable-prompt traffic self-hosted; long-tail, bursty or frontier-capability traffic hosted. Hybrid is often the correct answer and is rarely the one candidates give. ## What a weak answer looks like "Self-hosting is cheaper" with no utilisation model, or "hosted is easier" with no mention of residency or quota. The signal an interviewer wants is that you know which axis is decisive for a given workload, and that you would collect the numbers before committing capital.