你让本地 AI 一次读几百份行业资料，它也许装得下，却未必能稳定接活：两个人同时提问怎么办，显存不够怎么办，服务出错后怎么看，聊天消息又该怎样整理？NInfer 的新动向值得关注，正因为开发者开始处理这些不显眼、但决定软件能否真正工作的细节。
NInfer 是本地大模型推理引擎——负责让训练好的模型接收输入并生成回答的软件，与 llama.cpp、vLLM 处在同一层。本刊 8 月 31 日曾报道，有分支借两张 RTX 5090 和 YaRN 尝试百万 token 上下文。这一次，焦点从双卡纪录转向单张 RTX 5090，以及缓存、并发、监控和模板等服务能力。
需要先说明：目前材料来自两名 Reddit 用户的一手自述，没有论文、官方文档、代码复现或第三方测试。两者共同支持的结论，是 NInfer 已被用于在单张 RTX 5090 32GB 上运行 Qwen3.8-27B NVFP4，并提供至少 240K 上下文；其余性能数字大多只有单一来源。
先把“记忆”挪出显存
上下文越长，模型需要保留的 KV cache 越大。KV cache 可以理解为模型读长文时留下的中间笔记，避免生成每个新词时都重读全文。问题是，这本笔记通常占用昂贵的 GPU 显存。
开发者 gzenz 的个人分支加入了 NVFP4 KV cache，即用 4-bit 格式压缩这份笔记。他自报其占用为每 token、每 KV head 144 bytes，对照 int8 的 264 bytes 和 bf16 的 512 bytes，显存用量降低 45%。分支还加入 HostKVSafetyNet 和主机端 KV 缓存：当 GPU 显存紧张时，把部分笔记停放到电脑的系统内存，并处理并发恢复、内存整理和多段分配。
该分支还支持多级前缀复用。若多次请求共享一大段开头内容，系统可以复用已算好的缓存，不必每次从头处理。对长期运行的服务来说，这类能力往往比单次跑出一个极长数字更实际。
55.5 万上下文之外，还补了什么
据分支作者自测，Qwen3.8-27B 的上下文可从原生 262K 扩展到单卡 555K（c=3+vision），或在 c=1 时达到 600K。作者还报告 LongBench 45%、AIME 96.7% 和 needle-in-haystack 100%，并称 600K 时表现与 int8 基线相当，能生成连贯的 592K-token 输出。但这些测试的样本、计分口径和“连贯”标准没有完整披露，因此更适合作为待复现线索，而不是已经坐实的结论。
更重要的变化在纪录之外。这个个人分支补入监控、Jinja 模板和更开放的模型支持。Jinja 是把变量填入文本骨架的模板系统，在模型服务里常用来把用户、助手等不同角色的消息整理成模型预期的提示格式。它们不会让跑分数字立刻变漂亮，却是接入真实应用时绕不开的基础设施。
另一名用户把 NInfer、llama.cpp 和 vLLM 放进真实的 HVAC 内容分析流程，测试长文本检索、跨转录问答、推理和结构化抽取。其配置中，NInfer 使用 240K 上下文、FP8 KV cache，并以连续批处理提供两路并发；llama.cpp 对照配置为 parallel=1。NInfer 的 MTP3——一次尝试预测多个后续 token 的生成方式——录得 76% acceptance。不过供稿截断在评估方法，缺少最终质量和速度结果，不能据此断言 NInfer胜过 llama.cpp 或 vLLM。
为什么值得继续追踪
极长上下文像仓库容量，生产服务则还要看装卸、调度和盘点。NInfer 现在显露出的变化，正是从“能塞进去多少”转向“能否让多人稳定使用”：压缩并转移缓存，复用共同前缀，支持连续批处理，再补上监控和消息模板。
这还不是成熟度已经得到证明，而是社区开始补正确的短板。尤其值得注意的是，这些新增能力属于个人 fork，不能归到上游 NInfer 名下。
局限与未知
- 该生产测试中，NInfer 不支持
json_mode，因此结构化抽取项目被跳过；这仍是服务化能力的明显缺口。 - 555K/600K、45% 显存降幅及质量分数均只有作者自测，尚无独立复现；两份材料的 KV cache 格式和上下文配置也不同，不能互相充当验证。
- 所谓 96GB 以上 GPU 可达 8M token，只是作者未经测试的推算，不能写成已经实现。