尧图网站建设 
MLX Audio 流式音频实战指南TTS 分块合成、STT 实时转录与 WebSocket 低延迟方案【免费下载链接】mlx-audioA text-to-speech (TTS), speech-to-text (STT) and speech-to-speech (STS) library built on Apples MLX framework, providing efficient speech analysis on Apple Silicon.项目地址: https://gitcode.com/GitHub_Trending/ml/mlx-audio导读MLX Audio 是基于 Apple MLX 框架构建的 TTS / STT / STS 库流式Streaming能力让音频不再需要等整段合成完毕才能听到TTS 合成过程中逐块产出音频、STT 在解码过程中逐步吐出文本。本文以 docs/guides/streaming.md 为主线覆盖 CLI、Python API、HTTP API Server 与 WebSocket 四条路径的流式用法并结合仓库源码如 mlx_audio/tts/generate.py、mlx_audio/tts/models/base.py、mlx_audio/server.py讲解streaming_interval的分块原理与GenerationResult数据契约。读完本文你将掌握如何为低延迟语音交互、实时字幕与长音频处理配置并调优流式生成。流式工作原理从整段等待到分块产出流式的核心思想是边生成边返回。非流式模式下generate()会等整句语音全部合成后再一次性返回音频开启流式后generate()变成一个生成器Generator每合成一段音频就yield一个结果对象调用方可以立即将这段音频送入播放器或缓冲区从而实现接近实时的首包延迟。这一点在源码中有清晰体现mlx_audio/tts/generate.py 中的generate_audio()在streamTrue时逐块遍历results每个result对应一块音频若同时playTrue会调用player.queue_audio(result.audio)把每一块依次送入AudioPlayer播放队列见 mlx_audio/tts/audio_player.py。流式与播放是绑定的源码中play play or stream一行表明只要开启--stream就会自动启用--play无需重复传参。CLI 流式 TTS一条--stream命令开始实时播放在任意 TTS 生成命令后追加--stream标志即可启用流式播放。音频会随着块就绪实时播放而不是等整段合成结束mlx_audio.tts.generate \ --model mlx-community/Kokoro-82M-bf16 \ --text Hello, this is a streaming example! \ --lang_code a \ --stream提示流式即播放--stream会自动启用--play二者无需同时传入。源码依据见 mlx_audio/tts/generate.py 中的play play or stream。该命令底层由mlx_audio.tts.generate模块的main()→generate_audio()驱动相关参数定义在 mlx_audio/tts/generate.py 的parse_args()中CLI 参数类型默认值说明--stream布尔开关False以分块形式流式产出音频隐含--play--streaming_intervalfloat秒2.0控制音频块产出的时间间隔--save布尔开关False将流式音频保存为文件要求必须同时开启--stream控制分块大小--streaming_interval--streaming_interval参数单位秒决定音频块多久产出一次。值越小首包延迟越低但每个块都会带来额外的解码与调度开销mlx_audio.tts.generate \ --model mlx-community/Kokoro-82M-bf16 \ --text Adjusting the streaming interval changes latency. \ --lang_code a \ --stream \ --streaming_interval 1.5默认间隔为2.0 秒。从源码看该值不仅传给模型generate()还会被换算为具体的采样帧数。例如 mlx_audio/tts/models/breeze_tts/breeze_tts.py 中以chunk_frames max(1, int(streaming_interval * self.sample_rate / decode_rate))计算单块帧数且明确校验streaming_interval必须为正数Qwen3-TTS 则按max(1, int(streaming_interval * 12.5))换算成 token 块数见下文。把流式结果落盘--save流式模式下若想保存音频文件需要显式传入--save。parse_args()中带有强制约束if args.save and not args.stream: parser.error(--save requires --stream)。保存时可通过--join_audio将所有块拼接为单个文件否则按segment_idx分别落盘对应 mlx_audio/tts/generate.py 中streamed_audio_chunks与streamed_segment_audio两条分支。Python TTS 流式遍历GenerationResult分块所有 TTS 模型的generate()方法都接受streamTrue。开启后它产出的是一个个GenerationResult对象而非等待整段合成from mlx_audio.tts.utils import load_model model load_model(mlx-community/Kokoro-82M-bf16) for result in model.generate( textThis audio will stream chunk by chunk., voiceaf_heart, lang_codea, streamTrue, streaming_interval2.0, ): # result.audio is an mx.array with one chunk of audio print(fChunk: {result.audio.shape[0]} samples) # Feed result.audio to an audio player or bufferGenerationResult定义在 mlx_audio/tts/models/base.py是一个dataclass。流式场景下最关键的是audio、sample_rate与两个流式标记字段属性类型说明audiomx.array本块的波形数据一维采样点数组sample_rateint采样率Hz块与块之间保持一致is_streaming_chunkbool中间块为True用于标记这是流式过程中的一块is_final_chunkbool最后一块为True表示当前序列合成结束此外该 dataclass 还包含samples、segment_idx、token_count、audio_duration、real_time_factor、processing_time_seconds、peak_memory_usage等统计字段。注意is_streaming_chunk与is_final_chunk并非互斥——从源码看流式循环的最后一个块通常同时带is_streaming_chunkTrue与is_final_chunkTrue例如 mlx_audio/tts/models/qwen3_tts/qwen3_tts.py 第 1517-1518 行、mlx_audio/tts/models/higgs_audio/model.py 中的中间块产出逻辑因此判断是否结束应优先看is_final_chunk。流式模型在源码层如何实现不同模型的分块实现细节不同但都遵循按streaming_interval切块、逐块yield的统一契约Qwen3-TTSmlx_audio/tts/models/qwen3_tts/qwen3_tts.py先生成离散音频 token再按streaming_chunk_size max(1, int(streaming_interval * 12.5))分批把 token 送入speech_tokenizer.decoder.streaming_step()做增量解码复用卷积缓冲与 Transformer KV Cache每个批次mx.eval(audio_chunk)后立即yield序列末尾还会reset_streaming_state()清理状态。Breeze-TTSmlx_audio/tts/models/breeze_tts/breeze_tts.py按streaming_interval * sample_rate / decode_rate计算帧块大小逐块yield并标记is_streaming_chunk/is_final_chunk。Higgs-Audiomlx_audio/tts/models/higgs_audio/model.py支持生成中途流式每个yield设is_streaming_chunkTrue最后一个设is_final_chunkTruestreaming_interval同样参与分块节奏。这种统一GenerationResult契约 模型各自实现分块的设计使得调用方代码对所有模型保持一致。Qwen3-TTS 流式三通道生成 12.5 Hz 分块Qwen3-TTS 模型在全部三种生成方法上都支持流式generate()、generate_custom_voice()、generate_voice_design()。典型用法from mlx_audio.tts.utils import load_model model load_model(mlx-community/Qwen3-TTS-12Hz-1.7B-CustomVoice-6bit) audio_chunks [] for result in model.generate( textHello, how are you today?, voiceserena, streamTrue, streaming_interval0.32, # ~4 tokens at 12.5 Hz ): audio_chunks.append(result.audio) # Play or process each chunk for low-latency outputQwen3-TTS 的流式间隔说明Qwen3-TTS 的音频 token 速率约为 12.5 Hz即每秒约 12.5 个 token。streaming_interval设为0.32秒时每个块大约包含 4 个 token0.32 × 12.5 ≈ 4。取值越小延迟越低但分块/解码开销越大。这一换算在源码中有直接依据Qwen3-TTS 的多个生成入口generate_custom_voice()、generate_voice_design()等内部统一使用streaming_chunk_size max(1, int(streaming_interval * 12.5))决定每次增量解码的 token 数量见 mlx_audio/tts/models/qwen3_tts/qwen3_tts.py。STT 流式解码过程中逐步输出文本多个语音识别STT模型支持流式转录。核心写法同样是给generate()传streamTrue逐块拿到文本增量。根据模型能力差异仓库提供了两种接口形态从源码可确认一类是generate(..., streamTrue)直接逐块产出文本增量另一类是专门的stream_transcribe()方法如 mlx_audio/stt/models/vibevoice_asr/vibevoice_asr.py、mlx_audio/stt/models/mega_asr/mega_asr.py、mlx_audio/stt/models/qwen3_asr/qwen3_asr.py。Voxtral Realtimegenerate(..., streamTrue)形态from mlx_audio.stt.utils import load model load(mlx-community/Voxtral-Mini-4B-Realtime-2602-4bit) for chunk in model.generate(audio.wav, streamTrue): print(chunk, end, flushTrue)该模型专为实时场景设计其流式实现在 mlx_audio/stt/models/voxtral_realtime/voxtral_realtime.pygenerate()在streamTrue时逐块产出文本增量配合flushTrue可实现边说边出字的字幕效果。Parakeet分段转录 时间戳from mlx_audio.stt.utils import load model load(mlx-community/parakeet-tdt-0.6b-v3) for chunk in model.generate(long_audio.wav, streamTrue): print(chunk.text, end, flushTrue)Parakeet 的generate()在流式模式下产出StreamingResult每个块除text外还带有对齐 token 与句子级时间信息参考 mlx_audio/stt/models/parakeet/parakeet.py 中关于流式返回的说明。VibeVoice-ASRstream_transcribe()形态from mlx_audio.stt.utils import load model load(mlx-community/VibeVoice-ASR-bf16) for text in model.stream_transcribe(audiospeech.wav, max_tokens4096): print(text, end, flushTrue)VibeVoice-ASR 使用独立的stream_transcribe()接口max_tokens控制单次生成的最大 token 数逐块返回识别文本实现见 mlx_audio/stt/models/vibevoice_asr/vibevoice_asr.py。流式 STT 的 CLI 用法STT 侧同样提供 CLI 流式入口python -m mlx_audio.stt.generate \ --model mlx-community/whisper-large-v3-turbo-asr-fp16 \ --audio speech.wav \ --output-path output \ --format json \ --stream该 CLI 由 mlx_audio/stt/generate.py 实现--stream开关定义在其中输出格式支持txt/srt/vtt/json四种--format参数。流式模式下generate_transcription()会遍历模型的每个流式结果把result.text累积拼接成完整文本并汇总语言、token 统计与耗时信息最后按指定格式落盘。选择json格式时每个片段还会保留start、end、is_final等字段便于下游做带时间戳的实时字幕。API Server 流式HTTP 请求中的stream: true启动 API Server 后mlx_audio.serverTTS 与 STT 两个端点均支持流式。只需在请求体中设置stream: true相关字段定义在 mlx_audio/server.pySpeechRequest/ 转录请求模型均含stream: bool False与streaming_interval: float 2.0。流式 TTSPOST /v1/audio/speechcurl -X POST http://localhost:8000/v1/audio/speech \ -H Content-Type: application/json \ -d { model: mlx-community/Kokoro-82M-bf16, input: Streaming over HTTP!, voice: af_heart, stream: true, streaming_interval: 2.0, response_format: wav } \ --output streamed_speech.wav服务端收到streamtrue后会以流式方式生成音频块并通过 HTTP 响应逐步下发源码中speech_request.stream与speech_request.streaming_interval会原样传入底层generate_audio()见 mlx_audio/server.py。response_format指定音频编码如wav。流式 STTPOST /v1/audio/transcriptionscurl -X POST http://localhost:8000/v1/audio/transcriptions \ -F fileaudio.wav \ -F modelmlx-community/whisper-large-v3-turbo-asr-fp16 \ -F streamtrue流式 STT 的响应格式为 newline-delimited JSONapplication/x-ndjson每一行是一个独立的 JSON 对象包含text字段以及可选的时序信息时间戳等。这种逐行 JSON的传输方式天然适合流式消费客户端可以按行解析边接收边渲染字幕无需等待整个转录完成。从 mlx_audio/server.py 源码看该端点的流式响应显式使用media_typeapplication/x-ndjson并可通过response_format在ndjson默认与其它格式间切换。实时 WebSocket 转录面向麦克风等连续音频流对于实时麦克风输入或连续音频流场景API Server 额外暴露了一个 WebSocket 端点ws://localhost:8000/v1/audio/transcriptions/realtime其处理逻辑mlx_audio/server.py 中的_stream_transcription会根据模型能力自动分流若模型的generate()签名中带有stream参数即支持流式则直接对收到的音频数组以streamTrue方式逐块推理实时推送文本增量否则退化为临时文件 批量生成的兼容路径一次性返回结果。这保证了端点对不同 STT 模型的统一可用性。WebSocket 长连接模式避免了 HTTP 每次请求的握手开销适合语音助手、实时字幕、会议转写等持续音频输入场景。调优与工程实践建议延迟 vs. 质量streaming_interval越小首块产出越快、整体延迟越低但分块边界更多、单块解码与调度开销上升。建议先使用默认值2.0 秒确认管线正常再按实际场景逐步调小找到延迟与开销的平衡点。内存占用流式不会显著改变峰值内存——模型权重始终驻留显存流式改变的只是解码完成的音频在何时被返回先于整段合成返回而非加载更少的权重。因此不必担心开启流式导致内存暴涨。拼接分块为完整文件若最终需要单个连续音频文件可在循环中收集所有result.audio数组结束后一次性拼接并写出import mlx.core as mx from mlx_audio.audio_io import write chunks [result.audio for result in model.generate(..., streamTrue)] audio mx.concatenate(chunks, axis0) write(joined.wav, audio, model.sample_rate, formatwav)这与仓库内部write_joined_audio()的做法一致见 mlx_audio/tts/generate.py多个块用mx.concatenate(audio_chunks, axis0)沿时间轴拼接再交给mlx_audio.audio_io.write()统一写出。判断流式结束遍历GenerationResult时以is_final_chunk为准判断序列是否结束而不是依赖is_streaming_chunk最后一个中间块会同时置为True。STT 增量合并CLI 层的流式转录会自动累积各块文本在 Python 层自行消费时注意区分增量文本与累计文本两种模型行为避免重复拼接mlx_audio/stt/generate.py 中已有对两种形态的兼容处理。总结MLX Audio 的流式能力覆盖了完整链路CLI 一行命令实时播放--stream--streaming_interval、Python API 逐块消费GenerationResult含is_streaming_chunk/is_final_chunk标记、HTTP 端点的stream请求STT 返回application/x-ndjson、以及面向连续音频的 WebSocket 实时转录端点。分块节奏由streaming_interval统一控制不同模型Qwen3-TTS、Breeze-TTS、Higgs-Audio、Whisper、Parakeet、Voxtral Realtime 等在底层各自实现增量解码但对调用方保持一致的流式契约。合理调整间隔、善用块标记与拼接策略即可在 Apple Silicon 上构建低延迟的语音交互应用。【免费下载链接】mlx-audioA text-to-speech (TTS), speech-to-text (STT) and speech-to-speech (STS) library built on Apples MLX framework, providing efficient speech analysis on Apple Silicon.项目地址: https://gitcode.com/GitHub_Trending/ml/mlx-audio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MLX Audio 流式音频实战指南：TTS 分块合成、STT 实时转录与 WebSocket 低延迟方案
MLX Audio 流式音频实战指南TTS 分块合成、STT 实时转录与 WebSocket 低延迟方案【免费下载链接】mlx-audioA text-to-speech (TTS), speech-to-text (STT) and speech-to-speech (STS) library built on Apples MLX framework, providing efficient speech analysis on Apple Silicon.项目地址: https://gitcode.com/GitHub_Trending/ml/mlx-audio导读MLX Audio 是基于 Apple MLX 框架构建的 TTS / STT / STS 库流式Streaming能力让音频不再需要等整段合成完毕才能听到TTS 合成过程中逐块产出音频、STT 在解码过程中逐步吐出文本。本文以 docs/guides/streaming.md 为主线覆盖 CLI、Python API、HTTP API Server 与 WebSocket 四条路径的流式用法并结合仓库源码如 mlx_audio/tts/generate.py、mlx_audio/tts/models/base.py、mlx_audio/server.py讲解streaming_interval的分块原理与GenerationResult数据契约。读完本文你将掌握如何为低延迟语音交互、实时字幕与长音频处理配置并调优流式生成。流式工作原理从整段等待到分块产出流式的核心思想是边生成边返回。非流式模式下generate()会等整句语音全部合成后再一次性返回音频开启流式后generate()变成一个生成器Generator每合成一段音频就yield一个结果对象调用方可以立即将这段音频送入播放器或缓冲区从而实现接近实时的首包延迟。这一点在源码中有清晰体现mlx_audio/tts/generate.py 中的generate_audio()在streamTrue时逐块遍历results每个result对应一块音频若同时playTrue会调用player.queue_audio(result.audio)把每一块依次送入AudioPlayer播放队列见 mlx_audio/tts/audio_player.py。流式与播放是绑定的源码中play play or stream一行表明只要开启--stream就会自动启用--play无需重复传参。CLI 流式 TTS一条--stream命令开始实时播放在任意 TTS 生成命令后追加--stream标志即可启用流式播放。音频会随着块就绪实时播放而不是等整段合成结束mlx_audio.tts.generate \ --model mlx-community/Kokoro-82M-bf16 \ --text Hello, this is a streaming example! \ --lang_code a \ --stream提示流式即播放--stream会自动启用--play二者无需同时传入。源码依据见 mlx_audio/tts/generate.py 中的play play or stream。该命令底层由mlx_audio.tts.generate模块的main()→generate_audio()驱动相关参数定义在 mlx_audio/tts/generate.py 的parse_args()中CLI 参数类型默认值说明--stream布尔开关False以分块形式流式产出音频隐含--play--streaming_intervalfloat秒2.0控制音频块产出的时间间隔--save布尔开关False将流式音频保存为文件要求必须同时开启--stream控制分块大小--streaming_interval--streaming_interval参数单位秒决定音频块多久产出一次。值越小首包延迟越低但每个块都会带来额外的解码与调度开销mlx_audio.tts.generate \ --model mlx-community/Kokoro-82M-bf16 \ --text Adjusting the streaming interval changes latency. \ --lang_code a \ --stream \ --streaming_interval 1.5默认间隔为2.0 秒。从源码看该值不仅传给模型generate()还会被换算为具体的采样帧数。例如 mlx_audio/tts/models/breeze_tts/breeze_tts.py 中以chunk_frames max(1, int(streaming_interval * self.sample_rate / decode_rate))计算单块帧数且明确校验streaming_interval必须为正数Qwen3-TTS 则按max(1, int(streaming_interval * 12.5))换算成 token 块数见下文。把流式结果落盘--save流式模式下若想保存音频文件需要显式传入--save。parse_args()中带有强制约束if args.save and not args.stream: parser.error(--save requires --stream)。保存时可通过--join_audio将所有块拼接为单个文件否则按segment_idx分别落盘对应 mlx_audio/tts/generate.py 中streamed_audio_chunks与streamed_segment_audio两条分支。Python TTS 流式遍历GenerationResult分块所有 TTS 模型的generate()方法都接受streamTrue。开启后它产出的是一个个GenerationResult对象而非等待整段合成from mlx_audio.tts.utils import load_model model load_model(mlx-community/Kokoro-82M-bf16) for result in model.generate( textThis audio will stream chunk by chunk., voiceaf_heart, lang_codea, streamTrue, streaming_interval2.0, ): # result.audio is an mx.array with one chunk of audio print(fChunk: {result.audio.shape[0]} samples) # Feed result.audio to an audio player or bufferGenerationResult定义在 mlx_audio/tts/models/base.py是一个dataclass。流式场景下最关键的是audio、sample_rate与两个流式标记字段属性类型说明audiomx.array本块的波形数据一维采样点数组sample_rateint采样率Hz块与块之间保持一致is_streaming_chunkbool中间块为True用于标记这是流式过程中的一块is_final_chunkbool最后一块为True表示当前序列合成结束此外该 dataclass 还包含samples、segment_idx、token_count、audio_duration、real_time_factor、processing_time_seconds、peak_memory_usage等统计字段。注意is_streaming_chunk与is_final_chunk并非互斥——从源码看流式循环的最后一个块通常同时带is_streaming_chunkTrue与is_final_chunkTrue例如 mlx_audio/tts/models/qwen3_tts/qwen3_tts.py 第 1517-1518 行、mlx_audio/tts/models/higgs_audio/model.py 中的中间块产出逻辑因此判断是否结束应优先看is_final_chunk。流式模型在源码层如何实现不同模型的分块实现细节不同但都遵循按streaming_interval切块、逐块yield的统一契约Qwen3-TTSmlx_audio/tts/models/qwen3_tts/qwen3_tts.py先生成离散音频 token再按streaming_chunk_size max(1, int(streaming_interval * 12.5))分批把 token 送入speech_tokenizer.decoder.streaming_step()做增量解码复用卷积缓冲与 Transformer KV Cache每个批次mx.eval(audio_chunk)后立即yield序列末尾还会reset_streaming_state()清理状态。Breeze-TTSmlx_audio/tts/models/breeze_tts/breeze_tts.py按streaming_interval * sample_rate / decode_rate计算帧块大小逐块yield并标记is_streaming_chunk/is_final_chunk。Higgs-Audiomlx_audio/tts/models/higgs_audio/model.py支持生成中途流式每个yield设is_streaming_chunkTrue最后一个设is_final_chunkTruestreaming_interval同样参与分块节奏。这种统一GenerationResult契约 模型各自实现分块的设计使得调用方代码对所有模型保持一致。Qwen3-TTS 流式三通道生成 12.5 Hz 分块Qwen3-TTS 模型在全部三种生成方法上都支持流式generate()、generate_custom_voice()、generate_voice_design()。典型用法from mlx_audio.tts.utils import load_model model load_model(mlx-community/Qwen3-TTS-12Hz-1.7B-CustomVoice-6bit) audio_chunks [] for result in model.generate( textHello, how are you today?, voiceserena, streamTrue, streaming_interval0.32, # ~4 tokens at 12.5 Hz ): audio_chunks.append(result.audio) # Play or process each chunk for low-latency outputQwen3-TTS 的流式间隔说明Qwen3-TTS 的音频 token 速率约为 12.5 Hz即每秒约 12.5 个 token。streaming_interval设为0.32秒时每个块大约包含 4 个 token0.32 × 12.5 ≈ 4。取值越小延迟越低但分块/解码开销越大。这一换算在源码中有直接依据Qwen3-TTS 的多个生成入口generate_custom_voice()、generate_voice_design()等内部统一使用streaming_chunk_size max(1, int(streaming_interval * 12.5))决定每次增量解码的 token 数量见 mlx_audio/tts/models/qwen3_tts/qwen3_tts.py。STT 流式解码过程中逐步输出文本多个语音识别STT模型支持流式转录。核心写法同样是给generate()传streamTrue逐块拿到文本增量。根据模型能力差异仓库提供了两种接口形态从源码可确认一类是generate(..., streamTrue)直接逐块产出文本增量另一类是专门的stream_transcribe()方法如 mlx_audio/stt/models/vibevoice_asr/vibevoice_asr.py、mlx_audio/stt/models/mega_asr/mega_asr.py、mlx_audio/stt/models/qwen3_asr/qwen3_asr.py。Voxtral Realtimegenerate(..., streamTrue)形态from mlx_audio.stt.utils import load model load(mlx-community/Voxtral-Mini-4B-Realtime-2602-4bit) for chunk in model.generate(audio.wav, streamTrue): print(chunk, end, flushTrue)该模型专为实时场景设计其流式实现在 mlx_audio/stt/models/voxtral_realtime/voxtral_realtime.pygenerate()在streamTrue时逐块产出文本增量配合flushTrue可实现边说边出字的字幕效果。Parakeet分段转录 时间戳from mlx_audio.stt.utils import load model load(mlx-community/parakeet-tdt-0.6b-v3) for chunk in model.generate(long_audio.wav, streamTrue): print(chunk.text, end, flushTrue)Parakeet 的generate()在流式模式下产出StreamingResult每个块除text外还带有对齐 token 与句子级时间信息参考 mlx_audio/stt/models/parakeet/parakeet.py 中关于流式返回的说明。VibeVoice-ASRstream_transcribe()形态from mlx_audio.stt.utils import load model load(mlx-community/VibeVoice-ASR-bf16) for text in model.stream_transcribe(audiospeech.wav, max_tokens4096): print(text, end, flushTrue)VibeVoice-ASR 使用独立的stream_transcribe()接口max_tokens控制单次生成的最大 token 数逐块返回识别文本实现见 mlx_audio/stt/models/vibevoice_asr/vibevoice_asr.py。流式 STT 的 CLI 用法STT 侧同样提供 CLI 流式入口python -m mlx_audio.stt.generate \ --model mlx-community/whisper-large-v3-turbo-asr-fp16 \ --audio speech.wav \ --output-path output \ --format json \ --stream该 CLI 由 mlx_audio/stt/generate.py 实现--stream开关定义在其中输出格式支持txt/srt/vtt/json四种--format参数。流式模式下generate_transcription()会遍历模型的每个流式结果把result.text累积拼接成完整文本并汇总语言、token 统计与耗时信息最后按指定格式落盘。选择json格式时每个片段还会保留start、end、is_final等字段便于下游做带时间戳的实时字幕。API Server 流式HTTP 请求中的stream: true启动 API Server 后mlx_audio.serverTTS 与 STT 两个端点均支持流式。只需在请求体中设置stream: true相关字段定义在 mlx_audio/server.pySpeechRequest/ 转录请求模型均含stream: bool False与streaming_interval: float 2.0。流式 TTSPOST /v1/audio/speechcurl -X POST http://localhost:8000/v1/audio/speech \ -H Content-Type: application/json \ -d { model: mlx-community/Kokoro-82M-bf16, input: Streaming over HTTP!, voice: af_heart, stream: true, streaming_interval: 2.0, response_format: wav } \ --output streamed_speech.wav服务端收到streamtrue后会以流式方式生成音频块并通过 HTTP 响应逐步下发源码中speech_request.stream与speech_request.streaming_interval会原样传入底层generate_audio()见 mlx_audio/server.py。response_format指定音频编码如wav。流式 STTPOST /v1/audio/transcriptionscurl -X POST http://localhost:8000/v1/audio/transcriptions \ -F fileaudio.wav \ -F modelmlx-community/whisper-large-v3-turbo-asr-fp16 \ -F streamtrue流式 STT 的响应格式为 newline-delimited JSONapplication/x-ndjson每一行是一个独立的 JSON 对象包含text字段以及可选的时序信息时间戳等。这种逐行 JSON的传输方式天然适合流式消费客户端可以按行解析边接收边渲染字幕无需等待整个转录完成。从 mlx_audio/server.py 源码看该端点的流式响应显式使用media_typeapplication/x-ndjson并可通过response_format在ndjson默认与其它格式间切换。实时 WebSocket 转录面向麦克风等连续音频流对于实时麦克风输入或连续音频流场景API Server 额外暴露了一个 WebSocket 端点ws://localhost:8000/v1/audio/transcriptions/realtime其处理逻辑mlx_audio/server.py 中的_stream_transcription会根据模型能力自动分流若模型的generate()签名中带有stream参数即支持流式则直接对收到的音频数组以streamTrue方式逐块推理实时推送文本增量否则退化为临时文件 批量生成的兼容路径一次性返回结果。这保证了端点对不同 STT 模型的统一可用性。WebSocket 长连接模式避免了 HTTP 每次请求的握手开销适合语音助手、实时字幕、会议转写等持续音频输入场景。调优与工程实践建议延迟 vs. 质量streaming_interval越小首块产出越快、整体延迟越低但分块边界更多、单块解码与调度开销上升。建议先使用默认值2.0 秒确认管线正常再按实际场景逐步调小找到延迟与开销的平衡点。内存占用流式不会显著改变峰值内存——模型权重始终驻留显存流式改变的只是解码完成的音频在何时被返回先于整段合成返回而非加载更少的权重。因此不必担心开启流式导致内存暴涨。拼接分块为完整文件若最终需要单个连续音频文件可在循环中收集所有result.audio数组结束后一次性拼接并写出import mlx.core as mx from mlx_audio.audio_io import write chunks [result.audio for result in model.generate(..., streamTrue)] audio mx.concatenate(chunks, axis0) write(joined.wav, audio, model.sample_rate, formatwav)这与仓库内部write_joined_audio()的做法一致见 mlx_audio/tts/generate.py多个块用mx.concatenate(audio_chunks, axis0)沿时间轴拼接再交给mlx_audio.audio_io.write()统一写出。判断流式结束遍历GenerationResult时以is_final_chunk为准判断序列是否结束而不是依赖is_streaming_chunk最后一个中间块会同时置为True。STT 增量合并CLI 层的流式转录会自动累积各块文本在 Python 层自行消费时注意区分增量文本与累计文本两种模型行为避免重复拼接mlx_audio/stt/generate.py 中已有对两种形态的兼容处理。总结MLX Audio 的流式能力覆盖了完整链路CLI 一行命令实时播放--stream--streaming_interval、Python API 逐块消费GenerationResult含is_streaming_chunk/is_final_chunk标记、HTTP 端点的stream请求STT 返回application/x-ndjson、以及面向连续音频的 WebSocket 实时转录端点。分块节奏由streaming_interval统一控制不同模型Qwen3-TTS、Breeze-TTS、Higgs-Audio、Whisper、Parakeet、Voxtral Realtime 等在底层各自实现增量解码但对调用方保持一致的流式契约。合理调整间隔、善用块标记与拼接策略即可在 Apple Silicon 上构建低延迟的语音交互应用。【免费下载链接】mlx-audioA text-to-speech (TTS), speech-to-text (STT) and speech-to-speech (STS) library built on Apples MLX framework, providing efficient speech analysis on Apple Silicon.项目地址: https://gitcode.com/GitHub_Trending/ml/mlx-audio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考