AI Engineer World's Fair 2024
Decoding Mistral AI's Large Language Models
Read the talk
How Mistral Models Turn Next-Token Prediction into Useful Applications
Mistral’s early model releases connect sparse computation, instruction tuning and preference feedback to a practical question: how much capability can you get for the cost of running a model?
From a talk by Devendra Chaplot and Devendra Singh Chaplot
Before you start: Basic familiarity with language-model prompts and Python functions is helpful; the article introduces tokens, sparse experts and the training stages as they appear.
A model portfolio built around developer access
What does it take to put capable language models in developers’ hands—and why release their weights while also selling commercial models? Mistral’s first year provides the starting point. Founded in June 2023, the company released Mistral 7B that September, then Mixtral 8x7B in December. Alongside the sparse expert model came platform APIs and commercial offerings, Mistral Medium and Mistral Embed.
February brought Mistral Large, positioned by Devendra Chaplot as the flagship for reasoning and mathematics. Mixtral 8x22B followed in April. The newest release discussed here is Codestral 22B, a model specialized for programming: Chaplot describes it as a June release, although its announcement dates to May 29, 2024. At the time of the talk, Codestral and Mistral Large were available through Mistral’s free chat interface.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Weights, deployment and customization
Developer access involves more than an endpoint. Mistral’s principles combine openness with portability: Chaplot lists Azure, AWS, GCP, virtual private clouds and on-premises deployment as options across the portfolio. Licensing weights for use on your own servers gives you control over where data travels and how it is secured. The deployment choice becomes part of the application’s privacy and security design.
The other priorities are performance relative to speed and model size, and the ability to customize a model for a particular application. The talk introduces mistral-finetune and a managed fine-tuning API for adaptation, followed by mistral-inference for running models. Both repositories were available tools in this historical workflow; both were subsequently archived in June 2026.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
More capacity without using every parameter
Mistral 7B is a dense transformer. Chaplot describes it as the first 7B model to reach 60 on MMLU and treats that level as an observed threshold for usefulness, rather than a universal rule. The original technical report reports 60.1% on five-shot MMLU for pretrained Mistral 7B under the authors’ evaluation pipeline. Its small size also enabled community deployments on laptops and phones, with speeds Chaplot describes as reasonable; the talk supplies no device configuration or throughput measurement.
Mixtral 8x7B changes the relationship between model capacity and computation. A sparse mixture of experts stores knowledge across a larger collection of parameters but uses only a subset for each token. More weights can therefore contribute to the model’s overall capacity without every token paying the computational cost of activating them all.
| Architecture | Capacity | Computation per token |
|---|---|---|
| Dense transformer | Model weights | Uses the dense network |
| Sparse mixture of experts | Shared weights and multiple experts | Uses a subset of expert parameters |
The distinction is between total parameters and active parameters. Sparse activation constrains inference computation; it does not make the inactive weights disappear from the model.
Mixtral 8x22B scales up this sparse architecture. Chaplot presents it as offering better performance and a larger context window, with multilingual support that includes English, French, Italian, German and Spanish, as well as other languages.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Why open releases can support a business
Releasing weights raises an obvious commercial question: what remains to sell? Mistral’s answer is that community contribution and long-term business value can reinforce each other. Open science is one motivation, but the exchange also creates concrete benefits for the company.
- Awareness: Developers try the models and recommend them to others. Chaplot says Mistral had no in-house marketing team at the time; model quality and word of mouth helped create demand.
- Paid upgrades: Users who like an open model may move to a proprietary model when they need greater capability.
- Deployment knowledge: Community experiments reveal ways to customize models or run them in new settings. Laptop and phone deployments are useful discoveries that Mistral does not have to produce entirely on its own.
The feedback runs in both directions: developers gain access to weights, while Mistral learns from what they build.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The simple objective behind pre-training
The training overview has three stages: pre-training, instruction tuning, and learning from human feedback. Pre-training starts with ordinary text. Given the preceding tokens, the model learns to predict the next one. Repeating that task across a large corpus teaches the patterns needed to continue many kinds of text.
Tokens are not necessarily whole words. Chaplot gives a rough estimate of three-quarters of a word per token, though that ratio depends on the language and tokenizer. A vocabulary may contain tens of thousands or hundreds of thousands of tokens. Each token has an integer ID and an associated embedding, so the model receives a sequence of numerical representations and predicts a continuation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Why a simple objective is hard to train
The difficulty begins with the dataset. Chaplot describes pre-training corpora containing trillions to tens of trillions of tokens. Preparing that material requires preprocessing, cleaning, deduplication and curation. More data is not automatically better data: adding noise can degrade the model rather than improve it.
At the largest scales, the discussion extends to models with hundreds of billions or even trillions of parameters. Chaplot estimates training costs in the tens to hundreds of millions of dollars for the large-model setting he describes, without giving per-model accounting. That expense makes failure unusually consequential. A small company may struggle to fund another run after an unsuccessful one, so training is not an experiment it can casually repeat until the settings work.
Nor can a team assume that the best hyperparameters for a small model will remain best for a larger one. Chaplot uses the Llama 1 family to make the uncertainty concrete: why does its 65B model have 80 layers rather than 82? His answer is that such choices still depend heavily on experience and intuition. Architecture, dataset mixture and training settings are consequential decisions, but their optimal combination is not settled science.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Knowing Python is not the same as answering a request
Ask a pretrained model to write a Python function that determines whether a number is prime. It may continue the problem statement, provide an example or explain an approach without producing the function. That response follows its training objective: continue the text with likely next tokens. A request written in natural language does not, by itself, guarantee that code is the most likely continuation.
Now supply a Python function definition and a docstring describing the same task. That context cues a code continuation, and the demonstration obtains the implementation. For example, the definition and docstring below establish the pattern that a completion model can extend with the body:
python
def is_prime(n: int) -> bool:
"""Return whether n is a prime number."""
if n < 2:
return False
divisor = 2
while divisor * divisor <= n:
if n % divisor == 0:
return False
divisor += 1
return True
The change is in how the capability is elicited. The model can produce the answer, yet may not respond to a human request in the expected form. That gap motivates the next two training stages.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Instruction tuning changes which tokens contribute to loss
Instruction tuning replaces undifferentiated text with prompt-response pairs. The prompt can now be the ordinary request to write a primality function, and the target response can be code such as is_prime above. The examples teach the model the interaction format users expect.
The prediction task remains next-token prediction, but the prompt is masked out of the training loss. It remains visible as context; the model is not being asked to learn the response without seeing the instruction.
- Present the prompt followed by the target response.
- Use the prompt and preceding response tokens to predict each response token.
- Compute the training loss on response tokens only.
This is response-only loss: the model learns to answer the request rather than being rewarded for predicting the request itself.
Chaplot describes instruction datasets ranging from hundreds to hundreds of thousands of examples. Compute requirements are much smaller than for pre-training: his spoken estimate is on the order of 100 GPUs for hours or days, while the slide gives a broader 1–100 GPU range. These are scale estimates, not a configuration-specific requirement.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Learning from choices between answers
Writing an ideal answer from scratch can be expensive. Choosing the better of two candidate answers is often easier. Human feedback turns that comparison into training data: show a person a prompt and two responses, then record which response they prefer. This can scale supervision faster than requiring a fully authored answer for every prompt.
Chaplot names reinforcement learning from human feedback (RLHF) and direct preference optimization (DPO) as routes for using preference data in further tuning. The talk does not derive either algorithm.
| Stage | Training material | Learning signal |
|---|---|---|
| Pre-training | Text sequences | Next-token prediction |
| Instruction tuning | Prompt-response pairs | Response-token prediction |
| Preference tuning | Compared responses | Human preference |
These stages differ in both their supervision and their resource demands. They describe the training framework used for Mistral’s open models, not a claim that every released checkpoint underwent both RLHF and DPO: pretrained and instruction-tuned checkpoints remain distinct.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Reading performance against active computation
The performance-cost graph returns to the purpose of sparse computation. Its horizontal axis measures active parameters, and its vertical axis measures MMLU performance. The desirable direction is toward the upper left: stronger benchmark results with fewer parameters participating in each token’s computation.
Chaplot presents active parameters as proportional to the cost of running the model. For this graph, that is a computational proxy rather than a complete deployment-cost model. It makes the earlier distinction useful: a sparse model can carry more total capacity while limiting the amount of that capacity activated per token.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Codestral: completion and conversation
Codestral 22B applies the performance-and-speed goal to programming. It is a dense transformer trained on more than 80 programming languages, with two interaction modes:
- Instruction mode: Ask a coding question or describe a bug or error, as in a chat assistant.
- Fill-in-the-middle mode: Supply code around a gap and generate the missing portion, supporting completion inside an editor.
These modes serve different moments in development: discussing a problem and continuing the code already on screen.
Chaplot reports that Codestral outperforms Code Llama 70B, DeepSeek Coder 33B and Llama 3 70B in the coding comparisons presented, despite its smaller size. This is a benchmark-specific comparison, not a guarantee across programming tasks. He also highlights its longer context window relative to the compared open coding models. Downloadable weights do not imply identical permissions across the portfolio: Codestral’s original release used the Mistral AI Non-Production License, unlike Mistral 7B’s Apache 2.0 license.
The following multilingual comparison extends the coding-performance discussion across languages; Chaplot says Codestral tends to perform better across the languages shown. For access, he points to free chat use and La Plateforme APIs, then tentatively mentions a free period lasting until the end of July. The launch terms distinguish an eight-week free beta on a dedicated Codestral endpoint from billed platform access, so that historical offer should not be read as free access through every API route. VS Code and JetBrains integrations bring completion into the editor.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Prototype broadly, then specialize the model
For a new application, start with the adaptation methods available around the model: prompt engineering, few-shot examples, chain-of-thought prompting and retrieval-augmented generation. Open weights additionally let you perform task-specific fine-tuning with your own data and compute. Chaplot contrasts that freedom with commercial models, which he says typically do not permit fine-tuning. That is a contextual generalization, not a categorical restriction: GPT-3.5 Turbo already offered commercial fine-tuning before this talk.
The practical decision is how to balance application performance against cost. A high-end commercial model offers strong general-purpose capability and can make the first prototype easier to build. Once the task is understood and usage grows, a smaller open model fine-tuned for that task can become competitive—or outperform the commercial alternative on that specific workload.
Chaplot describes an observed progression:
- Prototype with the most capable model available.
- Establish the particular task the application needs to solve.
- Fine-tune an open model such as Mistral 7B or Mixtral 8x7B for that task.
Specialization can improve performance relative to cost because the deployed model no longer has to be the strongest general-purpose system. The relevant test becomes whether it does the application’s job well enough at the volume and cost the product requires.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Release announcement describing the larger sparse expert model and its active versus total parameter counts.
Original coding-model announcement covering completion, benchmarks, licensing and release-era access.
LoRA training code and fine-tuning examples. Archived in June 2026 and no longer maintained.
Reference inference code with chat and fill-in-the-middle examples. Archived in June 2026.
Further reading
Original architecture, five-shot MMLU results and instruction-tuning discussion for Mistral 7B.
Historical introduction to Mistral's self-hosted, managed and custom training offerings.
Read the complete timestamped transcript
- 0:00
[upbeat music] Uh, hi everyone. I'm, uh, very excited to be here.
- 0:16
Um, I am very, um, happy that there is an open models track. Um, so I'm gonna talk about the, um, open models of Mistral AI and, uh, go a little bit deeper into why we do open source and how we do open source.
- 0:35
So first of all, uh, Mistral AI, we, uh, started last June, uh, about one year ago. Uh, we released our first open model, Mistral 7B, in September '23. Um, and then after that, in December, we released our first mixture of experts open model, 8x7B.
- 0:53
Uh, and along with that, we released our platform with model APIs,
- 0:58
uh, and also commercial models, Mistral Medium and Mistral Embed.
- 1:03
And then, uh, earlier this year in February, we released Mistral Large, which is our flagship model,
- 1:09
uh, which has the best, uh, in class reasoning and, uh, math ability.
- 1:17
And also, uh, in April, we released a new open model, 8x22B.
- 1:23
And then, uh, very recently in June, we released a code-specific model called Codestral 22B,
- 1:30
and, uh, it's also available, uh, in the chat interface that we built, uh, along with Mistral Large and it's, uh, free to use.
- 1:42
Um, so our mission, um, is to bring frontier AI in everyone's hands, and we specifically focus on building cutting-edge AI for developers. And we have, uh, certain principles behind, uh, how we go about training models and releasing them.
- 2:03
So the first is openness. We want to train best-in-class open models and, uh, release it for, uh, the open source community. We want our mo- models to be portable.
- 2:16
Uh, all our models are available on Azure, AWS, GCP, virtual private cloud, and also they can be deploy- deployed on-prem, which means, uh, you can, uh, license the model weights and use, use it on your own servers, uh, with full control over security and privacy of your data.
- 2:36
Uh, we try to optimize for the performance to speed ratio. Uh, our models are particularly good at getting the best performance out of a particular size.
- 2:47
And, um, we want our models to be customizable. Uh, we are building our platform to... with all the libraries and tools to customize our models, uh, depending on your application.
- 3:00
Uh, we recently released the Mistral Finetune open source library, which can be used to fine-tune any of our open source models. And also, uh, we have a fine-tuning API on our, uh, platform.
- 3:13
And before that, we also released Mistral Inference, which is the inference library, uh, again, open source.
- 3:19
Uh, so I talked about these three models that we have open, um, sourced in the last one year.
- 3:27
The first model, uh, is a dense transformer model. Uh, it was the first model... first 7B model to a- achieve sixty on MMLU. And we saw that the sixty MMLU is like, uh, a bare minimum where the models become useful.
- 3:43
And this was the first 7B model to achieve this.
- 3:47
And people have, uh, u- people, people have been using this model for many, many different applications. And particularly, we have seen that this model can be deployed on laptops and phones, uh, and, uh, still get reasonable speed, uh, on, on-device.
- 4:03
Uh, we released the first, um... our first sparse mixture-of-experts model in December, 8x7B. It's based on the, uh, mixture of experts architecture, uh, which basically allows us to
- 4:18
push the performance of a model while keeping the inference budget in check. The idea here is we have higher number of total parameters in the model, which allows the model to, uh, still have the knowledge, uh, stored in the model weights.
- 4:31
But at the same time, we use only a small subset of the parameters, uh, for every token, which makes it really fast and cost efficient at inference time.
- 4:42
And then we released a bigger version of this sparse mixture-of-experts architecture, 8x22B, in April. Uh, it has even better performance, higher, uh, context window, and also it's multilingual. Uh, it supports English, French, Italian, German, Spanish, and also, uh, many other languages.
- 5:03
Um, so a lot of people ask me, "If you open source your models, how do you make money?" And, uh, I think this is a common misconception that people have that open source is somewhat, uh, competitive with profit.
- 5:20
That's actually not the case. We see open source as, uh,
- 5:26
uh, something that is... goes hand in hand with profit. It doesn't necessarily have to be competitive. It can be, uh, complementary. And, uh, we want to be in this quadrant where we can open source our models and still have long-term business value with the models.
- 5:44
Um, so why do we open source? So the first reason is it, uh, serves as a very good branding and marketing tool for us. Um, so we believe in open source and open science, and we want to contribute, uh, to the community, but it's not a, a one-way thing.
- 6:01
Uh, w-we are also benefiting from open source just as the community is be-benefiting from our models. So it helps us doing, doing, uh, a lot of branding and marketing.
- 6:11
Uh, lot of people like our models. They tell other people that our models are good. The model performance speaks for itself. We do not have a marketing team in-house, and, uh, just the open sourcing the models allows us to create awareness about our, uh, products.
- 6:28
It also helps us in customer acquisition. If people try out our open source models and they really like it, they come to us for an upgrade to proprietary models, and, uh, they pay for the upgrade.
- 6:41
And it also helps in customization and portability.
- 6:47
Uh, when-- whenever, uh, for example, the 7B model, people can try it, uh, to, to try to run it on laptops and phones. And this is the kind of stuff we benefit from because we don't necessarily have to do this out of the box, but the community works around our models, and we learn from the community how
- 7:06
our models can be customized or, uh, deployed in new settings.
- 7:11
So how are, um, these open source models trained? So I, I'll give you a very high, uh, level overview of the different stages of LLM training. And typically, LLMs are trained in three stages: pre-training, instruction tuning, and learning from human feedback.
- 7:29
So the idea behind pre-training is very simple. You take a piece of text,
- 7:34
and you pass, uh, word by word or token by token through the large language model and ask the model to predict the next token.
- 7:47
Um, so the idea itself is very simple. Each, uh, the task is the next token prediction. Each token is roughly point seven five word. The vocabulary size is roughly tens of thousands of tokens, or sometimes hundreds of thousands.
- 8:01
And each token is basically represented as an integer, and it has an embedding associated with it. And so the task of the model is to take in a sequence of embeddings or tokens and predict the next token.
- 8:14
Uh, although the concept is very simple, it-- in practice, it's, uh, actually very hard.
- 8:20
Uh, why is it hard? Because it requires a lot of effort in building the datasets. The datasets are huge. They are order of trillions of tokens, tens of trillions of tokens.
- 8:30
Uh, it requires pre-processing, cleaning, deduplication, curation. And there's, again, a common belief that more data leads to better performance, but that's not, not necessarily the case.
- 8:44
Uh, if you have noise in your data, that can actually hurt the model performance. It also requires a lot of investment. Uh, these models are huge. You know, it can go up to hundreds or even hundreds of billions or even trillions of parameters.
- 8:58
Uh, each model takes tens to hundreds of millions of dollars to train.
- 9:04
And the hardest part is you don't get multiple chances to train the model. Uh, the-- because it's so expensive, if something goes wrong in your training, uh, it's, uh, very difficult to get the investment to do another training run.
- 9:23
Uh, because, uh, typically for small companies, you don't get that kind of budget. If you do a, a model run and it's not successful, um, it becomes harder to get the funding for the next run.
- 9:35
Um, and this is hard because the best hyperparameters for a smaller mo-model might not be the best for a larger model.
- 9:46
Uh, here I'm showing you some hyperparameters for Llama one model family sizes. And you might ask,
- 9:55
um, why are the number of layers eighty and not eighty-two in Llama sixty-five B? And the answer is we don't know. Uh, there's a lot of
- 10:09
things that have been, uh, decided by intuition, and it's not exact science. Uh, so you'd need a lot of experience and intuition working with these models to come up with things that are very likely to work.
- 10:23
But, uh, we don't, uh... We're still not very mature with the science of what is the best way to train the model or where-- what's, what's the best architecture, what's the best dataset mixture.
- 10:37
So, uh, can we use this pre-trained model? Um, so let's say if you want to use this pre-trained model and, uh, ask it to write a Python function to find whether the input number is prime or not, and the model might give you a response like this.
- 10:51
Uh, continues the text, gives an example, and like describes the approach, but it might not give you the code. And this is because the model is trained to do this.
- 11:01
It's trained to predict the next token, so it predicts the most likely token from the text data it's been trained on.
- 11:09
But there is a way to trick the model. If you
- 11:14
give this input, like as a Python function definition and a docstring, uh, to, to get the same function, the model actually produces the code.
- 11:24
And so this shows you that model actually knows the answer, but it is not aligned with human preferences. It's not trained to interact with humans in the way humans want to.
- 11:35
And this is why we need the next two stages.
- 11:38
Um, so in the instruction tuning stage, instead of just, uh, a string of text, we have prompt-response pairs. So here we are giving the prompt, but in the way humans want to interact with the model.
- 11:53
So for example, this prompt to, uh, write a Python function, and the response is directly the code because that's what humans want as the response.
- 12:01
And the- Technique is very simple. Again, we are doing next token prediction, but the only difference is we are going to mask the prompt itself. We are going to do prediction only for the response.
- 12:16
Um, so the dataset is paired prompt response pairs. We typically use hundred to hundreds of thousands of inter- instructions. Uh, the task is next word prediction, but just we mask the, the input instruction.
- 12:30
Uh, it requires way less compute. Order of hundred GPUs for a few hours or days is typically sufficient to do instruction fine-tuning.
- 12:41
And then the last steps is learning from human feedback. And here the idea is, um, that human preferences are cheaper or easier to obtain than full human annotation. If I give you a prompt like this and two responses, it's much easier for a human to decide which response is better than to write the whole response, uh, from
- 13:01
scratch. And so this allows us to scale, uh, data faster. There are two main techniques, uh, learning from... re- reinforcement learning from human feedback and direct preference optimization, uh, where we use this kind of preference data to fine-tune the model, uh, further.
- 13:21
So just to summarize, uh, these are the three stages. Um, they have different orders of dataset and compute requirement, and the task is, uh, slightly different. And all the open source models we have have been used-- uh, have been trained using these techniques.
- 13:39
And so I won't go into the details of, um, the model architecture itself, but I'll show you the-- this nice graph of performance to cost ratio,
- 13:52
uh, which kind of shows that, uh, we really try to optimize, um, this metric. Uh, we try, try to get the best performance out of our models of a particular size.
- 14:05
So here on the X-axis, we have the active parameters, which is directly proportional to the cost of running through the model. And on the Y-axis, we have a popular benchmark, MMLU.
- 14:14
So we try to be in the top left corner to get more performance with a lower cost.
- 14:22
Um, we recently released, uh, the Codestral model, Codestral 22B. It's a dense transformer model trained specifically for code. Um, and again, we are trying to optimize performance and speed.
- 14:34
It's fluent in eighty-plus programming languages, and it has both, uh, instruct and fill-in-the-middle mode, which means that you can use it for code completion, uh, in, uh, your code editor, uh, just like GitHub Copilot, but also you can use it to ask questions about the bugs or errors you are facing, just like you would put it in
- 14:53
ChatGPT. Um, so it outperforms Code Llama 70B, Deep, DeepSeek Coder 33B, Llama 3 70B, while being a significantly smaller model. So again, we are getting more performance out of a model of a particular size, and it also has a longer context window, uh, than the other open source code models.
- 15:16
It is multilingual. Uh, we trained it with more than eighty programming languages and, uh,
- 15:24
across all these different languages tends to perform better than the other models.
- 15:30
So it's, uh, free to use on our chat interface, chat.mistral.ai. Uh, we also have the API access available on La Plateforme, which is our, uh, uh, platform API endpoint.
- 15:43
And here, uh, it's also free to use till, I believe, uh, end of July.
- 15:50
We also have, uh, integration with VS Code and JetBrains, so you can download, uh, a plugin in VS Code or JetBrains and use it as a coding assistant for code completion.
- 16:03
So, um, in the end, I, I would just discuss some practical tips because these are some commonly asked questions about how to use open source models and when to use open source versus when, uh, when to use commercial models.
- 16:19
So, uh, if you have a particular application in mind and you want to try out commercial models, you could do things like prompt engineering, few-shot prompting, chain-of-thought, and you could also do retrieval-augmented generation.
- 16:32
Uh, because commercial models typically don't allow you to do fine-tuning. Uh, but for open models, you can do task-specific fine-tuning as well. You need a little bit of data and compute for this.
- 16:47
Uh, but in the end, the choice is between how do you, how do you balance performance versus cost? Commercial models have a higher general purpose performance, so they are much easier to get started with if you are trying to build a new application.
- 17:01
Uh, but if you-- once you get into production or once you have high volume, open models can beat commercial models on specific task with fine-tuning. And, um, uh, typically what we have seen is people pro- prototype with the highest-end models, and then once they figure out that this is the, the, the task they want to solve, they
- 17:24
take a open source model like Mistral 7B or 8x7B and then fine-tuning for their task, and this optimizes the performance to cost ratio.
- 17:35
Uh, we have offices in Paris, London, and in Bay Area. Uh, we are always looking for talented, uh, researchers, engineers, uh, business marketing people. Uh, so,
- 17:50
uh, please, please do apply. And thank you. Uh, I don't know if you are taking questions, but are we? No. Okay. Thank you so much. [upbeat music]