Which Voice API Providers Can Put MiniMax Speech 2.8 HD and Turbo Into Production?

Because HD and Turbo take identical parameters, most of the work of taking MiniMax Speech 2.8 to production is engineering housekeeping: choosing which model serves which audio, freezing the voice and settings, handling rate limits and failed requests, and tracking usage. GMI Cloud MaaS has both models active in its model library, as minimax-tts-speech-2.8-hd and minimax-tts-speech-2.8-turbo, on the same API key as the rest of GMI's models and the same request queue as its other media models.

Choosing between HD and Turbo

The two documentation pages for Minimax TTS Speech 2.8 HD and Turbo carry the same parameters and the same description: MiniMax's latest high-performance text-to-speech model, with natural, expressive speech, emotional nuance and zero-shot voice cloning from a short reference clip. The model library describes both as offering "real-time response, intelligent parsing". What sets them apart is the model ID and the per-character price, where HD is the higher of the two.

With an identical request shape, a short evaluation on your own material settles the choice:

1. Collect 20 to 30 real scripts. Include the hardest product names, numbers, acronyms and every language you plan to serve.
2. Generate each script with both models, holding voice_id, speed and emotion constant.
3. Have listeners rate the pairs without knowing which model made which. Record the time from submit to success for each request.
4. Estimate cost as monthly characters divided by 1,000, times each model's per-thousand-character rate from its Pricing section.

If listeners cannot tell the two apart on your scripts, the lower per-character rate decides. If listeners prefer HD on a quality measure you set before the test, and the budget allows it, you have a measured reason to pay for HD. A product with two kinds of audio, for example clips that are kept and replayed and clips that are heard once, can also map each kind to its own model. Keep the model ID as a setting per use case rather than a constant in code, and the mapping stays a configuration change.

Settings to freeze before launch

Everything below goes in the payload object of the request. These are the parameters worth deciding deliberately; the rest of the documented fields (vol, pitch, vm_pitch, intensity, timbre) can stay at their defaults unless a voice needs them.

Store the chosen values as a named preset, for example support-voice-en-v1, and version it. When a preset changes, a version bump lets you tie any audio file back to the settings that made it and roll back if a new voice draws complaints.

A request looks like this:

POST https://console.gmicloud.ai/api/v1/ie/requestqueue/apikey/requests
Authorization: Bearer <GMI_API_KEY>
Content-Type: application/json

{
  "model": "minimax-tts-speech-2.8-hd",
  "payload": {
    "text": "Your order has shipped.",
    "voice_id": "English_expressive_narrator",
    "speed": 1,
    "emotion": "auto",
    "format": "mp3"
  }
}

Voice cloning is a separate family. The model library also lists minimax-audio-voice-clone-speech-2.8-hd and -turbo, which take a reference audio URL and generate speech in that voice. The HD clone page has the fields. Everything about HD, Turbo and production handling below applies to the stock-voice models.

Rate limits and tier upgrades

GMI rate limits are enforced per organization, not per key. Every organization starts on Tier 1, and under the rate limits, once cumulative credit purchases reach a tier's threshold, the organization is upgraded to that tier automatically, within 24 hours. Voucher redemptions do not count as purchases. For a manual upgrade, contact GMI support.

Because tier upgrades follow cumulative credit purchases, discuss the speech capacity your launch needs with GMI ahead of launch day. Concurrency and submission rate are different controls: faster requests finish sooner, so the same concurrency submits more requests per minute. A batch import that submits thousands of scripts at once can hit a limit, so put a submission queue in front of the API, cap both concurrency and submissions per window, and raise the ceilings gradually as your agreed capacity grows. When a request is rejected for rate limit, back off before retrying instead of resubmitting immediately.

Submitting, reading results and retrying

Treat each speech request as a job with an ID. The submit call returns a request_id. Read the request at GET /api/v1/ie/requestqueue/apikey/requests/{request_id} with the same bearer key. The documented status values are queued, processing, success, failed and cancelled. On success, the audio URL is in outcome.media_urls, and the response also includes the payload that produced it.

A production client built around that flow:

• Records the job before and after submitting. Write your own job record first, then store the returned request_id on it, so after a crash you can still read that request back. If a submit call times out without a response, mark the job as outcome unknown and check the request list for that model. If you cannot match a request to the job, do not resubmit automatically; have a person decide, because a duplicate risks an extra generation and its cost.
• Waits for a terminal status. Read at an interval that backs off exponentially as the wait grows, with a little random jitter so many jobs do not poll in lockstep, and stop at a timeout you choose, after which the job goes to review. Do not hand a URL to a user before success.
• Copies the file into your own storage as soon as a request succeeds, and serves users from that copy instead of the result URL.
• Retries only what failed. If a job already has a request_id, read that request first; a failed read is not a failed generation. For a request that reports failed, resubmit only when your logs show the cause was transient. Cap the number of attempts and space them out. Send any failure you cannot classify to a person for review. A retry is a new request with a new request_id, and your own job ID is only your link between the attempts, so log every request_id against it so usage can be reconciled afterward. Do not retry cancelled requests automatically.
• Backfills from the request list. The list endpoint accepts model_id, so after an incident you can pull the requests for one model and find jobs that never got their audio.

Alert on a sudden run of failures for one model. Because HD and Turbo accept the same payload, falling back from one to the other is a one-line change, but decide in advance whether a fallback is acceptable for each use case, since the two models are priced differently.

Tracking usage

Speech is billed by characters, so your own application should log the character count of every request next to its request_id. GMI's usage view supplies the other side of the reconciliation. Its Serverless Usage page sits under Billing in the console, and the usage documentation describes the key and model filters you will rely on.

Usage filter fields for speech: set the key to one environment and the model to HD or Turbo to see that model's usage on its own.

Create one API key per environment and per product surface, and the usage report separates them by key. Compare the HD and Turbo lines of the report against the character counts in your logs weekly during the first month. The report goes down to hourly granularity, and your own request logs cover per-minute peaks.

Production terms for speech traffic

MaaS lists the production-stage pieces: guaranteed SLAs with uptime and performance commitments, seamless switching between models, zero-retention configurations for sensitive workloads, per-client customization across pricing, policies and deployment, and centralized billing across all models. Contact Sales to discuss figures and terms for your speech traffic. Bring a short list to that conversation:

• The quota you expect to need for each speech model, and the date it should take effect.
• The service level and support channel you expect for speech requests.
• Data handling: zero-retention configurations for sensitive workloads, and how they apply to your speech traffic.
• Billing: invoicing arrangements across models.

To test before that conversation, the GMI Cloud console lists both models.

FAQ

If we fall back from HD to Turbo during an incident, will the same voice_id still work?

HD and Turbo offer the same list of 332 voice IDs, with English_expressive_narrator as the default, and accept the same parameters, so a preset moves between them with only the model value changed. During a fallback window, write the model ID into your own job record at submit time so you can tell afterward which clips came from which model and which ones to regenerate.

What output settings suit phone lines and IVR playback?

For IVR prompts that your telephony platform plays as MP3 files, use mono at a low sample rate: set channel to 1 (the default is 2, stereo) and audio_sample_rate to 8000 or 16000, whichever the platform accepts. With format set to mp3, bitrate offers 32000 and 64000 as its lowest options. Leave sound_effects empty, because lofi_telephone adds a telephone-style effect to the voice and does not produce a phone-line format. Save the set as its own preset, such as ivr-voice-en-v1.

Launch checklist

1. Create separate API keys for staging and production.
2. Run the 20 to 30 script evaluation on HD and Turbo, then freeze and version one preset per delivery channel.
3. Add a submission queue with fixed concurrency, and build the job flow around each request_id.
4. Log character counts per request, keep model IDs in configuration, and alert on failure spikes.

Run the script evaluation on HD and Turbo from a console API key, then take the results to Sales when you settle the production terms.