vLLM-Omni 单阶段 AR 模式实践以 MOSS-TTS-Nano 为例的端到端流式 TTS 接入指南【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni导读本文讲解 vLLM-Omni 中的Single-Stage AR单阶段自回归接入模式当上游模型无法干净地拆分为AR 语言模型 独立解码器时典型如 MOSS-TTS-Nano以及所有通过inference_stream()生成器把 AR 与 codec 捆绑在一起的模型如何把整条流水线放进一个 AR worker 中、按请求逐块产出音频。读完本文你将掌握这种模式的模型实现骨架、pipeline.py固定拓扑声明、deploy YAML 的运行时配置要点以及流式生命周期与 lint 纪律的完整实战方案。本文以仓库内.claude/skills/add-tts-model/references/single-stage-ar.md为骨架结合 MOSS-TTS-Nano 的真实落地代码展开。为什么需要单阶段 AR 模式vLLM-Omni 的编排模型通常鼓励多阶段拓扑AR 阶段做文本/自回归推理扩散或 VAE 阶段做音频/图像解码。但并非所有上游模型都适合这种切分无法干净拆分部分模型的inference_stream()生成器把 AR LM 与音频 codec 绑定在同一个循环里逐帧产出音频事件强共享状态远程模型与音频 tokenizer 共享进程级 RNG 与流式解码状态跨请求并发会导致音频损坏这直接决定了后文max_num_seqs1的限制体积小、无需多卡如 MOSS-TTS-Nano 仅 0.1BAR LM 与 MOSS-Audio-Tokenizer-Nano 合起来约 2 GiB单卡即可容纳。此时正确的做法是把整条流水线运行在单个 AR worker 内模型forward()每次被调用时从 per-request 生成器中弹出一个音频块由 AR 调度器维持请求存活直到最后一个块产出。需要区分的是VoxCPM2 虽然也是单阶段运行但它在基础语言模型上使用 vLLM 原生 PagedAttention并在 vLLM 之外做扩散/VAE 旁路计算属于另一变体见plan/voxcpm2_native_ar_design.md的原始设计说明不在本文范围内。模型实现骨架参考文档给出的实现分为三步每一步在 MOSS-TTS-Nano 的真实代码中都有对应落点。1. 单一模型文件同时加载 AR LM 与 codecMOSS-TTS-Nano 的 AR 语言模型与音频 tokenizer 都加载在同一个MossTTSNanoForGeneration内见 modeling_moss_tts_nano.pyclass MossTTSNanoForGeneration(nn.Module): requires_raw_input_tokens True have_multimodal_outputs True has_preprocess False has_postprocess False enable_update_additional_information True def __init__(self, *, vllm_config: VllmConfig, prefix: str ) - None: super().__init__() ... self._lm: nn.Module lm # AR LM0.1B self._audio_tokenizer: nn.Module audio_tokenizer # MOSS-Audio-Tokenizer-Nano self._stream_gens: dict[str, Any] {} # request_key → generator self._ar_last_chunk_flags: list[bool] [] # 与最近一次 forward batch 对齐的 EOS 掩码模型类声明了have_multimodal_outputs True并以OmniOutput作为返回类型通过multimodal_outputs{model_outputs: ..., sr: ...}携带音频波形与采样率。2. 权重加载的时机__init__与load_weights()的取舍参考文档强调在load_weights()中加载权重而不是__init__()理由是 vLLM 会在任何 CUDA 分配之前初始化分布式状态。但 MOSS-TTS-Nano 的真实实现注释给出了一个有意偏离它在__init__中通过AutoModelForCausalLM.from_pretrained(...)急切构造模型目的是让load_format: dummy可用DummyModelLoader会跳过load_weights但急切构造保证参数已就位避免 vLLM init 后 KV-cache profiling 带来的 OOM与 qwen3_ttsPR #3117的做法保持一致。对应的load_weights()只做排空迭代器 上报全部参数def load_weights(self, weights: Iterable[tuple[str, torch.Tensor]]) - set[str]: for _ in weights: pass return {name for name, _ in self.named_parameters()}从源码结构看这属于从__init__急切加载 load_weights空实现的变体——如果你的模型通过 vLLM 的load_format机制加载权重仍应遵循文档的通用原则在load_weights()中加载选择哪种取决于是否需要dummy加载与 KV-cache profiling 的兼容性。此外真实代码还包含两个值得注意的加载细节transformers 兼容垫片_hf_load_without_tp_warmup()上下文管理器临时把transformers.modeling_utils._is_torch_distributed_initialized置为False规避 transformers 5.8.x 在torch.distributed已初始化时对_tp_planNone的 remote-code 模型做 warmup 导致的TypeErrortransformers_keys_to_ignore_compat()则处理 transformers 5.9 的 keys list-vs-set 变更RoPE 权重修复reinit_rotary_inv_freq(lm, base10000.0)重新初始化以persistentFalse注册的inv_freq缓冲区否则trust_remote_code的自定义 RoPE 类会在首次 forward 时产生 NaN logits。3. 通过 per-request 生成器流式输出参考文档给出的核心模式是forward()根据runtime_additional_information每个请求一个 dict拿到 request_key首次见到该 key 时创建生成器存入self._stream_gens之后每次next()弹出一个(waveform, is_last)元组is_last为真时删除生成器。MOSS-TTS-Nano 的实现进一步明确了 request_key 的取值request_key str(info.get(global_request_id) or info.get(_omni_req_id) or id(info))代码注释说明global_request_id由引擎设置info 键集合为[text, mode, prompt_audio_array, global_request_id, omni_final_stage_id, generated_len]而_omni_req_id是永不会被当前引擎设置的遗留回退键——如果回退到常量所有请求会塌缩到同一个生成器请求 N 的残留块会重放给请求 N1表现为后一个请求的音频与前一请求输入一致的串扰。这一点对文档中request ID 由 vLLM 设置的说明做了重要补充新引擎下应优先使用global_request_id。生成器主体遍历上游inference_stream()事件流同时处理两种事件类型def _create_stream_gen(self, info: dict[str, Any]): ... for event in self._lm.inference_stream( texttext, output_audio_pathoutput_path, modemode, prompt_textprompt_text, prompt_audio_pathprompt_audio_path, text_tokenizer_pathself.model_path, audio_tokenizerself._audio_tokenizer, devicedevice, nqNone, max_new_framesmax_new_frames, do_sampleTrue, use_kv_cacheTrue, **sampling, ): event_type str(event.get(type, )) if event_type audio: waveform event.get(waveform) if waveform is not None: chunk _to_mono_1d(waveform) audio_chunks.append(chunk) yield chunk, False # 增量块is_lastFalse elif event_type result: if not audio_chunks: # 回退无增量块时使用最终合并结果 waveform event.get(waveform) if waveform is not None: yield _to_mono_1d(waveform), True return yield torch.zeros((0,), dtypetorch.float32), True # 结束哨兵这里包含三个工程细节事件双路径audio增量与result最终合并两种事件都要处理短句在某些后端上可能只发result声道混合_to_mono_1d()对(channels, samples)张量按 channel 求均值降为单声道——MOSS 音频 tokenizer 配置为双声道若用.T.reshape(-1)直接展平会把 L/R 交错成 2 倍长度流以 1× 采样率回放导致播放速度慢一倍RNG 状态保存/恢复seed非空时快照并恢复 CPU/GPU RNG 状态避免上游依赖全局 RNG 的采样逻辑污染引擎其他组件。forward()对 dummy/profiling 调用有专门分支当runtime_additional_information为空或全部_is_dummy时直接返回空输出并置self._ar_last_chunk_flags [True] * len(infos)立即结束请求dummy 信息由get_dummy_runtime_additional_information()提供。正常路径下每次next(generator)弹出一个块并更新逐行 EOS 掩码。4. 用compute_logits()控制 AR 调度器的请求生命周期单阶段 AR 模式下forward()本身不产出真正的 logits请求何时结束由compute_logits()决定。MOSS-TTS-Nano 的实现按行构造 logitsdef compute_logits(self, hidden_states, sampling_metadataNone): ... for row in range(num_rows): is_last flags[row] if row len(flags) else True # 失同步时保守视为结束 if is_last: logits[row, eos_id] 1.0e6 # EOS 占优 → 调度器结束该请求 else: logits[row, eos_id] -1.0e9 logits[row, safe_id] 1.0e6 # 非 EOS → 请求保持存活等待下一块 return logitseos_id 2vocab_size 2时与 pipeline 配置中sampling_constraints{stop_token_ids: [2]}的硬性兜底对应即使compute_logits()逻辑被绕过调度器侧仍有 stop token 兜底。5. 异常终止时的生成器清理forward()只在正常完成is_last或StopIteration时弹出生成器。取消、超时、抢占等异常终止会泄漏生成器并跳过其finally块导致临时 WAV 文件残留。因此模型实现了on_requests_finished(finished_req_ids)def on_requests_finished(self, finished_req_ids): for req_id in finished_req_ids: gen self._stream_gens.pop(str(req_id), None) if gen is not None: gen.close() # 触发 GeneratorExit让 finally 清理块运行关键点速查参考文档归纳的三条 key points在真实代码中均可验证runtime_additional_information是正确的参数名不是**kwargs它按批内每个请求携带一个 dict——forward()签名中显式声明了runtime_additional_information: list[dict[str, Any]] | None请求 ID 的语义是info.get(_omni_req_id)由 vLLM 设置不是用户代码设置——实际引擎中该键已废弃应使用global_request_id必须同时处理上游模型的audio增量与result最终合并两种事件类型。Pipeline 与 deploy 配置固定拓扑声明pipeline.py单阶段 AR 的拓扑是固定不可变的在pipeline.py中声明。MOSS-TTS-Nano 的真实声明位于 pipeline.pyfrom vllm_omni.config.stage_config import ( PipelineConfig, StageExecutionType, StagePipelineConfig, ) MOSS_TTS_NANO_PIPELINE PipelineConfig( model_typemoss_tts_nano, default_deploy_config_namemoss_tts_nano.yaml, model_archMossTTSNanoForCausalLM, stages( StagePipelineConfig( stage_id0, model_stagemoss_tts_nano, execution_typeStageExecutionType.LLM_AR, input_sources(), final_outputTrue, final_output_typeaudio, owns_tokenizerTrue, engine_output_typeaudio, sampling_constraints{ detokenize: False, stop_token_ids: [2], # compute_logits() 的硬性兜底 }, ), ), )各字段语义见 stage_config.py 中PipelineConfig/StagePipelineConfig定义model_type/model_arch模型唯一标识与 HF 架构名StageConfigFactory据此路由到正确的 pipelineHF 架构名撞车时可用hf_architectures元组消歧execution_typeStageExecutionType.LLM_AR声明为 AR 阶段。调度器由此解析async_chunk为 false 时用OmniARScheduler否则用OmniARAsyncScheduler_resolve_scheduler的对应逻辑input_sources()单阶段无上游输入源为空owns_tokenizerTrue本阶段拥有 tokenizerengine_output_typeaudio与final_outputTrue/final_output_typeaudio引擎侧输出与最终对外输出均为音频。注册与部署配置在 pipeline_registry.py 中注册第 102 行导入MOSS_TTS_NANO_PIPELINE第 191 行挂到moss_tts_nano键并在 registry.py 中注册模型架构MossTTSNanoForCausalLM到moss_tts_nano.modeling_moss_tts_nano.MossTTSNanoForGeneration。运行时放置与尺寸由 deploy YAML 决定参考 moss_tts_nano.yamlasync_chunk: false trust_remote_code: true stages: - stage_id: 0 max_num_seqs: 1 gpu_memory_utilization: 0.3 enforce_eager: true enable_prefix_caching: false max_num_batched_tokens: 4096 max_model_len: 4096 devices: 0 skip_mm_profiling: true default_sampling_params: temperature: 1.0 top_p: 1.0 top_k: 50 max_tokens: 4096 seed: 42每个字段的选择依据文件头注释 源码共同支撑async_chunk: false同步分块模式与_resolve_scheduler中非异步路径的OmniARScheduler对应trust_remote_code: true上游模型与 codec 均需远程代码执行enforce_eager: true模型走inference_stream() trust_remote_code未接 CUDA graph 捕获max_num_seqs: 1硬性约束。_validate_max_num_seqs()会在__init__中直接raise ValueError拒绝大于 1 的值因为远程模型与音频 tokenizer 共享进程级 RNG 与流式解码状态并发请求会互相污染音频gpu_memory_utilization: 0.3AR LM codec 合计约 2 GiB0.3 足够skip_mm_profiling: trueMOSS-TTS-Nano 无多模态输入预处理profile 阶段跳过 dummy-MM passdefault_sampling_params与上游 demo 默认值一致_DEFAULT_TEXT_TEMPERATURE1.0、_DEFAULT_TEXT_TOP_P1.0、_DEFAULT_TEXT_TOP_K50。该配置在 1× L4 24GB 上验证通过且对 H20 / A100 / 3090 同样足够。拓扑与部署的职责边界execution_type、输出归属、tokenizer 归属、模型架构都属于 pipeline 拓扑frozen 的StagePipelineConfig绝不能挪进 deploy YAMLdeploy YAML 只负责设备、显存、批量尺寸等运行时放置。Lint 纪律参考文档提醒只从additional_information中提取实际会转发给模型调用的变量未使用的提取会触发 pre-commit 的ruff F841unused variable。在 MOSS-TTS-Nano 的_create_stream_gen中可以看到规范的提取模式——每个键经_pick(info, key, default)提取后都被用于inference_stream(...)的具名参数或分支逻辑无悬空变量。参考实现清单拓扑声明vllm_omni/model_executor/models/moss_tts_nano/pipeline.py部署配置vllm_omni/deploy/moss_tts_nano.yaml模型实现vllm_omni/model_executor/models/moss_tts_nano/modeling_moss_tts_nano.py流水线注册vllm_omni/config/pipeline_registry.py架构注册vllm_omni/model_executor/models/registry.py拓扑/执行类型定义vllm_omni/config/stage_config.py端到端测试tests/e2e/offline_inference/test_moss_tts_nano_expansion.py、tests/e2e/online_serving/test_moss_tts_nano_expansion.py、tests/model_executor/models/moss_tts_nano/test_npu_compat.py小结Single-Stage AR 模式是 vLLM-Omni 为AR 与 codec 深度捆绑类模型提供的标准接入范式单模型文件承载全部计算per-request 生成器驱动逐块流式输出compute_logits()按行决定请求生命周期固定拓扑留在pipeline.py、运行时放置留在 deploy YAML。MOSS-TTS-Nano 作为仓库内参考实现完整演示了从_stream_gens管理、事件双路径、声道混合、RNG 状态恢复到on_requests_finished清理的全部细节——接入同类模型时可以直接以其为模板照此结构落地。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 8:54:26 · 阅读 1.2k vLLM-Omni 单阶段 AR 模式实践：以 MOSS-TTS-Nano 为例的端到端流式 TTS 接入指南
vLLM-Omni 单阶段 AR 模式实践以 MOSS-TTS-Nano 为例的端到端流式 TTS 接入指南【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni导读本文讲解 vLLM-Omni 中的Single-Stage AR单阶段自回归接入模式当上游模型无法干净地拆分为AR 语言模型 独立解码器时典型如 MOSS-TTS-Nano以及所有通过inference_stream()生成器把 AR 与 codec 捆绑在一起的模型如何把整条流水线放进一个 AR worker 中、按请求逐块产出音频。读完本文你将掌握这种模式的模型实现骨架、pipeline.py固定拓扑声明、deploy YAML 的运行时配置要点以及流式生命周期与 lint 纪律的完整实战方案。本文以仓库内.claude/skills/add-tts-model/references/single-stage-ar.md为骨架结合 MOSS-TTS-Nano 的真实落地代码展开。为什么需要单阶段 AR 模式vLLM-Omni 的编排模型通常鼓励多阶段拓扑AR 阶段做文本/自回归推理扩散或 VAE 阶段做音频/图像解码。但并非所有上游模型都适合这种切分无法干净拆分部分模型的inference_stream()生成器把 AR LM 与音频 codec 绑定在同一个循环里逐帧产出音频事件强共享状态远程模型与音频 tokenizer 共享进程级 RNG 与流式解码状态跨请求并发会导致音频损坏这直接决定了后文max_num_seqs1的限制体积小、无需多卡如 MOSS-TTS-Nano 仅 0.1BAR LM 与 MOSS-Audio-Tokenizer-Nano 合起来约 2 GiB单卡即可容纳。此时正确的做法是把整条流水线运行在单个 AR worker 内模型forward()每次被调用时从 per-request 生成器中弹出一个音频块由 AR 调度器维持请求存活直到最后一个块产出。需要区分的是VoxCPM2 虽然也是单阶段运行但它在基础语言模型上使用 vLLM 原生 PagedAttention并在 vLLM 之外做扩散/VAE 旁路计算属于另一变体见plan/voxcpm2_native_ar_design.md的原始设计说明不在本文范围内。模型实现骨架参考文档给出的实现分为三步每一步在 MOSS-TTS-Nano 的真实代码中都有对应落点。1. 单一模型文件同时加载 AR LM 与 codecMOSS-TTS-Nano 的 AR 语言模型与音频 tokenizer 都加载在同一个MossTTSNanoForGeneration内见 modeling_moss_tts_nano.pyclass MossTTSNanoForGeneration(nn.Module): requires_raw_input_tokens True have_multimodal_outputs True has_preprocess False has_postprocess False enable_update_additional_information True def __init__(self, *, vllm_config: VllmConfig, prefix: str ) - None: super().__init__() ... self._lm: nn.Module lm # AR LM0.1B self._audio_tokenizer: nn.Module audio_tokenizer # MOSS-Audio-Tokenizer-Nano self._stream_gens: dict[str, Any] {} # request_key → generator self._ar_last_chunk_flags: list[bool] [] # 与最近一次 forward batch 对齐的 EOS 掩码模型类声明了have_multimodal_outputs True并以OmniOutput作为返回类型通过multimodal_outputs{model_outputs: ..., sr: ...}携带音频波形与采样率。2. 权重加载的时机__init__与load_weights()的取舍参考文档强调在load_weights()中加载权重而不是__init__()理由是 vLLM 会在任何 CUDA 分配之前初始化分布式状态。但 MOSS-TTS-Nano 的真实实现注释给出了一个有意偏离它在__init__中通过AutoModelForCausalLM.from_pretrained(...)急切构造模型目的是让load_format: dummy可用DummyModelLoader会跳过load_weights但急切构造保证参数已就位避免 vLLM init 后 KV-cache profiling 带来的 OOM与 qwen3_ttsPR #3117的做法保持一致。对应的load_weights()只做排空迭代器 上报全部参数def load_weights(self, weights: Iterable[tuple[str, torch.Tensor]]) - set[str]: for _ in weights: pass return {name for name, _ in self.named_parameters()}从源码结构看这属于从__init__急切加载 load_weights空实现的变体——如果你的模型通过 vLLM 的load_format机制加载权重仍应遵循文档的通用原则在load_weights()中加载选择哪种取决于是否需要dummy加载与 KV-cache profiling 的兼容性。此外真实代码还包含两个值得注意的加载细节transformers 兼容垫片_hf_load_without_tp_warmup()上下文管理器临时把transformers.modeling_utils._is_torch_distributed_initialized置为False规避 transformers 5.8.x 在torch.distributed已初始化时对_tp_planNone的 remote-code 模型做 warmup 导致的TypeErrortransformers_keys_to_ignore_compat()则处理 transformers 5.9 的 keys list-vs-set 变更RoPE 权重修复reinit_rotary_inv_freq(lm, base10000.0)重新初始化以persistentFalse注册的inv_freq缓冲区否则trust_remote_code的自定义 RoPE 类会在首次 forward 时产生 NaN logits。3. 通过 per-request 生成器流式输出参考文档给出的核心模式是forward()根据runtime_additional_information每个请求一个 dict拿到 request_key首次见到该 key 时创建生成器存入self._stream_gens之后每次next()弹出一个(waveform, is_last)元组is_last为真时删除生成器。MOSS-TTS-Nano 的实现进一步明确了 request_key 的取值request_key str(info.get(global_request_id) or info.get(_omni_req_id) or id(info))代码注释说明global_request_id由引擎设置info 键集合为[text, mode, prompt_audio_array, global_request_id, omni_final_stage_id, generated_len]而_omni_req_id是永不会被当前引擎设置的遗留回退键——如果回退到常量所有请求会塌缩到同一个生成器请求 N 的残留块会重放给请求 N1表现为后一个请求的音频与前一请求输入一致的串扰。这一点对文档中request ID 由 vLLM 设置的说明做了重要补充新引擎下应优先使用global_request_id。生成器主体遍历上游inference_stream()事件流同时处理两种事件类型def _create_stream_gen(self, info: dict[str, Any]): ... for event in self._lm.inference_stream( texttext, output_audio_pathoutput_path, modemode, prompt_textprompt_text, prompt_audio_pathprompt_audio_path, text_tokenizer_pathself.model_path, audio_tokenizerself._audio_tokenizer, devicedevice, nqNone, max_new_framesmax_new_frames, do_sampleTrue, use_kv_cacheTrue, **sampling, ): event_type str(event.get(type, )) if event_type audio: waveform event.get(waveform) if waveform is not None: chunk _to_mono_1d(waveform) audio_chunks.append(chunk) yield chunk, False # 增量块is_lastFalse elif event_type result: if not audio_chunks: # 回退无增量块时使用最终合并结果 waveform event.get(waveform) if waveform is not None: yield _to_mono_1d(waveform), True return yield torch.zeros((0,), dtypetorch.float32), True # 结束哨兵这里包含三个工程细节事件双路径audio增量与result最终合并两种事件都要处理短句在某些后端上可能只发result声道混合_to_mono_1d()对(channels, samples)张量按 channel 求均值降为单声道——MOSS 音频 tokenizer 配置为双声道若用.T.reshape(-1)直接展平会把 L/R 交错成 2 倍长度流以 1× 采样率回放导致播放速度慢一倍RNG 状态保存/恢复seed非空时快照并恢复 CPU/GPU RNG 状态避免上游依赖全局 RNG 的采样逻辑污染引擎其他组件。forward()对 dummy/profiling 调用有专门分支当runtime_additional_information为空或全部_is_dummy时直接返回空输出并置self._ar_last_chunk_flags [True] * len(infos)立即结束请求dummy 信息由get_dummy_runtime_additional_information()提供。正常路径下每次next(generator)弹出一个块并更新逐行 EOS 掩码。4. 用compute_logits()控制 AR 调度器的请求生命周期单阶段 AR 模式下forward()本身不产出真正的 logits请求何时结束由compute_logits()决定。MOSS-TTS-Nano 的实现按行构造 logitsdef compute_logits(self, hidden_states, sampling_metadataNone): ... for row in range(num_rows): is_last flags[row] if row len(flags) else True # 失同步时保守视为结束 if is_last: logits[row, eos_id] 1.0e6 # EOS 占优 → 调度器结束该请求 else: logits[row, eos_id] -1.0e9 logits[row, safe_id] 1.0e6 # 非 EOS → 请求保持存活等待下一块 return logitseos_id 2vocab_size 2时与 pipeline 配置中sampling_constraints{stop_token_ids: [2]}的硬性兜底对应即使compute_logits()逻辑被绕过调度器侧仍有 stop token 兜底。5. 异常终止时的生成器清理forward()只在正常完成is_last或StopIteration时弹出生成器。取消、超时、抢占等异常终止会泄漏生成器并跳过其finally块导致临时 WAV 文件残留。因此模型实现了on_requests_finished(finished_req_ids)def on_requests_finished(self, finished_req_ids): for req_id in finished_req_ids: gen self._stream_gens.pop(str(req_id), None) if gen is not None: gen.close() # 触发 GeneratorExit让 finally 清理块运行关键点速查参考文档归纳的三条 key points在真实代码中均可验证runtime_additional_information是正确的参数名不是**kwargs它按批内每个请求携带一个 dict——forward()签名中显式声明了runtime_additional_information: list[dict[str, Any]] | None请求 ID 的语义是info.get(_omni_req_id)由 vLLM 设置不是用户代码设置——实际引擎中该键已废弃应使用global_request_id必须同时处理上游模型的audio增量与result最终合并两种事件类型。Pipeline 与 deploy 配置固定拓扑声明pipeline.py单阶段 AR 的拓扑是固定不可变的在pipeline.py中声明。MOSS-TTS-Nano 的真实声明位于 pipeline.pyfrom vllm_omni.config.stage_config import ( PipelineConfig, StageExecutionType, StagePipelineConfig, ) MOSS_TTS_NANO_PIPELINE PipelineConfig( model_typemoss_tts_nano, default_deploy_config_namemoss_tts_nano.yaml, model_archMossTTSNanoForCausalLM, stages( StagePipelineConfig( stage_id0, model_stagemoss_tts_nano, execution_typeStageExecutionType.LLM_AR, input_sources(), final_outputTrue, final_output_typeaudio, owns_tokenizerTrue, engine_output_typeaudio, sampling_constraints{ detokenize: False, stop_token_ids: [2], # compute_logits() 的硬性兜底 }, ), ), )各字段语义见 stage_config.py 中PipelineConfig/StagePipelineConfig定义model_type/model_arch模型唯一标识与 HF 架构名StageConfigFactory据此路由到正确的 pipelineHF 架构名撞车时可用hf_architectures元组消歧execution_typeStageExecutionType.LLM_AR声明为 AR 阶段。调度器由此解析async_chunk为 false 时用OmniARScheduler否则用OmniARAsyncScheduler_resolve_scheduler的对应逻辑input_sources()单阶段无上游输入源为空owns_tokenizerTrue本阶段拥有 tokenizerengine_output_typeaudio与final_outputTrue/final_output_typeaudio引擎侧输出与最终对外输出均为音频。注册与部署配置在 pipeline_registry.py 中注册第 102 行导入MOSS_TTS_NANO_PIPELINE第 191 行挂到moss_tts_nano键并在 registry.py 中注册模型架构MossTTSNanoForCausalLM到moss_tts_nano.modeling_moss_tts_nano.MossTTSNanoForGeneration。运行时放置与尺寸由 deploy YAML 决定参考 moss_tts_nano.yamlasync_chunk: false trust_remote_code: true stages: - stage_id: 0 max_num_seqs: 1 gpu_memory_utilization: 0.3 enforce_eager: true enable_prefix_caching: false max_num_batched_tokens: 4096 max_model_len: 4096 devices: 0 skip_mm_profiling: true default_sampling_params: temperature: 1.0 top_p: 1.0 top_k: 50 max_tokens: 4096 seed: 42每个字段的选择依据文件头注释 源码共同支撑async_chunk: false同步分块模式与_resolve_scheduler中非异步路径的OmniARScheduler对应trust_remote_code: true上游模型与 codec 均需远程代码执行enforce_eager: true模型走inference_stream() trust_remote_code未接 CUDA graph 捕获max_num_seqs: 1硬性约束。_validate_max_num_seqs()会在__init__中直接raise ValueError拒绝大于 1 的值因为远程模型与音频 tokenizer 共享进程级 RNG 与流式解码状态并发请求会互相污染音频gpu_memory_utilization: 0.3AR LM codec 合计约 2 GiB0.3 足够skip_mm_profiling: trueMOSS-TTS-Nano 无多模态输入预处理profile 阶段跳过 dummy-MM passdefault_sampling_params与上游 demo 默认值一致_DEFAULT_TEXT_TEMPERATURE1.0、_DEFAULT_TEXT_TOP_P1.0、_DEFAULT_TEXT_TOP_K50。该配置在 1× L4 24GB 上验证通过且对 H20 / A100 / 3090 同样足够。拓扑与部署的职责边界execution_type、输出归属、tokenizer 归属、模型架构都属于 pipeline 拓扑frozen 的StagePipelineConfig绝不能挪进 deploy YAMLdeploy YAML 只负责设备、显存、批量尺寸等运行时放置。Lint 纪律参考文档提醒只从additional_information中提取实际会转发给模型调用的变量未使用的提取会触发 pre-commit 的ruff F841unused variable。在 MOSS-TTS-Nano 的_create_stream_gen中可以看到规范的提取模式——每个键经_pick(info, key, default)提取后都被用于inference_stream(...)的具名参数或分支逻辑无悬空变量。参考实现清单拓扑声明vllm_omni/model_executor/models/moss_tts_nano/pipeline.py部署配置vllm_omni/deploy/moss_tts_nano.yaml模型实现vllm_omni/model_executor/models/moss_tts_nano/modeling_moss_tts_nano.py流水线注册vllm_omni/config/pipeline_registry.py架构注册vllm_omni/model_executor/models/registry.py拓扑/执行类型定义vllm_omni/config/stage_config.py端到端测试tests/e2e/offline_inference/test_moss_tts_nano_expansion.py、tests/e2e/online_serving/test_moss_tts_nano_expansion.py、tests/model_executor/models/moss_tts_nano/test_npu_compat.py小结Single-Stage AR 模式是 vLLM-Omni 为AR 与 codec 深度捆绑类模型提供的标准接入范式单模型文件承载全部计算per-request 生成器驱动逐块流式输出compute_logits()按行决定请求生命周期固定拓扑留在pipeline.py、运行时放置留在 deploy YAML。MOSS-TTS-Nano 作为仓库内参考实现完整演示了从_stream_gens管理、事件双路径、声道混合、RNG 状态恢复到on_requests_finished清理的全部细节——接入同类模型时可以直接以其为模板照此结构落地。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考