vLLM-Omni Diffusion 模块家族深度解析运行时架构、执行模式与源码级实践指南【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni本篇技术指南以仓库内 diffusion.md 为骨架结合 docs/design/module/diffusion/ 下的五份子模块设计文档Diffusion Runtime、Model Integration、Continuous Batching、Parallelism、Offloader与 vllm_omni/diffusion/ 源码实现系统讲解 vLLM-Omni 扩散模型推理子系统的分层架构、请求生命周期、两种执行模式、分布式执行后端与 offload 内存管理机制。读完本文你将掌握该模块家族的核心设计约束与不变量invariants、请求从准入到清理的完整状态机、uni/mp执行后端的取舍以及各子模块对应的源码与测试路径可直接用于代码评审、二次开发与故障定位。一、Diffusion 模块家族总览从顶层索引到五条主线vLLM-Omni 将扩散diffusion相关能力组织为一个模块家族module family其权威索引位于 docs/design/module/diffusion/index.md而面向代码评审的入口摘要则是 .claude/skills/review-pr/references/modules/diffusion.md。该模块家族涵盖运行时runtime、模型集成model integration、批量调度continuous batching、分布式执行parallelism与内存管理offloader五个子系统对应五份子模块文档子模块关注的信号设计文档Runtime准入、调度、执行、进度、输出、取消、钩子、清理diffusion_runtime.mdModel Integration流水线、注册表、加载器、适配器、共享层、模型特定处理diffusion_model_integration.mdContinuous Batching兼容性、请求/步骤批次、逐请求进度、容量continuous_batching.mdParallelism秩拓扑、进程组、分片、集合通信、分布式执行parallelism.mdOffloader驻留、迁移、内存记账、预取、销毁offloader.md而缓存cache、量化quantization、性能剖析profiling与基准测试benchmarking则遵循各自的顶层模块文档不属于本家族文档的范畴。从源码看该家族的核心代码集中在vllm_omni/diffusion/**vllm_omni/diffusion/ 目录下包含diffusion_engine.py、request.py、data.py、sched/、executor/、worker/、models/、model_loader/、offloader/、distributed/等子包相关的平台代码位于vllm_omni/platforms/**验证测试位于 tests/diffusion/。1.1 家族级检查清单代码评审要点索引文档给出了五条全家族通用检查项是评审任何 diffusion 相关改动时的第一道关口单一生命周期所有者从准入admission到完成、取消、失败、清理每个请求必须只有一个调度器scheduler拥有的生命周期可选功能必须通过已定义的钩子hooks接入而非另起一套生命周期。通过注册表选择模型模型实现必须通过 registry 与 loader 契约选择禁止散落的model_name条件分支真实的模型差异只允许留在各自的模型目录中对应不变量 DIFF-MODEL-INV-002。追踪张量全链路latent、conditioning、timestep、generator、shape、layout、dtype、device、batch 扩展与输出转换必须一路追踪到实际消费者。批量兼容性与逐请求隔离批量兼容必须显式声明禁止依据不稳定的 batch 位置关联输出对应不变量 BATCH-INV-004。分布式边界纪律拓扑必须从校验过的配置推导、每个分片边界必须明确、集合通信必须对称、且必须保留受支持的单秩single-rank路径每个被 offload 的组件只能有一个驻留所有者传输就绪后才能被消费必须保留模型状态、限制保留副本数量并确定性清理。评审时还需要为缓存、量化、并行、连续批处理或 offload 加载对应的特性设计文档并强制要求特性关闭feature-off时行为正确、代表性的推理验证、terminal-path 测试以及针对优化的质量证据。二、Diffusion Runtime控制循环与组件职责Diffusion Runtime 是整个模块家族的核心负责 diffusion stage 内部的请求准入、调度、执行、进度、输出、取消与清理。它的设计文档是 diffusion_runtime.md主代码路径为 diffusion_engine.py、request.py、data.py、sched/、executor/、worker/核心验证测试在 test_diffusion_engine.py 与 test_diffusion_scheduler.py。2.1 运行时是一个小控制循环文档将运行时描述为一个精简的控制循环共五步调度器scheduler选择就绪请求执行器executor将这一选择发送到 worker 层每个worker管理自己的设备并把模型工作委托给runnerrunner调用模型流水线并返回逐请求结果引擎engine把这些结果反馈给调度器与输出流。从源码看DiffusionEngine定义于 diffusion_engine.py 第 218 行其类方法make_engine第 836 行负责解析引擎类并构造执行器与调度器add_request第 903 行负责准入abort第 1306 行与close第 1271 行负责取消与幂等关闭。2.2 目标与非目标目标让请求策略policy与设备执行device execution解耦让请求身份request identity从准入到最终输出含取消与失败保持稳定。非目标本模块不负责选择下一个 Omni stage、不放置 stage 副本、也不定义某个模型的去噪算法跨 stage 路由属于 engine_orchestration.md进程放置与副本生命周期属于 stage_runtime.md模型特定工作属于 diffusion_model_integration.md。2.3 运行时组件速览Stage 拥有DiffusionEngine与一个DiffusionExecutor后端。内联 stage clientinline_stage_diffusion_client.py把整条执行栈保留在调用进程内而进程型 stage 则运行在StageDiffusionProcstage_diffusion_proc.py内部进程间通过 ZMQ 通信。执行器随后决定 worker 的运行方式uninum_gpus 1时的默认值UniProcDiffusionExecutoruniproc_executor.py 第 43 行在进程内构建一个 worker没有worker 子进程、没有共享内存 RPCmpnum_gpus 1时的默认值或显式指定MultiprocDiffusionExecutormultiproc_executor.py 第 144 行为每个设备启动一个WorkerProc。无论哪种方式每个 worker 都拥有自己的设备、分布式状态、DiffusionWorker、DiffusionModelRunner与流水线实例。需要特别注意的是部署的 stage 可能已经运行在StageDiffusionProc子进程中这与可选的mpworker 进程是两回事。使用uni时worker 与引擎同处一个进程。2.4 组件职责划分表组件拥有不拥有DiffusionEngine准入、busy loop、调度器/执行器协调、RPC 排序、输出流、warmup、abort 路由批处理策略细节、设备设置、模型计算BaseScheduler请求状态、waiting/running 集合、容量、兼容性、终态转换IPC、worker 调用、输出格式化RequestScheduler完整请求波wave与可选的准入延迟面向请求级批处理去噪步骤进度StepScheduler逐请求去噪进度与逐步完成流水线张量与模型状态DiffusionExecutor执行后端契约、worker RPC、健康、关闭准入与请求状态转换UniProcDiffusionExecutornum_gpus 1时的单进程内 worker无 IPC、无异步输出泵多 GPU 执行MultiprocDiffusionExecutorworker 进程、共享内存消息队列、结果分发、worker 监控进程内单 GPU 路径WorkerProc单个mpworker 进程的 IPC 循环与回复规则调度策略uni不使用DiffusionWorker设备/分布式设置、LoRA 激活、profiling、sleep/wake、runner 委托请求准入DiffusionModelRunner流水线加载、请求本地模型状态、cache/compile 设置、请求或步骤执行排队与跨 stage 路由其中RequestScheduler、StepScheduler、BaseScheduler的实现分别位于 request_scheduler.py第 59 行、step_scheduler.py第 30 行、base_scheduler.py第 46 行DiffusionWorker与WorkerProc定义在 diffusion_worker.py第 225 行与第 1028 行DiffusionModelRunner定义在 diffusion_model_runner.py第 150 行。2.5 策略与执行的边界DiffusionSchedulerOutput策略与执行的边界是DiffusionSchedulerOutput对象。它包含新准入的请求负载payload其 runner 状态已被缓存、无需重新初始化的请求 ID已完成的请求 ID可选的 KV 预取prefetch工作当启用 paged Diffusion KV 时挂在NewRequestData信封上的逐请求diffusion_kv_metadata。执行器与 worker 只消费这个输出不自行决定接下来该运行什么。这从机制上保证了执行必须跟随调度决策这条不变量DIFF-RUNTIME-INV-002。BaseScheduler.initialize()会用od_config.max_num_seqs默认值为 1设置max_num_running_reqs。引擎可以为了分布式 layerwise offloadAllGather DP 并发而覆盖该容量。2.6 一次调度 tick 的完整时序异步请求共享同一个引擎 busy loopworker 调用与控制 RPC 都经过该循环因此不会在 executor 传输上产生竞态。一次 tick 的调用链为Caller调用Engine.add_request(request)引擎把请求交给Scheduler.add_request(request)并调用schedule()调度器返回DiffusionSchedulerOutput引擎调用Executor.execute_batch()或execute_step()执行器调用 worker 方法worker 再委托 runner 执行完整模型或单步runner 返回RunnerOutput(s)逐层回传为BaseRunnerOutput引擎调用Scheduler.update_from_output(...)得到已完成的请求 ID引擎向调用方输出 chunk 或最终结果。引擎会捕获请求执行错误并将其转换为逐请求错误输出。而整个 worker 组死亡是另一种情况执行器把自己标记为失败健康检查抛出EngineDeadError由所属 stage client 处理 stage 级故障。三、两种执行模式Request Batch 与 Step Batch引擎在启动时只解析一种模式并绑定对应的调度器与执行器调用模式调度器执行器调用Runner 路径Request batchRequestSchedulerexecute_batch()单请求execute_model()或融合批execute_model_batch()Step batchStepSchedulerexecute_step()execute_stepwise()用户侧的选择方法见 execution_modes.md对应 docs/user_guide/diffusion/ 目录下的执行模式指南本文聚焦模式选定之后运行时内部发生的事情。3.1 Request 模式整条流水线前向Request 模式为每个调度波wave运行一次完整的流水线前向单请求波是保守路径conservative path多请求波通常使用融合的execute_model_batch()要求流水线显式声明支持 request-batch。3.2 DLO DP 并发AllGather 专用分发路径分布式 layerwise offload AllGatherDLO DP 并发是一条独立的 multiproc 分发路径激活条件data_parallel_size 1设置了enable_distributed_layerwise_offloaddlo_use_allgather为 true。激活后引擎把dp_concurrent置为True并把scheduler.max_num_running_reqs提升到dp_size覆盖initialize()中来自max_num_seqs的默认值。调度器仍然发出多请求DiffusionSchedulerOutputmultiproc 执行器通过execute_request()而不是融合的execute_model_batch()来路由该波。可选的准入合并admission coalescing可以填满一个dp_size波当request_batch_max_wait_ms 0时RequestScheduler可能在一个波首次调度前短暂等待在dp_concurrent下稳定窗口为min(0.3s, wait/2)。默认request_batch_max_wait_ms 0即不等待。分发前MultiprocDiffusionExecutor.execute_request()会拒绝采样参数兼容性或extra_args不一致的波AllGather 要求每个 DP 秩遵循相同的前向调度。随后每个 worker 秩从波中取一个信封req[dp_rank % len(req)]这样每个秩进入同一个集合通信、同时计算不同请求。3.3 Step 模式与流式输出Step 模式把StepRequestState保存在 runner 中新请求先运行一次prepare_encode()每个 tick 运行denoise_step()与step_scheduler()完成的请求运行post_decode()。调度器只保留生命周期与进度元数据——不持有模型张量。Step 模式也是流式扩散输出的必经路径启用streaming_output时必要时会自动切换到 step 执行。支持 chunk 的流水线可以通过同一条请求流发出中间输出仅支持 final-only step 的流水线仍然只输出最终结果。如果流水线没有实现 step 执行初始化会失败。相关验证见 tests/diffusion 下的test_diffusion_streaming_output.py。四、请求状态机与身份管理调度器是已准入请求的真相来源source of truth其正常状态流转为[*] -- WAITING: add_request WAITING -- RUNNING: schedule WAITING -- FINISHED_ABORTED: abort RUNNING -- FINISHED_ABORTED: abort RUNNING -- FINISHED_COMPLETED: successful output RUNNING -- FINISHED_ERROR: failed or missing output FINISHED_COMPLETED -- [*]: deliver and remove state FINISHED_ABORTED -- [*]: deliver and remove state FINISHED_ERROR -- [*]: deliver and remove statePREEMPTED与BaseScheduler.preempt_request()虽然存在于调度器 API 上但当前引擎循环并不会调用它们——只有调度器单元测试在使用。request_id把调度器状态、runner 状态、执行器结果与输出队列串在一起。batch 位置是临时的在把结果映射回去时绝不能用 batch 位置代替请求身份不变量 DIFF-RUNTIME-INV-005 与 BATCH-INV-004 的双重约束。只有兼容的请求才能进入同一个运行波。调度器会比较一个模式相关的采样参数键并在第一个不兼容的等待请求处停止。这是有意为之的保守策略代价是可能产生队头阻塞head-of-line blocking。五、执行后端与 IPCuni 与 mp 的取舍DiffusionExecutor是后端接口通过distributed_executor_backend选择内置后端后端何时选择Worker 布局uninum_gpus 1默认或显式指定单个进程内 workermpnum_gpus 1默认或显式指定每设备一个 worker 进程Ray 与外部启动器external-launcher的扩散后端未实现。自定义DiffusionExecutor子类或 import path 也可被接受。5.1 Uniproc 后端UniProcDiffusionExecutor在引擎进程内构造WorkerWrapperBase并直接调用 worker 方法从而避免第二次模型加载、MessageQueue ring、ZMQ IPC socket 与/dev/shm张量打包。RPC 超时参数仅为接口一致性而保留不强制执行一个挂死的 worker 会阻塞调用线程。粘性加速器故障sticky accelerator faults通过失败回调把执行器标记为 dead普通请求错误仍是逐请求的。验证见 test_uniproc_executor.py。5.2 Multiproc 后端MultiprocDiffusionExecutor的启动流程创建所有 worker 共享的 broadcast 队列为每个配置的设备派生一个 worker 进程等待所有 worker 报告就绪以 RPC 消息发送生成与控制调用应用 rank-aware 回复规则只让预期秩应答监控 worker 进程哨兵若有 worker 死亡则使执行器失败。在 request 模式下每个异步输出产生两条以async_output_id关联的消息COMPUTE_DONE——前向结束设备可以开始下一个请求OUTPUT_READY——后台 D2H/SHM 打包完成最终输出就绪。worker 在入队COMPUTE_DONE之前就把后台打包工作排入队列但两条消息到达执行器的先后顺序不固定因此 result pump 与execute_batch()必须同时处理两种顺序。Step 模式保持同步结果路径不启动这些泵。更详细的时间线见特性文档 async_diffusion_output.md 与测试 test_result_pump.py、test_async_output_worker.py、test_multiproc_engine_concurrency.py。5.3 Worker 与 Runner 边界在mp路径上WorkerProc接收消息并通过WorkerWrapperBase调用方法在uni路径上执行器直接持有该 wrapper。两种情况下DiffusionWorker都处理与设备相关的部分分布式初始化、模型 runner 构造、LoRA 激活、profiling、内存 sleep/wake并把实际模型工作委托给DiffusionModelRunner。runner 拥有长生命周期的模型侧状态已加载的流水线与编译compile设置cache 与 offload 集成随机生成器设置完整前向的请求批次step 执行所需的StepRequestState与InputBatch。这种切分把基础设施挡在模型流水线之外流水线只接收请求批或 step 状态并执行模型工作不应检查引擎队列或修改调度器状态。这也正是 DIFF-MODEL-INV-003模型代码不负责调度请求的落地。六、生命周期与清理启动、取消、关闭6.1 启动与 WarmupDiffusionEngine.make_engine()解析引擎类、构造执行器与调度器然后通常运行一个小的 dummy 请求来预热warmup模型。仅在以下情况跳过 warmup启用了 DLO AllGatherenable_distributed_layerwise_offload与dlo_use_allgather且max(data_parallel_size, sequence_parallel_size) 1——因为 dummy run 只发送一个请求而 AllGather 要求每个 shard 秩进入同一个集合通信。若初始化或 warmup 失败运行时在返回错误前会先关闭调度器状态与 worker 资源。验证见 test_diffusion_engine_dummy_run.py。6.2 取消abort()把请求 ID 放入 abort 队列。busy loop 将这些请求标记为FINISHED_ABORTED终结阶段移除调度器状态并在仍有消费者时发出 aborted 输出。runner 在收到报告该请求 ID 已结束的调度输出时会清除缓存的 step 模式状态。在 multiproc request 模式的异步路径上abort 或消费者在输出物化期间断开时应当释放关联的 async-output 记账避免请求结束后仍保留迟到结果文档标注为 pending #6253/#6439/#6580。当前设计是未被消费的OUTPUT_READY会被有意缓存直到wait_output_ready()或执行器销毁。丢弃输出流消费者会移除该消费者的队列但不接管调度器清理的所有权。6.3 关闭与 worker 故障DiffusionEngine.close()是幂等的停止 busy loop、以错误唤醒挂起的流、关闭调度器状态、关闭执行器。mp执行器请求 worker 停止并等待错过宽限期的 worker 会被终止。关闭会把未完成的 RPC 与 async-output future 标记为失败并清除。为后续wait_output_ready()缓存且已完成的 async 输出随执行器对象一起丢弃。uni执行器关闭进程内 worker、丢弃最后一个模型引用、清空加速器缓存使后续引擎可以复用该设备。重要警告在致命的集合通信超时或意外 worker 退出后不要继续使用该 worker 组——分布式状态可能不完整。multiproc 执行器刻意 fail-closed让 stage 可以重启uniproc 执行器在加速器上下文本身被污染时同样 fail-closed。七、扩展边界与候选不变量评审锚点7.1 扩展边界自定义引擎可设置default_diffusion_model_runner_cls显式配置的diffusion_model_runner_cls仍然优先。测试与自定义引擎集成可以注入BaseScheduler子类SchedulerInterface仅作为已废弃的兼容名称保留见 base_scheduler.py 第 471 行。distributed_executor_backend可以是uni、mp、自定义DiffusionExecutor子类或 import path。后端必须保持调度输出、请求身份、健康与清理契约。需要进程隔离或多 GPU 时用mpuni是单 GPU 默认。worker 扩展通过WorkerWrapperBase进行添加 worker 方法但不变成第二个调度器或请求生命周期。这些是高级 Python 集成点不是稳定的终端用户 CLI 定制面。7.2 运行时不变量DIFF-RUNTIME-INV 系列INV-001 单一生命周期所有者每个已准入请求在完成、取消或失败之前必须恰好有一个调度器拥有的生命周期。INV-002 执行跟随调度输出执行器与 worker 必须执行调度决策不得独立准入、重排或转发请求。DLO AllGather 是分发时的例外调度器可调度多请求波但每个 DP 秩只从该波执行一个信封以保证所有秩进入同一集合通信调度。INV-003 终态清理完整每条终态路径必须释放请求状态、临时张量、钩子与运行时拥有的资源abort 或消费前消费者丢弃时的 async-output 记账也属必需要求pending #6253/#6439/#6580。INV-004 可选功能走运行时钩子cache、profiling、offload 与并行特性应在已定义的钩子上集成而不是再创建一个请求生命周期。INV-005 结果保持请求身份批量与异步结果必须按稳定请求 ID 映射而非假定的完成顺序。7.3 安全改动指南回归证据映射改动区域最小证据准入或状态转换test_diffusion_scheduler.py覆盖重复 ID、兼容性、abort、缺失输出引擎循环或输出投递test_diffusion_engine.py、test_diffusion_engine_cleanup.py、test_diffusion_engine_rpc_routing.py执行器或 IPCtest_multiproc_engine_concurrency.py、test_uniproc_executor.py、test_result_pump.py、test_diffusion_ipc.py、test_async_output_worker.pyWorker 或 Runnertest_diffusion_worker.py、test_diffusion_model_runner.pyStage 边界test_stage_diffusion_proc.py、test_inline_stage_diffusion_client.pyWarmup 或流式test_diffusion_engine_dummy_run.py、test_diffusion_streaming_output.py改动后务必覆盖成功、取消、逐请求失败、致命 worker 失败、重复关闭、单请求、多兼容请求step 模式改动还要测试部分进度与 runner 状态清理。八、其余四个子模块的契约与不变量8.1 Model Integration注册表即选择边界设计文档 diffusion_model_integration.md 的代码路径为vllm_omni/diffusion/models/**与vllm_omni/diffusion/model_loader/**相关layers/**、lora/**、utils/**。其职责是流水线契约、注册、checkpoint 加载、适配器、共享层与模型特定处理。不变量DIFF-MODEL-INV-001流水线必须声明其支持的模态、配置、输入、输出、加载路径与运行时能力DIFF-MODEL-INV-002运行时必须通过 registry 或 loader 契约选择模型实现而非散落的模型名条件分支DIFF-MODEL-INV-003流水线代码不得拥有准入、批处理、取消或跨 stage 路由DIFF-MODEL-INV-004模型目录应只包含真实的模型差异共享行为保持共享。Safe-change 指南要求测试registry 选择、checkpoint 加载、最小推理、输入输出契约以及每个已声明的可选能力。8.2 Continuous Batching显式兼容与逐请求隔离设计文档 continuous_batching.md 的代码路径为vllm_omni/diffusion/sched/**相关executor/**验证在 tests/diffusion/batching/。它定义扩散请求何时兼容、如何共享执行步、以及每个请求如何独立推进。不变量BATCH-INV-001 兼容性显式只有当所选流水线、调度器步骤、形状、精度与执行特性所需的所有属性都兼容时请求才可共享批次BATCH-INV-002 逐请求状态隔离批次组装必须保留每个请求的随机生成器、进度、conditioning、输出、取消与错误BATCH-INV-003 准入有界准入必须遵守配置容量不得依赖无界的等待或活动请求集合BATCH-INV-004 批次顺序≠完成顺序输出关联必须使用稳定请求身份而非跨执行步的 batch 位置。Safe-change 指南测试异构请求、部分完成、取消、确定性种子、容量限制以及 batch size 为 1 和多个的场景。8.3 Parallelism拓扑单一真相源设计文档 parallelism.md 的代码路径为vllm_omni/diffusion/distributed/**与vllm_omni/diffusion/attention/parallel/**相关vllm_omni/distributed/**、vllm_omni/config/composable_parallel/**。其职责是秩拓扑、进程组、张量与序列分片、集合通信与分布式执行。不变量PARALLEL-INV-001 拓扑单一真相源秩坐标、组成员与并行维度必须从校验过的配置推导PARALLEL-INV-002 分片契约显式每个分布式边界必须定义张量形状、分片维度、放置、dtype、生产者与消费者PARALLEL-INV-003 集合通信对称进程组成员必须以相同逻辑顺序调用兼容的集合通信PARALLEL-INV-004 单秩路径有效分布式实现应保留一个无需分布式初始化的受支持单秩路径。Safe-change 指南测试拓扑校验、单秩执行、受影响的并行模式、组合模式、非法形状与有序销毁。8.4 Offloader驻留、就绪与有界内存设计文档 offloader.md 的代码路径为vllm_omni/diffusion/offloader/**相关models/**、worker/**上游参考为torch.nn.Module.to。其职责是组件驻留、迁移调度、内存记账、预取与销毁。不变量OFFLOAD-INV-001 驻留显式每个被管理组件必须有一个已知驻留状态与一个负责转换的所有者OFFLOAD-INV-002 使用跟随就绪组件迁移到目标设备完成之前运行时不得消费它OFFLOAD-INV-003 迁移保留模型状态offload 必须保留参数与 buffer 的身份、dtype、设备以及所选执行模式所需的正确性OFFLOAD-INV-004 内存有界且释放保留的主机与设备副本必须遵守配置上限并提供确定性销毁。此外allocator-cache 保留必须局限于显式组件所有者、同时声明 cache 与物理空闲内存边界、在遥测不可用时保守释放并在失败或内存压力时强制释放它不得取代无条件的执行器关闭清理。相关配置与实现见 offloader/config.py 与 offloader/base.py。Safe-change 指南测试启用与禁用路径、重复执行、异步迁移、内存上限、失败、销毁与数值等价性。九、总结一次代码评审的完整检查路径结合 diffusion.md 的家族级检查与五份子模块文档评审一个 diffusion 相关改动时建议按以下路径走查先定子模块改动落在 Runtime引擎/调度/执行器/worker、Model Integration模型/注册/加载、Batching调度兼容性、Parallelism分布式还是 Offloader内存加载对应子模块文档与其不变量。验证生命周期纪律请求是否只有一个调度器所有者可选功能是否走钩子而不是新建生命周期INV-001/INV-004验证选择边界模型选择是否通过 registry/loader是否引入新的model_name条件分支DIFF-MODEL-INV-002验证身份与兼容性结果是否按request_id而非 batch 位置映射批次兼容是否显式、逐请求状态是否隔离、准入是否有界BATCH-INV 系列验证分布式纪律拓扑是否来自校验配置、分片契约是否显式、集合通信是否对称、单秩路径是否保留PARALLEL-INV 系列验证内存纪律offload 组件是否有唯一驻留所有者、就绪后才被消费、状态是否保留、副本是否有界OFFLOAD-INV 系列对照测试证据按第三节的 safe-change 映射表运行对应单元测试并补齐成功/取消/逐请求失败/致命故障/重复关闭/单请求/多兼容请求的覆盖。通过这套自顶向下的检查路径可以在不改动一行代码的情况下快速定位绝大多数设计级缺陷这也是该文档家族作为设计索引 评审锚点的核心价值所在。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考