Ollama et BF16 : fonctionnement réel et limites du support

Le support du format BF16 (bfloat16) est devenu un sujet important pour les utilisateurs d’Ollama qui souhaitent exploiter pleinement la puissance de leurs GPU récents. Sur le papier, Ollama permet de télécharger et d’exécuter des modèles publiés en BF16 au format safetensors ou GGUF. Mais en pratique, la réalité est plus nuancée.

Que se passe lorsque vous utilisez des commandes comme :

ollama run hf.co/unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF:BF16

ou encore :

ollama run hf.co/unsloth/Mistral-Small-3.2-24B-Instruct-2506-GGUF:BF16

Nous verrons pourquoi Ollama ne conserve pas le format BF16 natif, quelles sont les conséquences sur vos performances et la précision IA, et quelles améliorations pourraient être apportées.

---

Télécharger un modèle BF16 avec Ollama

Lors d’un ollama pull ou d’un ollama run pointant vers un fichier BF16, Ollama télécharge bien l’artefact tel qu’il est publié sur Hugging Face. Par exemple, dans le cas de Qwen3-Coder-30B-A3B-Instruct-GGUF:BF16, c’est bien un fichier GGUF encodé en bfloat16 qui est récupéré en local. Idem pour Mistral-Small-3.2-24B-Instruct-2506-GGUF:BF16.

À ce stade, tout semble indiquer que le modèle sera exécuté en BF16, ce qui serait logique pour profiter des optimisations matérielles disponibles sur des cartes comme les RTX 40xx, RTX 50xx ou les Nvidia H100.

---

Conversion automatique en FP16 lors de l’import

La réalité est différente : au moment de l’import, Ollama applique une conversion systématique en FP16. Autrement dit, même si vous spécifiez un modèle BF16, l’exécution s’effectue toujours en FP16.

Cette limitation a été confirmée à plusieurs reprises par l’équipe et la communauté dans des discussions GitHub :

• Importing BF16/FP32 models converts to FP16 (#9944)
• BF16 models run as FP16 without native BF16 support (#4670)
• Bug when importing BF16 GGUF models (#9343)

En clair, Ollama ne propose pas encore d’option permettant de conserver un modèle en BF16 ou FP32 natif.

---

Conséquences de cette conversion

Cette conversion automatique n’est pas anodine et a plusieurs implications directes :

• Perte du vrai support BF16 : les GPU modernes disposent d’unités matérielles optimisées pour le calcul en BF16. En passant en FP16, Ollama prive l’utilisateur de ces optimisations.
• Impact sur les performances et la précision IA : BF16 offre un compromis intéressant entre consommation mémoire et précision numérique. En imposant le FP16, Ollama augmente légèrement l’empreinte mémoire et peut réduire la précision sur certains calculs sensibles (long raisonnement, maths complexes).
• Uniformisation forcée : cette stratégie simplifie sans doute la maintenance du pipeline Ollama, mais elle empêche les utilisateurs avancés de choisir le format le plus adapté à leur matériel et à leurs besoins.

---

Exemples concrets avec Qwen3 et Mistral

Prenons le cas du modèle Qwen3-Coder-30B-A3B-Instruct disponible en GGUF BF16. En lançant :

ollama run hf.co/unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF:BF16

le modèle est bien téléchargé en BF16, mais converti en FP16 dès l’import. Le même processus s’applique avec :

ollama run hf.co/unsloth/Mistral-Small-3.2-24B-Instruct-2506-GGUF:BF16

Dans les deux cas, vous n’exécutez jamais réellement un modèle en BF16 natif, malgré la mention explicite dans la commande.

---

Améliorations possibles

• Une future mise à jour d’Ollama ou de llama.cpp pourrait introduire un flag permettant de conserver un modèle en BF16 ou FP32 natif.
• Il serait utile d’ajouter une option –keep-bf16 ou –keep-fp32 dans la commande ollama create ou ollama run.
• Documentation : la communication officielle autour de cette limitation reste limitée, ce qui entretient une certaine confusion dans la communauté.

---

Le support BF16 en bref

Le support BF16 dans Ollama est partiel et trompeur : les fichiers téléchargés en BF16 sont convertis automatiquement en FP16. Cela impacte directement vos performances et la précision IA, surtout si vous disposez d’un GPU récent capable d’exploiter le BF16 de manière native.

Tant qu’une option de conservation n’est pas intégrée, il faut considérer que tout modèle BF16 tourne en réalité en FP16 dans Ollama.

---

Alternatives pour exécuter réellement des modèles BF16

En attendant qu’Ollama propose un support natif du BF16, certains utilisateurs se tournent vers des solutions alternatives qui permettent de tirer parti de ce format sans conversion forcée en FP16. Voici les principales options :

---

Utiliser directement llama.cpp

Ollama repose sur llama.cpp comme moteur d’inférence, il est possible de contourner Ollama et de lancer les modèles BF16 directement avec llama.cpp.

• llama.cpp supporte partiellement le format BF16, même si la compatibilité dépend du modèle et du GPU.
• Cela permet de préserver les poids tels qu’ils sont distribués, sans conversion intermédiaire.
• Exemple : en utilisant la commande ./llama-cli -m model.gguf –bf16, il est possible de forcer l’exécution en BF16 si le GPU le supporte.

⚠️ la prise en charge complète de BF16 dans llama.cpp évolue rapidement, mais n’est pas encore parfaite pour tous les modèles et toutes les cartes graphiques.

---

Passer par d’autres runtimes compatibles

D’autres runtimes open source offrent un support plus explicite du BF16 :

• vLLM : utilisé dans des environnements serveur, il prend mieux en charge les poids en FP32, FP16 et parfois BF16, avec une gestion plus fine des GPU modernes.
• Transformers + PyTorch : lancer un modèle BF16 avec PyTorch permet d’exploiter directement les accélérations matérielles, en utilisant par exemple torch_dtype=torch.bfloat16.
• Text Generation Inference (TGI) : la solution d’Hugging Face est conçue pour tourner en production et gère plus explicitement le BF16 sur les GPU Nvidia récents.

Ces solutions sont souvent plus complexes à mettre en place qu’Ollama, mais elles permettent de réellement exploiter les capacités BF16 de votre matériel.

---

Attendre l’évolution d’Ollama

La communauté a déjà remonté cette limitation dans plusieurs issues GitHub, notamment :

• Importing BF16/FP32 models converts to FP16 (#9944)
• BF16 models run as FP16 without native BF16 support (#4670)

L’équipe d’Ollama est donc consciente du problème. Une évolution future pourrait introduire un flag comme –keep-bf16 ou –native-dtype, permettant de choisir le format à conserver lors de l’import.

---

Comment exécuter un modèle BF16 aujourd’hui ?

Si vous voulez exécuter réellement un modèle en BF16 aujourd’hui, il faut se tourner vers llama.cpp, vLLM, ou encore PyTorch. Ollama reste pratique pour sa simplicité et son intégration avec des modèles prêts à l’emploi, mais son pipeline actuel force la conversion BF16 → FP16, ce qui limite l’intérêt du format pour vos performances et la précision IA.

---

FAQ sur Ollama et le support BF16

Ollama exécute-t-il vraiment les modèles en BF16 ?

Non. Même si vous lancez un modèle étiqueté BF16, Ollama convertit automatiquement les poids en FP16 lors de l’import. L’inférence se fait donc en FP16. Voir issue #9944

Pourquoi Ollama ne garde-t-il pas le format BF16 natif ?

Le pipeline d’import a été conçu pour uniformiser les poids et simplifier la compatibilité avec le moteur interne. Cela évite d’avoir plusieurs chemins de gestion des types, mais prive l’utilisateur des avantages matériels du BF16.

Quels sont les impacts sur mes performances et la précision IA ?

• Perte des optimisations matérielles du BF16 disponibles sur les RTX 40xx et H100.
• Consommation mémoire légèrement plus élevée qu’en BF16 natif.
• Précision réduite dans certains cas (long raisonnement, calculs sensibles).

Y a-t-il une option pour conserver le BF16 ou FP32 natif dans Ollama ?

Non. Actuellement, aucune commande comme –keep-bf16 n’existe. C’est une fonctionnalité souvent demandée, mais pas encore disponible. Voir issue #4670

Comment exécuter un modèle réellement en BF16 ?

• llama.cpp avec l’option –bf16 (si supportée par le GPU).
• vLLM ou Text Generation Inference (TGI).
• PyTorch en utilisant torch_dtype=torch.bfloat16

Le problème sera-t-il corrigé dans une future version ?

Probablement. La communauté a remonté le besoin à plusieurs reprises, et il est possible qu’une option de conservation native du BF16/FP32 arrive dans une version future d’Ollama.