AGAnchorGPU

Guide per carichi di lavoro

Servire un LLM con vLLM

Pianifica memoria e concorrenza, configura un endpoint vLLM e valida un carico di lavoro di inferenza rappresentativo.

9 min di lettura · Aggiornato

Definisci il contratto di serving

Registra l'identificativo e la revisione del modello, il formato dei pesi, la quantizzazione, la lunghezza massima del contesto, la distribuzione della lunghezza dei prompt, la concorrenza e l'obiettivo di latenza. Queste impostazioni fanno parte del carico di lavoro, non sono note di benchmark opzionali.

I pesi condividono la memoria GPU con la cache KV e gli spazi di lavoro temporanei. Un modello che si carica correttamente con un prompt breve può comunque esaurire la memoria sotto il traffico previsto. Mantenere un margine operativo e testare le richieste più lunghe consentite.

Inizia con una GPU quando è sufficiente

Una singola GPU evita la comunicazione tra GPU e rende più semplice diagnosticare un primo deployment. Considera il parallelismo tensoriale quando il modello e lo stato di runtime richiesto non entrano in un singolo acceleratore, o quando una misurazione rappresentativa giustifica la divisione.

Le repliche indipendenti servono richieste separate; il parallelismo tensoriale divide il calcolo del modello. Risolvono problemi diversi. Un nodo del catalogo con più schede non dimostra, di per sé, una particolare interconnessione.

Confronta H100 SXM con H100 PCIe

Qualifica l'ambiente completo

L'immagine vllm di AnchorGPU è disponibile per NVIDIA e AMD nel catalogo. Prima dell'esecuzione reale, identifica il driver effettivo, il runtime CUDA o ROCm, le versioni di PyTorch, Python e vLLM. Verifica insieme l'architettura del modello, il supporto della quantizzazione e gli eventuali kernel di attention compilati.

Questo sito locale salva le configurazioni ma non esegue un server di modelli remoto. I comandi seguenti appartengono a un vero nodo Linux provisioned con il software richiesto e l'accesso ai modelli.

Avvia un endpoint privato

Imposta il modello e una chiave API privata nella shell usata per avviare il server. Sostituisci entrambi i segnaposto. La chiave è una credenziale di serving vLLM, non la chiave API del tuo account AnchorGPU. Esegui il binding su loopback durante la validazione; l'accesso remoto richiede un percorso TLS autenticato o su rete privata.

export MODEL_ID="your-organization/your-model"
export VLLM_API_KEY="replace-with-a-private-serving-key"
vllm serve "$MODEL_ID" --host 127.0.0.1 --port 8000

Per un modello diviso intenzionalmente su quattro GPU visibili sullo stesso nodo, aggiungi --tensor-parallel-size 4. Conferma la disposizione hardware e il supporto software prima di apportare la modifica.

Controlla l'API prima del test di carico

In un'altra shell, imposta la stessa chiave VLLM_API_KEY e interroga l'elenco dei modelli. Una richiesta di completamento chat richiede inoltre un modello con un template di chat appropriato; un avvio riuscito del server non garantisce che ogni attività API sia supportata.

curl http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer $VLLM_API_KEY"

Usa l'identificatore del modello riportato dal server nelle richieste del client. Mantieni l'autenticazione abilitata durante i test.

Misura la capacità sostenuta

Ripeti richieste sanificate con le lunghezze di prompt previste, i limiti di output e la concorrenza. Registra il tempo al primo token, la latenza end-to-end, il throughput, il tasso di errore, l'uso della memoria GPU e la capacità della cache KV riportata dal server.

Misurare il caricamento a freddo del modello separatamente dal servizio a regime. Aumentare gradualmente la concorrenza. Se il limite è la memoria, valutare un contesto/concurrency inferiore, un formato di quantizzazione adatto o più memoria prima di presumere che più potenza di calcolo possa aiutare.

Converti il lavoro completato in costo utilizzando il prezzo fisso di prenotazione. Un numero di token al secondo di primo piano non è una promessa di capacità e non rivendichiamo risultati benchmark AnchorGPU in questa guida.

Risolvi le modalità di errore comuni

Richiesta chat non riuscita: verificare il template di chat del modello e l'attività API supportata. Errore di memoria dopo l'aumento del carico: verificare la pressione della cache KV, il contesto e la concorrenza. Blocco dell'inizializzazione multi-GPU: confermare i dispositivi visibili, le librerie collettive e la validità della suddivisione tensor-parallel.

Salva la revisione del modello, il digest del container, la configurazione di avvio, i risultati della validazione e il contratto API del client. Copia gli artefatti operativi lontano dal nodo prima di rilasciarlo.

Leggi la guida al ciclo di vita delle istanze

Fonti e approfondimenti

Installazione GPU vLLMParallelismo e scalabilità di vLLMAvvio rapido e autenticazione vLLMServing online vLLM
Configura un nodo di inferenza