muh 86d6c9f6c2 [critical/config] baseline.muh: sync from computility-run.yaml — was stale
FOUND: baseline.muh had completely different values from computility-run.yaml
(the actual deployment config). This means gen_yaml.py would produce a WRONG
computility-run.yaml if someone regenerated it from baseline.muh.

Key differences synced:
  max_model_len:        100000 → 256000  (competition allows 256K context)
  gpu_memory_utilization: 0.9 → 0.95    (squeeze more KV cache)
  max_num_seqs:              1 → 2       (allow 2 concurrent sequences)
  max_num_batched_tokens: 8192 → 4096   (smaller prefill chunks)
  enforce_eager:        (missing) → true (BI-V100 doesn't support CUDA graph)
  dtype:                (missing) → half
  VLLM_ATTENTION_BACKEND: (missing) → XFORMERS

CRITICAL DISCOVERY: CoreX native libraries revealed:
  libcorex_fa2.so — Iluvatar FlashAttention2 (NOT generic xformers)
  libcorex_gdn.so — CoreX GDN ops
  libcorex_moe.so — CoreX MoE GEMM kernel
These are the REAL performance-critical kernels, loaded via VLLM_COREX_*
env vars. The Triton flash_attention.py is a FALLBACK, not the primary path.

CCCL insight: thread_store.cuh shows PTX cache modifiers (st.cg, st.cs)
may be ignored on non-NVIDIA hardware. This explains why LOAD_DEFAULT
outperforms LOAD_LDG on BI-V100 — CoreX has a different cache hierarchy.
2026-08-06 06:12:51 +00:00
2026-07-30 17:03:23 +08:00

project_6

Description
No description provided
Readme 428 MiB
Languages
C++ 41.8%
Cuda 31.6%
Python 22.2%
C 2.1%
CMake 1.1%
Other 1.1%