Comment Databricks déploie des modèles de pointe auprès de 12 000 collaborateurs dès le premier jour

Offrir à nos employés un accès aux capacités d'AI de pointe est une priorité absolue chez Databricks. Par conséquent, il est important pour nous qu'ils puissent utiliser les nouveaux modèles instantanément dès leur sortie. En même temps, donner un accès rapide à un nouveau modèle à plus de 12 000 personnes n'est pas une mince affaire car :

1. Les modèles présentés comme étant de pointe ne le sont souvent pas. Par exemple, Opus 5.0 était plus cher et moins bien classé par nos ingénieurs, tant sur les scores de qualité quantitatifs que qualitatifs, par rapport à Opus 4.8. Migrer vers un modèle qui régresse par rapport à la frontière technologique peut nuire considérablement à une entreprise, plutôt que de l'aider. D'après notre expérience, une grande prudence est de mise lors de l'évaluation des modèles avant de migrer massivement les charges de travail vers de nouveaux modèles.
2. L'utilisation naïve d'un nouveau modèle peut faire exploser les coûts. Lorsque nous avons mis GPT Astra à la disposition d'un groupe de contrôle sans mesures d'atténuation des coûts associées, le développeur moyen a dépensé 60 % de plus qu'avant d'avoir accès à Astra. Une augmentation soudaine de 60 % des coûts du jour au lendemain pour une population de plus de 10 000 utilisateurs est très difficile à planifier pour une entreprise. Une fois que nous avons mieux compris les tâches pour lesquelles Astra est exceptionnellement performant, nous avons pu orienter l'utilisation afin de réduire considérablement les coûts globaux.

Cet article présente un ensemble de techniques que nous avons employées pour donner à la plupart des employés de Databricks un accès dès le premier jour (« Day 1 ») aux nouveaux modèles, tout en nous permettant d'évaluer si ces modèles sont de bons outils de travail à long terme. Ces techniques s'appuient fortement sur Unity Gateway pour déployer, évaluer et intégrer de nouveaux modèles de manière adaptative. La semaine du 21 septembre a été un test critique de ces capacités lorsque Opus 5, GPT-6 Sol et GPT-Luna sont sortis coup sur coup. Au cours de cette semaine, Databricks a fourni un accès dès le premier jour à tous ses employés, et dès le troisième jour, nous avions recueilli suffisamment de données pour confirmer que ces modèles se situaient sur la frontière d'efficacité, ce qui a conduit à leur intégration dans notre infrastructure globale.

Le cycle de vie du déploiement des modèles

 De manière générale, les lancements de nouveaux modèles chez Databricks passent par un pipeline qui se présente comme suit :

1. Rendre immédiatement les nouveaux modèles disponibles pour tous les employés, à titre « expérimental ».
2. Limiter l'utilisation des nouveaux modèles en fonction d'un budget par utilisateur.
3. Après avoir recueilli suffisamment de données, décider de promouvoir le modèle en production (ou même d'en faire le modèle par défaut).

Étape 1 : Rendre les nouveaux modèles immédiatement disponibles

Pour faciliter la gestion des modèles entre les fournisseurs de modèles propriétaires et open source, nous exploitons notre propre Databricks Unity Gateway pour tout notre usage interne. Il s'agit de notre hub central pour la gouvernance de l'AI, la gestion des coûts et l'observabilité, il est donc naturel que nous commencions par là.

C'est via la Gateway que nous permettons à tous les employés d'accéder au modèle nouvellement publié. Cependant, la configuration côté serveur ne suffit pas. Nos employés utilisent Claude Code, Codex et le méta-harnais Omnigent sur leurs ordinateurs portables, et nous devons leur distribuer la configuration du nouveau modèle.

C'est là qu'intervient Unity Gateway CLI (UG CLI). L'UG CLI fonctionne déjà sur l'ordinateur portable de chacun, déployée via notre gestion des appareils mobiles. Chaque fois que quelqu'un lance Claude Code, Codex ou Omnigent, l'UG CLI s'exécute pour rechercher de nouveaux modèles, outils et compétences, et met à jour la configuration du harnais local. L'UG nous permet également de désigner de manière centralisée les modèles par défaut par rapport aux modèles expérimentaux, de préparer les modèles pour le routage intelligent et de collecter des traces pour évaluer chaque déploiement de modèle.

Nous avons configuré Unity Gateway pour pousser les configurations expérimentales pour Opus 5.5 et Sol 6. Ces modèles s'affichent désormais avec ce tag, afin que les employés puissent les sélectionner tout en comprenant qu'il s'agit d'un nouveau modèle qui n'est pas forcément le meilleur de sa catégorie ou qui pourrait ne pas rester indéfiniment :

La sortie du modèle Claude Code désigne clairement Ous 5.5 comme expérimental

Étape 2 : Limiter l'utilisation à l'aide d'un budget par utilisateur

Nous avons déjà publié un article sur la façon dont nous configurons les budgets par utilisateur pour les dépenses d'AI. Depuis lors, nous avons étendu notre architecture budgétaire globale pour inclure quatre budgets principaux, chacun défini par utilisateur :

1. Maximum mensuel : chaque utilisateur dispose d'un plafond global de dépenses mensuelles pour l'ensemble des modèles.
2. Limite quotidienne d'emballement : chaque utilisateur a un maximum quotidien, qui peut être augmenté directement dans Slack pour éviter les dépenses accidentelles dues à une session hors de contrôle.
3. [Nouveau !] Budget pour les modèles de pointe : nous allouons une certaine fraction du budget mensuel aux modèles les plus haut de gamme situés à la frontière de la qualité, tels que GPT Astra et Claude Fable. (Fable n'est pas encore déployé en interne en raison des politiques de rétention des données d'Anthropic, mais nous travaillons en étroite collaboration pour mettre en œuvre leur nouvelle politique.) Cela traduit l'intention que ces modèles ne doivent pas être utilisés au quotidien, mais plutôt sélectionnés pour des tâches spécialisées pour lesquelles ils sont particulièrement adaptés, afin de justifier un coût 2 à 3 fois plus élevé que le niveau de qualité inférieur.
4. [Nouveau !] Budget expérimental : une autre fraction du budget mensuel est allouée à l'utilisation de nouveaux modèles non testés. Ici, notre objectif est de concilier la rapidité d'adoption avec le risque de déployer largement un modèle qui ne se situe pas sur la frontière d'efficacité.

Dès le premier jour du lancement des modèles, nous avons rendu Opus 5.5 et Sol 6 disponibles pour tous les employés via Unity Gateway et les avons associés au budget expérimental. Nous avons ensuite mis à profit les jours suivants pour recueillir des données afin de décider de la suite à donner : retirer le tag expérimental ou supprimer le modèle du catalogue visible par nos développeurs.

Aperçu de la configuration budgétaire, reflétant les quatre budgets

Étape 3 : Promouvoir ou abandonner le modèle

Pour déterminer si le modèle se situe sur la frontière d'efficacité, nous nous appuyons sur trois signaux :

1. Données de benchmark : nous disposons d'un ensemble de benchmarks privés qui testent une série de tâches, notamment des benchmarks hors ligne tels que le raisonnement sur les documents, la recherche dans l'espace de travail et notre propre produit Genie, ainsi que des benchmarks en ligne dans lesquels nous exécutons deux modèles côte à côte et comparons les résultats pour la création de pull requests. Nous continuons d'étendre et d'ajuster ces benchmarks ; dans un monde idéal, nos benchmarks suffisent à déterminer rapidement le coût et la qualité de tout nouveau modèle publié.
    
2. Qualité rapportée par les utilisateurs : le déploiement expérimental du modèle fournit une multitude de données anecdotiques sur le ressenti des utilisateurs vis-à-vis du nouveau modèle. Nous constatons qu'un groupe d'utilisateurs chevronnés est impatient d'essayer les nouveaux modèles et de comparer leurs expériences sur Slack et via des réponses à des enquêtes.
    
3. Suivi des coûts via les traces OpenTelemetry : Unity Gateway enregistre toutes les traces dans un emplacement centralisé, ainsi que les informations sur les coûts. Nous pouvons comparer la façon dont les utilisateurs pilotes ont dépensé de l'argent sur la génération précédente de modèles par rapport aux derniers modèles, session par session.  Cela ne nous renseigne pas nécessairement sur la qualité, mais cela nous donne une bonne mesure du coût.

Pour Opus 5.5 et Sol 6, ces trois indicateurs nous racontent une histoire assez cohérente.

Les benchmarks, comme notre OfficeQA Pro V2, montrent qu'Opus 5.5 se situe clairement sur la frontière coût/qualité, représentant une avancée majeure sur ces deux aspects par rapport à Opus 5. GPT-6 Sol obtient des résultats intermédiaires entre GPT-5.6 Sol et GPT-5.6 Terra, tant en termes de coût que de qualité.

Les retours d'expérience des utilisateurs s'accordent généralement à dire que pour les tâches d'ingénierie et de débogage (la grande majorité de nos premiers utilisateurs étant des ingénieurs), Opus 5.5 offre une nette amélioration de la qualité par rapport à Opus 5 et Opus 4.8, et son style de rédaction est largement préféré. En revanche, GPT-6 Sol représente parfois une baisse de qualité par rapport à GPT-5.6 Sol.

Le suivi des coûts nous a permis de comparer l'utilisation des premiers adoptants avec celle du même groupe une semaine plus tôt. Le maintien de la même cohorte s'est avéré crucial, car les premiers adoptants ont tendance à être des utilisateurs intensifs de l'AI plutôt que des utilisateurs moyens.

Nous souhaitions normaliser les coûts sur une base de $/session, car les utilisateurs qui testent un nouveau modèle augmentent parfois leur utilisation en termes de nombre de sessions au fil de leurs expérimentations. Nous avons constaté qu'une simple comparaison en $/session restait trompeuse, car la répartition des sessions évoluait également : les premiers adoptants soumettaient des problèmes plus complexes aux nouveaux modèles par rapport à leur session moyenne.

Par conséquent, nous avons stratifié les sessions selon qu'elles étaient à tour unique ou multiple et qu'elles incluaient ou non des modifications de fichiers, puis nous avons repondéré la distribution en conséquence. Le tableau ci-dessous présente les résultats pour Opus 5.5 vs Opus 4.8 et GPT-6 Sol vs GPT-5.6 Sol.

Les chiffres de GPT ne sont pas très surprenants étant donné que le prix a été réduit de 50 %. Mais nous avons été ravis de constater qu'Opus 5.5 représente également une réduction de prix significative pour nos charges de travail réelles, compte tenu de notre expérience passée avec Opus 5.

Notre décision

Nous avons pu offrir aux collaborateurs un accès expérimental à Opus 5 ainsi qu'à GPT-6 Sol et Luna dès le premier jour du lancement des modèles. En l'espace de trois jours, nous avions recueilli suffisamment de données pour confirmer que ces modèles se situaient sur la frontière d'efficacité, et nous avons décidé de les retirer du budget expérimental pour les intégrer dans la circulation standard en tant que modèles généralement disponibles.

Au cours de la semaine prochaine, nous irons encore plus loin pour Opus 5.5 en en faisant le modèle par défaut pour Claude Code, compte tenu de sa position claire de modèle de meilleure qualité et moins coûteux que ses prédécesseurs.

Notre expérience avec GPT-6 Sol suggère qu'il ne remplacera pas GPT-5.6 Sol comme modèle par défaut pour Codex. Cependant, nous intégrerons GPT-6 Sol dans la boîte à outils de notre routeur intelligent, compte tenu de son avantage de coût par rapport à 5.6 Sol. 

Dans l'ensemble, nous avons trouvé cette approche efficace pour évaluer rapidement la qualité et le coût des modèles, ce qui nous permet d'adopter rapidement les derniers modèles qui font leurs preuves. Cette flexibilité est plus importante que jamais, avec de nouveaux modèles qui arrivent presque quotidiennement.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original