Pourquoi DeepSeek est bon march� � grande �chelle mais co�teux � exploiter localement, par sean goedecke

**Sean Goedecke** · 02/09/2025, 15h19

Pourquoi DeepSeek est bon march� � grande �chelle mais co�teux � exploiter localement, par Sean Goedecke

Pourquoi DeepSeek-V3 est-il cens� �tre rapide et bon march� � grande �chelle, mais trop lent et co�teux � exploiter localement ? Pourquoi certains mod�les d'IA sont-ils lents � r�pondre mais rapides une fois qu'ils sont lanc�s ?

Les fournisseurs d'inf�rence IA �voquent souvent un compromis fondamental entre le d�bit et la latence : pour un mod�le donn�, vous pouvez soit le servir � haut d�bit et haute latence, soit � faible d�bit et faible latence. En fait, certains mod�les sont si naturellement inefficaces en termes de GPU qu'ils doivent, dans la pratique, �tre servis � haute latence pour avoir un d�bit exploitable (par exemple, DeepSeek-V3).

Ce compromis provient de la taille du lot que le fournisseur d'inf�rence choisit pour le mod�le : il ne s'agit pas de regrouper les inf�rences au sein d'une requ�te individuelle, mais de regrouper les inf�rences entre des dizaines ou des centaines de requ�tes utilisateur simultan�es. C'est une caract�ristique particuli�re des LLM bas�s sur des transformateurs que le calcul d'un lot de compl�tions en m�me temps est presque aussi rapide que le calcul d'une seule compl�tion. Pourquoi ?

Qu'est-ce que l'inf�rence par lots ?

Les GPU sont efficaces pour effectuer de grandes multiplications matricielles (GEMM, ou � general matrix multiplications �). Supposons que vous ayez un seul jeton que vous souhaitez faire passer dans un mod�le (c'est-�-dire en le multipliant par tous ses poids - les autres d�tails de l'architecture ne sont pas pertinents). Vous l'exprimez sous la forme d'un vecteur qui correspond � la dimension (ou taille cach�e) du mod�le (c'est-�-dire 1 x la largeur de ses grandes matrices de poids) et vous le multipliez. Cela correspond � 1 GEMM. Mais si vous souhaitez faire passer dix jetons dans un lot, cela ne correspond toujours qu'� un seul GEMM, car vous pouvez empiler les jetons dans une seule matrice (10 x la dimension du mod�le). C'est beaucoup plus rapide que d'effectuer dix GEMM l�g�rement plus petits. Ainsi, la mise en �uvre d'un serveur d'inf�rence pourrait ressembler � ceci :

Une requ�te arrive avec une instruction g�n�rative
Cette instruction g�n�rative est pr�remplie (pass�e par l'attention - nous verrons plus tard comment cela peut �galement �tre trait� par lots), formant un cache KV et une matrice de la taille d'un jeton (1 x la taille du mod�le) qui deviendra finalement le jeton pr�dit
Cette matrice de la taille d'un jeton est plac�e dans une file d'attente
Un serveur GPU extrait des lots (par exemple de 128) de cette file d'attente, les empile dans une matrice de 128 x la taille du mod�le et les multiplie par les poids du mod�le feed-forward
Le r�sultat final est ensuite divis� en 128 jetons distincts
Celui correspondant � la requ�te d'origine est renvoy� � l'utilisateur.
En supposant que ce jeton ne soit pas un jeton de fin de s�quence, revenez � l'�tape 2 pour continuer � g�n�rer le jeton suivant dans la r�ponse.

Notez que c'est le serveur qui d�cide de la taille du lot � extraire. Il s'agit d'un compromis entre le d�bit et la latence. Si vous ne faites pas de traitement par lots et que vous traitez les jetons un par un, aucun utilisateur n'attend dans une file d'attente (�tape 3 ci-dessus), donc la latence est faible (en supposant que vous disposiez de suffisamment de GPU). Cependant, si vous effectuez beaucoup de traitements par lots, la latence est �lev�e car les utilisateurs attendent que la taille du lot soit remplie, mais le d�bit est beaucoup plus �lev� car les GPU sont utilis�s plus efficacement.

Pourquoi les GPU sont-ils plus rapides pour multiplier une seule fois de grandes matrices que pour multiplier plusieurs fois de petites matrices ? Il y a deux raisons � cela. Premi�rement, l'�mission de chaque commande au GPU entra�ne une certaine surcharge, et une seule commande permet de lancer une grande multiplication. Deuxi�mement, chaque nouvelle commande GPU implique de r�cup�rer des poids dans la m�moire, ce qui peut �tre co�teux pour les poids importants. Si vous ex�cutez de nombreux petits GEMM, vous pouvez finir par passer la plupart de votre temps � transf�rer des poids vers et depuis la m�moire au lieu de les calculer.

Pourquoi certains mod�les sont-ils optimis�s pour des tailles de lots �lev�es ?

En g�n�ral, un serveur d'inf�rence dispose d'une � fen�tre de collecte � o� les demandes des utilisateurs sont re�ues et mises en file d'attente. Les serveurs de chat visent g�n�ralement 5 � 10 ms, mais les backends � tr�s haut d�bit peuvent aller jusqu'� 200 ms. Si une nouvelle requ�te arrive au d�but de la fen�tre, elle peut attendre toute la dur�e de la fen�tre avant d'�tre trait�e. Lorsque la fen�tre se ferme, toutes les requ�tes en file d'attente sont regroup�es en lots (c'est-�-dire que toutes les matrices de taille 1xmod�le sont concat�n�es en une seule matrice de taille 128xmod�le) et ce lot est envoy� via le pipeline. L'ex�cution d'un lot comme celui-ci est parfois appel�e � tick �.

Comme l'explique le paragraphe ci-dessus, vous pouvez ex�cuter n'importe quel mod�le avec n'importe quelle taille de lot. Le processus de traitement par lots n'a rien en soi qui exclurait certains types de mod�les. Cependant, il est possible de construire un mod�le si peu efficace en termes de GPU qu'il n�cessite effectivement un traitement par lots pour �tre pratique.

Pourquoi le m�lange d'experts n�cessite des tailles de lots plus importantes

Prenons par exemple un mod�le de m�lange d'experts (comme DeepSeek-V3 ou, suppos�ment, le GPT-4 original). Vous pouvez obtenir un mod�le puissant en l'entra�nant � disposer de centaines et de centaines d'� experts � : des blocs distincts de poids feed-forward, � partir desquels une couche de routage s�lectionne un sous-ensemble qui est utilis� sur chaque jeton. Mais un mod�le comme celui-ci est vraiment inefficace en termes de GPU. Nous pouvons comprendre pourquoi : les GPU veulent effectuer un petit nombre de multiplications matricielles vraiment importantes, mais si vous avez beaucoup d'experts, vous �tes oblig� d'effectuer de nombreuses petites multiplications. � moins que vous ne fassiez votre inf�rence par lots, cela se traduira par un faible d�bit.

R�fl�chissons � la fa�on dont une � fen�tre de collecte � de 5 ms et 200 ms fonctionnerait pour un grand mod�le de m�lange d'experts. Supposons que vous r�cup�riez dix requ�tes utilisateur dans cette fen�tre de 5 ms. Si vous avez de nombreux experts, certains d'entre eux pourraient finir par ne traiter qu'un ou deux jetons (c'est-�-dire que la taille du lot pour chaque expert sera bien inf�rieure � l'ensemble total des requ�tes que vous avez r�cup�r�es dans votre fen�tre). Si, en revanche, vous attendez 200 ms et r�cup�rez 4 000 requ�tes utilisateur, vous avez beaucoup plus de chances de saturer tous vos experts. Au prix d'une certaine latence, vous vous assurez que vos GEMM sont volumineux et que vos GPU sont constamment utilis�s � leur capacit� maximale.

Pourquoi les pipelines volumineux n�cessitent des tailles de lots �lev�es pour �viter les bulles de pipeline

Pour les mod�les volumineux, il peut �tre difficile de maintenir les GPU actifs. Les mod�les volumineux comportent g�n�ralement de nombreuses couches de transformateurs, c'est-�-dire des centaines de matrices de poids qui composent le r�seau feed-forward. La seule fa�on d'obtenir une inf�rence rapide dans ce cas est de mettre ces couches en pipeline en demandant � un GPU de traiter les dix premi�res couches, � un autre de traiter les dix suivantes, et ainsi de suite. Sinon, vous ne pourrez tout simplement pas faire tenir tous les poids dans la m�moire d'un seul GPU, vous passerez donc beaucoup de temps � �changer les poids dans et hors de la m�moire, ce qui finira par �tre tr�s lent. Pendant l'inf�rence, chaque jeton (g�n�ralement dans un � micro-lot � de quelques dizaines de jetons chacun) passe s�quentiellement par ce pipeline de GPU.

L'efficacit� de votre pipeline d�pend du nombre de couches dont vous disposez et de la taille de votre fen�tre de collecte. Lorsque vous traitez les jetons dans une fen�tre pendant un � tick �, vous obtenez des GPU inactifs au d�but (car les GPU des couches suivantes n'ont encore rien � traiter) et d'autres GPU inactifs � la fin (lorsqu'il n'y a plus de jetons dans la file d'attente, les GPU des premi�res couches doivent attendre le prochain � tick �). Ces p�riodes d'inactivit� sont parfois appel�es � warmup � (�chauffement) et � drain � (vidange). Si vous avez de nombreuses petites fen�tres, vous passerez plus de temps GPU en �chauffement et en vidange que si vous avez moins de grandes fen�tres. En choisissant la taille de votre fen�tre, vous faites donc un compromis direct entre le d�bit et la latence.

Si vous avez une multitude de couches et que votre fen�tre de collecte est tr�s courte, vous pouvez parfois vous retrouver avec moins de jetons � traiter que de couches. C'est ce qu'on appelle une � bulle de pipeline � : en effet, la phase de � vidange � commence plus t�t que d'habitude. Vous ne pouvez pas �liminer l'�chauffement et la vidange (pour les raisons �voqu�es ci-dessous, l'inf�rence doit fonctionner par � ticks � s�quentiels), mais vous pouvez �liminer les bulles de pipeline en rendant votre fen�tre de collecte suffisamment longue. Les bulles de pipeline peuvent �tre absolument brutales pour le d�bit du mod�le, c'est pourquoi les fournisseurs d'inf�rence d�finissent toujours leurs fen�tres suffisamment larges pour les �viter. Cela ajoute une latence notable pour les mod�les comportant de nombreuses couches.

Ne pouvez-vous pas simplement garder la file d'attente pleine ?

Pourquoi les fournisseurs d'inf�rence ne pourraient-ils pas �liminer compl�tement l'�chauffement et la vidange en gardant la file d'attente du GPU pleine de jetons ? En d'autres termes, ne pourriez-vous pas supprimer compl�tement les ticks et simplement maintenir le flux des micro-lots de jetons ? Bien s�r, l'inf�rence de chaque utilisateur doit �tre s�quentielle (car vous ne pouvez pas commencer � g�n�rer le jeton suivant tant que le jeton actuel n'est pas termin�), mais les grands fournisseurs d'inf�rence devraient avoir suffisamment de trafic simultan� pour maintenir la file d'attente pleine de demandes d'utilisateurs distinctes.

J'avoue que j'ai du mal � comprendre pourquoi cela ne serait pas possible en th�orie. D'apr�s ce que je peux en juger, l'obstacle pratique r�side dans la mani�re dont l'�tape d'attention est trait�e par lots : si vous voulez regrouper les GEMM d'attention, ils doivent tous avoir la m�me forme (c'est-�-dire le m�me nombre de jetons ant�rieurs dans la s�quence). Vous devez donc ex�cuter des groupes de m�me forme en m�me temps, au lieu de pouvoir simplement maintenir une seule file d'attente. Il existe au moins quelques recherches publiques � ce sujet, mais je ne serais pas surpris qu'il existe des astuces plus ing�nieuses pour y parvenir que je ne connais pas.

Autre id�e : si vous avez besoin de ticks pour l'�tape d'attention, pourquoi ne pas simplement avoir un syst�me d'inf�rence d'attention bas� sur les ticks et un syst�me continu plus efficace pour le FFN ? Si je comprends bien, la raison est la surcharge m�moire :

comme la sortie d'attention est n�cessaire pour le FFN, vous auriez besoin d'un emplacement en m�moire pour la stocker en attendant son tour dans la file d'attente du FFN, ce qui deviendrait rapidement trop co�teux.
Les piles d'inf�rence modernes sont capables de combiner l'�tape d'attention et l'�tape FFN en quelques GEMM de grande taille dans une seule � op�ration �. Si vous effectuez ces op�rations sur diff�rents GPU, vous devez ex�cuter diff�rentes op�rations et transf�rer les poids vers et depuis la m�moire.

R�sum�

Les GPU sont plus efficaces sur les GEMM de grande taille. Par cons�quent, empiler de nombreux jetons dans une seule multiplication matricielle permet d'obtenir un d�bit de jetons bien sup�rieur � celui obtenu en les traitant un par un.
Pendant le d�codage, l'attention ne peut �tre regroup�e que pour les jetons d'une m�me �tape, ce qui oblige les planificateurs � fonctionner par � ticks � courts. Le nombre de jetons que vous regroupez dans un seul � tick � (c'est-�-dire le temps que vous attendez pour collecter les jetons) correspond � la taille de votre lot.
- Il s'agit de jetons provenant de diff�rents utilisateurs. Vous ne pouvez pas regrouper les jetons d'un m�me utilisateur, car vous avez besoin des jetons pr�c�dents pour g�n�rer le suivant. Le regroupement n�cessite donc un volume �lev� de trafic provenant de diff�rents utilisateurs.
Les lots plus importants augmentent la latence, car les jetons des utilisateurs peuvent attendre jusqu'� 200 ms avant que le lot soit suffisamment rempli pour �tre ex�cut�, mais ils augmentent le d�bit en permettant des GEMM plus importants (et donc plus efficaces) dans l'�tape de feed-forward.
Les mod�les comportant de nombreuses couches (par exemple, les pipelines longs) n�cessitent des lots plus importants pour �viter les bulles de pipeline (en s'assurant que chaque tick contient plus de lots que d'�tapes de pipeline).
Les mod�les de type � mixture-of-experts � doivent �tre servis avec une latence �lev�e pour �tre efficaces : chaque expert ne voit que les jetons qui lui sont achemin�s, vous avez donc besoin de lots globaux plus importants pour que chaque expert reste occup�.
Les fournisseurs d'inf�rence choisissent une taille de lot/fen�tre qui �limine les bulles de pipeline et sature les experts. Les lots de grande taille vous permettent d'obtenir un d�bit plus �lev� au prix d'une latence plus importante, car les jetons attendent de remplir le tick.
Certains mod�les (comme ceux de DeepSeek) qui sont des m�langes d'experts � plusieurs couches n�cessitent donc des lots de grande taille et une latence �lev�e, sinon le d�bit chute brutalement. C'est pourquoi on dit souvent qu'il n'est pas facile d'utiliser DeepSeek � des fins personnelles : en effet, avec un seul utilisateur ex�cutant une seule inf�rence � la fois, son efficacit�/son d�bit est tr�s faible.
Le fait que les mod�les d'OpenAI et d'Anthropic soient rapides � r�pondre sugg�re que :
- leurs mod�les ont une architecture plus efficace (non MoE, moins de couches), ou
- OpenAI/Anthropic ont recours � des astuces tr�s intelligentes pour servir l'inf�rence, ou
- ils paient le prix fort pour beaucoup plus de GPU qu'ils n'en ont strictement besoin.