iFlytek Releases Spark-ASR-2.0

iFlytek Moves the Focus of Speech Recognition from “Hearing Clearly” to “Writing Like a Human”

On September 23, iFlytek officially released its next-generation speech recognition foundation model, Spark-ASR-2.0. The core information provided by the company is clear: compared with Spark-ASR-1.0, Spark-ASR-2.0 delivers significant improvements in Chinese-English mixed speech, dialects, professional terminology, high-noise environments, low-volume speech, fast speech, children’s speech, and text fluency, while increasing overall inference costs by only about 10%.

This is not simply a routine model upgrade. In the past, the primary goal of speech recognition systems was to restore speech to text as accurately as possible, with evaluation criteria generally focused on WER (word error rate) and CER (character error rate). However, in meeting minutes, customer service quality inspections, interview transcription, input methods, and smart hardware, users need more than just a “dictation result.” They need text that can be read, searched, edited, and even delivered directly.

The change introduced by Spark-ASR-2.0 is a move away from “verbatim transcription” and toward “organizing text based on context.” iFlytek summarizes this as “fluent document generation”: while preserving the original meaning as much as possible, the model reduces redundancies in spoken language and makes sentence segmentation, punctuation, numbers, and professional terminology more consistent with written-language conventions.

Three Technical Approaches, Each Addressing a Different Problem

Based on the information disclosed by iFlytek, Spark-ASR-2.0 mainly revolves around three technical approaches: collaboration between non-autoregressive and LLM-enhanced autoregressive models, joint enhancement of Chinese-English mixed text and acoustics, and dynamic context injection.

1. Collaboration Between Non-Autoregressive and Autoregressive Models: Rebalancing Speed and Quality

Speech recognition systems typically make trade-offs among speed, accuracy, and text quality.

Non-autoregressive models can process more content in parallel, giving them advantages in response speed and throughput. They are suitable for real-time input, live captions, and large-scale audio transcription. However, their ability to handle complex contexts is limited. When dealing with homophones, long-range semantic relationships, professional terminology, and mixed Chinese-English expressions, they may correctly identify individual parts while producing sentences that sound wrong as a whole.

Autoregressive models are more like humans when composing sentences: they generate subsequent content step by step based on the preceding text. As a result, they are generally stronger in contextual understanding, word-order adjustment, and text fluency. The trade-off is a longer inference chain, which may increase latency and computational costs.

Spark-ASR-2.0 adopts a collaborative approach. The goal is not to completely replace one model with the other, but to have the non-autoregressive path handle efficient recognition while the LLM-enhanced autoregressive path processes segments that require more contextual judgment. Put simply, the system first understands the speech quickly, then applies deeper language modeling to areas that are prone to errors or require polishing.

The value of this approach is that the model does not need to send the entire audio stream through a high-cost inference process just because of a few complex segments. For API providers and developers, this is more practical than simply adding computational resources, because the cost of speech transcription is often determined not by a single call, but by millions of hours of audio, concurrent real-time requests, and long-lived connections every day.

2. Joint Enhancement of Chinese-English Mixed Text and Acoustics: Handling Real-World Input That Is “Half Chinese, Half English”

Real-world speech is rarely as clean as a test set. Developers mix English terms such as API, token, WebSocket, and embedding into technical discussions; product managers insert model names and company names into Chinese sentences; and users frequently say things like “Help me check the price of GPT-5” when using an input method.

Traditional recognition systems often require considerable switching among language models, vocabularies, and decoding strategies. Chinese and English differ in pronunciation, syllable structure, word boundaries, and capitalization. Relying solely on text-side vocabulary lists cannot solve every problem. If the acoustic side is not sufficiently trained for mixed-language speech, the system may know that a particular word could appear in a sentence but still fail to identify it reliably from the pronunciation.

Spark-ASR-2.0 emphasizes joint enhancement of Chinese-English mixed text and acoustics. This means that it is not merely expanding its vocabulary, but also attempting to have “acoustic features” and “linguistic expression” participate jointly in the decision-making process. For developers, this capability is particularly suitable for technical conferences, cross-border customer service, product demonstrations, intelligent cockpits, and office input.

Of course, iFlytek has so far mainly disclosed capability directions and relative performance. It has not released the complete test-set size, specific WER/CER figures for individual scenarios, or the original results of item-by-item comparisons with competing models. Therefore, the claim that it is “significantly better than the industry’s best performance” still requires further independent testing, particularly across different microphones, sampling rates, numbers of speakers, and domain-specific vocabularies.

3. Dynamic Context Injection: Helping the System Understand “What Is Being Discussed”

Many speech recognition errors occur not because the model failed to hear something, but because it does not know the context.

For example, in medical scenarios, the acoustic difference between “thyroid nodule” and ordinary words may not be obvious. In finance, terms such as “duration,” “net asset value,” and “drawdown” require domain knowledge. In automotive scenarios, model names, road names, and control commands form another specialized vocabulary.

In the past, the usual solution was to maintain a hotword list and pass domain-specific vocabulary to the recognition engine during each call. This approach is effective, but relatively static: if the hotword list is too large, it may affect decoding; if it is too small, it cannot cover changes in real conversations.

Dynamic context injection is more like temporarily providing the recognition system with a set of “on-site materials.” The system can dynamically adjust candidate words based on the current conversation, application scenario, user input history, or business domain. For a smart office notebook, the context may come from the topic of the current meeting. For an in-vehicle assistant, it may come from the navigation destination and vehicle status. For a customer service system, it may come from the support ticket, customer information, and product catalog.

This turns speech recognition from a relatively independent foundational component into a context-aware module within a business system. Its upper limit is no longer determined solely by the acoustic model; it also depends on whether developers can provide the model with business context in an appropriate way.

Complex Acoustic Environments Are Spark-ASR-2.0’s Main Battleground

In quiet environments, the gap between mainstream speech recognition models is narrowing. The real differences in user experience often emerge in uncontrollable environments: subways, shopping malls, conference rooms, vehicles, and outdoor settings, as well as situations in which the speaker is far from the microphone, speaks softly, or talks too quickly.

iFlytek states that Spark-ASR-2.0 delivers significant improvements in high-noise environments, low-volume speech, fast speech, and children’s speech, while also offering advantages over the industry’s best performance in dialect recognition, high-noise tasks, and low-volume tasks.

These scenarios impose different requirements on the model:

• High noise requires the system to extract useful information from the target speaker amid background music, keyboard sounds, wind noise, and conversations among other people;
• Low volume requires the model to process weak acoustic signals and avoid misclassifying low-energy speech as noise;
• Fast speech requires the model to handle connected syllables, omitted sounds, and changes in word boundaries more accurately;
• Children’s speech often features higher pitch, faster variations, and less stable pronunciation patterns;
• Dialect recognition involves more than switching to another vocabulary; it also involves differences in phonology, grammar, tones, and regional patterns of expression.

This is also where iFlytek’s long-term accumulation provides an advantage. Speech recognition cannot be solved solely with general-purpose Internet text. It requires large quantities of real-world audio, data from complex environments, and continuous engineering optimization. In particular, for dialects and noisy environments, there is often a significant gap between laboratory data and real-world business data.

According to iFlytek, the test set for Spark-ASR-2.0 is drawn from real developer requests on the iFlytek Spark App, iFlytek Hearing App, iFlytek Translator, iFlytek Input Method, and iFlytek Open Platform, and is continuously updated. Using real business data for evaluation helps cover more practical problems, but it also makes it more important to disclose the data composition, annotation standards, and evaluation methods. Otherwise, external developers will find it difficult to reproduce the results directly.

A 10% Increase in Inference Costs Is More Important Than Simply Pursuing Accuracy

In the speech API sector, improving model performance is not unusual. The difficult part is keeping costs under control after improving performance.

If a model can reduce the error rate but doubles inference costs, it may only be suitable for offline transcription tasks that are extremely sensitive to accuracy. If a model can improve performance in complex scenarios while keeping costs largely unchanged, it is more likely to be adopted in high-frequency applications such as real-time input, customer service, meetings, and smart hardware.

Spark-ASR-2.0 increases overall inference costs by only about 10% compared with the previous generation. At least from a product-design perspective, iFlytek does not appear to have pursued an upgrade strategy of “using more computing power to achieve a lower error rate.” This is particularly important for large-scale speech applications: with the same budget, developers can process more audio or invest the savings in downstream processing such as speaker diarization, emotion analysis, summary generation, and translation.

However, it should be noted that a “10% increase in overall inference costs” does not mean that the final price of every API request will increase by only 10%. Actual costs are also affected by audio duration, concurrency, real-time versus offline mode, whether speaker diarization is enabled, domain enhancement, and the pricing model of the subscription plan. When migrating models, developers still need to conduct comprehensive cost tests based on real traffic.

Rollout on iFlytek Input Method Begins Tomorrow, Followed by More Hardware Products

According to iFlytek’s plans, Spark-ASR-2.0 will gradually roll out on iFlytek Input Method starting September 24, with API services provided through the iFlytek Open Platform. It will subsequently be deployed in products including iFlytek AI Glasses, iFlytek Smart Office Notebook, and iFlytek Hearing.

iFlytek Input Method is a relatively direct validation scenario. When users speak into their phones, the environment is often uncontrollable, their language is more conversational, and their input may contain a mixture of names, place names, brand names, and Internet slang. If the new model can reduce character errors and improve sentence segmentation in these scenarios, users will notice the difference immediately.

iFlytek Hearing and the Smart Office Notebook are better suited for validating long-audio transcription, meeting scenarios, and multi-speaker conversations. Here, the key is not merely to recognize each sentence, but also to handle timestamps, speaker diarization, proper nouns, paragraph structure, and subsequent summarization. If Spark-ASR-2.0 can integrate “recognition” and “organization” more closely, its value will extend beyond that of an ASR engine: it could become the entry point for meeting and knowledge-management systems.

AI glasses represent another type of challenge. Wearable devices are typically constrained by microphone arrays, power consumption, network connectivity, and the distance between the device and the wearer. Users may not speak directly toward the device either. Recognition of high-noise, low-volume, and far-field speech may be more important than laboratory accuracy in quiet environments.

What Does This Mean for Developers? Start by Looking at Four Metrics

If you are already using a speech recognition API, Spark-ASR-2.0 is worth watching, but you should not focus solely on the phrase “improved performance” from the launch event. During actual integration, you should at least pay close attention to the following metrics:

1. WER/CER on real business data: Do not test only standard Mandarin. Include the names, product names, professional terminology, and Chinese-English mixed expressions most common in your business.
2. Robustness in complex environments: Test conference rooms, vehicles, outdoor settings, conversations among multiple people, and background music separately, and observe whether errors are concentrated in a particular type of scenario.
3. End-to-end latency: For real-time speech applications, distinguish among first-packet latency, stable-result latency, and final-result latency. Do not look only at offline transcription speed.
4. Text post-processing capabilities: Pay attention to sentence segmentation, punctuation, number formatting, English capitalization, proper nouns, and the handling of spoken-language redundancies. These factors directly determine whether the output can be incorporated into business processes without further processing.

For businesses that have already integrated Spark-ASR-1.0, migration costs will theoretically involve more than SDK changes. More importantly, developers will need to revalidate hotwords, domain parameters, context injection, and exception-retry strategies. If the output style of the new model differs from that of the old model, downstream segmentation, summarization, retrieval, and review logic may also need to be adjusted accordingly.

iFlytek’s Advantage Is Shifting from “Recognition Capability” to a “Closed-Loop Scenario”

China’s speech recognition market is no longer simply about comparing whose general-purpose accuracy is higher. Developers care more about whether the model can be integrated reliably, whether it performs consistently in complex scenarios, whether the API supports sufficient customization, whether pricing and concurrency can support their business, and whether a complete engineering toolchain is available when the model makes mistakes.

iFlytek’s advantage lies in its ownership of real business entry points, including an input method, meeting transcription, a translator device, office hardware, and an open platform. Model upgrades can quickly receive feedback from multiple products, which can then feed back into training and evaluation. This “model–product–data–model” loop is not necessarily available to companies focused solely on models.

At the same time, Spark-ASR-2.0’s competitiveness must ultimately be demonstrated through verifiable API performance. Particularly in the developer market, a model name and promotional metrics may generate a first trial, but long-term retention is determined by stability, documentation quality, concurrency policies, pricing transparency, and consistency across scenarios.

Overall, the direction of the Spark-ASR-2.0 release is sound. Rather than limiting the upgrade to a single error-rate metric on a leaderboard, iFlytek is addressing complex acoustics, contextual understanding, and text readability at the same time, while keeping the increase in inference costs to approximately 10%. If the actual API service delivers on the performance described in the release information, iFlytek’s advantages in Chinese speech recognition, dialect recognition, and transcription in complex environments could expand further.

For developers, the gradual rollout of iFlytek Input Method and the Open Platform beginning tomorrow will provide the first opportunities to observe whether this upgrade is genuinely useful. Whether it can become the default speech entry point for meetings, customer service, and smart hardware will depend on latency, pricing, and long-tail error performance under real-world usage.

OpenAI Hub currently aggregates major models including GPT, Claude, Gemini, and DeepSeek, and is compatible with the OpenAI API format, making it suitable for developers who need to manage calls to multiple models in a unified manner. For speech recognition models, whether they will be included in the unified access scope should remain subject to subsequent platform announcements. In actual projects, ASR can also be evaluated separately from large-model summarization, translation, structured extraction, and other stages, avoiding the need to bind every task to a single model.

References

• ITHome: iFlytek Releases New Speech Recognition Foundation Model Spark-ASR-2.0: The primary source for the release date, core technical directions, performance improvements, inference costs, and plans for subsequent product deployment discussed in this article.