nx_batch_scheduler.nx

nx_batch_scheduler.nx -- H2 continuous batching (bits-up). Per NISHI_ELDER_AI_OFF_DOCKER_2026_05_20.md §2.1 H2: pack pending requests at TOKEN level not request level so the GPU stays saturated. vLLM + TGI ship this pattern at scale (~10x throughput over naive request-by-request scheduling). V1 mechanics: N-slot fixed scheduler. Each slot holds at most one active request (sequence_id + tokens_remaining + state). admit() places a request in a free slot OR queues it. step() reports the slots currently in RUNNING state -- those are the active batch for the next forward pass. complete() marks a slot DONE. recycle() reclaims DONE slots and drains the pending queue into the newly-free slots. The "continuous" part: at each scheduler step, the active batch composition CAN CHANGE. A slot whose request finished at token N gets reclaimed and refilled with a queued request at token 0 -- so the GPU forward pass never has to wait for the whole batch to finish. Pure substrate logic. No Linux features. Composes with shipped nx_kv_arena (request's sequence holds its KV pages) and the future actor cardinal (sequences serve text + image-prompt + any other endpoint). V1 honest scope: - Fixed slot count (N <= NX_BATCH_MAX_SLOTS = 32) - Fixed pending queue (M <= NX_BATCH_MAX_PENDING = 64) - First-come-first-served queue ordering (no priority yet) - No per-sequence preemption (a slot runs to DONE; preemption queued for V2 when attention-class arbitration lands) genealogy_id: vllm_continuous_batching_2023 + tgi_2023 + cardinal_2026-05-20_elder_ai_off_docker + cardinal_2026-05-20_bits_up_nishi_not_linux lineage_id: substrate_batch_scheduler_v1 nx_capability_manifest: variant_class: batch_scheduler