Comment un contrôle RAID interagit-il avec la latence de l’inférence locale ?
Un scrub RAID augmente la latence de l'inférence locale lorsque ses lectures de vérification entrent en concurrence avec le chargement du modèle, la récupération, la journalisation ou la pression mémoire sur des chemins de stockage partagés.
Un modèle déjà présent dans la mémoire du GPU peut décoder normalement pendant un scrub, tandis que sa première requête, sa recherche RAG ou son opération de débordement ralentit soudainement. Le scrub parcourt les données allouées, lit les copies redondantes ou la parité, vérifie l'intégrité et peut réparer les dommages. Son impact dépend moins du terme RAID que des disques, des files d'attente du contrôleur, des cycles CPU et des pages de cache dont l'inférence a encore besoin.
Le scrub transforme la capacité inutilisée en E/S de vérification
Un scrub lit systématiquement les blocs alloués, valide les sommes de contrôle ou la parité et reconstruit les données endommagées lorsque la redondance le permet. Même les baies saines effectuent les opérations de lecture et de vérification, de sorte que le processus peut maintenir chaque disque membre occupé pendant des heures.
OpenZFS décrit le scrub et la reconstruction comme une classe d'E/S scrub distincte dont la concurrence est équilibrée avec les lectures et écritures normales. Augmenter l'activité du scrub accélère la fin de la vérification, mais peut accroître la latence des opérations au premier plan.
Les baies de disques rotatifs souffrent des déplacements des têtes lorsque les lectures du scrub s'entrecroisent avec de petites requêtes aléatoires, tandis que les baies SSD peuvent saturer la bande passante du contrôleur ou les canaux flash internes. Un même débit nominal peut donc produire des latences de queue très différentes.
L'inférence ne ressent le scrub qu'à travers les dépendances partagées
Le décodage des jetons à partir de poids et d'un cache KV entièrement résidents dépend principalement du calcul et de la bande passante mémoire. Le stockage devient visible lors du chargement du modèle, des défauts de page liés au mappage mémoire, de la récupération, de la journalisation des prompts, des changements d'adaptateur, du déport du cache KV ou de tout accès à un checkpoint ou à un index.
OpenZFS indique que les opérations de scrub émettent des lectures disque et que l'ordre de balayage modifie la manière dont le travail atteint le pool. Ces paramètres de planification du balayage peuvent évincer des pages de cache utiles ou occuper les files d'attente avant l'arrivée d'une lecture de modèle ou de vecteurs sensible à la latence.
Le calcul des sommes de contrôle par le CPU et la reconstruction de la parité peuvent également entrer en concurrence avec la tokenisation, la récupération ou l'inférence CPU. Le délai observable peut apparaître sous forme de latence jusqu'au premier jeton, de retard de récupération ou de blocages périodiques, plutôt que comme une réduction uniforme du nombre de jetons produits par seconde.
La limitation de débit échange le temps d'achèvement contre la latence de queue
Limiter la concurrence du scrub ou suspendre la vérification pendant les heures interactives laisse davantage de capacité dans les files pour l'inférence, mais prolonge la période durant laquelle les erreurs latentes restent inconnues. La planification seule n'est utile que lorsque la demande est prévisible et que le scrub peut malgré tout s'achever dans le délai de maintenance prévu.
Le guide de réglage d'OpenZFS indique qu'augmenter le délai du scrub peut réduire l'effet du scrub sur les charges de travail dynamiques. Le réglage approprié dépend du matériel et de la charge de travail, car un miroir, un groupe RAID-Z, un SSD SATA et un pool NVMe présentent des goulots d'étranglement différents.
La limite critique est celle d'une baie dégradée ou d'une réparation en cours. La reconstruction des données peut devoir passer avant la latence interactive, et une limitation trop forte peut prolonger la période de vulnérabilité ; la bonne réponse n'est pas de dissimuler un risque de stockage derrière un chatbot rapide.
Profilage d'un scrub sur le chemin critique de l'inférence
Mesurez le temps p50 et p99 jusqu'au premier jeton, le débit de jetons, la latence de récupération, les défauts de page du modèle, la profondeur de la file disque, la latence de lecture, le débit, l'utilisation du CPU, la taille de l'ARC ou du cache de pages et la progression du scrub avant et pendant la vérification. Cette distinction reste observable lors des tests ultérieurs en conditions domestiques.
Utilisez la concurrence de stockage liée aux instantanés pour distinguer la concurrence des instantanés de celle du scrub. Répétez les tests avec des modèles résidents et froids, le RAG activé et désactivé, une concurrence du scrub normale et limitée, ainsi qu'une référence utilisant uniquement le stockage. Le résultat intermédiaire doit rester vérifiable avant toute automatisation.
Choisissez une limite qui protège la latence de queue interactive tout en permettant de terminer les vérifications d'intégrité dans les délais. Si le décodage depuis le GPU reste inchangé mais que la récupération bloque, isolez ou priorisez le chemin de stockage partagé au lieu de régler le modèle.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce que la dérive des représentations vectorielles, et quand faut-il reconstruire un index de recherche privé ?
Décoder la dérive du modèle, du prétraitement, du corpus et des requêtes ; distinguer la surveillance de l’incompatibilité ; et déterminer quand un index...
Qu’est-ce que la compatibilité des tokeniseurs et pourquoi peut-elle perturber le changement de modèle ?
Décodez l’identité du vocabulaire, la sémantique des tokens spéciaux, les modèles de chat, les tokens mis en cache, les adaptateurs et les vérifications de...
Qu’est-ce que la résidence d’un modèle et quand un service d’IA local doit-il conserver les poids chargés ?
Comprendre la persistance des poids, les niveaux de cache, les démarrages à froid, l’éviction, le multiplexage, la pression mémoire et les situations où un...
