Claude Code sur GLM-5.3 et Qwen : cinq pièges lors du remplacement du modèle via LiteLLM

Remplacer le modèle derrière Claude Code est un jeu d'enfant : ANTHROPIC_BASE_URL, un jeton, et l'agent envoie ses requêtes au protocole Anthropic Messages vers n'importe quelle destination. Les problèmes commencent dès le deuxième jour. L'équipe de la passerelle biélorusse ZuBrIQ, où Claude Code ne fonctionne pas officiellement et où il n'y a aucun moyen de payer Anthropic, a décrit les cinq pièges dans lesquels elle est elle-même tombée.

Le schéma et la règle principale

Entre les clients (Claude Code, Codex, OpenCode, Zed, Cursor) et les modèles se trouve LiteLLM, déployé sur deux pods. Les clients ne connaissent que des noms stables : zubr, zubr-flash, zubr-coder. Derrière chacun se cache une liste de routes avec ordre et repli : GLM-5.3 chez un fournisseur, DeepSeek V4 Pro en solution de secours et un Qwen3.8-27B maison sur quatre V100. Si les poids changent ou si un fournisseur tombe, les intégrations ne s'en aperçoivent pas. C'est pratique, mais c'est précisément là que se cachent les pannes silencieuses.

Trois pannes silencieuses

Première : le repli discret. GLM-5.3 avait été déclaré comme un backend openai/ ordinaire. Le chat fonctionnait, mais Claude Code et Codex recevaient les réponses du modèle de secours. LiteLLM convertit /v1/messages et /v1/responses vers l'API Responses, le fournisseur répond 404 et le routeur passe silencieusement à la suite. Aucune erreur dans les logs : seul l'en-tête x-litellm-attempted-fallbacks: 1 trahit le problème. La solution est d'utiliser le fournisseur natif de LiteLLM pour ce vendeur, qui convertit tout en chat/completions.

Deuxième : la consommation à zéro. Avec le fournisseur natif, LiteLLM ne récupère pas le prix depuis model_info : le spend reste à zéro, les budgets des clés ne se déclenchent pas et le rapport de marge est faux. Il faut dupliquer les prix directement dans litellm_params : input_cost_per_token, output_cost_per_token, cache_read_input_token_cost. Autre nuance : une modification via PATCH /model/{id}/update met une à deux minutes à atteindre le second pod, inutile donc de conclure trop vite que cela n'a pas fonctionné.

Troisième : les images. GLM-5.3 excelle en code mais n'accepte pas les images.

Le point d'accès chat du fournisseur répond 400, tandis que le point d'accès compatible Anthropic supprime silencieusement l'image, et le modèle devine alors avec aplomb à partir du texte. L'utilisateur envoie une capture d'écran d'erreur et reçoit des raisonnements sur ce que le modèle n'a pas vu. Dans ZubrCode, le contournement est le suivant : si le catalogue indique que le modèle n'a pas de vision, l'image est remplacée par une description textuelle générée par GLM-5.

3 Flash, et le résultat est mis en cache selon le sha256 de l'image, car l'agent rejoue tout l'historique à chaque tour. À cela s'ajoute un bug de catalogue : supports_vision: null était interprété comme false, et la vision a disparu sur un modèle qui voit pourtant.

Configuration de Claude Code et GPU maison

Claude Code envoie lui-même des sous-tâches de service — titres, compression du contexte, sous-agents — à des modèles des classes Haiku, Sonnet et Opus. Si vous ne remplacez que ANTHROPIC_MODEL, ces requêtes échoueront avec une erreur 403 en plein travail. Il faut définir ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL et ANTHROPIC_DEFAULT_HAIKU_MODEL. Écrivez ANTHROPIC_BASE_URL sans /v1, sinon vous obtiendrez /v1/v1/messages. Le suffixe [1m] indique une fenêtre de 1M et est retiré avant l'envoi ; pour les modèles sans ce suffixe, la fenêtre est définie par CLAUDE_CODE_MAX_CONTEXT_TOKENS.

Faire tourner son propre modèle sur des cartes de 2017 est une autre histoire. Les V100 ne disposent ni de bf16 ni de FP8 ; il faut donc de l'AWQ INT4 avec calculs en FP16, vLLM avec parallélisme tensoriel sur 4 cartes et un fork prenant en charge SM70. Le fork ne soustrait pas les poids lors du calcul du budget du cache KV, d'où la nécessité de définir explicitement --kv-cache-memory-bytes.

On ne peut pas démarrer deux instances simultanément : le pic d'initialisation dépasse 16 Go, le worker subit un OOM et le processus principal se bloque sur le watchdog NCCL, alors que systemd affiche active. Désormais, la seconde unité attend le health de la première. Un modèle dense de 27B, plutôt que le MoE 35B-A3B, est plus intelligent et voit lui-même les images, mais le premier token arrive en ~1,3 s contre ~0,6 s ; on le réserve donc aux tâches de fond et aux données confidentielles.

Que faire

Les limites sont évidentes : il s'agit du retour d'expérience d'une seule équipe, les prix des exemples sont fictifs et le comportement de LiteLLM peut changer d'une version à l'autre. Mais le principe est général. Si vous placez une passerelle entre un agent et des modèles, surveillez les en-têtes de repli, comparez la consommation avec les factures réelles du fournisseur, vérifiez ce qu'il advient d'une image sur chaque route et renseignez les trois emplacements Haiku, Sonnet et Opus.

Les bugs les plus coûteux ici ne plantent pas avec une erreur : ils répondent avec assurance, mais avec les mauvais mots. La passerelle fait partie de la plateforme commerciale des auteurs, l'article est donc en partie publicitaire, mais les détails techniques se vérifient facilement sur votre propre banc d'essai.