Fournisseurs de modèles

Qwen Code vous permet de configurer plusieurs fournisseurs de modèles via le paramètre modelProviders dans votre fichier settings.json. Cela vous permet de basculer entre différents modèles et fournisseurs d’IA à l’aide de la commande /model.

Aperçu

Utilisez modelProviders pour déclarer des listes de modèles préconfigurés, spécifiques à chaque type d’authentification, entre lesquelles le sélecteur /model peut basculer. Les clés doivent correspondre à des types d’authentification valides (openai, anthropic, gemini, etc.). Chaque entrée requiert un champ id et doit inclure le champ envKey, les champs name, description, baseUrl et generationConfig étant facultatifs. Les identifiants ne sont jamais persistés dans les paramètres ; le runtime les lit depuis process.env[envKey]. Les modèles Qwen utilisant l’authentification OAuth restent codés en dur et ne peuvent pas être remplacés.

Exemples de configuration par type d’authentification

Ci-dessous figurent des exemples complets de configuration pour différents types d’authentification, illustrant les paramètres disponibles et leurs combinaisons.

Types d’authentification pris en charge

Les clés de l’objet modelProviders doivent correspondre à des valeurs valides de authType. Les types d’authentification actuellement pris en charge sont les suivants :

[!warning] Si une clé de type d’authentification non valide est utilisée (par exemple, une faute de frappe comme "openai-custom"), la configuration sera ignorée silencieusement, et les modèles n’apparaîtront pas dans le sélecteur /model. Utilisez toujours l’un des types d’authentification pris en charge listés ci-dessus.

SDK utilisés pour les requêtes API

Qwen Code utilise les SDK officiels suivants pour envoyer des requêtes à chaque fournisseur :

Cela signifie que l’URL de base (baseUrl) que vous configurez doit être compatible avec le format d’API attendu par le SDK correspondant. Par exemple, lors de l’utilisation du type d’authentification openai, le point de terminaison doit accepter des requêtes au format de l’API OpenAI.

Fournisseurs compatibles OpenAI (openai)

Ce type d’authentification prend en charge non seulement l’API officielle d’OpenAI, mais aussi tout point de terminaison compatible OpenAI, y compris les fournisseurs agrégés de modèles tels qu’OpenRouter.

{
  "modelProviders": {
    "openai": [
      {
        "id": "gpt-4o",
        "name": "GPT-4o",
        "envKey": "OPENAI_API_KEY",
        "baseUrl": "https://api.openai.com/v1",
        "generationConfig": {
          "timeout": 60000,
          "maxRetries": 3,
          "enableCacheControl": true,
          "contextWindowSize": 128000,
          "modalities": {
            "image": true
          },
          "customHeaders": {
            "X-Client-Request-ID": "req-123"
          },
          "extra_body": {
            "enable_thinking": true,
            "service_tier": "priority"
          },
          "samplingParams": {
            "temperature": 0.2,
            "top_p": 0.8,
            "max_tokens": 4096,
            "presence_penalty": 0.1,
            "frequency_penalty": 0.1
          }
        }
      },
      {
        "id": "gpt-4o-mini",
        "name": "GPT-4o Mini",
        "envKey": "OPENAI_API_KEY",
        "baseUrl": "https://api.openai.com/v1",
        "generationConfig": {
          "timeout": 30000,
          "samplingParams": {
            "temperature": 0.5,
            "max_tokens": 2048
          }
        }
      },
      {
        "id": "openai/gpt-4o",
        "name": "GPT-4o (via OpenRouter)",
        "envKey": "OPENROUTER_API_KEY",
        "baseUrl": "https://openrouter.ai/api/v1",
        "generationConfig": {
          "timeout": 120000,
          "maxRetries": 3,
          "samplingParams": {
            "temperature": 0.7
          }
        }
      }
    ]
  }
}

Anthropic (anthropic)

{
  "modelProviders": {
    "anthropic": [
      {
        "id": "claude-3-5-sonnet",
        "name": "Claude 3.5 Sonnet",
        "envKey": "ANTHROPIC_API_KEY",
        "baseUrl": "https://api.anthropic.com/v1",
        "generationConfig": {
          "timeout": 120000,
          "maxRetries": 3,
          "contextWindowSize": 200000,
          "samplingParams": {
            "temperature": 0.7,
            "max_tokens": 8192,
            "top_p": 0.9
          }
        }
      },
      {
        "id": "claude-3-opus",
        "name": "Claude 3 Opus",
        "envKey": "ANTHROPIC_API_KEY",
        "baseUrl": "https://api.anthropic.com/v1",
        "generationConfig": {
          "timeout": 180000,
          "samplingParams": {
            "temperature": 0.3,
            "max_tokens": 4096
          }
        }
      }
    ]
  }
}

Google Gemini (gemini)

{
  "modelProviders": {
    "gemini": [
      {
        "id": "gemini-2.0-flash",
        "name": "Gemini 2.0 Flash",
        "envKey": "GEMINI_API_KEY",
        "baseUrl": "https://generativelanguage.googleapis.com",
        "capabilities": {
          "vision": true
        },
        "generationConfig": {
          "timeout": 60000,
          "maxRetries": 2,
          "contextWindowSize": 1000000,
          "schemaCompliance": "auto",
          "samplingParams": {
            "temperature": 0.4,
            "top_p": 0.95,
            "max_tokens": 8192,
            "top_k": 40
          }
        }
      }
    ]
  }
}

Modèles locaux auto-hébergés (via API compatible OpenAI)

La plupart des serveurs d’inférence locaux (vLLM, Ollama, LM Studio, etc.) fournissent un point de terminaison d’API compatible avec OpenAI. Configurez-les en utilisant le type d’authentification openai avec une baseUrl locale :

{
  "modelProviders": {
    "openai": [
      {
        "id": "qwen2.5-7b",
        "name": "Qwen2.5 7B (Ollama)",
        "envKey": "OLLAMA_API_KEY",
        "baseUrl": "http://localhost:11434/v1",
        "generationConfig": {
          "timeout": 300000,
          "maxRetries": 1,
          "contextWindowSize": 32768,
          "samplingParams": {
            "temperature": 0.7,
            "top_p": 0.9,
            "max_tokens": 4096
          }
        }
      },
      {
        "id": "llama-3.1-8b",
        "name": "Llama 3.1 8B (vLLM)",
        "envKey": "VLLM_API_KEY",
        "baseUrl": "http://localhost:8000/v1",
        "generationConfig": {
          "timeout": 120000,
          "maxRetries": 2,
          "contextWindowSize": 128000,
          "samplingParams": {
            "temperature": 0.6,
            "max_tokens": 8192
          }
        }
      },
      {
        "id": "local-model",
        "name": "Modèle local (LM Studio)",
        "envKey": "LMSTUDIO_API_KEY",
        "baseUrl": "http://localhost:1234/v1",
        "generationConfig": {
          "timeout": 60000,
          "samplingParams": {
            "temperature": 0.5
          }
        }
      }
    ]
  }
}

Pour les serveurs locaux ne nécessitant pas d’authentification, vous pouvez utiliser n’importe quelle valeur factice pour la clé API :

 
# Pour Ollama (aucune authentification requise)
export OLLAMA_API_KEY="ollama"
 
# Pour vLLM (si aucune authentification n’est configurée)
export VLLM_API_KEY="non-nécessaire"

Plan de codage Alibaba Cloud

Le Plan de codage Alibaba Cloud fournit un ensemble préconfiguré de modèles Qwen optimisés pour les tâches de programmation. Cette fonctionnalité est disponible pour les utilisateurs disposant d’un accès à l’API du Plan de codage Alibaba Cloud et offre une configuration simplifiée avec des mises à jour automatiques de la configuration des modèles.

Aperçu

Lorsque vous vous authentifiez avec une clé API Alibaba Cloud Coding Plan à l’aide de la commande /auth, Qwen Code configure automatiquement les modèles suivants :

Configuration

1. Obtenez une clé API Alibaba Cloud Coding Plan :
   • Chine : https://bailian.console.aliyun.com/?tab=model#/efm/coding_plan 
   • International : https://modelstudio.console.alibabacloud.com/?tab=dashboard#/efm/coding_plan 
2. Exécutez la commande /auth dans Qwen Code
3. Sélectionnez Alibaba Cloud Coding Plan
4. Sélectionnez votre région
5. Entrez votre clé API lorsque vous y êtes invité

Les modèles seront automatiquement configurés et ajoutés à votre sélecteur /model.

Régions

Le plan de codage Alibaba Cloud prend en charge deux régions :

La région est sélectionnée lors de l’authentification et stockée dans le fichier settings.json, sous la clé codingPlan.region. Pour changer de région, réexécutez la commande /auth et sélectionnez une autre région.

Stockage de la clé API

Lorsque vous configurez Coding Plan via la commande /auth, la clé API est stockée en utilisant le nom de variable d’environnement réservé BAILIAN_CODING_PLAN_API_KEY. Par défaut, elle est stockée dans le champ env de votre fichier settings.json.

# ~/.qwen/.env
BAILIAN_CODING_PLAN_API_KEY=votre-clé-api-ici

Mises à jour automatiques

Les configurations des modèles de planification de code sont versionnées. Lorsque Qwen Code détecte une version plus récente du modèle, vous êtes invité à effectuer la mise à jour. En l’acceptant, les actions suivantes sont réalisées :

• Remplacement des configurations existantes du modèle de planification de code par leurs versions les plus récentes
• Conservation de toute configuration de modèle personnalisée que vous avez ajoutée manuellement
• Passage automatique au premier modèle figurant dans la configuration mise à jour

Ce processus de mise à jour garantit que vous disposez toujours des dernières configurations et fonctionnalités des modèles, sans intervention manuelle.

Configuration manuelle (avancé)

Si vous préférez configurer manuellement les modèles Coding Plan, vous pouvez les ajouter à votre fichier settings.json comme n’importe quel fournisseur compatible OpenAI :

{
  "modelProviders": {
    "openai": [
      {
        "id": "qwen3-coder-plus",
        "name": "qwen3-coder-plus",
        "description": "Qwen3-Coder via le plan Coding d’Alibaba Cloud",
        "envKey": "VOTRE_CLE_ENV_PERSONNALISEE",
        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1"
      }
    ]
  }
}

Couches de résolution et atomicité

Les valeurs effectives d’authentification, de modèle et d’identifiants sont choisies pour chaque champ selon la priorité suivante (la première valeur présente l’emporte). Vous pouvez combiner --auth-type avec --model pour cibler directement une entrée de fournisseur ; ces indicateurs CLI sont traités avant les autres couches.

*Lorsqu’elles sont présentes, les options d’authentification CLI remplacent les paramètres. Sinon, le type d’authentification est déterminé par security.auth.selectedType ou par la valeur implicite par défaut. Qwen OAuth et OpenAI sont les seuls types d’authentification disponibles sans configuration supplémentaire.

Superposition des configurations de génération : la couche fournisseur imperméable

La résolution des configurations suit un modèle de superposition strict avec une règle cruciale : la couche modelProvider est imperméable.

Fonctionnement

1. Lorsqu’un modèle modelProvider EST sélectionné (par exemple, via la commande /model en choisissant un modèle configuré par un fournisseur) :

   • L’ensemble de la configuration generationConfig provenant du fournisseur est appliqué de façon atomique
   • La couche fournisseur est totalement imperméable : les couches inférieures (CLI, variables d’environnement, paramètres) ne participent aucunement à la résolution de generationConfig
   • Tous les champs définis dans modelProviders[].generationConfig utilisent les valeurs fournies par le fournisseur
   • Tous les champs non définis par le fournisseur sont fixés à undefined (ils ne sont pas hérités des paramètres)
   • Cela garantit que les configurations fournisseurs agissent comme un « package scellé » complet et autonome

2. Lorsqu’aucun modèle modelProvider n’est sélectionné (par exemple, en utilisant l’option --model avec un identifiant brut de modèle, ou en utilisant directement la CLI / les variables d’environnement / les paramètres) :

   • La résolution se propage aux couches inférieures
   • Les champs sont remplis selon l’ordre suivant : CLI → variables d’environnement → paramètres → valeurs par défaut
   • Cela crée un modèle d’exécution (voir la section suivante)

Priorité par champ pour generationConfig

Traitement atomique des champs

Les champs suivants sont traités comme des objets atomiques : les valeurs fournies par le fournisseur remplacent entièrement l’objet, aucune fusion n’est effectuée :

• samplingParams — Température, top_p, max_tokens, etc.
• customHeaders — En-têtes HTTP personnalisés
• extra_body — Paramètres supplémentaires du corps de la requête

Exemple

// Paramètres utilisateur (~/.qwen/settings.json)
{
  "model": {
    "generationConfig": {
      "timeout": 30000,
      "samplingParams": { "temperature": 0.5, "max_tokens": 1000 }
    }
  }
}
 
// Configuration modelProviders
{
  "modelProviders": {
    "openai": [{
      "id": "gpt-4o",
      "envKey": "OPENAI_API_KEY",
      "generationConfig": {
        "timeout": 60000,
        "samplingParams": { "temperature": 0.2 }
      }
    }]
  }
}

Lorsque gpt-4o est sélectionné depuis modelProviders :

• timeout = 60000 (provenant du fournisseur, remplace les paramètres utilisateur)
• samplingParams.temperature = 0.2 (provenant du fournisseur, remplace entièrement l’objet samplingParams des paramètres utilisateur)
• samplingParams.max_tokens = indéfini (non défini dans la configuration du fournisseur, et la couche fournisseur n’hérite pas des paramètres utilisateur — les champs non fournis sont explicitement définis à undefined)

Lorsqu’un modèle brut est utilisé via --model gpt-4 (pas issu de modelProviders, crée un modèle exécuté à l’exécution) :

• timeout = 30000 (provenant des paramètres utilisateur)
• samplingParams.temperature = 0.5 (provenant des paramètres utilisateur)
• samplingParams.max_tokens = 1000 (provenant des paramètres utilisateur)

La stratégie de fusion pour modelProviders est le REMPLACEMENT : l’ensemble de la section modelProviders provenant des paramètres du projet remplace entièrement la section correspondante des paramètres utilisateur, au lieu de fusionner les deux.

Modèles fournisseurs vs modèles d’exécution

Qwen Code distingue deux types de configurations de modèles :

Modèle fournisseur

• Défini dans la configuration modelProviders
• Dispose d’un ensemble de configuration complet et atomique
• Lorsqu’il est sélectionné, sa configuration est appliquée comme une couche imperméable
• Apparaît dans la liste des commandes /model avec tous ses métadonnées (nom, description, fonctionnalités)
• Recommandé pour les flux de travail multi-modèles et la cohérence au sein des équipes

Modèle d’exécution

• Créé dynamiquement lors de l’utilisation d’identifiants bruts de modèle via l’interface CLI (--model), des variables d’environnement ou des paramètres
• Non défini dans modelProviders
• Sa configuration est construite en « projetant » à travers plusieurs couches de résolution (CLI → variable d’environnement → paramètres → valeurs par défaut)
• Capturé automatiquement sous forme de RuntimeModelSnapshot dès qu’une configuration complète est détectée
• Permet une réutilisation sans avoir à saisir à nouveau les identifiants

Cycle de vie de RuntimeModelSnapshot

Lorsque vous configurez un modèle sans utiliser modelProviders, Qwen Code crée automatiquement un RuntimeModelSnapshot afin de conserver votre configuration :

 
# Cette commande crée un RuntimeModelSnapshot avec l’identifiant : $runtime|openai|my-custom-model
qwen --auth-type openai --model my-custom-model --openaiApiKey $KEY --openaiBaseUrl https://api.example.com/v1

Ce snapshot :

• Capture l’identifiant du modèle, la clé API, l’URL de base et la configuration de génération ;
• Persiste entre les sessions (stocké en mémoire pendant l’exécution) ;
• Apparaît dans la liste des options runtime de la commande /model ;
• Peut être sélectionné à l’aide de /model $runtime|openai|my-custom-model.

Principales différences

Quand utiliser chacun

• Utilisez les modèles fournisseurs lorsque : vous disposez de modèles standard partagés au sein d’une équipe, vous avez besoin de configurations cohérentes ou vous souhaitez éviter les remplacements accidentels.
• Utilisez les modèles d’exécution lorsque : vous testez rapidement un nouveau modèle, utilisez des identifiants temporaires ou travaillez avec des points de terminaison ponctuels.

Persistance de la sélection et recommandations

• /model et /auth persistent model.name (le cas échéant) et security.auth.selectedType dans le domaine modifiable le plus proche qui définit déjà modelProviders ; à défaut, ils se rabattent sur le domaine utilisateur. Cela maintient la synchronisation entre les fichiers de l’espace de travail et de l’utilisateur et le catalogue de fournisseurs actif.
• En l’absence de modelProviders, le résolveur mélange les couches CLI, variables d’environnement et paramètres, créant ainsi des modèles d’exécution (Runtime Models). Cela fonctionne correctement dans les configurations à fournisseur unique, mais devient contraignant lors de changements fréquents. Définissez des catalogues de fournisseurs dès que des workflows multi-modèles sont courants, afin que les changements restent atomiques, attribués à leur source et débogables.