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 que le sélecteur /model peut utiliser pour 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 informations d’identification ne sont jamais persistées 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 son propre type d’authentification, 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 (composées uniquement d’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-your-actual-openai-key-here",
    "OPENROUTER_API_KEY": "sk-or-your-actual-openrouter-key-here",
    "REQUESTY_API_KEY": "sk-your-actual-requesty-key-here"
  },
  "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-your-actual-anthropic-key-here"
  },
  "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-your-actual-gemini-key-here"
  },
  "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 une 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 une baseUrl locale :

{
  "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": "Local Model (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 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"

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 codage. Cette fonctionnalité est disponible pour les utilisateurs ayant un accès API au Plan de codage Alibaba Cloud 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 du Plan de codage Alibaba Cloud via la commande /auth, Qwen Code configure automatiquement les modèles suivants :

Configuration

1. Obtenez une clé API du Plan de codage Alibaba Cloud :
   • 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

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 settings.json sous la configuration modelProviders. Pour changer de région, relancez la commande /auth et choisissez une région différente.

Stockage de la clé API

Lorsque vous configurez le Plan de codage 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èles du Plan de codage sont versionnées. Lorsque Qwen Code détecte une version plus récente du modèle de configuration, vous serez invité à mettre à jour. Accepter la mise à jour : Remplacez les configurations existantes du modèle Coding Plan par les dernières versions

• Préservez toute configuration personnalisée que vous avez ajoutée manuellement
• Basculez automatiquement vers le premier modèle de la configuration mise à jour

Le processus de mise à jour vous garantit d’avoir toujours accès aux dernières configurations de modèle et fonctionnalités 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 pour tout 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": "YOUR_CUSTOM_ENV_KEY",
          "baseUrl": "https://coding.dashscope.aliyuncs.com/v1"
        }
      ]
    }
  }
}

Couches de résolution et atomicité

Les valeurs effectives d’auth/model/credential sont sélectionnées par champ selon 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 sont traités avant les autres couches.

*Lorsqu’ils sont présents, les indicateurs CLI d’authentification 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 disponibles sans configuration supplémentaire.

Génération des couches de configuration : la couche fournisseur imperméable

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

Comment ça fonctionne

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

   • L’intégralité de generationConfig du fournisseur est appliquée atomiquement
   • La couche du 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 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 du fournisseur correspondant. Les valeurs model.generationConfig de niveau supérieur, y compris contextWindowSize, modalities, customHeaders et extra_body, sont ignorées pour les modèles des fournisseurs. Configurez ces champs sous modelProviders[authType][].generationConfig pour qu’ils s’appliquent.

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

   • La résolution redescend vers les couches inférieures
   • Les champs sont peuplés depuis CLI → env → paramètres → valeurs par défaut
   • Cela crée un Modèle Runtime (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, sans aucune fusion :

• samplingParams - Temperature, 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 (depuis le fournisseur, surcharge 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 du fournisseur n’hérite pas des paramètres — les champs sont explicitement définis à undefined s’ils ne sont pas fournis)

Lorsqu’on utilise un modèle brut via --model gpt-4 (pas depuis 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 elle-même est REMPLACER : l’intégralité de modelProviders depuis les paramètres du projet remplacera la section correspondante dans les paramètres utilisateur, plutôt que de fusionner les deux.

Configuration du raisonnement / réflexion

Le champ optionnel reasoning sous generationConfig contrôle l’intensité 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 l’avis « 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 extra-fort spécifique à 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 chez tous les fournisseurs — utile pour les requêtes annexes peu coûteuses qui ne bénéficient pas d’un raisonnement. Cela est également honoré au niveau de la requête via request.config.thinkingConfig.includeThoughts: false pour des appels ponctuels (p. ex. génération de suggestions).

Sur une URL de base api.deepseek.com, le pipeline OpenAI émet le champ thinking: { type: 'disabled' } explicite que DeepSeek V4+ exige — la valeur par défaut côté serveur est 'enabled', donc omettre simplement 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 la commande qu’expose votre framework d’inférence) via samplingParams/extra_body.

Interaction avec samplingParams (compatibles 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 reste le paramètre déterminant.

Modèles fournisseur 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
• 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 workflows multi-modèles et la cohérence d’équipe

Modèle d’exécution

• Créé dynamiquement lors de l’utilisation d’ID de modèles bruts via la CLI (--model), les variables d’environnement ou les paramètres
• N’est pas défini dans modelProviders
• La configuration est construite par « projection » à travers les couches de résolution (CLI → env → paramètres → valeurs par défaut)
• Automatiquement capturé comme 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 d’une session à l’autre (stocké en mémoire pendant l’exécution)
• Apparaît dans la liste de la commande /model comme une option d’exécution
• Peut être sélectionné via /model $runtime|openai|my-custom-model

Différences clés

Quand utiliser chaque type

• Utilisez les modèles fournisseur lorsque : vous avez des modèles standards partagés au sein d’une équipe, avez besoin de configurations cohérentes, ou souhaitez éviter les écrasements accidentels
• Utilisez les modèles d’exécution 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 modifiable le plus proche qui définit déjà modelProviders ; sinon, elles tombent par défaut sur le scope utilisateur. Cela maintient la cohérence des fichiers d’espace de travail/utilisateur avec le catalogue actif de fournisseurs.
• Sans modelProviders, le résolveur mélange les couches CLI/env/paramètres, créant des modèles d’exécution. Cela convient pour les configurations mono-fournisseur 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, attribués à une source et déboguables.