oMLX 连续批处理原理深度剖析BatchGenerator 如何调度并发请求【免费下载链接】omlxLLM inference server with continuous batching SSD caching for Apple Silicon — managed from the macOS menu bar项目地址: https://gitcode.com/GitHub_Trending/om/omlxoMLX 是一款运行在 Apple SiliconM 系列芯片上的本地 LLM 推理服务器支持**连续批处理Continuous Batching**与 SSD 缓存并通过 macOS 菜单栏一键管理。本文将带你从零理解它的调度核心Scheduler如何把成百上千个并发请求喂给 mlx-lm 的BatchGenerator让多个用户同时对话时GPU 依然保持满载。什么是连续批处理为什么它快传统推理服务常用静态批处理凑齐一批请求一起跑完才释放。问题在于——短请求早就答完了却要为最长的那条请求陪跑GPU 大量时间被浪费。连续批处理的思路则完全不同以「生成一个 token」为最小调度粒度某条请求一旦答完立刻移出批次空出的算力立即给下一条排队的请求顶上新请求完成提示词处理Prefill后随时可以插入正在运行的批次。oMLX 正是遵循 vLLM 的经典设计一个等待队列 一个运行集合 一个批处理引擎。核心洞察写在源码注释里mlx-lm 的BatchGenerator本身已经在 token 层面实现了连续批处理所以 oMLX 直接把它当作推理后端在其上构建调度层见 omlx/scheduler.py。调度全景Waiting 队列、Running 集合与 Prefill 阶段打开 omlx/scheduler.pyScheduler类内部维护三块核心状态状态数据结构含义waiting双端队列FCFS排队等待的已入队请求running字典按请求 ID已进入批次、正在逐 token 解码的请求prefilling集合长提示词正在分块预处理的请求请求的完整生命周期如下入队API 请求到达完成分词tokenize后进入waiting队列准入调度器检查内存水位与 SSD 前缀缓存命中情况决定是否放行预填充长提示词按prefill_step_size默认 2048 token分块处理短提示词一步完成插入批次Prefill 完成即调用BatchGenerator.insert()请求获得内部 UID 并移入runningomlx/scheduler.py解码BatchGenerator对批次内所有请求并行生成 token出队命中停止条件或达到最大长度后请求被remove()输出流回写给客户端。并发请求如何排队add_request 里的门道add_requestomlx/scheduler.py是请求的入口它藏着几个对高并发很关键的设计背压机制等待队列有上限max_num_seqs × 4最少 32。队列满了就抛出SchedulerQueueFullError服务端将其映射为HTTP 503 Retry-After让客户端稍后重试而不是无限堆积请求拖垮内存前缀缓存查询延迟到准入阶段如果同前缀的请求正在把缓存块写入 SSD新请求会先短暂等待从而提高缓存命中率同时不阻塞调度主流程记忆预检Preflight没有块感知缓存时入队即估算本次 Prefill 的显存需求装不下的请求提前拒绝。每个请求对象omlx/request.py还会记录batch_uid即BatchGenerator分配的内部编号——调度器用它把 mlx-lm 返回的响应准确映射回对应请求。调度心跳一个 step() 里发生了什么调度器以一步step为单位循环推进step()方法omlx/scheduler.py的固定节奏是先处理中止客户端断开的请求立即从批次移除绝不带着死请求前进推进分块预填正在 Prefill 的长提示词每步前进一个块。若其他引擎正在解码还会通过解码公平性decode fairness主动让出 GPU 时间片避免长 Prefill 卡住所有人的生成速度准入调度把waiting队列中通过检查的请求调度过去执行一次生成调用BatchGenerator.next_generated()批次内所有 running 请求同步产出各自的新 token分发与清理响应按 UID 分发回各请求流完成的请求清理 KV 缓存每 1024 个 token 定期清理 Metal 内存池防止长会话内存碎片累积。值得一提的细节最后一批请求完成后oMLX 会延迟 8 步再调用mx.clear_cache()因为 macOS 的 IOKit 存在异步内存回收回调清得太急会触发内核异常源码中引用了 issue #435。这是典型的硬件平台细节决定调度节奏的例子。关键参数速览如何调节并发能力所有调度参数集中在SchedulerConfigomlx/scheduler.py大部分可在管理面板或 CLI 中调整参数默认值作用max_num_seqs256批次内最大并发请求数直接决定同时能服务多少人max_num_batched_tokens8192单步最多处理的 token 总量prefill_step_size2048长提示词分块预填的块大小chunked_prefillFalse开启后 Prefill 分块与 Decode 交错执行降低并发下的首字延迟TTFTdecode_fairnessTruePrefill 主动向正在解码的请求让路保证多人对话不打架简单选型建议‍单人使用并发数调小4~8内存占用更低单请求速度更快多客户端共享保持较大max_num_seqs并开启chunked_prefill首字延迟更平稳⚠️ 并发越大KV 缓存占用越高。oMLX 通过SSD 分页缓存见 omlx/cache/factory.py把冷数据换出到固态硬盘让高并发不至于爆内存。再深入一点值得阅读的文件调度器主体与连续批处理实现omlx/scheduler.py请求模型与 BatchGenerator 集成字段omlx/request.py引擎核心循环驱动 Scheduler.stepomlx/engine_core.py模型所有权与批次状态隔离omlx/model_registry.py调度器单元测试含 BatchGenerator 打桩tests/test_scheduler.py调度器分块预填专项测试tests/test_scheduler_chunked_prefill.py项目结构与贡献指南docs/CONTRIBUTING.md小结oMLX 的连续批处理可以概括为一句话调度器管谁来跑BatchGenerator 管怎么跑。Scheduler负责准入、排队、分块预填和生命周期管理mlx-lm 的BatchGenerator负责在 Apple Silicon 上高效执行 token 级批处理。两者配合让 M 系列芯片上的本地大模型服务在多人并发时依然流畅——这正是Local AI, no more waiting on your Mac的技术底气。✨【免费下载链接】omlxLLM inference server with continuous batching SSD caching for Apple Silicon — managed from the macOS menu bar项目地址: https://gitcode.com/GitHub_Trending/om/omlx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考