我们已在 vllm-metax 0.11.0 + MACA 3.3 上完成 transformers 5.3.0 与 tokenizer 补丁，仍卡在 layers.16 权重映射。计划升级至 v0.19.0+ 以获取 upstream glm_ocr 实现。请确认：① 是否有 Kylin ARM64 的 v0.19.0/v0.20.0 官方镜像；② C550 MACA 3.3 → 3.5.3/3.7 的升级路径；③ GLM-OCR 在 MetaX 上是否需额外 vllm_metax 模型适配。
star
- Members
- Joined 2026年6月9日
-
各位好，
我们在 ARM 麒麟 + MetaX C550 × 8 环境上，按官方 vLLM-metax 镜像尝试部署智谱开源 GLM-OCR（ZhipuAI/GLM-OCR，约 0.9B 多模态 OCR），参考沐曦 Day 0 适配新闻及 GLM-OCR 官方 vLLM 部署文档，目前环境验证通过，但 vLLM 服务无法端到端启动，想确认是否有含 glm_ocr 原生实现的 vLLM-metax 版本/镜像可提供。
一、环境信息
项目 值
CPU / OS
ARM aarch64，Kylin V10（4.19.90-89.11.v2401.ky10.aarch64）
GPU
MetaX C550 × 8，单卡 64GB
驱动
mx-smi 2.2.12
容器镜像
cr.metax-tech.com/public-ai-release/maca/vllm-metax:0.11.0-maca.ai3.3.0.11-torch2.6-py310-kylin2309a-arm64
容器内
torch 2.6.0+metax3.3.0.2，8 卡可见，vLLM 0.11.0
模型路径
/root/models/GLM-OCR（config.json 中 model_type=glm_ocr，safetensors 齐全）
二、已验证通过的部分
宿主机 8 卡识别正常，mx-smi 正常
vLLM-metax 容器可启动，PyTorch/MACA 正常
GLM-OCR 权重落盘完整
离线 wheel 升级 transformers 至 5.3.0 成功
对 vllm/transformers_utils/tokenizer.py 打兼容补丁后，AutoTokenizer.from_pretrained 正常
三、阻塞现象（按复现顺序）
1）默认镜像未升级 transformers
直接 vllm serve 在 ModelConfig 阶段失败：Value error, The checkpoint you are trying to load has model type
glm_ocr
but Transformers does not recognize this architecture.
镜像内置 transformers 4.57.1，不满足 GLM-OCR 要求的 >=5.3.0。
--trust-remote-code 无效，日志提示该参数被忽略。2）升级 transformers 5.3.0 后
越过 config 解析，但在 tokenizer 阶段报错（已通过补丁解决）：AttributeError: TokenizersBackend has no attribute all_special_tokens_extended
3）tokenizer 补丁后，权重加载失败（当前终极阻塞）
日志显示无 GLM-OCR 原生 vLLM 实现，fallback 到通用后端后权重映射失败：Resolved architecture: TransformersForMultimodalLM
WARNING TransformersForMultimodalLM has no vLLM implementation,
falling back to Transformers implementation.
INFO Using Transformers backend.
ERROR ValueError: There is no module or parameter named
'model.language_model.layers.16' in TransformersForMultimodalLM
RuntimeError: Engine core initialization failed.
启动时 vLLM-metax 会注册 Qwen2VL、Qwen3VL、DeepSeek 等，但日志中无 glm_ocr 注册项。
我们理解当前 vllm-metax 0.11.0 镜像缺少 glm_ocr 原生 Model 类，而 GLM-OCR 官方要求 vLLM >= 0.19.0。另：--speculative-config MTP 投机解码在当前环境报 Speculative decoding with draft model is not supported yet，已去掉该参数。
四、当前启动命令（单卡试跑）
export CUDA_VISIBLE_DEVICES=1
vllm serve /root/models/GLM-OCR \
--port 8080 \
--served-model-name glm-ocr \
--allowed-local-media-path / \
--max-model-len 4096 \
--gpu-memory-utilization 0.60 \
--max-num-batched-tokens 1024 \
--enforce-eager
（已升级 transformers>=5.3.0 并完成 tokenizer 补丁）五、已向社区/文档核对的信息
GLM-OCR 官方：pip install -U "vllm>=0.19.0" + transformers>=5.3.0
upstream vLLM 0.19+ 提供 vllm.model_executor.models.glm_ocr
沐曦 Day 0 新闻称 C500/C550 已适配 GLM-OCR，但我们手头 0.11.0 公开镜像无法跑通
我们评估过从 v0.19 拷贝 glm_ocr.py 到 v0.11，因 engine/loader/multimodal 接口差异及 MACA 算子适配，自行移植成本过高，希望走官方支持。六、想请沐曦协助确认
是否有支持 GLM-OCR 的 vLLM-metax 镜像 tag（版本是否需 >= 0.19）？若有，请提供镜像名与推荐启动参数。
Day 0 适配所用环境与公开 0.11.0 镜像是否一致？若不一致，差异点是什么？
除 vLLM 外，C550 + ARM 麒麟 上是否有推荐的 SGLang 部署 GLM-OCR 方案或镜像？
若暂无公开镜像，是否有计划/时间表，或可提供内部 patch（glm_ocr Model 注册 + MACA 适配）？
七、补充说明
同机其他模型（如 Qwen3-Coder-30B）在同底座 vLLM-metax 0.11.0 上可正常 8 卡 TP 部署，说明基础环境正常。
OCR 生产侧我们暂用 PaddleOCR + Triton（v16）兜底，GLM-OCR 主要用于复杂文档场景验证。
感谢指点。如需完整日志或复现脚本，我们可以补充 -
-06-09 17:17:38.541219737 [I:onnxruntime:, session_state_utils.cc:339 SaveInitializedTensors] Done saving initialized tensors
[ERROR][2026-06-09 17:17:42.870][graph_parser.cc:190] unsupported op: domain[], type[GridSample], version[16]
[ERROR][2026-06-09 17:17:42.870][graph_parser.cc:232] ParseNodeInfo for node[GridSample.4] failed: unsupported
[ERROR][2026-06-09 17:17:42.870][graph_parser.cc:320] ParseGraphNode failed.
[ERROR][2026-06-09 17:17:42.870][model_parser.cc:80] parse graph failed: unsupported
[ERROR][2026-06-09 17:17:42.873][runtime_builder_impl.cc:48] parse graph failed: unsupported
[ERROR][2026-06-09 17:17:42.882][opt_graph.cc:299] cannot find creator for CudaOptKernel[GridSample.4] type[:GridSample]16
[ERROR][2026-06-09 17:17:42.882][opt_graph.cc:1075] init kernels failed: not found
[ERROR][2026-06-09 17:17:42.882][engine.cc:122] OptGraph DoOptimeize failed: not found
[ERROR][2026-06-09 17:17:42.882][engine.cc:183] DoOptimize failed: not found
[ERROR][2026-06-09 17:17:42.882][utils.cc:246] process graph[MACA_0] by engine[cuda] failed: not found
[ERROR][2026-06-09 17:17:42.882][utils.cc:395] GenPartitionsInfoAndShapes failed:not found
[ERROR][2026-06-09 17:17:42.882][runtime_builder_impl.cc:87] process graph failed: not found
[ERROR][2026-06-09 17:17:42.882][runtime_impl.cc:105] cannot find consumer[Conv.0] of [image]
[ERROR][2026-06-09 17:17:42.882][runtime_impl.cc:269] GenGraphInputs failed: not found
[ERROR][2026-06-09 17:17:42.882][runtime_impl.cc:305] InitGraphResources failed: not found
[ERROR][2026-06-09 17:17:42.882][runtime_builder_impl.cc:108] init runtime failed: not found
Signal (11) received.
0# triton::server::(anonymous namespace)::ErrorSignalHandler(int) at triton_signal.cc:?
1# __kernel_rt_sigreturn in linux-vdso.so.1
2# 0x0000FFFDD9044724 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
3# 0x0000FFFDD95B6580 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
4# 0x0000FFFDD95B6BD0 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
5# 0x0000FFFDD95C695C in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
6# 0x0000FFFDD95D73C4 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
7# 0x0000FFFDD95DCC4C in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
8# 0x0000FFFDD95E3968 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
9# 0x0000FFFDD90207D8 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
10# 0x0000FFFDD8FC63E4 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
11# 0x0000FFFDD8FC6608 in /opt/maca-ai/onnxruntime-maca/lib/libonnxruntime.so.1.12.0
12# 0x0000FFFEF0618690 in /opt/tritonserver/backends/onnxruntime/libtriton_onnxruntime.so
13# 0x0000FFFEF05F5DEC in /opt/tritonserver/backends/onnxruntime/libtriton_onnxruntime.so
14# 0x0000FFFEF05FB074 in /opt/tritonserver/backends/onnxruntime/libtriton_onnxruntime.so
15# 0x0000FFFEF05FC814 in /opt/tritonserver/backends/onnxruntime/libtriton_onnxruntime.so
16# TRITONBACKEND_ModelInstanceInitialize in /opt/tritonserver/backends/onnxruntime/libtriton_onnxruntime.so
17# 0x0000FFFF07670540 in /opt/tritonserver/bin/../lib/libtritonserver.so
18# 0x0000FFFF07671288 in /opt/tritonserver/bin/../lib/libtritonserver.so
19# 0x0000FFFF076562B8 in /opt/tritonserver/bin/../lib/libtritonserver.so
20# 0x0000FFFF076568CC in /opt/tritonserver/bin/../lib/libtritonserver.so
21# 0x0000FFFF07661A1C in /opt/tritonserver/bin/../lib/libtritonserver.so
22# 0x0000FFFF06014210 in /usr/lib64/libc.so.6
23# 0x0000FFFF0764E9AC in /opt/tritonserver/bin/../lib/libtritonserver.so
24# 0x0000FFFF0624F40C in /usr/lib64/libstdc++.so.6
25# 0x0000FFFF0600F630 in /usr/lib64/libc.so.6
26# 0x0000FFFF06075B9C in /usr/lib64/libc.so.6[root@node1 triton_server]# docker run --rm \
--privileged \
--network host \
--ipc host \
-v /data/triton_server:/data/triton_server \
triton-metax:2.56-doclayout \
bash -lc '
python3 - <<PY
import onnx
p="/data/triton_server/model_repository/pp_doclayout_v2_20260415/doclayout_raw_gpu/1/model.onnx"
m=onnx.load(p)
ops=sorted(set(n.op_type for n in m.graph.node))
print("GridSample count:", sum(1 for n in m.graph.node if n.op_type=="GridSample"))
print("has GridSample:", "GridSample" in ops)
PY
'
GridSample count: 18
has GridSample: True
[root@node1 triton_server]#显示更多
17:20
确认了，模型里有：GridSample count: 18
has GridSample: True
所以现在可以定性了：当前沐曦 onnxruntime-maca 1.12.0 不支持 GridSample
因此 doclayout_raw_gpu 无法用 MACAExecutionProvider 跑 GPU
这不是你操作问题，也不是模型包没解好。日志已经非常明确：unsupported op: GridSample version[16]
下一步建议先把 doclayout_raw_gpu 改成 CPU，验证整个 DocLayout 流程能跑通。执行：
CONFIG=/data/triton_server/model_repository/pp_doclayout_v2_20260415/doclayout_raw_gpu/config.pbtxt
cp -a "$CONFIG" "$CONFIG.gpu_maca_gridsample_unsupported.bak.$(date +%Y%m%d_%H%M%S)"
cat > "$CONFIG" <<'EOF'
name: "doclayout_raw_gpu"
backend: "onnxruntime"
max_batch_size: 0input [
{
name: "image"
data_type: TYPE_FP32
dims: [1, 3, 800, 800]
}
]output [
{
name: "fetch_name_0"
data_type: TYPE_FP32
dims: [1, 300, 4]
},
{
name: "fetch_name_1"
data_type: TYPE_FP32
dims: [1, 300, 25]
}
]instance_group [
{
count: 1
kind: KIND_CPU
}
]parameters: {
key: "execution_providers"
value: { string_value: "CPUExecutionProvider" }
}
EOF
然后重启 Triton，再加载：cd /data/triton_server
bash dockers/pp_doclayout_v2_metax_ctl.sh stop
bash dockers/pp_doclayout_v2_metax_ctl.sh remove-containerexport CUDA_VISIBLE_DEVICES=3
export HOST_TRITON_ROOT=/data/triton_server
export IMAGE_NAME='cr.metax-tech.com/public-ai-release/maca/triton-inference-server:2.56.0-maca.ai3.3.0.10-torch2.6-py310-kylin2309a-arm64'bash dockers/pp_doclayout_v2_metax_ctl.sh start
这一步如果成功，说明：preproc / raw / postproc / ensemble 全链路 OK
只是 raw 模型不能走 MACA GPU
如果必须 GPU那就只能继续找支持 GridSample 的沐曦 ORT/Triton 镜像，筛选标准不是“opset17”，而是这个：
sess = ort.InferenceSession(model.onnx, providers=["MACAExecutionProvider"])
必须能成功，而且不能报：unsupported op: GridSample
目前这个镜像肯定不行。 -
举例一个场景：
PP-DocLayoutV2 官方模型是 Paddle 格式：
inference.pdmodel / inference.json + inference.pdiparams不是 PyTorch 模型。torch.export 只处理 PyTorch nn.Module，它不能直接读 Paddle 的 .pdmodel/.pdiparams。
即使你先把 Paddle 转 PyTorch，也不是简单命令，模型结构、权重名、算子都要适配，工程量很大。
另外你说的 opset=16，通常是：
torch.onnx.export(..., opset_version=16)
不是 torch.export。但前提仍然是：你已经有 PyTorch 模型。
所以当前可行性排序：
最推荐：找支持 opset17 的沐曦 Triton / ONNXRuntime 镜像-----你们官网竟然没有，能不能开发好和配套好再卖gpu