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 d’IA et fournisseurs à l’aide de la commande /model.

Aperçu

Utilisez modelProviders pour déclarer des modèles par type d’authentification entre lesquels le sélecteur /model peut basculer. Les clés doivent être des types d’authentification valides (openai, anthropic, gemini, etc.). Chaque type d’authentification correspond à un objet ProviderConfig avec un champ protocol et un champ models (le tableau des définitions de modèles). Chaque entrée dans models nécessite un id ; envKey est optionnel et recommandé (lorsqu’il est omis, il revient à la clé d’environnement par défaut du type d’authentification, par exemple OPENAI_API_KEY pour openai), avec des champs optionnels name, description, baseUrl et generationConfig. Les identifiants ne sont jamais persistés dans les paramètres ; l’exécution 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

Vous trouverez ci-dessous des exemples de configuration complets pour différents types d’authentification, montrant 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 inconnue est utilisée (par exemple, une faute de frappe comme "openai-custom"), une clé non vide est acceptée telle quelle en tant que groupe de type d’authentification propre, mais elle ne correspondra à aucun protocole connu — ses modèles ne fonctionneront donc pas comme prévu et ne se comporteront pas correctement dans le sélecteur /model. Seules les clés vides (uniquement des espaces) sont ignorées. 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 et Requesty.

{
  "env": {
    "OPENAI_API_KEY": "sk-votre-cle-openai-reelle-ici",
    "OPENROUTER_API_KEY": "sk-or-votre-cle-openrouter-reelle-ici",
    "REQUESTY_API_KEY": "sk-votre-cle-requesty-reelle-ici"
  },
  "modelProviders": {
    "openai": {
      "protocol": "openai",
      "models": [
        {
          "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
            }
          }
        },
        {
          "id": "openai/gpt-4o-mini",
          "name": "GPT-4o Mini (via Requesty)",
          "envKey": "REQUESTY_API_KEY",
          "baseUrl": "https://router.requesty.ai/v1",
          "generationConfig": {
            "timeout": 120000,
            "maxRetries": 3,
            "samplingParams": {
              "temperature": 0.7
            }
          }
        }
      ]
    }
  }
}

Anthropic (anthropic)

{
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-votre-cle-anthropic-reelle-ici"
  },
  "modelProviders": {
    "anthropic": {
      "protocol": "anthropic",
      "models": [
        {
          "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-votre-cle-gemini-reelle-ici"
  },
  "modelProviders": {
    "gemini": {
      "protocol": "gemini",
      "models": [
        {
          "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 auto-hébergés locaux (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": {
      "protocol": "openai",
      "models": [
        {
          "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 qui ne nécessitent 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="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 codage. Cette fonctionnalité est disponible pour les utilisateurs ayant 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.

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 ModelStudio, puis choisissez Coding Plan dans le sous-menu
4. Sélectionnez votre région
5. Saisissez votre clé API lorsque vous y êtes invité

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 la configuration modelProviders. Pour changer de région, réexécutez la commande /auth et sélectionnez une région différente.

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-cle-api-ici

Mises à jour automatiques

Les configurations de modèle Coding Plan sont versionnées. Lorsque Qwen Code détecte une version plus récente du modèle de modèle, vous serez invité à mettre à jour. Accepter la mise à jour effectuera les opérations suivantes :

• Remplacer les configurations de modèle Coding Plan existantes par les dernières versions
• Préserver toutes les configurations de modèle 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 avez toujours accès aux dernières configurations et fonctionnalités de modèle 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": {
      "protocol": "openai",
      "models": [
        {
          "id": "qwen3-coder-plus",
          "name": "qwen3-coder-plus",
          "description": "Qwen3-Coder via Alibaba Cloud Coding Plan",
          "envKey": "VOTRE_CLE_ENV_PERSONNALISEE",
          "baseUrl": "https://coding.dashscope.aliyuncs.com/v1"
        }
      ]
    }
  }
}

Couches de résolution et atomicité

Les valeurs effectives d’auth/model/credential sont choisies par champ en utilisant la priorité 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 indicateurs CLI s’exécutent avant les autres couches.

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

La résolution de la configuration suit un modèle de hiérarchisation strict avec une règle cruciale : la couche modelProvider est imperméable.

Fonctionnement

1. Lorsqu’un modèle de modelProvider EST sélectionné (par exemple, via la commande /model choisissant un modèle configuré par un 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, settings) 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 mis à undefined (non hérités des paramètres)
   • Cela garantit que les configurations des fournisseurs agissent comme un « package scellé » complet et autonome

   Si un modèle est listé dans modelProviders, placez tous les paramètres de génération spécifiques à ce modèle dans l’entrée fournisseur correspondante. Les valeurs de model.generationConfig de niveau supérieur, y compris contextWindowSize, modalities, customHeaders et extra_body, sont ignorées pour les modèles de fournisseur. Configurez ces champs sous modelProviders[authType][].generationConfig pour qu’ils s’appliquent.

2. Lorsqu’aucun modèle modelProvider n’est sélectionné (par exemple, en utilisant --model avec un ID de modèle brut, ou directement via CLI/env/settings) :

   • La résolution descend à travers les couches inférieures
   • Les champs sont renseignés à partir de CLI → env → settings → valeurs par défaut
   • Cela crée un Runtime Model (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 du fournisseur remplacent complètement l’objet entier, 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": {
      "protocol": "openai",
      "models": [{
        "id": "gpt-4o",
        "envKey": "OPENAI_API_KEY",
        "generationConfig": {
          "timeout": 60000,
          "samplingParams": { "temperature": 0.2 }
        }
      }]
    }
  }
}

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

• timeout = 60000 (du fournisseur, remplace les paramètres)
• samplingParams.temperature = 0.2 (du 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 mis à undefined s’ils ne sont pas fournis)

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

• 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 elle-même est REPLACE : l’intégralité de modelProviders des paramètres du projet remplacera la section correspondante dans les paramètres utilisateur, plutôt que de fusionner les deux.

Configuration du raisonnement / de la réflexion

Le champ optionnel reasoning sous generationConfig contrôle l’agressivité avec laquelle le modèle raisonne 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": {
      "protocol": "openai",
      "models": [
        {
          "id": "deepseek-v4-pro",
          "name": "DeepSeek V4 Pro",
          "baseUrl": "https://api.deepseek.com/v1",
          "envKey": "DEEPSEEK_API_KEY",
          "generationConfig": {
            // Échelle à quatre niveaux :
            //   'low'    | 'medium' — mappé côté serveur vers 'high' sur DeepSeek
            //   'high'   — intensité de raisonnement par défaut
            //   'max'    — niveau supplémentaire propre à DeepSeek
            // Ou définir `false` pour désactiver complètement le raisonnement.
            "reasoning": { "effort": "max" },
          },
        },
      ],
    },
  },
}

Comportement par fournisseur

reasoning: false

Définir reasoning: false (le booléen littéral) désactive explicitement la réflexion sur chaque fournisseur — 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 (par exemple, la génération de suggestions).

Sur une URL de base api.deepseek.com, le pipeline OpenAI émet le champ explicite thinking: { type: 'disabled' } que DeepSeek V4+ exige — la valeur par défaut côté serveur est 'enabled', donc simplement omettre reasoning_effort paierait toujours la latence/le coût de la 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 (compatible OpenAI uniquement)

budget_tokens

Vous pouvez fixer un budget exact de jetons de réflexion en incluant budget_tokens avec 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.

Provider Models vs Runtime Models

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

Provider Model

• Défini dans la configuration modelProviders
• Possède 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 les métadonnées complètes (nom, description, capacités)
• Recommandé pour les flux de travail multi-modèles et la cohérence d’équipe

Runtime Model

• Créé dynamiquement lors de l’utilisation d’ID de modèles bruts via CLI (--model), variables d’environnement ou paramètres
• Non défini dans modelProviders
• La configuration est construite en « projetant » à travers les couches de résolution (CLI → env → settings → valeurs par défaut)
• Automatiquement capturé en tant que RuntimeModelSnapshot lorsqu’une configuration complète est détectée
• Permet la réutilisation sans avoir à ressaisir les identifiants

Cycle de vie de RuntimeModelSnapshot

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

# Ceci crée un RuntimeModelSnapshot avec l'ID : $runtime|openai|my-custom-model
qwen --auth-type openai --model my-custom-model --openai-api-key $KEY --openai-base-url https://api.example.com/v1

Le snapshot :

• Capture l’ID 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 de la commande /model comme une option runtime
• Peut être activé en utilisant /model $runtime|openai|my-custom-model

Différences clés

Quand utiliser l’un ou l’autre

• Utilisez Provider Models lorsque : Vous avez des modèles standard partagés au sein d’une équipe, avez besoin de configurations cohérentes, ou souhaitez éviter les remplacements accidentels
• Utilisez Runtime Models lorsque : Vous testez rapidement un nouveau modèle, utilisez des identifiants temporaires, ou travaillez avec des endpoints ad-hoc

Persistance de la sélection et recommandations

• Les commandes /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, elles tombent en arrière sur le scope utilisateur. Cela maintient la synchronisation des fichiers de l’espace de travail/utilisateur avec le catalogue de fournisseurs actif.
• Sans modelProviders, le résolveur mélange les couches CLI/env/settings, créant des Runtime Models. C’est acceptable pour les configurations à fournisseur unique, mais fastidieux lors de changements fréquents. Définissez des catalogues de fournisseurs dès que les flux de travail multi-modèles sont courants afin que les changements restent atomiques, attribués à une source et débogables.