Retour au feed
Reddit r/LocalLLaMA·

Tiny LLM Benchmark: Jetson Orin Nano Super 8GB - Four Power Modes × Eight Models

Signal
82
Hype
15
En 3 lignesBenchmark complet de 8 petits LLMs (135M–1B) sur Jetson Orin Nano Super 8GB avec llama.cpp CUDA, testés en 4 modes de puissance (7W–MAXN). Mode 25W optimal : SmolLM2-135M atteint 165 tok/s et 22.6 tok/J ; LFM2.5-1.2B meilleur en classe ~1B (54.1 tok/s). 384 cellules de benchmark, données brutes publiées.

## Jetson Orin Nano Super : 384 cellules de benchmark pour cartographier l'efficacité énergétique des petits LLMs

### Ce que ce benchmark apporte réellement

Les benchmarks sur matériel edge sont rares, méthodologiquement sérieux encore plus. Celui-ci couvre 8 modèles × 4 modes de puissance × 48 combinaisons prompt/génération = 3 072 points de mesure bruts, publiés sur HuggingFace. C'est exploitable directement par quiconque déploie des inférences locales sur Jetson ou matériel Ampere contraint.

Le Jetson Orin Nano Super 8GB à 250 $ est aujourd'hui la référence entrée de gamme pour l'inférence edge sous NVIDIA. Son architecture unifiée CPU+GPU (8 GB LPDDR5 @ 204,8 GB/s, pas de split VRAM) le distingue des GPU discrets : toute la mémoire est accessible sans transfert PCIe, ce qui avantage les modèles tenant en RAM unifiée. Avant ce benchmark, les données publiques sur ce device se limitaient à des tests isolés, sans comparaison systématique des modes de puissance.

### Le résultat central : 25W est le point Pareto, pas MAXN

C'est la conclusion la plus actionnelle. Le mode MAXN (fréquences maximales, consommation non plafonnée) produit +8 à +35 % de tok/J en moins que le mode 25W selon les modèles. Autrement dit, pousser le SoC à fond dégrade l'efficacité énergétique de manière mesurable. Le mode 25W délivre 36–47 % de débit supplémentaire par rapport au 15W, tout en maintenant une efficacité énergétique 3–26 % supérieure. La température junction est restée ≤ 73 °C sur l'ensemble des runs avec refroidissement actif — pas de throttling thermique observé.

Pour les déploiements sur batterie ou à budget énergétique fixe (drones, robots, capteurs industriels), cette donnée change directement le paramétrage système recommandé.

### Classement des modèles : taille vs efficacité

**Classe sub-1B :** - SmolLM2-135M : 165 tok/s, 22,6 tok/J, 101 MB, ~5,4W à 25W. Meilleure efficacité énergétique de toute la suite. Pour des tâches de classification, extraction simple ou complétion courte, c'est le choix rationnel sur ce hardware. - LFM2.5-350M : 120 tok/s dans 219 MB. Il égale le SmolLM2-360M (369 MB) à moins de la moitié de l'empreinte mémoire — avantage architectural direct des LFM (Liquid Foundation Models) sur les transformers classiques pour ce segment.

**Classe ~1B (ctx=2048, gen=256) :** - LFM2.5-1.2B : 54,1 tok/s, 5,26 tok/J, 698 MB, 8,46W. Meilleur débit et meilleur tok/J brut de la classe. - Gemma3-1B : légèrement devant sur tok/J total (118,5 vs 116,2) grâce à une consommation plus basse (6,87W vs 8,46W) qui compense un débit inférieur. Si la contrainte est strictement énergétique plutôt que latence, Gemma3-1B gagne. - Llama3.2-1B : 47,0 tok/s, 4,67 tok/J — troisième sur les deux métriques clés dans sa classe.

### Les perdants implicites

**Llama3.2-1B** sort clairement dominé dans sa classe par LFM2.5-1.2B sur débit (+15 %) et tok/J (+12,6 %). Pour Meta, dont la série 3.2 visait explicitement le edge, ce positionnement est inconfortable face à des architectures alternatives.

**Le mode MAXN** comme choix par défaut dans les tutoriels Jetson est remis en question. Beaucoup de guides recommandent MAXN pour "les meilleures performances" sans nuancer l'efficacité — ce benchmark montre que c'est une erreur pour l'inférence LLM.

**Les transformers denses classiques** dans la gamme 350M–400M subissent la pression des LFM : LFM2.5-350M à 219 MB vs SmolLM2-360M à 369 MB pour des performances équivalentes représente un ratio mémoire de 0,59×.

### Limites et ce qui manque

Le benchmark mesure uniquement le débit de génération (output tokens/s et tok/J). Il n'évalue pas la qualité des sorties — aucun score MMLU, HellaSwag ou benchmark de code. Un modèle plus lent mais plus précis peut rester préférable selon le cas d'usage. La méthodologie aiperf avec 20 requêtes par combinaison est correcte mais ne teste pas les scénarios de concurrence (plusieurs requêtes simultanées), pertinents pour les déploiements serveur edge.

Les données brutes HuggingFace permettent à la communauté de compléter l'analyse — c'est la valeur ajoutée principale de cette publication par rapport aux benchmarks fermés.

Lire la source
Ton avis ?
BenchmarksOpen sourceInfrastructureGénération de code

Résumé généré par Claude — vérifié par l'humain