Sage-A1.5 sur une carte de 24 GB : 136 tokens/s, et un mode de vérification qui double le travail sur les questions faciles

Trente-cinq milliards de paramètres sur le disque, environ trois milliards au travail pour chaque mot. C'est cet écart qui permet à Sage-A1.5, un agent de recherche ouvert du Shanghai AI Laboratory, de tenir sur une seule carte gaming. Nous avons fait tourner le fichier compressé des auteurs eux-mêmes sur une RTX 4090, une carte gaming de 24 GB, sur notre cloud (InferenceKey Cloud), avec des logiciels open source standard. Sa mécanique d'agent y a fonctionné : il a distribué des tâches, a demandé à notre code de chercher, et a répondu. Il a écrit environ 136 tokens par seconde, une longue réponse en 11 secondes, et a répondu juste à notre unique question de recherche en trois parties dans les trois exécutions de test. Son nouveau Verification Mode, qui lui fait vérifier son propre travail, a donné les mêmes bonnes réponses sur des questions faciles, mais a pris 2,2 fois plus de temps et deux fois plus de tokens. Le modèle tourne sur un worker GPU que vous contrôlez, et les outils tournent dans votre propre code. Laissez le mode de vérification désactivé pour les recherches simples, et testez-le sur vos cas difficiles.

L'image montre une même question posée deux fois sur la même carte : dans quelle ville le hafnium a-t-il été découvert, et par qui. Les deux exécutions ont répondu juste, et celle avec le mode activé a continué de vérifier des faits qu'elle avait déjà lus.

35 milliards de paramètres, 3 milliards éveillés pour chaque mot

Sage-A1.5 est gros sur le disque et petit en mouvement, et c'est pour cela qu'une seule carte gaming peut le servir. C'est un modèle mixture-of-experts. Imaginez une équipe de 256 spécialistes, plus un généraliste toujours présent dans la pièce. Pour chaque mot qu'il écrit, le modèle consulte 8 spécialistes. Les autres attendent. Ainsi, sur 35 milliards de paramètres, seuls environ 3 milliards travaillent à chaque étape, selon la page du projet. La vitesse suit les 3 milliards, et la facture mémoire suit les 35.

Le modèle est réentraîné à partir de deux autres : le modèle ouvert 35B de l'équipe Qwen et Agents-A1, l'agent précédent du laboratoire lui-même, publié en juin. Le papier, signé par Wenjie Lou et 98 co-auteurs, a été mis en ligne le 20 octobre. Le modèle complet et le fichier compressé, environ 22 GB, sont tous deux sous Apache-2.0 : utilisables commercialement et téléchargeables sans formulaire. Un petit fichier en plus permet au modèle de lire des images, et deux modes que vous activez vous-même en font un agent :

• Agentic Orchestration. Vous donnez au modèle un outil qui distribue des tâches. Le modèle découpe alors une question en tâches et confie chacune à un sous-agent, qui cherche et lit de son côté, puis fait son rapport. C'est un chercheur principal qui envoie trois assistants à la bibliothèque en même temps.
• Verification Mode. Une ligne ajoutée aux instructions du modèle lui dit de vérifier son propre travail avant de répondre. Les auteurs disent qu'il n'a besoin de rien d'autre d'installé.

Les scores des auteurs viennent du modèle non compressé et n'ont pas été reproduits ici

Sur BrowseComp, qui demande des faits difficiles à trouver sur le web, les auteurs annoncent 81,7 sur 100, contre 91,2 pour Kimi-K3, le meilleur modèle de leur tableau. Dans un test séparé, mode activé contre désactivé, sur les 1 266 questions de BrowseComp, Verification Mode a fait passer le score de 72,5 % à 82,9 %. Nous ne pouvons pas dire si le 81,7 inclut déjà ce gain. Leurs autres scores sont en annexe.

Notre test : une RTX 4090, le fichier des auteurs, nos propres questions

La limite d'abord : une poignée de questions faciles, appuyées sur Wikipédia, sur une seule carte, un agent à la fois. Cela vérifie la mécanique (appels d'outils, distribution des tâches, retour des réponses), pas l'étendue de ses capacités de recherche.

Nous avons servi le fichier compressé des auteurs avec llama.cpp, le logiciel ouvert qui fait tourner des modèles sur une seule machine, sur une RTX 4090 de notre cloud. Nous avons utilisé les réglages recommandés par les auteurs. Toutes les requêtes sont passées par notre plateforme, comme une application l'appellerait, et nous avons aussi vérifié la vitesse directement contre llama.cpp.

Les questions étaient les nôtres. Chacune demandait quelques faits tirés de Wikipédia : qui a découvert le rhénium et où, d'après quelle ville le hafnium a été nommé, quand le technétium a été trouvé. Le modèle cherchait et lisait des pages en direct au moyen de deux outils que nous avons écrits. Pour l'orchestration, nous avons posé une seule question, exécutée trois fois : combien d'années se sont écoulées entre les découvertes de trois éléments, de sorte que chaque sous-agent en prenne un.

Environ 136 tokens par seconde, et une question de recherche juste dans les trois exécutions

Sur une RTX 4090, le modèle a écrit environ 136 tokens par seconde pour une requête, et le premier token est arrivé en un quart de seconde environ. Passer par notre plateforme n'a ajouté aucun délai mesurable : llama.cpp seul a donné la même vitesse. Une réponse de 1 489 tokens a pris environ 11 secondes.

Il lit aussi vite les longs prompts. Nous avons caché une étiquette inventée, 7342-ORCHID, dans un prompt de 92 662 tokens, à peu près la longueur d'un roman. Le modèle a tout lu en 31 secondes et a trouvé l'étiquette.

La question de recherche est revenue juste à chaque fois que nous l'avons posée. Dans chacune des trois exécutions de test, le modèle a distribué trois tâches à la fois, une par élément. Les trois sous-agents ont cherché sur Wikipédia et ont renvoyé leurs résultats. Le modèle principal a ensuite écrit la réponse : hafnium en 1923, rhénium en 1925, technétium en 1937, 14 ans entre le premier et le dernier. Chaque appel d'outil est sorti exactement au format dont notre code avait besoin pour l'exécuter. Un test plus simple avec un seul appel de recherche est revenu propre 3 fois sur 3, en moins d'une seconde à chaque fois.

Le temps dépend de la possibilité pour les sous-agents de tourner côte à côte, et le réglage par défaut de notre plateforme les met en file d'attente. Après un déploiement, elle envoie au modèle une requête à la fois, donc les trois sous-agents ont attendu leur tour et l'exécution a pris 72,0 secondes. Un appel d'API a monté la limite à deux, et les exécutions ont alors pris 50 et 56 secondes. Statut : le réglage par défaut est toujours à un, et l'appel est en annexe.

La partie vision fonctionne aussi. Nous lui avons montré le propre graphique de benchmarks des auteurs et demandé une valeur. Il a lu 80,0 sur la bonne barre, et 50,0 comme le meilleur des modèles plus grands, les deux corrects.

Le piège, c'est le temps qu'il passe à réfléchir. Ce modèle raisonne longuement avant de répondre. Une définition en deux phrases a pris 14,4 secondes, parce qu'il a d'abord raisonné sur 1 905 tokens. Même 17 x 23 a demandé 336 tokens de raisonnement. À 136 tokens par seconde, cela convient à une tâche de recherche, et c'est lent pour une fenêtre de chat.

Verification Mode a doublé le travail sur les questions faciles et n'a changé aucune réponse

Sur nos questions faciles, Verification Mode n'a rien apporté de mesurable. Les 12 réponses étaient justes avec le mode désactivé comme avec le mode activé.

Le travail en plus était surtout de la répétition. Avec le mode activé, le raisonnement s'est rempli de tours "Let me verify" alors que les faits étaient déjà confirmés. L'écart a varié : dans l'autre exécution sur le hafnium, le mode activé a fait un appel d'outil de moins que le mode désactivé. Une exécution a pris 52,7 secondes parce qu'une recherche Wikipédia a expiré et que le modèle a réessayé.

Cela ne contredit pas les auteurs. Leur gain est venu sur BrowseComp, où les faits sont difficiles à trouver et où une première piste fausse est fréquente.

Quel GPU : une vraie carte de 24 GB à pleine vitesse, environ un cinquième de la vitesse ou moins en dessous

La plus petite carte qui a fait tourner Sage-A1.5 à pleine vitesse était une vraie RTX 4090 de 24 GB. Avec les réglages de notre exemple, de la place pour 32 768 tokens de conversation et deux requêtes à la fois, il a utilisé 21,3 des 23,5 GiB de la carte. La configuration de la fiche du modèle, 64K tokens avec la vision, a culminé à 23,1 GiB. 128K tokens, texte seul, a culminé à 23,4 GiB, ce qui laisse la carte presque pleine. Toutes ces configurations ont tenu, sans perte de vitesse.

En dessous de 24 GB, le modèle ne tourne que si une partie passe dans la mémoire principale de l'ordinateur. Llama.cpp peut y garer certains spécialistes et laisser le processeur les exécuter, ce qui est beaucoup plus lent. Nous avons simulé des cartes plus petites sur la même 4090, en sortant des spécialistes jusqu'à ce que la mémoire de la carte reste sous chaque limite.

• 16 GB simulés : 14,4 GiB sur la carte, environ 5,6 fois plus lent, et la question de recherche est encore revenue juste en 98 secondes.
• 12 GB simulés : 10,8 GiB sur la carte, et la question est revenue juste en 93 secondes.
• 8 GB simulés : 3,0 GiB avec tous les spécialistes en mémoire principale. Une exécution de recherche sur deux a épuisé sa limite de 12 étapes au bout de 270 secondes sans réponse. La nouvelle tentative a été juste.
• Pas essayé : de vraies cartes de 16 et 12 GB, la RTX 3090, les cartes de 32 GB, le modèle non compressé.

Les vitesses simulées dépendent du processeur et de la mémoire de l'ordinateur, prenez-les donc comme une tendance, pas comme une promesse. Les réglages plus petits demandent aussi de la mémoire principale libre pour les spécialistes garés, jusqu'à environ 17 GB quand ils y passent tous.

Sur InferenceKey : prêt en 104 secondes, après une correction de la commande de la fiche du modèle

Un modèle d'agent 35B ne devrait pas avoir besoin d'un moteur sur mesure, et celui-ci n'en a pas eu besoin. Entre l'appel de déploiement et le service, il s'est écoulé 104,1 secondes, avec la version de llama.cpp que notre plateforme livre déjà : télécharger le fichier de 21,7 GB, le charger, répondre. Notre plateforme fait tourner un modèle sur un worker, une machine GPU que vous possédez ou louez et que vous y connectez, et son llama.cpp par défaut a chargé Sage-A1.5 sans modification. La première fois sur une machine neuve, llama.cpp doit aussi être compilé pour la carte, ce qui a pris dix minutes et demie. Ensuite, un redémarrage prend de 4 à 7 secondes.

Le seul problème sur lequel vous tomberez est dans la fiche du modèle elle-même. Sa commande llama.cpp utilise un réglage de raisonnement appelé deepthink, que llama.cpp n'a pas. Le serveur s'arrête au démarrage avec "Unknown reasoning format: deepthink". Nous avons aussi vérifié une version bien plus récente de llama.cpp, et il n'y existe toujours pas. La correction consiste à écrire deepseek à la place. Statut : corrigé dans notre exemple, toujours présent dans la fiche des auteurs.

Un second manque est de notre côté. Les auteurs activent Verification Mode avec un réglage que notre plateforme ne transmet pas encore au modèle. Notre exemple ajoute à la place la même ligne d'activation aux instructions du modèle. Nous avons vérifié que le modèle voit exactement le même prompt dans les deux cas. Statut : ouvert de notre côté, contourné dans l'exemple.

Faut-il l'essayer ? Oui sur une carte de 24 GB : la mécanique d'agent a fonctionné

• Si vous voulez un agent qui cherche, lit et rend compte sur votre propre matériel, essayez-le.
• Si la justesse sur les questions difficiles compte pour vous, testez Verification Mode sur vos propres cas difficiles.
• Si vous avez besoin de réponses de chat rapides, cherchez ailleurs. Il réfléchit sur des centaines ou des milliers de tokens avant des réponses courtes.
• Si votre carte a 16 GB ou moins, attendez-vous à une fraction de la vitesse, et seulement avec beaucoup de mémoire principale.

Pour poser à Sage-A1.5 la même question de recherche sur votre propre carte, avec des sous-agents et avec Verification Mode désactivé puis activé, lancez python main.py depuis l'exemple Sage-A1.5 du SDK. Il faut un projet InferenceKey avec un token SDK et une clé d'API, et un worker NVIDIA privé de 24 GB ou plus. Il supprime le déploiement quand il a fini.

llama-server -hf InternScience/Sage-A1.5-Q4_K_M-GGUF --hf-file Sage-A1.5-Q4_K_M.gguf \
  --no-mmproj --alias sage-a1.5 -ngl 99 -fa on -c 32768 -np 2 --kv-unified \
  --jinja --reasoning-format deepseek \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0 --presence-penalty 1.5

system = "You are a careful research assistant." + "\n\nVerification protocol: enabled"