IMPORTANT: To view this page as Markdown, append `.md` to the URL (e.g. /get-started.md). For the complete documentation index, see llms.txt.
Skip to main content
For the complete documentation index, see llms.txt. Markdown versions of all pages are available by appending .md to any URL (e.g. /get-started.md).

Mojo function

kpool_ring_close_kernel

def kpool_ring_close_kernel[dtype: DType, OutLayoutType: TensorLayout, out_origin: MutOrigin, ClosedLayoutType: TensorLayout, closed_origin: MutOrigin, TailLayoutType: TensorLayout, tail_origin: ImmOrigin, KLayoutType: TensorLayout, k_origin: ImmOrigin, GateLayoutType: TensorLayout, gate_origin: ImmOrigin, ApeLayoutType: TensorLayout, ape_origin: ImmOrigin, IROLayoutType: TensorLayout, iro_origin: ImmOrigin, CacheLenLayoutType: TensorLayout, SlotLayoutType: TensorLayout, slot_origin: ImmOrigin, OutEngine: TensorEngine, ClosedEngine: TensorEngine, TailEngine: TensorEngine, KEngine: TensorEngine, GateEngine: TensorEngine, ApeEngine: TensorEngine, IROEngine: TensorEngine, CacheLenEngine: TensorEngine, SlotEngine: TensorEngine, head_dim: Int, kpool: Int](pooled: TileTensor[dtype, OutLayoutType, out_origin, Engine=OutEngine], closed_pool: TileTensor[.int32, ClosedLayoutType, closed_origin, Engine=ClosedEngine], tail: TileTensor[dtype, TailLayoutType, tail_origin, Engine=TailEngine], k: TileTensor[dtype, KLayoutType, k_origin, Engine=KEngine], gate: TileTensor[dtype, GateLayoutType, gate_origin, Engine=GateEngine], ape: TileTensor[.float32, ApeLayoutType, ape_origin, Engine=ApeEngine], input_row_offsets: TileTensor[.uint32, IROLayoutType, iro_origin, Engine=IROEngine], cache_lengths: TileTensor[.uint32, CacheLenLayoutType, ImmutAnyOrigin, Engine=CacheLenEngine], slot_idx: TileTensor[.uint32, SlotLayoutType, slot_origin, Engine=SlotEngine], num_requests: Int32)

Closes each request's pending tail-ring pool, ragged and unconditional.

A cached prefix ending mid-pool leaves that pool's earlier members in tail (see kpool_seed_tail_kernel), and neither kpool_compress_kernel nor kpool_seed_tail_kernel reads them back -- kpool_compress_kernel only ever builds pools entirely from this call's own tokens, skipping the leading remainder the ring already holds. This kernel is the one that reads that remainder, so a request whose new tokens complete it is not stuck forever.

Unlike kpool_tail_update_kernel, this takes a ragged, arbitrary-width chunk per request (input_row_offsets, not a compile-time next_n), and closes at most one pool per request per call -- the ring never holds more than kpool - 1 members between calls, so there is never a second one to close. Any further pools this call completes are entirely new tokens and belong to kpool_compress_kernel, which already derives its own pool count and starting row by skipping exactly the tokens this kernel consumes (align below, computed the same way in both).

Parameters:

Args:

Was this page helpful?