L'utilisation de plusieurs puces d'inférence nécessite une planification minutieuse

Les deux dernières années ont été extrêmement chargées dans le secteur des puces d'inférence. Pendant un certain temps, il a semblé qu'une semaine sur deux, une autre entreprise présentait une nouvelle et meilleure solution. Alors que toute cette innovation était géniale, le problème était que la plupart des entreprises ne savaient pas quoi faire des différentes solutions car elles ne pouvaient pas dire laquelle était la plus performante qu'une autre. Sans ensemble de références établies sur ce nouveau marché, ils devaient soit se familiariser très rapidement avec les puces d'inférence, soit croire les chiffres de performance fournis par les différents fournisseurs.

La plupart des fournisseurs ont fourni un certain type de chiffre de performance et il s'agissait généralement de la référence qui leur donnait une bonne apparence. Certains fournisseurs ont parlé de TOPS et de TOPS/Watt sans spécifier de modèles, de tailles de lots ou de conditions de processus/tension/température. D'autres ont utilisé le benchmark ResNet-50, qui est un modèle beaucoup plus simple que ce dont la plupart des gens ont besoin, donc sa valeur dans l'évaluation des options d'inférence est discutable.

Nous avons parcouru un long chemin depuis ces premiers jours. Les entreprises ont lentement compris que ce qui compte vraiment pour mesurer les performances des puces d'inférence, c'est 1) une utilisation MAC élevée, 2) une faible puissance et 3) vous devez tout garder petit.

Nous savons mesurer, quelle est la prochaine étape ?

Maintenant que nous avons une assez bonne idée de la façon de mesurer les performances d'une puce d'inférence par rapport à une autre, les entreprises se demandent maintenant quels sont les avantages (ou les inconvénients) à utiliser plusieurs puces d'inférence ensemble dans la même conception. La réponse simple est que l'utilisation de plusieurs puces d'inférence, lorsque la puce d'inférence est conçue de la bonne manière, peut générer des augmentations linéaires des performances. L'analogie avec une autoroute n'est pas loin lorsque nous envisageons d'utiliser plusieurs puces d'inférence. Une entreprise souhaite-t-elle les performances d'une autoroute à une voie ou d'une autoroute à quatre voies ?

De toute évidence, chaque entreprise veut une autoroute à quatre voies, la question devient donc désormais « comment pouvons-nous fournir cette autoroute à quatre voies sans créer de trafic ni de goulots d'étranglement ? » La réponse repose sur le choix de la bonne puce d'inférence. Pour expliquer, examinons un modèle de réseau de neurones.

Les réseaux de neurones sont décomposés en couches. Des couches telles que ResNet-50 ont 50 couches, YOLOv3 en a plus de 100 et chaque couche reçoit une activation de la couche précédente. Ainsi, dans la couche N, sa sortie est une activation qui passe dans la couche N+1. Il attend que cette couche entre, un calcul est effectué et la sortie est des activations qui vont à la couche n+2. Cela continue pendant toute la longueur des couches jusqu'à ce que vous obteniez enfin un résultat. Gardez à l'esprit que l'entrée initiale de cet exemple est une image ou tout autre ensemble de données en cours de traitement par le modèle.

Quand plusieurs jetons font la différence

La réalité est que si vous avez une puce qui a un certain niveau de performances, il y aura toujours un client qui voudra deux fois plus de performances ou quatre fois plus de performances. Si vous analysez le modèle de réseau de neurones, il est possible d'y parvenir dans certains cas. Il vous suffit de regarder comment vous divisez le modèle entre deux ou quatre puces.

Cela a été un problème avec le traitement parallèle au fil des ans, car il a été difficile de comprendre comment partitionner le traitement que vous effectuez et de vous assurer que tout est additionné, au lieu d'être soustrait en termes de performances.

Contrairement au traitement parallèle et à l'informatique à usage général, l'avantage des puces d'inférence est que les clients savent généralement à l'avance s'ils souhaitent utiliser deux puces afin que le compilateur n'ait pas à le découvrir à la volée - cela se fait au moment de la compilation. Avec les modèles de réseaux de neurones, tout est totalement prévisible afin que nous puissions analyser et déterminer exactement comment diviser le modèle et s'il fonctionnera bien sur deux puces.

Pour s'assurer que le modèle peut fonctionner sur deux puces ou plus, il est important d'examiner à la fois la taille d'activation et le nombre de MAC couche par couche. Ce qui se passe généralement, c'est que les plus grandes activations se situent dans les premières couches. Cela signifie que les tailles d'activation diminuent lentement au fur et à mesure que le nombre de couches augmente.

Il est également important d'examiner le nombre de MAC et le nombre de MAC effectués à chaque cycle. Dans la plupart des modèles, le nombre de MAC effectués dans chaque cycle est généralement en corrélation avec les tailles d'activation. Ceci est important car si vous avez deux puces et que vous souhaitez fonctionner à une fréquence maximale, vous devez affecter des charges de travail égales à chaque puce. Si une puce fait la majeure partie du modèle et que l'autre puce ne fait qu'une petite partie du modèle, vous serez limité par le débit de la première puce.

La façon dont vous divisez le modèle entre les deux puces est également importante. Vous devez regarder le nombre de MAC car cela détermine la répartition de la charge de travail. Il faut aussi regarder ce qui se passe entre les jetons. À un moment donné, vous devez découper le modèle à un endroit où l'activation que vous avez transmise est aussi faible que possible afin que la quantité de bande passante de communication requise et la latence de la transmission soient minimales. Si vous découpez le modèle à un point où l'activation est très importante, la transmission de l'activation peut devenir le goulot d'étranglement qui limite les performances de la solution à deux puces.

Le tableau ci-dessous montre pour les images YOLOv3, Winograd, 2 mégapixels la taille de la sortie d'activation et les opérations Mac cumulées couche par couche (les couches de convolution sont tracées). Pour équilibrer la charge de travail entre deux puces, le modèle sera coupé à environ 50 % d'opérations MAC cumulées — à ce stade, les activations à passer d'une puce à l'autre sont de 1 Mo ou 2 Mo. A répartir entre 4 jetons, les coupes sont d'environ 25 %, 50 % et 75 %; notez que les tailles d'activation sont les plus importantes au début, donc le point de coupure de 25 % a 4 ou 8 Mo d'activations à passer.

Cliquez ici pour agrandir l'image
Taille de sortie d'activation (barres bleues) et opérations MAC cumulées couche par couche (ligne rouge) pour les images YOLOv3/Winograd/2Mpixel , montrant comment la charge de travail est répartie entre plusieurs puces (Image :Flex Logix)

Outils de performance

Heureusement, des outils de performance sont désormais disponibles pour assurer un débit élevé. En fait, le même outil qui modélise les performances d'une seule puce peut alors être généralisé pour modéliser les performances de deux puces. Bien que les performances d'une couche donnée soient exactement les mêmes, le problème est de savoir comment la transmission des données affecte les performances. L'outil de modélisation doit en tenir compte car si la bande passante requise n'est pas suffisante, cette bande passante limitera le débit.

Si vous utilisez quatre puces, vous aurez besoin d'une bande passante plus importante car les activations dans le premier quart du modèle ont tendance à être plus importantes que l'activation dans la dernière partie du modèle. Ainsi, la quantité de ressources de communication dans laquelle vous investissez vous permettra d'utiliser un plus grand nombre de puces en pipeline, mais ce sera un coût indirect que toutes les puces devront supporter, même si ce sont des puces autonomes.

Conclusion

L'utilisation de plusieurs puces d'inférence peut apporter des améliorations significatives des performances, mais uniquement lorsque le réseau de neurones est conçu correctement comme décrit ci-dessus. Si nous revenons à l'analogie de l'autoroute, il existe de nombreuses possibilités de laisser le trafic augmenter en utilisant la mauvaise puce et le mauvais modèle de réseau neuronal. Si vous commencez avec la bonne puce, vous êtes sur la bonne voie. N'oubliez pas que le débit, et non les benchmarks TOPS ou Res-Net50, est ce qui compte le plus. Ensuite, une fois que vous avez sélectionné la bonne puce d'inférence, vous pouvez concevoir un modèle de réseau neuronal tout aussi puissant qui offre des performances maximales pour les besoins de votre application.

— Geoff Tate est le PDG de Flex Logix