Skip to content

Commit c82c05b

Browse files
tengqmclaude
tengqm
and
claude
authored
docs(vllm): mthreads MUSA 4.3.6 verification (0.24.0) — T path ✅, F path ✅* (flagtree 0.6.1) (#413)
* docs(vllm): mthreads MUSA 4.3.6 verification (0.24.0) — T path ✅, F path ❌ Records the MUSA 4.3.6 0.24.0 verification on the mthreads platform (v0.3.0-dev, zero patches), completing the mthreads platform in the matrix: - T path ✅ (2026-08-17): `compiler triton` → vendor triton 3.6.0+git89458660, same pow kernel compiles, serve reaches `Application startup complete`, inference coherent. Fingerprint vllm-0.24.0-5936039f. Verified on DeepSeek-R1-0528-Qwen3-8B-FlagOS (the matrix's "Qwen3-4B" convention does not apply to this cell). - F path ❌ (two-layer root cause, no app-layer workaround, handed to the compiler team): flag_gems intercepts pow → flagtree 0.6.0+mthreads3.6 emits vectorized `v2f32 = fexp2` that vendor llc (-march=mtgpu -mcpu=mp_31) cannot select → SIGABRT; excluding pow (VLLM_FL_FLAGOS_BLACKLIST=pow_scalar, verified effective) falls through to native torch __rpow__/torch.pow which crashes on torch 2.9.0+musa.4.3.6 with INTERNAL ASSERT device().is_cpu(). Delivery is fixed to `compiler triton`. Contrast: 5.2.0's flagtree 0.6.1+mthreads3.6 passes the F path — the 0.6.0→0.6.1 difference is the suspected root cause. Matrix: MUSA 4.3.6 0.24.0(T) ⬜ → ✅, 0.24.0(F) ⬜ → ❌. Report gets §9. Co-Authored-By: Claude <noreply@anthropic.com> * docs(vllm): 4.3.6 F path ✅ on flagtree 0.6.1 (0.6.0→0.6.1 fixes fexp2) The suspected root cause of the 4.3.6 F-path failure is confirmed fixed: the same pow kernel (flag_gems pow_scalar → pow_func_scalar_tensor_kernel_rank_1_bptr_t1024, tl.exp2) that SIGABRTs with "LLVM ERROR: Cannot select: v2f32 = fexp2" under flagtree 0.6.0+mthreads3.6 compiles fine under 0.6.1+mthreads3.6 (op-level repro OK [1.0, 1.01358..., 1.02735...]); serve reaches Application startup complete, completions greedy + chat CoT coherent, fingerprint vllm-0.24.0-5936039f (same as T path, same container/plugin). Matrix: MUSA 4.3.6 0.24.0(F) ❌ → ✅* (asterisk = validated on flagtree 0.6.1; configs.yaml pins 0.6.0 and must be bumped to 0.6.1 + image rebuild before the cell matches the deliverable). Report §9.3 rewritten, 遗留事项 item updated to the configs bump. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
1 parent 0c75043 commit c82c05b

2 files changed

Lines changed: 105 additions & 5 deletions

File tree

‎packaging/vllm/docs/report-vllm-0.24.0.md‎

Lines changed: 80 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -479,11 +479,89 @@ MUSA 平台走插件路径（`PlatformFL` → device_type `musa`、dist_backend
479479

480480
---
481481

482-
## 9. 遗留事项
482+
## 9. mthreads（MUSA 4.3.6）详细记录
483+
484+
- 节点：`mthreads`（JumpServer → 10.121.38.24），用户 `secure`
485+
- 容器：`vllm-verify-mthreads-musa4.3.6`，MUSA SDK 4.3.6（torch 2.9.0+musa.4.3.6）
486+
- venv：`/flagos`（cpython-3.10 —— 与 5.2.0 同为 cp310 wheel）
487+
- 插件：v0.3.0-dev head（零补丁），editable install 于 `/opt/vllm-plugin-FL`
488+
- 模型：`/data/DeepSeek-R1-0528-Qwen3-8B-FlagOS`
489+
- 端口：8031
490+
491+
### 9.1 构建 + 安装
492+
493+
同 §8.1 —— 单步安装 `vllm==0.24.0+flagos`（cp310 wheel，命中 `+flagos`
494+
wheel，无 torch 侧漏）；`pin_indirect: {xgrammar: "0.2.3"}` 同。
495+
496+
### 9.2 插件基线：v0.3.0-dev 零补丁
497+
498+
同 §8.2 —— v0.3.0-dev head（fbc115d），零补丁。serve 启动链与 5.2.0 一致：
499+
OpManager **10 ops / 14 implementations** → attention_backend fallback
500+
`default.flagos` → `vendor.musa` → 权重加载 → `Application startup complete`。
501+
非致命遥测 fork 报错（`Cannot re-initialize MUSA in forked subprocess`）与
502+
§8.2 相同，不影响服务。
503+
504+
### 9.3 编译器路径判定
505+
506+
**T 路径 ✅**（vendor triton 3.6.0+git89458660）：
507+
508+
- 触发算子：YaRN rotary-embedding `_compute_inv_freq` 中的
509+
`base ** pos_freqs`（base=1000000.0，1024 元素 MUSA float 张量）→
510+
flag_gems `pow_scalar` → `pow_func_scalar_tensor_kernel_rank_1_bptr_t1024`。
511+
该内核在 **vendor triton 下编译通过**（op 级 repro 输出
512+
`OK [1.0, 1.01358..., 1.02735...]`）。
513+
- serve E2E ✅：`Application startup complete`；completions greedy 与
514+
chat CoT 均连贯；指纹 `vllm-0.24.0-5936039f`（5.2.0 为
515+
`vllm-0.24.0-423da8ca`）。
516+
- 验证模型为 DeepSeek-R1-0528-Qwen3-8B-FlagOS（mthreads 节点无 Qwen3-4B），
517+
矩阵"Qwen3-4B"约定在此单元格不适用；原始 completions 直给 R1 模型 +
518+
temperature 0.6 的整段重复回声是模型行为伪影（同 §8.2）。
519+
520+
**F 路径 ✅（flagtree 0.6.1；configs 现 pin 0.6.0 需 bump）**：
521+
522+
1. **0.6.0 的失败（双层根因，镜像原状）**：
523+
a. **flag_gems 拦截 pow → flagtree codegen 失败**：`base ** pos_freqs` →
524+
`__rpow__` → flag_gems `pow_scalar` → `pow_func_scalar_tensor_kernel_rank_1_bptr_t1024`
525+
（pow.py:61:34，`tl.exp2`）→ flagtree 0.6.0+mthreads3.6 发出向量化
526+
`LLVM ERROR: Cannot select: v2f32 = fexp2` → vendor llc
527+
（`/usr/local/musa/bin/llc -march=mtgpu -mcpu=mp_31`）无法选择 → SIGABRT。
528+
报错前一行是 `llc` failed with error code -6。
529+
b. **黑名单排除 pow 后落入损坏的原生 torch 路径**：
530+
`VLLM_FL_FLAGOS_BLACKLIST=pow_scalar`（**正确排除名** —— flag_gems
531+
`config_filter` 按 Python 函数 `__name__` 匹配，不是 aten schema 名
532+
`pow.Scalar`；`enable(unused=["pow"])` 不生效）→ pow 不再被 flag_gems
533+
拦截（崩溃位置从 flag_gems pow.py 变为 `torch/_tensor.py:1113` 的
534+
`__rpow__`）→ 原生 `torch.pow(other, self)` →
535+
`RuntimeError: tensor.device().is_cpu() INTERNAL ASSERT FAILED at
536+
pybind_utils.cpp:590` —— torch 2.9.0+musa.4.3.6 无法处理 Python float
537+
底数 ** MUSA 张量指数。
538+
2. **0.6.0→0.6.1 实验（2026-08-17）确认修复**：同一容器手动替换 flagtree
539+
为 **0.6.1+mthreads3.6**（whl `flagtree-0.6.1+mthreads3.6-cp310-cp310-...`，
540+
安装到 `/opt/flagtree061` 后整体替换 `/opt/flagtree`，原 0.6.0 保留在
541+
`/opt/flagtree060`）后：
542+
- op 级 repro 通过：同一 `base ** pos_freqs` 内核编译成功，输出
543+
`OK [1.0, 1.01358..., 1.02735...]`（0.6.0 下同脚本 SIGABRT）；
544+
- serve E2E ✅：`Application startup complete`（OpManager 10 ops / 14
545+
impls，rms_norm / silu_and_mul 走 `default.flagos`），completions greedy
546+
+ chat CoT 均连贯；指纹 `vllm-0.24.0-5936039f`（同 T 路径，同容器同插件）。
547+
548+
结论：`self.base ** pos_freqs` 在 flagtree **0.6.1** 下可用 —— 0.6.0→0.6.1
549+
即修复（不再对 `tl.exp2` 发出 vendor llc 不可选择的 `v2f32 = fexp2`）。
550+
**configs.yaml 4.3.6 现 pin flagtree==0.6.0（F 路径坏），需 bump 到 0.6.1
551+
并重建镜像后，单元格才对应交付物。** 5.2.0 自始即 0.6.1（§8，F 路径 ✅），
552+
两者对齐后 mthreads 平台 F 路径全线一致。
553+
554+
---
555+
556+
## 10. 遗留事项
483557

484558
- [ ] `setuptools 84.0.0` 不满足 pyproject 中 `<81` 要求 —— 非致命问题，先不动，留意。
485559
- [ ] 0.24.0 其余后端（hygon、iluvatar、enflame、sunrise、cambricon、
486-
ascend、kunlunxin 等）的验证 —— mthreads ✅（§8）；nvidia ✅（§6）
560+
ascend、kunlunxin 等）的验证 —— mthreads（§8 5.2.0 全通；§9 4.3.6
561+
T ✅ / F ✅*，`*` = flagtree 0.6.1 验证、configs 待 bump）；nvidia ✅（§6）
562+
- [ ] mthreads-musa4.3.6 **configs.yaml flagtree 0.6.0→0.6.1 bump** + 镜像
563+
重建 —— 0.6.1 已验证修复 F 路径（§9.3），0.6.0 构建的镜像 F 路径
564+
仍不可用，重建后矩阵 `✅*` 才对应交付物
487565

488566
---
489567

‎packaging/vllm/docs/vllm-verification-matrix.md‎

Lines changed: 25 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@
1717
| — | 该后端无此编译器 |
1818

1919
列名后缀：T = Triton 编译器，F = FlagTree 编译器。
20+
`*` = 单元格存在前置条件（flagtree 版本），见事实 bullet 与报告 §9。
2021

2122
## 矩阵
2223

@@ -35,7 +36,7 @@
3536
| 昆仑芯 | XRE 5.37.1 | ⛔ | ⛔ | ⬜ | ⬜ |
3637
| 沐曦 | MACA 3.7.2.1 | ⬜ | ✅ | ✅ | ✅ |
3738
| 沐曦 | MACA 3.8.1.3 | ⬜ | ⬜ | ✅ | ✅ |
38-
| 摩尔线程 | MUSA 4.3.6 | ⬜ | ⬜ | ⬜ | ⬜ |
39+
| 摩尔线程 | MUSA 4.3.6 | ⬜ | ⬜ | ✅ | ✅* |
3940
| 摩尔线程 | MUSA 5.2.0 | — | ✅ | ✅ | ✅ |
4041
| 进迭时空 | SPACEMIT | ⬜ | — | ⬜ | — |
4142
| 曦望 | TANGRT 1.2.0 | ✅ | ❌ | ⬜ | ⬜ |
@@ -120,6 +121,22 @@
120121
不清除已在 PYTHONPATH 的另一个 side dir，导致 entry-point 混叠
121122
（flagtree 声明 `mthreads` backend、/opt/triton 声明 `musa`），
122123
切换路径本身干净。已修 `runtime/zz-compiler.sh`（PR #411）。
124+
- **mthreads-musa4.3.6**（2026-08-17，v0.3.0-dev 零补丁，python 3.10）：
125+
**T 路径 ✅** —— `compiler triton` → vendor triton 3.6.0+git89458660，
126+
同一 pow 内核编译通过，serve 到 `Application startup complete`、推理连贯，
127+
指纹 `vllm-0.24.0-5936039f`（5.2.0 为 `vllm-0.24.0-423da8ca`）。
128+
验证模型同为 DeepSeek-R1-0528-Qwen3-8B-FlagOS（矩阵"Qwen3-4B"约定
129+
在此单元格不适用，同 §8）。
130+
**F 路径 ✅*（flagtree 0.6.1，2026-08-17 实验确认）**：同一容器手动替换
131+
flagtree 0.6.0 → **0.6.1+mthreads3.6** 后，同一 pow 内核（flag_gems
132+
`pow_scalar` → `pow_func_scalar_tensor_kernel_rank_1_bptr_t1024`，`tl.exp2`）
133+
编译通过 —— 0.6.0 下报 `LLVM ERROR: Cannot select: v2f32 = fexp2`
134+
（vendor llc `-march=mtgpu -mcpu=mp_31`）SIGABRT，0.6.1 下无此问题；
135+
serve 到 `Application startup complete`、completions greedy + chat CoT 均
136+
连贯（op 级 repro `OK [1.0, 1.01358..., 1.02735...]`）。
137+
**`*` 前提：configs.yaml 4.3.6 现 pin flagtree==0.6.0**（F 路径坏），
138+
需 bump 到 0.6.1 后重建镜像，单元格才对应交付物；0.6.0→0.6.1 差异即
139+
根因（见 `report-vllm-0.24.0.md` §9）。
123140

124141
**跨版本事实**
125142

@@ -136,6 +153,10 @@
136153
（TritonSDNN pass 链 / XTDK 后端断言），应用层无法绕过。
137154
- **sunrise**：flagtree flash-attn decode 挂死，已交 FlagTree 团队；
138155
交付固定走官方 Triton。
156+
- **mthreads-musa4.3.6**：flagtree **0.6.0** 对 pow 内核发出 vendor llc
157+
不可选择的 `v2f32 = fexp2`；黑名单排除后原生 torch pow
158+
（torch 2.9.0+musa.4.3.6）亦损坏。**0.6.1 已验证修复**（F 路径 ✅*）；
159+
阻塞项转为 configs.yaml 4.3.6 flagtree 0.6.0→0.6.1 bump + 镜像重建。
139160
- **iluvatar**：推理乱码根因在厂商工具链过旧（torch 2.7.1），非编译器层问题。
140161
- **enflame**：策略性不用 flagtree（不信任），走 vendor triton + native FLASH_ATTN。
141162

@@ -144,7 +165,8 @@
144165
1. **0.24.0 nvidia-cuda12.8 先行**（参考实现）：确认 0.24.0 在 flagtree 下的基线行为。
145166
2. **3.10 / 3.11 后端先补构建**：0.24.0 empty wheel 与 CPython 绑定，
146167
验证前需按后端 Python 版本构建对应 wheel。
147-
3. **双编译器后端逐一对两编译器验证**：metax 已全通；mthreads 已全通
148-
（F/T 双路径），hygon、enflame、sunrise 等按风险排序推进。
168+
3. **双编译器后端逐一对两编译器验证**：metax 已全通；mthreads 5.2.0 已全通
169+
（F/T 双路径）、4.3.6 T 路径 ✅ / F 路径 ✅*（flagtree 0.6.1，见上）；
170+
hygon、enflame、sunrise 等按风险排序推进。
149171
4. **单编译器后端**（cambricon、spacemit、thead）：只需验证可用的一列。
150172
5. **kunlunxin / iluvatar**：等待上游修复后再列入验证队列。

0 commit comments

Comments
 (0)