iFlytek Launches Spark-Audio-1.0: Speech Models Begin to “Understand Directly”

iFlytek announced today (September 16) the official launch of its speech foundation model, Spark-Audio-1.0-Preview. Trained on a fully domestically produced computing cluster, the model attempts to address a core problem that has long existed in speech AI: What machines hear is often merely transcribed text, rather than the complete audio signal.

Structurally, Spark-Audio-1.0-Preview consists of a 0.65B-parameter Dense audio encoder and a 30B-A3B-parameter MoE large language model. It was trained on approximately 13 million hours of audio, along with a large volume of text data. According to the company, the model supports recognition of 99 languages and 202 dialects, and can handle tasks including speech transcription, multilingual translation, environmental sound recognition, speaker identification, emotion analysis, and complex audio question answering.

This is not simply another speech-recognition API from iFlytek. Rather, it advances speech capabilities from “tool calling” to the level of a “foundation model.”

From “Transcribe First” to “Understand Sound Directly”

Most speech applications in the past used a cascaded architecture: first, ASR (automatic speech recognition) converted audio into text; second, the text was passed to a large language model for summarization, question answering, or reasoning; when necessary, additional modules for speaker recognition, translation, and speech synthesis were invoked.

This approach is relatively mature from an engineering perspective, but it essentially “compresses” audio information. Text can preserve what was said, but it is difficult for it to fully retain the following:

• The speaker’s tone, pauses, emphasis, and hesitation;
• Changes in emotions such as anger, sadness, excitement, and nervousness;
• The relationships between speakers when multiple people are talking simultaneously;
• Environmental sounds such as keyboard typing, alarms, collisions, and music;
• Dialect pronunciation, accent differences, and sound events without clear textual equivalents.

For example, in customer-service quality inspection, when a customer says “It’s okay,” the transcription alone may lead the system to classify the interaction as ending normally. However, the speech rate, intonation, and long pauses in the original audio may indicate that the customer is actually quite dissatisfied. Similarly, in meeting records, a series of “um”s and “ah”s is not necessarily meaningless noise; it may indicate that the speaker is hesitating, interrupting, or waiting for the other party to continue.

To address these issues, cascaded systems generally need to integrate additional modules for emotion recognition, speaker recognition, and audio-event detection. The more modules there are, the longer the pipeline becomes, and the more errors tend to accumulate: if one stage misidentifies a person’s name, subsequent summarization, translation, and decision-making will continue reasoning from that error.

Spark-Audio-1.0-Preview takes a different approach: it allows the model to directly receive speech and text, and performs auditory information encoding and language-level understanding within the same model. In other words, it attempts to determine not only “what was said,” but also “who said it, how it was said, and what was happening around it.”

What This Architecture Means for Developers

For developers, the biggest change is not that one fewer API call is required, but that the input layer of applications is being redefined.

In a traditional architecture, developers often first need to design a data pipeline involving audio segmentation, noise reduction, speech transcription, timestamp alignment, and speaker diarization, before assembling the results into structured text for further processing by an LLM. Each stage requires separate parameter tuning. Real-time scenarios also need to handle network jitter, queue buildup, and latency fluctuations.

Native speech models may have the opportunity to consolidate this pipeline within the model itself. Specifically, the following types of applications may benefit first.

1. Complex Meeting and Interview Analysis

Basic meeting minutes require only “transcription + summarization,” but real meetings typically involve people speaking over one another, colloquial expressions, microphones at different distances, and substantial background noise. If a model can simultaneously identify speakers, content, and tone, it can further produce:

• Each participant’s statements and viewpoints;
• Points of disagreement, unresolved issues, and the basis for decisions;
• Key segments featuring significant changes in tone;
• Tasks requiring follow-up, along with responsible parties and deadlines.

This is closer to the meeting intelligence that enterprises actually need than simply feeding an entire transcript to a general-purpose LLM.

2. Customer-Service Quality Inspection and Sales Analysis

The value in customer-service scenarios lies not in writing down every sentence, but in identifying emotions, intent, and risks in the conversation. A native speech model can analyze signals such as “the customer requested a refund,” “the customer raised their voice,” and “the customer-service representative remained silent for an extended period” within the same context, reducing the complexity of integrating multiple classifiers in parallel.

However, these applications also depend more heavily on reliable speaker diarization, emotion recognition, and industry-specific labeled data. A model’s ability to understand emotions does not mean that it can automatically understand an industry’s compliance rules. Enterprises still need to establish their own review standards through prompts, fine-tuning, or post-processing.

3. Multilingual and Multidialect Interaction

iFlytek emphasized support for 99 languages and 202 dialects. For cross-regional customer service, government hotlines, in-vehicle voice systems, and educational products, support for multiple dialects is more directly meaningful than simply adding a few more foreign languages. Traditional solutions generally need to identify the language or dialect first and then switch to the corresponding model. If a model can recognize speech without requiring such switching, the engineering cost of handling mixed multilingual input will decrease.

However, it is important to note that “supported” does not mean “equally stable in all real-world scenarios.” Dialects, accents, far-field audio capture, and overlapping speech can all significantly affect actual performance. Before deployment, developers should still conduct targeted evaluations using their own business audio rather than relying solely on rankings from public datasets.

4. Audio Question Answering and Environmental Awareness

Environmental sound recognition and complex audio question answering mark the boundary between native speech models and traditional ASR. For example, a model may be able to answer not only “What was said in the recording?” but also “When did the alarm sound?”, “Which speaker proposed the plan first?”, and “Who began speaking after the background music changed?”

This gives speech models some characteristics of an “auditory agent.” In the future, in-vehicle systems, robots, security inspections, and accessibility-assistance scenarios may no longer need to convert every sound into text before processing it. Instead, they could make decisions directly based on sound events.

The Parameter Size Is Not Particularly Large; the Key Lies in the Combination

The configuration of Spark-Audio-1.0-Preview deserves separate attention. It uses a 0.65B audio encoder together with a 30B-A3B mixture-of-experts language model. “30B-A3B” means that the model has approximately 30 billion total parameters, while approximately 3 billion parameters are actually activated during each inference pass. Compared with a fully Dense 30B model, this MoE architecture may reduce the computational cost of each inference while maintaining relatively strong expressive and reasoning capabilities.

This does not necessarily mean that deployment will be lightweight. The audio encoder, language model, KV cache, context length, and streaming-inference strategy all affect memory usage and latency. In particular, in long-audio scenarios, the number of audio tokens may grow rapidly. Whether the model supports efficient segmented processing, timestamp alignment, and incremental context reuse often has a greater impact on production experience than the parameter count itself.

iFlytek says that the model was trained on a fully domestically produced computing cluster using 13 million hours of audio data. The significance of this information lies primarily in the supply chain and training-infrastructure dimensions: it indicates that domestic speech foundation models are attempting to reduce their dependence on overseas computing resources and general-purpose speech-model ecosystems. However, domestic production of the training infrastructure does not automatically mean lower inference and deployment costs. Developers still need to pay attention to whether the model weights, inference frameworks, hardware adaptations, and service interfaces are available.

Compared with Qwen3.5, iFlytek Is Betting on Broader Speech Coverage

According to information released by iFlytek, Spark-Audio-1.0-Preview performs comparably overall to, and in some areas better than, the similarly sized Qwen3.5-omni-flash (35B-A3B) across multiple speech tasks. It demonstrates particular advantages in multilingual and multidialect recognition, while delivering results close to those of the Qwen3.5-omni-plus, whose parameter scale is an order of magnitude larger.

iFlytek also stated that the model performed strongly on speech-recognition evaluations covering Chinese, English, multiple languages, and multiple dialects, including Fleurs, Kespeech, and LibriSpeech. Its advantages were reportedly even more pronounced on tasks closer to real-world applications, such as high-noise environments and soft-spoken speech.

This comparison is directionally reasonable. iFlytek has accumulated extensive data and scenario experience in speech recognition, dialects, speech synthesis, and education over many years. Speech coverage may be its primary competitive advantage over general-purpose multimodal models. For developers working on Chinese speech, regional dialects, hotline calls, or long-form recording analysis, a dedicated speech foundation model is generally more worth testing than a “general-purpose vision-language model that also happens to listen to audio.”

However, these conclusions currently come mainly from official disclosures. Differences in input formats, audio duration, evaluation prompts, decoding parameters, and metric definitions can all affect the final rankings. In particular, “comparable overall” and “leading in some areas” cannot be directly translated into accuracy, latency, or cost advantages for a specific business. Spark-Audio-1.0-Preview still carries the “Preview” designation, so in production environments it should be treated as a foundational capability requiring validation, rather than as a final product that has already passed stability certification.

From Foundation Models to Industry-Specific Models

iFlytek says that Spark-Audio-1.0-Preview can be fine-tuned in the same way as the “1+N” system of the Spark large model, enabling the further development of specialized models or systems for speech recognition, simultaneous interpretation, speech interaction, and other applications.

This is more important than simply providing a general-purpose interface. The differences between speech applications often do not lie in whether they can understand standard Mandarin, but in whether they can recognize industry terminology, product models, regional accents, and specific operating instructions. A healthcare-oriented model needs to understand drug names and clinical descriptions; a model for industrial inspections needs to identify equipment alarms; and an in-vehicle model needs to remain stable amid wind noise, road noise, and conversations among multiple people.

If iFlytek subsequently provides sufficiently complete fine-tuning tools, data formats, evaluation suites, and deployment options, developers can build more specialized speech systems on top of the foundation model without training an end-to-end model from scratch. The capabilities that ultimately determine the ecosystem’s appeal will be these supporting tools, not merely the evaluation figures released on launch day.

The Boundaries of This Release Are Also Clear

First, native speech understanding will not eliminate all engineering challenges. Recording quality, microphone arrays, far-field echo, overlapping speech, privacy compliance, and real-time transmission still need to be addressed on the application side.

Second, emotion analysis and environmental understanding are inherently uncertain. A model can infer emotions from acoustic features, but “sounding nervous” does not necessarily mean that the speaker is nervous. Environmental sound recognition may also be affected by data distribution and differences between devices. In high-risk decision-making scenarios involving finance, healthcare, recruitment, or the judiciary, model outputs cannot be used as the sole basis for decisions.

Third, Preview versions generally mean that interfaces, model behavior, and performance may still change. When integrating the model, developers should leave room for audio preprocessing, model fallback mechanisms, transcription fallbacks, and result validation, and should avoid binding their business logic entirely to a single model’s output format.

Conclusion: Competition Among Speech Foundation Models Is Entering the Era of “Understanding Scenarios”

The value of Spark-Audio-1.0-Preview lies not simply in iFlytek adding another, larger speech model. Rather, it explicitly chooses the route of end-to-end native speech understanding: audio is no longer merely a temporary format used before entering an LLM, but a first-class input that the model can reason over directly.

Whether this route ultimately prevails will depend on three metrics: stability in real-world noisy environments, the cost of long-audio processing and real-time interaction, and whether developers can transform general-purpose capabilities into industry-specific capabilities through fine-tuning. iFlytek has significant accumulated experience in Chinese speech, dialects, and industrial scenarios, so this model is at least worth a round of hands-on testing by speech-application developers.

For teams that need to compare multiple models quickly, they can first validate text, multimodal, and speech-related tasks through a unified OpenAI-compatible calling layer, and then decide whether to pursue deeper integration based on latency, recognition accuracy, dialect coverage, and cost. OpenAI Hub currently aggregates mainstream models such as GPT, Claude, Gemini, and DeepSeek. As for the specific integration method and available capabilities of Spark-Audio-1.0-Preview, they should still be determined according to the interfaces and documentation that iFlytek officially makes available later.

References

• ITHome: Trained on a Fully Domestically Produced Computing Infrastructure, iFlytek Spark Speech Foundation Model Spark-Audio-1.0-Preview Goes Online — The primary source for this article’s information on the model’s release, architectural parameters, training data, language and dialect coverage, and official evaluation results.
• iFlytek Open Platform Documentation Center — Entry point to iFlytek’s development documentation for speech recognition, speech synthesis, and Spark-related services, enabling developers to learn about existing capabilities and integration methods.