vllm.models.kimi_k3.nvidia.specialized_decode.runtime.prefetch
¶
L2 weight prefetch for the specialized decode.
Small-batch decode is bound by HBM bandwidth, and each kernel that starts on weights
not yet in L2 stalls on DRAM. Some kernels leave bandwidth idle, such as the attention
core and the all-reduces. At fixed points of each layer, this module launches a small
kernel (cutedsl/common/prefetch.py) on a side stream. It pulls the byte ranges of
the weights the next kernels read into L2, so that they start warm.
Prefetch points (fork(point, layer, batch)), each with its batches per TP:
oproj_down: after the o-projection (B3-8), the MoE front's packed router + latent-down rows.attention_moe: at TP8 only, after the KDA input projection (B5-8) or the MLA core (B8), this layer's o-projection, the same front rows, the shared expert's weights and this rank's shard of the latent up projection (the MoE tail's weights, which otherwise stream from HBM on the critical path beside the next-attention prefetch). GB300 TP8 K3.1 DSpark k=4 R1 (B5) 32K step, ms: front + shared 10.28,- up projection 10.03, + o-projection 9.89.
next_attention: once the routed experts are launched, the next layer's attention weights, capped in MiB per batch (NEXT_ATTENTION). Not above B8, where the HBM-bound experts lose more bandwidth than the attention gains.
At the EXPERTS_AHEAD batches the next layer's attention weights are not a side
stream launch: the routed experts' producers prefetch them (ahead), each CTA its
share, once its last weight stage is issued. The experts' drain (FC2 hand-off,
finalize) leaves HBM idle for ~10 us, and no extra CTAs hold SMs the WaveMoeTail
clusters need when the experts exit.
The front and shared-expert ranges are on the critical path. They launch with the highest stream priority and the maximum shared-memory carveout, which needs a driver launch because CuTe drops both attributes.
Each fork records an event on the main stream that the side stream waits on, so a
prefetch starts only after the work it overlaps. join() at the end of the step
makes the main stream wait for the side stream, so a captured graph always rejoins
it. This lives in runtime/ rather than cutedsl/ because it is host-side
orchestration across layers: a stream, events, and per-(point, layer, batch) tables
built from the model's layers.
Classes:
-
PrefetchController–Prefetch launches per (point, layer, batch) on one side stream.
-
PreparedWeightRanges–One owner retains weights, immutable range table, executable and launch ABI.
Functions:
-
attention_weights–Next-attention weights in their consumption order.
-
weight_ranges–(address, bytes) of each weight's span in order, the total capped at
PrefetchController
¶
Prefetch launches per (point, layer, batch) on one side stream.
Methods:
-
ahead–The [PREFETCH_ROWS, 2] (address, bytes) table of the next layer's attention
Source code in vllm/models/kimi_k3/nvidia/specialized_decode/runtime/prefetch.py
155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 | |
ahead(layer, batch)
¶
The [PREFETCH_ROWS, 2] (address, bytes) table of the next layer's attention
weights the routed experts of (layer, batch) prefetch in-kernel, or None
(EXPERTS_AHEAD).
Source code in vllm/models/kimi_k3/nvidia/specialized_decode/runtime/prefetch.py
PreparedWeightRanges
¶
One owner retains weights, immutable range table, executable and launch ABI.
Source code in vllm/models/kimi_k3/nvidia/specialized_decode/runtime/prefetch.py
attention_weights(attention)
¶
Next-attention weights in their consumption order.
Source code in vllm/models/kimi_k3/nvidia/specialized_decode/runtime/prefetch.py
weight_ranges(weights, byte_cap=0)
¶
(address, bytes) of each weight's span in order, the total capped at
byte_cap bytes (0: uncapped).