Rechercheur interactif d’adéquation des modèles — sélectionnez le matériel ou le modèle, ajustez la quantification et le contexte.
Fonctionnement
Le widget estime les besoins en mémoire en utilisant :
Les modèles MoE (comme Qwen3.8-2.4T-A95B ou DeepSeek-V3) chargent tous les poids des experts en mémoire, donc le nombre total de paramètres détermine l’utilisation de la mémoire — même si seul le sous-ensemble actif s’exécute par token.
La formule de dimensionnement
Les poids du modèle occupent un nombre fixe d’octets par paramètre, et ce nombre dépend entièrement de la précision :
La taille brute des poids n’est pas tout. Vous avez aussi besoin de mémoire pour le cache KV, les activations et la surcharge du framework. Le widget ci-dessus ajoute une estimation modeste du cache KV (à la longueur de contexte sélectionnée) plus un facteur de 5% de surcharge sur les poids et le cache KV combinés :
×1.2 sur la taille brute des poids seule est un raccourci raisonnable — il intègre une estimation approximative du cache KV et de la surcharge en une étape, et c’est ce qu’utilisent les exemples détaillés ci-dessous.
Exemples détaillés à ~Q4 (4-bit), incluant la surcharge de ~1.2 :
À titre de référence, une précision plus élevée scale les mêmes modèles bien au-delà de ce qu’une seule carte grand public peut contenir :
70B en FP16 fait environ 140 GB, et 120B en FP16 fait environ 230 GB.
Hugging Face documente un schéma similaire à travers les tailles de modèle : par exemple, environ 29 GB en bf16, ~15 GB en 8-bit, et ~9.5 GB en 4-bit pour un grand modèle. Consultez le guide Hugging Face pour l’optimisation des LLM et le README quantize de llama.cpp pour les chiffres sous-jacents — GGUF Q4_K_M utilise une précision mixte qui moyenne environ 0.5–0.56 octets par paramètre.
La compression de poids ternaire va plus loin que toute quantification standard. Bonsai 2 27B stocke chaque poids comme -1, 0 ou +1 — environ 1.58 bits par poids — réduisant Qwen3.8-27B de 54 GB à 5.9 GB. Cela tient sous 6 GB de VRAM sur un GPU grand public. Le calculateur ci-dessus ne modélise pas directement le format ternaire, car c’est une technique au moment de l’entraînement plutôt qu’une quantification post-entraînement applicable à n’importe quel modèle.
Ces formules estiment la taille des poids. Le nombre réel qui importe est la taille du fichier
GGUF listée sur Hugging Face pour la quantification exacte que vous prévoyez d’exécuter, plus le cache KV pour votre longueur de contexte cible. Vérifiez toujours cela avant de vous engager sur du matériel.VRAM des GPU en un coup d’œil
Sources : NVIDIA GeForce RTX 50 series, NVIDIA professional GPUs, Wikipedia: GeForce RTX 40 series, Wikipedia: GeForce RTX 30 series, AMD Ryzen AI Max, spécifications techniques Apple.
La mémoire GDDR dédiée (les cartes NVIDIA ci-dessus) est rapide et de taille fixe — vous ne pouvez pas en ajouter plus tard. La mémoire unifiée (Apple Silicon, Strix Halo) partage un seul pool entre le CPU et le GPU, donc elle peut être bien plus grande, mais elle tourne à une bande passante plus faible qu’une carte dédiée.
Ce qui tient où
Le tableau ci-dessous estime le niveau de confort à la quantification~Q4 pour une longueur de contexte modeste. Considérez chaque entrée comme une estimation — vérifiez la taille réelle du fichier GGUF plus le cache KV avant de vous engager.
La vérité terrain est toujours la taille du fichier
GGUF sur Hugging Face pour la quantification que vous choisissez, plus le cache KV que votre longueur de contexte requiert.
Vous avez choisi un modèle ? Connectez-le
Un point de terminaison authentifié sur
https://api.tokios.com — aucun port entrant, environ 5 minutes.Pourquoi la mémoire unifiée charge les grands modèles mais les exécute plus lentement
Charger un modèle nécessite seulement une capacité mémoire suffisante pour contenir les poids. L’exécuter rapidement nécessite une bande passante mémoire suffisante pour alimenter en continu les unités de calcul, car le décodage à flux unique est limité par la bande passante mémoire — chaque token généré doit lire les poids du modèle (ou, pour un modèle mixture-of-experts, les experts actifs) depuis la mémoire. Le prefill (traitement du prompt) est limité par le calcul à la place, donc il se comporte différemment. C’est pourquoi les deux types de mémoire présentent des compromis différents :- GDDR dédié (RTX 4090, 5090 et similaires) : bande passante élevée (environ
1000–1800 GB/s), mais capacité fixée par la carte. - Mémoire unifiée (Apple Silicon, Strix Halo) : capacité bien plus grande (jusqu’à
128 GB), mais bande passante plus faible (environ256–546 GB/s).
96 GB peut charger un modèle de 120B qui ne tiendrait jamais sur un seul GPU grand public. Il générera néanmoins les tokens plus lentement qu’un GPU dédié exécutant un modèle qui tient dans sa propre VRAM, car il a moins de bande passante pour déplacer les poids par token.
Ne vous fiez pas aux chiffres de tok/s publiés par d’autres configurations — le matériel, les versions de pilotes, la quantification, la longueur du contexte et la taille du lot modifient tous le résultat. Mesurez votre propre déploiement avec llama-bench et consultez Test your deployment pour une méthode reproductible de comparaison des déploiements une fois votre modèle en fonctionnement.
Étapes suivantes
Commencer avec Tokios
Une fois qu’un modèle convient à votre matériel, Tokios le transforme en un point de terminaison API stable que vous pouvez appeler de n’importe où.
Choisir le bon modèle pour votre tâche
Le dimensionnement réduit ce qui convient. L’adéquation à la tâche réduit quelle famille charger en premier lieu.