Voxtral-Small-24B-2507
Voxtral Small is Mistral Small 3 with ears. It transcribes speech, and — more unusually — it reasons about audio directly: ask a question about a recording and get an answer, without an intermediate transcript and without a second model. That removes the standard two-stage pipeline where a speech recogniser produces text and a language model reads it, along with everything lost at the handover. A 32k window holds thirty minutes of audio for transcription or forty for understanding, spoken intent can trigger function calls with no transcription step in between, and the text capability of its backbone is retained intact.

Voxtral Small 24B
Mistral Small 3 with audio input. It transcribes, and it reasons about what it heard.
One Model Instead of Two
The architectural point, and it removes a pipeline rather than adding a feature.
The conventional approach to audio understanding is two models. A speech recogniser converts sound to text; a language model reads the text and answers. Two integrations, two sets of failure modes, and a handover where everything not in the words is discarded — tone, hesitation, overlapping speakers, background, emphasis.
Voxtral receives the audio. Questions, summaries, and function calls all operate on the recording itself rather than on a transcript of it.
Mistral's own framing: analyse audio and generate structured summaries without the need for separate ASR and language models.
Where that matters most. "What did the customer actually mean here" is a question about how something was said. A transcript answers it with the words and loses the rest.
Two Modes, Two Endpoints, Two Temperatures
This model lives on two request paths, and they are configured differently.
| Transcription | Understanding | |
|---|---|---|
| Endpoint | /v1/audio/transcriptions | /v1/chat/completions |
| Temperature | 0.0 | 0.2 |
| Top-p | — | 0.95 |
| Audio ceiling | 30 minutes | 40 minutes |
| Output | Every word spoken | An answer, a summary, a tool call |
Mistral publish both temperature settings, and they are not interchangeable. Zero for transcription, because there is one correct answer and variance produces errors. Slightly above zero for understanding, because generating an answer is not transcription.
Carrying one setting into the other mode degrades output in a way that is hard to trace back to sampling.
Why Thirty Minutes and Forty
The two ceilings come from the same 32k window, and the difference is arithmetic.
Transcription emits every word spoken. Half an hour of speech is a great many output tokens, and they share the window with the audio itself.
Understanding emits an answer. A forty-minute recording summarised in three hundred tokens leaves far more of the window for the audio.
So the limit is not a property of the audio — it is a property of what you ask for. A question answered in one sentence fits more recording than a full transcript of the same length does.
Practical consequence: if a long recording exceeds the transcription ceiling, ask a question about it instead of transcribing it. That is frequently what you wanted anyway.
Function Calling Straight From Voice
The capability that is hardest to build any other way.
Spoken intent triggers backend functions, workflows, or API calls directly — with no transcription step in between.
Why the missing step matters. A conventional voice pipeline is: transcribe, parse the text for intent, map intent to a function, extract arguments, call. Each stage loses something and each stage can fail. Intent that was obvious from tone survives none of them.
Here the model hears the request and calls the function.
Where it fits: voice assistants, hands-free operation, call-centre automation that acts rather than logs, and any interface where speaking is faster than typing.
Specifications
| Model ID | mistralai/Voxtral-Small-24B-2507 |
| Parameters | 24B |
| Backbone | Mistral Small 3 |
| Context window | 32k tokens |
| Audio — transcription | Up to 30 minutes |
| Audio — understanding | Up to 40 minutes |
| Input | Audio, text |
| Output | Text |
| Languages | 8 |
| Language detection | Automatic |
| Licence | Apache 2.0 |
| Released | July 2025 |
| GPU RAM (bf16/fp16) | ~55 GB |
Languages: English, Spanish, French, Portuguese, Hindi, German, Dutch, Italian.
Language detection is automatic — Voxtral predicts the source language and transcribes accordingly, without being told which.
Text capability is retained intact from the backbone. This is not a speech model with a small language head; it is a full language model that also hears.
Capabilities
| Capability | Value |
|---|---|
input_types | audio, text |
output_types | text |
image_input | Not supported |
context_window | 32768 |
transcription_mode | Dedicated |
audio_understanding | Supported |
language_detection | Automatic |
multiple_audios | Supported per message |
streaming | Supported |
tool_calling | Supported — including from voice |
structured_output | Supported |
requires_prompt | Audio required; text prompt optional in transcription mode |
Multiple audio files per message and multiple user turns with audio are both supported — so a conversation can carry several recordings and reference them across turns.
Using Voxtral Small on DEVUP AI
Two endpoints, two purposes.
Transcription
Endpoint: POST https://api.devupai.com/v1/audio/transcriptions
A multipart form upload. The response carries the transcript text and per-segment timestamps.
curl -X POST "https://api.devupai.com/v1/audio/transcriptions" \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-F model="mistralai/Voxtral-Small-24B-2507" \
-F file=@meeting.mp3import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEVUP_API_KEY"],
base_url="https://api.devupai.com/v1",
)
with open("meeting.mp3", "rb") as audio:
result = client.audio.transcriptions.create(
model="mistralai/Voxtral-Small-24B-2507",
file=audio,
temperature=0.0,
)
print(result.text)temperature=0.0 is Mistral's recommendation for this mode. Transcription has one correct answer;
sampling variance produces words that were never spoken.
Audio understanding
Endpoint: POST https://api.devupai.com/v1/chat/completions
response = client.chat.completions.create(
model="mistralai/Voxtral-Small-24B-2507",
messages=[
{
"role": "user",
"content": [
{"type": "input_audio", "input_audio": {"data": encoded_audio, "format": "mp3"}},
{
"type": "text",
"text": (
"Summarise this call. State what the customer asked for, what was agreed, "
"and what remains unresolved. Quote the moment agreement was reached."
),
},
],
}
],
temperature=0.2,
top_p=0.95,
max_tokens=4096,
)
print(response.choices[0].message.content)temperature=0.2, top_p=0.95 — Mistral's published settings for understanding, distinct from the
transcription mode.
⚠️ How audio is supplied on the chat endpoint varies by platform. Confirm the field shape with a test request before building around it.
Working With Timestamps
Transcription returns per-segment timing, which is what makes a recording searchable rather than a text dump.
with open("interview.mp3", "rb") as audio:
result = client.audio.transcriptions.create(
model="mistralai/Voxtral-Small-24B-2507",
file=audio,
temperature=0.0,
)
for segment in result.segments:
minutes, seconds = divmod(int(segment["start"]), 60)
print(f"[{minutes:02d}:{seconds:02d}] {segment['text'].strip()}")Store the timestamps with the text from the start. Recovering them later means re-transcribing, and a searchable archive where a phrase links back to its moment in the recording is a different product from a wall of prose.
Choosing the Mode
The decision that saves the most work, and it goes against habit.
Habit says transcribe first, then analyse. That is how the two-model pipeline worked, and it is a reflex worth questioning here.
Ask the audio directly when the transcript is not the deliverable.
| What you need | Mode |
|---|---|
| The exact words, for a record or subtitles | Transcription |
| An answer about what was said | Understanding |
| A summary of a long recording | Understanding |
| A tool call from a spoken request | Understanding |
| A searchable archive with timestamps | Transcription |
Understanding handles forty minutes against transcription's thirty, and skips producing text nobody will read. On a pipeline processing calls to extract three fields, transcribing the whole call first is work you are paying for and discarding.
Preparing Audio
Quality is decided before the request is sent more often than people expect.
Convert to a supported format first. Check which formats your path accepts — anything else needs converting before upload.
ffmpeg -i recording.m4a -ar 16000 -ac 1 recording.wav16 kHz mono is the standard working format. Higher sample rates and stereo upload several times the necessary bytes for output that is effectively identical.
Trim leading and trailing silence. Speech models given nothing to transcribe sometimes produce text that was never spoken, and a silent opening is where that happens.
Split very long recordings at natural pauses. A single forty-minute upload is one request that succeeds or fails as a whole; splitting on silence gives you resumability and keeps individual requests manageable.
Do not denoise aggressively. Noise reduction tuned for human listening frequently removes information the model uses. Test on a sample before applying it to an archive.
Voice-Triggered Tools
The pattern the function-calling capability exists for.
import json
TOOLS = [
{
"type": "function",
"function": {
"name": "create_ticket",
"description": "Open a support ticket with a category, priority, and description.",
"parameters": {
"type": "object",
"properties": {
"category": {
"type": "string",
"enum": ["billing", "delivery", "technical", "other"],
},
"priority": {"type": "string", "enum": ["low", "normal", "high"]},
"description": {"type": "string"},
},
"required": ["category", "priority", "description"],
},
},
},
]
def create_ticket(category: str, priority: str, description: str) -> dict:
"""Replace with your real ticketing system."""
raise NotImplementedError
HANDLERS = {"create_ticket": create_ticket}
thread = [
{
"role": "system",
"content": (
"You handle spoken support requests. Judge priority from what the caller says and how "
"they say it. If the request is ambiguous about what is wrong, ask rather than "
"guessing a category."
),
},
{
"role": "user",
"content": [
{"type": "input_audio", "input_audio": {"data": encoded_audio, "format": "mp3"}},
],
},
]
CEILING = 8
for step in range(CEILING):
response = client.chat.completions.create(
model="mistralai/Voxtral-Small-24B-2507",
messages=thread,
tools=TOOLS,
temperature=0.2,
top_p=0.95,
max_tokens=2048,
)
message = response.choices[0].message
thread.append(message)
if not message.tool_calls:
print(message.content)
break
for call in message.tool_calls:
handler = HANDLERS.get(call.function.name)
if handler is None:
outcome = {"error": "unknown tool", "name": call.function.name}
else:
try:
outcome = handler(**json.loads(call.function.arguments or "{}"))
except Exception as exc:
outcome = {"error": type(exc).__name__, "detail": str(exc)}
thread.append({"role": "tool", "tool_call_id": call.id, "content": json.dumps(outcome)})
else:
print(f"Stopped at the {CEILING}-step ceiling.")"Judge priority from what the caller says and how they say it" is the instruction that uses the model rather than working around it. Urgency is audible, and it does not survive transcription.
The clarification instruction matters as much. A caller describing a problem imprecisely should produce a question, not a ticket in the wrong category.
The Family
Two checkpoints, and the gap between them is large.
| Model | Parameters | GPU RAM |
|---|---|---|
| Voxtral Small | 24B | ~55 GB |
| Voxtral Mini | 3B | ~9.5 GB |
The Mini fits on a consumer card and shares the same feature set — transcription mode, 32k window, the same audio ceilings, the same eight languages, function calling from voice.
What you gain at 24B is the text half. Voxtral Small retains Mistral Small 3's language capability; the Mini is built on a 3-billion-parameter backbone. If the audio is the easy part and the reasoning about it is the hard part, that difference is the reason to be here.
Self-Hosting
~55 GB of GPU RAM in bf16 or fp16. Two 40 GB cards, or one 80 GB.
vLLM 0.10.0 or later, with Mistral's own tokenizer, config, and load formats specified rather than the defaults.
mistral_common 1.8.1 or later, installed with audio support — mistral_common[audio]. The audio
extra is not optional, and a client missing it fails on the first recording rather than at install
time.
The tool-call parser must be set to mistral, with automatic tool choice enabled, if you want
voice-triggered functions.
Transformers supports Voxtral natively, which is the alternative to the vLLM path.
Where It Fits
Call analysis and quality monitoring, where the question is about the conversation rather than about a transcript of it.
Meeting summarisation — forty minutes in, structured summary out, one model.
Voice interfaces that act, using function calling directly from spoken intent.
Multilingual audio across eight languages with automatic detection.
Searchable audio archives, using transcription mode with segment timestamps.
Self-hosted and sensitive-audio environments, where recordings cannot leave your infrastructure — and Apache 2.0 makes that deployable commercially.
Not for speech generation. It hears; it does not speak. Text-to-speech is a different model.
Not for images. Audio and text only.
Not for recordings beyond forty minutes without splitting.
Practical Notes
Use temperature 0.0 for transcription and 0.2 with top-p 0.95 for understanding. Two modes, two settings.
Ask the audio directly when the transcript is not the deliverable.
Convert to 16 kHz mono before uploading.
Trim silence from both ends.
Store timestamps alongside transcripts from the start.
Instruct the model to use tone and delivery, not only words — that is the capability a transcript cannot give you.
Split recordings longer than the ceiling at natural pauses.
Confirm how audio is supplied on the chat endpoint before building a batch path.
Limitations
Two ceilings, not one. Thirty minutes for transcription, forty for understanding, from the same 32k window.
Eight languages. Others are outside the stated coverage.
No speech output. Audio in, text out.
No image input.
32k context, shared between the audio and everything else in the request.
Transcription is not deterministic in the strict sense. Temperature zero reduces variance substantially; store transcripts rather than regenerating them.
Speaker identity is not tracked. The model transcribes and reasons about what was said, not who said it — diarisation is a separate problem.
Audio leaves your system when uploaded. Recordings routinely contain personal, confidential, or legally sensitive speech; handle them under the same policy you apply to any other outbound data, and more carefully than you would text.
Confident output on unclear audio. A poor recording produces a fluent transcript rather than an obviously degraded one — verify against the audio where accuracy matters.