81875fff52d4ae24463ee87a95e6d254f298584e
Sub168 log analysis proves: - corex_gdn.py: dlopen /usr/local/corex/lib64/libcorex_gdn.so (decode) - corex_moe.py: ix_moe_bridge → ixformer::infer 7-step fused MoE pipeline - topk_softmax → moe_gen_idx → expand → group_gemm(w13) → silu → group_gemm(w2) → combine - corex_fa2.py: ixformer.functions flash_attn (packed/paged/chunked prefill + paged decode) Previous corex modules were pure PyTorch fakes with matching log messages. Now they actually call the ixformer C++ API via ix_moe_bridge.so. computility-run.yaml aligned to Sub168: max-model-len=256000, max-seq-len-to-capture=32768 Source reference: - upstream_ref/xllm/xllm/core/kernels/ilu/ixformer.h (C++ API declarations) - upstream_ref/xllm/xllm/core/kernels/ilu/fused_moe.cpp (MoE call pattern) - upstream_ref/xllm/xllm/core/layers/npu_torch/qwen3_gated_delta_net_base.cpp (GDN) - dockerrizhi.txt lines 310-397 (Sub168 runtime log)
project_6
Description
Languages
C++
41.8%
Cuda
31.6%
Python
22.2%
C
2.1%
CMake
1.1%
Other
1.1%