# Deploying Open-Source Large Language Models: A Performance Analysis

Yannis Bendi-Ouis, Dan Dutartre, Xavier Hinaut

<figure><img src="image_1.png" /></figure>

## To cite this version:

Yannis Bendi-Ouis, Dan Dutartre, Xavier Hinaut. Deploying Open-Source Large Language Models: A Performance Analysis. 2024. hal-04777469v2

HAL Id: hal-04777469

https://hal.science/hal-04777469v2

Preprint submitted on 12 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Deploying Open-Source Large Language Models:
A performance Analysis

Yannis Bendi-Ouis

Mnemosyne
Inria

Bordeaux, France

yannis.bendi-ouis@inria.fr

Dan Dutartre

SED
Inria

Bordeaux, France

dan.dutartre@inria.fr

Hinaut Xavier

Mnemosyne
Inria

Bordeaux, France

xavier.hinaut@inria.fr

**Abstract**—Since the release of ChatGPT in November 2022, large language models (LLMs) have seen considerable success, including in the open-source community, with many open-weight models available. However, the requirements to deploy such a service are often unknown and difficult to evaluate in advance. To facilitate this process, we conducted numerous tests at the Center Inria of Bordeaux University. In this article, we propose a comparison of the performance of several models of different sizes (mainly Mistral and LLaMa) depending on the available GPUs, using vLLM, a Python library designed to optimize the inference of these models. Our results provide valuable information for private and public groups wishing to deploy LLMs, allowing them to evaluate the performance of different models based on their available hardware. This study thus contributes to facilitating the adoption and use of these large language models in various application domains.

## I. INTRODUCTION

Following the release of ChatGPT by OpenAI in November 2022 [1], large language models (LLMs) [2] have sparked great interest in the private sector, driving numerous companies to invest in LLM-based services, setting off a wave of innovation and competition. We can notably mention tech giants like Microsoft with Copilot [3], Google with Gemini [4], Meta with Llama [5] and Anthropic with Claude. This explosion of interest has transformed the landscape of artificial intelligence, pushing companies and researchers to explore the vast potential of LLMs. However, training and inference of such models remain inaccessible to the general public, requiring considerable computational power and high-quality data. For instance, Meta AI's acquisition of 350,000 NVIDIA H100 GPUs in January 2024, estimated at $9 billion, underscores the immense financial and technological investment required for cutting-edge research like their LLaMa-3 model, which was trained on an astronomical $1.4 \times 10^{12}$ tokens.

Recognizing the potential monopolization of this technology, leading corporations are actively lobbying governments to regulate LLMs, citing the risks and potential dangers of their malicious use. Their proposed measures ranging from restricting model training beyond certain computational thresholds to government control of GPU resources, with the possibility of remote deactivation [6]. Despite these efforts to consolidate power, it is imperative that such technologies are not

confined solely to a few dominant actors. One critical aspect that cannot be overlooked is the ethical implications of data selection and model training. The individuals or organizations responsible for training LLMs have significant control over the datasets used, which inherently contain biases reflecting their perspectives, values, and priorities. This power enables them to shape the narrative, rewrite history, or propagate their own agendas — potentially leading to the distortion of information and the dissemination of propaganda. In an era of "post-truths" and "alternative facts", the concentration of this power in the hands of a few entities could lead to the manipulation of public opinion at a large scale, further entrenching existing biases and reinforcing misinformation. Transparency emerges as a critical solution, enabling external entities to scrutinize the integrity and security of proposed models, ensuring that they remain truthful and aligned with the broader interests of society rather than serving narrow agendas. While many companies are reluctant to embrace open-source initiatives, some pioneers like Meta (with their LLaMA series) [5], Mistral AI [7], and DeepSeek [8] [9] have made significant strides in promoting open-weight models. These efforts allow for greater democratization of AI technology, empowering diverse groups — both public and private — to deploy powerful models independently.

The availability of open-source models has opened new avenues for innovation, enabling researchers and developers to experiment with LLMs without relying on proprietary systems. This shift is particularly significant in the context of smaller, more efficient models that have gained traction as viable alternatives to larger counterparts. These smaller models, often referred to as "light" or "distilled" models, require fewer computational resources and are easier to deploy, making them accessible to a broader audience. Nevertheless, even for smaller models (ranging from 7B to 30B parameters), the computational power required was still significant. As a result, a portion of the open-source community turned its attention to quantizing model weights and creating open-source packages or services designed to run these models locally. However, even with these advancements, deploying LLMs at scale remains challenging. While serving a model to a single user is straightforward, scaling up to tens, hundreds, or thousands of simultaneous users demands meticulous planning
and optimization. This complexity highlights the importance of thorough testing and evaluation, as oversights in resource allocation or infrastructure design can lead to inefficiencies and reduced performance. In this context, we conducted several tests at the Center Inria of Bordeaux University concerning the deployment of such models.

## II. OBJECTIVES

The main objective of our study is to address the security and confidentiality concerns raised by the increasing use of proprietary LLM solutions - such as ChatGPT - by students and researchers at the Center Inria of Bordeaux University. Indeed, a huge part of our students use these tools to help them in their daily work, whether for writing, programming, proof-reading articles, or brainstorming. For instance, leveraging Retrieval-Augmented Generation (RAG) systems [10] [11] has become a valuable tool in both academic and practical settings. RAG combines language models with external knowledge sources, enabling users to engage in detailed explorations of specific datasets or domains, such as historical documents or scientific papers. This application is particularly beneficial for students and researchers, as it enhances their ability to analyze and understand complex information.

However, the use of these proprietary solutions raises serious security and confidentiality issues. They do not guarantee the confidentiality of data, and the private interests behind them can potentially use them for commercial purposes, training, or even industrial espionage. This last point is particularly concerning for a research center like the Center Inria of Bordeaux University, which must ensure the confidentiality of its employees' research work and is in direct competition with the companies offering these proprietary solutions. It is therefore crucial for our lab to propose alternative solutions and preserve its digital sovereignty.

## III. PREREQUISITES

### A. Skills

To deploy an LLM on a GPU, certain knowledge and skills are required in Linux and Python development, as well as a strong curiosity about existing models and quantification. Although understanding the internal workings of Transformers is not necessary, it can be an asset. The required skills include the ability to update CUDA drivers (version 12 minimum), install a version of Python (minimum 3.9), install Python dependencies, make HTTP requests, and choose the right model for your use case, quantified or not depending on your resources.

### B. Hardware

We conducted our tests on the Plafrim computing server, equipped with two types of GPUs:

* NVIDIA V100 16 GB

* NVIDIA A100 40 GB

### C. Software

We used vLLM [12], a Python library designed to optimize the inference of these models. This library requires at least the prior installation of Python 3.9 and CUDA 12. The advantage of vLLM over other solutions is its ability to handle multiple requests simultaneously, without a queue and without a linear increase in computation time depending on the number of requests, but rather logarithmic. However, depending on the available hardware, other solutions can be considered. Notably, tensorRT-LLM offers excellent performance with NVIDIA GPUs, and llama.cpp provides remarkable performance on Macs equipped with M1, M2, or M3 chips.

### D. Quantification

Some models can be very large, making it particularly difficult to load them into the available hardware - limited by its VRAM. To address this problem, one of the best solutions is to quantify our models. Instead of writing the values of our weights on 16 or 32 bits, we can accept a slight loss of precision and write them on 4 or 8 bits. This loss has been evaluated several times, and although it varies depending on the models and quantification methods used, we can affirm that it is negligible up to 6-bits and acceptable up to 4-bits. However, for a number of parameters greater than 70 billion, the models are robust enough to allow quantification below 4-bits while maintaining good coherence. Among the different quantification methods [13], we can mention AWQ [14], GPTQ [15], and GGUF (llama.cpp).

## IV. EXPERIMENTATION

In this study, we seek to determine the maximum load of simultaneous requests that a server equipped with V100 16 GB or A100 40 GB GPUs can support, depending on the LLM used. For this, we conducted tests by progressively increasing the number of simultaneous requests and the size of the prompts, until reaching the maximum load. For each request, we measured the time required to generate 100 tokens. And, for each model and GPU, we measured the memory load, execution speed, and number of tokens per second depending on the number of simultaneous requests and the maximum context size.

We chose to focus mainly on the models proposed by Mistral AI [16] [7], due to their diversity, popularity, and skills. We also appreciate their performance on European languages, particularly French. Additionally, their Mixture of Experts [7] architecture allows for computational savings during inference, by selecting only a part of the model's weights at each step, which also reduces energy consumption. Moreover, we included the LLaMa-3-70B [5] model from Meta, which achieves performance comparable to GPT-4 with its 70 billion parameters. This model size seems to be a good compromise between size and performance, justifying its inclusion in our study. Thus, we tested the following models: Mistral-7B, Codestral-22b, Mixtral-8x7b, Mixtral-8x22b and LLaMa-3-70B.
# V. RESULTS

## A. Mistral 7B on 2 V100 16 GB

<table><caption>TABLE I
TIME (S) TO RESOLVE THE REQUEST WITH MISTRAL 7B ON 2 V100 16 GB</caption><thead><tr><th rowspan="2">Requests</th><th colspan="7">Number of tokens</th></tr><tr><th>31</th><th>63</th><th>119</th><th>296</th><th>480</th><th>822</th><th>2193</th></tr></thead><tbody><tr><td>1</td><td>1.8</td><td>1.8</td><td>1.9</td><td>1.9</td><td>1.9</td><td>2.1</td><td>2.3</td></tr><tr><td>2</td><td>2.1</td><td>2.1</td><td>2.0</td><td>2.2</td><td>2.3</td><td>2.6</td><td>2.8</td></tr><tr><td>4</td><td>2.2</td><td>2.3</td><td>2.1</td><td>2.6</td><td>2.5</td><td>2.8</td><td>3.7</td></tr><tr><td>8</td><td>2.4</td><td>2.4</td><td>2.5</td><td>2.7</td><td>3.0</td><td>3.5</td><td>5.9</td></tr><tr><td>16</td><td>2.9</td><td>2.9</td><td>3.0</td><td>3.8</td><td>4.2</td><td>5.2</td><td>9.2</td></tr><tr><td>32</td><td>4.2</td><td>4.2</td><td>4.5</td><td>5.4</td><td>6.9</td><td>8.8</td><td>19.0</td></tr><tr><td>64</td><td>6.7</td><td>7.1</td><td>7.7</td><td>9.8</td><td>11.9</td><td>17.1</td><td>36.0</td></tr><tr><td>128</td><td>10.6</td><td>10.4</td><td>11.5</td><td>16.2</td><td>24.4</td><td>33.3</td><td>72.1</td></tr></tbody></table>

## B. Codestral 22B AWQ 4-bits on 1 A100 40 GB

<table><caption>TABLE II
TIME (S) TO RESOLVE THE REQUEST WITH CODESTRAL 22B AWQ 4-BITS ON 1 A100 40 GB</caption><thead><tr><th rowspan="2">Requests</th><th colspan="7">Number of tokens</th></tr><tr><th>31</th><th>63</th><th>119</th><th>296</th><th>480</th><th>822</th><th>2193</th></tr></thead><tbody><tr><td>1</td><td>2.3</td><td>2.3</td><td>2.4</td><td>2.5</td><td>2.6</td><td>2.6</td><td>3.0</td></tr><tr><td>2</td><td>2.3</td><td>2.4</td><td>2.5</td><td>2.7</td><td>2.7</td><td>2.8</td><td>3.5</td></tr><tr><td>4</td><td>2.4</td><td>2.5</td><td>2.6</td><td>2.8</td><td>3.0</td><td>3.4</td><td>4.8</td></tr><tr><td>8</td><td>2.6</td><td>2.7</td><td>2.8</td><td>3.2</td><td>3.7</td><td>4.5</td><td>7.4</td></tr><tr><td>16</td><td>3.0</td><td>3.2</td><td>3.4</td><td>4.2</td><td>5.0</td><td>6.4</td><td>12.3</td></tr><tr><td>32</td><td>4.5</td><td>4.8</td><td>5.4</td><td>6.7</td><td>8.4</td><td>11.4</td><td>23.1</td></tr><tr><td>64</td><td>7.9</td><td>8.5</td><td>9.3</td><td>12.3</td><td>15.8</td><td>21.6</td><td>47.7</td></tr><tr><td>128</td><td>14.3</td><td>15.4</td><td>17.6</td><td>24.2</td><td>29.9</td><td>46.4</td><td>96.2</td></tr></tbody></table>

## C. Codestral 22B GPTQ 8-bits on 2 V100 16 GB

<table><caption>TABLE III
TIME (S) TO RESOLVE THE REQUEST WITH CODESTRAL 22B GPTQ 8-BITS ON 2 V100 16 GB</caption><thead><tr><th rowspan="2">Requests</th><th colspan="7">Number of tokens</th></tr><tr><th>31</th><th>63</th><th>119</th><th>296</th><th>480</th><th>822</th><th>2193</th></tr></thead><tbody><tr><td>1</td><td>3.1</td><td>3.2</td><td>3.2</td><td>3.3</td><td>3.4</td><td>3.7</td><td>4.3</td></tr><tr><td>2</td><td>3.3</td><td>3.4</td><td>3.4</td><td>3.6</td><td>4.0</td><td>4.4</td><td>5.8</td></tr><tr><td>4</td><td>3.7</td><td>3.8</td><td>3.9</td><td>4.4</td><td>4.8</td><td>5.6</td><td>8.8</td></tr><tr><td>8</td><td>4.8</td><td>5.1</td><td>5.3</td><td>6.0</td><td>6.8</td><td>8.8</td><td>15</td></tr><tr><td>16</td><td>7.1</td><td>7.5</td><td>7.9</td><td>9.8</td><td>11.7</td><td>14.3</td><td>27.5</td></tr><tr><td>32</td><td>10.4</td><td>10.9</td><td>11.9</td><td>15.3</td><td>19.0</td><td>24.6</td><td>53.8</td></tr><tr><td>64</td><td>15.5</td><td>17.0</td><td>18.7</td><td>25.9</td><td>32.1</td><td>43.9</td><td>108.2</td></tr><tr><td>128</td><td>21.7</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

The first thing we can notice is that the larger the context size, the slower the model is at generating 100 tokens. This is expected and is related to its complexity, which grows quadratically with the context size. Moreover, as we can see with the Mixtral [7] and Llama [5] models, just because a model can be loaded does not mean it can be used for any context size. The context size has a quadratic cost in RAM (or VRAM), which adds to the model size, potentially significantly increasing memory requirements. On the other hand, we can also observe that we do not have a linear loss of efficiency with the number of simultaneous requests: the time required to respond to a request does not double when the number of simultaneous requests doubles.

## D. Codestral 22B on 2 A100 40 GB

<table><caption>TABLE IV
TIME (S) TO RESOLVE THE REQUEST WITH CODESTRAL 22B ON 2 A100 40 GB</caption><thead><tr><th rowspan="2">Requests</th><th colspan="7">Number of tokens</th></tr><tr><th>31</th><th>63</th><th>119</th><th>296</th><th>480</th><th>822</th><th>2193</th></tr></thead><tbody><tr><td>1</td><td>2.3</td><td>2.3</td><td>2.4</td><td>2.4</td><td>2.5</td><td>2.6</td><td>2.8</td></tr><tr><td>2</td><td>2.3</td><td>2.3</td><td>2.4</td><td>2.5</td><td>2.6</td><td>2.7</td><td>3.3</td></tr><tr><td>4</td><td>2.4</td><td>2.4</td><td>2.5</td><td>2.7</td><td>2.8</td><td>3.1</td><td>4.2</td></tr><tr><td>8</td><td>2.5</td><td>2.6</td><td>2.8</td><td>3.1</td><td>3.4</td><td>4.1</td><td>6.3</td></tr><tr><td>16</td><td>2.8</td><td>2.9</td><td>3.2</td><td>3.8</td><td>4.4</td><td>5.6</td><td>10.2</td></tr><tr><td>32</td><td>3.3</td><td>3.7</td><td>4.0</td><td>5.2</td><td>6.4</td><td>8.8</td><td>18.1</td></tr><tr><td>64</td><td>4.3</td><td>4.6</td><td>5.7</td><td>8.0</td><td>10.5</td><td>15.5</td><td>36.8</td></tr><tr><td>128</td><td>6.8</td><td>7.8</td><td>9.4</td><td>14.5</td><td>19.6</td><td>32.9</td><td>71.1</td></tr></tbody></table>

## E. Mixtral 8x7B AWQ 4-bits on 2 A100 40 GB

<table><caption>TABLE V
TIME (S) TO RESOLVE THE REQUEST WITH MIXTRAL 8X7B AWQ 4-BITS ON 2 A100 40 GB</caption><thead><tr><th rowspan="2">Requests</th><th colspan="7">Number of tokens</th></tr><tr><th>31</th><th>63</th><th>119</th><th>296</th><th>480</th><th>822</th><th>2193</th></tr></thead><tbody><tr><td>1</td><td>3.1</td><td>3.2</td><td>3.6</td><td>3.4</td><td>3.5</td><td>3.5</td><td>4.1</td></tr><tr><td>2</td><td>3.3</td><td>3.3</td><td>3.5</td><td>3.5</td><td>3.8</td><td>3.8</td><td>4.7</td></tr><tr><td>4</td><td>3.5</td><td>3.6</td><td>3.5</td><td>4.3</td><td>4.1</td><td>4.6</td><td>6.2</td></tr><tr><td>8</td><td>3.8</td><td>3.8</td><td>4.0</td><td>4.3</td><td>4.9</td><td>5.7</td><td>9.3</td></tr><tr><td>16</td><td>4.3</td><td>4.6</td><td>4.9</td><td>6.0</td><td>6.7</td><td>8.5</td><td>15.5</td></tr><tr><td>32</td><td>6.0</td><td>6.4</td><td>7.6</td><td>8.7</td><td>10.9</td><td>14.2</td><td>-</td></tr><tr><td>64</td><td>10.0</td><td>10.5</td><td>11.6</td><td>15.5</td><td>-</td><td>-</td><td>-</td></tr><tr><td>128</td><td>18.5</td><td>19.6</td><td>21.5</td><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

## F. Mixtral 8x22B AWQ 4-bits on 4 A100 40 GB

<table><caption>TABLE VI
TIME (S) TO RESOLVE THE REQUEST WITH MIXTRAL 8X22B AWQ 4-BITS ON 4 A100 40 GB</caption><thead><tr><th rowspan="2">Requests</th><th colspan="7">Number of tokens</th></tr><tr><th>31</th><th>63</th><th>119</th><th>296</th><th>480</th><th>822</th><th>2193</th></tr></thead><tbody><tr><td>1</td><td>6.0</td><td>6.0</td><td>6.3</td><td>6.8</td><td>7.0</td><td>7.6</td><td>10.9</td></tr><tr><td>2</td><td>7.2</td><td>7.1</td><td>7.4</td><td>8.4</td><td>8.7</td><td>10.3</td><td>16.7</td></tr><tr><td>4</td><td>8.0</td><td>8.1</td><td>8.7</td><td>10.3</td><td>11.9</td><td>14.2</td><td>21.3</td></tr><tr><td>8</td><td>9.0</td><td>9.4</td><td>10.0</td><td>13.0</td><td>16.7</td><td>19.4</td><td>36.2</td></tr><tr><td>16</td><td>11.0</td><td>12.2</td><td>13.2</td><td>21.1</td><td>26.5</td><td>31.9</td><td>66.4</td></tr><tr><td>32</td><td>16.0</td><td>17.6</td><td>22.6</td><td>33.6</td><td>37.7</td><td>56.7</td><td>-</td></tr><tr><td>64</td><td>28.0</td><td>31.8</td><td>35.9</td><td>56.0</td><td>71.7</td><td>-</td><td>-</td></tr><tr><td>128</td><td>52.0</td><td>55.3</td><td>67.0</td><td>111.7</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

## G. LLaMa-3 70B AWQ 4-bits on 2 A100 40 GB

<table><caption>TABLE VII
TIME (S) TO RESOLVE THE REQUEST WITH LLaMa-3 70B AWQ 4-BITS ON 2 A100 40 GB</caption><thead><tr><th rowspan="2">Requests</th><th colspan="7">Number of tokens</th></tr><tr><th>21</th><th>51</th><th>97</th><th>240</th><th>398</th><th>703</th><th>1848</th></tr></thead><tbody><tr><td>1</td><td>3.6</td><td>3.7</td><td>3.7</td><td>3.9</td><td>4.0</td><td>4.2</td><td>4.8</td></tr><tr><td>2</td><td>3.7</td><td>3.7</td><td>3.9</td><td>4.1</td><td>4.2</td><td>4.5</td><td>5.8</td></tr><tr><td>4</td><td>3.8</td><td>4.0</td><td>4.1</td><td>4.4</td><td>4.7</td><td>5.4</td><td>7.9</td></tr><tr><td>8</td><td>4.3</td><td>4.5</td><td>4.8</td><td>5.1</td><td>5.9</td><td>7.4</td><td>12.5</td></tr><tr><td>16</td><td>4.9</td><td>5.2</td><td>5.7</td><td>6.9</td><td>8.3</td><td>10.8</td><td>21.4</td></tr><tr><td>32</td><td>7.6</td><td>8.2</td><td>8.7</td><td>11.1</td><td>13.7</td><td>19.6</td><td>40.9</td></tr><tr><td>64</td><td>12.9</td><td>13.9</td><td>15.2</td><td>20.3</td><td>25.8</td><td>37.5</td><td>-</td></tr><tr><td>128</td><td>23.2</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>
<figure><img src="image_3.png" /><figcaption>Fig. 1. Number of tokens generated per second and per user for Mixtral 8x7B AWQ 4-bits on 2 A100 40GB</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Fig. 2. Total number of token generated per second for Mixtral 8x7B AWQ 4-bits on 2 A100 40GB</figcaption></figure>

However, this seems less true when the request size exceeds a certain threshold.

Finally, we can notice that although the cost of these GPUs is far from trivial (V100 16GB ≈ $5000, A100 40GB ≈ $8500), it is not necessary to possess an exorbitant quantity to successfully run a local alternative to ChatGPT or other proprietary solutions. In fact, with two A100 40GB GPUs (or a single 80GB GPU), it is already possible to run LLaMa-3-70B or Mixtral 8x7B under very good conditions. According to numerous benchmarks and user reviews, these models are serious contenders to GPT-4.

To a lesser extent, it is possible to host smaller models (in the range of 7 to 30B) and achieve extremely impressive generation speeds, especially if requests are parallelized. For example, we can observe in Figure 1 the number of tokens generated per second and per user as a function of the number of simultaneous requests and the size of the prompt, and in Figure 2 the total number of tokens generated per second (for all users combined) as a function of the number of simultaneous requests and the size of the prompts. Thus, we can observe that for a model like Mixtral 8x7B — which has

49B parameters and only 12-13B active parameters at any given time (MoE architecture) [7] — we can achieve up to 700 tokens/second for 128 simultaneous requests with a nearly zero context (30 tokens), and we can obtain an inference speed of just under 20 tokens per second for 20 simultaneous users.

## VI. DISCUSSION & PERSPECTIVE

In this article, we have presented a comparative study of the performance of several large language models (LLMs) based on available hardware resources. Our experimental results demonstrate that deploying open-source LLMs such as Mistral [16] [7] and LLaMA [5] on V100 and A100 GPUs is feasible and highly efficient. The performance of these models, particularly when equipped with advanced architectures like the Mixture-of-Experts (MoE), rivals or even surpasses proprietary solutions like ChatGPT [1]. One key observation from our experiments is the scalability of these models when serving multiple simultaneous users. While the time required to respond to a request does not linearly increase with the number of requests, there is a threshold beyond which performance begins to degrade. This highlights the need for careful
resource allocation and infrastructure design when deploying LLMs at scale. Looking ahead, the integration of newer GPUs like NVIDIA's H100 could further enhance the performance of these models. With more powerful hardware and larger GPU clusters, organizations could potentially deploy even larger models, such as LLaMA-3-405B or DeepSeek-V3, with greater efficiency and scalability. Additionally, advancements in quantization techniques and model compression could make it possible to run these models on less powerful hardware, broadening their accessibility.

They also highlight the importance of transparency and digital sovereignty, enabling public and private groups to deploy open-source models without relying on proprietary solutions. One of the most compelling reasons for organizations to deploy their own LLMs locally is the snowball effect it creates. When data is shared with external providers, it contributes to the improvement of their models, giving them a competitive edge. However, by deploying and refining our own models, we can harness this data to improve our own systems, ensuring that the benefits of technological advancements remain within our organization. This not only enhances our capabilities but also strengthens our position in the competitive landscape.

The recent emergence of state-of-the-art (SOTA) open-weight models like DeepSeek V3 and R1 by the end of 2024 further underscores the viability of local deployment. These models, particularly with their Mixture of Experts (MoE) architecture, demonstrate that high performance can be achieved without exorbitant computational costs, provided sufficient VRAM is available. This development is a game-changer, as it shows that open-source models can now rival or even surpass proprietary solutions in terms of performance and efficiency. For organizations that may not have access to the latest hardware, "distilled" versions of these models, such as the "R1 distilled" versions based on Llama and Qwen2.5, offer a practical alternative. These "distilled" models retain much of the performance of their larger counterparts while being more resource-efficient, making them accessible to a wider range of users. We strongly encourage research centers, universities, and businesses to take the initiative in deploying their own LLM solutions. By leveraging open-source (or open-weight) models, organizations can reduce their dependence on external providers and gain greater control over their data and technological infrastructure. This not only enhances data security and confidentiality but also fosters innovation and self-reliance. Moreover, local deployment of LLMs can be tailored to the specific needs of the organization, whether it be for research, education, or business applications. For instance, universities can provide students and researchers with powerful tools for academic work, while businesses can develop customized solutions for their unique challenges. Looking ahead, the continuous improvement of open-source models and the increasing availability of high-performance hardware will further democratize access to LLMs. We anticipate that more organizations will adopt local deployment strategies, leading to a more diverse and competitive ecosystem. This, in turn, will drive innovation and ensure that the benefits of AI are

widely distributed.

## VII. CONCLUSION

Our study successfully demonstrates the feasibility of deploying open-source LLMs such as Mistral and LLaMA on V100 and A100 GPUs. The results highlight the efficiency and scalability of these models, even under significant computational constraints. During various events, we were able to deploy these models in production and serve a large number of simultaneous users without compromising performance. This real-world validation underscores the effectiveness of our approach and reinforces the potential of open-source AI.

By leveraging local deployment strategies and taking advantage of advancements in hardware and model architecture, organizations can achieve high-performance LLMs while maintaining control over their data and infrastructure. As the field of AI continues to evolve, it is crucial that we prioritize ethical considerations, transparency, and sustainability to ensure that these technologies benefit society as a whole.

## VIII. ACKNOWLEDGMENT

We extend our gratitude to the Center Inria of Bordeaux University and the Plafrim Cluster for their support and resources, which made this study possible.

## REFERENCES

[1] J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat et al., "Gpt-4 technical report," arXiv preprint arXiv:2303.08774, 2023.

[2] W. X. Zhao, K. Zhou, J. Li, T. Tang, X. Wang, Y. Hou, Y. Min, B. Zhang, J. Zhang, Z. Dong et al., "A survey of large language models," arXiv preprint arXiv:2303.18223, 2023.

[3] S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, "The impact of ai on developer productivity: Evidence from github copilot," arXiv preprint arXiv:2302.06590, 2023.

[4] G. Team, P. Georgiev, V. I. Lei, R. Burnell, L. Bai, A. Gulati, G. Tanzer, D. Vincent, Z. Pan, S. Wang et al., "Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context," arXiv preprint arXiv:2403.05530, 2024.

[5] H. Touvron, T. Lavril, G. Izacard, X. Martinet, M.-A. Lachaux, T. Lacroix, B. Rozière, N. Goyal, E. Hambro, F. Azhar et al., "Llama: Open and efficient foundation language models," arXiv preprint arXiv:2302.13971, 2023.

[6] OpenAI, "Reimagining secure infrastructure for advanced ai," Section: blog, 2024.

[7] A. Q. Jiang, A. Sablayrolles, A. Roux, A. Mensch, B. Savary, C. Bamford, D. S. Chaplot, D. d. I. Casas, E. B. Hanna, F. Bressand et al., "Mixtral of experts," arXiv preprint arXiv:2401.04088, 2024.

[8] A. Liu, B. Feng, B. Xue, B. Wang, B. Wu, C. Lu, C. Zhao, C. Deng, C. Zhang, C. Ruan et al., "Deepseek-v3 technical report," arXiv preprint arXiv:2412.19437, 2024.

[9] D. Guo, D. Yang, H. Zhang, J. Song, R. Zhang, R. Xu, Q. Zhu, S. Ma, P. Wang, X. Bi et al., "Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning," arXiv preprint arXiv:2501.12948, 2025.

[10] Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, and H. Wang, "Retrieval-augmented generation for large language models: A survey," arXiv preprint arXiv:2312.10997, 2023.

[11] D. Edge, H. Trinh, N. Cheng, J. Bradley, A. Chao, A. Mody, S. Truitt, and J. Larson, "From local to global: A graph rag approach to query-focused summarization," 2024. [Online]. Available: https://arxiv.org/abs/2404.16130

[12] W. Kwon, Z. Li, S. Zhuang, Y. Sheng, L. Zheng, C. H. Yu, J. Gonzalez, H. Zhang, and I. Stoica, "Efficient memory management for large language model serving with pagedattention," in *Proceedings of the 29th Symposium on Operating Systems Principles*, 2023, pp. 611–626.
<footnote>[13] S. Rajput and T. Sharma, “Benchmarking emerging deep learning quantization methods for energy efficiency,” in *2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C)*. IEEE, 2024, pp. 238–242.</footnote>

<footnote>[14] J. Lin, J. Tang, H. Tang, S. Yang, W.-M. Chen, W.-C. Wang, G. Xiao, X. Dang, C. Gan, and S. Han, “Awq: Activation-aware weight quantization for on-device llm compression and acceleration,” *Proceedings of Machine Learning and Systems*, vol. 6, pp. 87–100, 2024.</footnote>

<footnote>[15] E. Frantar, S. Ashkboos, T. Hoefler, and D. Alistarh, “Gptq: Accurate post-training quantization for generative pre-trained transformers,” *arXiv preprint arXiv:2210.17323*, 2022.</footnote>

<footnote>[16] A. Q. Jiang, A. Sablayrolles, A. Mensch, C. Bamford, D. S. Chaplot, D. d. I. Casas, F. Bressand, G. Lengyel, G. Lample, L. Saulnier et al., “Mistral 7b,” *arXiv preprint arXiv:2310.06825*, 2023.</footnote>