[CV186X 1-core] Qwen3-VL-2B bmodel produces garbage output — compiler creates 2-core context despite --num_core 1

[brewswang-maker]

Environment

Item	Detail
Chip	CV186AH (BM1688 family, 1-core TPU)
libsophon	0.4.14 (2026-06-11)
tpu-mlir	v1.28.1-20260429 (latest from pip)
Model	Qwen3-VL-2B-Instruct (official BF16 weights from ModelScope)
Runtime	LLM-TPU cpp_demo ( sophgo/LLM-TPU, Qwen3_VL )

Compilation

llm_convert.py \
  -m Qwen3-VL-2B-Instruct \
  -s 2048 \
  -q w4bf16 \
  -c cv186x \
  --num_core 1 \
  --max_input_length 1024 \
  --max_pixels 768,768 \
  --dynamic

Compilation completes successfully. Output bmodel is 2.1 GB, 61 networks (vit + embedding + 28×block + 28×block_cache + lm_head).

Problem

The bmodel loads normally on the device (DevMem ~4934/5628 MB), but block_0 prefill output is garbage — regardless of input, the model produces incoherent hallucinated text.

Tested 3 compilation variants, all produce garbage:

#	Source Weights	Mode	Output (input: "你好")
1	kaitchup W4A16 (GPTQ)	dynamic	inate...
2	kaitchup W4A16 (GPTQ)	static	!!!!!!
3	Official BF16 (ModelScope)	dynamic	ocale!!! then long English hallucination

Key Evidence: Compiler creates 2-core context even with --num_core 1

In the block compilation log (block_0.log), even though --num_core 1 was specified:

TPU-MLIR v1.28.1-20260429
Create Core #0/2, NPU_NUM=32       ← Creates 2-core context!

The final bmodel reports core num: 1 in its header, but the kernel code appears to be generated for a 2-core context, which may produce incorrect results on a 1-core CV186AH.

bmodel Structure (from model.log)

bmodel version: B.2.2+v1.28.1-20260429
chip: CV186X
net 0: [add]          static
net 1: [vit]          dynamic
net 2: [embedding]    static
net 3-30: [block_cache_0..27]  static
net 31: [embedding_cache]      static
net 32: [lm_head]     static
net 33-60: [block_0..27]      dynamic
Total: 61 networks

block_0 inputs:

input: input_states,     [1, 1024, 2048], bfloat16
input: position_ids,     [3, 1024], int32
input: attention_mask,   [1, 1, 1024, 1024], bfloat16
output: output_states,   [1, 1024, 2048], bfloat16
output: k_cache,         [1, 1024, 8, 128], bfloat16
output: v_cache,         [1, 1024, 8, 128], bfloat16

TPU Core Verification

Verified 1-core via C API on the device:

bm_get_tpu_scalar_num(handle, &core_num);
// Returns: status=0, value=1

Official bmodel Availability

The LLM-TPU Qwen3_VL README provides pre-compiled bmodels for:

• bm1684x_1dev_dynamic (BM1684X)
• bm1688_2core_dynamic (BM1688, 2-core only)

No cv186x_1core or bm1688_1core pre-compiled bmodel is provided for any VLM model (checked Qwen3-VL, Qwen2.5-VL, Qwen2-VL, InternVL3, MiniCPMV4.6).

Request

1. Is CV186X 1-core TPU supported for Qwen3-VL compilation? If yes, can you provide a pre-compiled cv186x_1core bmodel for verification?
2. The Create Core #0/2 log with --num_core 1 suggests the compiler may not correctly handle single-core codegen for CV186X. Could this be a bug?
3. Text-only models (e.g., Qwen2-1.5B) compiled with the same toolchain work correctly on the same device — the issue appears specific to VLM (qwen3_vl) model compilation on 1-core.

Related

• All VLM models on BM1688 in LLM-TPU repo only ship 2core variants
• Text models (Qwen2/Qwen2.5) have both 1core and 2core variants and work fine on CV186AH