In large-model inference, the Attention formula is usually not the hardest part; what really determines performance is often how data lands in memory and at what granularity the hardware can fetch that data at once.

This article uses Qwen3.5’s official prefix-off long-context path as an example to discuss a problem that seems small but actually runs through vLLM configuration, KV Cache, paged attention, and DCU kernel dispatch: the default physical KV Cache page on this path is 784 tokens, while the vendor paged-attention path on Hygon DCU gfx936 requires the page length to satisfy 64-token alignment. In the end, we did not hard-code page size as a scheduler parameter; instead, following vLLM’s existing hybrid Attention/Mamba page calculation logic, we automatically derived it to the minimum compatible value 832.

This change itself differs only by one number, but it changes the precondition for whether the kernel can be invoked. Subsequently, chunked-prefill with q=4096 enters the vendor FlashAttention path, while q=1 decode continues to use the page-contiguous Triton path, avoiding mixing two completely different workloads into one kernel.

This article focuses on DCU execution granularity, KV Cache physical layout, block table address calculation, and end-to-end validation. It does not cover competition submission, repository addresses, or internal environment details.

1. Why Start Looking at Attention from the “Page”

For a context of length T, Attention needs to access historical K/V. vLLM does not allocate one contiguous K/V block per request; instead, it slices the cache into fixed-size physical pages and maps logical pages to physical pages via the block table.

The address of a token can be simplified as:

1
2
3

logical_page = token_index // BLOCK_SIZE
page_offset  = token_index %  BLOCK_SIZE
physical_page = block_table[logical_page]

Then combine this with the K/V cache stride, KV head, and head dimension to calculate the final address.

This paged design solves memory fragmentation and dynamic request management, but it also brings a hardware fact: BLOCK_SIZE is not just an integer in the scheduler; it also determines the kernel’s intra-page loop, vectorized access, and boundary mask.

If the hardware kernel wants to use 64 tokens as a regular access unit, then a physical page not divisible by 64 usually leaves an irregular tile or extra boundary handling at the tail of each page. For short requests, this may be only a small waste; for long contexts, page-table parsing and K/V reads are repeated many times.

2. Key Constraint of gfx936: wave64 and 64-Token Access Granularity

The ROCm-compatible execution environment of Hygon DCU uses wave64 execution granularity on the gfx936 path. Here wave64 should not be simplified to “the number of threads becomes 64”; it affects:

• how threads within a wave cooperate to load vectors;
• how the token dimension of K/V is assigned to lanes;
• whether contiguous addresses can form regular memory transactions;
• how the kernel handles page-tail masks and cross-page access.

In the vendor paged-attention interface used in this experiment, the physical page length must satisfy 64-token alignment. What is directly confirmed by source code and runtime logs is this interface constraint; it matches the access granularity of wave64, but this article does not attribute 64 alignment solely to wave64. The default 784 can be decomposed as:

1

784 = 12 × 64 + 16

and 832 can be decomposed as:

1

832 = 13 × 64

This means page832 can internally consist of 13 complete 64-token access groups, without leaving an irregular 16-token tail block at the end of each physical page. The benefit here does not come from reducing Attention mathematical computation, but from aligning data layout with hardware execution granularity.

It should be emphasized that page832 is not an empirical parameter of “bigger is faster”. 1024 also satisfies 64 alignment, but it has about 30.6% more token capacity than 784; 832 increases by only about 6.1% and is the minimum compatible page satisfying the constraint, more suitable for memory-constrained 27B hybrid models.

3. Why Qwen3.5’s Hybrid Cache Makes This Problem More Complex

Qwen3.5 contains both full attention and GDN/Mamba-like state paths. vLLM needs to keep the Attention page and Mamba state page compatible in the hybrid model; otherwise, the same request encounters different cache granularity and padding rules across layers.

On the path with prefix caching disabled, page selection can be abstracted as (omitting the minimum comparison and subsequent padding branches in the existing configuration):

1
2
3
4

attn_page_size_1_token = FullAttentionSpec(...).page_size_bytes
required_page = ceil(mamba_page_bytes /
                     (alignment_tokens * attn_page_size_1_token))
                 * alignment_tokens

For this Qwen3.5/DCU shape, backend adaptation raises alignment_tokens from the generic 16 to 64; after calculation along the existing verify_and_update_config logic, the default page is rounded up from 784 to 832.

This is two different things from directly writing block_size = 832 in the scheduler:

1. The calculation is still completed by existing model configuration and cache-spec data flow;
2. Page size is still passed to subsequent components as the result of KV Cache physical layout;
3. The scheduler’s token budget, chunk count, and request scheduling semantics remain unchanged;
4. When Qwen3.5, ROCm, head size, KV head count, and prefix state conditions are not met, the original logic is preserved.

The core of such a change is “letting the backend’s physical constraints enter the existing layout calculation”, rather than bypassing vLLM’s cache model with a new parameter.

4. Actual Page Shape of Qwen3.5

The full-attention shape in this experiment is highly deterministic:

1
2
3
4
5

query heads: 24
KV heads:     4
GQA ratio:    6
head size:    256
dtype:        BF16

vLLM’s complete K/V cache tensor also includes a K/V dimension; the shape can be written as:

1

[num_physical_pages, 2, BLOCK_SIZE, 4, 256]

After unbind(1), the shape of an individual K or V cache is:

1

[num_physical_pages, BLOCK_SIZE, 4, 256]

When K and V are stored separately, the data volume of a single page is approximately:

1

BLOCK_SIZE × 4 × 256 × sizeof(BF16)

For K and V together, multiply by 2. After switching to page832, a single page holds a few more tokens, but every 64-token group within the page is complete. This increased capacity cost must be evaluated together with kernel memory access efficiency; one cannot look only at single-page latency.

5. From Page Table to Coalesced Load

The core loop of a generic Triton paged-attention kernel can be abstracted as follows:

1
2
3
4
5
6
7
8
9
10

for tile in key_tiles:
    token = tile * TILE_SIZE + lane_offset
    logical_page = token // BLOCK_SIZE
    page_offset = token % BLOCK_SIZE
    physical_page = block_table[logical_page]

    K = load(key_cache[physical_page, page_offset, kv_head, dim])
    V = load(value_cache[physical_page, page_offset, kv_head, dim])
    score = dot(Q, K) * scale
    update_online_softmax(score, V)

On page784, the result of token % BLOCK_SIZE leaves an interval at the page tail that cannot be aligned with a 64-token access group. A generic kernel can guarantee correctness via mask, but mask does not turn irregular addresses into regular addresses; what is described here is mechanistic inference of memory-access layout, not additional hardware trace counts.

On page832, the token interval within a page can naturally be divided into complete 64-token groups. The vendor kernel still needs to handle the actual length of the last request, but it does not need to face a fixed 16-token tail block inside every physical page.

The optimization point here is not “removing the causal mask”. The causal constraint is fully preserved; what changes is the intra-page loop and physical address layout, making vector loads better suited to DCU execution granularity.

6. Why the Vendor Kernel Only Takes Over Strict Single-Sequence Prefill Shapes

Long-context serving is not a single workload. q=1 decode, q=4096 chunked-prefill, and the final tail chunk of less than 4096 differ in parallelism, memory-access direction, and graph capture method.

Therefore, the vendor dispatch of the final Tail-Q version uses strict conditions rather than global replacement:

1
2
3
4
5
6
7
8
9
10
11
12

1 < num_actual_tokens <= 4096
max_seqlen_q == num_actual_tokens
single sequence
decoder attention
BF16 Q/K/V/output
Qwen3.5: 24 Q heads, 4 KV heads, head size 256
page size = 832
GQA ratio = 6
causal = true
no sliding window
no ALiBi / sinks / softcap
no multimodal prefix range

When the conditions are met, call the existing vendor varlen_fwd_unified interface:

1
2
3
4
5
6

q, k, v
cu_seqlens_q
seqused_k
block_table
max_seqlen_q / max_seqlen_k
causal = true

If not met, fall back to the original unified Triton attention. This design has two engineering implications:

• The vendor kernel only faces the fixed shapes it is really good at;
• Even if the new path is unsuitable at some boundary, it will not pollute generic attention.

The initial candidate only covered q=4096; the final Tail-Q version covers 1 < q <= 4096 and max_seqlen_q == q, explicitly excluding q=1 decode. Thus the last prefill chunk of less than 4096 can also enter the same class of full causal attention, without changing the scheduler’s chunking logic.

7. Why Decode Needs a Separately Maintained Page-Contiguous Path

prefill has a large q, suitable for letting vendor FlashAttention handle an entire query chunk; decode q is usually 1, and the main problem becomes reading K/V from a large number of historical pages and completing online softmax with low launch overhead.

The loop of the page-contiguous decode kernel is closer to:

1
2
3
4
5
6
7

for page_idx in pages_for_sequence:
    physical_page = block_table[page_idx]
    for local_tile in tiles_inside_page:
        page_offset = local_tile * TILE_SIZE + offsets
        K = load(K_cache[physical_page, page_offset, ...])
        V = load(V_cache[physical_page, page_offset, ...])
        update_online_softmax(Q, K, V)

This path still parses the block table; it does not skip any logical page, nor change the causal range. It only reduces generic scheduling overhead for the access geometry of q=1, GQA6, head size 256, and supports both page784 and page832.

On page832, the decode speedup of the standalone CUDAGraph microbench is approximately:

This set of results is bitwise exact; however, the speedup of an independent kernel cannot be directly treated as end-to-end serving speedup, because decode is also surrounded by Linear, sampling, graph replay, and Python/scheduling boundaries.

8. Measured Results: How Kernel Speedup Propagates to the Serving Layer

Under the same container, same model, same native extension, and same dataset, baseline uses the official prefix-off page784 path, candidate uses page832, vendor prefill, and page-contiguous decode. Each side completed 10/10 for all three tiers, failed=0. Runtime logs also confirm four key facts:

1
2
3
4

baseline: prefix caching = False, block size = 784
candidate: prefix caching = False, block size = 832
vendor q=4096 prefill marker: hit
page832 decode marker: hit

The relative changes of the local three-tier A/B are:

q=4096 vendor prefill standalone is about 2.75x-2.92x relative to the page784 Triton path; the improvement in full serving is significantly smaller than this number. The long tier has more obvious gains because in this test workload, q=4096 chunks and long-sequence paged-KV access account for a higher proportion; this is an explanation derived from workload/profile and should not be understood as a single trace already proving the exact proportion of a certain memory transaction.

This also explains why one cannot use only a kernel table as the conclusion: in the official 8K profile of page832, prefix-off, all-Tail-Q, the total Attention bucket of q=4096 prefill drops from 681.071 ms to 238.718 ms; this is not the standalone time of a single vendor kernel, and end-to-end serving still pays GEMM, GDN, decode, and scheduling costs.

The numerical scope here must be separated: 2.75x-2.92x is standalone kernel comparison, +0.62%/+2.67%/+13.78% is same-container end-to-end A/B, 681.071/238.718 ms is the profile’s total Attention bucket. They cannot substitute for each other, nor can local A/B ratios be directly treated as official absolute throughput on another machine.

9. Numerical Correctness: Fast Does Not Mean Bitwise Identical

vendor BF16 attention and Triton attention compute the same complete causal Attention, but the parallel reduction order may differ. Therefore:

• vendor standalone output is finite and stable across repeated runs;
• page832 Triton and page784 Triton can be bitwise identical;
• relative L2 error between vendor and Triton is about 0.0058-0.0064;
• generated text is not guaranteed to be bitwise identical per request.

This is not a detail that can be ignored. Tiny differences in BF16 reduction may be amplified in long-sequence generation, so one must simultaneously do:

1. kernel output finite check;
2. repeated-run consistency check;
3. relative error comparison with reference kernel;
4. four types of task-level accuracy smoke;
5. record generated text and token count per request.

In this route, Q/K/V are not skipped, the causal range is not shortened, no sparse attention is done, and no cross-request KV reuse is done; the changes are physical page layout and equivalent kernel selection.

10. An Important Failure Case: page832 Once “Seemed Ineffective”

The most valuable finding of this route is not the first 2.9x result, but the later discovery that the test path behind the old conclusion was incomplete.

The old experiment only submitted the attention dispatch change, but did not simultaneously submit the page-layout alignment logic. The official loader disabled prefix caching, and the actual runtime was still page784; because 784 does not satisfy the vendor kernel’s 64-token page requirement, the vendor path did not hit at all.

On the other hand, the old fast-start script enabled prefix caching, and Mamba align raised the page to 1024. The local result was therefore page1024, not the official path’s page832.

Thus a typical contradiction appeared:

1
2

standalone page832 vendor: very fast
old official submission: almost no gain

The correct conclusion is not “standalone is untrustworthy”, nor “official is definitely unsuitable”, but to first check:

1
2
3
4

Does the source code really contain the layout change?
What is the runtime block size?
Does the vendor marker appear?
Did prefix caching change the page?

Only when these conditions align do performance numbers belong to the same path.

11. Reproduction and Acceptance Checklist

If reproducing on another DCU or another vLLM version, it is recommended to follow this order:

11.1 First Confirm Hardware and Software Constraints

1
2
3
4

Confirm gfx936/corresponding DCU target architecture
Confirm wave64-related kernel constraints
Confirm vendor FlashAttention page alignment requirements
Confirm the real model shape of BF16, GQA6, head size 256

11.2 Then Confirm Page Calculation

1
2
3
4

Print prefix caching status
Print final cache block size
Print attention page bytes and Mamba page bytes
Confirm page832 comes from alignment calculation, not a hidden parameter in the script

11.3 Finally Confirm Kernel Hit

1
2
3
4

Print vendor prefill marker
Print page-contiguous decode marker
Check whether it falls back to unified Triton when conditions are not met
Check that block table and K/V stride are consistent with page size

11.4 End-to-End Acceptance

1
2
3
4
5

Same container, same model, same dataset
Sufficient warmup to avoid first-compilation pollution
Three tiers of throughput, failed = 0
Record TTFT, TPOT, output token count, and text
accuracy smoke

12. Conclusion: The Real Optimization Happens at the Boundary Between “Hardware Constraints” and “Framework Semantics”

page832 is not an isolated tuning result; it simultaneously involves:

• wave64 execution granularity of gfx936;
• vendor attention’s requirement for 64-token pages;
• page compatibility calculation of vLLM hybrid Attention/Mamba;
• block table and stride address formulas of paged KV;
• different access geometries of q=4096 prefill and q=1 decode;
• numerical validation issues brought by BF16 reduction order.

If only the kernel is changed without changing page layout, the kernel may not hit at all; if only page size is changed without changing decode access, long-context gains may also be limited; if only microbench is considered without looking at output and official loader, conclusions may also be polluted by wrong paths.

For DCU inference optimization, the most reusable method is:

First translate the hardware’s access granularity into data layout constraints, then connect the layout constraints into the framework’s existing semantic paths, and finally use runtime markers and end-to-end results to prove the kernel actually hits.

This is closer to real kernel engineering than “change a BLOCK_SIZE and see”, and it better explains why a 48-token page difference repeatedly appears in every layer’s attention and multiple physical page accesses of every long request and affects overall serving performance.

This article discusses publicly explainable hardware, layout, and kernel methods; the implementation description does not include internal repository addresses, account information, container credentials, or private infrastructure details. Performance numbers come from fixed-shape same-container experiments; actual results will vary with DCU model, driver, DTK, compilation cache, and runtime load.

When profiling large models on Hygon DCU, the hardest part is usually not whether a trace can be generated, but how to read it after it has been generated.

A local sampling run of Qwen3.5-27B BF16 produced:

1
2
3
4

总事件:       235,964
GPU 事件:      61,804
kernel 事件:   60,124
GPU event 总时长: 5773.493 ms

Sorting directly by total kernel time only shows a long list of Tensile, Triton, Attention, and custom kernel names. It does not proactively tell you:

• which ones belong to Prefill;
• which ones belong to Decode;
• how many times a kernel is called per token;
• whether the call counts can map back to the number of model layers;
• which time bucket is the real bottleneck worth optimizing.

This article does not discuss a new kernel. Instead, using this measured Hygon DCU trace, it demonstrates how to reconstruct the complete inference structure from event context and call counts.

1. First, Limit the Scope of the Profile

This sampling covers only one request with clear boundaries:

1
2
3

3 个 q=4096 Prefill chunk
1 个 q=1685 Prefill tail
60 个 Decode step

This is a very important precondition.

If the profile covers multiple concurrent requests, model loading, first compilation, and long generation, the number of events will expand rapidly, and it will be difficult to attribute a given kernel to a specific phase.

For Hygon DCU large-model services, a more reliable workflow is:

1
2
3
4
5

服务先完成加载和必要 warmup
-> 开启 profiler
-> 只发送一个有代表性的请求
-> 等请求完整结束
-> 立即停止并保存 trace

The goal of profiling is to answer “where is the time spent,” not to reproduce maximum throughput.

2. First Cut: Split Prefill and Decode by Execution Context

Each batch of GPU events in the trace has an upper-level execution context. Using the token count and generation state, they can first be divided into:

Decode average per step:

1
2

2586.460 ms / 60
= 43.108 ms/token

This step is more important than looking directly at the top kernels.

The same GEMM name may appear in both Prefill and Decode, but the M dimension, parallelism, and optimization methods are completely different in the two phases. Only after splitting by context do the later statistics have physical meaning.

3. Second Cut: Identify Model Structure Using Call Counts

3.1 LLMM1 kernel

In the Decode interval, LLMM1 totals:

1
2

10,560 launches
1,408.219 ms

Divided by 60 Decode steps:

1
2

10,560 / 60 = 176 launches/token
1,408.219 / 60 = 23.470 ms/token

176 is not a random number; it maps completely back to the model structure:

1
2
3
4
5
6

64 次 MLP gate/up
48 次 GDN qkvz
48 次 GDN BA
16 次 Full-Attention QKV
-------------------------
176 次/token

When the trace call count and the model layer count fully close, the kernel attribution is basically credible.

3.2 rocBLAS/Tensile GEMV

In the same Decode interval, rocBLAS/Tensile GEMV is:

1
2

7,740 launches
876.431 ms

After conversion:

1
2

7,740 / 60 = 129 launches/token
876.431 / 60 = 14.607 ms/token

129 can likewise be mapped back to modules:

1
2
3
4
5
6

64 次 MLP down projection
48 次 GDN output projection
16 次 Attention output projection
 1 次 lm_head
--------------------------------
129 次/token

This kind of “call-count closure” is very valuable. It not only tells us whether a kernel is hot, but also checks:

• whether some type of Linear was missed in the statistics;
• whether a fusion actually reduced launches;
• whether runtime markers are consistent with the actual call count;
• whether the model structure and the trace come from the same version.

4. Third Cut: Convert Time into a Per-Token Budget

LLMM1 and rocBLAS combined:

1
2

23.470 + 14.607
= 38.078 ms/token

Relative to 43.108 ms/token for Decode:

1
2

38.078 / 43.108
= 88.33%

This shows that in this Hygon DCU trace, the main Decode bottleneck is Linear, not some scattered pointwise kernel.

Other major Decode time includes:

After seeing this ratio, optimization priorities become clear:

• a small fusion that saves only 2-3 us per layer is unlikely to change total TPOT;
• an implementation covering hundreds of Linear calls may accumulate endpoint gains even if each call is only a few percent faster;
• continuing to optimize a bucket that accounts for less than 2% requires first proving a sufficiently large absolute saving.

The role of profiling is not to automatically provide a solution, but to constrain the physical upper bound of the solution.

5. Prefill Cannot Reuse Decode’s Conclusions

The main time items for the three q=4096 Prefill chunks are:

The same model presents different shapes in Prefill and Decode:

1
2
3
4
5

Prefill:
  大 M GEMM + 长序列 Attention

Decode:
  M=1 Linear/GEMV + 状态读取

Therefore, in trace analysis, “Linear accounts for 88.33% of Decode” cannot be understood as a unified share for the entire request, nor can Decode’s M=1 kernels be used to explain q=4096 Prefill.

The correct approach is to establish two separate budgets:

1
2

TTFT 预算 -> Prefill 上下文
TPOT 预算 -> Decode 上下文

6. Why Looking Only at Kernel Rankings Misleads

Suppose the first place in the top kernel list is LLMM1 and the second place is some Tensile kernel.

Without context splitting, you will encounter at least three problems.

6.1 The Same Name May Correspond to Different Shapes

The same library kernel may be reused by multiple Linear modules. You need to combine M, N, K, call count, and parent events to map it to a model layer.

6.2 High Total Time May Just Mean Many Calls

A 130 us kernel called ten thousand times will rank ahead of a 5 ms kernel. When optimizing, look at all of:

1
2
3
4

单次耗时
调用次数
覆盖层数
端点时间占比

6.3 The Profile Itself Is Not an Endpoint Benchmark

The profiler introduces recording, synchronization, and buffering overhead. The 43.108 ms/token in the trace is used to establish the time composition and cannot directly replace the service TPOT without a profiler.

7. A Real Profiler Shutdown Failure

The target request completed normally, and the trace file was successfully written; but after stop_profile was called, the ROCm runtime triggered a VMFault, and EngineCore subsequently exited.

Therefore, this run was handled as follows:

1
2
3
4
5
6
7
8

已写出的 trace:
  作为诊断证据保留

profiled request 的吞吐和 TPOT:
  不作为端点性能证据

发生故障后的服务:
  不继续复用做 benchmark

This boundary is very important.

“A service crash when stopping the profiler” does not mean that all previously written events are invalid; but it does mean that the profiler lifecycle has changed the service state, and the same process cannot continue to be used for performance A/B.

When collecting long traces on Hygon DCU, it is recommended to treat the profiler service as a one-time diagnostic instance.

8. A Reusable Hygon DCU Trace Analysis Workflow

Step 1: Fix the Request

Choose a single request that can cover the target Prefill shape and enough Decode steps.

Step 2: Record the Coverage Scope

Explicitly write down:

1
2
3
4

Prefill chunk 数量与 token 数
Decode step 数量
是否包含首次编译
是否包含模型加载

Step 3: Bucket by Context

At minimum, divide into:

• large Prefill;
• tail Prefill;
• Decode;
• sampling and copies outside the execute context.

Step 4: Count Kernel Calls and Total Time

Do not keep only the top-N times; also keep the count and average time.

Step 5: Divide by Decode Steps

Convert the total call count and total time into:

1
2

launches/token
ms/token

Step 6: Map Back to Model Layers

Check whether the call count can be fully summed from the MLP, GDN, Attention, and lm_head layer counts.

Step 7: Calculate the Physical Upper Bound

Estimate for candidate optimizations:

1
2
3

maximum endpoint saving
= current bucket time
  × removable fraction

Step 8: Start a Clean Service for A/B

Profiling is responsible for locating; the endpoint in the same environment without a profiler is responsible for confirming real throughput, TTFT, TPOT, and output consistency.

9. What This Means for Hygon DCU Developers

This trace proves that in the gfx936 local software stack, the PyTorch/ROCm-compatible trace path can simultaneously observe:

• Tensile GEMM;
• custom HIP kernels;
• Triton kernels;
• CUDAGraph replay;
• Attention and GDN paths;
• Prefill and Decode contexts.

But the data volume is large. What is truly useful is not generating a trace file, but compressing 60,124 kernel events into a verifiable model structure:

1
2
3
4

176 次 LLMM1/token
129 次 rocBLAS GEMV/token
38.078 ms Linear/token
88.33% Decode 占比

Only when the call count, layer count, and time all close does the profile turn from a “pretty timeline” into engineering evidence that can guide Hygon DCU optimization.

10. Conclusion

From 235,964 trace events, the local reconstruction yielded:

• three q=4096 Prefill chunks;
• one q=1685 tail;
• 60 Decode steps;
• 176 LLMM1 calls per token;
• 129 rocBLAS GEMV calls per token;
• Linear totaling 38.078 ms/token;
• Linear accounting for 88.33% of Decode.

The core of this article is not a kernel ranking, but a Hygon DCU profiling method:

First split phases by execution context, then reconstruct the model structure using call counts, and finally convert total time into a per-token physical budget.

Profiling is used to decide where it is worth doing work; endpoint A/B is used to decide whether the work is actually effective. The two kinds of evidence cannot be mixed.

The data in this article comes from a local gfx936 diagnostic trace with a clear coverage scope. Profiler execution has additional overhead; the profile times in this article are only used for operator attribution and budget analysis and do not represent the final throughput of a service without a profiler.

That time, compilation ended normally, the service could start, the endpoint could return results, and the performance test even produced a change that looked explainable. Only after rechecking the runtime environment did I discover a more troublesome problem: the source code, build artifacts, and the files actually loaded by the service were not in the same state. All previous judgments about performance had to be discarded.

This changed my debugging order. Now every time I finish modifying a ROCm kernel, I do not immediately look at throughput; instead, I first answer a more basic question:

Is what is actually executing on the Hygon DCU really the code I just modified, compiled, and was about to test?

This article records a set of vLLM incremental compilation and runtime verification methods that I have actually used on a Hygon DCU with the gfx936 architecture. The focus is not introducing some faster operator, but rather opening up one by one the links between .cu source and real kernel dispatch where stale state can easily hide.

Experimental Environment

The measured environment involved in this article is as follows. The timings and binary information later are only valid for this environment and should not be extrapolated as fixed results for other DCU, DTK, or vLLM versions.

In this vLLM source tree, _rocm_C consists of three files:

1
2
3

csrc/rocm/torch_bindings.cpp
csrc/rocm/skinny_gemms.cu
csrc/rocm/attention.cu

skinny_gemms.cu and attention.cu first go through hipify, then DTK’s compiler generates target code for gfx936, and finally they are linked together with the operator registration code into _rocm_C.abi3.so.

A kernel has at least six “identities” before it runs

Looking only at the source directory, it is easy to mistakenly think that a modification has already taken effect. The actual chain is much longer:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

skinny_gemms.cu
        |
        | hipify
        v
skinny_gemms.hip
        |
        | clang++ --offload-arch=gfx936
        v
cmake-build-rocm/_rocm_C.abi3.so
        |
        | cmake --install / manual install
        v
vllm/_rocm_C.abi3.so in the Python environment
        |
        | loaded by the service process
        v
loaded shared library in /proc/<pid>/maps
        |
        | runtime conditions such as shape, dtype, layout
        v
kernel branch actually selected for this request

If any layer here is not aligned, a very dangerous state appears: the program runs, but it is not running the implementation you think it is.

Therefore, “compilation succeeded” can at most prove that the third layer generated a file. It cannot prove that the file was installed into the current Python environment, still less that the already-started vLLM process reloaded it, and finally it cannot prove that the target request actually hit the new dispatch.

The incremental compilation I actually got working

Given an existing build directory, after modifying csrc/rocm/skinny_gemms.cu, I use the following two commands:

1
2

cmake --build --preset rocm-release --target _rocm_C
cmake --install cmake-build-rocm --component _rocm_C

In this environment there is a not-so-obvious difference: when only CMakeUserPresets.json was placed, the current image’s build process did not recognize it correctly; it worked stably only after switching to the actually used CMakePresets.json. The preset must at least specify the following information:

1
2
3
4

VLLM_TARGET_DEVICE=rocm
PYTORCH_ROCM_ARCH=gfx936
ROCM_PATH=/opt/dtk
CMAKE_HIP_COMPILER_LAUNCHER=ccache

A real incremental build log can be compressed into the following lines:

1
2
3
4
5
6
7
8
9

[1/4] ... hipify.py ... skinny_gemms.cu attention.cu
skinny_gemms.cu -> skinny_gemms.hip [ok]
attention.cu -> attention.hip [skipped, already hipified]
Successfully preprocessed all matching files.
Total number of unsupported CUDA function calls: 0
Total number of replaced kernel launches: 19

[2/3] clang++ ... --offload-arch=gfx936 ... skinny_gemms.hip
[3/3] ... -o _rocm_C.abi3.so

These lines are more useful than the final build success. They simultaneously prove four things:

1. The modified .cu was re-hipified;
2. The unmodified attention.cu was not pointlessly re-converted;
3. The compilation command really targeted gfx936;
4. A shared library relink actually occurred.

The same local experiment also recorded the state of the generated extension:

1
2
3
4

size: 21018624 bytes
sha256: 0e3280734c80bf7d33e101c04eecd9cdee0844feb3447b2141a3326ad6ef7549
torch: 2.10.0
LLMM1_registered: True

This hash is only used to identify that particular binary at that time and does not mean that other correct builds should produce the same hash.

A shared directory can slow down the configuration phase

I also compared the CMake configure time for the same source tree in two locations:

The difference is about 8.2x. This result does not mean that /root will be 8.2x faster on any machine; it means that when the source tree, CMake probes, and a large number of small-file operations all land on high-latency shared storage, the configuration phase itself can become an iteration bottleneck.

My approach is to put the temporary source overlay and cmake-build-rocm on the container-local disk, and after compilation only copy the logs, source patches, and final .so that need to be preserved back to the persistent directory. This keeps the evidence while avoiding repeated metadata access on the shared directory for every configure.

Four “looks successful” failure states

I have encountered all four of the following situations in actual debugging. They are troublesome because the service does not necessarily report an error.

1. import vllm succeeds, but the ROCm extension does not exist

After reinstalling a wheel once, the Python package was restored and import vllm worked normally, but the default installation did not contain _rocm_C.abi3.so. If you verify the environment only with import vllm, you will mistake “the Python package exists” for “the custom ROCm extension is installed”.

A more reliable check is to import the extension directly and confirm that the target operator has been registered:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

python3 - <<'PY'
import importlib.util
import os
import torch

spec = importlib.util.find_spec("vllm._rocm_C")
print("extension:", None if spec is None else spec.origin)
if spec is None:
    raise SystemExit("vllm._rocm_C is missing")

import vllm._rocm_C  # noqa: F401
op_name = os.environ.get("DCU_VERIFY_OP", "LLMM1")
print("registered:", op_name, hasattr(torch.ops._rocm_C, op_name))
PY

Here LLMM1 is the operator name I was verifying at the time. When switching to another project, set DCU_VERIFY_OP to the registration name you actually need to test.

2. After reinstalling the wheel, only one currently modified file was copied

In another round of experiments, reinstalling the wheel restored site-packages to the wheel’s default state. At that time I copied only the Python file I was currently modifying, but missed other modified files inherited by the candidate implementation. The service could still start and the benchmark could complete, but that was not the complete candidate, and the results had no comparative value.

Since then, I no longer decide the synchronization scope by “how many files I manually changed this time”; instead, I decide it by the complete source diff:

1

git diff --name-only <baseline>...HEAD

All differing files that can affect runtime must be installed, hashed, and included in the backup and restore list. For Python files, python -m py_compile should also be run before starting the service, to avoid leaving transport corruption, encoding anomalies, or incomplete files to be discovered only at the model-loading stage tens of minutes later.

3. The .so on disk is updated, but the old process is still using the original mapping

Overwriting _rocm_C.abi3.so will not cause an already-running Python process to automatically unload the old shared library. After replacing the binary, the service must be fully restarted; if CUDAGraph is used, graph capture should also be redone, and the graph state from the old process must not be reused.

I once encountered a more insidious situation: after the previous service exited, a VLLM::EngineCore process was still alive and occupying GPU memory. Although the next service started, the environment was no longer clean.

Before starting a new service, I now perform at least two read-only checks:

1
2

ps -eo pid,ppid,cmd | grep -E 'vllm|VLLM::EngineCore' | grep -v grep
ss -ltnp | grep ':8000 '

Confirm that the old service, EngineCore, benchmark driver, and listening port have all been cleaned up, then restart through the normal service management method. After startup, you can also inspect the mappings of the target process:

1
2

PID=$(pgrep -n -f 'VLLM::EngineCore')
grep '_rocm_C.abi3.so' "/proc/${PID}/maps"

It can at least answer “from which path did the current process load the extension”. If the path is not as expected, there is no need to continue analyzing the subsequent performance data.

4. Same filename, but different binary origin

Once, while cleaning up the environment, I recorded that the hash prefix of _rocm_C in the runtime environment was:

1

7aee47576aa8...

while the hash prefix of the known extension prepared as a control was:

1

f2c5393af460...

Both files are named _rocm_C.abi3.so, and the target operators can run in both, but they are not the same binary. Without a hash record, this difference is easily masked by the filename.

I now record the hashes of both the build directory and the actual installation location:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

BUILD_SO=cmake-build-rocm/_rocm_C.abi3.so
INSTALLED_SO=$(python3 - <<'PY'
import importlib.util
spec = importlib.util.find_spec("vllm._rocm_C")
if spec is None:
    raise SystemExit(1)
print(spec.origin)
PY
)

sha256sum "$BUILD_SO" "$INSTALLED_SO"
cmp -s "$BUILD_SO" "$INSTALLED_SO" \
  && echo "binary match" \
  || echo "binary mismatch"

Hash alone is not enough: you must prove that the request hit the new dispatch

Consistent hashes only prove that the service loaded the target extension; they do not prove that a request selected the new kernel. Dispatch in vLLM is often affected simultaneously by shape, dtype, layout, sequence phase, and cache configuration. If even one condition is missed, the program may silently fall back to the original path.

My approach is to keep a diagnostic marker controlled by an environment variable in the candidate branch, printing only on the line where the candidate kernel is actually selected:

1
2
3
4
5
6
7

if os.getenv("VLLM_DCU_KERNEL_DIAG") == "1":
    logger.warning(
        "DCU_KERNEL_DIAG selected=%s shape=%s dtype=%s",
        selected,
        tuple(x.shape),
        x.dtype,
    )

The key to the marker is not “the feature is enabled”; rather, selected=True must come from the actual dispatch result. My automated runner extracts the marker from the service log and treats “expected shape appears, key parameters are correct, selected=True” as a precondition for a valid benchmark.

This is especially important for ROCm kernels on Hygon DCU. The fallback in many experiments is still a usable and reasonably fast vendor or Triton path, so “the service did not report an error” absolutely cannot prove that the new kernel was executed.

The seven verification gates I now use

The following table is the check order I finally settled on. If the previous item does not pass, do not proceed to the next.

This process looks like a few more steps than “compile and then run the benchmark directly”, but most checks take only seconds. What really takes time is skipping them and then spending hours analyzing a set of data that actually came from an old binary, half the source tree, or a fallback path.

A read-only verification script

The following is a compressed version of the common checks I use. It does not modify files and does not stop processes; it is suitable for running once before and once after service startup. The operator name can be replaced through an environment variable.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

#!/usr/bin/env bash
set -euo pipefail

export DCU_VERIFY_OP="${DCU_VERIFY_OP:-LLMM1}"

python3 - <<'PY'
import importlib.util
import os
import torch
import vllm

print("vllm:", vllm.__file__)
spec = importlib.util.find_spec("vllm._rocm_C")
print("_rocm_C:", None if spec is None else spec.origin)
if spec is None:
    raise SystemExit("missing vllm._rocm_C")

import vllm._rocm_C  # noqa: F401
name = os.environ["DCU_VERIFY_OP"]
ok = hasattr(torch.ops._rocm_C, name)
print("op:", name, "registered=", ok)
if not ok:
    raise SystemExit("target op is not registered")
PY

SO=$(python3 - <<'PY'
import importlib.util
print(importlib.util.find_spec("vllm._rocm_C").origin)
PY
)

ls -l "$SO"
sha256sum "$SO"

echo "--- active vLLM processes ---"
ps -eo pid,ppid,cmd | grep -E 'vllm|VLLM::EngineCore' | grep -v grep || true

If the .so in the build directory, the .so actually imported by Python, the .so in the process mapping, and the dispatch marker can form a closed chain of evidence, only then will I write the subsequent results into the experimental conclusion.

The boundaries of this method

There are three points that need to be made clear in this article:

1. 111 seconds -> 13.5 seconds is an observation under specific container and shared-storage conditions, not a fixed performance metric for Hygon DCU;
2. 21018624 bytes and the SHA256 in this article belong to one specific build and are only used to illustrate how to record binary identity;
3. This process proves “the test object is correct”; it does not automatically prove that the kernel is faster or numerically correct. Performance and correctness still need separate verification.

However, for me, this step has already become the engineering habit most worth keeping in Hygon DCU kernel development. HIPify, the DTK compiler, the CMake build tree, the Python installation directory, the long-running vLLM process, and runtime dispatch—each layer may retain stale state. Verifying them layer by layer is far more reliable than staring at the final line build success.

Now after I finish modifying a kernel, my first reaction is no longer to see how much the number has increased, but to first confirm: is the source correct, is the binary correct, is the process correct, and did this request actually reach it? The extra cost is only a few minutes, and what is often saved is an entire round of erroneous experiments.

What is most worth recording about THU-BDC2026 is not some return that looks beautiful once, but those experiments that pulled the model back from “looks effective” to “actually verifiable”.

This is my experiment log. It does not seek to package the project as smooth sailing; instead, it specifically writes down several optimizations that made the results worse and worse, because the experience that can truly remain in a competition is often hidden in these failures.

Why Write It as a Log

At the beginning, this project could easily get people carried away: complex models, rich metrics, and some backtest results that looked very strong.

But what quantitative projects fear most is “abnormally pretty”. As long as there is a little future information in the training set split, label construction, or feature window, the model will become stronger as if it suddenly got it. The problem is that this kind of strength is not real strength; it just saw the answer in advance.

So the focus of this article is not “how powerful a model I built”, but recording how I squeezed out the fluff step by step:

• First, acknowledge that single-period results cannot be conclusions;
• Then fix the time isolation between training and prediction;
• Next, delete features that may depend on leakage;
• Finally, see which factors can still retain real gains.

Early Single-Period Backtest: Very Bright, but Not to Be Trusted Too Much

There is an early backtest report in the archive; it only tested the 5 trading days from 2026-03-09 to 2026-03-13.

At the time, the results looked very good:

If you only look at this table, it is easy to feel that the direction is already right. But 5 trading days is too short, and luck plays a big role. It is more like a hint: “There may be something here, worth investigating further,” but it cannot prove that the model is stably effective.

Looking back later, the greatest value of this stage was not the return, but the reminder that I had to lengthen the validation period and make the backtesting process stricter.

Fixing Data Leakage: The Most Painful, but the Most Worthwhile

What truly changed the direction of the project was fixing data leakage.

The original backtest only ensured that training sample dates were earlier than the backtest date, but the labels used the opening prices of the next 5 days. That is, for training samples close to the backtest date, although the dates were in the past, the labels might already extend into the future window.

This type of leakage is very hidden. The code looks fine, and the results look very good, but in essence the model has already peeked at the answer.

After the fix, the results immediately became ugly:

1
2
3
4

Sharpe:        -0.49
Cumulative portfolio:     -17.11%
Win rate vs. equal-weight: 44.8%
Max drawdown:     -31.17%

This step was very discouraging, but it was the most important step in the entire experiment line. Because from here on, the later results are worth discussing.

Subtraction: Cutting Volatility Features

After fixing the leakage, I began to suspect a batch of volatility-related features.

For example:

• boll_width
• atr_pct
• vol_20d
• Aggregate features and cross-sectional rank features derived from these indicators

They had very high importance in the old version, but the old version itself had leakage. So I was not sure whether they were truly effective or just helped the model memorize shortcuts in the wrong validation.

So I ran a deletion experiment:

1
2
3
4

Feature dimension: 289 -> 227
Sharpe:     -0.49 -> 0.40
Cumulative return: -17.11% -> 4.39%
Win rate:     44.8% -> 51.7%

This time the results actually got better. The reminder it gave me was very direct: more features are not safer. Especially in financial data, some features seem to have a lot of information, but in fact they just amplify noise and wrong validation together.

Money Flow: One of the Few Things That Truly Brought Gains

Later I added Tushare money-flow-related factors, mainly including three categories:

• Main-force net inflow rate;
• Small-order net inflow rate;
• Super-large-order share.

This version is a relatively decent one in the current experiment log:

1
2
3
4
5

Sharpe:         0.70
Cumulative portfolio:     12.33%
Annualized return:     29.90%
Win rate vs. equal-weight: 51.7%
Max drawdown:     -25.13%

More importantly, 主力净流入率_ma20_cs_rank entered the top 20 feature importances.

This made me feel that capital behavior signals may be more valuable than simply stacking price patterns. Price patterns easily overfit; money flow at least provided another type of information in this window.

Three Failed Optimizations

Top-80 Feature Selection

I used data before 2023 to select the 80 most important features, wanting to reduce noise and speed up training.

Training speed did indeed become faster:

1
2

Training time: 116 minutes -> 50 minutes
Speed improvement: about 57%

But the results got worse:

1
2

Cumulative return: +12.33% -> -7.47%
Sharpe:     0.70 -> -0.07

This shows that importance in a historical window does not necessarily transfer to the future. Financial data is not a static dataset; once the market regime changes, the features that were most important in the past may instead hold it back.

Three-Class Labels

I also tried roughly dividing stocks into three tiers:

• Top 30%;
• Middle 40%;
• Bottom 30%.

The intention was to make the model focus more on the “buy zone” and the “risk-avoidance zone”, but the actual effect was very poor, and the Sharpe fell to -1.08.

The reason is probably that a ranking task cannot be cut too coarsely. Although 10-bin labels are a bit more complex, they retain more relative order information and are more suitable for selecting the Top 5 from 300 stocks every day.

Industry Coverage Fix

There was also a very counterintuitive failure: the industry coverage fix.

Originally industry coverage was only 4.7%, which was certainly unreasonable, so I filled the industry information to 100%. From the perspective of data completeness, this step was absolutely correct.

But model performance dropped from a Sharpe of 0.70 to 0.18, and sector_id became the most important feature.

This shows that the model may not have “learned the industry” but rather “trusted the industry too much”. Industry information needs finer constraints, such as downweighting, regularization, and grouped validation; it cannot just be stuffed in all at once.

Rules Left in the End

After this round of experiments, I left myself a few rules:

1. Single-period results can only be clues, not conclusions.
2. The first step of backtesting is always to check for data leakage.
3. Feature importance should be viewed by time period; one historical window cannot be treated as truth.
4. Subtraction is not shameful; being able to remove noise is also a skill.
5. More complete data also needs to be used correctly by the model.
6. All changes that “look reasonable” must ultimately let the backtest speak.

What to Do Next

If I continue advancing this project, I will prioritize three things:

• Lengthen the rolling backtest period and stop being led by single-week returns;
• Perform grouped validation on strongly structural features such as industry, market cap, and liquidity;
• Keep LightGBM LambdaRank as the main line, and treat deep models as auxiliary experiments rather than the main battlefield.

This record does not constitute any investment advice. It is more like a competition experiment memo: break open the good-looking results, keep the ugly-looking results, and only what remains in the end may be real experience.

The previous post was more like a competition retrospective; this one is specifically to sort out the technical route for THU-BDC2026.

For this project, from the earliest deep model to the later LightGBM LambdaRank, the transition was not simply “switching models”; rather, my understanding of the problem changed: the stock ranking task is not just about predicting returns, but more like making cross-sectional comparisons among 300 stocks on the same day.

So afterward I focused more and more on three things:

• the daily cross-sectional ranking;
• the temporal separation between training and prediction;
• whether the features can truly carry across different years.

Phase One: Transformer + Cross-Sectional Modeling

The earliest design was StockTransformer.

The input used data from the past 30 trading days; each stock had 72 technical indicators, organized overall as:

1

[batch, 300只股票, 30天, 72特征]

The model had several key modules:

• TransformerEncoder: processes the time series of a single stock;
• FeatureAttention: aggregates time-series information at different scales;
• CrossStockAttention: lets stocks on the same day “see” each other;
• MoE Ranking: uses multiple expert heads for ranking scores;
• Score Head: outputs the final score for each stock.

The advantage of this design was strong expressiveness, and it also aligned with the intuition that stocks have relative relationships. The drawbacks were also obvious: slow training, high tuning cost, inconvenient backtest iteration, and the validation method was slightly problematic; complex models amplify the problem.

Phase Two: Turning to LambdaRank

Later I switched the main iteration to LightGBM’s lambdarank.

The reasons were practical:

First, the competition objective is essentially Top 5 ranking, and it is not necessarily about predicting an absolute return. Treating the 300 stocks each day as a group and directly optimizing NDCG@3 / NDCG@5 with a ranking objective is closer to the task.

Second, LightGBM trains much faster. A rolling backtest still takes a long time, but it is more suitable for repeated trial and error than a deep model.

Third, the feature importance of tree models is easier to inspect. It does not necessarily represent causality, but at least it lets me discover whether the model is being skewed by some weird type of feature.

Labels and Grouping

The label definition is:

1

(T+5 开盘价 - T+1 开盘价) / T+1 开盘价

That is, the model predicts the stage return from T+1 to T+5. To make different trading days comparable, I process cross-sectionally by date, then treat the stocks on the same day as one ranking group.

This is where problems most easily occur.

If the backtest date is bt_date, the training set cannot just be written as:

1

processed['日期'] < bt_date

Because for samples close to bt_date, their label may already use future opening prices. Later I changed it to leave at least a gap, to avoid the training set peeking at information near the prediction.

This step is more important than changing any model.

Feature Engineering

The features used in this project roughly fall into several categories:

Later I became increasingly fond of “cross-sectional ranking”. Because in stock competitions, absolute values are often not that stable, but who is stronger or weaker on the same day is closer to the task itself.

Several Key Versions

These values are staged backtest results, not official rankings, and not investment advice.

The Most Counterintuitive Parts

Several conclusions in this project are quite counterintuitive.

First, cutting features improves performance. Volatility features were conspicuous when there was data leakage; after the fix, they instead dragged the model down. It reminded me: feature importance is not an eternal truth; it depends on the validation method.

Second, feature selection worsens performance. The Top-80 version trained much faster, but its cross-year performance was poor. In financial data, what was important in the past does not necessarily remain important in the future.

Third, fixing industry coverage also worsens performance. Industry data was fixed from 4.7% to 100%; by rights the metadata was cleaner, but the model weighted sector_id too heavily, and the result declined instead.

All three results point to one thing: quantitative models cannot be accepted based on intuition; they must be accepted through strict backtesting.

The Route I Now Prefer

If I were to do it again, I would not start by stacking very complex deep structures.

I would first use LightGBM LambdaRank to build a clean, fast, interpretable baseline, and make the following solid:

• date grouping and label isolation;
• rolling backtest;
• robustness check after removing the best month;
• feature importance drift;
• ablation of a single change;
• weight constraints on prediction results.

After these are stable, then consider bringing the deep model back for ensembling.

This project ultimately made me believe more: the truly advanced part in a competition is not how impressive the model name sounds, but whether you can prove your results are not accidental, not peeking at the future, and not fooled by some weird feature.

For this THU-BDC2026, I actually kept three project directories: the original, archive, and v2. They look like three projects, but after going through them, a more accurate description is: this is the three-stage growth history of the same competition project.

The problem itself is very direct: based on the historical market data of CSI 300 constituent stocks, rank the stocks, select the Top 5 to form a portfolio, and then assign weights to them. Put plainly, it asks the model to answer a very practical question: over the next period, which stocks deserve to be ranked higher?

At first I was very excited, because this problem naturally lends itself to writing something very “advanced”: Transformer, CrossStockAttention, MoE, cross-sectional standardization, Top 5 softmax weights. Stacking up the keywords looked beautiful, and the code really did run.

But later I found that the scariest thing in finance competitions is not that the model is not complex enough, but that the model looks too right.

First Version: Looked Impressive

The earliest approach was the deep model route.

I used the past 30 trading days as the time window, calculated 72 technical indicators for each stock, and then constructed a four-dimensional tensor:

1

[batch, 股票数, 30天, 特征数]

The model structure was roughly:

• StockTransformer to model time series;
• CrossStockAttention to model relationships between different stocks on the same day;
• MoE Ranking to increase model capacity;
• Finally output a ranking score for each stock and take the Top 5.

From an engineering perspective, this solution was quite complete, and even had a bit of a “competition flavor.” But in quant, you cannot just look at whether the structure is pretty; the core is still whether the backtest can withstand scrutiny.

The Bug That Calmed Me Down

Later I found a very serious problem in the backtest code: training data filtering only used data before the prediction date.

The original logic was similar to this:

1

train_proc = processed[processed['日期'] < bt_date].copy()

The problem is that the labels were calculated using the opening prices of the next 5 days. That is, although the samples from the few days before the prediction date had dates earlier than the prediction date, their labels might already contain future price information around the prediction date.

After the fix, I separated the training samples from the prediction date:

1
2
3
4

train_proc = processed[
    (processed['日期'] < bt_date) &
    (processed['日期'] + pd.Timedelta(days=10) < bt_date)
].copy()

After this cut, the results were very ugly.

The worst part was not the loss, but that I had to admit: that beautiful result from before was not trustworthy.

Starting Over with a More Honest Version

After fixing the data leakage, I did not continue piling things onto the model. Instead, I first did subtraction.

I found that some volatility-related features were especially “useful” when leakage existed, but after the fix they acted more like noise sources. So I removed vol_5d, vol_10d, vol_20d, boll_pctb, boll_width, and atr_pct.

The feature dimension dropped from 289 to 227, and the backtest actually got better:

This step gave me a big reminder: more features is not always better. Some features look especially smart under the wrong validation method, but once validation becomes clean, they expose themselves.

Tushare-Enhanced Version: A More Decent One

Later I added Tushare’s capital flow factors and Shenwan industry classification, mainly including:

• Main force net inflow rate;
• Small order net inflow rate;
• Extra-large order proportion;
• Industry and market cap related features.

This version had the best staged backtest performance:

Among them, 主力净流入率_ma20_cs_rank entered the Top 20 feature importance, which shows that capital flow factors really did provide some extra information.

But I also do not want to write this as “finally succeeded.” Because the backtest window was only a rolling test from 2024 to 2026, and after removing the best months, return stability clearly weakens. It is a staged better version, not a god model that can be bragged about for a lifetime.

The Attempts That Didn’t Improve

There were several interesting failures later in this project.

I tried Top-80 feature selection. Training time did drop from 116 minutes to 50 minutes, but Sharpe fell from 0.70 to -0.07. The reason is probably that important features from before 2023 do not necessarily transfer to 2024-2026.

I also tried three-class labels, splitting stocks into “top 30% / middle 40% / bottom 30%.” The result was even worse, with Sharpe falling to -1.08. Later I thought it made sense: a stock ranking task needs to retain as much relative order information as possible, and crude three-class classification erases the middle information instead.

Another time I fixed industry coverage from 4.7% to 100%. It sounds like it must be right, but the backtest fell from 0.70 to 0.18. This result is very counterintuitive, and also quite real: more complete data does not mean the model is necessarily better. If the model relies too heavily on industry features, fixing metadata may also lead it astray.

Biggest Takeaway

The biggest lesson this competition gave me was not some model structure, nor some metric, but four words: don’t fool yourself.

In financial machine learning, the most dangerous thing is “looks reasonable.” Code runs, curves look good, metrics are high—none of these automatically prove that the model really has predictive power.

What really matters is:

• Whether labels peeked at the future;
• Whether the training set and prediction date were isolated;
• Whether the backtest window is too short;
• Whether the best month propped up all the returns;
• Whether feature importance is just an illusion from a certain period;
• Whether an improvement was just a coincidence.

This article only records the competition and backtest retrospective, and does not constitute any investment advice.

If I do similar projects in the future, I will put backtest hygiene, data leakage checks, and rolling validation first. Models can become complex gradually, but once the validation method is wrong, all subsequent efforts will be led into a ditch.

The most valuable part of this time may be that I really fell into it once, and then recorded it.