Accueil / Articles / LLMOps pour les petits modèles de langage : frameworks de déploiement et guides de mise en production

LLMOps pour les petits modèles de langage : frameworks de déploiement et guides de mise en production

Pourquoi les SLM l’emportent en termes de coût et de confidentialité, comment se comparent vLLM, SGLang, TGI, llama.cpp, Ollama, WebLLM, ONNX et TensorRT-LLM, ainsi que comment les quantifier, les évaluer et les intégrer en environnement de production.

4127 mots

LLMOps pratiques pour les modèles de langage compacts : quand l’inférence locale ou sur appareil est supérieure aux API de pointe, quels ensembles de services s’adaptent à quelles limites matérielles, et comment les maintenir en bon état après le premier appel réussi.

Introduction

Entre « affiner le plus grand modèle pour tout » et « exécuter un modèle de quelques centaines de millions de paramètres sur un téléphone », les priorités en environnement de production ont changé. De nombreuses tâches — classification des intentions, routage des outils, extraction structurée, réclassification RAG — n’ont pas besoin de modèles de grande envergure une fois qu’un SLM solide a été quantifié et servi correctement.

Le problème : un SLM sans stratégie de déploiement n’est qu’un fichier de sauvegarde sur disque. Le faire fonctionner en production soulève des questions liées à la mémoire GPU, au regroupement des requêtes, à la fidélité de la quantification, aux mécanismes de rollback et à l’évaluation, des sujets que les guides classiques d’MLOps traitent à peine.

1. Les coûts et les latences augmentent à grande échelle

2. La gravité des données et la protection de la vie privée poussent l’inférence vers le périphérique

Les charges de travail dans les domaines de la santé, des finances et pour les utilisateurs sur appareil ne peuvent souvent pas envoyer du texte brut à une API tierce. Un SLM qui tient dans quelques gigaoctets de RAM peut être exécuté à côté des données — sur des GPU locaux, des ordinateurs portables ou des téléphones — et respecter ainsi les exigences de résidence que le modèle cloud ne peut pas remplir.

3. L’infrastructure de mise à disposition des modèles présente ses propres modes de défaillance

La mise à disposition des modèles échoue différemment des bugs ordinaires des applications : fragmentation de la mémoire GPU due à une allocation naïve du cache KV, manque de ressources chez le planificateur en raison d’un trafic irrégulier, incohérences de quantification qui détériorent silencieusement la qualité, ainsi que des démarrages lents qui dépassent les objectifs de performance après une réduction à zéro.

4. LLMOps est une discipline distincte de MLOps

Les MLOps classiques partent du principe que les modèles ont des formes relativement stables et des performances déterministes. Les LLMOps intègrent des éléments non déterministiques tels que différentes versions de textes, de prompts et d’outils, des mécanismes économiques liés aux tokens, ainsi que des filtres de sécurité. La régression n’est plus seulement synonyme d’une baisse de 2 % de la précision – elle peut aussi résulter d’un manque de conformité au schéma JSON ou d’une chute du nombre de tokens par seconde après une mise à jour du moteur.

Qu’est-ce que les LLMOps et en quoi diffèrent-elles des MLOps ?

Les LLMOps concernent la manière dont les équipes déployent, hébergent, surveillent et améliorent les modèles de langage dans des systèmes en temps réel, avec le même niveau de sérieux opérationnel accordé à tout autre service critique.

Tandis que les MLOps se demandent si la précision a diminué, les LLMOps se posent également les questions suivantes :

L’engine de déploiement utilise-t-il efficacement la mémoire GPU en situation de concurrence ?
L’artefact quantifié reste-t-il suffisamment fiable pour cette tâche ?
Les versions des prompts et des outils sont-elles fixées et permettent-elles un retour en arrière ?

Le trafic peut-il être redirigé entre les modèles sans avoir à réécrire le client ?

Les traces révèlent-elles le coût des tokens et la latence par route ?

Le reste de ce guide répond à ces questions spécifiquement pour les SLM.

Le paysage des frameworks de déploiement SLM

En ce qui concerne la puissance brute des GPU, vLLM est un choix courant pour de hautes fréquences d’opérations, disposant d’une API compatible OpenAI sur des GPU NVIDIA ou AMD. SGLang est une alternative lorsque la réutilisation de préfixes et la génération structurée sont importantes. Hugging Face TGI convient aux équipes déjà standardisées sur le Hub et les charts Helm.

En ce qui concerne les solutions portables, llama.cpp / GGUF fonctionne sur des CPU, Apple Silicon et de nombreuses GPU grand public. Ollama encapsule cet ensemble pour offrir une expérience locale en deux commandes seulement. LM Studio ajoute une interface graphique de bureau pour l’évaluation. MLC-LLM / WebLLM sont conçus pour fonctionner dans les navigateurs et sur les appareils mobiles. ONNX Runtime GenAI cible Windows/NPU ainsi que les normes ONNX professionnelles. TensorRT-LLM + Triton visent à maximiser les performances des systèmes NVIDIA après une compilation préalable.

Chacun de ces outils transforme un point de contrôle en réponses ; ils diffèrent par leurs hypothèses matérielles, le poids des opérations et leur conception en matière de concurrence.

Analyses approfondies des frameworks

vLLM

vLLM a popularisé PagedAttention, gérant le cache KV de manière similaire à la mémoire virtuelle afin que les séquences concurrentes consomment moins de RAM GPU. Le lotage continu permet de maintenir un taux d’utilisation élevé.

# Install vLLM
pip install vllm

# Serve using VLLM
vllm serve Qwen/Qwen2.5–1.5B-Instruct - port 8000 # fully OpenAI-compatible endpoint


# Make Request
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

# Python Script for vllm

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5–1.5B-Instruct",
    messages=[{"role": "user", "content": "Summarize LLMOps in one sentence."}],
)
print(resp.choices[0].message.content)

Idéal pour : des backends à fort débit par seconde et des services RAG nécessitant des points de terminaison compatibles avec OpenAI. Avantages : débit élevé, couverture des modèles, formats de quantification (AWQ/GPTQ/FP8). Inconvénients : axé sur les GPU ; nécessite encore une orchestration pour assurer la haute disponibilité.

SGLang

SGLang s’appuie sur RadixAttention afin de partager des caches de préfixes entre les requêtes similaires — ce qui est utile pour les boucles d’agents avec des prompts système répétés — et intègre un DSL sgl.function pour une génération structurée.

# Installation
pip install "sglang[all]"

# SGLang launch server
python -m sglang.launch_server \
 - model-path Qwen/Qwen2.5–1.5B-Instruct \
 - port 30000


# CURL Request
curl http://localhost:30000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

import sglang as sgl

@sgl.function
def classify(s, ticket):
  s += sgl.user(f"Classify this support ticket as billing/technical/other: {ticket}")
  s += sgl.assistant(sgl.gen("label", max_tokens=8))

sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))
state = classify.run(ticket="My invoice charged me twice this month")
print(state["label"])

Idéal pour : les pipelines d’agents et les sorties JSON restreintes. Avantages : réutilisation des préfixes, sortie structurée. Inconvénients : écosystème plus restreint que vLLM ; uniquement compatible avec les GPU.

Hugging Face Text Generation Inference (TGI)

TGI s’intègre dans l’écosystème Hub grâce à une emballage compatible Docker/Kubernetes.

docker run - gpus all -p 8080:80 \
-v $PWD/data:/data \
ghcr.io/huggingface/text-generation-inference:latest \
 - model-id microsoft/Phi-3.5-mini-instruct \
 - quantize bitsandbytes-nf4

from huggingface_hub import InferenceClient
client = InferenceClient("http://localhost:8080")
print(client.text_generation("Explain quantization in one line.", max_new_tokens=64))

Idéal pour : les équipes axées sur Hub et les architectures réglementées cherchant une solution de déploiement prise en charge. Avantages : intégration avec Hub, options de quantification, support Helm. Inconvénients : certaines charges de travail préfèrent encore vLLM pour une bande passante brute ; surveillez les conditions de licence avec le temps.

llama.cpp / GGUF

Né pour exécuter LLaMA sur le CPU d’un MacBook, llama.cpp constitue la base de la plupart des solutions SLM locales ou en périphérie grâce à la quantification GGUF.

# macOS: brew install llama.cpp   |   or build from source:
# git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp && cmake -B build && cmake --build build

# Pull a quantized SLM straight from Hugging Face and serve an OpenAI-compatible endpoint
llama-server -hf Qwen/Qwen2.5-0.5B-Instruct-GGUF:Q4_K_M \
    --port 8090 -c 4096 -ngl 999   # -ngl offloads layers to GPU if available (Metal/CUDA)

curl http://localhost:8090/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"What is GGUF?"}]}'

Idéal pour : les serveurs basés sur CPU, Apple Silicon, ainsi que les boîtiers Pi ou en périphérie sans CUDA. Avantages : portabilité, échelle de quantification avancée, licence MIT. Inconvénients : la bande passante simultanée est inférieure à celle des solutions natives GPU.

Ollama

Ollama encapsule llama.cpp dans une expérience de développement simple à utiliser, avec une API HTTP locale.

ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b "Write a haiku about model quantization"

import requests
r = requests.post("http://localhost:11434/api/chat", json={
  "model": "qwen2.5:1.5b",
  "messages": [{"role": "user", "content": "Give me 3 LLMOps metrics to track"}],
  "stream": False,
})
print(r.json()["message"]["content"])

Idéal pour : le développement local, les prototypes, l’hébergement autonome en petite équipe. Avantages : expérience utilisateur optimisée et paramètres prédéfinis. Inconvénients : il n’est pas conçu pour un déploiement en production nécessitant une forte concurrence.

LM Studio

Une interface graphique desktop basée sur des moteurs locaux similaires, permettant de parcourir, télécharger et discuter — ainsi qu’un serveur compatible OpenAI en un clic pour les démonstrations. Parfait pour évaluer avant d’écrire des fichiers de déploiement ; ce n’est pas un composant d’infrastructure à déployer en masse.

MLC-LLM / WebLLM

Bâti sur Apache TVM, MLC compile des modèles pour de nombreux systèmes d’exploitation ; WebLLM s’exécute entièrement dans le navigateur.

pip install mlc-llm

mlc_llm chat HF://mlc-ai/Qwen2.5-1.5B-Instruct-q4f16_1-MLC

// WebLLM: fully in-browser inference, no backend server
import * as webllm from "@mlc-ai/web-llm";

const engine = await webllm.CreateMLCEngine("Qwen2.5-1.5B-Instruct-q4f16_1-MLC");
const reply = await engine.chat.completions.create({
  messages: [{ role: "user", content: "Explain WebGPU inference simply." }],
});
console.log(reply.choices[0].message.content);

Idéal pour : les applications mobiles, l’inférence côté client respectueuse de la vie privée, les fonctionnalités hors ligne. Avantages : compilation pour plusieurs cibles ; pas de serveur requis pour WebLLM. Inconvénients : complexité de compilation ; limitations liées aux appareils dans les navigateurs.

ONNX Runtime GenAI

L’API GenAI de Microsoft étend ONNX Runtime pour une génération autoregressive avec gestion d’un cache KV via Windows DirectML et les NPUs.

pip install onnxruntime-genai

python -c "
import onnxruntime_genai as og
model = og.Model('phi-3.5-mini-onnx-directml')
tokenizer = og.Tokenizer(model)
tokens = tokenizer.encode('Explain ONNX Runtime GenAI briefly.')
params = og.GeneratorParams(model)
params.set_search_options(max_length=200)
generator = og.Generator(model, params)
generator.append_tokens(tokens)
while not generator.is_done():
    generator.generate_next_token()
print(tokenizer.decode(generator.get_sequence(0)))
"

Idéal pour : les applications natives de Windows et les entreprises utilisant le standard ONNX. Avantages : portabilité après exportation. Inconvénients : difficultés de conversion ; communauté plus petite que celle des moteurs natifs PyTorch.

NVIDIA TensorRT-LLM + Triton Inference Server

TensorRT-LLM permet une compilation à l’avance des moteurs avec des noyaux fusionnés ; Triton gère des flottes de modèles multiples.

# Build a TensorRT-LLM engine for a small model (simplified)
trtllm-build --checkpoint_dir ./qwen2.5-1.5b-checkpoint \
    --output_dir ./qwen2.5-1.5b-engine \
    --gemm_plugin float16

# Serve via Triton
tritonserver --model-repository=/models

Idéal pour : un débit maximal du parc NVIDIA et les traitements où la latence est critique. Avantages : performances maximales une fois compilé. Inconvénients : les moteurs sont spécifiques à chaque SKU et à sa forme ; une récompilation est nécessaire en cas de changement du matériel ou des paramètres de lot.

Choisir un framework : un guide de décision

Un modèle mental : trois questions, pas une liste de fonctionnalités

Question 1 : Où le modèle doit-il s’exécuter physiquement ? Navigateur ou téléphone sans appel réseau → WebLLM/MLC. CPU/Apple/edge sans CUDA → llama.cpp/Ollama. Ce n’est qu’ensuite qu’il convient d’envisager les moteurs GPU pour data center.

Question 2 : S’agit-il d’un service en production ou d’une exploration humaine ? Exploration → LM Studio ou Ollama. API en production → vLLM/SGLang/TGI/TensorRT selon la question suivante.

Question 3 (uniquement pour la production GPU) : Quelle est la forme du trafic, et quel est le budget alloué à l’ingénierie ? Complétions indépendantes en une seule fois → vLLM par défaut. Préfixes d’agents très répétitifs / sorties structurées → SGLang. Optimisation maximale de NVIDIA avec investissement dans la plateforme → TensorRT-LLM + Triton. Facilité d’utilisation avec Hub/Helm → TGI.

Recherches compressées :

Rendement maximal de l’API GPU → vLLM (ou SGLang en cas d’usage agentiel ou répétitif)
Optimisation maximale de NVIDIA avec budget de compilation → TensorRT-LLM + Triton
CPU/Apple/edge → llama.cpp ; enveloppe DX → Ollama
Navigateur/client hors ligne → WebLLM/MLC
Windows/NPU/ONNX standard → ONNX Runtime GenAI
Évaluation par clic → LM Studio

Systèmes agentiels d’entreprise contre tout le reste

Le trafic de demande/réponse en une seule étape privilégie le lotage continu sur vLLM. Les agents d’entreprise peuvent appeler le modèle des dizaines de fois par tâche — planification, choix d’outil, observation, réplanification — ce qui rend le cache préfixé et les sorties structurées essentiels. Ces déploiements reposent souvent sur SGLang ou TensorRT-LLM + Triton sur des GPU auto-hébergés, avec TGI comme alternative lorsque l’intégration au Hub prime sur la bande passante maximale.

Les plateformes d’agents multi-locataires nécessitent également des quotas par utilisateur, un suivi des appels aux outils et une possibilité de réversion claire des paires prompt+modèle — des considérations liées aux LLMOps qui dépassent le cadre d’un seul moteur.

Guide de déploiement en production

Faire fonctionner quelque chose ne représente qu’environ un cinquième du travail. Le reste consiste à le maintenir correct, économique et sécurisé.

Considérez la quantification, le registre, l’évaluation, les versions de test et le routage comme un cycle que traverse chaque version du modèle :

1. Stratégie de quantification. Par défaut, on opte pour AWQ-4bit ou GGUF Q4_K_M dans de nombreux flux de travail SLM en production — les métriques des tâches en FP16 restent généralement à quelques pour cent près lors d’une évaluation minutieuse — et il faut s’assurer que le moteur choisi prend en charge ce format. La quantification n’est pas une conversion ponctuelle ; elle s’arrête à un point d’évaluation, et non avec la commande de conversion.

2. Versionnement des modèles et registre. Considérez les versions affinées ainsi que les artefacts quantifiés comme des objets immuables et versionnés — ne jamais écraser directement sur place. MLFlow, des dépôts Hugging Face Hub avec des digests, ou un registre OCI interne d’artefacts fonctionnent tous à condition que les digests soient spécifiés dans les manifestes de déploiement.

3. Points d’évaluation. Maintenez un ensemble de référence pour la tâche : l’F1 de classification, la précision des champs extraits, le taux de validité du schéma, la justesse des refus, ainsi que les budgets de latence. Empêchez le passage en production lorsque ces points d’évaluation échouent, même si les démonstrations semblent plus performantes.

4. Topologie de traitement. Séparez les outils de tokenisation/prétraitement basés sur CPU des travailleurs GPU lorsque cela est utile ; ajustez automatiquement la capacité en fonction de la profondeur de la file d’attente et de l’utilisation des GPU, et non seulement du nombre de requêtes par seconde. Maintenez un pool prêt à l’emploi si les démarrages en mode froid violent les objectifs de performance.

5. Observabilité. Exportez les données relatives à la latence des requêtes, au nombre de tokens entrants/sortants, aux taux d’atteinte du cache, à la taille des lots, ainsi qu’au nombre de cas de dépassement de mémoire ou de tentatives de réessai. Échantillonnez soigneusement les requêtes en respectant la politique de confidentialité.

6. Retours arrière. Utilisez des approches blue/green ou canary en fonction du résumé du modèle et de la version de la requête comme entité unique. Rétablissez immédiatement les configurations initiales en cas d’augmentation soudaine de la qualité des résultats.

7. Tests A/B et routage multi-modèles

Routez les tâches en fonction de leur type : utilisez des modèles SLM pour la classification et l’extraction ; optez pour des modèles plus gros pour la génération ouverte. Dirigez temporairement le trafic vers les modèles de test avant le passage complet. Suivez le coût par tâche réussie, et non seulement le nombre de tokens, afin qu’un modèle moins cher qui nécessite deux tentatives ne soit pas considéré à tort comme le meilleur.

Les flags de fonctionnalité doivent relier les routes clients aux points d’entrée du modèle nommés situés derrière le gateway, afin que les changements ne nécessitent pas de mises à jour de l’application.

Plans d’action par domaine

Applications consommatrices/mobiles

Préférez les SLM embarqués ou proches de l’appareil via MLC/WebLLM ou GGUF sur les environnements d’exécution locaux. Gérez soigneusement la mémoire ; transmettez les tokens de manière fluide pour améliorer l’expérience utilisateur ; conservez une solution de secours en cloud pour les requêtes complexes, avec un consentement clair.

Les autres domaines (copilotes de support, RAG interne, gateways edge) suivent le même modèle : choisissez d’abord les contraintes matérielles, puis le moteur, enfin la boucle de quantification et d’évaluation.

Anti-modèles

Déployer en FP16 « pour des raisons de qualité » sans mesurer une version quantifiée sur la tâche réelle
Utiliser des topologies Ollama/LM Studio pour des environnements de production à fort débit sans moteur de service conçu pour la concurrence
Écraser directement les fichiers du modèle, ce qui rend les retraits de version obsolètes

Évaluer uniquement sur des tests de vibe plutôt que sur des ensembles d’entraînement complets.

Ignorer le KV-cache et les métriques par lots jusqu’à ce que les GPU manquent de mémoire en production.

Considérer les modifications des prompts comme gratuites tout en fixant les versions des modèles — ou l’inverse.

Points clés

Les SLMs sont préférables lorsque les tâches sont restreintes, que les données ne peuvent pas quitter l’environnement d’entraînement, ou lorsque les budgets de coût et de latence interdisent l’utilisation de modèles avancés.
LLMOps étend MLOps en intégrant l’efficacité du déploiement, la fidélité de la quantification, la gestion des versions des prompts et outils, ainsi que des considérations économiques liées aux tokens.
Choisir les moteurs en fonction du lieu d’exécution (device/CPU/GPU), de l’étape (exploration vs déploiement) et de la nature du trafic (uniquement pour une requête vs traitement agissant).
Le succès en production repose sur un cycle : quantifier → enregistrer → évaluer → tester progressivement → observer → revenir en arrière.
Associer des résumés de modèles durables à un système de routage du type « doorbell » afin que les clients restent stables malgré l’évolution des backends.

Références

Veuillez consulter la documentation officielle de chaque projet pour connaître les paramètres d’installation et les versions spécifiques : vLLM, SGLang, Hugging Face TGI, llama.cpp, Ollama, LM Studio, MLC-LLM/WebLLM, ONNX Runtime GenAI ainsi que NVIDIA TensorRT-LLM/Triton. Les guides matériels fournis par NVIDIA et les documents Apple Metal complètent les fiches README des moteurs lors de la mise en tune des tailles de lots et de la quantification.

Gardez un manuel interne qui indique quels digests ont été testés avec quels ensembles de référence sur quelles SKU de GPU — c’est cet élément qui transforme ce guide en une plateforme opérationnelle.

Appendice : Gestion des SLM de la deuxième à la vingtième semaine

Après le premier appel curl réussi vers un serveur local, des questions difficiles surgissent : qui est responsable en cas d’incident, comment sont planifiées les mises à jour des pilotes CUDA, et que se passe-t-il lorsque une campagne marketing triple les QPS du jour au lendemain ? Répondez-y par écrit avant de lancer le premier canari.

La planification de la capacité pour les SLM nécessite encore de la marge pour faire face à l’augmentation de la mémoire cache KV en fonction de la longueur du contexte. Un modèle de 1,5 milliard de paramètres qui semble modeste avec un contexte de 2 k peut exercer une pression sur la mémoire lorsque les clients ouvrent des fenêtres de 32 k. Il convient de suivre les tokens de contexte au niveau p95 séparément du taux de requêtes.

Les audits de sécurité doivent couvrir la chaîne d’approvisionnement des modèles : vérification des checksum lors du téléchargement, identification de ceux qui peuvent publier dans le registre, et vérification pour savoir si des prompts système contenant des informations sensibles finissent par figurer dans les bundles destinés aux clients. Les modèles exécutés sur le dispositif nécessitent des canaux de mise à jour tout aussi rigoureux que ceux utilisés pour les applications mobiles.

Les analyses de coûts doivent comparer le coût total de possession : location des GPU, temps consacré par les ingénieurs aux reconfigurations TensorRT, ainsi que les incidents de qualité liés à une quantification trop agressive. Parfois, un SLM légèrement plus grand en 8 bits est moins cher qu’un modèle minuscule qui oblige à des interventions manuelles.

Il est essentiel de former l’équipe. Fournissez aux ingénieurs en développement des outils prêts à l’emploi : un fichier Helm ou Compose, une URL de base compatible OpenAI, ainsi que des tableaux de bord déjà configurés. Offrez aux ingénieurs en apprentissage automatique des moyens simples pour publier des synthèses qui respectent les critères requis. La plupart des échecs surviennent lors du transfert de responsabilités entre ces groupes.

Finalement, réexaminez chaque trimestre la tentation d’opter pour des modèles plus gros, en vous basant sur des données concrètes. Si la note obtenue par un SLM stagne alors que les tâches des utilisateurs deviennent plus complexes, procédez à des mises à niveau ciblées — selon le parcours approprié — plutôt que de remplacer l’ensemble du système du jour au lendemain. LLMOps pour les SLMs repose autant sur la retenue que sur l’accélération.

Note opérationnelle : indiquez précisément les versions des composants CUDA dans des fichiers de verrouillage, et notez la version du pilote à côté de chaque version testée avec succès afin de pouvoir diagnostiquer les dérives entre les couches logicielles et matérielles en cas d’incident.

Note opérationnelle : spécifier les versions exactes des roues CUDA dans les fichiers de verrouillage, et noter la version du pilote à côté de chaque version canari fonctionnelle afin de pouvoir isoler les dérives entre les couches logicielles et le firmware en cas d’incident.

Note opérationnelle : spécifier les versions exactes des paquets CUDA dans les fichiers de verrouillage, et noter la version du pilote à côté de chaque version de test réussie afin de pouvoir diagnostiquer les régressions au niveau du logiciel et du firmware en cas d’incident.

Note opérationnelle : spécifier les versions exactes des roues CUDA dans les fichiers de verrouillage, et noter la version du pilote à côté de chaque version canari fonctionnelle afin de pouvoir diagnostiquer les régressions au niveau du logiciel et du firmware en cas d’incident.

Note opérationnelle : spécifier les versions exactes des roues logicielles pour les piles CUDA dans les fichiers de verrouillage, et noter la version du pilote à côté de chaque version de test réussie afin de pouvoir diagnostiquer les régressions au niveau du logiciel et du firmware en cas d’incident.

Note opérationnelle : indiquer les versions exactes des roues logicielles pour les piles CUDA dans les fichiers de verrouillage, et noter la version du pilote à côté de chaque version de test réussie afin de pouvoir diagnostiquer les régressions au niveau du logiciel et du firmware en cas d’incident.

Tous les articles Envoyer le brief