Format GGUF : guide complet pour l’inférence LLM en local

Qu’est-ce que GGUF ?

GGUF, pour GGML Unified Format, est un format de fichier binaire qui regroupe les poids du modèle, les données du tokenizer, les métadonnées d’architecture et les informations de quantification dans un fichier portable unique pour l’inférence avec des runtimes basés sur GGML, en particulier llama.cpp.

GGUF résout un problème de déploiement des LLM. De nombreux formats exigent de conserver plusieurs fichiers ensemble : poids du modèle, fichiers de tokenizer, fichiers de configuration et code de chargement spécifique à l’architecture. GGUF simplifie tout cela en rendant le fichier du modèle largement auto-descriptif.

Un fichier GGUF contient généralement :

• Tenseurs du modèle
• Poids quantifiés ou non quantifiés
• Vocabulaire du tokenizer
• Configuration du tokenizer
• Métadonnées de l’architecture du modèle
• Paramètres de longueur de contexte
• Dimensions des embeddings
• Nombre de têtes d’attention
• Configuration RoPE
• Noms, formes et types de données des tenseurs

L’idée clé : le fichier se décrit lui-même. Le runtime peut inspecter les métadonnées, comprendre l’architecture, charger le tokenizer et mapper les tenseurs sans dépendre d’un config.json séparé ni d’un dossier de tokenizer.

Cela ne signifie pas que chaque fichier GGUF est universellement compatible avec tous les runtimes pour toujours. Le runtime doit tout de même prendre en charge l’architecture du modèle et les types de tenseurs utilisés. Toutefois, GGUF facilite grandement cette compatibilité par rapport aux anciens formats, car le fichier transporte beaucoup plus d’informations structurées.

Quatre caractéristiques définissent GGUF :

1. Déploiement en fichier unique
2. Prise en charge du memory mapping pour un chargement efficace
3. Métadonnées extensibles typées en paires clé-valeur
4. Prise en charge de nombreux types de quantification, des formats agressifs en très peu de bits jusqu’à la pleine précision

GGUF a été introduit en 2023 au sein de l’écosystème llama.cpp et GGML. C’est désormais le format dominant pour distribuer des LLM locaux quantifiés sur Hugging Face.

GGUF vs GGML

Le format GGML (Georgi Gerganov Machine Learning) a précédé GGUF. Il a joué un rôle clé en rendant possibles les premières inférences locales. Mais il montrait ses limites pratiques à mesure que l’écosystème s’étendait au-delà des modèles LLaMA d’origine.

Parmi les difficultés fréquentes de GGML :

• Gestion des métadonnées moins flexible
• Hypothèses de chargement plus spécifiques à l’architecture
• Gestion du tokenizer et de la configuration moins autonome
• Extensibilité difficile avec l’apparition de nouvelles familles de modèles

GGUF a corrigé ces limites grâce à un format plus structuré. Il a introduit des métadonnées typées, de meilleurs embeddings pour le tokenizer et une structure de fichier plus claire. Résultat : llama.cpp et outils associés prennent plus facilement en charge de nouvelles architectures sans réinventer sans cesse la chaîne de chargement.

Pour l’utilisateur, l’essentiel est simple : GGUF est le format moderne. Si vous téléchargez des modèles aujourd’hui, choisissez presque toujours GGUF plutôt que les anciens fichiers GGML.

GGUF vs GPTQ et AWQ

En explorant les formats de fichiers, vous avez sans doute croisé GGUF, GPTQ (Generative Post-Training Quantization) et AWQ (Activation-Aware Weight Quantization). On les compare souvent car tous visent à rendre l’inférence LLM plus efficace. Mais ils ne relèvent pas de la même catégorie.

GGUF est avant tout un format de fichier et un conteneur de déploiement. Il prend en charge de nombreux types de quantification et est étroitement associé à l’inférence locale façon llama.cpp.

GPTQ et AWQ sont des méthodes de quantification et des écosystèmes couramment utilisés pour une inférence optimisée GPU, en particulier sur du matériel NVIDIA via des frameworks comme Transformers, ExLlama, AutoGPTQ et des workflows compatibles vLLM.

Si votre objectif est une compatibilité maximale entre ordinateurs portables, PC de bureau, Apple Silicon et environnements mixtes, GGUF est généralement le choix le plus sûr.

Si votre objectif est le débit maximal sur des serveurs d’inférence NVIDIA dédiés, GPTQ, AWQ, FP8 ou d’autres formats optimisés GPU peuvent être plus adaptés.

Pourquoi utiliser GGUF ?

GGUF a gagné en popularité parce qu’il résout des problèmes de déploiement concrets. Je le trouve aussi très pratique pour déployer en local sans s’encombrer d’une configuration complexe.

Exécuter des LLM en local impliquait autrefois des outils épars, des poids volumineux non compressés, des formats de modèles incompatibles et des étapes d’installation compliquées. GGUF permet maintenant de standardiser une grande partie de ce flux.

Plutôt que de gérer une myriade de fichiers et de scripts de chargement, vous pouvez vous concentrer sur le choix du bon modèle, du niveau de quantification, puis lancer l’inférence.

Exécuter des modèles en local

GGUF vous permet d’exécuter des LLM sur votre propre machine. Cela signifie :

• Pas de coût à l’usage par token
• Aucune dépendance à un fournisseur d’inférence hébergée
• Pas besoin d’envoyer vos prompts à une API tierce
• Inférence hors ligne possible une fois le modèle téléchargé

C’est particulièrement utile pour les workflows sensibles à la confidentialité. Les développeurs peuvent refuser d’envoyer du code propriétaire, des documents internes, des données clients ou des prompts confidentiels à une API externe.

L’inférence locale n’est pas automatiquement sécurisée. Vous devez toujours gérer correctement votre machine, vos journaux, vos applications et les contrôles d’accès. Mais GGUF rend un déploiement local privé bien plus accessible.

Pour pratiquer l’exécution locale, consultez nos tutoriels sur le serving de Mistral Medium 3.5 avec SGLang, l’exécution de DeepSeek V4 Flash en local, l’exécution du modèle efficace Bonsai 1‑bit sur un vieil ordinateur et l’exécution de MiniMax M2 en local comme assistant de code.

Flexibilité matérielle

GGUF est utile car il fonctionne sur de nombreuses configurations matérielles.

Selon le runtime et le backend, les modèles GGUF peuvent tourner sur :

• Machines uniquement CPU
• GPU NVIDIA via CUDA
• Apple Silicon via Metal
• GPU AMD via HIP ou Vulkan
• GPU Intel via SYCL ou Vulkan
• Certains environnements ARM et mobiles

Cette flexibilité a beaucoup contribué à l’influence de llama.cpp. Il n’a pas été pensé uniquement pour des GPU serveurs haut de gamme, mais pour rendre l’inférence locale possible sur un large éventail de matériels.

Par exemple, un utilisateur Mac peut s’appuyer sur l’accélération Metal, tandis qu’un utilisateur Linux sur PC exploitera CUDA ou Vulkan. Un utilisateur uniquement CPU peut toujours exécuter des modèles plus petits quantifiés, au prix d’une génération plus lente.

Large prise en charge dans l’écosystème

De nombreux outils d’inférence locale prennent en charge GGUF. Par exemple :

• llama.cpp pour l’inférence en ligne de commande ou en mode serveur
• Ollama pour une gestion des modèles orientée CLI et un accès API
• LM Studio pour une interface de bureau
• GPT4All pour une discussion locale axée confidentialité
• KoboldCpp pour le roleplay local et la génération de texte
• Jan et Open WebUI pour des interfaces IA locales

C’est important, car vous n’êtes pas enfermé dans une seule interface. Le même format de modèle peut servir à différents workflows.

Un développeur peut benchmarker un modèle avec llama.cpp, discuter avec lui dans LM Studio, le servir via Ollama et le connecter à une interface web via Open WebUI.

Distribution sur Hugging Face

Hugging Face est devenu un hub majeur de distribution de modèles GGUF.

Source : Hugging Face

Beaucoup de modèles à poids ouverts populaires reçoivent rapidement des variantes GGUF uploadées par la communauté après leur sortie. Ces dépôts incluent souvent plusieurs options de quantification pour s’adapter à votre matériel.

Parmi les variantes courantes :

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0
• IQ4_XS
• IQ3_M
• IQ2_XXS

Cela signifie que la conversion manuelle est souvent inutile. Pour les modèles les plus populaires, quelqu’un a déjà créé des fichiers GGUF pour les niveaux de quantification usuels.

Contrôle précis du compromis taille/qualité

GGUF vous laisse ajuster finement le compromis taille/qualité. Vous pouvez choisir :

• Des quantifications plus petites pour des machines avec peu de mémoire
• Des quantifications intermédiaires pour un usage quotidien équilibré
• Des quantifications en plus de bits pour le code, le raisonnement ou les sorties structurées
• La pleine ou quasi-pleine précision quand la mémoire n’est pas un problème

Cette flexibilité est l’un des grands atouts du format. Plutôt qu’une cible de déploiement unique, GGUF permet d’adapter une même famille de modèles à de nombreux paliers matériels.

Comment fonctionne GGUF ?

Un fichier GGUF est organisé en trois grandes parties :

1. En‑tête
2. Métadonnées et informations sur les tenseurs
3. Données des tenseurs

La structure exacte est définie par la spécification GGUF. L’essentiel : les métadonnées et les informations sur les tenseurs apparaissent avant les données brutes des tenseurs, ce qui permet au runtime de comprendre ce qu’il va charger.

L’en‑tête

L’en‑tête identifie le fichier comme GGUF et indique au runtime comment parser le reste du fichier. Il inclut :

• Nombre magique pour GGUF
• Version du format
• Nombre de tenseurs
• Nombre de paires clé‑valeur de métadonnées

Les fichiers GGUF modernes utilisent généralement la version 3.

Les moteurs d’inférence vérifient d’abord le nombre magique. Si le fichier ne commence pas par l’identifiant GGUF attendu, le runtime peut le rejeter avant d’essayer de parser les tenseurs ou d’allouer de la mémoire.

C’est une étape simple mais essentielle pour la sûreté et la fiabilité. Elle évite qu’un runtime ne traite par erreur un binaire quelconque comme un modèle.

Paires clé‑valeur de métadonnées

Les métadonnées GGUF sont un magasin typé clé‑valeur. Elles peuvent décrire :

• Informations générales sur le modèle
• Famille d’architecture
• Longueur de contexte
• Taille des embeddings
• Nombre de couches
• Nombre de têtes d’attention
• Paramètres RoPE
• Vocabulaire du tokenizer
• Tokens spéciaux
• Informations de quantification

Les clés sont généralement « namespacées ». Exemples :

• general.architecture
• general.alignment
• llama.context_length
• tokenizer.ggml.tokens

Le namespace est important car il permet à GGUF de prendre en charge de nombreuses architectures sans changer tout le format. Un modèle de la famille LLaMA peut utiliser des clés llama.*, tandis que d’autres familles utilisent leurs propres métadonnées spécifiques.

C’est l’une des raisons pour lesquelles GGUF s’est bien adapté à des modèles au‑delà de LLaMA, comme Qwen, Mistral, Gemma, DeepSeek, Phi, et d’autres.

Informations de tenseurs et données des tenseurs

Après les métadonnées, le fichier stocke les informations de tenseurs puis les données des tenseurs.

Les informations décrivent :

• Nom du tenseur
• Forme
• Type de données
• Décalage dans la section des données de tenseurs

La section « données des tenseurs » contient les poids réels du modèle. Ces poids peuvent être stockés en pleine précision ou dans l’un des types de tenseurs quantifiés pris en charge par GGUF.

GGUF utilise une valeur d’alignement définie dans les métadonnées, souvent general.alignment. Beaucoup de fichiers GGUF utilisent un alignement de 32 octets, mais l’idée correcte est que l’alignement est contrôlé par métadonnées plutôt que figé en dur.

L’alignement compte car il permet aux runtimes d’accéder efficacement aux blocs de tenseurs.

Memory mapping

L’un des avantages pratiques de GGUF est le memory mapping, souvent appelé mmap.

Avec le memory mapping, le système d’exploitation peut mapper le fichier du modèle en mémoire virtuelle au lieu de forcer le runtime à copier tout le fichier en RAM dès le départ.

Cela peut accélérer nettement le démarrage du modèle, surtout sur SSD. Le système peut aussi paginer les données du modèle à la demande.

Cependant, le memory mapping n’est pas magique. Le modèle a toujours besoin d’une bande passante mémoire suffisante et de RAM/VRAM disponible pour bien tourner. Si votre système pagine sans cesse depuis le disque, l’inférence peut devenir lente.

Une bonne façon de penser à mmap :

• Améliore l’efficacité de chargement
• Réduit les copies inutiles
• Laisse l’OS gérer la pagination
• N’élimine pas les besoins mémoire de l’inférence

Comprendre les types de quantification GGUF

La quantification compresse les poids du modèle en représentations de plus faible précision.

Au lieu de stocker chaque poids en virgule flottante 16 bits, un modèle quantifié stocke des valeurs approchées avec moins de bits. Cela réduit la taille disque, l’usage RAM/VRAM et la pression sur la bande passante mémoire.

L’idée clé : beaucoup de poids de réseaux de neurones n’ont pas besoin d’une pleine précision en virgule flottante à l’inférence. Un modèle bien quantifié peut préserver l’essentiel du comportement tout en étant bien plus compact.

Nomination des quantifications GGUF

Les noms de quantification GGUF suivent généralement ce schéma :

• Q signifie quantifié
• Le nombre indique les bits approximatifs par poids
• K renvoie à la famille k‑quant
• S, M et L désignent souvent les variantes small, medium, large

Exemples :

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0

Le nom sert de guide, mais n’exprime pas toujours exactement la taille finale. Elle dépend du mix de tenseurs, de l’architecture, des métadonnées, de la taille du tokenizer et d’éventuels tenseurs conservés en plus haute précision.

Types de quantification GGUF courants

Ces valeurs sont des ordres de grandeur pour des modèles denses de classe 7B. Les architectures récentes, les modèles mixture‑of‑experts, des tokenizers plus grands et des dispositions de tenseurs différentes peuvent modifier la taille réelle.

En pratique, Q4_K_M s’est imposé comme défaut populaire car il offre un excellent équilibre entre taille et qualité. Beaucoup le jugent suffisant pour le chat généraliste, le résumé, la réécriture et l’exploration d’IA locale.

Q5_K_M et Q6_K sont souvent préférables pour des charges plus exigeantes, comme le code ou le suivi d’instructions en plusieurs étapes.

La raison est simple : ces tâches sont plus sensibles aux dégradations, même faibles.

K‑quants vs I‑quants

Les K‑quants sont la famille la plus répandue derrière des formats comme Q4_K_M, Q5_K_M et Q6_K.

Ils utilisent des schémas de quantification groupée avec des informations d’échelle qui aident à préserver le comportement du modèle tout en réduisant les besoins mémoire. Ils sont populaires car fiables, largement pris en charge et faciles à trouver dans les releases GGUF communautaires.

Les I‑quants, souvent notés IQ, sont des types plus récents tels que :

• IQ4_XS
• IQ3_M
• IQ2_XXS
• IQ1_S

Les I‑quants visent une meilleure qualité à très petite taille. Ils peuvent utiliser des techniques comme la quantification sensible à l’importance et des codebooks de quantification non linéaires. Certains workflows emploient une matrice d’importance (imatrix) pour préserver davantage les poids critiques lors de la quantification.

Le compromis, c’est la complexité. Les I‑quants peuvent offrir d’excellents résultats taille/qualité, surtout à très bas débits, mais ils requièrent parfois des workflows de quantification plus soignés et une prise en charge runtime adaptée.

Pour la plupart des débutants, les K‑quants restent le point de départ le plus simple.

Choisir un niveau de quantification pour votre matériel

Le tableau suivant propose des points de départ pratiques. Considérez‑les comme des repères et non des garanties. La longueur de contexte, la charge du système, l’offload GPU, la taille du cache KV et l’architecture exacte du modèle peuvent modifier les besoins mémoire.

Règles générales :

• Utilisez Q4_K_M comme défaut sûr pour la plupart des inférences locales.
• Optez pour Q5_K_M quand la qualité prime plus que chaque gigaoctet économisé.
• Choisissez Q6_K ou Q8_0 si la mémoire le permet et que vous visez une meilleure fidélité.
• Évitez Q2_K pour du travail sérieux, sauf scénarios très contraints en mémoire.
• Réservez de la mémoire pour le cache KV, surtout avec de longues fenêtres de contexte.

Le cache KV est facile à négliger. Un modèle peut tenir en RAM avec un court contexte mais échouer ou ralentir fortement avec un contexte long, car le cache croît avec la longueur de séquence.

L’écosystème GGUF

L’adoption de GGUF tient autant aux outils qu’au format lui‑même.

Un format ne devient utile que si l’on peut facilement télécharger, exécuter, inspecter, convertir et servir des modèles. GGUF profite d’un écosystème solide : outils en ligne de commande, applications de bureau, APIs, dépôts hébergés.

1. llama.cpp

llama.cpp est le runtime GGUF originel et le plus important. C’est un moteur d’inférence C/C++ léger créé par Georgi Gerganov et maintenu par la communauté GGML. Son objectif : rendre l’inférence LLM efficace avec un minimum de configuration sur de nombreuses plateformes matérielles.

La version moderne de llama.cpp prend en charge de nombreux backends, notamment :

• CPU
• CUDA pour GPU NVIDIA
• Metal pour appareils Apple
• Vulkan
• HIP pour GPU AMD via ROCm
• SYCL pour GPU Intel
• OpenCL dans certains environnements
• Autres backends spécialisés comme CANN, OpenVINO, WebGPU selon la plateforme

Il inclut aussi des outils de conversion, quantification, serving, benchmarking et inférence en ligne de commande. Outils courants :

• convert_hf_to_gguf.py
• llama-quantize
• llama-cli
• llama-server
• llama-bench

Commandes pour créer un build CMake CPU basique :

cmake -B build
cmake --build build --config Release

Selon la configuration, il faut parfois ajouter des flags à la première commande :

• Désactiver Apple Metal sur macOS (activé par défaut) : -DGGML_METAL=OFF
• Build Vulkan : -DGGML_VULKAN=1
• Build CUDA pour GPU NVIDIA : -DGGML_CUDA=ON

Notez que les builds actuels utilisent des options CMake GGML_* comme GGML_CUDA, GGML_VULKAN et GGML_HIP.

2. Ollama

Ollama est l’une des façons les plus simples d’exécuter des modèles en local. Il offre :

• Une CLI simple
• Le pull et la gestion de modèles
• Une API REST locale
• Des bibliothèques officielles Python et JavaScript
• Des intégrations avec de nombreuses interfaces IA locales

Ollama stocke et gère les modèles pour vous, si bien que l’utilisateur ne manipule généralement pas directement les fichiers .gguf. Cependant, Ollama repose sur une inférence locale compatible llama.cpp et peut aussi importer des fichiers GGUF via un Modelfile.

Ollama expose une API locale à :

http://localhost:11434/api

Deux endpoints souvent utilisés :

• /api/generate pour la complétion de prompt
• /api/chat pour des messages de type chat

Pour débuter, Ollama est souvent le chemin le plus rapide vers l’inférence locale.

3. LM Studio

Source : LM Studio

LM Studio est une application de bureau pour découvrir, télécharger et discuter avec des modèles locaux. Idéal pour celles et ceux qui préfèrent une interface graphique aux outils en ligne de commande.

4. GPT4All

Source : GPT4All

GPT4All est une autre application IA multiplateforme centrée sur des chats privés et locaux. Elle prend en charge GGUF et propose un environnement accessible pour débuter en inférence locale.

Ces outils rendent GGUF accessible aux non‑spécialistes. Pas besoin de maîtriser CMake, la disposition des tenseurs ou les arcanes de la quantification pour essayer un modèle en local.

Bien démarrer avec les modèles GGUF

Deux approches pratiques :

1. Utiliser Ollama pour l’expérience la plus simple.
2. Utiliser directement llama.cpp pour plus de contrôle.

Exécuter un modèle avec Ollama

Le workflow le plus simple : télécharger le modèle et démarrer une session de chat interactive :

ollama pull llama3.3
ollama run llama3.3

Pour appeler le modèle depuis Python via l’API REST :

import requests

payload = {
    "model": "llama3.3",
    "prompt": "Give me three practical use cases for GGUF.",
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/generate",
    json=payload
)

print(response.json()["response"])

Pour des applications de type chat, utilisez /api/chat :

import requests

payload = {
    "model": "llama3.3",
    "messages": [
        {"role": "user", "content": "What is GGUF used for?"}
    ],
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/chat",
    json=payload
)

print(response.json()["message"]["content"])

Le champ stream: false est important pour des scripts simples. Sans lui, Ollama renvoie un flux d’objets JSON plutôt qu’une réponse JSON finale unique.

Vous pouvez aussi utiliser la bibliothèque Python officielle d’Ollama :

from ollama import chat

response = chat(
    model="llama3.3",
    messages=[
        {"role": "user", "content": "Explain GGUF quantization simply."}
    ]
)

print(response.message.content)

Exécuter un fichier GGUF avec llama.cpp

Si vous avez déjà un fichier .gguf, vous pouvez l’exécuter directement avec llama.cpp après compilation du projet.

Exemple :

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Explain the difference between GGUF and GPTQ." \
  -n 256

Si le support GPU est activé, vous pouvez offloader des couches sur le GPU :

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Summarize GGUF in five bullet points." \
  -n 256 \
  -ngl 99

L’option -ngl contrôle le nombre de couches offloadées sur le GPU. Une valeur élevée comme 99 sert souvent à offloader un maximum, si le modèle tient en VRAM.

Pour exposer une API, utilisez llama-server :

./build/bin/llama-server \
  -m models/model.Q4_K_M.gguf \
  -ngl 99 \
  --host 127.0.0.1 \
  --port 8080

Vous disposez ainsi d’une interface serveur locale pour intégrer llama.cpp à vos applications.

Convertir un modèle Hugging Face en GGUF

La plupart des utilisateurs n’ont pas besoin de convertir manuellement des modèles car des releases GGUF communautaires sont largement disponibles.

Cependant, la conversion manuelle est utile quand :

• Vous avez affiné votre propre modèle
• Aucune version GGUF n’existe encore
• Vous souhaitez contrôler vous‑même la quantification
• Vous avez besoin d’un type de quantification spécifique

Workflow type :

1. Télécharger un modèle Hugging Face.
2. Le convertir en GGUF.
3. Quantifier le fichier GGUF.

Exemple :

huggingface-cli download mistralai/Mistral-7B-Instruct-v0.3 \
  --local-dir mistral-7b

Puis conversion en GGUF :

python convert_hf_to_gguf.py mistral-7b \
  --outfile mistral-f16.gguf \
  --outtype f16

Ensuite, quantification :

./build/bin/llama-quantize \
  mistral-f16.gguf \
  mistral-q4_k_m.gguf \
  Q4_K_M

Dans les workflows llama.cpp actuels, convert_hf_to_gguf.py et llama-quantize sont les outils pertinents. D’anciens tutoriels peuvent mentionner des scripts ou binaires obsolètes.

Avantages et limites du format GGUF

GGUF est optimisé pour l’inférence locale pratique. Ce n’est pas un remplaçant universel pour tous les formats ni toutes les piles de serving.

Pour la CPU‑first, Apple Silicon, le matériel hétérogène et l’inférence axée confidentialité, GGUF est souvent un excellent choix.

Pour un déploiement serveur NVIDIA à très haut débit, d’autres formats et moteurs peuvent être plus rapides selon le modèle, la taille de lot, la méthode de quantification et le framework de serving.

Pour conclure

GGUF rend l’inférence LLM locale praticable en regroupant dans un fichier portable tout ce dont le runtime a besoin (poids, tokenizer, métadonnées, info de quantification). Sa vraie force, c’est l’écosystème : llama.cpp, Ollama, LM Studio et Hugging Face en ont fait le format par défaut pour le déploiement IA local.

Pour la plupart des utilisateurs, la voie est simple : installez Ollama, « pull » un modèle et exécutez‑le. Q4_K_M est un excellent défaut ; passez à Q5_K_M ou Q6_K si vous avez besoin de meilleur raisonnement ou de sorties code et disposez de la mémoire nécessaire.

Si vous souhaitez aller plus loin sur le déploiement de LLM, l’optimisation de modèles et les workflows d’inférence locale, explorez le parcours Associate AI Engineer for Data Scientists ou Associate AI Engineer for Developers.