Qwen3.7 Flash GPU Requirements: It's API-Only (2026)

Type "qwen3.7 flash gpu requirements" into a search box and you'll get zero real answers, because there's nothing to size. Qwen3.7 Flash has no Hugging Face repository, no GGUF, no AWQ checkpoint, and no vLLM support path. It's an Alibaba API product, not something you download. If what you actually want is a self-hostable model with similar reach (text, image, video in), the model to look at is Qwen3.6-35B-A3B, Alibaba's open-weight vision MoE from the generation before this one. This post covers why Flash can't be self-hosted, what 35B-A3B actually needs in VRAM, and an honest cost-per-token comparison between running it yourself and just paying Alibaba's API rate.

Qwen3.7 Flash GPU Requirements: Why the Question Doesn't Apply

There is no GPU config for Qwen3.7 Flash because there are no weights to load onto a GPU. It's served exclusively through Alibaba's QwenCloud API (and resold through aggregators like OpenRouter). Every "requirements" question, VRAM, quantization, tensor parallelism, is moot until Alibaba changes that, which it has given no indication of doing.

No Hugging Face Repo, No Downloadable Weights

Hugging Face returns no repository for Qwen3.7 Flash, and Roboflow lists its license as proprietary. As one review of the model puts it: "Hugging Face returns no repo for it and Roboflow lists the licence as proprietary, so it is API-only" (eesel AI). That's not a temporary gap waiting on a release. It's the distribution model: the same review notes the entire Qwen3.7 line, Flash, Plus, and Max, is closed weight, "a departure from Qwen's earlier open-source approach."

That departure matters if you've followed Qwen releases before. Qwen 3, Qwen 3.5, and the open side of Qwen 3.6 all shipped downloadable weights on day one, sometimes alongside a hosted API. 3.7 broke that pattern across the board.

What Alibaba Actually Shipped on July 25, 2026

The only first-party announcement was a single paragraph in the QwenCloud changelog, dated July 25, 2026 (OpenRouter listed the model two days later, on July 27). Alibaba's own description:

"The Qwen3.7 native vision-language Flash model series delivers a comprehensive upgrade over 3.6-Flash in multimodal understanding and agent execution... with optimized multimodal coding for a smoother vibe coding experience." (QwenCloud changelog)

Under the hood, Flash accepts text, image, and video input and returns text output, with a 1,000,000-token context window (991,808 tokens usable for input, 65,536 for output) and a 262,144-token chain-of-thought budget for reasoning traces. Pricing is tiered by prompt size: $0.03/$0.13 per 1M input/output tokens under 32K context, $0.10/$0.40 from 32K-256K, and $0.20/$0.80 from 256K-1M (eesel AI).

Those list prices are aggressive: 6.25x cheaper on input and 8.65x cheaper on output than Qwen 3.6 Flash, which listed at $0.1875/$1.125 per 1M tokens (eesel AI). But real usage skews higher: OpenRouter's actual customer traffic blends to roughly $0.044/M input and $0.149/M output, well above the sub-32K sticker price, because most production traffic runs longer prompts than the cheapest tier assumes. At that blended rate the advantage shrinks a lot, to about 4.26x cheaper on input and 7.55x cheaper on output than Qwen 3.6 Flash, still meaningfully cheaper, just nowhere near the sticker-price multiples. Whatever Flash is architecturally, Alibaba priced it to compete on cost, not to be self-hosted.

Qwen3.7 Max vs Flash: The Whole 3.7 Line Is Closed Weight

If you searched for deploy Qwen3.7 Max GPU cloud hoping for a different answer, it's the same one. Max is Alibaba's frontier tier in the 3.7 generation, positioned above Flash for reasoning and agentic depth, but it ships through the identical closed distribution model. There's no repository, no checkpoint, and no self-hosting path for it either. Our own deployment guide for Qwen3.7 Max, written when Alibaba's plans were still unclear, has since had to caveat every VRAM estimate as speculative for exactly this reason: there was never a model card to size against.

Third-party coverage confirms this isn't a temporary state. One analysis is blunt about it: "Qwen 3.7-Max is not open source and not open-weight... You cannot download Qwen 3.7-Max. You cannot run it on your own GPUs. Access is API-only," adding that "Qwen has not announced any plan to release Qwen 3.7-Max as an open model" (Yotta Labs). Flash and Max differ in target use case and presumably in scale, but not in how you access them: both are QwenCloud API products with no downloadable form.

How This Differs From Qwen 3.6 and Earlier Generations

Alibaba's earlier Qwen releases mixed open and closed distribution within a single generation, but always left an open path somewhere in the lineup. Qwen 3 and Qwen 3.5 shipped full weight releases across most model sizes. Qwen 3.6 continued that: the open side of the family includes Qwen3.6-35B-A3B, released under Apache 2.0 with full weights on Hugging Face.

Qwen3.7 is the first generation where that open path doesn't exist anywhere in the lineup. Flash, Plus, and Max are all API-only. If self-hosting matters to you, and you want architecture, context length, and modality support in the same neighborhood as Flash, the open Qwen3.6 release is where to look, not anything with a 3.7 in the name.

The Open Alternative: Qwen3.6-35B-A3B GPU and VRAM Requirements

Qwen3.6-35B-A3B is Alibaba's open-weight, Apache 2.0-licensed multimodal MoE model, released on Hugging Face in April 2026. It has 35B total parameters with 3B active per token, routed across 256 experts (8 routed plus 1 shared expert active per forward pass), and accepts text, image, and video input (Hugging Face). The architecture mixes Gated DeltaNet-based and Gated Attention-based MoE layers across 40 total layers, a hybrid pattern similar to the linear-attention approach Alibaba used in Qwen 3.6 Plus, which keeps KV cache growth in check at long context.

Native context is 262,144 tokens, extensible to roughly 1,010,000 tokens via YaRN scaling. vLLM (0.19.0+), SGLang (0.5.10+), KTransformers, and Hugging Face Transformers all support it.

VRAM Table (FP16, FP8, INT4) and Recommended GPU Configs

The MoE routing doesn't reduce VRAM: all 35B total parameters have to sit in memory regardless of how many activate per token. Only compute and throughput benefit from the 3B active-parameter sparsity.

FP8 on H100 is the practical default: native FP8 Tensor Core support, and the weight footprint leaves plenty of room for KV cache even at extended context. A100 lacks hardware FP8 support, so use --quantization bitsandbytes (INT8) on A100 instead of trying to force FP8. For a longer treatment of VRAM sizing methodology across open vision-language models, see the vision language model deployment guide, which covers the same weight-size-plus-KV-cache math for Qwen3-VL and InternVL3.

What won't work: RTX 4090 or any 24GB consumer card at any precision above INT4, and FP16 on a single 80GB card if you also need meaningful KV cache headroom for long-context requests.

What It Gives Up vs Qwen3.7 Flash (Vision Benchmark Gap)

Be careful with this comparison, because the two models weren't run through the same benchmark. Qwen3.7 Flash is scored on Roboflow's Vision Evals, a six-task suite, where it averages 61.7% and ranks 22nd of 23 vision models tested. Its strongest category is identification at 84.4% (10th of 23); its weakest-ranked category is OCR, where it scores 84.1% but still finishes dead last, 23rd of 23, because most of the field clears that task well above 90% (Roboflow). Qwen3.6-35B-A3B is scored on MMMU and MMMU-Pro instead, reporting 81.7% on MMMU by one source and 75.3% on MMMU-Pro by another (BenchLM). Those aren't the same test, and MMMU and MMMU-Pro aren't even the same test as each other, so don't read a percentage-point gap into these numbers.

What you can say plainly: Alibaba's own July 25 changelog markets Flash specifically on "agent execution capabilities" for Search Agent and CI Agent workflows, plus multimodal coding polish, capabilities that are product-specific to Flash and aren't something an open weight release replicates by default. And on the one independent vision benchmark that does exist for Flash, it isn't a standout performer, ranking near the bottom of Roboflow's leaderboard with genuinely weak OCR. If OCR or document understanding is your actual workload, a dedicated open OCR model is likely to outperform either option; see the best open-source OCR and document VLMs guide for models built specifically for that task.

Cost Per Token: Self-Hosted Qwen3.6-35B-A3B vs the Qwen3.7 Flash API

The MoE routing that keeps 35B-A3B cheap to run also makes it a fair comparison against a "flash"-tier API model: both are built to be inexpensive per token. Throughput for 35B-A3B on H100 hasn't been independently benchmarked yet, but Qwen 3 30B-A3B, a similarly-sized sparse MoE with the same 3B active-parameter class, measured roughly 3,900 tok/s on a single H100 SXM5 in Spheron's own cross-model benchmark (GPU cost per token benchmark). We use that as a working estimate here; benchmark your actual deployment before committing budget to either path.

Spheron GPU Pricing for the Self-Hosted Config

Live pricing from the Spheron GPU pricing API, fetched 03 Aug 2026:

Pricing fluctuates based on GPU availability. The prices above are based on 03 Aug 2026 and may have changed. Check current GPU pricing → for live rates.

At the ~3,900 tok/s estimate on H100 SXM5, cost per million tokens works out to roughly $0.24/M on-demand and $0.10/M on spot at full utilization. Real production servers rarely run at 100% utilization; at a more realistic 65%, that's about $0.37/M on-demand and $0.16/M on spot.

Break-Even Volume: When Self-Hosting Actually Wins

Here's the part that doesn't fit the usual "self-hosting crushes the API" narrative: once you put both sides on the same $/M-total-tokens basis, Flash's API pricing holds up better than it looks at first glance.

Because GPU billing is time-based, not per-token, self-hosted cost per token doesn't change with your input/output mix. Flash's blended cost does, since input and output are billed separately and vision workloads tend to be input-heavy (image tokens count against the input rate). Using OpenRouter's real blended customer rates ($0.044/M in, $0.149/M out) at a few input:output ratios, normalized to cost per total token (input plus output) so it lines up with the GPU columns:

Normalized this way, Flash beats both self-hosted options at every ratio in this table, and the gap grows in Flash's favor as the mix gets more input-heavy: input tokens bill at roughly a third of the output rate, so an input-skewed workload pulls the blended average down, not up. Even at full, non-degraded utilization, self-hosted spot's floor is $0.10/M, still above Flash's $0.097/M at a 1:1 ratio and further behind at 3:1 ($0.070/M) and 5:1 ($0.062/M). On-demand isn't close at any ratio; its full-utilization floor is $0.24/M.

In practical terms: for the input-heavy vision workloads Flash is built for, the API is the cheaper option per token, not just the lower-effort one. Self-hosting Qwen3.6-35B-A3B can still make sense if you need data residency, want to avoid third-party rate limits, or you're running a roughly balanced-to-output-heavy workload on spot at close to full, sustained utilization, but don't expect self-hosting to win on cost alone for a typical input-heavy pipeline.

Step-by-Step: Deploy Qwen3.6-35B-A3B on GPU Cloud with vLLM

1. Provision the GPU. Go to app.spheron.ai and pick your precision tier: H100 SXM5 for the FP8 default, A100 for INT8/INT4, or H200 if you need FP16 headroom. SSH in and run nvidia-smi to confirm GPU count, VRAM, and driver version.

2. Install vLLM.

pip install "vllm>=0.19.0"
python -c "import vllm; print(vllm.__version__)"

Qwen3.6-35B-A3B's hybrid Gated DeltaNet/Gated Attention layers need this version or newer. If the model class isn't recognized, add --trust-remote-code as a fallback.

3. Download weights to persistent storage.

huggingface-cli download Qwen/Qwen3.6-35B-A3B \
    --local-dir /data/models/qwen3.6-35b-a3b

4. Launch the server.

FP8 on H100 SXM5:

vllm serve /data/models/qwen3.6-35b-a3b \
    --served-model-name qwen3.6-35b-a3b \
    --quantization fp8 \
    --gpu-memory-utilization 0.9 \
    --max-model-len 32768 \
    --port 8000

INT8 on A100 (no native FP8 tensor cores):

vllm serve /data/models/qwen3.6-35b-a3b \
    --served-model-name qwen3.6-35b-a3b \
    --quantization bitsandbytes \
    --gpu-memory-utilization 0.9 \
    --max-model-len 32768 \
    --port 8000

5. Test it.

curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "qwen3.6-35b-a3b",
        "messages": [{"role": "user", "content": "Describe what you see in one sentence."}],
        "max_tokens": 256
    }'

6. Benchmark before you commit budget. Run a load test against your real prompt shapes (with images, if that's your workload) and measure actual tokens/sec. Divide your GPU $/hr by that number to get a real CPM, then compare it against the Flash API tables above using your own input:output ratio, not the estimates in this post.

When to Just Use the Qwen3.7 Flash API Instead

If none of that settles it for you: run both. Flash is cheap enough on the API side that testing it costs very little, and a single H100 spot instance is cheap enough to test the self-hosted side too. The normalized math above favors Flash for input-heavy ratios, so run the numbers on your actual token mix before assuming self-hosting is cheaper.

If Qwen3.6-35B-A3B's vision-MoE profile fits your workload, an H100 SXM5 gets you FP8 inference with real KV cache headroom in a couple of minutes.

H100 on Spheron → | A100 GPU rental | Check current GPU pricing →