Abstract Text-to-Speech (TTS) is an essential module that provides spoken responses in an LLM-centered spoken dialogue system (SDS). To ensure accurate TTS synthesis, responses generated by an LLM must be converted into TTS-readable formats via a Text Normalization (TN) module, imposing strict low-latency requirements in real-time SDS scenarios. Existing TN solutions are largely rule-based, rely on manual engineering, and generalize poorly to unseen patterns. Although an LLM itself can perform TN through prompt engineering, it faces key limitations: high first-token latency due to non-streaming processing, hallucination risks, and degraded intelligence or reasoning when the core LLM module is fine-tuned solely for TN. To address these challenges, we propose StreamTN, a lightweight LLM-based Chinese streaming TN model. Built on Qwen3-0.6B, StreamTN employs a dual-track streaming framework in which input tokens and output tokens are processed on two parallel tracks, enabling low-latency real-time inference without complex prompting. Moreover, task-specific fine-tuning yields superior TN performance and fewer hallucinations than rule-based systems and general-purpose LLMs. We also introduce a TN benchmark that spans diverse text scenarios, providing a comprehensive evaluation standard for speech generation in spoken dialogue systems. Experiments demonstrate the effectiveness of StreamTN in accuracy and inference latency.

This page is for research demonstration purposes only.

Contents

System Overview

Figure 1. The architecture of our proposed StreamTN model.

Case Studies

Integers and Decimals

Ordinal Numbers

Phone Numbers

Time

Military Passwords

Capital Amounts

Physical Units

Chemical Formulas and Equations

Daily Chemicals

Simple Mathematical Equations

Fractions and Percentages

Years and Dates

Amount Readings

Complex Mathematical Equations

Delay Frame Analysis

Latency measurement setup. The upstream LLM (Qwen3-32B) is served with vLLM on 2×A6000 GPUs (tensor_parallel_size=2, greedy decoding, gpu_memory_utilization=0.9, dtype=auto), producing roughly 20 tokens/s. StreamTN and all local TN baselines run on a single NVIDIA A6000 GPU. Encoding all test inputs with the Qwen3 tokenizer gives a mean length of 27.58 tokens. FPD (ms) denotes First Packet Delay, decomposed as upstream waiting (the time to receive the first d tokens) plus StreamTN computation. The configuration marked with * is adopted in our main experiments.

Appendix: Supplementary Experiments

Detailed latency decomposition, full evaluation metrics, and ablations referenced in the rebuttal.

A. Latency Comparison

FPD is the sum of the upstream waiting time and the TN computation time. Streaming StreamTN starts after receiving the first d tokens from Qwen3-32B (~20 tokens/s on 2×A6000). Non-streaming methods must wait for the complete input (a mean of 27.58 tokens → roughly 1.4 s at 20 tokens/s) before producing any output, which is the architectural latency advantage of the dual-track design.

* configuration adopted in our main experiments. For streaming rows, “Upstream Wait” is the time to receive the first d tokens and “TN Compute” is StreamTN’s incremental first-token compute. For non-streaming methods, “Upstream Wait” is the time to receive the complete input, a simulated estimate (≈1.4 s) obtained from the mean input length (27.58 tokens) divided by the upstream token rate (~20 tokens/s) rather than a directly measured value. FPD is therefore dominated by this wait, and the method’s own compute (mean, shown in the “TN Compute” column, ≤50 ms) adds only a negligible amount. TN compute for BiLSTM and non-streaming StreamTN is the time to the first output token; for the other non-streaming methods it is the full-output processing time.

B. Full Evaluation Metrics

Character-level Micro-F1 is the primary metric because it accommodates pronunciation-equivalent variants (e.g., “2900¥” → “两千九百元” or “二千九百元” are both correct for TTS). Sentence-level exact match and CER are reported as complementary, stricter metrics.

C. Prompt Used for the General-Purpose LLM Baseline

The exact prompt used to evaluate the non-fine-tuned Qwen3-0.6B baseline:

messages = [
    {"role": "system", "content": "你是一个专业的文本标准化助手，请为我做一个文本标准化任务，将原始文本中的数字时间符号等全部标准化为汉字，用于后续TTS系统合成。"},
    {"role": "user", "content": raw_text.strip()}
]

More detailed rule-based prompts were also tested but substantially increased per-item latency while still causing frequent insertion, deletion, and out-of-input hallucination errors.

D. Zero-Vector Ablation: Shared Zero vs. Learned Delay Embedding

In the dual-track design, the input and output embeddings are added element-wise. During the delay phase the output track contributes a zero vector, so the summed embedding carries only the raw input; once the input ends, the input track contributes a zero vector, so the summed embedding carries only the output history. The phase is therefore recoverable from whichever track is nonzero, which is why sharing a single zero vector for delay and pad does not confuse the model. Replacing it with a learned delay embedding yields no consistent gain.

E. LoRA Rank / Alpha Ablation

With learning rate 1e-5 and the q/k/v/o projections fixed, a rank sweep (α=4r) raises Micro-F1 from 0.5228 (r=2) to 0.7292 (r=32), still below full fine-tuning (0.8937 at d=4). The gap is therefore configuration-dependent rather than an inherent LoRA limitation.

F. Error Analysis

On the 1,262-sample test set, 565 samples (44.8%) contain at least one character-level error. Character-level Levenshtein alignment (tie priority S>D>I) yields 33,684 matches, 2,736 substitutions (51.9%), 1,264 deletions (24.0%), and 1,271 insertions (24.1%), for 5,271 total edits.

Complex chemistry and advanced mathematics account for 11.9% of samples but 60.7% of total edits, indicating that whole-expression rewrites and omissions (hallucination / context loss) are the dominant failure mode for these categories, rather than tokenizer fragmentation alone.

High-Frequency Edits