From c9e0d723c80b5e2dc62ae0dd9be4714fd5186afd Mon Sep 17 00:00:00 2001 From: Quarto GHA Workflow Runner Date: Thu, 6 Jun 2024 14:10:53 +0000 Subject: [PATCH] Built site for gh-pages --- .nojekyll | 2 +- III-Deploiements/3_Socle_Production.html | 4 ++-- search.json | 4 ++-- sitemap.xml | 24 ++++++++++++------------ 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/.nojekyll b/.nojekyll index abd35ad..a65e604 100644 --- a/.nojekyll +++ b/.nojekyll @@ -1 +1 @@ -2c22d3a3 \ No newline at end of file +794991cb \ No newline at end of file diff --git a/III-Deploiements/3_Socle_Production.html b/III-Deploiements/3_Socle_Production.html index 705ad8f..65611c5 100644 --- a/III-Deploiements/3_Socle_Production.html +++ b/III-Deploiements/3_Socle_Production.html @@ -352,7 +352,7 @@

C. Exemple de d spec: containers: - name: fastchat-controller - image: 10.156.254.10:8082/llm-api-light:1.0.0 + image: llm-api-light:1.0.0 imagePullPolicy: IfNotPresent ports: - containerPort: 21001 @@ -394,7 +394,7 @@

C. Exemple de d spec: containers: - name: fastchat-openai - image: 10.156.254.10:8082/llm-api-light:1.0.0 + image: llm-api-light:1.0.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8000 diff --git a/search.json b/search.json index 2ac8d45..995c79b 100644 --- a/search.json +++ b/search.json @@ -4,7 +4,7 @@ "href": "III-Deploiements/3_Socle_Production.html", "title": "PARTIE III. Deploiements", "section": "", - "text": "Les LLM sont des modèles de langage puissants qui nécessitent des ressources informatiques importantes pour fonctionner efficacement. Pour mettre en production une application utilisant des LLM, il est essentiel de choisir le bon matériel et les bons outils pour garantir la disponibilité des applications et des performances optimales.\nPour certains modèles de langage, les processeurs habituels appelés CPU (Central Processing Unit) peuvent suffire. Mais pour la plupart des modèles plus importants, pour que les calculs se fassent dans des temps raisonnables, il est nécessaire de se doter d’unités de traitement graphique (GPU). Nous allons donc nous intéresser ici aux différents critères à étudier pour choisir correctement des GPUs, aux outils qui permettent de suivre leurs performances et enfin le lien avec les essentiels de déploiements en termes de management de ressources (avec l’exemple du lien à Kubernetes).\n\n\nLa sélection des GPU (Graphics Processing Units) pour une installation dans une structure dépend de multiples facteurs. En voici quelques uns :\n\nPuissance de calcul : La puissance de traitement des GPU est mesurée en flops (floating-point operations per second). Un GPU plus puissant permettra d’exécuter des tâches plus rapidement et de gérer des charges de travail plus élevées.\nMémoire vive : La mémoire vive (VRAM) des GPU est essentielle pour les applications nécessitant une grande quantité de mémoire, comme les simulations scientifiques ou les applications de traitement d’image. Assurez-vous de choisir des GPU avec suffisamment de mémoire vive pour répondre aux besoins de vos applications.\nÉnergie et consommation : Les GPU consomment de l’énergie et génèrent de la chaleur. Choisissez des GPU économes en énergie et dotés de systèmes de refroidissement efficaces pour réduire les coûts énergétiques et améliorer la durée de vie des composants.\nCoût et rentabilité : Évaluez le coût total de possession (TCO) des GPU, en tenant compte des coûts d’achat, de maintenance et d’énergie. Choisissez des GPU qui offrent une bonne rentabilité pour votre administration.\nCompatibilité avec les systèmes d’exploitation : Vérifiez que les GPU sont compatibles avec les systèmes d’exploitation utilisés dans votre administration, tels que Windows, Linux ou macOS.\n\nPour le dernier point, il est commun d’acheter les GPUs par plusieurs, déjà groupés dans des serveurs. Il faut faire attention cependant au format et aux besoins spécifiques de ces serveurs, qui ne sont souvent pas standards par leur taille et par la chaleur qu’ils dégagent.\nDes GPUs reconnus peuvent être les T5, A100, V100 et leur prix d’achat est de l’ordre de milliers d’euros, mais il faut bien prendre en compte également les coûts cachés. En effet, l’intégration dans un SI pré-existant peut nécessiter des travaux. Durant leur cycle de vie, ils ont besoin de maintenance. Et enfin, tout au long de leur utilisation, ils ont besoin d’être administrés, ce qui peut représenter des Equivalents Temps Plein (ETP), dont le coût n’est pas à négliger.\n\n\n\nIl est judicieux d’utiliser un orchestrateur pour déployer des Language Models (LLMs) dans une organisation pour plusieurs raisons :\n\nSimplification de la gestion des déploiements : un orchestrateur permet de gérer de manière centralisée tous les déploiements de LLMs dans l’organisation. Cela facilite la surveillance, la maintenance et la mise à l’échelle des déploiements.\nÉvolutivité : un orchestrateur permet de mettre à l’échelle automatiquement les déploiements en fonction de la demande, ce qui est particulièrement utile pour les LLMs qui peuvent être très gourmands en ressources.\nSécurité : un orchestrateur peut aider à renforcer la sécurité en fournissant des fonctionnalités telles que l’authentification, l’autorisation et le chiffrement des données. Il peut également aider à respecter les normes de conformité en matière de traitement des données.\nGestion des versions : un orchestrateur permet de gérer les versions des LLMs et de faciliter le déploiement de nouvelles versions ou de rollbacks en cas de problème.\nIntégration avec d’autres outils : un orchestrateur peut s’intégrer facilement avec d’autres outils de développement et d’exploitation, tels que les systèmes de surveillance, les outils de débogage et les systèmes de journalisation.\nRéduction des coûts : en automatisant les déploiements et en les mettant à l’échelle de manière efficace, un orchestrateur peut aider à réduire les coûts associés aux déploiements de LLMs.\n\nEn résumé, un orchestrateur offre une gestion centralisée, une évolutivité, une sécurité renforcée, une gestion des versions, une intégration avec d’autres outils et une réduction des coûts pour les déploiements de LLMs dans une organisation. Des solutions techniques peuvent être :\n\nKubernetes\nDocker Swarm\nApache Mesos\n\n\n\n\nNous allons développer dans cette partie un exemple de déploiement d’une structure LLM avec Kubernetes. On utilise la même structure de microservices que dans la partie précedente avec FastChat mais cela peut être adapté à tout choix d’organisation et d’architecture.\nVoici un schéma résumant l’organisation proposée ici, avec le controller, l’api openai-like et deux modèles LLMs :\n\n\n\nSchéma de structure des services pour Kubernetes\n\n\nLa méthodologie générale de l’utilisation de Kubernetes est la suivante :\n\nPréparer les images Docker qui seront utilisées pour les déploiements\nCréez les fichiers de configuration YAML pour votre application\nDéployez les avec :\n\nkubectl apply -f FILENAMES.yaml\n\nSurveiller le lancement des différents services et leur bonne interconnexion\n\nAvec cela, vous avez une application plus robuste, mais cela necessite une certaine familiarité avec Kubernetes. Quelques exemples de fichiers de configuration sont proposés ci-dessous.\n\nTout d’abord les services obligatoires comme le gestionnaire de l’API et le controlleur. On fait en même temps le deployment du pod et le service permettant d’y accéder. Ils se basent sur une image Docker légère et sans requirements spécifiques.\n\nOn remarquera que les deux deploiments semblent assez similaires et que la principale différence réside dans les noms donnés aux objets et à la commande lancée dans le conteneur lancé :\n[\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\nou\n[\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\nCes commandes sont celles de FastChat mais peuvent être remplacées par votre propre solution de déploiement de modèle.\nPour le controlleur :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-controller\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-controller\n template:\n metadata:\n labels:\n app: fastchat-controller\n spec:\n containers:\n - name: fastchat-controller\n image: 10.156.254.10:8082/llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 21001\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-llm-mixtral,svc-llm-e5-dgfip,svc-llm-llama\n command: [\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-controller2\nspec:\n type: NodePort\n ports:\n - nodePort: 30001\n port: 80\n targetPort: 21001\n selector:\n app: fastchat-controller\nEt pour l’api :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-openai\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-openai\n template:\n metadata:\n labels:\n app: fastchat-openai\n spec:\n containers:\n - name: fastchat-openai\n image: 10.156.254.10:8082/llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 8000\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller,svc-llm-mixtral\n command: [\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-openai-api\nspec:\n type: NodePort\n ports:\n - nodePort: 30081\n port: 80\n targetPort: 8000\n selector:\n app: fastchat-openai\n\nCréez les fichiers de configuration pour un modèle LLM, avec également le pod et le service correspondant. Cette fois-ci, l’image est plus lourde car elle contient le modèle et les modules nécessaires à son fonctionnement.\n\nOn remarquera notamment :\nimage: fastchat-mixtral:v0.3.1\nresources:\n limits:\n nvidia.com/gpu: 2\nEt la commande qui lance le modèle (ici Fastchat mais pourrait être n’importe quel module):\ncommand: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: llm-mixtral\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: llm-mixtral\n template:\n metadata:\n labels:\n app: llm-mixtral\n spec:\n containers:\n - name: llm-mixtral\n image: fastchat-mixtral:v0.3.1\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 2100\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller\n - name: CUDA_VISIBLE_DEVICES\n value: \"0,1\"\n command: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\n resources:\n limits:\n nvidia.com/gpu: 2\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-llm-mixtral\nspec:\n type: NodePort\n ports:\n - nodePort: 30091\n port: 80\n targetPort: 2100\n selector:\n app: llm-mixtral\nEnfin, tous ces composants se basent sur des images docker qui continennent tout le code de mise à disposition des modèles ou des APIs. Des exemples d’images utiles pour les différents services sus-mentionnés sont décrites dans ce Dockerfile :\n#################### BASE OPENAI IMAGE ####################\nFROM python:3.9-buster as llm-api-light\n\n# Set environment variables\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\n# Install dependencies\nRUN apt-get update -y && apt-get install -y curl\n# Install pip\nRUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py\nRUN python3.9 get-pip.py\n# Copy the FastChat directory into the Docker container\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n# Go into the FastChat directory and install from this directory\nWORKDIR /FastChat\nRUN pip3 install -e \".[webui]\" pydantic==1.10.13\nRUN pip3 install plotly\n\n#################### BASE LLM BUILD IMAGE ####################\nFROM nvidia/cuda:12.1.0-devel-ubuntu22.04 AS base\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\nRUN apt-get update -y && apt-get install -y python3.9 curl\nRUN apt-get install -y python3-pip git\n# Copiez le répertoire FastChat dans le conteneur DockerEnfin, tous c\n\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n\n# Allez dans le répertoire FastChat et installez à partir de ce répertoire\nWORKDIR /FastChat\nRUN pip3 install --upgrade pip\nRUN pip3 install -e \".[model_worker]\" pydantic==1.10.13\nRUN pip3 install plotly==5.18.0\nRUN pip3 install accelerate==0.25.0\nRUN pip3 install vllm==0.3.1\nRUN pip3 install minio==7.2.2\nRUN pip3 install pynvml==11.5.0\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-llama\nCOPY ./models/Upstage--Llama-2-70b-instruct-v2 /data/models/vllm/Upstage--Llama-2-70b-instruct-v2\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-mixtral\nCOPY ./models/Mixtral-8x7B-Instruct-v0.1 /data/models/vllm/Mixtral-8x7B-Instruct-v0.1", + "text": "Les LLM sont des modèles de langage puissants qui nécessitent des ressources informatiques importantes pour fonctionner efficacement. Pour mettre en production une application utilisant des LLM, il est essentiel de choisir le bon matériel et les bons outils pour garantir la disponibilité des applications et des performances optimales.\nPour certains modèles de langage, les processeurs habituels appelés CPU (Central Processing Unit) peuvent suffire. Mais pour la plupart des modèles plus importants, pour que les calculs se fassent dans des temps raisonnables, il est nécessaire de se doter d’unités de traitement graphique (GPU). Nous allons donc nous intéresser ici aux différents critères à étudier pour choisir correctement des GPUs, aux outils qui permettent de suivre leurs performances et enfin le lien avec les essentiels de déploiements en termes de management de ressources (avec l’exemple du lien à Kubernetes).\n\n\nLa sélection des GPU (Graphics Processing Units) pour une installation dans une structure dépend de multiples facteurs. En voici quelques uns :\n\nPuissance de calcul : La puissance de traitement des GPU est mesurée en flops (floating-point operations per second). Un GPU plus puissant permettra d’exécuter des tâches plus rapidement et de gérer des charges de travail plus élevées.\nMémoire vive : La mémoire vive (VRAM) des GPU est essentielle pour les applications nécessitant une grande quantité de mémoire, comme les simulations scientifiques ou les applications de traitement d’image. Assurez-vous de choisir des GPU avec suffisamment de mémoire vive pour répondre aux besoins de vos applications.\nÉnergie et consommation : Les GPU consomment de l’énergie et génèrent de la chaleur. Choisissez des GPU économes en énergie et dotés de systèmes de refroidissement efficaces pour réduire les coûts énergétiques et améliorer la durée de vie des composants.\nCoût et rentabilité : Évaluez le coût total de possession (TCO) des GPU, en tenant compte des coûts d’achat, de maintenance et d’énergie. Choisissez des GPU qui offrent une bonne rentabilité pour votre administration.\nCompatibilité avec les systèmes d’exploitation : Vérifiez que les GPU sont compatibles avec les systèmes d’exploitation utilisés dans votre administration, tels que Windows, Linux ou macOS.\n\nPour le dernier point, il est commun d’acheter les GPUs par plusieurs, déjà groupés dans des serveurs. Il faut faire attention cependant au format et aux besoins spécifiques de ces serveurs, qui ne sont souvent pas standards par leur taille et par la chaleur qu’ils dégagent.\nDes GPUs reconnus peuvent être les T5, A100, V100 et leur prix d’achat est de l’ordre de milliers d’euros, mais il faut bien prendre en compte également les coûts cachés. En effet, l’intégration dans un SI pré-existant peut nécessiter des travaux. Durant leur cycle de vie, ils ont besoin de maintenance. Et enfin, tout au long de leur utilisation, ils ont besoin d’être administrés, ce qui peut représenter des Equivalents Temps Plein (ETP), dont le coût n’est pas à négliger.\n\n\n\nIl est judicieux d’utiliser un orchestrateur pour déployer des Language Models (LLMs) dans une organisation pour plusieurs raisons :\n\nSimplification de la gestion des déploiements : un orchestrateur permet de gérer de manière centralisée tous les déploiements de LLMs dans l’organisation. Cela facilite la surveillance, la maintenance et la mise à l’échelle des déploiements.\nÉvolutivité : un orchestrateur permet de mettre à l’échelle automatiquement les déploiements en fonction de la demande, ce qui est particulièrement utile pour les LLMs qui peuvent être très gourmands en ressources.\nSécurité : un orchestrateur peut aider à renforcer la sécurité en fournissant des fonctionnalités telles que l’authentification, l’autorisation et le chiffrement des données. Il peut également aider à respecter les normes de conformité en matière de traitement des données.\nGestion des versions : un orchestrateur permet de gérer les versions des LLMs et de faciliter le déploiement de nouvelles versions ou de rollbacks en cas de problème.\nIntégration avec d’autres outils : un orchestrateur peut s’intégrer facilement avec d’autres outils de développement et d’exploitation, tels que les systèmes de surveillance, les outils de débogage et les systèmes de journalisation.\nRéduction des coûts : en automatisant les déploiements et en les mettant à l’échelle de manière efficace, un orchestrateur peut aider à réduire les coûts associés aux déploiements de LLMs.\n\nEn résumé, un orchestrateur offre une gestion centralisée, une évolutivité, une sécurité renforcée, une gestion des versions, une intégration avec d’autres outils et une réduction des coûts pour les déploiements de LLMs dans une organisation. Des solutions techniques peuvent être :\n\nKubernetes\nDocker Swarm\nApache Mesos\n\n\n\n\nNous allons développer dans cette partie un exemple de déploiement d’une structure LLM avec Kubernetes. On utilise la même structure de microservices que dans la partie précedente avec FastChat mais cela peut être adapté à tout choix d’organisation et d’architecture.\nVoici un schéma résumant l’organisation proposée ici, avec le controller, l’api openai-like et deux modèles LLMs :\n\n\n\nSchéma de structure des services pour Kubernetes\n\n\nLa méthodologie générale de l’utilisation de Kubernetes est la suivante :\n\nPréparer les images Docker qui seront utilisées pour les déploiements\nCréez les fichiers de configuration YAML pour votre application\nDéployez les avec :\n\nkubectl apply -f FILENAMES.yaml\n\nSurveiller le lancement des différents services et leur bonne interconnexion\n\nAvec cela, vous avez une application plus robuste, mais cela necessite une certaine familiarité avec Kubernetes. Quelques exemples de fichiers de configuration sont proposés ci-dessous.\n\nTout d’abord les services obligatoires comme le gestionnaire de l’API et le controlleur. On fait en même temps le deployment du pod et le service permettant d’y accéder. Ils se basent sur une image Docker légère et sans requirements spécifiques.\n\nOn remarquera que les deux deploiments semblent assez similaires et que la principale différence réside dans les noms donnés aux objets et à la commande lancée dans le conteneur lancé :\n[\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\nou\n[\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\nCes commandes sont celles de FastChat mais peuvent être remplacées par votre propre solution de déploiement de modèle.\nPour le controlleur :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-controller\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-controller\n template:\n metadata:\n labels:\n app: fastchat-controller\n spec:\n containers:\n - name: fastchat-controller\n image: llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 21001\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-llm-mixtral,svc-llm-e5-dgfip,svc-llm-llama\n command: [\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-controller2\nspec:\n type: NodePort\n ports:\n - nodePort: 30001\n port: 80\n targetPort: 21001\n selector:\n app: fastchat-controller\nEt pour l’api :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-openai\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-openai\n template:\n metadata:\n labels:\n app: fastchat-openai\n spec:\n containers:\n - name: fastchat-openai\n image: llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 8000\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller,svc-llm-mixtral\n command: [\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-openai-api\nspec:\n type: NodePort\n ports:\n - nodePort: 30081\n port: 80\n targetPort: 8000\n selector:\n app: fastchat-openai\n\nCréez les fichiers de configuration pour un modèle LLM, avec également le pod et le service correspondant. Cette fois-ci, l’image est plus lourde car elle contient le modèle et les modules nécessaires à son fonctionnement.\n\nOn remarquera notamment :\nimage: fastchat-mixtral:v0.3.1\nresources:\n limits:\n nvidia.com/gpu: 2\nEt la commande qui lance le modèle (ici Fastchat mais pourrait être n’importe quel module):\ncommand: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: llm-mixtral\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: llm-mixtral\n template:\n metadata:\n labels:\n app: llm-mixtral\n spec:\n containers:\n - name: llm-mixtral\n image: fastchat-mixtral:v0.3.1\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 2100\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller\n - name: CUDA_VISIBLE_DEVICES\n value: \"0,1\"\n command: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\n resources:\n limits:\n nvidia.com/gpu: 2\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-llm-mixtral\nspec:\n type: NodePort\n ports:\n - nodePort: 30091\n port: 80\n targetPort: 2100\n selector:\n app: llm-mixtral\nEnfin, tous ces composants se basent sur des images docker qui continennent tout le code de mise à disposition des modèles ou des APIs. Des exemples d’images utiles pour les différents services sus-mentionnés sont décrites dans ce Dockerfile :\n#################### BASE OPENAI IMAGE ####################\nFROM python:3.9-buster as llm-api-light\n\n# Set environment variables\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\n# Install dependencies\nRUN apt-get update -y && apt-get install -y curl\n# Install pip\nRUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py\nRUN python3.9 get-pip.py\n# Copy the FastChat directory into the Docker container\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n# Go into the FastChat directory and install from this directory\nWORKDIR /FastChat\nRUN pip3 install -e \".[webui]\" pydantic==1.10.13\nRUN pip3 install plotly\n\n#################### BASE LLM BUILD IMAGE ####################\nFROM nvidia/cuda:12.1.0-devel-ubuntu22.04 AS base\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\nRUN apt-get update -y && apt-get install -y python3.9 curl\nRUN apt-get install -y python3-pip git\n# Copiez le répertoire FastChat dans le conteneur DockerEnfin, tous c\n\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n\n# Allez dans le répertoire FastChat et installez à partir de ce répertoire\nWORKDIR /FastChat\nRUN pip3 install --upgrade pip\nRUN pip3 install -e \".[model_worker]\" pydantic==1.10.13\nRUN pip3 install plotly==5.18.0\nRUN pip3 install accelerate==0.25.0\nRUN pip3 install vllm==0.3.1\nRUN pip3 install minio==7.2.2\nRUN pip3 install pynvml==11.5.0\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-llama\nCOPY ./models/Upstage--Llama-2-70b-instruct-v2 /data/models/vllm/Upstage--Llama-2-70b-instruct-v2\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-mixtral\nCOPY ./models/Mixtral-8x7B-Instruct-v0.1 /data/models/vllm/Mixtral-8x7B-Instruct-v0.1", "crumbs": [ "III-Deploiements", "Socle Production" @@ -15,7 +15,7 @@ "href": "III-Deploiements/3_Socle_Production.html#socle-pour-production-camille-jérôme-conrad", "title": "PARTIE III. Deploiements", "section": "", - "text": "Les LLM sont des modèles de langage puissants qui nécessitent des ressources informatiques importantes pour fonctionner efficacement. Pour mettre en production une application utilisant des LLM, il est essentiel de choisir le bon matériel et les bons outils pour garantir la disponibilité des applications et des performances optimales.\nPour certains modèles de langage, les processeurs habituels appelés CPU (Central Processing Unit) peuvent suffire. Mais pour la plupart des modèles plus importants, pour que les calculs se fassent dans des temps raisonnables, il est nécessaire de se doter d’unités de traitement graphique (GPU). Nous allons donc nous intéresser ici aux différents critères à étudier pour choisir correctement des GPUs, aux outils qui permettent de suivre leurs performances et enfin le lien avec les essentiels de déploiements en termes de management de ressources (avec l’exemple du lien à Kubernetes).\n\n\nLa sélection des GPU (Graphics Processing Units) pour une installation dans une structure dépend de multiples facteurs. En voici quelques uns :\n\nPuissance de calcul : La puissance de traitement des GPU est mesurée en flops (floating-point operations per second). Un GPU plus puissant permettra d’exécuter des tâches plus rapidement et de gérer des charges de travail plus élevées.\nMémoire vive : La mémoire vive (VRAM) des GPU est essentielle pour les applications nécessitant une grande quantité de mémoire, comme les simulations scientifiques ou les applications de traitement d’image. Assurez-vous de choisir des GPU avec suffisamment de mémoire vive pour répondre aux besoins de vos applications.\nÉnergie et consommation : Les GPU consomment de l’énergie et génèrent de la chaleur. Choisissez des GPU économes en énergie et dotés de systèmes de refroidissement efficaces pour réduire les coûts énergétiques et améliorer la durée de vie des composants.\nCoût et rentabilité : Évaluez le coût total de possession (TCO) des GPU, en tenant compte des coûts d’achat, de maintenance et d’énergie. Choisissez des GPU qui offrent une bonne rentabilité pour votre administration.\nCompatibilité avec les systèmes d’exploitation : Vérifiez que les GPU sont compatibles avec les systèmes d’exploitation utilisés dans votre administration, tels que Windows, Linux ou macOS.\n\nPour le dernier point, il est commun d’acheter les GPUs par plusieurs, déjà groupés dans des serveurs. Il faut faire attention cependant au format et aux besoins spécifiques de ces serveurs, qui ne sont souvent pas standards par leur taille et par la chaleur qu’ils dégagent.\nDes GPUs reconnus peuvent être les T5, A100, V100 et leur prix d’achat est de l’ordre de milliers d’euros, mais il faut bien prendre en compte également les coûts cachés. En effet, l’intégration dans un SI pré-existant peut nécessiter des travaux. Durant leur cycle de vie, ils ont besoin de maintenance. Et enfin, tout au long de leur utilisation, ils ont besoin d’être administrés, ce qui peut représenter des Equivalents Temps Plein (ETP), dont le coût n’est pas à négliger.\n\n\n\nIl est judicieux d’utiliser un orchestrateur pour déployer des Language Models (LLMs) dans une organisation pour plusieurs raisons :\n\nSimplification de la gestion des déploiements : un orchestrateur permet de gérer de manière centralisée tous les déploiements de LLMs dans l’organisation. Cela facilite la surveillance, la maintenance et la mise à l’échelle des déploiements.\nÉvolutivité : un orchestrateur permet de mettre à l’échelle automatiquement les déploiements en fonction de la demande, ce qui est particulièrement utile pour les LLMs qui peuvent être très gourmands en ressources.\nSécurité : un orchestrateur peut aider à renforcer la sécurité en fournissant des fonctionnalités telles que l’authentification, l’autorisation et le chiffrement des données. Il peut également aider à respecter les normes de conformité en matière de traitement des données.\nGestion des versions : un orchestrateur permet de gérer les versions des LLMs et de faciliter le déploiement de nouvelles versions ou de rollbacks en cas de problème.\nIntégration avec d’autres outils : un orchestrateur peut s’intégrer facilement avec d’autres outils de développement et d’exploitation, tels que les systèmes de surveillance, les outils de débogage et les systèmes de journalisation.\nRéduction des coûts : en automatisant les déploiements et en les mettant à l’échelle de manière efficace, un orchestrateur peut aider à réduire les coûts associés aux déploiements de LLMs.\n\nEn résumé, un orchestrateur offre une gestion centralisée, une évolutivité, une sécurité renforcée, une gestion des versions, une intégration avec d’autres outils et une réduction des coûts pour les déploiements de LLMs dans une organisation. Des solutions techniques peuvent être :\n\nKubernetes\nDocker Swarm\nApache Mesos\n\n\n\n\nNous allons développer dans cette partie un exemple de déploiement d’une structure LLM avec Kubernetes. On utilise la même structure de microservices que dans la partie précedente avec FastChat mais cela peut être adapté à tout choix d’organisation et d’architecture.\nVoici un schéma résumant l’organisation proposée ici, avec le controller, l’api openai-like et deux modèles LLMs :\n\n\n\nSchéma de structure des services pour Kubernetes\n\n\nLa méthodologie générale de l’utilisation de Kubernetes est la suivante :\n\nPréparer les images Docker qui seront utilisées pour les déploiements\nCréez les fichiers de configuration YAML pour votre application\nDéployez les avec :\n\nkubectl apply -f FILENAMES.yaml\n\nSurveiller le lancement des différents services et leur bonne interconnexion\n\nAvec cela, vous avez une application plus robuste, mais cela necessite une certaine familiarité avec Kubernetes. Quelques exemples de fichiers de configuration sont proposés ci-dessous.\n\nTout d’abord les services obligatoires comme le gestionnaire de l’API et le controlleur. On fait en même temps le deployment du pod et le service permettant d’y accéder. Ils se basent sur une image Docker légère et sans requirements spécifiques.\n\nOn remarquera que les deux deploiments semblent assez similaires et que la principale différence réside dans les noms donnés aux objets et à la commande lancée dans le conteneur lancé :\n[\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\nou\n[\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\nCes commandes sont celles de FastChat mais peuvent être remplacées par votre propre solution de déploiement de modèle.\nPour le controlleur :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-controller\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-controller\n template:\n metadata:\n labels:\n app: fastchat-controller\n spec:\n containers:\n - name: fastchat-controller\n image: 10.156.254.10:8082/llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 21001\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-llm-mixtral,svc-llm-e5-dgfip,svc-llm-llama\n command: [\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-controller2\nspec:\n type: NodePort\n ports:\n - nodePort: 30001\n port: 80\n targetPort: 21001\n selector:\n app: fastchat-controller\nEt pour l’api :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-openai\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-openai\n template:\n metadata:\n labels:\n app: fastchat-openai\n spec:\n containers:\n - name: fastchat-openai\n image: 10.156.254.10:8082/llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 8000\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller,svc-llm-mixtral\n command: [\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-openai-api\nspec:\n type: NodePort\n ports:\n - nodePort: 30081\n port: 80\n targetPort: 8000\n selector:\n app: fastchat-openai\n\nCréez les fichiers de configuration pour un modèle LLM, avec également le pod et le service correspondant. Cette fois-ci, l’image est plus lourde car elle contient le modèle et les modules nécessaires à son fonctionnement.\n\nOn remarquera notamment :\nimage: fastchat-mixtral:v0.3.1\nresources:\n limits:\n nvidia.com/gpu: 2\nEt la commande qui lance le modèle (ici Fastchat mais pourrait être n’importe quel module):\ncommand: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: llm-mixtral\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: llm-mixtral\n template:\n metadata:\n labels:\n app: llm-mixtral\n spec:\n containers:\n - name: llm-mixtral\n image: fastchat-mixtral:v0.3.1\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 2100\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller\n - name: CUDA_VISIBLE_DEVICES\n value: \"0,1\"\n command: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\n resources:\n limits:\n nvidia.com/gpu: 2\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-llm-mixtral\nspec:\n type: NodePort\n ports:\n - nodePort: 30091\n port: 80\n targetPort: 2100\n selector:\n app: llm-mixtral\nEnfin, tous ces composants se basent sur des images docker qui continennent tout le code de mise à disposition des modèles ou des APIs. Des exemples d’images utiles pour les différents services sus-mentionnés sont décrites dans ce Dockerfile :\n#################### BASE OPENAI IMAGE ####################\nFROM python:3.9-buster as llm-api-light\n\n# Set environment variables\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\n# Install dependencies\nRUN apt-get update -y && apt-get install -y curl\n# Install pip\nRUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py\nRUN python3.9 get-pip.py\n# Copy the FastChat directory into the Docker container\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n# Go into the FastChat directory and install from this directory\nWORKDIR /FastChat\nRUN pip3 install -e \".[webui]\" pydantic==1.10.13\nRUN pip3 install plotly\n\n#################### BASE LLM BUILD IMAGE ####################\nFROM nvidia/cuda:12.1.0-devel-ubuntu22.04 AS base\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\nRUN apt-get update -y && apt-get install -y python3.9 curl\nRUN apt-get install -y python3-pip git\n# Copiez le répertoire FastChat dans le conteneur DockerEnfin, tous c\n\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n\n# Allez dans le répertoire FastChat et installez à partir de ce répertoire\nWORKDIR /FastChat\nRUN pip3 install --upgrade pip\nRUN pip3 install -e \".[model_worker]\" pydantic==1.10.13\nRUN pip3 install plotly==5.18.0\nRUN pip3 install accelerate==0.25.0\nRUN pip3 install vllm==0.3.1\nRUN pip3 install minio==7.2.2\nRUN pip3 install pynvml==11.5.0\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-llama\nCOPY ./models/Upstage--Llama-2-70b-instruct-v2 /data/models/vllm/Upstage--Llama-2-70b-instruct-v2\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-mixtral\nCOPY ./models/Mixtral-8x7B-Instruct-v0.1 /data/models/vllm/Mixtral-8x7B-Instruct-v0.1", + "text": "Les LLM sont des modèles de langage puissants qui nécessitent des ressources informatiques importantes pour fonctionner efficacement. Pour mettre en production une application utilisant des LLM, il est essentiel de choisir le bon matériel et les bons outils pour garantir la disponibilité des applications et des performances optimales.\nPour certains modèles de langage, les processeurs habituels appelés CPU (Central Processing Unit) peuvent suffire. Mais pour la plupart des modèles plus importants, pour que les calculs se fassent dans des temps raisonnables, il est nécessaire de se doter d’unités de traitement graphique (GPU). Nous allons donc nous intéresser ici aux différents critères à étudier pour choisir correctement des GPUs, aux outils qui permettent de suivre leurs performances et enfin le lien avec les essentiels de déploiements en termes de management de ressources (avec l’exemple du lien à Kubernetes).\n\n\nLa sélection des GPU (Graphics Processing Units) pour une installation dans une structure dépend de multiples facteurs. En voici quelques uns :\n\nPuissance de calcul : La puissance de traitement des GPU est mesurée en flops (floating-point operations per second). Un GPU plus puissant permettra d’exécuter des tâches plus rapidement et de gérer des charges de travail plus élevées.\nMémoire vive : La mémoire vive (VRAM) des GPU est essentielle pour les applications nécessitant une grande quantité de mémoire, comme les simulations scientifiques ou les applications de traitement d’image. Assurez-vous de choisir des GPU avec suffisamment de mémoire vive pour répondre aux besoins de vos applications.\nÉnergie et consommation : Les GPU consomment de l’énergie et génèrent de la chaleur. Choisissez des GPU économes en énergie et dotés de systèmes de refroidissement efficaces pour réduire les coûts énergétiques et améliorer la durée de vie des composants.\nCoût et rentabilité : Évaluez le coût total de possession (TCO) des GPU, en tenant compte des coûts d’achat, de maintenance et d’énergie. Choisissez des GPU qui offrent une bonne rentabilité pour votre administration.\nCompatibilité avec les systèmes d’exploitation : Vérifiez que les GPU sont compatibles avec les systèmes d’exploitation utilisés dans votre administration, tels que Windows, Linux ou macOS.\n\nPour le dernier point, il est commun d’acheter les GPUs par plusieurs, déjà groupés dans des serveurs. Il faut faire attention cependant au format et aux besoins spécifiques de ces serveurs, qui ne sont souvent pas standards par leur taille et par la chaleur qu’ils dégagent.\nDes GPUs reconnus peuvent être les T5, A100, V100 et leur prix d’achat est de l’ordre de milliers d’euros, mais il faut bien prendre en compte également les coûts cachés. En effet, l’intégration dans un SI pré-existant peut nécessiter des travaux. Durant leur cycle de vie, ils ont besoin de maintenance. Et enfin, tout au long de leur utilisation, ils ont besoin d’être administrés, ce qui peut représenter des Equivalents Temps Plein (ETP), dont le coût n’est pas à négliger.\n\n\n\nIl est judicieux d’utiliser un orchestrateur pour déployer des Language Models (LLMs) dans une organisation pour plusieurs raisons :\n\nSimplification de la gestion des déploiements : un orchestrateur permet de gérer de manière centralisée tous les déploiements de LLMs dans l’organisation. Cela facilite la surveillance, la maintenance et la mise à l’échelle des déploiements.\nÉvolutivité : un orchestrateur permet de mettre à l’échelle automatiquement les déploiements en fonction de la demande, ce qui est particulièrement utile pour les LLMs qui peuvent être très gourmands en ressources.\nSécurité : un orchestrateur peut aider à renforcer la sécurité en fournissant des fonctionnalités telles que l’authentification, l’autorisation et le chiffrement des données. Il peut également aider à respecter les normes de conformité en matière de traitement des données.\nGestion des versions : un orchestrateur permet de gérer les versions des LLMs et de faciliter le déploiement de nouvelles versions ou de rollbacks en cas de problème.\nIntégration avec d’autres outils : un orchestrateur peut s’intégrer facilement avec d’autres outils de développement et d’exploitation, tels que les systèmes de surveillance, les outils de débogage et les systèmes de journalisation.\nRéduction des coûts : en automatisant les déploiements et en les mettant à l’échelle de manière efficace, un orchestrateur peut aider à réduire les coûts associés aux déploiements de LLMs.\n\nEn résumé, un orchestrateur offre une gestion centralisée, une évolutivité, une sécurité renforcée, une gestion des versions, une intégration avec d’autres outils et une réduction des coûts pour les déploiements de LLMs dans une organisation. Des solutions techniques peuvent être :\n\nKubernetes\nDocker Swarm\nApache Mesos\n\n\n\n\nNous allons développer dans cette partie un exemple de déploiement d’une structure LLM avec Kubernetes. On utilise la même structure de microservices que dans la partie précedente avec FastChat mais cela peut être adapté à tout choix d’organisation et d’architecture.\nVoici un schéma résumant l’organisation proposée ici, avec le controller, l’api openai-like et deux modèles LLMs :\n\n\n\nSchéma de structure des services pour Kubernetes\n\n\nLa méthodologie générale de l’utilisation de Kubernetes est la suivante :\n\nPréparer les images Docker qui seront utilisées pour les déploiements\nCréez les fichiers de configuration YAML pour votre application\nDéployez les avec :\n\nkubectl apply -f FILENAMES.yaml\n\nSurveiller le lancement des différents services et leur bonne interconnexion\n\nAvec cela, vous avez une application plus robuste, mais cela necessite une certaine familiarité avec Kubernetes. Quelques exemples de fichiers de configuration sont proposés ci-dessous.\n\nTout d’abord les services obligatoires comme le gestionnaire de l’API et le controlleur. On fait en même temps le deployment du pod et le service permettant d’y accéder. Ils se basent sur une image Docker légère et sans requirements spécifiques.\n\nOn remarquera que les deux deploiments semblent assez similaires et que la principale différence réside dans les noms donnés aux objets et à la commande lancée dans le conteneur lancé :\n[\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\nou\n[\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\nCes commandes sont celles de FastChat mais peuvent être remplacées par votre propre solution de déploiement de modèle.\nPour le controlleur :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-controller\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-controller\n template:\n metadata:\n labels:\n app: fastchat-controller\n spec:\n containers:\n - name: fastchat-controller\n image: llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 21001\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-llm-mixtral,svc-llm-e5-dgfip,svc-llm-llama\n command: [\"python3.9\", \"-m\", \"fastchat.serve.controller\", \"--host\", \"0.0.0.0\", \"--port\", \"21001\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-controller2\nspec:\n type: NodePort\n ports:\n - nodePort: 30001\n port: 80\n targetPort: 21001\n selector:\n app: fastchat-controller\nEt pour l’api :\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: fastchat-openai\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: fastchat-openai\n template:\n metadata:\n labels:\n app: fastchat-openai\n spec:\n containers:\n - name: fastchat-openai\n image: llm-api-light:1.0.0\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 8000\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller,svc-llm-mixtral\n command: [\"python3.9\", \"-m\", \"fastchat.serve.openai_api_server\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\", \"--api-keys\", \"dtnumds,dtnum-s56f1esfd,srp-sd5fze21d,dgfip-si2023\", \"--controller-address\", \"http://svc-controller\"]\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-openai-api\nspec:\n type: NodePort\n ports:\n - nodePort: 30081\n port: 80\n targetPort: 8000\n selector:\n app: fastchat-openai\n\nCréez les fichiers de configuration pour un modèle LLM, avec également le pod et le service correspondant. Cette fois-ci, l’image est plus lourde car elle contient le modèle et les modules nécessaires à son fonctionnement.\n\nOn remarquera notamment :\nimage: fastchat-mixtral:v0.3.1\nresources:\n limits:\n nvidia.com/gpu: 2\nEt la commande qui lance le modèle (ici Fastchat mais pourrait être n’importe quel module):\ncommand: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: llm-mixtral\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: llm-mixtral\n template:\n metadata:\n labels:\n app: llm-mixtral\n spec:\n containers:\n - name: llm-mixtral\n image: fastchat-mixtral:v0.3.1\n imagePullPolicy: IfNotPresent\n ports:\n - containerPort: 2100\n env:\n - name: no_proxy\n value: localhost,127.0.0.1,0.0.0.0,svc-controller\n - name: CUDA_VISIBLE_DEVICES\n value: \"0,1\"\n command: [\"python3\", \"-m\", \"fastchat.serve.vllm_worker\", \"--model-path\", \"/data/models/vllm/Mixtral-8x7B-Instruct-v0.1\", \"--worker-address\", \"http://svc-llm-mixtral\", \"--host\", \"0.0.0.0\", \"--port\", \"2100\", \"--controller\", \"http://svc-controller\", \"--trust-remote-code\", \"--model-names\", \"mixtral-instruct\", \"--num-gpus\", \"2\"]\n resources:\n limits:\n nvidia.com/gpu: 2\n imagePullSecrets:\n - name : regcred\n\n---\n\napiVersion: v1\nkind: Service\nmetadata:\n name: svc-llm-mixtral\nspec:\n type: NodePort\n ports:\n - nodePort: 30091\n port: 80\n targetPort: 2100\n selector:\n app: llm-mixtral\nEnfin, tous ces composants se basent sur des images docker qui continennent tout le code de mise à disposition des modèles ou des APIs. Des exemples d’images utiles pour les différents services sus-mentionnés sont décrites dans ce Dockerfile :\n#################### BASE OPENAI IMAGE ####################\nFROM python:3.9-buster as llm-api-light\n\n# Set environment variables\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\n# Install dependencies\nRUN apt-get update -y && apt-get install -y curl\n# Install pip\nRUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py\nRUN python3.9 get-pip.py\n# Copy the FastChat directory into the Docker container\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n# Go into the FastChat directory and install from this directory\nWORKDIR /FastChat\nRUN pip3 install -e \".[webui]\" pydantic==1.10.13\nRUN pip3 install plotly\n\n#################### BASE LLM BUILD IMAGE ####################\nFROM nvidia/cuda:12.1.0-devel-ubuntu22.04 AS base\nENV https_proxy=http://proxy.infra.dgfip:3128\nENV http_proxy=http://proxy.infra.dgfip:3128\nENV DEBIAN_FRONTEND noninteractive\nRUN apt-get update -y && apt-get install -y python3.9 curl\nRUN apt-get install -y python3-pip git\n# Copiez le répertoire FastChat dans le conteneur DockerEnfin, tous c\n\nWORKDIR /\nRUN git clone -n https://github.com/lm-sys/FastChat.git && \\\n cd FastChat && \\\n git checkout ed6735d\n\n# Allez dans le répertoire FastChat et installez à partir de ce répertoire\nWORKDIR /FastChat\nRUN pip3 install --upgrade pip\nRUN pip3 install -e \".[model_worker]\" pydantic==1.10.13\nRUN pip3 install plotly==5.18.0\nRUN pip3 install accelerate==0.25.0\nRUN pip3 install vllm==0.3.1\nRUN pip3 install minio==7.2.2\nRUN pip3 install pynvml==11.5.0\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-llama\nCOPY ./models/Upstage--Llama-2-70b-instruct-v2 /data/models/vllm/Upstage--Llama-2-70b-instruct-v2\n\n#################### EXTENSION LLAMA ####################\nFROM base AS llm-mixtral\nCOPY ./models/Mixtral-8x7B-Instruct-v0.1 /data/models/vllm/Mixtral-8x7B-Instruct-v0.1", "crumbs": [ "III-Deploiements", "Socle Production" diff --git a/sitemap.xml b/sitemap.xml index bc6550e..47ad06c 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -2,50 +2,50 @@ https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/3_Socle_Production.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/2_Socle_avance.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/4_Impacts.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/3_Acculturation.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/II-Developpements/3_Evaluations.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/II-Developpements/1_Revue_Technique_LLM.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/Guide.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.392Z https://etalab.github.io/programme10pourcent-kallm/II-Developpements/2_RAG.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/1_Besoins.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/2_Deja_Fait_Admin.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/4_Infras_administrations.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/1_Socle_minimal.html - 2024-06-06T14:07:22.000Z + 2024-06-06T14:10:35.396Z