300B sur un mini-PC, 64 tâches dans 6B : le local resserre les coûts

150 langues, et le document entier

Bilibili publie Index-Translate, une famille de modèles de traduction multilingue bâtie sur Qwen3.5. Les modèles texte couvrent 150 langues et suivent des consignes de terminologie et de formatage : on peut donc leur imposer un vocabulaire et une mise en forme, pas seulement une langue cible.

La famille ne s'arrête pas au texte. Index-Echo produit des sous-titres ou une voix à partir de la voix du locuteur, et Index-NativeLong traduit un document complet en gardant le contexte entre les passages. C'est ce dernier point qui structure l'ensemble : l'enjeu annoncé n'est pas de traiter chaque segment isolément, mais de conserver le fil à l'échelle d'un document entier. La traduction, la synthèse vocale et le traitement long document se retrouvent ainsi réunis sous une même famille de modèles.

Du 300B sur un mini-PC, du 27B sur une RTX 4080

Deux projets racontent la même poussée vers le matériel modeste. Kyojin, moteur construit sur ExLlamaV3 pour Strix Halo (gfx1151, ROCm), fait tenir deux modèles MoE de classe 300B chacun sur une seule machine de 128 Go. Sur un Ryzen AI Max+ 395, GLM-5.3-Flash (99,7 Go) atteint 580 tok/s en prefill à 3,5K et 26 à 30 tok/s en décodage, tandis que MiMo-V2.6-Flash-MOPD (105 Go) grimpe à 44 tok/s en code. Les poids MiMo viennent d'une quantification maison ; le pack GLM mélange des tenseurs EXL3 publics de turboderp en 2,05 et 3,05 bpw.

Autre machine, autre contrainte : Ninfer 4080 fait tourner ISTA-DASLab-Qwen-3.8-27B-GSQ sur une RTX 4080 de 16 Go avec 100k de contexte. Le développeur annonce jusqu'à 2720 tok/s en préfill et 262 tok/s en génération, là où les projets Ninfer 5090, 4090 et 3090 restaient hors de portée de cette classe de GPU. Le code est partagé sur GitHub, et l'auteur précise avoir 20 ans d'expérience en ingénierie logicielle — mais aucune en développement de kernels GPU.

Un humanoïde de 6B pour 64 tâches

Unitree Robotics présente UnifoLM-WLA-1.0, un modèle de fondation humanoïde de 6B paramètres entraîné sur environ 2 500 heures de données issues de robots réels. Un seul modèle couvre 64 tâches, dont 10 de corps entier et 54 sur table, avec pincements parallèles ou deux mains dextres.

La démonstration tourne sur le robot G1 : faire le lit, charger la machine à laver, plier du linge, trier des objets. Le chiffre à retenir n'est pas la taille du réseau mais le nombre de gestes qu'il absorbe : 64 tâches pour 6B paramètres, là où l'on attendrait volontiers une architecture plusieurs fois plus lourde.

Des plafonds durs, pas des e-mails

Simon Willison estime que les services facturés à l'usage et les API doivent proposer des plafonds budgétaires durs par défaut : passé un montant mensuel, le service s'arrête et renvoie des erreurs. Les plafonds souples, qui se contentent d'un e-mail d'avertissement, ne suffisent pas selon lui.

Son argument tient à ce que les agents changent. Les agents de code, et les agents personnels, réduisent fortement la friction pour lancer du code qui appelle des API payantes, des applications hébergées, ou du stockage et du calcul facturés à l'usage. Moins de friction pour déclencher, donc, mais aussi moins d'occasions de reprendre la main avant la facture — d'où la préférence pour un arrêt automatique plutôt qu'une alerte.

Et maintenant ?

Les dépêches dessinent deux mouvements parallèles. D'un côté la compression : traduction multilingue dans une famille unique, deux MoE de classe 300B sur 128 Go, 100k de contexte sur 16 Go, 64 tâches dans 6B de paramètres. De l'autre la facture : quand les agents multiplient les appels payants, le plafond budgétaire devient une fonctionnalité au même titre que la fenêtre de contexte. Le point commun est arithmétique. Ce qui compte n'est plus seulement ce qu'un modèle sait faire, mais ce qu'il coûte en mémoire ou en euros pour le faire.