AREX Feed Article
vLLM 宣布 Day-0 支持 ERNIE 5.5 Flash Base，部署需装百度的 vLLM-ERNIE 插件
11 月 5 日 22 时 14 分（UTC 14:14），vLLM 项目的官方 X 账号 @vllm_project 发帖称，已对百度 ERNIE 5.5 Flash Base 提供 。帖文给出的具体形态是：用百度提供的 vLLM-ERNIE 插件，在 vLLM 0.32.0 上以 FP8 或 BF16 精度部署模型；ECHO 投机解码走 vLLM 的 MTP（多 token 预测）路径；配套的 recipes（部署配方）覆盖专家并行、KV 缓存卸载（KV offload）与预填充/解码分离（prefill/decode disaggregation）；并称已在 NVIDIA GB200 与 H100 上验证运行。
当晚 22 时 01 分，百度 ERNIE 账号先发布了这批，vLLM 的帖文随之复述了 280B 总参数、14B 每 token 激活、33.5T 预训练 tokens、128K 训练上下文与 1M 微调/推理上下文。这些规格在里已经写明；新增的是部署侧的具体形态：版本号、插件、精度、配方与硬件清单。
支持走百度的外部插件，插件没装对就加载不了
vLLM 的写明，模型通过 out-of-tree（在 vLLM 主仓库之外）的 vLLM-ERNIE 插件服务，跑在已发布的 vLLM 0.32.0 wheel（预编译安装包）上，不修改 vLLM 本身；插件仓库 以 Apache-2.0 开源，通过 vllm.general_plugins 入口加载，安装命令是 uv pip install vllm==0.32.0，再加 uv pip install git+https://github.com/baidu/vLLM-ERNIE.git。
vLLM 0.32.0 本身在 10 月 18 日发布（）。插件仓库的创建时间是 10 月 27 日，比权重发布早 9 天（）。
对部署方来说，边界由插件决定：仓库自述只在 NVIDIA GPU 上运行；插件没装对时 vllm serve 会报 Model architectures ['Ernie5_5_MoeForCausalLM'] are not supported，仓库的排查建议是确认插件装在运行 vLLM 的那个环境里，或者 VLLM_PLUGINS 没有把 ernie 排除掉。模型卡的部署段落同时列了 SGLang 与 vLLM 两条路径。
版本写法也不一致：配方页的标记写「vLLM 0.32.0+」，插件仓库的安装命令固定 vllm==0.32.0，两边都没有说明更高的 vLLM 版本该配哪个插件版本。许可同样分两套：插件是 Apache-2.0，权重按 ERNIE 5.5 Flash Base Model License Agreement v1.0 提供（见模型卡）。
配方给的是并行方式、显存下限和一条只开到 128K 的启动命令
配方页默认的启动命令是：--data-parallel-size 4 --enable-expert-parallel 做 attention 数据并行加 MoE 专家并行，--kv-cache-dtype fp8 把 KV cache 存成 FP8，--moe-backend humming 在 Blackwell 上启用支持 FP8 权重与 SiTU 激活的 MoE kernel，--max-model-len 131072，再加 --speculative-config '{"method":"mtp","num_speculative_tokens":2}' 打开两步 ECHO 草稿。页面说明所有配方都采用 attention 数据并行与 MoE 专家并行；插件仓库另提到 attention 张量并行（TP 2、4、8）也能用，但保留的 KV cache 更少。
显存下限按权重精度分档，配方页给出的估算如下：
| GPU（显存） | FP8（约 280 GB 权重） | BF16（约 560 GB 权重） |
|---|---|---|
| B300 / GB300（288 GB） | 2 张 | 4 张 |
| B200（192 GB） | 4 张 | 8 张 |
| GB200（192 GB） | 4 张 | 2 个 tray × 4 张 |
| H100（80 GB） | 8 张 | 2 个节点 × 8 张 |
H100 这一档能看出权重体积的约束：稀疏激活只压缩每 token 的计算量，权重体积不变，FP8 权重仍有约 280 GB，80 GB 卡要 8 张才装得下；BF16 约 560 GB，需要两个节点各 8 张。
1M 上下文也不是默认项。每条配方都只用 128K 训练长度（--max-model-len 131072）；要用 1,048,576，需要改这个参数、降低 --max-num-seqs 让每张卡的 KV cache 装得下整条请求，并把 --gpu-memory-utilization 从默认 0.92 降到 0.85；配方页的解释是 1M token 的 prefill 还要额外几十 GB 临时显存。80 GB 卡放不下 1M，H100 在 0.93 利用率下最高 262,144。
ECHO 把最后一层当草稿，实测每步接受 1.98～2.49 个 token
ERNIE 5.5 Flash 的 43 层里有 1 层 dense FFN 和 42 层 Multi-Router Latent MoE，注意力是 37 层 HCA（Heavily Compressed Attention，高度压缩注意力）加 6 层 MLA-DSA，每个 MoE 层 512 个路由专家取 top-10、另加 1 个共享专家，专家在 2048 维 latent 空间里计算（见模型卡）。插件仓库列出的实现就是 HCA + MLA-DSA、mHC（用流形约束的超连接替换残差流）与 MoE 这套结构，Ernie5_5_MoeForCausalLM 由插件提供，vLLM 才能加载。
ECHO 用的是 vLLM 现成的 MTP 路径。按模型卡的说法，checkpoint 在主栈之后带一层 ECHO，它复用了骨干自己的最后一层，训练时预测未来 token，推理时直接当草稿模型，不再单独训练一个 MTP 模块。配置上用 --speculative-config 里的 method: mtp 和草稿步数控制。
配方页给了这层草稿的实测：GSM8K、batch size 1、贪心解码下，1、2、3 步草稿的平均接受长度分别是 1.98、2.39、2.49 个 token，准确率不变；2 步拿走大部分收益，低延迟预设就用 2 步。配方页没有给出吞吐或延迟数据，与速度有关的只有这组接受长度。
长上下文的账：KV 卸载分三档，预填充与解码拆开跑
要跑到 1M 上下文，KV cache 是配方页处理的重点。配方页给了三种卸载方式：Simple 按 DP rank 预留主机内存给 KV 缓存，GB200 tray（4 卡单元，4 个 rank）上每 rank 默认的 220 GiB 太大，页面建议改成 128 GiB；CPU + 文件系统在 NVMe 上留一层，页面记录 ERNIE 5.5 的 KV 块在磁盘上约 280 KB/token；Mooncake 把各张卡的 host memory 汇成池子，需要安装 mooncake-transfer-engine-cuda13，并把 MOONCAKE_DEVICE_NAME 只指向 InfiniBand HCA，否则会选到以太网口导致传输失败。
prefill/decode 分离（PD 分离）的配方更具体：一个 prefill、一个 decode 的 GB200 tray，各自 DP4 + EP4，KV 通过 MooncakeConnector 走 RDMA，前面挂 vllm-router==0.1.16，投机解码的配置要在两边写成一样。配方页对 KV 卸载的解释是，长共享前缀（系统提示、agent 历史）离开 GPU cache 后可以留在显存外，需要时载回而不是重算；代价是主机内存与 NVMe 空间。
还没回答的问题：吞吐、验证范围，以及目前只能做续写
帖文说在 GB200 与 H100 上验证运行，但没有给吞吐、首 token 延迟或每卡 tokens/s；配方页同样没有这些数字，只有显存下限和 ECHO 的接受长度。硬件范围也比帖文点名的两款宽：配方页为 B300/GB300、B200、GB200、H100 都列了配置和显存估算，而帖文的「已验证」只写了 GB200 与 H100。这些运行结论的出处是 vLLM 项目自己的账号与配方页。
插件仓库还有一条运维提醒：示例命令绑定 0.0.0.0 且不带鉴权，除非网络可信，否则要加 --api-key 或改绑 127.0.0.1。
接口层还有一个限制。Base 权重只做文本续写，走 /v1/completions；配方页明确说它没有 chat、reasoning 或 tool-call 训练，--reasoning-parser 与 --tool-call-parser 对它不适用。配方里的 DSpark 草稿与 ernie5 解析器都指向尚未发布的 post-trained 版本，对 Base 权重都不适用。