VibeVoice-ASR 的 BitNet 版与常规版：文档与模型卡各自写明了什么
选 ASR 模型这件事，真正卡住人的往往不是模型本身，而是「我这台机器算不算数」。手上有 GPU 服务器的人和只有一台工控机的人，读同一份 README 会读出完全不同的结论。VibeVoice 这边正好摆着两条线：常规的 VibeVoice-ASR，以及 2026-07-23 发布的 VibeVoice-ASR-BitNet。
这篇只做一件事：把两边各自写明了什么摊开对齐。凡是一方没写的，我直接说没写，不猜、不补、不排名。
先分清「文档在哪」这件事
这是选型第一个岔口，也是最容易被忽略的。
常规版的东西全在 github.com/microsoft/VibeVoice 这个仓库里：文档是 docs/vibevoice-asr.md，推理脚本在 demo/，vLLM 部署说明在 docs/vibevoice-vllm-asr.md，微调在 finetuning-asr/。你可以逐行读源码。
BitNet 版不一样。仓库 README 的新闻节把它描述为「an edge CPU inference engine for VibeVoice-ASR」，并指向另一个仓库 github.com/microsoft/VibeASR.cpp。也就是说，推理引擎的代码不在这个仓库里。本文核对范围只覆盖 VibeVoice 仓库与 Hugging Face 上的模型卡，VibeASR.cpp 我们没有核过，所以下文不会出现任何它的编译步骤、命令行参数或依赖——那些我们没有依据。
这个差别本身就是决策信息：常规版你能把整条链路读完，BitNet 版你得去另一个仓库补齐。
常规版：仓库里给了三个入口
入口一，本仓库直装。 docs/vibevoice-asr.md 的 Installation 一节推荐用 NVIDIA 的深度学习容器管理 CUDA 环境，先 docker run 起 nvcr.io/nvidia/pytorch 镜像（文档里写了具体 tag 与一个已验证的版本区间，这类值随版本变动，以文档为准），并注明若镜像里没有 flash attention 需要自行 pip install flash-attn --no-build-isolation。然后是：
git clone https://github.com/microsoft/VibeVoice.git
cd VibeVoice
pip install -e .
pyproject.toml 里 requires-python 给 Python 划了下限，dependencies 里对 transformers 同样只划下限并排除了下一个大版本——具体取值以仓库当前的 pyproject.toml 为准，随版本会变，别把它抄进自己的 requirements 就不管了。
文档接着给了两条用法：一条是 demo/vibevoice_asr_gradio_demo.py，一条是 demo/vibevoice_asr_inference_from_file.py，都用 --model_path 指模型。后一个脚本值得多看两眼，因为它的 argparse 里 --device 的 choices 是 cuda、cpu、mps、xpu、auto，默认按 torch 探测到的设备走；--attn_implementation 的 choices 是 flash_attention_2、sdpa、eager、auto，脚本里写明 auto 在非 CUDA 情况下一律落到 sdpa，注释直说 MPS/XPU/CPU 不支持 flash_attention_2。
请注意分寸：参数里有 cpu 这个取值，只说明入口存在，不说明在 CPU 上跑得动或跑得快。仓库没有对这条路径做任何表现描述，我们也没跑过，所以到此为止。
入口二，vLLM 服务化。 docs/vibevoice-vllm-asr.md 走的是插件形态，文档写明不需要改 vLLM 源码；对应到 pyproject.toml 里就是那行 entry point：[project.entry-points."vllm.general_plugins"] 下的 vibevoice = "vllm_plugin:register_vibevoice"。部署是拿官方 vllm/vllm-openai 镜像挂载仓库目录，容器里执行 python3 /app/vllm_plugin/scripts/start_server.py。多卡有两个参数：--tp 是 tensor parallel，把一个模型切到 N 张卡；--dp 是 data parallel，起 N 个独立副本、由 nginx 反向代理在同一个端口后面做负载均衡。文档明确写了 Total GPUs required = dp × tp。环境变量层面文档列了 VIBEVOICE_FFMPEG_MAX_CONCURRENCY 与 PYTORCH_ALLOC_CONF 两个。
Troubleshooting 一节列了 CUDA out of memory 的处置方向：调小 --gpu-memory-utilization、--max-num-seqs、--max-model-len。至于到底要多少显存，文档没给数字，我们不推。
入口三，Transformers 原生。 这条线对应的是另一个模型 id microsoft/VibeVoice-ASR-HF，它的模型卡写明「VibeVoice-ASR is available as of v5.3.0 of Transformers」，加载写法是 AutoProcessor 配 VibeVoiceAsrForConditionalGeneration。这里有个真会绊人的细节：本仓库里的类名是 VibeVoiceASRForConditionalGeneration（见 vibevoice/modular/modeling_vibevoice_asr.py），Transformers 里的是 VibeVoiceAsrForConditionalGeneration，ASR 的大小写不一样，抄错了就是 ImportError。
模型卡里还写明输入用 processor.apply_transcription_request(...) 构造（它是 apply_chat_template 的包装），解码时 processor.decode(..., return_format=...) 可以取 "parsed" 或 "transcription_only"，并说明解析失败时原样返回生成结果。模型卡另有一节叫「Adjusting tokenizer chunk (e.g. if out-of-memory)」，写明长音频是被切成 60 秒一段、段间缓存卷积状态处理的；如果这个分块对你的设备来说太大，可以给 generate 传 tokenizer_chunk_size 调小，且该值需为声学 tokenizer hop length 的整数倍——这是模型卡当前写的默认值与约束，随版本可能变动。至于什么设备会遇到这个情况，模型卡没写，我们也不推。
BitNet 版：模型卡给的是量化路线，不是部署步骤
BitNet 那份模型卡的 frontmatter 里 library_name 写的是 ggml（常规版那两份写的是 transformers），tags 里带 quantization、cpu-inference、gguf、bitnet。光这几行就说明它不是同一套运行时。
量化是分模块做的，模型卡的 Quantization Strategy 表里写明：VAE Tokenizer 用 I8_S，LM Decoder 用 I2_S + Q6_K。仓库 README 的新闻节把这个组合称为 heterogeneous quantization（异构量化）。落到文件上，模型卡的 Model Files 表列了两个标注 ready to use 的 gguf：vibeasr-vae-encoder-i8_s.gguf 与 vibeasr-lm-i2_s-embed-q6_k.gguf，另有 model-*.safetensors 一栏注明用途是 for conversion。硬件侧模型卡写的是 commodity x86（AVX2）与 ARM（NEON），并写明在 ggml 框架内做了 fused operators 的自定义 SIMD kernel。
模型卡里同时给了体积、压缩比、RTF 与各基准的 WER 表。这些数值本文一律不搬——跑分和速度是会随版本与硬件变的，我们也没有能力复核，你要看就直接看模型卡原文。
顺带记一笔并置观察，只陈述不引申：BitNet 那个模型库里的 config.json，architectures 与 model_type 和常规版那份一致（VibeVoiceForASRTraining / vibevoice），但 decoder_config 里的 hidden_size、num_attention_heads、num_key_value_heads、max_position_embeddings 这几个字段与常规版那份并不在同一档，反而与仓库内 vibevoice/configs/qwen2.5_1.5b_64k.json 的 decoder_config 对得上。模型卡把 BitNet 描述为常规版的压缩变体，而这两处的字段值对不齐——原因我们不知道，也不据此推断任何能力或资源需求，只提醒你真要用的时候按实际下载到的文件核一遍。
哪些维度能比，哪些不比
能比的第一项：部署形态。 常规版给了三个入口且代码可读；BitNet 版把推理引擎放在另一个仓库，模型仓提供的是量化好的权重文件。
能比的第二项：量化路线。 BitNet 侧写得很具体，逐模块给了量化方法。反过来，常规版这边我们在仓库文档和模型卡里没有找到任何量化方案的说明——既没有量化脚本，也没有量化权重。想在常规版上自己压，仓库不提供依据。
能比的第三项：二次训练。 finetuning-asr/README.md 给了完整的 LoRA 路线：装 peft，用 torchrun 跑 lora_finetune.py，数据是音频加同名 JSON（字段有 segments、speaker、start、end，以及可选的 customized_context），可调 --lora_r、--lora_alpha、--lora_dropout，推理用 inference_lora.py，也可以用 peft 的 merge_and_unload() 合并权重。README 特别注明 toy_dataset/ 是合成数据、仅供演示，不是完整微调集。BitNet 侧，我们在模型卡里没有找到任何微调或再量化的说明，这一点不比。
不比的维度：功能面。 常规版文档与模型卡都写明了 hotwords / 上下文提示（vLLM 测试脚本有 --hotwords，Transformers 侧是 apply_transcription_request 的 prompt=）、说话人与时间戳的结构化输出、长音频单次处理。BitNet 模型卡的 tags 里与能力相关的只有 ASR 与 multilingual（其余几个是 quantization、cpu-inference 这类运行时标记），没有 Diarization、hotwords 一类标记，正文也没写这些能力。没写不等于没有，我们不替它下结论，这一栏留白。
同样不比的：速度、显存、准确率、音质。 我们没有下载权重、没有跑过推理，这四项一个字都不写。
这个差异什么时候会咬到你
如果你的场景要的是「谁在什么时候说了什么」这种结构化转写，再加上专有名词纠正，那常规版文档里写明的东西是齐的；换到 BitNet 版，你得自己去 VibeASR.cpp 那边确认这些能力在不在——模型卡没给这个答案。
反过来，如果你的约束是不能上 GPU、要离线跑在边缘设备上，那常规版这边仓库没有给你任何量化路线，--device cpu 只是一个参数取值而不是一份部署方案；BitNet 那两个 gguf 文件才是官方给出的、面向这个场景的产物。
还有一条容易忘的：两条线的运行时不同（transformers 与 ggml），意味着微调产物很可能不能直接互换。仓库和模型卡都没有写从 LoRA 结果到 gguf 的转换路径，别默认它存在。
本文依据 github.com/microsoft/VibeVoice 仓库与 Hugging Face 模型卡于 2026-08-18 的公开内容整理，事实来自仓库内的文档与源码。我们没有下载权重、没有跑过推理、也没有做过训练，因此不涉及显存占用、推理速度、识别准确率与音质的任何描述，也不与其它模型做比较或排名。该项目持续更新，文中涉及的模块路径、配置字段与接口写法随版本变动，请以仓库最新内容为准。
文中出现的命令与代码片段均原样取自上述仓库文档与模型卡，未经实测，以仓库最新内容与相应工具的实际输出为准。
仓库 README 的风险与限制一节写明：该模型仅供研究与开发用途，未经进一步测试与开发不建议用于商业或真实场景，并特别提示了合成语音被用于伪造与虚假信息的风险。使用合成语音时应遵守所在司法辖区的法律法规，并在分享 AI 生成内容时主动披露。
本文对照的是同一项目内的两种用法，依据均为上述仓库内容，不对两种用法做优劣排名，选型结论只在仓库文档写明的能力边界内成立。