Qwen3.8-27B su vLLM: Servirlo in produzione su una o due GPU

Sì — Qwen3.8 27B gira in produzione su vLLM oggi, e su una singola GPU nella maggior parte dei casi. La versione che conta è vLLM 0.17.0 o successiva: include la ricetta ufficiale, i kernel di attenzione ibrida necessari per questo modello e un endpoint /v1 compatibile con OpenAI. Per una GPU Blackwell, esegui la quantizzazione NVFP4 — la ricetta di vLLM la misura a 24,6 GiB di VRAM con dimensione tensor-parallel 1. Per una singola scheda da 48 GB, esegui FP8. BF16 completo, un checkpoint da 51,7 GB, richiede una GPU da 80 GB o due schede da 48 GB in tensor-parallel. I comandi esatti sono sotto; il primo è un one-liner.

Tutto ciò che è riportato qui è stato verificato il 15 agosto 2026, il terzo giorno in cui i pesi erano live. Architettura, contesto e licenza provengono dalla scheda del modello Qwen3.8 27B su Hugging Face; la dimensione del checkpoint è la somma dei 18 shard safetensors del repository; i comandi vLLM e il dato di 24,6 GiB provengono dalla pagina recipe di vLLM per questo modello. Qwen3.8 27B è il modello multimodale denso da 27 miliardi di parametri di Ali​baba — pesi con licenza Apache 2.0, rilasciati tra il 13 e il 14 agosto — e poiché i pesi sono aperti, puoi servirlo da solo invece di noleggiare token. È proprio questo fork il vero argomento di questo articolo.

I fatti che contano, con le fonti

• Architettura — 27B dense (27,8B contando la torre di visione e il vocabolario con padding), 64 layer, dimensione nascosta 5.120, vocabolario 248.320. Scheda ufficiale del modello, verificata oggi.

• Attenzione — ibrido: 16 layer di attenzione completa, 48 layer lineari Gated DeltaNet in uno schema a blocchi 3:1. Solo 16 layer mantengono una cache chiave-valore in crescita; gli altri 48 mantengono invece uno stato ricorrente a dimensione fissa.

• Contesto — 262,144 token nativamente, estendibile a circa 1M tramite scaling YaRN RoPE. Scheda del modello, verificata oggi.

• Input — testo, immagine e video nativi; output di testo. vLLM espone tutti e tre tramite l'API standard chat-completions, senza file proiettore separato.

• Licenza — Apache 2.0. Questo singolo fatto è il motivo per cui esiste la domanda "servirselo da soli vs noleggiare i token".

• Pesi — il checkpoint BF16 ammonta a 51,7 GB su 18 shard safetensors (Hugging Face, verificato oggi). Qwe​n pubblica anche checkpoint FP8 e NVFP4 progettati per vLLM.

• requisito di vLLM — 0.17.0 o successiva, con transformers ≥ 5.8.0. La pagina delle ricette di vLLM, verificata oggi. "Qualunque vLLM" non è un'istruzione sicura; i kernel del livello ricorrente sono ciò che la nuova versione aggiunge.

• Predizione multi-token — una testa di bozza per la decodifica speculativa è inclusa nel checkpoint, quindi non serve un modello di bozza separato. vLLM documenta il flag; non esiste ancora una misura di accelerazione indipendente.

La scala GPU — quale quant su quale scheda

Tre formati di serving coprono la gamma pratica. Scegli in base alla VRAM che hai effettivamente, non in base al "best quant".

• NVFP4 — 24,6 GiB totali (pesi più una cache KV FP8), secondo la ricetta di vLLM su TP1. Si adatta a una singola GPU di classe Blackwell — in pratica una RTX 5090 da 32GB o una B200. Questo è il percorso a latenza più bassa e quello che mantiene più contesto per scheda: la ricetta di vLLM riporta una capacità di 6,6 milioni di token KV anche con l'estensione del contesto da 1M.

• FP8 — circa 26 GB di pesi. Una scheda da 48 GB (L40S, RTX A6000, RTX 6000 Ada) lo gestisce con spazio per il contesto; due schede da 48 GB in tensor-parallel offrono margine per contesti più lunghi o maggiore concorrenza. La ricetta di vLLM esegue FP8 con TP4 su un tray GB300 a quattro GPU quando si desidera la più grande cache KV possibile.

• BF16 — 51,7 GB di pesi, quindi una singola GPU da 80 GB (H100, A100 80GB, B200, GB300) o due schede da 48 GB in TP2. Questa è l'opzione a precisione di riferimento, ed è quella che il comando di estensione del contesto a 1M qui sotto usa effettivamente.

• MXFP4 — non utilizzare su NVIDIA. Il percorso MXFP4 di vLLM attualmente non supporta il metodo lineare; gli stessi pesi sono pubblicati come NVFP4, che è il formato effettivamente usato dalla ricetta NVIDIA.

Eseguilo — i comandi vLLM

La configurazione predefinita a GPU singola a bassa latenza (NVFP4, una GPU Blackwell), testualmente dalla ricetta di vLLM:

vllm serve Inferact/Qwen3.8-27B-NVFP4 --tensor-parallel-size 1 --max-model-len 262144 --kv-cache-dtype fp8 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder

Il comando FP8 della stessa ricetta (TP4, un vassoio GB300, la cache KV più grande):

vllm serve Qwen/Qwen3.8-27B-FP8 --tensor-parallel-size 4 --max-model-len 262144 --kv-cache-dtype fp8 --reasoning-parser qwen3

Per due schede da 48GB, mantieni il comando FP8 e imposta --tensor-parallel-size 2 invece di 4.

Aggiungi questo a uno dei due comandi per abilitare la decodifica speculativa MTP:

--speculative-config '{"method":"mtp","num_speculative_tokens":3}'

L'estensione del contesto da 1M (anche dalla ricetta di vLLM):

vllm serve Qwen/Qwen3.8-27B --max-model-len 1010000 --hf-overrides '{"text_config": {"max_position_embeddings": 1010000}}'

Point any O​penAI client at http://localhost:8000/v1 — the endpoint is a drop-in replacement. Two runtime details matter once it is up: thinking is on by default at reasoning_effort xhigh, so turn it off per request with chat_template_kwargs {"enable_thinking": false} or drop it to {"reasoning_effort": "low"} for faster answers. And the checkpoint ships temperature 1.0, top_p 0.95, top_k 20 in its generation config — pass those unless your app already overrides sampling.

Cosa promettono e cosa non promettono le pagine di vLLM

• Ancora nessun dato sul throughput per il 27B.Al 15 agosto, la pagina recipe di vLLM non pubblica benchmark di throughput o latenza per Qwen3.8 27B. Il dato "4.000+ token al secondo per GPU" che circola appartiene al Qwen3.8 2.4T-A95B su un rack GB300 NVL72 con 72 GPU, è riportato dal vendor e non riguarda questo modello. I valori di token al secondo della community che vedrete circolare per GGUF riguardano llama.cpp o Ollama — un runtime e un carico di lavoro diversi rispetto al serving con vLLM.

• L'affermazione sul KV-cache economico dipende dal runtime. La scheda del modello dice che solo 16 dei 64 layer mantengono una cache, ma questo aiuta solo se il motore di servizio implementa effettivamente i layer Gated DeltaNet. vLLM 0.17+ è la versione che lo fa; ecco perché il pin della versione è la prima cosa in questo articolo piuttosto che una nota a piè di pagina.

• MTP è integrato ma non misurato qui.La testa di draft è nel checkpoint e vLLM documenta il flag, ma nessuno ha ancora pubblicato una cifra indipendente di accelerazione per questo 27B su vLLM. Pianifica di misurarlo sul tuo traffico.

• NVIDIA è la strada collaudata.La ricetta di vLLM è scritta per GPU NVIDIA (NVFP4 e FP8). Le implementazioni su AMD Instinct o Intel Gaudi di questo modello ad attenzione ibrida sono ancora sperimentali, e questo articolo non pretende il contrario.

Servilo da solo, o noleggia i token

È qui che Apache 2.0 fa il suo lavoro. Non c'è alcuna tariffa di licenza per token su Qwen3.8 27B, quindi l'unica vera domanda è se possiedi l'hardware o noleggi i token.

• Self-host (questo articolo) — paghi la GPU una volta sola e ogni token successivo è gratuito. Una RTX 5090 che già possiedi rende il comando NVFP4 un endpoint a costo marginale zero, senza che alcun dato esca dalla macchina. Se devi noleggiare la GPU, una 5090 cloud o una coppia di A6000 è la voce di costo, e l'intero ragionamento regge solo se hai già la scheda o un volume d'uso sostenuto.

• Noleggia i token — poiché i pesi sono aperti, diversi host li eseguono, e il prezzo minimo è il costo dell'hardware. Qwen3.8 27B è disponibile su OrcaRouter oggi a $0,33 per milione di token in input e $2,40 per milione in output — nessun ricarico del fornitore da trasferire, dato che OrcaRouter esegue i pesi aperti sulla propria infrastruttura — e gli stessi pesi aperti finanziano un livello gratuito con limiti di frequenza che addebita $0 per richiesta e restituisce HTTP 429 quando superi il suo limite. Un mese rappresentativo di 10 milioni di token con il 70% di input costa circa $9,51 sul piano a pagamento.

• La regola decisionale — se possiedi già la GPU, fai self-hosting. Se dovessi acquistarne o noleggiarne una, l'API si ripaga in fretta ai volumi di un side project, e lo stesso client compatibile con O​penAI punta a entrambi gli endpoint, quindi il codice non cambia quando passi da uno all'altro.

Quando vLLM è la risposta sbagliata

• Sei una persona su un laptop — vLLM è un motore di serving, non un'app desktop. Per un'esecuzione locale a utente singolo, llama.cpp o Ollama con un Q4 GGUF è più semplice e richiede una scheda da 24GB, non una GPU Blackwell; la nostra guida su come eseguire Qwen3.8-27B in locale percorre quel percorso dall'inizio alla fine.

• Ti serve un throughput garantito con zero operazioni — self-hosting significa che sei tu a gestire il paging, le code e il failover. Se "l'API è giù" non è una frase che vuoi nel tuo vocabolario, affitta invece i token e lascia che sia qualcun altro a gestire la flotta.

• Hai davvero bisogno del contesto completo di ~1M con qualità all'avanguardia — è il compito di Qwen3.8 2.4T-A95B, gestito da vLLM o SGLang su un rack GB300 NVL72 con 72 GPU. Qwen3.8 27B su una o due GPU non lo eguaglierà; il nostro articolo sul serving del 2.4T spiega perché quel modello appartiene a una classe diversa di problemi.

• Hai una scheda 24GB più vecchia — NVFP4 è un formato Blackwell; sulle schede 24GB Ampere (RTX 3090) o Ada (RTX 4090), il percorso FP8 è l’opzione vLLM, e al di là di questo una quantizzazione GGUF tramite llama.cpp è la scelta pragmatica. Lo stesso modello su una scheda 24GB è un altro discorso.

• Devi gestire la massima concorrenza su una singola scheda — i valori predefiniti per singola GPU sopra indicati sono il punto di partenza, non la configurazione di produzione. Ottimizza --max-num-seqs, la cache KV e la configurazione MTP in base al tuo mix di richieste prima di considerare il lavoro concluso.

Il risultato finale

Qwen3.8 27B è il raro modello denso 27B che vLLM serve su una singola GPU in produzione. Aggiorna a vLLM 0.17.0+, scarica la quantizzazione NVFP4 per una scheda Blackwell da 32GB a 24,6 GiB, la quantizzazione FP8 per una scheda da 48GB o due in tensor-parallel, e riserva BF16 per una GPU da 80GB. I comandi sono one-liner, l'endpoint è compatibile con O​penAI e, poiché i pesi sono sotto licenza Apache 2.0, puoi servirlo da solo o noleggiarlo a $0,33/$2,40 per milione di token con un piano gratuito — in entrambi i casi lo stesso codice client. L'unica cosa che nessuno ha ancora è un numero di throughput indipendente per il 27B su vLLM, quindi prevedi un'ora di benchmark dopo averlo avviato prima di promettere a chiunque un numero di latenza.