NInfer 引擎架构深度解析Gateway、Frontend、Engine 与 Program 四层执行边界【免费下载链接】ninferHigh-performance single-GPU inference for selected model checkpoints and GPUs.项目地址: https://gitcode.com/gh_mirrors/ni/ninferNInfer 是一款面向单张 GPU 的高性能 LLM 推理引擎它为 Qwen3.5 等模型 checkpoint 提供从 CLI 到 HTTP 服务的完整推理链路。本文以 NInfer 引擎架构为主线带你在没有代码噪音的情况下快速看懂 Gateway、Frontend、Engine、Program 四层执行边界是如何划分职责、又如何在一次请求中协同工作的。 为什么要拆成四层NInfer 的 Generation 引擎在一张 GPU 上运行一个常驻模型实例配合有界 FIFO 等待队列和max_concurrency1..8的小并发模型。无论是文本、视觉输入还是 MTP/DFlash 推测解码所有请求都走同一条公共 Engine 路径而不是各开各的调度器。为了让协议、语义、调度和物理执行互不污染NInfer 把请求路径固定为四层Gateway 协议与媒体获取 ▼ Frontend 提示词与输出语义 ▼ Engine 请求顺序与生命周期 ▼ Program 物理资源与模型执行这套单 GPU 推理引擎分层架构是整个项目最稳定的边界协议怎么改、模型怎么换四层的所有权划分都不变。上图为 bench/fixtures/ttft/ 中的 TTFT 基准媒体输入正是经由 Gateway 层进入引擎的视觉素材类型。第 1 层Gateway —— 协议翻译官Gateway 是 CLI 客户端 与 HTTP 服务 等一切产品入口源码集中在 src/serve/ 目录。它负责协议解析与流式传输同时支持 OpenAI Chat / Responses 与 Anthropic Messages 两种消息协议核心入口是 generation_service.h 与 http_server.h输入统一把 message、tool call、URL 与本地媒体文件统一转换成公共输入格式通用转换逻辑在 src/product/prompt_input/ 与 src/product/media_acquire/响应与错误response schema、usage 统计和产品侧错误映射。关键约束Gateway 从不选择请求顺序、缓存来源或 KV 页它只是把外部世界翻译成引擎能懂的语言。第 2 层Frontend —— 模型的语义专家Frontend 拥有模型家族的输入输出语义实现位于 src/models/qwen3_5/frontend/输入侧tokenizer、chat template、视觉预处理和提示词构建产出不可变的PreparedPrompt见 frontend.h输出侧每个请求独占一个OutputSessionoutput_session.h负责停止词、thinking/content 通道、detokenization 等预览权而非发布权Frontend 可以预览一次模型输出将产生的语义效果但只有 Engine 完成提交后才能真正发布。上图是 examples/cli/ 中的视觉推理示例图形计数与位置关系的识别就依赖 Frontend 把图像编码进提示词、再把模型输出还原为文本。第 3 层Engine —— 请求控制平面Engine 是四层中的总指挥公共门面定义在 include/ninfer/engine.h核心实现在 src/runtime/engine/engine_core.h 与 engine.cpp。它拥有等待队列、请求记录、取消与响应事件内部又分两个专职裁判组件位置只决定什么Schedulerscheduler.h谁在何时运行FIFO 队头、prefill/decode 公平门、紧凑 decode 批次成员ResourceManagercontext_cache/resource_manager.h保留什么逻辑上下文logical lane、checkpoint 目录、缓存保留策略请求在 Engine 中沿一条稳定状态机前进Waiting → Materializing → Prefill → DecodeReady / ControlReady → TerminalPending → Finished同时Engine 编排两类互不替代的提交事务资源迁移事务materialization、checkpoint 捕获、释放与模型单元事务每轮 prefill/decode 产出PendingBatch由一次commit或abort整体消费。输出发布的严格顺序是Frontend 预览 → Program 提交 → 预算与调度记账 →OutputSession提交 → 向用户发布事件。因此消费者永远不会看到未提交的 token。第 4 层Program —— 物理执行的唯一权威Program 是模型实例的物理执行入口实现位于 src/models/qwen3_5/program/核心是 program.h。它独占状态与缓存State/KV store、分配器、replica 与 reservation底层页式 KV 由 src/core/ 的 paged KV 设施支撑执行后端prefill、普通 decode以及 MTP / DFlash / DFlash2 推测解码都是 Program 内部后端不产生第二套调度机制高性能细节workspace 规划、CUDA Graph 捕获、固定模型调用。Program 的边界同样严格它不维护 FIFO、不决定缓存价值、不碰用户可见输出——那些都属于 Engine。物理事实占用、可行性、ResourcePlan只由 Program 说了算。 核心不变量NInfer 为什么稳定架构文档 docs/maintainer/engine-architecture.md 定义了十项核心不变量其中最值得记住的三条请求顺序只由 Scheduler 决定资源状况不能反向改变 FIFO 所有权物理可行性只由 Program 决定一个 PendingBatch 必须被一次 commit 或 abort 完整消费模型输出必须经过 Program、Frontend、预算三方提交后才对消费者可见。 阅读源码的建议路径想动手验证本文内容建议按四层依次阅读公共接口include/ninfer/engine.h、include/ninfer/types.hEngine 控制面src/runtime/engine/、合同定义 src/runtime/contract/模型前端src/models/qwen3_5/frontend/物理执行src/models/qwen3_5/program/、语义算子 src/ops/相邻深入文档资源调度与上下文缓存、Paged KV Cache一句话总结Gateway 管协议、Frontend 管语义、Engine 管顺序、Program 管物理——这四条边界就是 NInfer 引擎架构的全部骨架看懂它就看懂了单 GPU 高并发推理引擎的设计精髓。【免费下载链接】ninferHigh-performance single-GPU inference for selected model checkpoints and GPUs.项目地址: https://gitcode.com/gh_mirrors/ni/ninfer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考