Step-Audio-TTS-3B

What is Step-Audio-TTS-3B?

Step-Audio-TTS-3B is StepFun’s open-weight model for text-to-speech (TTS), the process of turning written text into spoken audio. Its primary role is speech generation rather than general conversation, speech recognition, text reasoning, or image creation. The model is intended for users who want to run an expressive TTS system locally and have access to its model files.

The model was released on February 17, 2025. The supplied model information describes it as having approximately 4 billion parameters and using BF16 weights. In practical terms, that places it in a substantially larger class than lightweight voice-generation models, but the available documentation does not provide a standardized speed benchmark or a direct quality comparison with other TTS systems.

Step-Audio-TTS-3B belongs to StepFun’s Step-Audio family. It is the TTS component associated with the broader Step-Audio speech-interaction work, but this page is specifically about the standalone speech-synthesis model. StepFun’s repository now indicates that the original Step-Audio repository is no longer maintained and points users toward later Step-Audio model lines for newer speech-interaction use cases. That maintenance status is important when evaluating it for a new production deployment.

What can the model generate?

Step-Audio-TTS-3B is designed to produce speech with controllable delivery rather than simply reading text in a fixed voice. According to the official model card, its supported use cases include:

• Multilingual speech synthesis.
• Emotional speech and changes in vocal style.
• Dialect and prosody control, where prosody means features such as rhythm, stress, and intonation.
• Rap generation.
• Humming generation.
• Reference-based voice cloning.

These capabilities make the model relevant to narration, character voices, creative audio, demonstrations, and experiments with expressive vocal performance. The documentation supports the existence of these generation features, but it does not establish that every language, dialect, emotional category, or singing-like style will perform equally well. Results will depend on the prompt, reference recording, hardware configuration, and the particular voice or language being generated.

Separate speech and humming vocoders

The release includes a speech vocoder and a vocoder optimized for humming. A vocoder converts the model’s intermediate acoustic representation into an audio waveform that can be played. Providing a dedicated humming-oriented vocoder is a notable design choice because humming has different acoustic characteristics from ordinary spoken language.

The model is not described as a general music-generation system. Its documented humming capability should therefore be understood as a specialized vocal-generation feature, not evidence that it can compose complete instrumental tracks or produce arbitrary music.

Architecture and supported inputs

Step-Audio-TTS-3B uses a dual-codebook architecture. In simple terms, codebooks are discrete representations used to encode different aspects of an audio signal. The available research identifies the dual-codebook design as part of the model’s training and generation approach, but does not provide enough detail here to translate it into a user-facing quality or latency guarantee.

The ordinary TTS workflow takes text as input and returns audio. Voice cloning adds a reference speaker identifier, prompt text, and prompt WAV file, according to the official repository’s example workflow. This means that cloning is not just a matter of entering a name: the local inference process uses a speaker reference recording and associated prompt information to guide the generated voice.

For the purposes of supported modalities, the model accepts text and audio in the documented workflows and produces audio. It does not provide image or video input/output, and it is not documented as a speech-recognition model. Its output is audio rather than text, structured JSON, images, or video.

Local deployment and hardware requirements

Step-Audio-TTS-3B is distributed as an open-weight model rather than as a metered hosted service. The model is available through Hugging Face and ModelScope, and the official repository provides local inference instructions. StepFun’s repository lists approximately 8 GB of minimum GPU memory for the TTS component with batch size 1. This is a practical minimum from the provider’s deployment guidance, not a guarantee that every supported workflow, language, or voice-cloning configuration will fit within that amount.

The repository recommends NVIDIA CUDA on Linux. Users should therefore expect a locally managed machine-learning setup rather than a browser-only workflow. Installing the required software, downloading the weights, configuring CUDA, and preparing audio prompts are part of the deployment process. The available information does not specify CPU-only performance, exact generation latency, supported operating-system variants beyond the Linux recommendation, or a maximum batch size.

Because the weights are open, local deployment can be useful when an organization needs control over its inference environment or wants to avoid sending voice prompts to a third-party hosted endpoint. It also means that the user is responsible for GPU availability, dependency maintenance, monitoring, storage, and any safeguards required for voice cloning.

Pricing and API availability

No official hosted per-token, per-request, or subscription price was identified for Step-Audio-TTS-3B. The model should not be presented as having a conventional paid API price. Its direct software cost is instead associated with obtaining and operating the open-weight model, including GPU infrastructure and engineering time.

The supplied research also states that the model is not currently deployed by a Hugging Face Inference Provider. The official repository supplies local inference examples, but the available documentation does not establish a managed StepFun API with service-level guarantees, usage quotas, streaming support, or production uptime commitments for this model.

There is no documented context-length limit, maximum output-token limit, or official audio-duration limit in the supplied research. TTS systems still have practical limits related to prompt size, memory, and generation time, but those limits should be measured from the actual implementation rather than assumed from the model’s parameter count.

Strengths and limitations

Where Step-Audio-TTS-3B is strong

• Expressive control: The model is intended to handle emotion, vocal style, dialect, prosody, rap, and humming rather than only neutral reading.
• Open-weight access: Users can download and run the model locally through the published repositories.
• Voice cloning workflow: The official examples document cloning with a speaker reference identifier, prompt text, and WAV recording.
• Specialized humming generation: A humming-optimized vocoder gives this use case explicit support in the release.
• Multilingual positioning: The model card identifies multilingual synthesis as a supported capability, although it does not provide a complete language-by-language performance table in the supplied material.

Important limitations

• Maintenance status: The original Step-Audio repository is marked as no longer maintained, which can increase integration and security-maintenance risk over time.
• No identified hosted pricing or official inference service: Teams wanting a turnkey API may need a different option or must build and operate their own service.
• Limited published operational specifications: Context limits, maximum output limits, latency benchmarks, throughput figures, and standardized quality scores are not supplied.
• Not a general-purpose assistant: It is not documented for reasoning, coding, web search, tool use, speech recognition, or image and video generation.
• Voice-cloning responsibility: Any use of a person’s voice requires appropriate authorization and careful handling of reference recordings. Open weights do not remove privacy, consent, or impersonation concerns.

When to choose Step-Audio-TTS-3B

Choose Step-Audio-TTS-3B when the main requirement is locally controlled, expressive speech generation and the team is prepared to operate an open-weight model. It is especially relevant for prototypes and applications that need emotional narration, distinctive character delivery, dialect or prosody experiments, rap-like vocal output, humming, or reference-based voice adaptation.

It may also suit researchers and developers who want to inspect or modify a downloadable model rather than depend on a closed hosted TTS API. The approximately 8 GB minimum GPU guidance makes it more approachable than some larger local systems, although the overall setup still requires CUDA-oriented deployment work.

Another type of option may be more appropriate when the priority is a maintained managed API, predictable latency, automatic scaling, documented service limits, streaming delivery, or commercial support. A newer Step-Audio model line may also be preferable for current speech-interaction projects because StepFun’s repository identifies the original Step-Audio repository as no longer maintained. That positioning does not make Step-Audio-TTS-3B unsuitable for local experimentation, but it is a meaningful trade-off for long-lived production systems.

Overall assessment

Step-Audio-TTS-3B is best understood as an open-weight expressive TTS model, not as a general AI assistant or a conventional API product. Its most distinctive documented features are the combination of multilingual speech synthesis, controllable emotional and stylistic delivery, voice cloning, rap generation, and dedicated humming support. The trade-off is operational: users must manage local inference, and the original repository’s maintenance status reduces its appeal for teams seeking a continuously supported production platform.

For a local voice-generation experiment or a research project focused on expressive audio, the model offers a broad feature set in one downloadable package. For a production service that needs guaranteed availability, transparent pricing, current maintenance, and detailed performance limits, the lack of an identified hosted offering and the incomplete published operational specifications should be treated as decisive limitations.