Evaluación de rendimiento y eficiencia energética de procesos de inferencia en GPUs

Universidad Complutense de Madrid Facultad de Inform´ atica EVALUACI ´ ON DE RENDIMIENTO Y EFICIENCIA ENERG´ ETICA DE PROCESOS DE INFERENCIA EN GPUS PERFORMANCE AND ENERGY EFFICIENCY EVALUATION OF INFERENCE PROCESSES ON GPUS Trabajo Fin de Grado Grado en Ingenier´ıa Inform´atica Autor Gonzalo Isla Llave Tutores Francisco D. Igual Pe˜na Jorge Villarrubia Elvira Mayo 2024 Agradecimientos A mi tutor, Fran, por su infinita paciencia y ayuda en el trabajo, y a mi familia y amigos por todo su apoyo. Resumen La compa˜n´ıa NVIDIA se sit´ua como un referente de innovaci´on y desarrollo de GPUs, coloc´andose entre las compa˜n´ıas que m´as est´an creciendo en estos ´ultimos meses. Con la nueva gama de GPUs Blackwell publicada este mismo a˜no 2024, vemos la importancia que se le est´a dando a este sector, como un gran proyecto de futuro. El uso de gran cantidad de datos procedentes del auge de la inteligencia artificial hace que estas m´aquinas tengan tanta importancia. Parte de las investigaciones que se llevan a cabo son formas de sacar el m´aximo partido de estas m´aquinas debido a la cantidad inmensa de procesadores que contienen. Es esta misma premisa lo que se intenta conseguir con este trabajo, haciendo uso del bechmark MLPerf. A trav´es del modo de trabajo Offline que proporciona el banco de trabajo, se estudian una serie de modelos de inferencia que van desde el reconocimiento autom´atico de voz hasta la divisi´on de im´agenes en 3D para ´ambito biom´edico. Estos modelos ya entrenados se analizan en base a su rendimiento en cuanto a latencia, throughput 1y rendimiento energ´etico. La tecnolog´ıa utilizada para contrastar resultados se basa en una NVIDIA A30 y una Jetson Orin AGX, haciendo uso de la herramienta nvpmodel que proporciona a esta ´ultima para limitar la potencia m´axima consumida. Se ha conseguido ver c´omo al aumentar el n´umero de peticiones m´aximas que se le pasa al modelo, el n´umero de muestras procesadas por segundo aumenta. Esto es debido a que las GPUs son capaces de paralelizar el gran n´umero de peticiones entre sus los distintos cores. Por otro lado, se ha demostrado que la eficiencia energ´etica mejora a medida que disminuye la potencia m´axima de la m´aquina. Esto se debe a que en el proceso de inferencia no se est´a proporcionando una suficiente carga de trabajo, de forma que no se puede paralelizar en las m´aquinas de mayor potencia. Por ´ultimo, cuando se estudia la latencia se ha contrastado que al aumentar el batch que se le pasa al modelo (i.e. el n´umero de peticiones), cuando se fija el n´umero de muestras esperadas al n´umero de muestras resultantes, el tiempo de ejecuci´on no var´ıa. Palabras Clave: NVIDIA, MLPerf, Inferencia, A30, AGX, nvpmodel, rendimiento, GPU. El repositorio con las aportaciones, scripts y resultados obtenidos se encuentra en este enlace. 1Eficiencia computacional 3 Abstract NVIDIA has become a leading innovator in GPU development, positioning itself among the fastest-growing companies in recent months. With the release of the new Blackwell GPU series in 2024, we see the importance that is being placed on this sector, with a promising future ahead. The use of vast amount of data driven by the rise of artificial intelligence highlights the importance of these machines. Part of the ongoing research focuses on maximizing the performance due to the massive amount of cores they have. This same premise is carried through in this work, using MLPerf. With the Offline mode provided by the benchmark, a series of models are studied, ranging from automatic speech recognition to 3D image segmentation for biomedical applications. These pre-trained models are analyzed for their performance in terms of latency, throughput and energy efficiency. The technology used to compare the results is a NVIDIA A30 and a Jetson Orin AGX, using the nvpmodel tool provided by the latter to cap the maximum power consumption. It has been observed that as the maximum number of requests passed to the model increases, so does the rate of processed samples per second. This is due to the GPUs being able to parallelize the great number of requests among their different cores. On the other hand, it has also been observed that the energetic efficiency rises with decreasing maximum power of the machine. The reason for this is that during the inference process there would not be a sufficiently high workload, so parallelization in the highest power machines is not optimized. Lastly, in studying the latency it was apparent that increasing the batch size for the model (i.e., the number of requests), and fixing the number of expected samples to the number of resulting samples, the execution time does not vary. Key words: NVIDIA, MLPerf, Inference, A30, AGX, nvpmodel, benchamrk, GPU. The repository containing the contributions, scripts, and results obtained is located in this link. 4 ´ Indice general 1 Introducci´on 9 1.1 Motivaci´on ......................................... 9 1.2 Objetivos .......................................... 10 2 Introduction 12 2.1 Motivation ......................................... 12 2.2 Objectives .......................................... 13 3 Arquitecturas utilizadas 14 3.1 NVIDIA A30 ........................................ 14 3.2 Jetson AGX Orin ...................................... 15 4 MLPerf 16 4.1 Estructura general y escenarios .............................. 16 4.2 Modelos disponibles .................................... 18 4.2.1 BERT ........................................ 18 4.2.2 RNN-T ....................................... 19 4.2.3 3D-Unet ....................................... 19 4.2.4 ResNet50 ...................................... 20 4.2.5 RetinaNet ...................................... 20 4.2.6 GPT-J ........................................ 21 4.2.7 DLRMV2 ...................................... 21 5 Medici´on de potencia 22 5.1 Servidor ........................................... 22 5.1.1 NVIDIA A30 .................................... 22 5.1.2 Jetson AGX ..................................... 24 5.2 Cliente ............................................ 26 6 Dise˜no de los experimentos 28 6.1 Limitaciones ......................................... 31 7 Resultados Obtenidos 32 7.1 Bert ............................................. 32 7.1.1 Throughput ..................................... 32 7.1.2 Eficiencia Energ´etica ................................ 33 7.1.3 Latencia ....................................... 35 7.2 Resnet50 ........................................... 36 7.2.1 Throughput ..................................... 36 7.2.2 Eficiencia energ´etica ................................ 36 7.2.3 Latencia ....................................... 39 7.3 Rnnt ............................................. 40 5 ´ INDICE GENERAL 7.3.1 Througthput .................................... 40 7.3.2 Eficiencia energ´etica ................................ 41 7.3.3 Latencia ....................................... 42 7.4 3D-Unet ........................................... 43 8 Conclusi´on final y trabajo futuro 44 9 Conclusion and future work 45 A Script para automatizar MLPerf 46 B Ejemplo de cliente PMLib utilizando ctypes 48 6 ´ Indice de figuras 4.1 Representaci´on del modelo LoadGen. [1]......................... 16 4.2 Mapa conceptual de las fases del modelo BERT. [2]................... 19 4.3 Capas convolucionales del modelo 3D-Unet. [3]..................... 20 4.4 Representaci´on de red piramidal con las dos subredes propuesta por Retinanet. [4]. 21 6.1 Estructura de directorios. ................................. 28 7.1 Throughput hallado por cada valor de batch en el modelo Bert. ............ 32 7.2 Potencia consumida en cada batch por el modelo Bert en NVIDIA A30. ....... 33 7.3 Potencia consumida en cada batch por el modelo Bert en Jetson Orin AGX. ..... 34 7.4 Potencia consumida en cada batch por el modelo Bert en Jetson Orin AGX con 15W potencia m´axima. ...................................... 34 7.5 Latencia en cada batch para el modelo Bert. ....................... 35 7.6 Throughput hallado por cada valor de batch en el modelo Resnet50. ......... 36 7.7 Potencia consumida en cada batch por el modelo Resnet50 en NVIDIA A30. ..... 37 7.8 Potencia consumida en cada batch por el modelo Resnet50 en Jetson Orin AGX. . . 37 7.9 Potencia consumida en cada batch por el modelo Resnet50 en Jetson Orin AGX con 15W potencia m´axima. ................................... 37 7.10 Eficiencia energ´etica consumida en cada batch por el modelo Resnet50. ........ 38 7.11 Latencia en cada batch para el modelo Resnet50. .................... 39 7.12 Throughput hallado por cada valor de batch en el modelo Rnnt. ........... 40 7.13 Potencia consumida en cada batch por el modelo Rnnt en NVIDIA A30. ....... 41 7.14 Potencia consumida en cada batch por el modelo Rnnt en Jetson Orin AGX. . . . . 41 7.15 Potencia consumida en cada batch por el modelo Rnnt en Jetson Orin AGX con 15W potencia m´axima. ...................................... 41 7.16 Latencia en cada batch para el modelo Rnnt. ...................... 42 7.17 Throughput hallado por cada valor de batch en el modelo 3D-Unet. ......... 43 7 ´ Indice de tablas 4.1 Caracter´ısticas de los modos de MLPerf. [5]....................... 17 7.1 Comparaci´on de latencia entre diferentes m´aquinas y tama˜nos de batch para Bert. . 34 7.2 Comparaci´on de latencia entre diferentes m´aquinas y tama˜nos de batch para Resnet50. 38 7.3 Comparaci´on de latencia entre diferentes m´aquinas y tama˜nos de batch para Rnnt. . 42 8 Cap´ıtulo 1 Introducci´on 1.1. Motivaci´on Desde la invenci´on del primer ordenador se ha trabajado para mejorar el rendimiento del procesamiento de datos, y los enfoques han sido muy variados. Al inicio se llev´o a cabo aumentando la frecuencia de reloj y, de forma totalmente transparente al programador, se obtuvo una mejora sustancial. Sin embargo, debido a las corrientes de fuga y el aumento en la disipaci´on de calor que produce aumentar la frecuencia, este sistema no puede llevarse a cabo de forma indefinida. Por otra parte, siguiendo la famosa Ley de Moore en 1965 [6], se ha conseguido durante a˜nos reducir el tama˜no de los transistores a la mitad cada 18 meses, pero a su vez esta mejora tambi´en est´a limitada. A nivel de uniprocesador hemos tenido que tomar otras v´ıas para mejorar los computadores, optando en primer lugar por la paralelizaci´on a nivel de instrucci´on (ILP). Esto introdujo as´ı t´erminos como cambio de contexto opipelines y por tanto, t´ecnicas que hicieron mejorar el rendimiento como la ejecuci´on fuera de orden (Out of Orden - OoO), las predicciones de salto, el cambio de la jerarqu´ıa de memoria para hacer accesos ecualescentes, etc. M´as tarde lleg´o el paralelismo a nivel de thread (TLP), consiguiendo ejecutar varios hilos en un s´olo n´ucleo. Al igual que con ILP, tambi´en trajo problemas para el programador a la hora de sincronizar los datos (carreras cr´ıticas, deadlocks, coherencias de cach´e, etc.), aunque mejor´o el rendimiento. No fue hasta inicios de los 2000 cuando se populariz´o el uso de ordenadores multicore, consiguiendo conectar varios cores f´ısicos entre ellos por buses de alta velocidad. A˜nadir una memoria cach´e compartida, diferente de la individual, hizo que la latencia de acceso a memoria bajase de forma dr´astica y facilitase la comunicaci´on y por ende, el rendimiento. Como ´ultimo paso, a nivel de CPU, existen los grids, que son la interconexi´on de procesadores multicore a trav´es de red, lo que nos permite coordinar recursos de forma no centralizada, paralela y distribuida. Pese a todas estas mejoras cabe destacar que hay casos en los que por mucho m´as cores que se a˜nadan, por naturaleza de la aplicaci´on, no es posible paralelizar el programa. Con el auge de los videojuegos y con el aliciente por mejorar sus gr´aficos, nace en 1999 el t´ermino GPU (Graphics Processing Unit), que conlleva la explotaci´on del paralelismo a nivel de datos. Debido a la cantidad de operaciones de vectores derivadas del renderizado de im´agenes que producen los videojuegos, surgen las instrucciones vectoriales o SIMD (Single Instruction Multiple Data). A d´ıa de hoy, aunque las GPUs se siguen usando para el dise˜no de gr´aficos, tanto el auge de Hight Performance Computing (HPC) como de Machine Learning han ocultado su prop´osito inicial. Gracias a que contienen una cantidad inmensa de cores y la memoria est´a dise˜nada para poder acceder de forma r´apida y eficaz, se obtienen mejoras como la paralelizaci´on masiva de instrucciones. Adem´as, se consigue un gran ancho de banda para traer o llevar memoria desde la 9 Cap´ıtulo 4 MLPerf En este trabajo se ha elegido utilizar el est´andar de inferencia con MLPerf publicado en 2020 por MLCommons, un benchmark que complementa el entrenamiento de MLPerf. Lanzada la parte de inferencia en 2019 [11], se han aportado m´as de 3500 resultados por parte de la comunidad, con m´as de 100 configuraciones distintas pasando por distintas CPUs, GPUs, FPGAs y otro tipo de aceleradores. Hecho para investigaci´on, contiene una serie de modelos de c´odigo abierto de distintos tipos como segmentaci´on de im´agenes en el ´ambito m´edico, reconocimiento autom´atico de voz o autocompletado de frases, entre otros, que nos permite contrastar rendimiento. Estos son: Bert, Rnnt, 3d-Unet, GPTJ, DLRMV2, Resnet50 y Retinanet. Entre las versiones disponibles, se ha decidido utilizar la ´ultima en el momento de inciar este trabajo, la 3.1. 4.1. Estructura general y escenarios Si no se comenta nada, parece que MLPerf es el encargado de realizar todo el trabajo de inferencia, pero no es as´ı. Para poder medir el rendimiento utiliza el modelo LoadGen [1] esquematizado en la figura 4.1, el cual, a partir del sistema sobre el que queremos ejecutar (System Under Test o SUT), escenario y configuraci´on especificada, genera el tr´afico necesario para la ejecuci´on del modelo. Adem´as es el encargado de medir ciertos par´ametros como latencia o muestras por segundo. El orden en el que trabaja con el benchmark es que este le dice el conjunto de datos del modelo con el que trabajar y LoadGen genera las peticiones con las muestras. Una vez acabado LoadGen le responde con los resultados obtenidos. Figura 4.1: Representaci´on del modelo LoadGen. [1] 16 MLPerf LoagGen ofrece una serie de escenarios que simulan distintos entornos de trabajo donde se puede aplicar inferencia en nuestro SUT: Offline, Server, SingleStream y MultiStream. La diferencia entre ellos es la forma en la que reciben los datos de entrada (batch) y reportan el resultado. Offline simula una aplicaci´on de procesamiento de muestras, recibe una petici´on al sistema con todas las muestras y una vez realizado el proceso, devuelve el resultado en cualquier orden. Ejemplo de esto puede ser encontrar el n´umero de personas que hay en una fotograf´ıa. Para la medici´on de rendimiento se usan peticiones procesadas por segundo (queries per second or qps). En el modo Server, en cambio, llegan los datos usando una distribuci´on Poisson, la cual se asemeja a los datos recibidos com´unmente por un servidor, por lo que la unidad para medir tiempo vuelve a ser qps. Aqu´ı la latencia es importante, ya que al igual que hacemos consultas por internet conect´andonos a un servidor, queremos que vaya r´apido. Por esto el SUT responde a cada muestra en un rango de 15 a 250 milisegundos, y s´olo un percentil de uno de las muestras procesadas pueden pasarse del tiempo m´aximo para que el resultado siga siendo v´alido. En SingleStream llega una muestra por petici´on, la cu´al debe finalizar la ejecuci´on para que se env´ıe la siguiente. Debido a la importancia de la latencia, para medir el rendimiento se mide con el percentil 90 del tiempo en el que se ha llevado a cabo. Por ´ultimo, en MultipleStream llegan varias muestras por petici´on con una frecuencia fijada antes de empezar el proceso. La inferencia se debe completar entre 50 y 100 milisegundos dependiendo del modelo, por lo que se reporta la latencia de tantas muestras como haya dado tiempo a realizarse en el tiempo acordado. Se trabaja por intervalos, de forma que si se est´a procesando la petici´on anterior y se acaba el l´ımite, las dem´as muestras saltan un intervalo. Para que la ejecuci´on sea v´alida ocurre lo mismo que con Server, s´olo un uno por ciento de las muestras pueden no cumplir el plazo. Scenario Query Generation Duration Samples / query Latency Constraint Tail Latency Performance Metric Single stream LoadGen sends next query as soon as SUT completes the previous query 1024 queries and 60 seconds 1 None 90 % 90 %-ile measured latency Multiple stream (1.1 and earlier) LoadGen sends a new query every latency constraint if the SUT has completed the prior query, otherwise the new query is dropped and is counted as one overtime query 270,336 queries and 60 seconds Variable, see metric Benchmark specific 99 % Maximum number of inferences per query supported Multiple stream (2.0 and later) Loadgen sends next query, as soon as SUT completes the previous query 270,336 queries and 600 seconds 8 None 99 % 99 %-ile measured latency Server LoadGen sends new queries to the SUT according to a Poisson distribution 270,336 queries and 60 seconds 1 Benchmark specific 99 % Maximum Poisson throughput parameter supported Offline LoadGen sends all queries to the SUT at start 1 query and 60 seconds At least 24,576 None N/A Measured throughput Tabla 4.1: Caracter´ısticas de los modos de MLPerf. [5] 17 MLPerf Los cuatro modos de ejecuci´on cumplen una serie de restricciones que deben cumplir para que la ejecuci´on sea v´alida, encontradas en el fichero text tuning guide.md en la carpeta de documentaci´on. En todos ellos la duraci´on m´ınima (min duration) debe de ser de 600 segundos, 60 si se utiliza el flag ’--fast’. Todos deben cumplir que, de forma respectiva, los offline expected qps, server target qps, single stream expected latency ns y multi stream expected latency ns sean mayores que los a˜nadidos en el fichero de configuraci´on. Adem´as se deben de cumplir un n´umero m´ınimo de consultas fijado por defecto en 24576 para Offline, 270336 para Server, 1024 para SingleStream y 270336 para MultiStream. A pesar de estas restricciones, a´un existe un considerable margen de optimizaci´on en la configuraci´on, permitiendo, por ejemplo, sacrificar algo de exactitud a favor de menor latencia. MLPerf nos ofrece dos v´ıas: closed, que es algo m´as restringida pero m´as f´acil de configurar, y open, que permite mayor flexibilidad en los l´ımites de cada modelo. En este estudio se utilizar´a la opci´on closed. MLCommons intenta asemejarse en todo lo posible a casos reales, por lo que divide la calidad de servicio en varios sistemas: HPC, Edge, Datacenter, Tiny y Mobile. En nuestro caso, al usar la versi´on de la Jetson Orin-AGX entra en el ´ambito de sistemas Edge, mientras que la A30 pertenece a Datacenter. Docker Tanto para la preparaci´on del entorno como para ejecuci´on de los modelos, MLPerf utiliza Docker. Docker es una plataforma software que, mediante la creaci´on de contenedores, parecidos a m´aquinas virtuales, nos permite ejecutar y depurar los errores de forma sencilla. Los ’Makefile’ que se nos proporciona ya est´an creados para utilizar este software, as´ı como el almacenamiento de los modelos al que apunten la variable de entorno MLPERF SCRATCH PATH necesarias para la ejecuci´on, como se indica en la documentaci´on. 4.2. Modelos disponibles 4.2.1. BERT El modelo de lenguaje BERT (Bidirectional Encoder Representations from Transformers) [2], representado en la figura 4.2, enmascara aleatoriamente ciertas palabras del mensaje de entrada que recibe y, a trav´es del contexto, intenta predecir con la mayor exactitud posible la palabra enmascarada. Este modelo mejora a otros de su mismo prop´osito ya que fusiona el contexto izquierdo y el derecho, adem´as de trabajar mediante pares de oraciones. Por el momento s´olo trabaja con texto en ingl´es. Est´a compuesto por dos fases: pre-entreno y fine-tuning. El pre-entreno, a trav´es de tareas diferentes genera una serie de datos; estos son pasados a la tarea fine-tuning para conseguir ajustar el modelo. 18 MLPerf Figura 4.2: Mapa conceptual de las fases del modelo BERT. [2] 4.2.2. RNN-T RNN-T (Recurrent Neural Network-Transducer) [12] es un modelo de reconocimiento autom´atico de voz. El modelo propuesto por Alex Graves funciona secuencia a secuencia y est´a formado de 3 componentes: un codificador ac´ustico que recibe unos datos de entrada y genera una representaci´on de alto nivel, una red de predicci´on y un mezclador que une los resultados de los dos pasos anteriores. 4.2.3. 3D-Unet El modelo 3D-Unet [3] es una red neuronal convolucional dise˜nada en 2015, usada para la divisi´on de im´agenes en 3D en el ´ambito biom´edico. Esto significa que la red recibe una serie de im´agenes para ser entrenada y, mediante operaciones matem´aticas como pueden ser operaciones matriciales, produce un resultado. Esto se asemeja mucho a la idea de aplicar un filtro a una imagen. Est´a formada por 2 partes, ambas con 4 capas de nodos: la codificadora, a trav´es de la cual se eligen los datos que nos interesan, y la descodificadora, que har´a las operaciones inversas de la convoluci´on para la generaci´on del resultado. La capas convolucionales de este modelo son esbozadas en la figura 4.3. 19 MLPerf Figura 4.3: Capas convolucionales del modelo 3D-Unet. [3] 4.2.4. ResNet50 ResNet-50 (Residual Network) [13] es una red convolucional con 50 capas, capaz de clasificar fotograf´ıas en alrededor de 1000 categor´ıas distintas como puede ser diferenciar animales. Est´a formada por 48 capas convolucionales, 1 capa MaxPool, basada en dividir la imagen y reducirla eligiendo el valor m´as alto de cada rect´angulo, y una ´ultima capa pool que saca el promedio. 4.2.5. RetinaNet RetinaNet [4] es un modelo de una sola fase de detecci´on de objetos mediante una operaci´on de p´erdida focal. Usado para im´agenes a´ereas y de sat´elite, se realiza una red piramidal (FPN) sobre el resultado de aplicar ResNet a la imagen de entrada. Esta pir´amide, representada en la figura 4.4, est´a compuesta de anchor boxes [14]. Se trata de una t´ecnica usada en la detecci´on de objetos basada en una serie de cajas o anchor boxes predefinidas seg´un los datos de entrada, a los que el modelo atribuye una serie de atributos como la probabilidad de encontrar el objeto. Despu´es se ponen en marcha otras dos subredes: una clasificaci´on de anchor boxes y una regresi´on sobre las capas de la pir´amide. 20 MLPerf Figura 4.4: Representaci´on de red piramidal con las dos subredes propuesta por Retinanet. [4] 4.2.6. GPT-J Generado por EleutherAI, GPT-J (Generative Pre-trained Transformer)[15] es un modelo con c´odigo abierto de generaci´on de texto en ingl´es a partir de un texto de entrada. La complejidad del modelo al contener 28 capas, tener 6 mil millones de par´ametros y haber sido entrenado por una cantidad masiva de datos (modelo de entrenamiento llamado The Pile [16] de 825GiB), permite generar texto de forma creativa. Cabe destacar que s´olo funciona para texto en ingl´es y, aunque utiliza la misma tecnolog´ıa de transformaci´on de lenguaje, no es lo mismo que el famoso modelo ChatGPT, ya que este ´ultimo utiliza un n´umero mucho menor de par´ametros (alrededor de medio mill´on en el caso de ChatGPT-4). 4.2.7. DLRMV2 DLRMv2 (Deep Learning Recommendation Model) es un modelo de recomendaci´on dise˜nado para hacer uso tanto de datos num´ericos como categ´oricos. Est´a dise˜nado para poder entrenar modelos que sean demasiado grandes para una sola GPU y trabaja con cualquier tipo de conjunto de datos. Al ya conocer todos los modelos, podemos definir a qu´e corresponde una petici´on o querie en uno de ellos. En caso de Resnet, Retinanet, 3d-unet una consulta se refiere a una sola im´agen, mientras que en Bert y GPT-J es una frase, en Rnnt un audio de hasta 15 segundos y en DLRMV2 hasta 700 pares de datos usuario-elemento. 21 Cap´ıtulo 5 Medici´on de potencia Para la medici´on de potencia se ha usado el software PMLib (ejemplo en el ap´endice B) proporcionado por el departamento DACYA de la UCM, integr´andolo en la infraestructura de MLPerf. Dise˜nado como un sistema cliente-servidor, PMLib es capaz de hacer uso de diversos mecanismos de medici´on de consumo o medidores externos de forma transparente al usuario. Espec´ıficamente, PMLib despliega un servidor en la m´aquina destino que, con previa configuraci´on para su adaptaci´on al sistema de medici´on pertinente, ofrece mediante sockets (por defecto, escuchando en el puerto 6521) los servicios necesarios para establecer contadores de consumo. La parte cliente, que puede desplegarse de forma interactiva en cualquier equipo externo al de medici´on mediante el comando pm info, o bien instrumentando c´odigo, realiza las pertinentes conexiones contra dicho servidor, recogiendo los datos y proporcionandolos en forma de ficheros de texto que pueden a posteriori ser analizados. 5.1. Servidor En nuestro caso, el servidor PMLib ha interactuado utilizando dos mecanismos distintos de recogida de muestras para medici´on de consumo, adapt´andose de forma espec´ıfica a las herramientas disponibles en cada una de las dos m´aquinas disponibles. 5.1.1. NVIDIA A30 La infraestructura proporcionada por NVIDIA para la medici´on de consumo en GPUs discretas (como es la A30) es la biblioteca NVML (NVIDIA Management Library). NVML proporciona una API completa para la interacci´on desde programas (inicialmente en lenguaje C) para gestionar y consultar multitud de par´ametros proporcionados por el panel de control nvidia-smi. Entre estas caracteristicas, se encuentra la medici´on instant´anea de potencia. En nuestro caso, ya que la infraestructura PMLib est´a desarrollada en Python, se ha hecho uso de la biblioteca pyNVML proporcionada por la propia compa˜n´ıa. Espec´ıficamente, se ha desarrollado un plugin para PMLib que, de forma constante (en funci´on de la frecuencia de muestreo solicitada por el usuario), realiza peticiones al panel de control utilizando la infraestructura NVML. Previamente al desarrollo del plugin, se ha a˜nadido un fichero de configuraci´on (settings.py) en el que se define tanto la m´aquina a utilizar, como el medidor de consumo (de tipo NVMLDevice) del que se desea hacer uso: from daemon . d evices import ∗ from daemon . modules import ∗ #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 22 Medici´on de potencia # General s e c t i o n #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # IP and Port in which the daemon w i l l be l i s t e n i n g ( d e f aul t : 6526) IP=” 0 . 0 . 0 . 0 ” PORT=6526 # Log f i l e name ( d e f a u l t : ”/ var / l og /powermeter . l o g ”) LOGFILENAME=” . / powermeter . l o g ” path =”.” #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # Computers s e c t i o n #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− OCEJON = Computer . Computer ( name=”OCEJON” , ip=” 0 . 0 . 0 . 0 ” ) #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # Devices s e c t i o n #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− A30 dev = NVMLDevice( name = ”NVMLDevice” , computer = OCEJON, u r l=”” , max frequency=100) A30 dev . a d d l i n e ( number=0, name=”NVML OCEJON” , v ol tag e =12 , d e s c r i p t i o n=”NVML OCEJON” ) La clase NVMLDevice realiza la interaccion con la biblioteca NVML de forma constante en su m´etodo read, que es invocado peri´odicamente por la infraestructura. Espec´ıficamente, obs´ervese en el siguiente c´odigo c´omo se crea una ´unica l´ınea de lectura de potencia, cuyo valor es de retorno de la invocaci´on a la funci´on nvmlDeviceGetPowerUsage proporcionado por pyNVML: #−∗− coding : utf −8−∗− #====================================================================== # NVMLDevice c l a s s #====================================================================== import Device import pexpect import time from pynvml import ∗ ## An NVML d ev ic e d e s c r i p t i o n class NVMLDevice( Device . AttachedDevice ) : ## Creates a NVML de vi ce d e s c r i p t i o n and adds i t to the d ev i c es ## dictionary # # @param [ in ] name The d evic e name ( used f or i d e n t i f i c a t i o n , must be unique ) # @param [ i n ] u r l The u r l o f t h i s d ev ic e # @param [ in ] max frequency The maximum sample frequency o f the device # def i n i t ( s e l f , name , computer , url , max frequency ) : s e l f . n l i n e s = 1 s e l f . handle= [ 0 ] ∗s e l f . n l i n e s nvmlInit() f o r iin range ( 0 , s e l f . n l i n e s ) : s e l f . handle [ i ] = nvmlDeviceGetHandleByIndex ( i ) super(NVMLDevice , s e l f ) . i n i t (name , computer , url , max frequency ) def read ( s e l f ) : power= [ 0 ] ∗s e l f . n l i n e s 23 Medici´on de potencia t muestra = s e l f . max frequency ∗ ∗ −1 while s e l f . running : t1 = time . time ( ) power [ 0 ] = nvmlDeviceGetPowerUsage ( s e l f . handle [ 0 ] ) y i e l d power w = t muestra −( time . time ( ) −t1 ) i f ( w >0 ) : time . s l e e p (w) A partir de este punto, y tras desplegar el servidor en segundo plano, ser´a posible realizar una interacci´on con el mismo, creando contadores de consumo sobre dicha l´ınea para consultar los valores de potencia instant´anea asociados a la NVIDIA A30. 5.1.2. Jetson AGX En este caso, la infraestructura NVML no est´a disponible para su uso. Sin embargo, NVIDIA proporciona una serie de dispositivos de medici´on de consumo (sensores de efecto Hall INA 231 de Texas Instruments), que se exponen a trav´es de ficheros en el arbol de directorios de Linux para su consulta. Espec´ıficamente, nuestra soluci´on hace uso de los monitorizaci´on que ofrecen las m´aquinas NVIDIA [17], realizando una recopilaci´on de medidas de forma peri´odica sobre la m´aquina que se le indique. La Jetson AGX contiene 2 monitorizaciones de 3 canaless I2C, trabajando a trav´es de la lectura de una serie de sensores a trav´es de unos ficheros de texto encontrados en los siguientes directorios: /sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon[x] /sys/bus/i2c/drivers/ina3221/1-0041/hwmon/hwmon[y] Los dispositivos 0x40 y 0x41 corresponden con las direcciones donde se encuentran los monitores de potencia. Cada uno de estos ficheros corresponden a una ’l´ınea’ o tipo de medici´on, siendo capaces de poder configurar qu´e l´ıneas leer desde el fichero settings.py: #====================================================================== # PowerMeter daemon s e t t i n g s #====================================================================== from daemon . d evices import ∗ from daemon . modules import ∗ #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # General s e c t i o n #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # IP and Port in which the daemon w i l l be l i s t e n i n g ( d ef a u lt : 6526) IP=” 0 . 0 . 0 . 0 ” PORT=6526 # Log f i l e name ( d e f a u l t : ”/ var / l og / powermeter . l o g ”) LOGFILENAME=” . / powermeter . l o g ” path =”.” #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # Computers s e c t i o n #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ORIN = Computer . Computer ( name=”ORIN” , ip=” 0 . 0 . 0 . 0 ” ) 24 Medici´on de potencia #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # Devices s e c t i o n #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ORINAGX dev = ORINAGXDevice( name = ”ORINAGXDevice” , computer = ORIN, u r l=”” , max frequency=100) ORINAGX dev . a d d l i n e ( number=0, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=1, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=2, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=3, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=4, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=5, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=6, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=7, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=8, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=9, name=”AGX” , v ol t ag e =12, d e s c r i p t i o n=”AGX” ) ORINAGX dev . a d d l i n e ( number=10 , name=”AGX” , v ol tag e =12, d e s c r i p t i o n=”AGX” ) Obs´ervese que se a˜naden 11 l´ıneas que ser´an expuestas a los usuarios. Espec´ıficamente, estas l´ıneas corresponden a mediciones de voltaje y amperaje para cada uno de los posibles dispositivos de inter´es. V´ease la definici´on de la clase ORINAGXDevice para observar c´omo se extraen y combinan dichas l´ıneas (obs´ervese que, en este caso, la interacci´on con los sensores se realiza abriendo y leyendo constantemente ficheros de texto): #−∗− coding : utf −8−∗− #====================================================================== # PDUDevice c l a s s #====================================================================== import Device import pexpect import time ## An ORINNANO d ev ic e d e s c r i p t i o n class ORINAGXDevice( Device . AttachedDevice ) : ## Creates a ORINAGX d ev ic e d e s c r i p t i o n and adds i t to the d e vi ce s ## dictionary # # @param [ in ] name The d evic e name ( used f or i d e n t i f i c a t i o n , must be unique) # @param [ i n ] u r l The u r l o f t h i s d ev ic e # @param [ in ] max frequency The maximum sample frequency o f the device # def i n i t ( s e l f , name , computer , url , max frequency ) : s e l f . n l i n e s = 11 super(ORINAGXDevice , s e l f ) . i n i t (name , computer , url , max frequency ) def read ( s e l f ) : power= [ 0 ] ∗s e l f . n l i n e s t muestra = s e l f . max frequency ∗ ∗ −1 while s e l f . running : t1 = time . time ( ) power [ 0 ] = float(open (”/ s ys / bus / i 2c / d r i v e r s / ina3221 /1−0040/hwmon/hwmon3/ curr1 input”,”rb” ) . read ( ) ) power [ 1 ] = float(open (”/ s ys / bus / i 2c / d r i v e r s / ina3221 /1−0040/hwmon/hwmon3/ i n 1 input ”,”rb ” ) . read ( ) ) power [ 2 ] = float(open (”/ s ys / bus / i 2c / d r i v e r s / ina3221 /1−0040/hwmon/hwmon3/ curr2 input”,”rb” ) . read ( ) ) power [ 3 ] = float(open (”/ s ys / bus / i 2c / d r i v e r s / ina3221 /1−0040/hwmon/hwmon3/ i n 2 input ”,”rb ” ) . read ( ) ) power [ 4 ] = float(open (”/ s ys / bus / i 2c / d r i v e r s / ina3221 /1−0040/hwmon/hwmon3/ 25 Cap´ıtulo 7 Resultados Obtenidos Como se ha comentado, en el estudio se analiza el throughput, que en este caso equivale a los qps, la latencia y el rendimiento energ´etico en cada uno de los modelos. 7.1. Bert 7.1.1. Throughput En el caso del throughput nos tenemos que hacer la pregunta de d´onde est´an los l´ımites de las peticiones procesadas de cada m´aquina, si difieren entre ellas y en cu´anto. Figura 7.1: Throughput hallado por cada valor de batch en el modelo Bert. 32 Resultados Obtenidos En este modelo nos encontramos con unos l´ımites de rendimiento muy claros como se ve en la figura 7.1, estabiliz´andose antes cuanto menor es la potencia m´axima. Adem´as vemos un claro aumento en los qps cuanto mayor es esta potencia, alcanzando 1531 qps en la A30 con un batch 70, 512 con batch 30 en la Jetson Orin AGX y 67 qps con batch 20 al limitar la AGX a 15W. 7.1.2. Eficiencia Energ´etica Aunque las GPUs no est´en en funcionamiento sabemos que sigue habiendo un consumo est´atico por estar conectada a la corriente. En el caso de la A30 est´a en 31.5 W y, por parte de la Orin, la suma de CPU, GPU y otras consumos ronda los 6.5W, sin importar que est´e capada la potencia m´axima. Para hallar la eficiencia energ´etica primero debemos conocer el gasto de potencia en cada una de las m´aquinas con distintos valores de batch. Para estos valores se han tomado los siguientes valores de batch: 1, 20 y 70. Figura 7.2: Potencia consumida en cada batch por el modelo Bert en NVIDIA A30. 33 Resultados Obtenidos Figura 7.3: Potencia consumida en cada batch por el modelo Bert en Jetson Orin AGX. Figura 7.4: Potencia consumida en cada batch por el modelo Bert en Jetson Orin AGX con 15W potencia m´axima. As´ı como en la A30 (ver gr´afica 7.2) se ve como, por mucho que se var´ıe el batch recibido, la potencia m´axima consumida es la m´axima con 165W, no pasa lo mismo en la AGX. Y es que la potencia consumida en la AGX con m´axima potencia var´ıa, y mucho, con respecto al batch indicado, como se aprecia en la figura 7.3. Llega a pasar de alrededor de 30W de media con batch 1, subiendo r´apidamente a los 50W con batch 10. No se alcanza el m´aximo de 60W ya que hay que recordar que se tienen las otras dos l´ıneas de consumo: medici´on de CPU y de subsistema de memoria. En cambio, al capar la m´aquina a 15W no se dispone de mucho margen de mejora debido a que, de forma m´as dr´astica que el caso anterior, el consumo de las otras dos l´ıneas de consumo limitan la potencia consumida. A´un as´ı se puede apreciar una peque˜na mejora de alrededor de un watio entre las ejecuciones con batch 1 y 70. Esto se observa en la figura 7.4. Ya vistos los gastos de potencia, pasamos a lo que nos interesa: la eficiencia energ´etica. Para ello se crea la tabla 7.1, en la que se disponen los distintos n´umeros de batch de referencia en cada una de las m´aquinas utilizadas. Batch M´aquina NVIDIA A30 Jetson Orin AGX Jetson Orin AGX 15W 1666.422 / 163.842 = 4.068 185.116 / 29.985 = 6.173 38.389 / 5.781 = 6.640 20 1469.62 / 164.123 = 8.957 502.88 / 51.551 = 9.755 65.5127 / 6.580 = 9.955 70 1531.75 / 164.097 = 9.9337 534.112 / 53.787 = 9.931 66.8021 / 6.589 = 10.138 Tabla 7.1: Comparaci´on de latencia entre diferentes m´aquinas y tama˜nos de batch para Bert. De aqu´ı se sacan dos conclusiones: en primer lugar, para un tama˜no de batch peque˜no da lo esperado, la NVIDIA A30 es menos eficiente al no tener suficientes datos a analizar y consumir la m´axima potencia. Pero, sorprendentemente, los datos que se muestran al utilizar un batch de gran tama˜no indican que el aumento de los qps en la NVIDIA A30 no es suficiente para contrarrestar la potencia consumida. 34 Resultados Obtenidos 7.1.3. Latencia Siendo Bert el ´unico modelo en el que no se ha utilizado la opci´on --fast para acelerar el c´omputo en la AGX, la diferencia de latencia entre las m´aquina es m´ınima como se ve en la 7.5. Figura 7.5: Latencia en cada batch para el modelo Bert. 35 Resultados Obtenidos 7.2. Resnet50 7.2.1. Throughput Al igual que con el modelo Bert, Resnet50 no var´ıa en la existencia clara de unos l´ımites marcados por el rendimiento de la m´aquina (ver figura 7.6). Estos est´an marcados alrededor del batch 200 para el caso de la A30, alcanzando m´as de 19000 qps; con un batch 70 en cuanto a AGX con 6100 peticiones por segundo y batch 7 con apenas 1340 al limitar a 15W. Figura 7.6: Throughput hallado por cada valor de batch en el modelo Resnet50. 7.2.2. Eficiencia energ´etica En cambio, Resnet50 tiene una singularidad con los dem´as modelos estudiados como se aprecia en la im´agen 7.7, y es que var´ıa la potencia consumida en la A30. Esto quiere decir que debido a la implementaci´on del modelo, con un n´umero muy peque˜no de peticiones por segundo no necesita utilizar la potencia m´axima disponible. 36 Resultados Obtenidos Figura 7.7: Potencia consumida en cada batch por el modelo Resnet50 en NVIDIA A30. Figura 7.8: Potencia consumida en cada batch por el modelo Resnet50 en Jetson Orin AGX. Figura 7.9: Potencia consumida en cada batch por el modelo Resnet50 en Jetson Orin AGX con 15W potencia m´axima. Con la AGX vemos la misma estructura que se ve´ıa en el modelo Bert con las figuras 7.8 y7.9. Se aprecia un mayor consumo de potencia al aumentar los qps hasta el l´ımite de 40W. De nuevo no hay un mayor consumo debido a que est´a siendo usado por las otras dos l´ıneas de consumo. Al calcular la eficiencia energ´etica dividiendo los qps entre potencia consumida en los puntos de batch estudiandos, de nuevo se aprecia como una mejor eficiencia en la AGX capando a 15W. Esta diferencia es mucho m´as dr´astica que en Bert, siendo m´as del doble de eficiente para batches grandes, al realizarse un mayor n´umero de qps. Los c´alculos se disponen en la tabla 7.2. Para ver la diferencia de forma gr´afica se dispone de la figura 7.10. 37 Resultados Obtenidos Batch M´aquina NVIDIA A30 Jetson Orin AGX Jetson Orin AGX 15W 11927.86 / 95.742 = 20.139 2931.51 / 18.873 = 155.308 1344.51 / 5.573 = 241.183 79213.47 / 136.516 = 67.506 5018.74 / 26.769 = 187.420 1731.59 / 6.196 = 279.470 70 18009.9 / 160.638= 112.097 6181.56 / 34.069 = 181.397 1703.14 / 6.230 = 273.408 200 19208.9 / 160.948 = 119.354 6328.86 / 35.729 = 177.202 1456.22 / 5.943= 245.059 Tabla 7.2: Comparaci´on de latencia entre diferentes m´aquinas y tama˜nos de batch para Resnet50. Figura 7.10: Eficiencia energ´etica consumida en cada batch por el modelo Resnet50. 38 Resultados Obtenidos 7.2.3. Latencia En la latencia de Resnet50, aunque se puede distinguir un ligero aumento en AGX con 15W de potencia m´axima que en la AGX, no es representativa. La comparativa de la AGX con la A30 no es representativa al haber utilizado el flag --fast, acortando as´ı el tiempo consumido por la m´aquina al realizar la inferencia. A´un as´ı se aprecia c´omo al aumentar el batch hasta llegar a los l´ımites, la latencia no var´ıa. Figura 7.11: Latencia en cada batch para el modelo Resnet50. 39 Resultados Obtenidos 7.3. Rnnt 7.3.1. Througthput En el modelo Rnnt ocurre un caso algo distinto a los otros dos modelos. Anteriormente hemos visto que cuanto m´as potente es la m´aquina se obtiene un mayor rendimineto con un n´umero de batch mayor. Pero este no es el caso de Rnnt como se aprecia en la figura 7.12. Lo que ocurre es que debido al gran aumento exponencial de qps en los batches peque˜nos de la A30, se llega antes al l´ımite en esta m´aquina que en la AGX con m´axima potencia. Esto no pasa al capar a 15W ya que el escalado es m´ınimo. Figura 7.12: Throughput hallado por cada valor de batch en el modelo Rnnt. 40 Resultados Obtenidos 7.3.2. Eficiencia energ´etica Figura 7.13: Potencia consumida en cada batch por el modelo Rnnt en NVIDIA A30. Figura 7.14: Potencia consumida en cada batch por el modelo Rnnt en Jetson Orin AGX. Figura 7.15: Potencia consumida en cada batch por el modelo Rnnt en Jetson Orin AGX con 15W potencia m´axima. Con Rnnt pasa algo parecido que con Bert, en la NVIDIA A30 (ver figura 7.13) para cualquier valor de batch se obtiene que se consume la m´axima potencia, mientras que en la AGX para batches peque˜nos se gasta alrededor de la mitad que con un batch de gran tama˜no, como se aprecia en la figura 7.14. En el caso del consumo al capar a 15W, como se ve en la figura 7.3.2, en este modelo apenas se nota diferencia energ´etica al ejecutar con valores diferentes de batch. Al ver la comparativa de eficiencia energ´etica (ver figura 7.3) se dedude que hay una p´esima eficiencia para la A30 y Jetson Orin AGX con m´axima potencia para un tama˜no de batch peque˜no. 41 Ap´endice B Ejemplo de cliente PMLib utilizando ctypes from ctypes import * import time so_file = "/ work / pmlib_orin . so" pmlib = CDLL ( so_file ) print (type( pmlib )) print (pmlib.pm_create_counter) DOUBLE_10 = c_double * 10 CHAR_1 = c_char * 1 CHAR_4 = c_char * 4 CHAR_16 = c_char * 16 ## Structure definition . class PM_MeasuresStruct ( Structure ): _fields_ = ( (" watts_size " , c_int ), (" watts_sets_size ", c_int ) , (" watts_sets " , POINTER ( c_int )) , (" watts ", POINTER ( c_double )), (" lines_len ", c_int ) ) class PM_MeasuresWTStruct ( Structure ): _fields_ = ( ("next_timing", c_int ) , ("timing", POINTER ( c_double )) , ("energy", PM_MeasuresStruct) ) class LineStruct ( Structure ): 48 _fields_ = [ ("__bits", c_char * 16) ] class DeviceStruct ( Structure ): _fields_ = ( ("name ", c_char_p ), (" max_frequency ", c_int ) , ("n_lines", c_int ) , ) class CounterStruct ( Structure ): _fields_ = ( ("sock ", c_int ), (" aggregate ", c_int ) , (" lines ", LineStruct ), #(" lines ", CHAR_16 ) , (" num_lines ", c_int ) , (" interval ", c_int ), ("pm_measures_wt", POINTER ( PM_MeasuresWTStruct )) ) class ServerStruct ( Structure ): _fields_ = ( (" server_ip ", c_char * 16) , ("port ", c_int ), ) # Main program servidor = ServerStruct () contador = CounterStruct () lineas = LineStruct ( b ’1000000000000000’) disp = DeviceStruct() # Start pm_set_lines _pm_set_lines = pmlib . pm_set_lines _pm_set_lines . argtypes = [ c_char_p , POINTER ( LineStruct )] _pm_set_lines . restype = c_int lines_string = c_char_p (b’8 -10 ’) _pm_set_lines ( lines_string , byref ( lineas )) # End pm_set_lines # Start pm_set_server _pm_set_server = pmlib.pm_set_server _pm_set_server . argtypes = [ c_char_p , c_int , POINTER ( ServerStruct )] _pm_set_server . restype = c_int ip = c_char_p (b ’127.0.0.1 ’) for field_name , field_type in servidor._fields_: 49 print ( field_name , getattr( servidor , field_name )) _pm_set_server (ip , 6526 , byref ( servidor )) for field_name , field_type in servidor._fields_: print ( field_name , getattr( servidor , field_name )) # End pm_set_server # Start pm_create_counter _pm_create_counter = pmlib.pm_create_counter _pm_create_counter . argtypes = [c_char_p , LineStruct , c_int ,c_int , ServerStruct , POINTER ( CounterStruct )] _pm_set_server . restype = c_int # device_name = c_char_p (b ’ORINNANODevice ’) device_name = c_char_p (b ’ORINAGXDevice ’) # device_name = c_char_p (b ’NVMLDevice ’) _pm_create_counter ( device_name , lineas , 0, 0, servidor , byref( contador )) # End pm_create_counter # Start pm_start_counter _pm_start_counter = pmlib.pm_start_counter _pm_start_counter . argtypes = [ POINTER ( CounterStruct )] _pm_start_counter . restype = c_int _pm_start_counter ( byref ( contador )) # End pm_start_counter time . sleep (1) # Start pm_stop_counter _pm_stop_counter = pmlib . pm_stop_counter _pm_stop_counter . argtypes = [ POINTER ( CounterStruct )] _pm_stop_counter . restype = c_int _pm_stop_counter ( byref ( contador )) # End pm_stop_counter # Start pm_get_counter_data _pm_get_counter_data = pmlib.pm_get_counter_data _pm_get_counter_data . argtypes = [ POINTER ( CounterStruct )] _pm_get_counter_data.restype = c_int _pm_get_counter_data(byref(contador)) # End pm_get_counter_data # Start pm_print_data_csv 50 _pm_print_data_csv = pmlib.pm_print_data_csv _pm_print_data_csv . argtypes = [ c_char_p , CounterStruct , LineStruct , c_int ] _pm_print_data_csv . restype = c_int file_name = c_char_p (b ’test. csv ’) _pm_print_data_csv ( file_name , contador , lineas , -1) # End print_data_csv # Start pm_stop_counter _pm_finalize_counter = pmlib.pm_finalize_counter _pm_finalize_counter . argtypes = [ POINTER ( CounterStruct )] _pm_finalize_counter.restype = c_int _pm_finalize_counter(byref(contador)) # End pm_stop_counter 51 Bibliograf´ıa [1] Arjun Suresh y Pablo Gonzalez. Loadgen. https://github.com/mlcommons/inference/ tree/master/loadgen. (visitado 14-03-2024). [2] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT: Pretraining of Deep Bidirectional Transformers for Language Understanding. 2:16, May 2019. https://paperswithcode.com/method/bert. [3] Philipp Fischer Olaf Ronneberger and Thomas Brox. U-net: Convolutional networks for biomedical image segmentation. 1:8, Nov 2015. [4] Tsung-Yi Lin Priya Goyal Ross Girshick Kaiming He Piotr Dollar. Focal loss for dense object detection. page 10, Feb 2018. [5] MLCommons. Scenarios and metrics of mlperf. https://mlcommons.org/benchmarks/ inference-edge/. (visitado 24-05-2024). [6] Gordon E. Moore. Cramming more components onto integrated circuits. Electronics, 38(8):114– 117, 1965. [7] NVIDIA. Nvidia a30. https://www.nvidia.com/es-es/data-center/products/a30-gpu/. (visitado 29-05-2024). [8] Nvidia. Nvidia jetson orin. https://www.nvidia.com/es-es/autonomous-machines/ embedded-systems/jetson-orin/. (visitado 01-05-2024). [9] Intel. Procesador intel®xeon®silver 4314. https://ark.intel.com/content/www/xl/es/ ark/products/215269/intel-xeon-silver-4314-processor-24m-cache-2-40-ghz.html. (visitado 24-05-2024). [10] NVIDIA. Nvpmodel. https://docs.nvidia.com/jetson/archives/ r34.1/DeveloperGuide/text/SD/PlatformPowerAndPerformance/ JetsonOrinNxSeriesAndJetsonAgxOrinSeries.html#supported-modes-and-power-efficiency. (visitado 30-04-2024). [11] Reddi V.J. et al. Mlperf inference benchamrk. page 14, may 2020. [12] Alex Graves. Sequence transduction with recurrent neural networks. 1:9, Nov 2012. [13] Shaoqing Ren Jian Sun Kaiming He, Xiangyu Zhang. Deep residual learning for image recognition. page 12, Dec 2015. [14] MathWorks. Anchor boxes. https://es.mathworks.com/help/vision/ug/ anchor-boxes-for-object-detection.html. (visitado 03-05-2024). [15] Ben Wang and Aran Komatsuzaki. GPT-J-6B: A 6 Billion Parameter Autoregressive Language Model. https://github.com/kingoflolz/mesh-transformer-jax, May 2021. 52 [16] Sid Black Laurence Golding Travis Hoppe Charles Foster Jason Phang Horace He Anish Thite Noa Nabeshima Shawn Presser Connor Leahy Leo Gao, Stella Biderman. The pile: An 800gb dataset of diverse text for language modeling. page 39, Dec 2020. [17] NVIDIA. Canales de monitorizaci´on de potencia. https://docs.nvidia.com/ jetson/archives/r34.1/DeveloperGuide/text/SD/PlatformPowerAndPerformance/ JetsonOrinNxSeriesAndJetsonAgxOrinSeries.html#jetson-agx-orin-series. (visitado 1-05-2024). [18] Academic Torrents. Imagenet torrents. https://academictorrents.com/browse.php? search=imagenet&sort_field=seeders&sort_dir=DESC. (visitado 05-04-2024). 53