Commit Graph

5 Commits

Author SHA1 Message Date
Claude
6d0965195c [CCCL-PORT] Try native FusedMoE kernel before PyTorch fallback
CCCL source read: cub/device/dispatch/dispatch_reduce_by_key.cuh
  - DeviceReduceByKey sorts input by key, pads to tile boundary, then
    one fused kernel processes all key-value segments in parallel.
  - This is architecturally identical to base engine's fused_moe.py:
    moe_align_block_size (sort+pad) → invoke_fused_moe_kernel (one launch).

Discovery: _custom_ops.py (line 776-806) confirms ixformer HAS native MoE:
  - ixf_F.vllm_moe_topk_softmax
  - ixf_F.vllm_moe_align_block_size
  - ixf_F.vllm_invoke_fused_moe_kernel (takes only BLOCK_SIZE_M config)

Previous code assumed 'ixformer lacks MoE kernels' and used _pure_pytorch_experts
(Python for-loop over 256 experts). This may have been wrong or outdated.

Change: MoeSparseBlock.forward now tries self.experts (FusedMoE native) first.
If the native kernel fails on BI-V100, it catches the exception, logs a warning,
and permanently falls back to _pure_pytorch_experts for that instance.

Impact if native works: one fused CUDA kernel vs 256× F.linear calls = massive
decode speedup. Impact if native fails: same behavior as before (fallback).
2026-08-05 08:31:34 +00:00
Claude
10af71357b [CCCL-PORT] Two architecture-level optimizations from CCCL system design
Source CCCL files read as input:
  - cub/block/block_scan.cuh (RAKING algorithm concept)
  - cub/device/dispatch/dispatch_reduce.cuh (GridEvenShare, two-pass)
  - cub/agent/agent_reduce.cuh (vectorized vs scalar load paths)
  - thrust/examples/histogram.cu (sort + reduce_by_key pattern)
  - thrust/examples/scan_by_key.cu (keyed scan for state propagation)

Optimization 1: DeltaNet chunk kernel — solve_triangular replaces for-loop
  63 Python iterations → 1 CUDA kernel (lower-triangular system solve)

Optimization 2: MoE prefill — sort tokens by expert_id for contiguous gather
  CCCL histogram pattern: sort → segment → batched process
2026-08-05 08:20:01 +00:00
Claude
c5a0d61851 sync: align with enginex-vllm-bi100-qwen36 baseline (1902c81f)
Synced files from EngineX baseline zip (2026-06-30):
- ADD paged_attn.py (root): production paged attention with PyTorch fallback
- ADD launch_service: BI-V100 server startup script with env configuration
- SYNC computility-run.yaml: gpu_memory=0.9, batched_tokens=8192, seq_capture=32768
- SYNC qwen3_6_scripts/paged_attn.py: +311 lines, Triton bypass docs, _forward_decode_pytorch shape docs
- SYNC qwen3_6_scripts/qwen3_5.py: -72 lines, revert optimized MoE prefill to baseline (untested on BI-V100)
- KEEP Dockerfile: repo version has V2/Triton/head256 optimization patches not in baseline

Baseline commit: 1902c81fdd373943f17f5983eb8750758c7f4a69
Source: enginex-vllm-bi100-qwen36-main.zip (dev.modelhub.org.cn)
2026-07-31 09:43:58 +00:00
dylanyunlon
7ad59e781f [OPT] MoE prefill: sorted-token grouped GEMM (contiguous per-expert access)
Qwen3.6-35B-A3B has 256 experts × top_k=8. The baseline prefill MoE:
  for eid in unique_eids:  # up to 256 iterations
      tokens = hidden_states[tok_ids]  # SCATTERED gather
      F.linear(tokens, w13[eid])

Problem: hidden_states[tok_ids] creates a non-contiguous gather for each expert.
With 16384 tokens × 256 experts, this is 256 scattered gathers per layer.

Optimization (CCCL segmented-sort pattern):
  1. Flatten all token-expert pairs: (T×K,) assignments
  2. Sort by expert ID: tokens for same expert become CONTIGUOUS
  3. Each F.linear gets contiguous input → much better memory access
  4. Activation (silu × up) computed in ONE fused op across all pairs
  5. index_add_ scatter-back is one kernel call

Memory access improvement:
  Before: 256 × hidden_states[random_indices] → scattered HBM reads
  After:  sorted_tokens[start:end] → sequential HBM reads per expert

The expert loop still exists (can't batch variable-size GEMMs with F.linear),
but each iteration reads contiguous memory instead of scattered indices.
2026-07-30 16:12:42 +00:00
dylanyunlon
ef6abf3dc7 [DEPLOY] Complete submission: baseline + all optimizations
Adds ALL files needed for Dockerfile build:
  - qwen3_6_scripts/ (baseline patches + our optimizations)
  - vllm/ (full vllm package)
  - paged_attention_v2_pytorch.py (V2 with single-bmm optimization)
  - Dockerfile + computility-run.yaml

Our optimizations vs baseline:
  1. paged_attn.py: pre-gathered context KV (eliminates 194 gather calls),
     Triton try/fallback, V2 heuristic, threshold 32K→64K
  2. paged_attention_v2_pytorch.py: fills NotImplementedError,
     single-bmm Phase 1 (195 launches → 3)
  3. patch_enable_triton.py: HAS_TRITON=True with safety fallback
  4. patch_triton_tuning.py: BLOCK=64, NUM_WARPS=4 for BI-V100
  5. computility-run.yaml: gpu-memory-utilization 0.9→0.95,
     max-num-batched-tokens 8192→16384

This repo can now be submitted to dev.modelhub.org.cn as-is.
2026-07-30 16:06:20 +00:00