Des GPU dédiés pour entraîner
et servir vos modèles.
De la Tesla T4 à 8 × A100 NVSwitch, facturés à l'heure dans nos régions GPU européennes. Tout le cycle — tokeniser, fine-tuner, servir, passer à l'échelle — documenté ci-dessous avec des hypothèses de dimensionnement explicites.
Tokenisation : du texte aux entiers
Indexer 2 M documents juridiques pour du RAG. Avant de dimensionner la stack de serving, il faut connaître le budget tokens — taille du vocabulaire, moyenne de tokens par document, coût par million traité.
BPE apprend un vocabulaire V en fusionnant itérativement les paires adjacentes les plus fréquentes dans un corpus d'entraînement.
À l'inférence, un tokenizer greedy découpe l'entrée en les plus longs sous-mots de V et renvoie leurs IDs entiers. |V| est fixé à l'entraînement — 100 256 pour cl100k_base, 32 000 pour Mistral.
Mesures & code de référence
import tiktokenenc = tiktoken.get_encoding("cl100k_base")text = "Le cloud européen, bâti pour la production."ids = enc.encode(text)# [2356, 9624, 95199, 268, 11, 293,# 9011, 10462, 5019, 1208, 5788, 13]print(len(ids), "tokens") # 12 tokensprint(len(text), "characters") # 43 charactersprint(f"{len(ids)/len(text):.2f} tok/char") # 0.28
La boucle d'entraînement
Fine-tuner Mistral 7B sur 12 000 tickets de support annotés pour construire un classifieur d'intention à faible latence par requête. QLoRA garde les poids de base gelés en 4-bit et n'entraîne qu'un adaptateur low-rank — ~42 M params entraînables sur 7,2 Md.
- Forward. Les ids d'entrée traversent le transformer pour produire des logits.
- Loss. Cross-entropy au niveau token, moyennée sur le batch. L = −(1/BT) Σ log pθ(yt | x)
- Backward. Autograd parcourt le graphe pour produire ∂L/∂θ.
- Optimizer. θ ← θ − η · m̂t / (√v̂t + ε) — AdamW.
Run de dimensionnement · Mistral 7B · RTX 4090
for step, batch in enumerate(loader):input_ids = batch["input_ids"].to(device) # [B, T]labels = batch["labels"].to(device) # [B, T]# 1. forwardlogits = model(input_ids).logits # [B, T, |V|]# 2. lossloss = F.cross_entropy(logits.view(-1, logits.size(-1)),labels.view(-1),ignore_index=-100,)# 3. backwardloss.backward()torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0)# 4. optimizer stepoptimizer.step()scheduler.step()optimizer.zero_grad(set_to_none=True)
- model
- Mistral-7B-v0.1
- method
- QLoRA · rank 16 · α=32
- precision
- nf4 (base) + bf16 (adapters)
- optimizer
- AdamW · β=(0.9, 0.95) · wd=0.1
- learning rate
- 2 × 10⁻⁴ · cosine
- batch / seq
- 8 × 512 tokens · grad accum 4
- steps
- 750 optimizer steps · ~3.1 M tokens
- hardware
- GPU-PRO · RTX 4090 24 GB
- throughput
- ~1 350 training tok/s · MFU ~38 %
- total
- 38 min · ~0,95 €
Parallélisme multi-GPU
Pré-entraîner un encodeur multilingue de 2,7 Md de paramètres sur 40 Md de tokens. Sur 1 × A100 80 GB avec MFU soutenu conservateur : ~92 jours. Sur GPU-SUPERCOMPUTE (8 × A100 80 GB, NVSwitch) : ~14 jours. Le speedup est sous-linéaire parce que les gradients circulent entre GPU à chaque step.
Chaque GPU détient une copie complète des poids, calcule un gradient sur son shard de batch, puis un all-reduce moyenne les gradients entre N devices avant l'optimizer step.
tar ≈ 2(N−1)/N · (params · bytes) / bw
Chaque GPU envoie son shard au suivant ; après N−1 tours, tous ont la somme complète.
Comparatif interconnect · speedups de dimensionnement
Inférence : anatomie d'une requête
Assistant interne visant < 100 ms de time-to-first-token, puis un streaming à > 60 tok/s. Mistral 7B-Instruct sur GPU-ENTERPRISE (A100 40 GB) avec vLLM, poids fp16, KV-cache fp8 et continuous batching.
tprefill ≈ (2PT + 4LT²d) / FLOPS
tdec ≈ weight_read(P) + KV_read(L,T,d)
Le prefill est surtout compute-bound, avec un terme attention qui augmente avec la longueur du prompt. Le decode est généralement borné par la bande passante mémoire, car poids et KV-cache sont relus à chaque token.
Prefill vs decode · config vLLM
# vmcloud-inference.yamlmodel: mistralai/Mistral-7B-Instruct-v0.3tensor_parallel_size: 1dtype: float16kv_cache_dtype: fp8_e4m3# schedulingmax_num_seqs: 16max_num_batched_tokens: 8192enable_chunked_prefill: true# memorygpu_memory_utilization: 0.90swap_space: 4 # GiB CPU offload# qualitydisable_log_stats: falseguided_decoding_backend: outlines
Économie du token
Vous produisez environ 100 M tokens sortie / mois sur un modèle interne sensible à la latence. La question n'est pas de savoir si l'auto-hébergement est toujours moins cher — il ne l'est pas — mais si l'utilisation, la résidence des données et le contrôle des poids justifient un GPU dédié.
Calcul horaire : GPU-PRO à 1,50 €/h, 64 tok/s, 65 % d'utilisation donne 10,02 € / 1M. Calcul dédié mensuel : 830,64 € / 108 M tokens de capacité = 7,70 € / 1M.
| SKU | GPU | €/h | tok/s | €/1M out |
|---|---|---|---|---|
| GPU-STARTER | Tesla T4 | 0.85 | 22 | € 16.51 |
| GPU-PRO | RTX 4090 | 1.50 | 64 | € 10.02 |
| GPU-ENTERPRISE | A100 40GB | 4.20 | 96 | € 18.70 |
| GPU-TITAN | A100 80GB | 5.40 | 124 | € 18.61 |
| OpenAI · gpt-5.4-mini | $ 2.25 |
| OpenAI · gpt-5.4 | $ 7.50 |
| Anthropic · Claude Haiku 4.5 | $ 5.00 |
| Anthropic · Claude Sonnet 4.6 | $ 15.00 |
| Mistral · Small 4 | $ 0.60 |
Tarifs publics fournisseurs en USD, hors taxes, remises engagement, remises batch et change.
| volume | GPU-PRO | gpt-5.4-mini | gpt-5.4 | Sonnet 4.6 | lecture |
|---|---|---|---|---|---|
| 10 M tok/mois | €831 | $23 | $75 | $150 | API |
| 50 M tok/mois | €831 | $113 | $375 | $750 | API |
| 100 M tok/mois | €831 | $225 | $750 | $1 500 | API |
| 300 M tok/mois | €831 × 3 | $675 | $2 250 | $4 500 | API |
| 1 GPU · util 65 % | €7.70 / 1M | $2.25 / 1M | $7.50 / 1M | $15.00 / 1M | proche gpt-5.4 |
| 1 GPU · util 85 % | €5.89 / 1M | $2.25 / 1M | $7.50 / 1M | $15.00 / 1M | GPU vs premium |
Conclusion : un GPU-PRO dédié ne bat pas les APIs de petits modèles les moins chères au pur prix/token. Il devient rationnel face aux APIs premium quand le GPU reste occupé, et stratégiquement rationnel quand la résidence UE, la capacité fixe, les poids custom ou l'absence d'entraînement côté fournisseur comptent.
Questions techniques fréquentes
Écrit par les ingénieurs qui opèrent les clusters. Révisé chaque trimestre.
Quand choisir fine-tuning vs prompt engineering ?›
Prompt engineering en premier — toujours. Le fine-tuning devient intéressant pour un format de sortie strict, un domaine très spécifique (médical, juridique), ou une latence faible avec un petit modèle. Sous 10 k exemples, QLoRA sur un 7B suffit presque toujours.
FP8 ou FP16 pour l'inférence ?›
Utilisez les poids FP16/BF16 comme baseline de production. Le FP8 est très utile pour le KV-cache et peut l'être pour les poids sur les stacks compatibles, mais validez la qualité sur votre propre jeu d'évaluation avant production.
Pourquoi TTFT stagne quand la charge monte ?›
Le batch dynamique regroupe les prompts : si votre requête arrive juste après un batch qui vient de partir, elle attend. On limite la queue à 20 ms (configurable). Pour des TTFT stables garantis, utilisez des replicas dédiés.
Les poids vous sont-ils accessibles ?›
Oui. Les fine-tunes peuvent être écrits sur votre volume VM ou votre bucket S3-compatible, puis exportés avec les outils standard. Gardez un snapshot après chaque epoch pour rollback et reproductibilité.
Vous entraînez-vous sur mes données ?›
Non. VMCloud fournit l'infrastructure et n'utilise pas les datasets ou prompts clients pour entraîner ses propres modèles. L'accès humain est limité aux cas support, sécurité ou légaux prévus par les conditions et le DPA publiés.
Prêt à entraîner ?
Huit configurations GPU de la Tesla T4 à 0,85 €/h jusqu'aux 8× A100 80GB avec NVSwitch + InfiniBand. Tarification transparente, poids exportables, données hébergées en Europe.