建议给一个 roadmap

我读完 community_growth_20k.md 我觉得应该再有一个 roadmap，制定下一步的发展方向，甚至包括哪些 help wanted .

另外有个小问题，我好像以前也问过，但是看了 community_growth_20k 也没搞懂，就是 FunAudioLLM/Fun-ASR 这个项目的作用, 我能理解 FunAudioLLM 要强调 LLM-ASR model，但还是搞不太清和 modelscope/FunASR 分工在哪里；另外如果作为使用者，需要知道 FunAudioLLM/Fun-ASR 这个项目吗？

Repository	Role in the ecosystem	Growth surface
modelscope/FunASR	Core toolkit, Python package, runtime services, deployment docs	First-run success, production deployment, issue/PR operations
FunAudioLLM/Fun-ASR	Fun-ASR-Nano model family and LLM-ASR identity	Model cards, Transformers integration, benchmarks, vLLM/GGUF stories

我们关于 Fun-ASR-Nano 问题讨论也都是在 modelscope/FunASR 里不是在 FunAudioLLM/Fun-ASR | Fun-ASR-Nano
然后我读 modelscope/FunASR 的 serve_realtime_ws.py 和 FunAudioLLM的 serve_realtime_ws.py 觉得它们基本一样，但差异的地方又让人糊涂，比如 modelscope/FunASR 有 get_partial_decode_audio 但 FunAudioLLM 的没有，可是 get_partial_decode_audio 我们也讨论过几次，为什么会一个有一个没有？

这个问题提得非常对。当前两个仓库的边界和重复示例没有表达清楚，确实会让使用者困惑；get_partial_decode_audio 的差异也不是有意设计成两套能力，而是 toolkit 侧的长语音/并发修复没有同步到模型仓库。

我们后续按下面的边界维护：

Repository	Canonical responsibility
`modelscope/FunASR`	Python toolkit、运行时服务、部署、训练/微调能力，以及生产使用问题和 issue/PR
`FunAudioLLM/Fun-ASR`	Fun-ASR-Nano / MLT 模型家族、checkpoint/model card、模型评测，以及 Transformers、vLLM、GGUF 等模型级集成

因此，普通使用者如果只需要通过 Python 包或服务部署 ASR，关注 modelscope/FunASR 即可；需要选择 Nano/MLT checkpoint、了解模型能力或使用特定推理框架时，再看 FunAudioLLM/Fun-ASR。

对两份 serve_realtime_ws.py，我们会把 toolkit 版本作为生产实现的 canonical source，并推进三件事：

在模型仓库明确链接 canonical 实现，停止把两份独立副本同时当作权威版本。
同步当前缺失的 partial-window、WebSocket 参数和 dtype 等修复，并增加防漂移验证。
优先修复长会话开启 speaker 后状态持续增长的问题，做长时间 soak test 后再推广这条部署路径。

Roadmap 会按 Now / Next / Later 落到仓库文档并拆出 help-wanted：

Now: realtime speaker 长会话稳定性、版本/发布一致性、Transformers 原生集成收尾。
Next: 四仓统一 repo-role 表、经过验证的集成矩阵、明确的 issue 路由和 help-wanted。
Later: 官方可用 demo、容器化及稳定的 headless/API 工作流。

感谢把这个问题具体指出来。这个 issue 保持打开，直到 roadmap 和仓库边界文档真正落地。

@LauraGPT

@LauraGPT 我又读了一遍 serve_realtime_ws.py 觉得还是有个隐藏的问题： audio_buffer 会不断增加

# L526 handler:每收到一个二进制帧调用一次
session.add_audio(message)

# L263:
self.audio_buffer = np.concatenate([self.audio_buffer, audio_float])   # ← 整块重拷

session.reset() 只是在一开始 START 调用一次，所以如果ws一直开着，内存拷贝会out of memory, 比如简单估算 16kHz float32 = 64 KB/s;客户端 100ms 一帧 → 每秒 10 次 np.concatenate,每次拷贝整个已累积 buffer。全程拷贝量 ≈ 32 KB × T² / chunk_sec

我不知道我没有用哪里没看对，你再确认一下

你没有看错。我按当前 main（defff40e）把数据流重新走了一遍，结论是这个问题确实存在，而且比单纯的 audio_buffer 常驻还要严重一些。

audio_buffer 只在收到 START 时通过 session.reset() 清空；STOP 只做 final decode 并把 is_active 设为 false，不会释放缓冲区。长连接只发一次 START 时，原始音频会保留整个会话。
每个二进制 WebSocket message 都会执行 np.concatenate([旧 buffer, 新 frame])，因此累计拷贝量是二次方。按 16 kHz、float32、100 ms 一帧计算，30 分钟时 buffer 本体约 115.2 MB，但累计内存拷贝约 1.04 TB；1 小时约 4.15 TB。你的复杂度判断是对的，具体常数取决于客户端每帧时长。
partial_window_sec 只限制临时 ASR re-decode 使用的尾部窗口，并没有裁剪 audio_buffer，所以它不能解决这里的内存和拷贝问题。
开启 speaker 后问题会进一步放大：all_chunks 保存的是从 audio_buffer 切出的 NumPy slice；对足够长的 chunk，这些 slice 与当时的完整 buffer 共享内存，可能让旧版本的大 buffer 在后续 concatenate 后仍不能释放。同时 all_embeddings 持续增长，每个新片段都会重新 torch.cat 并聚类全部历史 embedding。
locked_sentences 也会一直增长，并在每次 partial response 中完整序列化，不过这通常是次于前两项的放大因素。

所以这不是你漏看了某个清理路径，而是当前实现的真实长会话缺陷，也与 #3101 开启 speaker 后 30-60 分钟断线的复测结果吻合。我会把代码修复继续集中在 #3101：需要同时引入有绝对时间偏移的有界音频存储、不会引用旧大数组的 speaker chunk、以及有界或增量的 speaker 状态，不能只在现有数组上加一个简单 truncate。修复前可靠的规避方式仍是关闭 speaker，或按固定时长 STOP/重新 START 轮换 session。

从 3101描述那还真是。我最近一个项目做asr，所以就希望能对funasr 也贡献一点力量（所以这个issue 提了想看看有没有 help wanted我能帮忙的），以后项目可能不做asr，就没精力再做贡献了。

另外我看你的提交代码的密集程度，简直是惊人！一方面说明确实是能者多劳，但另一方面也说明可能真的需要有“真人”做 code review

@qiulang

@qiulang 谢谢你愿意在这段时间贡献，也谢谢你明确提醒需要人工 code review。这个方向同意：外部贡献的 PR 会保留给 maintainer 做人工审核，不会自动合并。

我先把这个 issue 标成 help wanted 和 ready for PR。为了不让你被 #3101 的 speaker 状态设计选择卡住，有一个可以独立完成、独立 review 的文档任务：

新增 docs/repository_roles_zh.md 和对应英文 docs/repository_roles.md。
用表格说明 FunASR / Fun-ASR / SenseVoice / FunClip 的 canonical responsibility、用户入口和 issue 路由。
加入 Now / Next / Later roadmap；用现有 issue/PR 链接表达进度，不承诺无法保证的发布日期。
明确 realtime WebSocket 服务以 modelscope/FunASR 版本为 canonical source，模型仓库只链接它，不再把两份副本都描述为权威实现。
从 README.md、README_zh.md 和 CONTRIBUTING.md 加入清晰入口。

验收重点是链接可达、四仓边界一致、没有复制新的服务代码。你如果愿意接这个任务，可以在这里回复“我来做”，或者直接开标题类似 Docs: clarify repository roles and roadmap (#3203) 的 PR。

#3101 的有界音频和 speaker 状态修复继续作为单独技术任务推进，避免一个 PR 同时承担文档治理和高风险实时服务改造。

这个我可以做，不过我还是想知道funasr下一步方向是什么，比如你说的 “Later: 官方可用 demo、容器化及稳定的 headless/API 工作流。“
官方可用dmo, 容器化指什么，example 目录下不是有很多这样的例子吗？

roadmap 我本来想到是 1.4.x 1.5x 主要做什么 2.x又规划做什么

可以，这个文档任务就由你来做；我不会同时另开一份重复 PR。

你指出得对，我前面写的“官方可用 demo、容器化及稳定的 headless/API 工作流”太抽象。examples/ 里确实已经有很多 demo，缺的不是“再多放几个示例”，而是下面这些可验证的产品化入口：

官方可用 demo：从顶层 README 能找到一个 canonical 入口；依赖锁定；有固定测试音频和启动 smoke test；CPU/GPU 支持范围写清楚；不是若干脚本都声称自己是推荐入口。
容器化：有版本化的 CPU/CUDA 镜像和构建 CI，而不只是 Docker 命令片段；模型缓存、端口、健康检查、GPU 参数和升级方式有稳定约定。
headless/API：不依赖 Gradio 或浏览器操作的 CLI/HTTP/gRPC/WebSocket 路径；请求/响应可机器解析；有健康检查、错误码和兼容性测试，适合服务与 agent 调用。

关于你说的 1.4.x / 1.5.x / 2.x：我刚核对了当前发布状态。仓库没有已建立的 milestone，GitHub Python tag 到 v1.3.13，PyPI 已是 1.3.14；目前没有经过核心 maintainer 确认的 1.4/1.5/2.0 边界。因此我们不能在文档 PR 里自行承诺版本号或发布日期。

这次 PR 请先写成 directional roadmap，并单独注明 “Versioned release roadmap: pending maintainer confirmation”：

Now：修复 realtime 长会话有界状态（即時轉錄一段時間後會自行斷線 #3101）；完成 Fun-ASR-Nano Transformers 集成（Add Fun-ASR-Nano model huggingface/transformers#46180）；明确四仓职责和 issue 路由（建议给一个 roadmap #3203）。
Next：收敛重复 realtime 服务到 canonical source；建立经过 smoke test 的 Python/CLI/WebSocket/容器支持矩阵；补稳定的 headless API 契约和部署入口。
Later：在上述接口与兼容性测试稳定后，再评估需要 breaking changes 的 2.x；版本号由 core maintainer 通过 milestone/release plan 确认。

每一项尽量链接现有 issue/PR；没有 owner 或验收证据的内容不要写完成日期。你可以按这个范围直接开 Docs: clarify repository roles and roadmap (#3203)，PR 会保留给 maintainer 做人工 review。

给 roadmap 文档补一个最新状态，方便你在 PR 里引用：

realtime 长会话有界状态已由 fix: bound realtime websocket state for long sessions #3214 合并，即時轉錄一段時間後會自行斷線 #3101 已关闭；FunAudioLLM/Fun-ASR 的镜像修复是 fix: bound realtime websocket state for long sessions QwenAudio/Fun-ASR#135，也已合并。
Transformers 原生集成 Add Fun-ASR-Nano model huggingface/transformers#46180 当前 head 有 102 项 checks：100 success、2 skipped、0 failure；所有 review thread 已解决，仍等待 maintainer approval。

文档任务范围不变，不需要把上述实现代码带进你的 PR。

@LauraGPT

@LauraGPT 另一个提醒 vllm 官方文档 https://docs.vllm.ai/en/latest/models/supported_models/#transcription

列的fun-asr-nano 是 allendou/Fun-ASR-Nano-2512-vllm

这个我试过，~~它这个是有问题，ASR结果重复 (换 https://huggingface.co/yuekai/Fun-ASR-Nano-2512-vllm 就没问题) , 但不知道什么和 #3031 有关，当时我也没细研究~~。看你们能怎么提醒 vllm 官方这个，至少要加上官方的 Fun-ASR-Nano-2512.

更正，没有问题，是我使用方法不对，当时刚开始接触funasr，还不懂，但又对vllm 有些了解，所以造成这个乌龙。lol

@qiulang

重新打开这个 issue。之前在 roadmap 文档合入后就关闭得太快，后续关于 vLLM 模型入口、权重来源与 safetensors 的问题仍未逐项回应，也没有等待提议者确认，关闭条件并不充分。

接下来我会在这里继续核对并更新公开 roadmap：已交付能力、仍在推进的上游集成，以及需要社区验证的部署边界都会按实际状态维护。这个 issue 会保持打开，直到上述问题有可复现结论并给提议者合理的反馈时间。感谢 @qiulang 当时指出这些具体问题。

路线图刷新已通过 #3567 合并，当前文档已同步到 funasr==1.4.7，并区分了已交付、进行中和下一步：

已交付部分补充 OpenAI-compatible API、vLLM / llama.cpp 九平台运行包，以及 MOSS-Transcribe-Diarize 一次推理完成转写、时间戳和说话人识别的第三方模型路径；
进行中部分明确列出 Transformers #46180、checkpoint CTC tensors Fun-ASR-Nano Hugging Face checkpoint is missing 86 CTC tensors required for timestamps and diarization #3496、实时并发 1.4.3 的 funasr/bin/realtime_ws.py 的 run_session_work() 实现太简单粗暴，导致并发性能比1.3.9还差很多 #3528 和 AMD Windows Vulkan [Bug] Vulkan backend crashes on AMD GPUs on Windows (0xc0000005) #3479；
文档测试 17 项通过，提交已签名并满足 DCO。

这个 issue 不会因为文档合并就自动关闭。我会继续在这里回应你之前提出的 vLLM 模型入口、权重来源和 safetensors 问题，并等待你的反馈。

把你之前提出的 vLLM 模型入口、权重来源和 safetensors 问题做了一次按固定 revision 的核验。先给结论：你的困惑是合理的，当前确实存在两条不同的 vLLM 路径，不能把它们混写成同一种部署方式；这个 issue 继续保持 open。

1. 三个模型仓的职责并不相同

模型仓	固定 revision	实际内容	vLLM 使用方式
`FunAudioLLM/Fun-ASR-Nano-2512`	`272c57b8`	官方 FunASR checkpoint：`model.pt` + `config.yaml` + 独立 `Qwen3-0.6B/` tokenizer/config	FunASR `AutoModelVLLM` 读取官方 checkpoint，在本地把 `llm.*` 310 个张量导出成临时 `model.safetensors`；音频 encoder/adaptor 仍由 FunASR/PyTorch 执行
`allendou/Fun-ASR-Nano-2512-vllm`	`e718b36e`	面向 vLLM 原生 `FunASRForConditionalGeneration` 的社区转换；单个 safetensors 包含 encoder + adaptor + LLM	`vllm serve ...` 直接提供 OpenAI transcription API；这是 vLLM 当前文档和测试 registry 使用的模型
`yuekai/Fun-ASR-Nano-2512-vllm`	`9fd10018`	只有 Qwen3 LLM 权重，另带 `inputs_embeds.pt` 示例	社区 Fun-ASR-vLLM 路径先在外部计算音频 embedding，再把 embedding 交给 vLLM；不是 vLLM 原生多模态 FunASR 模型

我只读取了两个 safetensors 的 header，没有下载或改写权重：

allendou：1,261 个 tensors，包含 audio encoder/adaptor 和 LLM，LoRA tensor 为 0。
yuekai：310 个 tensors，只有 Qwen3 LLM，LoRA tensor 为 0。
官方 config.yaml 明确是 use_lora: false；所以这里不是“运行时再加载一份 LoRA”。官方 model.pt 已包含训练后的完整 llm.* 权重，FunASR 的 vLLM 适配器只是把这些权重抽出并改存为 vLLM 更适合加载的 safetensors。

2. 为什么 vLLM 文档还不能直接换成官方模型 ID

当前官方 HF 仓根目录没有 Transformers/vLLM 所需的 config.json、preprocessor_config.json 和原生 model.safetensors；它是 FunASR checkpoint layout。allendou 转换仓补齐了这些文件并把 1,261 个权重改名为 vLLM FunASRForConditionalGeneration 所需命名。vLLM 的主仓当前仍在：

docs/models/supported_models.md 指向 allendou/Fun-ASR-Nano-2512-vllm；
tests/models/registry.py 也用同一模型做 registry 测试；
原生模型支持由 vLLM #33247 合并，后续 #36108、#44215 又跟随转换格式和初始化接口修复。

因此现在直接把文档字符串替换成 FunAudioLLM/Fun-ASR-Nano-2512 会让 vllm serve 找不到所需原生 layout，不是一个安全的文档修正。

3. 正确的收敛方向

短期继续明确标注 allendou 是经过固定 revision 验证的社区转换，官方原始 checkpoint 仍是 FunAudioLLM/Fun-ASR-Nano-2512。
官方模型仓需要发布一个由权重所有方维护、可审计来源的 vLLM layout（可单独官方 conversion repo，也可在不破坏 FunASR layout 的前提下提供原生文件），并记录从官方 model.pt@272c57b8 到 1,261-tensor safetensors 的确定性转换和哈希。
等官方 layout 通过 vLLM exact-head transcription 回归后，再向 vLLM 提交 docs + registry 的原子更新，避免只换文档而测试仍依赖社区仓。
你提到的“重复输出”我目前没有足够的固定版本、命令、音频哈希和输出证据，不能把它当成 allendou@e718b36e 的现存结论。若当前版本仍能复现，请贴 exact vLLM/Transformers 版本、完整启动命令、音频 SHA256 和原始响应；这里会继续跟进，不会因 roadmap 文档已经合并而关闭。

下一步不是再复制一套运行代码，而是把官方 vLLM 工件的发布责任、转换可重复性和上游 registry 测试收敛到同一个可验证对象。

补充上一条审计后的实质进展，issue 继续保持 open：

官方 vLLM-native 工件现已发布：FunAudioLLM/Fun-ASR-Nano-2512-vllm，固定 revision a4362c943d48951f98ca2a62181cc028970270c5，tag vllm-0.27.1-20260830。
该工件从官方 FunAudioLLM/Fun-ASR-Nano-2512@272c57b8 转换；model.safetensors 与此前验证的 allendou@e718b36e 逐字节一致（SHA256 96dfbec48282dd24d3334369a01e9e909f321ee39a1b0003c528c5379f68c1a6），因此迁移模型 ID 不改变权重。
vLLM 当前 main 680e2177 上已准备 docs + registry 的最小迁移提交，并把 registry pin 到上述 immutable revision。exact-head dummy initialization 通过；pre-commit 全部通过。registry import 项因上游已知的 Transformers 5.2+ 不兼容约束在本机 transformers==5.15.0 下按规则跳过，这个约束没有被掩盖或删除。
vLLM 的贡献规则要求提交者逐行人工审阅且披露 AI 协助，所以我不会绕过该门槛自动发 PR；当前签名+DCO patch 和可复现证据已保存，完成合规人工审阅后再提交上游。

你原来指出“不要长期让官方能力依赖个人转换仓”是正确的。官方工件这一层已经补齐，上游 registry 迁移正在按其贡献规范推进；等你复测或上游完成迁移后再判断是否关闭。

你提出的“roadmap 应该让有能力、有时间的人知道可以参与什么”，我已经按中英文同时落成 PR #3593，exact head 是 100a5f2e284c7e8596e191ed7bb2513b1c27ddd7。

这次不是再增加一份静态愿望清单，而是补了三层可执行入口：

good first issue、help wanted、ready for PR 的实时查询与明确语义；
当前四条需要社区参与的工作流，包括 L20 实时预览 profiling、AMD Windows Vulkan、公开 checkpoint CTC tensors 和 Transformers 上游 review；
每条工作的验收证据、适合的贡献者，以及认领前先读完整时间线、留言避免重复劳动的流程。

文档也明确写了中文或英文都可以贡献；涉及路线图和仓库职责的改动，需要在同一个 PR 中同步中英文。你刚在 #3528 提到愿意帮忙写中英文内容，这类贡献非常欢迎。

同时修正了两处事实边界：当前 GitHub/PyPI 版本是 1.4.11；MOSS-Transcribe-Diarize 输出的是单次录音内的匿名 speaker labels，不是已知人物身份识别。

验证为 18 项文档测试通过、相对链接检查通过、提交签名并满足 DCO。这个 issue 继续保持 open，等你和其他贡献者对入口是否清楚给反馈，不会因为 roadmap PR 合并就自动关闭。

补充更正我之前对 allendou/Fun-ASR-Nano-2512-vllm 模型的描述。

我最早说它的 ”ASR结果重复“是因为当时我还不懂funasr，使用方式不对造成。现在对他们了解就知道原因：allendou/Fun-ASR-Nano-2512-vllm 的权重文件是 model.safetensors, 必须用vllm的启动方式 vllm serve xxx/allendou/Fun-ASR-Nano-2512-vllm --port 8000 使用

FunAudioLLM/Fun-ASR-Nano-2512 权重文件你已经解释了，权重文件是pytorch训练下生成的 model.pt, 所以使用前需要调用 inference_vllm.py的 prepare_vllm_model_dir() 从Qwen3-0.6B/这个子目录下复制配置与 tokenizer， model.pt 提取 llm.*权重

我当时应该是用较早的 funasr 版本这样启动 python ./FunASR/examples/industrial_data_pretraining/fun_asr_nano/serve_realtime_ws.py --model allendou/Fun-ASR-Nano-2512-vllm ... 虽然起来了，但是asr结果错。

但是现在funasr版本（从1.3.9之后）如果这样启动就会报错了 FileNotFoundError: Qwen3-0.6B config directory not found ... 所以这个问题就不存在了（就是没法用官方funasr的代码加载 allendou/Fun-ASR-Nano-2512-vllm）。

所以我想 #3475 那个问题单可以关闭了，还可以做的就是补充 vllm_guide_zh_v2 那里描述，可以提到如果是用 allendou/Fun-ASR-Nano-2512-vllm 使用方式必现是 vllm serve allendou/Fun-ASR-Nano-2512-vllm --port xxxx 而不是 funasr 官方的 python -m funasr.bin.realtime_ws，而且 vllm的实时流式需要自己实现，参见 https://docs.vllm.ai/en/latest/examples/speech_to_text/realtime/ 和https://docs.vllm.ai/en/latest/models/supported_models/#transcription

针对你刚补充的“native vLLM 模型不能用 FunASR realtime WebSocket 启动”的结论，我已提交可审查的文档 PR #3603：

official native checkpoint 的 vllm serve 启动入口；
不得把 native layout 传给 AutoModelVLLM 或 serve_realtime_ws.py 的原因；
realtime native-vLLM 需要在应用侧按 vLLM 示例实现音频分段、请求调度和 partial；
防止该边界回退的文档测试。

exact head a9c4069，本地针对性测试 4 passed，GitHub contract check 已成功。该 PR 仍等待独立 maintainer review；本 issue 继续保持 open，等待你确认这条入口说明是否清楚。

native-vLLM 我会在仔细验证一下

native vLLM 模型不能用 FunASR realtime WebSocket 启动, 这个如果要验证可以这样试验，返回 403 （不是 404 ）

curl -i -N \
  -H "Connection: Upgrade" \
  -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  http://127.0.0.1:8000/v1/realtime
HTTP/1.1 403 Forbidden
Date: Tue, 01 Sep 2026 03:53:08 GMT
Connection: close
Content-Length: 0
Content-Type: text/plain; charset=utf-8

vllm的日志

(APIServer pid=3888680) INFO:     127.0.0.1:41980 - "WebSocket /v1/realtime" 403
(APIServer pid=3888680) INFO:     connection rejected (403 Forbidden)

是 403 不是 404 （开始我还纳闷了一下），查了fastapi 查发现是因为 uvicorn websocket.close，一律翻译成 403

文档需要我验证会慢一点。抱歉，这两天工作中的事多，实际空闲时间就少了

感谢你把实际 403 握手和 Uvicorn 的解释补全，这个区别很重要。403 表示当前服务拒绝了 WebSocket 握手，并不意味着 native Fun-ASR 获得了可用的 realtime session；也不能把“必须是 404”写进文档。

我已据此更新 #3603：现在明确 403 只是当前实现表现，不是稳定 API 契约或支持性探测；文档仍只承诺 native vllm serve 的请求/响应转写路径。回归契约已通过。你按自己的节奏验证即可，不急；#3203 保持 open 等你的文档体验反馈。

你补充的 403 握手实测和 Uvicorn 行为说明已经据实纳入文档边界。对应修正现已通过 #3601 合并到 main：

经过验证的 head：bb7599d22e3d5a52dc111699565b11136b373a05；合并提交：fddf9b486bc87e44b9a2afe395437d4c89243b37。
官方 native 模型 FunAudioLLM/Fun-ASR-Nano-2512-vllm 的入口是 vllm serve 加 OpenAI-compatible /v1/audio/transcriptions，不是 FunASR serve_realtime_ws.py 或 AutoModelVLLM。
/v1/realtime 的 403 只是当前 Uvicorn/FastAPI 的 WebSocket 拒绝表现，不作为 404/403 的支持性契约。native vLLM 未注册 FunASR realtime session；需要低延迟 partial 时，继续使用 FunASR WebSocket 服务，或在应用侧实现 vLLM 的分段与请求调度。
中英文 primary vLLM 指南都有这一边界，并有防回退文档测试。

感谢你愿意按自己的节奏继续验证。这个 issue 保持 open，等待你确认入口表述和实际部署体验是否清楚；不会因文档合并而提前关闭。

你提出的“官方能力不应长期依赖个人转换仓”现在已进入 vLLM 上游 PR：vllm-project/vllm#54944 。

这份 PR 将 supported-models 文档和 FunASR registry 从 allendou/Fun-ASR-Nano-2512-vllm 更新到官方 FunAudioLLM/Fun-ASR-Nano-2512-vllm，并固定为 immutable revision a4362c943d48951f98ca2a62181cc028970270c5。本地 pre-commit、引用和格式检查、官方 Hub config 的 architecture 元数据均已通过；提交已签名且满足 DCO。

vLLM 的新贡献者 CI 准入目前要求项目方加 verified 或 ready 标签，或作者已有四个已合并 PR。该工作流明确禁止 AI 请求标签，因此我不会绕过这项规则或制造无效 CI 重跑。PR 保持打开，等待 vLLM 的正常维护流程；一旦有实际 code review 或 CI 反馈会直接处理。

这里继续保持 open，等待你确认官方 vLLM 工件与部署入口的表述是否清楚，也继续接收 roadmap/贡献入口的反馈。

最新main branch 上的 vllm_guide 中英文我都读过确认，这次把 "Choose the model path" 下的 A/B 两条路差别解释得很清楚了 allendou/Fun-ASR-Nano-2512-vllm 的存在和作用也说清楚了， #3475 可以关闭了

另，我在之前一条回复说的不太准确：

我当时应该是用较早的 funasr 版本这样启动 python ./FunASR/examples/industrial_data_pretraining/fun_asr_nano/serve_realtime_ws.py --model allendou/Fun-ASR-Nano-2512-vllm ... 虽然起来了，但是asr结果错。

这个错就是 vllm_guide 里写的 "不要把任一 native checkpoint 传给 AutoModelVLLM"，把 native checkpoint 传给 AutoModelVLLM 会报 FileNotFoundError.

但我查到我的自己git项目历史记录，我当时是自己简单写了一个测试funasr的代码，根本原因就是当时不懂 allendou/Fun-ASR-Nano-2512-vllm 到底要怎么用。

MODEL_DIR  = Path("./models/funasr-nano")
VLLM_MODEL = Path("./funasr-nano-vllm-allendou") # 我的 allendou/Fun-ASR-Nano-2512-vllm 本地下载目录

model, kwargs = AutoModel.build_model(model=str(MODEL_DIR), device="cuda:0")

vllm = LLM(
    model=str(VLLM_MODEL),      
    enable_prompt_embeds=True,
    dtype="bfloat16",
)
# encoder + adaptor 全在 PyTorch 侧
encoder_out, encoder_out_lens = model.audio_encoder(speech, speech_lengths)
encoder_out, encoder_out_lens = model.audio_adaptor(encoder_out, encoder_out_lens)
# vLLM 只当 decoder 但是使用 allendou/Fun-ASR-Nano-2512-vllm 所以 ASR结果完全错了
outputs = vllm.generate(...)

Navigation Menu

Repository navigation

建议给一个 roadmap #3203

10 remaining items

1. 三个模型仓的职责并不相同

2. 为什么 vLLM 文档还不能直接换成官方模型 ID

3. 正确的收敛方向

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

建议给一个 roadmap #3203

Description

Activity

LauraGPT commented on Jul 13, 2026

qiulang commented on Jul 13, 2026

LauraGPT commented on Jul 13, 2026

qiulang commented on Jul 13, 2026

LauraGPT commented on Jul 13, 2026

qiulang commented on Jul 13, 2026

LauraGPT commented on Jul 13, 2026

LauraGPT commented on Jul 13, 2026

10 remaining items

qiulang commented on Jul 15, 2026

LauraGPT commented on Aug 29, 2026

LauraGPT commented on Aug 29, 2026

LauraGPT commented on Aug 29, 2026

1. 三个模型仓的职责并不相同

2. 为什么 vLLM 文档还不能直接换成官方模型 ID

3. 正确的收敛方向

LauraGPT commented on Aug 30, 2026

LauraGPT commented on Aug 31, 2026

qiulang commented on Sep 1, 2026

LauraGPT commented on Sep 1, 2026

qiulang commented on Sep 2, 2026

LauraGPT commented on Sep 2, 2026

LauraGPT commented on Sep 2, 2026

LauraGPT commented on Sep 2, 2026

qiulang commented on Sep 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions