serve-config-guide

Par nvidia · skills

Générez un `trtllm-serve --config` YAML de départ étayé par des sources pour

npx skills add https://github.com/nvidia/skills --skill serve-config-guide

Guide de Configuration Serve

Périmètre : prefill+decode colocalisés agrégés/IFB (batching en vol), nœud unique, backend PyTorch, non-spéculatif par défaut ; DeepSeek-R1 MTP est le mode standard (tous les configs enregistrés incluent MTP).

Entrée : modèle, GPU, ISL (longueur de séquence d'entrée), OSL (longueur de séquence de sortie), concurrence, TP, objectif de performance (Min Latency | Balanced | Max Throughput | non spécifié). Sortie : YAML de démarrage ancré au repository pour trtllm-serve --config.

Si la requête est adjacente mais hors périmètre, fournissez une réponse au mieux de vos efforts en utilisant le config in-scope le plus proche comme point de départ, étiquetez clairement les champs déduits vs. vérifiés, et pointez vers la doc de feature pertinente dans docs/source/features/ (ex. speculative-decoding, disagg-serving, parallel-strategy) ou examples/llm-api/.

Contraintes

  1. Exclusion spéculative : Excluez les configs contenant speculative_config par défaut. Exception : configs DeepSeek-R1 MTP exacts enregistrés (modèles avec decoding_type: MTP dans examples/configs/). Lors de l'inclusion de MTP, copiez le bloc speculative_config complet verbatim — ne l'interpolez jamais.

  2. Préservation de l'objectif : Préservez l'objectif énoncé par l'utilisateur via la sélection de config. Utilisez les étiquettes de profil de database.py (Min Latency, Balanced, Max Throughput ; plus Low Latency/High Throughput dans les ensembles plus petits) comme aides de sélection. Si un config n'est pas étiqueté, traitez-le comme point de départ par défaut — ne prétendez pas qu'il correspond à un objectif spécifique. Si la seule correspondance entre en conflit avec l'objectif énoncé, signalez le désaccord.

  3. Préférence de source : Préférez les configs enregistrés à l'interpolation. Quand les docs et configs divergent, préférez le config pour le scénario exact et notez le désaccord. Marquez toute interpolation comme non vérifiée.

Format de Réponse

Pour les correspondances exactes : ConfigSourceCommande de lancement

Pour les configs interpolés : ConfigSource utilisée comme point de départCe qu'il faut évaluer (liste unique des paramètres à balayer, pas d'étiquettes non vérifiées par champ)

Étape 0 : Verrouiller Objectif et Mode de Décodage

Identifiez l'objectif de l'utilisateur (Min Latency | Balanced | Max Throughput | non spécifié) et le mode de décodage (non-spéculatif ou DeepSeek-R1 MTP selon la Contrainte 1). Préservez-les tous deux dans les étapes restantes.

Étape 1 : Correspondance Exacte en Base de Données

Recherchez dans examples/configs/database/lookup.yaml une correspondance exacte (model, gpu, isl, osl, concurrency, num_gpus). Utilisez database.py comme chargeur/assistant.

  • Appliquez l'exclusion spéculative.
  • Quand plusieurs recettes existent à différents points de concurrence, utilisez les étiquettes de profil pour correspondre à l'objectif de l'utilisateur selon la préservation d'objectif.
  • Préférez une correspondance exacte qui correspond aussi à l'objectif énoncé plutôt qu'un réglage manuel.

Étape 2 : Config Enregistré le Plus Proche

Si aucune correspondance exacte, élargissez la recherche pour inclure aussi examples/configs/curated/lookup.yaml.

Appliquez les mêmes contraintes qu'à l'Étape 1. De plus :

  • Une correspondance partielle de database/ est préférée à une correspondance partielle de curated/ pour le même modèle (les configs database sont réglés par benchmark).
  • Excluez les entrées désagrégées uniquement ou prefill uniquement (ex. qwen3-disagg-prefill.yaml).
  • Pour les configs curés, ne traitez l'intention comme explicite que quand le repo la label (ex. *-latency.yaml, *-throughput.yaml, ou texte guide).
  • Si aucun config in-scope ne correspond à l'objectif énoncé, choisissez le point de départ du même modèle le plus proche et signalez le désaccord.

Étape 3 : Lire les Docs du Modèle

Recherchez dans docs/source/deployment-guide/ et examples/models/core/ le guide de déploiement du modèle et le README. Lisez-les avant d'ajuster des paramètres.

Sources exclues : N'UTILISEZ PAS les valeurs de tuning ou nombres de benchmark de docs/source/legacy/ — ceux-ci ont été mesurés sur le backend de construction du moteur TensorRT et ne se transfèrent pas au serving backend PyTorch.

Mise en garde DeepSeek-V3 : Pour DeepSeek-V3/V3.2-Exp, utilisez examples/models/core/deepseek_v3/README.md, pas le guide de déploiement R1.

Étape 4 : Ajuster les Champs Appuyés par Source

Champs généralement dépendants du scénario (n'ajustez que ceux-ci, guidés par la source enregistrée) :

max_batch_size, max_num_tokens, max_seq_len, enable_attention_dp, attention_dp_config.*, kv_cache_config.free_gpu_memory_fraction, moe_expert_parallel_size (MoE), moe_config.backend (quand le guide le spécifie), stream_interval, num_postprocess_workers, cuda_graph_config.max_batch_size/batch_sizes, et champs spécifiques à MTP lors de l'utilisation de configs DeepSeek-R1 MTP.

Ne supposez pas que d'autres champs sont constants entre modèles/GPUs. Pour les notes de tuning, lisez references/knob-heuristics.md.

Checklist de Validation

  • [ ] trust_remote_code: true signalé comme limite de confiance quand présent
  • [ ] max_num_tokens >= ISL + frais du template chat (requêtes rejetées si violé)
  • [ ] Si interpolé : section unique « Ce qu'il faut évaluer » listant les paramètres à balayer, pas d'étiquettes non vérifiées par champ

Skills similaires