Gemma 4 26B local vs API : configuration 2GB, vitesse et coût

TL;DR

TurboFieldfare signale l’exécution d’une configuration Gemma 4 26B texte uniquement avec environ 2GB de mémoire d’exécution en gardant les composants partagés et un cache KV 4K en mémoire tout en diffusant en continu les experts routés depuis le SSD. Il s’agit d’une configuration spécialisée à faible mémoire pour Apple Silicon — pas d’une exigence minimale universelle pour Gemma 4 26B.

Gemma 4 26B A4B est un modèle Mixture-of-Experts de 25.2B paramètres qui active environ 3.8B paramètres par jeton. Google propose également un accès hébergé via l’API Gemini sous l’ID de modèle gemma-4-26b-a4b-it.

TurboFieldfare réduit la mémoire résidente en ne conservant que le noyau de modèle partagé, le cache KV et les experts récemment utilisés en mémoire. Les autres experts routés sont chargés depuis le SSD à mesure que chaque jeton est généré.

Le résultat annoncé de 2GB s’accompagne de plusieurs limites :

• Il utilise un cache KV 4K, et non la fenêtre de contexte complète de 256K du modèle.
• L’installation locale du modèle nécessite toujours environ 14.3GB de stockage SSD.
• Les performances dépendent de la vitesse du SSD, du comportement du cache et du matériel Apple Silicon.
• L’exécution actuelle prend en charge l’inférence texte uniquement.

La voie locale est conçue pour une utilisation hors ligne, la confidentialité sur l’appareil et le contrôle du matériel. L’API hébergée de Google offre l’entrée texte et image, une infrastructure gérée et une mise à l’échelle plus simple.

Ce guide explique la configuration à 2GB, puis compare l’inférence locale avec l’API de Google en termes de mémoire, vitesse, contexte, confidentialité, préparation à la production et coût total.

Gemma 4 26B API vs Local en un coup d’œil

Selon la fiche du modèle Gemma 4 officielle, la variante 26B A4B utilise 128 experts routés, en active huit par jeton, et inclut un expert partagé.

Bref contexte sur Gemma 4 26B A4B

Gemma 4 (publié ~avril 2026 par Google DeepMind sous Apache 2.0) inclut des modèles denses (E2B, E4B, 12B, 31B) et cette variante Mixture-of-Experts (MoE) : ~25.2B de paramètres totaux mais seulement ~3.8B actifs par jeton (le « A4B »). Il route chaque jeton vers un petit sous-ensemble d’experts (typiquement 8 actifs sur 128 au total + 1 expert partagé). Cela fournit une qualité proche d’un 31B pour un coût de calcul de classe ~4B, avec une fenêtre de contexte 256K et un support multimodal (texte + image).

Distinction importante : Tous les ~26B paramètres doivent toujours être disponibles pour le routage. Les runtimes classiques (Ollama, llama.cpp, LM Studio, vLLM, etc.) chargent l’ensemble des poids quantifiés en RAM/VRAM.

Que signifie l’affirmation sur Gemma 4 local en 2GB ?

Le résultat 2GB vient de TurboFieldfare, un runtime indépendant en Swift et Metal conçu spécifiquement pour Gemma 4 26B A4B sur Apple Silicon.

TurboFieldfare ne conserve pas toute l’installation locale du modèle en mémoire unifiée. Il garde en mémoire un noyau de modèle partagé de 1.35GB et le cache KV en FP16, puis diffuse en continu les experts routés requis pour chaque jeton depuis le SSD.

Le projet rapporte la configuration de référence suivante :

Ce sont des mesures communautaires de runtime, et non des benchmarks officiels de Google. La longueur de l’invite, la longueur générée, les performances du SSD, le comportement du cache d’experts et la configuration matérielle peuvent tous influencer le résultat.

Le résumé exact est :

TurboFieldfare exécute une configuration quantifiée, texte uniquement, de Gemma 4 26B A4B utilisant environ 2GB pour les poids et un cache KV 4K en diffusant les experts routés depuis le SSD.

Il ne faut pas résumer ainsi :

Gemma 4 26B n’a besoin que de 2GB de RAM.

Cette formule raccourcie omet l’exigence de 14.3GB de stockage, la configuration de contexte limitée, la dépendance au SSD, la méthode de quantification, et la mémoire toujours requise par macOS et les autres applications.

Ce que nécessite réellement l’inférence locale standard

Google publie les exigences mémoire approximatives suivantes pour l’inférence classique de Gemma 4 26B A4B :

Ces chiffres incluent une surcharge de chargement du modèle estimée à 20 %. Ils n’incluent pas la mémoire supplémentaire nécessaire au framework d’inférence ni au cache KV.

Voir l’aperçu de Gemma 4 et le tableau mémoire pour les estimations officielles actuelles.

Comment les 2GB se comparent-ils aux exigences standard ?

TurboFieldfare atteint une mémoire résidente bien plus faible car il ne garde pas le modèle quantifié complet en mémoire. Il combine :

1. Des poids de modèle en quatre bits.
2. Un cache d’experts en mémoire borné.
3. Un streaming depuis le SSD pour les experts routés.
4. Un cache KV 4K dans la configuration publiée.
5. Des kernels d’inférence Swift et Metal personnalisés.

Cela produit un compromis différent d’un déploiement entièrement résident conventionnel.

Un modèle Q4 entièrement résident requiert nettement plus de mémoire mais évite de recharger sans cesse les données des experts depuis le stockage. TurboFieldfare réduit la pression mémoire, mais rend les performances plus dépendantes de la bande passante SSD, des taux de hits du cache, de la longueur de contexte et de la génération du matériel.

Cela fonctionne parce que le modèle est MoE. Les modèles denses ne peuvent pas le faire utilement — chaque poids participe à chaque passage avant. C’est une astuce d’ingénierie qui exploite l’architecture plutôt qu’un changement fondamental de la taille du modèle. Les performances sont utilisables pour des travaux batch/asynchrones sur des Mac à faible RAM, mais pas pour un chat en temps réel sur le matériel le plus lent. C’est actuellement spécifique aux Mac/Apple Silicon et au modèle.

La configuration 2GB peut-elle utiliser la fenêtre de contexte complète 256K ?

Le modèle Gemma 4 26B A4B prend en charge une fenêtre de contexte allant jusqu’à 256K jetons. La configuration TurboFieldfare d’environ 2GB utilise cependant un cache KV 4K.

Ce sont des mesures distinctes :

• Capacité officielle du modèle : jusqu’à 256K jetons.
• Résultat local publié en mémoire : cache KV 4K.
• Contexte local pratique : déterminé par la mémoire disponible, les paramètres du runtime, la longueur de l’invite et la latence acceptable.

La mémoire du cache KV augmente à mesure que l’invite et la réponse générée s’allongent. Étendre la configuration locale vers 32K, 128K ou 256K jetons augmenterait l’utilisation mémoire et pourrait également affecter le temps de préremplissage et la vitesse de génération.

Les équipes évaluant l’analyse de documents longs devraient tester leur contexte cible réel plutôt que de supposer que le résultat 2GB s’applique à la fenêtre de contexte complète du modèle.

Quelle est la vitesse de Gemma 4 26B sur Apple Silicon ?

TurboFieldfare rapporte deux plages de vitesse de décodage de référence :

• 8GB M2 MacBook Air : 5.1–6.3 jetons par seconde.
• 24GB M5 Pro : 31–35 jetons par seconde.

Ces résultats montrent l’influence majeure du matériel sur l’inférence locale. Ils ne doivent pas être traités comme des garanties de performance universelles.

Estimer la sortie mensuelle maximale

Jetons de sortie mensuels maximum = jetons décodés par seconde × 60 × 60 × 24 × 30

En utilisant les vitesses rapportées :

Ce sont des estimations de décodage uniquement. Les applications réelles consacrent aussi du temps à :

• Le préremplissage de l’invite.
• La mise en file d’attente des requêtes.
• Le chargement et les redémarrages du modèle.
• Les réponses échouées ou rejetées.
• L’activité du système d’exploitation.
• Le monitoring et la maintenance.
• Les indisponibilités planifiées et imprévues.

Par exemple, produire quatre millions de jetons de sortie à 5.1 jetons par seconde nécessite environ 9.1 jours de décodage ininterrompu. Produire 20 millions de jetons de sortie nécessiterait environ 45.4 jours, rendant ce volume impossible pour une machine M2 unique sur un mois de 30 jours.

Un modèle de coût local réaliste doit donc tenir compte de la capacité de débit ainsi que du coût matériel fixe.

Existe-t-il une API officielle pour Gemma 4 26B ?

Oui.

Google fournit un accès hébergé à Gemma 4 26B via l’API Gemini. L’ID de modèle officiel est :

gemma-4-26b-a4b-it

Le point de terminaison hébergé prend en charge la génération de texte, la compréhension d’images, les instructions système, le raisonnement configurable, l’appel de fonctions et les conversations multi-tours. C’est la voie la plus rapide pour évaluer le modèle sans télécharger de poids ni exploiter un serveur d’inférence.

Google fournit les derniers exemples d’implémentation dans sa documentation Gemma sur l’API Gemini.

Appeler Gemma 4 26B avec Python

Installez le SDK Gen AI de Google :

pip install -U google-genai

Définissez votre clé API Gemini dans l’environnement, puis envoyez une requête :

from google import genai

client = genai.Client()

response = client.models.generate_content(
    model="gemma-4-26b-a4b-it",
    contents="Explain mixture-of-experts routing in simple terms.",
)

print(response.text)

Cet exemple confirme l’accès basique à l’API. Il ne valide pas les quotas de production, la latence, les performances en long contexte, ni les exigences de gestion des données de votre application.

Combien coûte l’API Gemma 4 26B ?

Google indique actuellement que l’entrée, la sortie et la mise en cache du contexte de Gemma 4 sont gratuites sur le palier gratuit de l’API Gemini. Aucun palier payant Gemma 4 n’est listé pour l’instant.

Avis concernant les données du palier gratuit : Google indique que le contenu soumis via le palier gratuit peut être utilisé pour améliorer ses produits. N’envoyez pas de données confidentielles, réglementées ou appartenant à des clients avant que votre équipe n’ait examiné les conditions d’utilisation et de conservation applicables.

Remarque sur la tarification : l’accès au palier gratuit ne doit pas être considéré comme un engagement de tarification de production permanent. La disponibilité, les quotas, les conditions de données et les options de paliers payants peuvent évoluer.

Consultez la page de tarification officielle de l’API Gemini avant de prendre une décision de production.

La tarification actuelle crée une comparaison inhabituelle :

• L’API officielle peut ne pas avoir de coût direct par jeton dans les limites de son palier gratuit.
• L’inférence locale n’a pas de facture par jeton de fournisseur, mais consomme du matériel, de l’électricité, du stockage, de la maintenance et du temps d’ingénierie.
• Des fournisseurs hébergés tiers peuvent proposer une capacité, une tarification, des politiques de rétention et des conditions commerciales différentes.

Pour Gemma 4 26B lui-même, utilisez la documentation officielle Gemma sur l’API Gemini et vérifiez les limites actuelles sur la page de tarification de l’API Gemini.

CometAPI ne liste pas actuellement Gemma 4 26B comme un modèle disponible. Les équipes souhaitant aussi évaluer des alternatives Gemini hébergées peuvent consulter les modèles actuellement listés tels que Gemini 3.6 Flash, Gemini 3 Flash, et d’autres options dans le catalogue des modèles Google sur CometAPI.

Gemma 4 local est-il moins cher que l’API ?

Avec la tarification actuelle, l’API Gemini officielle peut être moins chère en termes financiers directs car Gemma 4 est disponible gratuitement dans le palier gratuit.

Cependant, la tarification par jeton n’est qu’une partie de la décision.

Exemple de coût matériel local

Supposons qu’une équipe achète une machine Apple Silicon à 1 200 $ et l’amortisse sur 24 mois.

Amortissement matériel mensuel 1 200 $ ÷ 24 mois = 50 $ par mois

Si la machine génère effectivement quatre millions de jetons de sortie par mois :

Amortissement matériel par 1M de jetons de sortie 50 $ ÷ 4 = 12,50 $ par 1M de jetons de sortie

L’arithmétique est correcte, mais ce n’est pas une estimation complète du coût total. Elle exclut :

• L’électricité.
• L’usure et le remplacement du SSD.
• La mise en place et le temps d’ingénierie.
• Le monitoring et la maintenance.
• Les générations échouées et les relances.
• La relecture humaine.
• La capacité de secours.
• Les indisponibilités et la bascule.
• Le coût d’opportunité d’utiliser la machine pour l’inférence.

Elle suppose aussi que le matériel peut produire le volume de jetons cible dans la fenêtre d’exploitation disponible.

Comparer le coût par tâche acceptée

Une formule locale plus utile est :

Coût local par tâche acceptée = amortissement matériel

• électricité
• stockage et maintenance
• temps d’ingénierie
• échecs et relances
• relecture humaine ÷ tâches acceptées

Pour un service hébergé payant :

Coût hébergé par tâche acceptée = jetons d’entrée facturés

• jetons de sortie facturés
• frais de cache, d’outils ou de requêtes
• relances
• relecture humaine ÷ tâches acceptées

Le prix par jeton le plus bas n’entraîne pas toujours le coût d’application le plus bas. Une voie avec des réponses plus lentes, une sortie structurée invalide, ou un taux de relance élevé peut coûter plus cher par résultat accepté.

Le serveur local compatible OpenAI peut-il être utilisé en production ?

TurboFieldfare inclut un serveur compatible OpenAI expérimental qui écoute sur :

http://127.0.0.1:8080/v1

Il prend en charge Chat Completions, le streaming, les déclarations de fonctions et la réutilisation de préfixes d’invite. Toutefois, le projet indique que le serveur doit rester sur l’interface loopback car il ne fournit ni authentification distante ni TLS.

Il doit être traité par défaut comme un point de terminaison de développement local.

Un déploiement de production nécessiterait une couche de service supplémentaire avec :

• Authentification et autorisation.
• TLS pour le trafic sortant de l’hôte.
• Limites de taille des requêtes et des sorties.
• Mise en file d’attente et contrôles de concurrence.
• Supervision de processus et redémarrages automatiques.
• Vérifications de disponibilité du modèle.
• Surveillance de la pression mémoire.
• Mesures SSD et de cache d’experts.
• Monitoring de la latence et du débit.
• Journalisation respectueuse de la confidentialité.
• Gestion de la surcharge.
• Une route de secours en cas de défaillance locale.

Le serveur local peut renvoyer des appels d’outils générés par le modèle, mais l’application doit inspecter, autoriser et exécuter chaque action. Le modèle ne doit pas être autorisé à exécuter directement les outils.

Pour Gemma 4 26B, l’API Gemini de Google est la voie hébergée officielle. Si l’application utilise également d’autres modèles hébergés, le démarrage rapide CometAPI montre comment connecter les modèles pris en charge via une interface compatible OpenAI. Cela peut fournir une voie de secours hébergée séparée, mais cela ne doit pas être présenté comme une route CometAPI pour Gemma 4 à moins que le modèle n’apparaisse dans le catalogue en direct.

Décision de déploiement Gemma 4 26B

API (hébergée, API Gemini, autres)

• Tarification autour de 0,07 $ / 1M de jetons d’entrée et 0,30–0,34 $ / 1M de jetons de sortie (varie selon le fournisseur ; certains un peu plus élevés).
• Aucun coût matériel ni de mise en place, vitesse/débit élevés, mise à l’échelle facile, multimodal et fonctionnalités complètes disponibles.

• Coût continu par jeton, les données quittent votre machine, limites de débit/quotas, variance potentielle de latence.

Local standard

• Coût unique matériel + électricité ; confidentialité et capacité hors ligne.
• Nécessite suffisamment de RAM/VRAM (généralement 18–32+ GB utilisables) ou accepte des vitesses lentes/du swapping.

• Contrôle total, pas de frais par jeton après la mise en place, mais vous gérez la quantification, le service, les mises à jour et le matériel.

Local façon TurboFieldfare

• Fait tourner le MoE 26B à pleine capacité sur des machines qui ne le pourraient pas autrement (même des Mac 8 GB).
• Confidentialité/hors ligne + coût marginal quasi nul, mais plus lent qu’un GPU bien doté ou une bonne API, Mac uniquement aujourd’hui, axé texte dans l’implémentation actuelle, et nécessite le runtime spécialisé.

Utilisez une approche hybride lorsque :

• Les charges privées doivent rester locales.
• Le trafic public ou en rafale exige une capacité hébergée.
• L’application a besoin d’une bascule.
• Différentes tâches bénéficient de différents modèles.
• Vous souhaitez comparer les voies via une API cohérente.

Un chemin de décision simple est :

Must the workload remain offline or on-device?
├── Yes → Test the local Apple Silicon runtime
└── No
    ├── Need image input or fast setup? → Start with the Gemini API
    ├── Need paid capacity or an SLA? → Evaluate hosted providers
    └── Need privacy plus burst capacity? → Use a hybrid route

API officielle vs Local vs Hébergement tiers

Avant de sélectionner une voie tierce, vérifiez que le modèle exact est actuellement disponible plutôt que de supposer sa prise en charge. Gemma 4 26B doit être accessible via l’API Gemini officielle de Google, sauf si un autre fournisseur liste explicitement le même ID de modèle. Pour d’autres modèles Gemini hébergés, le catalogue des modèles Google sur CometAPI montre les options actuellement prises en charge, tandis que la documentation CometAPI explique comment appeler ces modèles via un point de terminaison compatible OpenAI.

Un déploiement hybride peut être le design le plus pratique à long terme : inférence locale pour les tâches texte privées ou hors ligne, point de terminaison officiel pour une évaluation multimodale rapide, et voie hébergée pour la capacité de production ou la bascule.

Comment évaluer l’API Gemma 4 26B vs le local

Faites tourner la même charge de travail via chaque voie de déploiement.

Un ensemble d’évaluation pratique pourrait inclure :

1. Dix tâches de code, d’extraction ou de transformation.
2. Cinq tâches de raisonnement à réponses objectives.
3. Cinq tâches long-contexte à différentes longueurs.
4. Cinq tâches de compréhension d’image pour les voies qui supportent les images.
5. Cinq tâches d’appel de fonctions avec autorisation côté client.
6. Cinq tâches de sortie structurée avec validation JSON stricte.

Relevez :

• Le temps jusqu’au premier jeton.
• Le temps total de complétion.
• Le temps de préremplissage de l’invite.
• Les jetons décodés par seconde.
• Le pic de mémoire locale.
• Les octets lus sur le SSD.
• Le temps de mise en file.
• Le comportement en concurrence.
• La longueur de contexte.
• La validité de la sortie structurée.
• La validité des appels d’outils.
• Le taux de tâches acceptées.
• Le temps de correction humaine.
• Le taux d’échec et de relance.
• Le coût d’exploitation local.
• Les frais de jetons et de requêtes hébergés.

Utilisez les mêmes gabarits d’invite, limites de sortie, températures et règles d’acceptation.

Ne comparez pas une courte requête texte locale avec une longue requête multimodale hébergée en présentant le résultat comme un benchmark direct du modèle.

FAQ

Existe-t-il une API officielle pour Gemma 4 26B ?

Oui. Google propose Gemma 4 26B via l’API Gemini avec l’ID de modèle gemma-4-26b-a4b-it. Elle prend en charge la génération de texte, l’entrée image, les instructions système, le raisonnement configurable, l’appel de fonctions et les conversations multi-tours.

L’API Gemma 4 26B est-elle gratuite ?

Google indique actuellement que l’entrée, la sortie et la mise en cache du contexte de Gemma 4 sont gratuites sur le palier gratuit de l’API Gemini. Aucun palier payant n’est actuellement listé pour Gemma 4. Le contenu du palier gratuit peut être utilisé pour améliorer les produits Google ; examinez donc les conditions applicables avant d’envoyer des informations sensibles.

Gemma 4 26B peut-il vraiment tourner avec 2GB de RAM ?

TurboFieldfare rapporte environ 2GB pour les poids et un cache KV 4K. La configuration complète requiert toujours un Mac Apple Silicon 8GB, environ 14.3GB de stockage, et un streaming d’experts appuyé sur SSD.

La configuration 2GB prend-elle en charge le contexte 256K ?

Le modèle prend en charge jusqu’à 256K jetons, mais le résultat local 2GB publié utilise un cache KV 4K. Des contextes locaux plus longs nécessitent plus de mémoire et des tests de performance.

Gemma 4 local est-il moins cher qu’une API hébergée ?

Il peut l’être pour des charges texte soutenues sur du matériel que vous possédez déjà, mais le résultat dépend du débit, de l’utilisation, de l’électricité, de la maintenance, des relances et de la qualité de la sortie. Étant donné que l’API officielle est actuellement gratuite dans les limites de son palier gratuit, le déploiement local n’est pas automatiquement l’option la moins chère.

Recommandation finale

La configuration d’environ 2GB de TurboFieldfare est une technique de déploiement spécialisée pour Apple Silicon, pas une exigence mémoire universelle de Gemma 4 26B. Elle fonctionne en limitant le cache KV et en diffusant les experts routés depuis le SSD au lieu de conserver en mémoire le modèle quantifié complet.

Pour la plupart des utilisateurs, les choix pratiques restent :

1. Utiliser l’API pour la commodité et la vitesse si les coûts et la confidentialité le permettent.
2. Exécuter des versions locales quantifiées standard si vous disposez de 24 GB+ de mémoire.
3. Utiliser TurboFieldfare (ou de futurs moteurs similaires) si vous voulez spécifiquement la qualité du MoE 26B sur un matériel Apple Silicon contraint.

Pour des charges de production, comparez les deux voies avec les mêmes invites, longueurs de contexte, limites de sortie et contrôles d’acceptation. La décision finale doit se baser sur la qualité, la latence, la confidentialité, le débit atteignable et le coût total par tâche acceptée — pas seulement sur l’accroche des 2GB.