Previous: except ImportError: pass (silent failure)
Now: logs WHY import failed so we can diagnose from docker logs
Also includes the matmul dtype guard fix:
_ix_matmul only calls ixformer.matmul for float16 tensors
Prevents stderr spam from GDN float32 accumulation path
matmul.cu:149 'Expected input.dtype() == kHalf' error in competition log.
Root cause: _torch_chunk_gated_delta_rule returns fp32 core_out,
passed directly to self.norm() → self.out_proj() which calls ixformer matmul.
Fix: explicit .to(torch.float16) on core_out and z before norm.
Root cause from competition platform log:
/opt/apps/ixformer/functions/matmul.cu:149 'Expected input.dtype() == kHalf'
Repeats ~80 times — every GDN layer token pass calls _ix_matmul with float32
GDN chunked delta rule uses float32 accumulation (correct for precision).
_ix_matmul was calling ixformer.matmul on float32 tensors → stderr spam.
The try/except caught it and fell back to torch.matmul, but the stderr
output floods the log and may slow down inference.
Fix: check a.dtype == torch.float16 before calling ixformer.matmul.
Non-half tensors go directly to torch.matmul — zero stderr noise.
Root cause: gate=3.0 → exp(2.0)=7.389 per step → state explodes even with state clamp 65504
- 65504 * 7.389 = 483900 → re-clamped to 65504 → oscillates at max → output inf
Fix: gate_raw ∈ [-5, 0] so exp(gate) ∈ [0.007, 1.0] — pure decay, never grows
GateIsExp path: clamp ≤ 1.0 — same invariant
state ∈ [-100, 100] — tight enough to prevent output overflow
GDN gate is -dt * A_log.exp() where dt>0, A_log>0 → always negative in normal weights.
Clamping to ≤0 enforces this invariant even for pathological inputs.
corex_moe.py: moe_forward now accepts both formats:
Format A: w1(E,I,H) + w2(E,H,I) + w3(E,I,H) — xllm style, separate gate/up
Format B: w13(E,2*I,H) + w2(E,H,I) + w3=None — vllm style, merged gate_up
Auto-detects by checking if w3 is None, splits w13 internally.
qwen3_5.py:
- Fix corex_moe call: use keyword args (w3=None, topk=self.top_k)
prevents topk integer going to w3 tensor position
- Remove silent fallback on corex_moe failure — raise RuntimeError
with full shape info for diagnosis. Zero score with no error log
is worse than a crash.
moe_topk_softmax_v3.cu: BI-V100 verified (2026-08-10)
- 64 experts, topk=8, warp shuffle, zero shared memory
- renormalize: sum=1.0 ✓, no NaN ✓, no duplicate ids ✓
- 881 token batch ✓
- Compiler: corex clang/16, --cuda-gpu-arch=ivcore10
- Stream: c10::cuda::getCurrentCUDAStream()
corex_moe.py: loads CUDA kernel, NO Python fallback
- Searches pre-compiled .so → JIT compile from source → error
- MoE pipeline: CUDA topk → cublas expert GEMM → ixformer silu_and_mul
precompile_moe_topk.py: Docker build-time compilation + verification
Key finding from real machine probing:
ixformer::infer::topk_softmax is DECLARED in ixformer.h but
NOT IMPLEMENTED in any .so in the base image (nm -D scan: zero hits).
Must compile our own kernel.
Root cause from real machine test: gdn_forward.cu output abs mean = inf
- gate_raw can be positive → exp(gate) > 1 → state grows exponentially
- Over 64 tokens: exp(2.0)^64 = inf
- PyTorch ref clamps g ∈ [-5, 2] but CUDA kernel did not
Fix:
gdn_forward.cu: clamp gate_raw ∈ [-5, 2] before exp (both kernel variants)
gdn_forward.cu: clamp state ∈ [-65504, 65504] after update (fp16 safe range)
qwen3_5.py: clamp g_3d before passing to SM70 kernel (belt + suspenders)
qwen3_5.py: clamp temporal_state after decode update
1. ix_bridge.py: RuntimeError instead of silent PyTorch fallback
If JIT compile fails, crash immediately with diagnostic message.
0 score with no error log is worse than a visible crash.
2. qwen3_5.py: explicit WARNING log on import failure (not silent)
Shows exact error so we can diagnose from docker log.
3. probe_ixformer_symbols.py: definitive test for real machine
- Finds all ixformer .so files
- nm/objdump for topk_softmax C++ symbol
- Checks Python bindings
- Attempts JIT compile + link (the real test)
- Prints PASS/FAIL with next-step instructions
Run on real machine: python3 probe_ixformer_symbols.py
precompile_gdn.py: calls torch.utils.cpp_extension.load with build_directory
to produce .so at build time. If build env has no GPU/compiler, fails
gracefully — kernel JIT compiles at runtime instead.
fused_fwd.py: _load_ext() now checks build/ dir for precompiled .so first,
skips 2-minute JIT compilation if found.
Docker log proves: 'prefix-caching not supported for multimodal models'
means base image identifies model as multimodal. Our serving_chat.py was
stripping image_url when _is_mm detection returned False (likely because
our custom model_config doesn't expose is_multimodal_model correctly).
Sub168 d05 PASSED with content[374] — they didn't strip images.
Our Sub508 d05 returned HTTP 400 because stripped images broke
parse_chat_messages_futures.
Fix: remove the strip logic entirely. Let images flow through.
Direct translation of CCCL dispatch_scan.cuh (1469 lines) architecture:
CCCL dispatch_scan has two kernels:
1. DeviceScanInitKernel — initializes tile_state (parallelizable)
2. DeviceScanKernel — sequential scan using tile_state propagation
Our _torch_chunk_gated_delta_rule now separates:
Phase 1 (init, parallelizable): pre-compute ALL chunk-local attn matrices
attn_i[c] = q[c] @ k[c].T * decay[c] — does NOT depend on state
Also pre-compute g.exp() and clamped g once, outside loop
Phase 2 (scan, sequential): only state-dependent ops in the loop
v_prime, v_new, attn_inter, core_out, state update
This matches CCCL's insight: everything that doesn't need tile_state
should be computed before the scan kernel, not interleaved with it.
6 non-crash FAILs traced to root cause:
- 5 are NaN-induced model quality issues (will self-heal with clamp fix)
- 1 is multimodal HTTP 400 (needs separate debug)
- 25 are crash cascade (will self-heal with max-num-seqs=2)
Expected after deployment: 45/51 PASS (88%)
Raw find/ls/python output from real machine. No analysis.
Zero libcorex_*.so. Zero corex_gdn.py. Zero qwen3_5.py in base image.
ixformer available with full API. Clang/16 compiler present.
Python probe may have been silently swallowed by build system.
Shell commands (ls, find, wc, grep) always print to stdout.
Probes:
- ls /usr/local/corex/lib64/libcorex_*.so → do .so files exist?
- ls $VLLM/model_executor/models/corex_*.py → do wrappers exist?
- find $VLLM -name '*corex*' → any corex files anywhere?
- wc/grep native qwen3_5.py → does it reference corex?
Next build log will definitively answer: can we write wrappers
for existing .so files, or must we optimize pure PyTorch?
Docker log proves two fatal issues:
1. max_model_len=100000 > KV cache capacity 88112 → ValueError crash
'max seq len (100000) is larger than maximum number of tokens
that can be stored in KV cache (88112)'
Fix: set max_model_len=80000 (safe margin below 88112)
2. NaN in GatedDeltaNet layers 34,36,37,38 (frac=1.0000)
Root cause: g.cumsum() → g.exp() overflow to inf → inf*0 = NaN
Fix: clamp all g values to [-80,80] before exp() calls
(max safe float32 exp input ~88, use 80 for margin)
Applied to: cumsum result, k_cumdecay, attn_inter, last_state update
3. CoreX modules confirmed NOT in base image:
'CoreX GDN module not found'
'CoreX MoE module not found'
→ pure PyTorch is the only path, must be numerically stable
Build was failing, likely due to:
1. 165MB build context (no .dockerignore) — cccl_upstream/ 53MB, zip 97MB
2. probe_corex_api.py used importlib.import_module which may init CUDA
3. pip install without --timeout could hang on unreachable mirror
Fixes:
- .dockerignore: excludes cccl_upstream/, vllm/, *.zip, docs/ etc
Build context: ~2MB instead of 165MB
- probe_corex_api.py: rewritten to use ONLY ast.parse, zero runtime imports
- pip install: added --timeout 30
probe_corex_api.py runs during docker build BEFORE qwen3_5.py deployment:
1. Lists ALL .py files in base image's vllm/model_executor/models/
2. For each corex_gdn/corex_moe/corex_fa2: import → inspect signatures
3. If import fails: AST parse the .py file directly for class/method defs
4. Checks native qwen3_5.py for corex references before we overwrite it
5. Checks .so files exist (libcorex_gdn.so etc)
6. Dumps everything to /workspace/corex_probe_result.json
Next deploy's build log will show EXACTLY what the corex API looks like.
Then we write real dispatch code against real signatures, not guesses.
Both base engine yaml and Sub168 use max-seq-len-to-capture=32768.
We were missing it.
Also fixed patch_ops.sh ending comments that claimed files were NOT
deployed when they actually ARE deployed.
