Nemotron Bolt E4B ou une API hébergée ? Choisissez selon le contexte et la tâche

Si votre tâche tient dans 64 000 tokens et que votre GPU a la place pour un modèle d'environ 4 Go, le Nemotron 3.5 Bolt E4B de NVIDIA peut l'exécuter sur votre propre machine. Si le travail nécessite une fenêtre plus grande, une réponse longue ou 20 000 éléments terminés aujourd'hui, un modèle hébergé est la voie la plus courte. Voici un tableau qui trie votre tâche, et l'arithmétique derrière chaque ligne.

Le côté hébergé de la comparaison utilise les trois modèles de la page des modèles CheapTokens : DeepSeek-V4-Flash, GLM-5.3-Flash et MiniMax-M2.7.

Ce que NVIDIA a publié, et ce qu'il a omis#

La page de recherche de NVIDIA pour Nemotron 3.5 Bolt E4B (publié le 23 octobre 2026, vérifié le 5 novembre) décrit un modèle construit sur Gemma 4 E4B et livré sous forme de checkpoint GGUF, quantification Q4_K_M, pour llama.cpp. NVIDIA indique qu'il tient dans aussi peu que 4 Go ; la VRAM mesurée allait de 3,1 à 5,0 Go (sur la charge de test de NVIDIA ; avec une fenêtre complète de 64K, l'utilisation mémoire sera plus élevée, donc vérifiez sur votre propre carte). Les poids sont sur Hugging Face sous nvidia/NVIDIA-Nemotron-3.5-Bolt-E4B-4GB et sont également disponibles via Ollama, LM Studio et Unsloth.

Trois faits décident de la plupart des choix :

• Contexte : 64K tokens. NVIDIA précise explicitement que la fenêtre contient tout à la fois : historique de chat, instructions, définitions d'outils et texte récupéré.
• Langues : 35, à partir d'un modèle de base pré-entraîné sur plus de 140.
• Vitesse : dans les exécutions llama.cpp CUDA de NVIDIA (Q4_K_M, taille de lot 1), une RTX 5070 avec 12 Go a utilisé 3,5 Go de VRAM et produit 133,4 tokens par seconde. Un Jetson Orin Nano avec 8 Go a utilisé 4,2 Go et produit 15,5 tokens par seconde. Les deux chiffres proviennent de la charge de test de NVIDIA, attendez-vous donc à des différences.

La page liste aussi des scores d'utilisation d'outils (BFCL-v3 68,5, Tau2-Bench 55,1) et RULER à 64K de 87,0. Ce sont les benchmarks du développeur lui-même : ils indiquent sur quoi le modèle a été testé, pas comment il se compare à un modèle hébergé, donc cet article ne les aligne pas.

Deux choses que la page ne précise pas : la longueur maximale d'une réponse unique, et la licence. Lisez les deux sur la fiche du modèle Hugging Face avant de construire quoi que ce soit dessus.

Quelle taille fait 64K quand un agent commence à travailler ?#

Considérez la fenêtre comme un bureau. Le modèle ne peut travailler qu'avec ce qui s'y trouve à l'instant présent, et l'historique, vos instructions, les définitions d'outils et tout texte récupéré partagent le même bureau. Alors, quelle surface représente 64K ?

C'est un court roman, donc un chat, un e-mail ou une traduction tient confortablement. La contrainte vient des agents, car chaque étape dépose la sortie de son outil sur le bureau et rien n'en sort.

Les agents réels contournent cela en tronquant ou en résumant les anciennes étapes. Cela fonctionne, mais c'est du code supplémentaire à écrire et à déboguer. Le côté coût de la même boucle est traité dans Coût d'une session d'agent : 50 étapes sur GLM, DeepSeek ou MiniMax.

Triez votre tâche : local ou hébergé#

La même question pour un grand modèle ouvert est traitée dans Exécuter DeepSeek localement ou utiliser une API. Pour un modèle de 4 Go, la réponse dépend de la tâche, alors triez d'abord la tâche et installez ensuite.

Les colonnes hébergées proviennent de la liste des modèles CheapTokens. DeepSeek-V4-Flash a un contexte de 380K, jusqu'à 32 768 tokens de sortie par réponse et un prix unique à toute heure. GLM-5.3-Flash a un contexte de 390K et jusqu'à 8 192 tokens de sortie. MiniMax-M2.7 a un contexte de 180K, jusqu'à 8 192 tokens de sortie, et convient aux travaux agentiques et de codage via une API.

Une ligne que le tableau ne peut pas capturer : si le texte ne doit jamais quitter votre machine, cela tranche en faveur du local.

Tâches en masse : des heures de GPU ou une petite facture#

Supposons que vous étiquetiez 20 000 tickets de support. Chacun fait environ 600 tokens en entrée et une étiquette de 50 tokens en sortie.

Totaux : 20 000 × 600 = 12 000 000 tokens d'entrée et 20 000 × 50 = 1 000 000 tokens de sortie.

Générer ces 1 000 000 de tokens aux vitesses mesurées par NVIDIA prend 1 000 000 ÷ 133,4 = 7 496 s (environ 2,1 heures) sur la RTX 5070 et 1 000 000 ÷ 15,5 = 64 516 s (environ 17,9 heures) sur le Jetson Orin Nano. Cela ne compte que la génération : la lecture des 12 millions de tokens d'entrée s'y ajoute, ainsi que l'électricité que la carte consomme pendant tout ce temps.

Le côté hébergé de la même tâche, aux prix actuels :

Le tableau chiffre la tâche sur chaque modèle, avec une colonne OpenRouter. Au total, en comptant l'entrée et la sortie ensemble, chacun d'eux revient moins cher qu'OpenRouter. Sur DeepSeek-V4-Flash, par exemple, les 1 000 000 de tokens de sortie sont facturés à $0.10 par 1M.

Votre tâche n'est probablement pas de 20 000 tickets. Mettez vos propres chiffres :

Vous avez maintenant les deux côtés dans les mêmes unités : des heures d'une machine que vous possédez contre des dollars sur un tableau en direct.

Documents longs et réponses longues#

Prenez un dossier de contrats de 120 000 tokens. Il est plus grand que 64 000, donc un Bolt E4B local nécessiterait de découper le dossier en morceaux, de l'interroger pièce par pièce et de recoudre les réponses. Sur une fenêtre de 380K, il passe en une seule requête : avec une réponse de 2 000 tokens, cela fait $0.002 aux prix actuels. Quel modèle convient à un document de 100K tokens passe en revue les limites de contexte et de sortie modèle par modèle.

Les réponses longues sont l'autre limite. DeepSeek-V4-Flash peut écrire jusqu'à 32 768 tokens en une réponse, et avec la même règle approximative de ¾ de mot par token (une hypothèse), 32 768 × 0,75 = 24 576 mots, soit un long rapport ou un fichier de code entier. La page de NVIDIA ne donne aucun maximum pour Bolt E4B, donc avant de planifier une sortie de 10 000 tokens en local, testez ce que votre runtime renvoie réellement.

Routez par taille : le même code, deux destinations#

Vous n'êtes pas obligé de choisir pour toujours. Gardez le petit modèle pour les petites tâches et envoyez les grosses vers un modèle hébergé. Si votre outil parle déjà à un endpoint compatible OpenAI, le changement se résume à une URL de base, une clé et un identifiant de modèle complet.

import os
from openai import OpenAI

hosted = OpenAI(
    base_url='https://api.cheaptokens.dev/v1',
    api_key=os.environ['CHEAPTOKENS_API_KEY'],
)

def too_big_for_local(text: str, limit: int = 60_000) -> bool:
    return len(text) // 4 > limit  # rough: about 4 characters per token in English

document = open('contract.txt', encoding='utf-8').read()
if too_big_for_local(document):
    resp = hosted.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[{'role': 'user', 'content': 'List the termination clauses:\n\n' + document}],
        max_tokens=2000,
    )
    print(resp.choices[0].message.content)
    print(resp.usage)

La limite de 60 000 laisse de la place sous la fenêtre de 64K pour les instructions et la réponse. Quand l'appel fonctionne, vous voyez le texte de la réponse, puis un objet usage avec prompt_tokens et completion_tokens : multipliez-les par les prix de la page de tarification pour obtenir le coût de la requête. Les étapes de la première requête sont dans la documentation.

Commencez par la ligne du tableau qui correspond à votre tâche. Si elle indique local, téléchargez le GGUF et mesurez vos propres tokens par seconde avant de planifier sur les chiffres de qui que ce soit.