You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf(core): paged pool slab growth reallocates whole layer tensors and transiently doubles server footprint #224
Found during a cross-version server memory-footprint measurement (v0.1.4 vs main, 2026-06-12) using scripts/bench_memory_footprint.py (commit 18c88c1). Method: one fresh mlxcel serve process per (config, scenario), fixed HTTP workloads at temperature 0, sampling the process phys-footprint via /usr/bin/footprint at 2.5 s (RSS does not see MLX Metal buffers at all). Model: llama-3.2-1b-4bit on M1 Ultra, --max-batch-size 8. Scenarios: idle, shared_prefix_burst (8 concurrent requests sharing a ~3.7k-token system prompt), seqshare (same prefix, 8 sequential requests), multiturn (one conversation, 8 turns), churn (32 distinct prompts). Run-to-run noise: idle/multiturn within 0.5 percent, burst/seqshare/churn peaks within 10 to 25 percent.
Problem
PagedBlockPool::grow_pool (src/lib/mlxcel-core/src/cache/paged.rs:1587) grows a layer's slab by allocating a fresh [capacity, block_size, n_kv_heads, head_dim] tensor with ffi::zeros and copying the old contents via slice_update, every POOL_GROW_CHUNK_BLOCKS = 32 blocks. The grow ops are recorded into the lazy graph, so during a long prefill many layers' old and new slabs coexist until the next eval. The transient cost approaches 2x the entire pool.
Activity
perf: chunked slab storage for the paged pool (#237)