Le modèle Qwen de 30 milliards de paramètres fonctionne en temps réel sur un Raspberry Pi

 (byteshape.com)
22 points par GN⁺ 2026-01-07 | 1 commentaires | Partager sur WhatsApp
  • Le modèle Qwen3-30B-A3B-Instruct-2507 fonctionne en temps réel sur un Raspberry Pi 5 (16 Go), tout en maintenant 8,03 TPS et 94,18 % de la qualité BF16
  • Grâce à la méthode d’apprentissage de longueur de bit ShapeLearn de ByteShape, l’équilibre entre vitesse et qualité est optimisé dans les limites mémoire de chaque appareil
  • Par rapport à Unsloth et MagicQuant, il atteint soit un TPS plus élevé à qualité égale, soit une meilleure qualité à TPS égal
  • Sur CPU comme sur GPU (notamment RTX 5090 et 4080), la zone proche de 4 bits apparaît comme le point de performance optimal, et réduire le nombre de bits n’accélère pas toujours l’exécution
  • Globalement, les modèles ByteShape offrent de bonnes performances de l’edge au datacenter avec une approche consistant à « considérer la mémoire comme un budget et optimiser le TPS/la qualité »

Aperçu de l’optimisation basée sur ShapeLearn

  • ByteShape optimise l’exécution des modèles en se concentrant sur la vitesse perçue et la qualité des réponses
    • ShapeLearn apprend le type de données des poids de chaque tenseur (bitlength) afin de maximiser simultanément le TPS (tokens par seconde) et la qualité de sortie
    • L’objectif n’est pas simplement de réduire la taille des fichiers, mais d’améliorer le véritable compromis entre vitesse et qualité
  • Dans l’environnement llama.cpp, réduire le nombre de bits n’améliore pas toujours la vitesse, et le choix du kernel ainsi que les surcoûts influencent fortement les performances
  • ByteShape considère la mémoire comme un « budget à faire rentrer », puis ajuste ensuite en priorité le TPS et la qualité

Performances sur Raspberry Pi 5

  • Sur Raspberry Pi 5 (16 Go), le modèle 30B conserve 8,5 TPS et plus de 92 % de précision
    • Le modèle Q3_K_S-2.70bpw [KQ-2] offre une réactivité adaptée à la conversation en temps réel
  • Sur les modèles orientés précision, ByteShape atteint un taux d’erreur relatif de 1,1 à 1,3 % (environ 98,8 % de précision), soit jusqu’à 1,87 fois moins d’erreurs qu’Unsloth
    • Dans le même environnement, ils maintiennent 5 à 6 TPS, ce qui les rend adaptés aux tâches privilégiant la précision
  • Le modèle orienté vitesse (Q3_K_S-3.25bpw [KQ-5]) est lui aussi plus petit et plus rapide qu’Unsloth, tout en gardant un avantage en précision
  • De nombreux modèles d’Unsloth et de MagicQuant ne peuvent pas être exécutés sur Pi en raison des contraintes mémoire

Performances sur Intel i7 (64 Go)

  • Dans un environnement où tous les modèles tiennent en mémoire, ByteShape obtient une meilleure qualité et un TPS plus élevé que Unsloth et MagicQuant
  • Segment orienté qualité : le modèle IQ4_XS-4.67bpw [KQ-9] de ByteShape affiche un taux d’erreur 1,44 fois plus faible que le Q6_K d’Unsloth, avec un TPS supérieur
  • Segment équilibré : le modèle Q3_K_S-3.25bpw de ByteShape présente un taux d’erreur 1,73 fois plus faible que celui d’Unsloth, et surpasse MagicQuant en précision comme en vitesse
  • ByteShape est le seul à couvrir à la fois la zone des 26+ TPS et celle de haute qualité

Comparaison des performances GPU (RTX 5090 / RTX 4080)

  • Sur GPU, les performances dépendent du choix du kernel et de l’efficacité d’accès à la VRAM
    • La zone proche de 4 bits (~4bpw) est confirmée comme le sweet spot pour le TPS et la qualité
  • RTX 5090 (32 Go)
    • Unsloth, MagicQuant et ByteShape se situent tous entre 302 et 303 TPS dans la zone 4b, avec une précision de 98,4 à 98,9 %
    • Le modèle IQ4_XS-4.67bpw de ByteShape atteint la meilleure précision avec 272,98 TPS et 99,75 % de précision
    • Il surpasse Unsloth Q6_K (6.57bpw, 264.88 TPS, 99.64 %) et MagicQuant mxfp4 (5.46bpw, 240.42 TPS, 99.32 %)
  • RTX 4080 (16 Go)
    • Les contraintes de VRAM empêchent l’usage des modèles 4b ; dans les mêmes 16 Go, ByteShape est supérieur à Unsloth en TPS comme en précision
    • ByteShape IQ4_XS-3.87bpw : 214.81 TPS, 98.66 % de précision
      • Par rapport à Unsloth Q3_K_XL : 1,59 fois moins d’erreurs et 9,4 % de TPS en plus
      • Par rapport à Unsloth IQ2_M : 2,54 fois moins d’erreurs

Le paradoxe du nombre de bits et de la vitesse

  • Réduire à 3 bits ou moins ne garantit pas un gain de vitesse
    • Les GPU fonctionnent par warps de 32 threads et sont optimisés pour certains formats de données et schémas d’accès
    • La VRAM lit par blocs alignés de 32 octets, de sorte que des données plus petites peuvent consommer la même bande passante
    • Une faible largeur en bits peut au contraire ralentir l’exécution à cause de la hausse du surcoût de décodage
  • Exemple : sur RTX 5090, iq4_xs prend 54µs contre 62µs pour iq3_xxs → 25 % de capacité en moins se traduit par une baisse de vitesse de 13 %
  • ShapeLearn prend en compte ces caractéristiques matérielles pour choisir le type de données de chaque tenseur et garantir à la fois vitesse et précision

Méthode d’évaluation et conclusion

  • Tous les modèles ont été mesurés avec le même harness d’évaluation pour le TPS et un score de qualité normalisé (par rapport au BF16)
    • L’évaluation de la qualité agrège les résultats de MMLU, GSM8K, IFEval, LiveCodeBench V4
  • Conclusions clés :
    • « Traitez la mémoire comme une contrainte, pas comme un objectif. »
    • Une fois le modèle chargé sur l’appareil, c’est la courbe d’équilibre entre TPS et qualité qui devient essentielle
    • ByteShape atteint sur tous les appareils soit une vitesse plus élevée à qualité égale, soit une meilleure qualité à vitesse égale
  • Sur Raspberry Pi 5, le modèle Q3_K_S-2.70bpw [KQ-2] convient à la conversation en temps réel
  • Le même principe s’applique aussi aux grands environnements CPU/GPU : « d’abord faire tenir, puis optimiser. »
  • ByteShape prévoit de continuer à publier davantage de modèles optimisés par appareil

À lire aussi

1 commentaires

 
GN⁺ 2026-01-07
Avis Hacker News

  • Je pense qu’il y a ici une grosse opportunité de marché
    Ce que je veux, c’est un assistant vocal de type Alexa, mais avec des composants standardisés basés sur de l’inférence locale et du stockage local

    • Appareil conversationnel : un appareil de type Alexa/Google/Apple avec de bons haut-parleurs et le contrôle vocal, ou bien un périphérique d’entrée pour la TV. Ce serait bien s’il pouvait aussi faire office d’extendeur Wi‑Fi ou de routeur. J’aimerais en mettre un dans chaque pièce pour créer un vrai réseau maillé
    • Serveur cloud domestique : un appareil avec un CPU bon marché, un peu de RAM et suffisamment de stockage, qui servirait de nœud central pour gérer les applications de la maison et les sauvegardes réseau
    • Moteur d’inférence : ce serait bien qu’il annonce les services de manière standardisée et que le nœud de contrôle s’y connecte automatiquement. Je veux un environnement plug-and-play qui fonctionne dès qu’on le branche
      L’essentiel, c’est la confidentialité et l’interopérabilité. S’il faut créer un compte ou se connecter à un serveur externe, je n’achèterai pas. Je veux que des commandes comme « Freddy, règle un minuteur sur 10 minutes » soient traitées en local
    • Il n’existe pas encore de produit totalement plug-and-play, mais j’ai obtenu des résultats assez satisfaisants avec Home Assistant et sa Voice Preview Edition
      L’idée consiste à répartir plusieurs appareils Wi‑Fi + micro + haut-parleur à bas coût dans toute la maison, tandis que le traitement vocal est assuré par une machine centrale plus puissante
      Au final, tout cela fonctionne comme un seul programme, donc en ajoutant une carte Wi‑Fi à une machine un peu plus puissante, elle pourrait aussi servir d’extendeur Wi‑Fi
    • Je partage aussi cette idée. J’ai du mal à rendre fluide l’intégration vocale avec ChatGPT dans Home Assistant (HA)
      Je n’aime pas non plus le concept de mot d’activation (wake word). J’ai l’impression qu’il reste encore beaucoup de choses à améliorer dans toute la stack
    • Et ce serait aussi amusant de voir ce type de système appliqué aux jouets

  • Je me demande s’il existe une bonne ressource pour comparer facilement différents modèles
    Je connais la différence de nombre de paramètres entre gpt-oss-20b et gpt-oss-120b, mais je ne vois pas bien ce que cela change en performances réelles
    Je n’ai utilisé que de gros modèles comme Gemini ou GPT, et j’aimerais savoir jusqu’à quelle taille de modèle plus réduite je pourrais encore les utiliser utilement sur mon matériel

  • J’ai cherché à voir ce que signifiait exactement une performance « en temps réel »
    Sur un Pi 5 (16GB), le modèle Q3_K_S-2.70bpw [KQ-2] atteindrait 8.03 TPS tout en conservant 94.18 % de la qualité BF16
    L’article traite aussi d’autres détails matériels

    • Je me dis qu’une page de résumé Hacker News qui ne montrerait que ce genre de chiffres clés serait utile

  • J’ai moi aussi fait des tests sur un Pi 5 (16GB) avec la dernière version de llama.cpp, mais j’ai eu une segmentation fault (segfault)
    Un message d’erreur de manque de mémoire s’est affiché, et le processus s’arrêtait après avoir utilisé environ 10GB de RAM
    En réduisant la taille du contexte avec l’option -c 4096, le chargement a réussi

    • Cela vaut peut-être le coup d’essayer les modèles quantifiés en 4 bits de illama ou ik_llama.cpp, ainsi que Microsoft BitNet
      Des modèles comme BitNet b1.58-2B-4T-gguf semblent bien adaptés à des essais comparatifs sur des appareils peu puissants ou des PC de bureau équipés uniquement d’un iGPU
    • Il est aussi possible qu’ils aient ajouté de la mémoire swap

  • Je me demande si la façon de mesurer la précision est différente de la perplexité habituelle
    Passer de BF16 à 2.8 avec seulement 5 % de perte de qualité me paraît étonnant

  • GPT-OSS-20B fait environ 11.2GB, donc il devrait pouvoir tourner sans perte de qualité même sur une machine avec 16GB de mémoire