Fournisseurs de modèles

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

Vue d’ensemble

Utilisez modelProviders pour déclarer des listes de modèles prédéfinies par 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 nécessite un id et doit inclure envKey, avec des champs optionnels name, description, baseUrl et generationConfig. Les identifiants ne sont jamais persistés dans les paramètres ; le runtime les lit depuis process.env[envKey]. Les modèles Qwen OAuth restent codés en dur et ne peuvent pas être remplacés.

Exemples de configuration par type d’authentification

Voici des exemples de configuration complets 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 être des valeurs authType valides. Les types d’authentification actuellement pris en charge sont :

[!warning] Si une clé de type d’authentification invalide est utilisée (ex. 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’une des valeurs de type d’authentification prises en charge listées 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 le 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 les 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 de modèles agrégés comme OpenRouter.

{
  "env": {
    "OPENAI_API_KEY": "sk-your-actual-openai-key-here",
    "OPENROUTER_API_KEY": "sk-or-your-actual-openrouter-key-here"
  },
  "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)

{
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-your-actual-anthropic-key-here"
  },
  "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)

{
  "env": {
    "GEMINI_API_KEY": "AIza-your-actual-gemini-key-here"
  },
  "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 OpenAI. Configurez-les en utilisant le type d’authentification openai avec un baseUrl local :

{
  "env": {
    "OLLAMA_API_KEY": "ollama",
    "VLLM_API_KEY": "not-needed",
    "LMSTUDIO_API_KEY": "lm-studio"
  },
  "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": "Local Model (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 fictive 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="not-needed"

Alibaba Cloud Coding Plan

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

Présentation

Lorsque vous vous authentifiez avec une clé API Alibaba Cloud Coding Plan via 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. Saisissez votre clé API lorsqu’elle vous est demandée

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

Régions

Alibaba Cloud Coding Plan prend en charge deux régions :

La région est sélectionnée lors de l’authentification et stockée dans settings.json sous codingPlan.region. Pour changer de région, relancez 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 à l’aide du 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=your-api-key-here

Mises à jour automatiques

Les configurations des modèles Coding Plan sont versionnées. Lorsque Qwen Code détecte une version plus récente du modèle de configuration, vous serez invité à effectuer une mise à jour. Accepter la mise à jour aura pour effet de :

• Remplacer les configurations existantes des modèles Coding Plan par les dernières versions
• Préserver toutes les configurations de modèles personnalisées que vous avez ajoutées manuellement
• Basculer automatiquement vers le premier modèle de la configuration mise à jour

Le 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 settings.json comme n’importe quel fournisseur compatible OpenAI :

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

Couches de résolution et atomicité

Les valeurs effectives d’authentification/modèle/identifiants sont choisies par champ selon la précédence suivante (la première présente l’emporte). Vous pouvez combiner --auth-type avec --model pour pointer directement vers une entrée de fournisseur ; ces flags CLI s’exécutent avant les autres couches.

*Lorsqu’ils sont présents, les flags d’authentification CLI remplacent les paramètres. Sinon, security.auth.selectedType ou la valeur par défaut implicite détermine le type d’authentification. Qwen OAuth et OpenAI sont les seuls types d’authentification exposés sans configuration supplémentaire.

Superposition de la configuration de génération : La couche fournisseur imperméable

La résolution de la configuration 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é (ex. via la commande /model choisissant un modèle configuré par fournisseur) :

   • L’intégralité du generationConfig du fournisseur est appliquée atomiquement
   • La couche fournisseur est complètement imperméable — les couches inférieures (CLI, env, paramètres) ne participent pas du tout à la résolution de generationConfig
   • Tous les champs définis dans modelProviders[].generationConfig utilisent les valeurs du fournisseur
   • Tous les champs non définis par le fournisseur sont définis sur undefined (et non hérités des paramètres)
   • Cela garantit que les configurations de fournisseur agissent comme un “paquet scellé” complet et autonome

2. Lorsqu’AUCUN modèle modelProvider n’est sélectionné (ex. utilisation de --model avec un ID de modèle brut, ou utilisation directe de CLI/env/paramètres) :

   • La résolution passe aux couches inférieures
   • Les champs sont renseignés depuis CLI → env → paramètres → valeurs par défaut
   • Cela crée un Modèle Runtime (voir section suivante)

Précédence par champ pour generationConfig

Traitement atomique des champs

Les champs suivants sont traités comme des objets atomiques : les valeurs du fournisseur remplacent complètement l’objet entier, aucune fusion n’a lieu :

• 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

// User settings (~/.qwen/settings.json)
{
  "model": {
    "generationConfig": {
      "timeout": 30000,
      "samplingParams": { "temperature": 0.5, "max_tokens": 1000 }
    }
  }
}
 
// modelProviders configuration
{
  "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 (depuis le fournisseur, remplace les paramètres)
• samplingParams.temperature = 0.2 (depuis le fournisseur, remplace complètement l’objet des paramètres)
• samplingParams.max_tokens = undefined (non défini dans le fournisseur, et la couche fournisseur n’hérite pas des paramètres — les champs sont explicitement définis sur undefined s’ils ne sont pas fournis)

Lors de l’utilisation d’un modèle brut via --model gpt-4 (non issu de modelProviders, crée un Modèle Runtime) :

• timeout = 30000 (depuis les paramètres)
• samplingParams.temperature = 0.5 (depuis les paramètres)
• samplingParams.max_tokens = 1000 (depuis les paramètres)

La stratégie de fusion pour modelProviders lui-même est REPLACE : l’intégralité de modelProviders des paramètres du projet remplacera la section correspondante dans les paramètres utilisateur, au lieu de fusionner les deux.

Configuration du raisonnement / réflexion

Le champ optionnel reasoning sous generationConfig contrôle l’intensité du raisonnement du modèle avant de répondre. Les convertisseurs Anthropic et Gemini le respectent toujours. Le pipeline compatible OpenAI le respecte sauf si generationConfig.samplingParams est défini — voir la mise en garde “Interaction avec samplingParams” ci-dessous.

{
  "modelProviders": {
    "openai": [
      {
        "id": "deepseek-v4-pro",
        "name": "DeepSeek V4 Pro",
        "baseUrl": "https://api.deepseek.com/v1",
        "envKey": "DEEPSEEK_API_KEY",
        "generationConfig": {
          // The four-tier scale:
          //   'low'    | 'medium' — server-mapped to 'high' on DeepSeek
          //   'high'   — default reasoning intensity
          //   'max'    — DeepSeek-specific extra-strong tier
          // Or set `false` to disable reasoning entirely.
          "reasoning": { "effort": "max" },
        },
      },
    ],
  },
}

Comportement par fournisseur

reasoning: false

Définir reasoning: false (le booléen littéral) désactive explicitement la réflexion sur tous les fournisseurs — utile pour les requêtes secondaires peu coûteuses qui ne bénéficient pas du raisonnement. Ceci est également respecté au niveau de la requête via request.config.thinkingConfig.includeThoughts: false pour les appels ponctuels (ex. génération de suggestions).

Sur un baseUrl api.deepseek.com, le pipeline OpenAI émet le champ explicite thinking: { type: 'disabled' } requis par DeepSeek V4+ — la valeur par défaut côté serveur est 'enabled', donc omettre simplement reasoning_effort entraînerait tout de même une latence/coût de réflexion. Les backends DeepSeek auto-hébergés (sglang/vllm) et les autres serveurs compatibles OpenAI ne reçoivent pas ce champ ; si vous devez désactiver la réflexion sur ceux-ci, injectez thinking: { type: 'disabled' } (ou tout autre paramètre exposé par votre framework d’inférence) via samplingParams/extra_body.

Interaction avec samplingParams (uniquement compatible OpenAI)

budget_tokens

Vous pouvez définir un budget exact de tokens de réflexion en incluant budget_tokens aux côtés de effort :

"reasoning": { "effort": "high", "budget_tokens": 50000 }

Pour Anthropic, cela devient thinking.budget_tokens. Pour OpenAI/DeepSeek, le champ est conservé mais actuellement ignoré par le serveur — reasoning_effort est le paramètre déterminant.

Modèles fournisseur vs Modèles Runtime

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

Modèle fournisseur

• Défini dans la configuration modelProviders
• Dispose d’un package 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 de la commande /model avec des métadonnées complètes (nom, description, capacités)
• Recommandé pour les workflows multi-modèles et la cohérence d’équipe

Modèle Runtime

• Créé dynamiquement lors de l’utilisation d’IDs de modèles bruts via CLI (--model), variables d’environnement ou paramètres
• Non défini dans modelProviders
• La configuration est construite par “projection” à travers les couches de résolution (CLI → env → paramètres → valeurs par défaut)
• Capturé automatiquement sous forme de RuntimeModelSnapshot lorsqu’une configuration complète est détectée
• Permet la réutilisation sans ressaisir les identifiants

Cycle de vie du RuntimeModelSnapshot

Lorsque vous configurez un modèle sans utiliser modelProviders, Qwen Code crée automatiquement un RuntimeModelSnapshot pour préserver votre configuration :

# This creates a RuntimeModelSnapshot with ID: $runtime|openai|my-custom-model
qwen --auth-type openai --model my-custom-model --openaiApiKey $KEY --openaiBaseUrl https://api.example.com/v1

Le snapshot :

• Capture l’ID du modèle, la clé API, le baseUrl et la configuration de génération
• Persiste entre les sessions (stocké en mémoire pendant l’exécution)
• Apparaît dans la liste de la commande /model comme une option runtime
• Peut être activé via /model $runtime|openai|my-custom-model

Différences clés

Quand utiliser chaque type

• Utilisez les Modèles fournisseur lorsque : Vous disposez de modèles standards partagés au sein d’une équipe, avez besoin de configurations cohérentes ou souhaitez empêcher les remplacements accidentels
• Utilisez les Modèles Runtime lorsque : Vous testez rapidement un nouveau modèle, utilisez des identifiants temporaires ou travaillez avec des points de terminaison ad hoc

Persistance de la sélection et recommandations

• /model et /auth persistent model.name (le cas échéant) et security.auth.selectedType dans le scope inscriptible le plus proche qui définit déjà modelProviders ; sinon, ils basculent vers le scope utilisateur. Cela maintient la synchronisation des fichiers workspace/utilisateur avec le catalogue de fournisseurs actif.
• Sans modelProviders, le résolveur mélange les couches CLI/env/paramètres, créant des Modèles Runtime. Cela convient pour les configurations à fournisseur unique, mais devient fastidieux lors de changements fréquents. Définissez des catalogues de fournisseurs dès que les workflows multi-modèles sont courants, afin que les changements restent atomiques, attribuables à leur source et débogables.