Sparkle-Qwen27b-Kvmem-ninfer

在 12GB 笔记本显卡上运行 27B 本地 Agent

NInfer 推理 · KVMem 分层 KV · MTP3 推测解码 · dsh Agent 工作台

快速开始 · v1.1.0 更新 · 实测数据 · 文档地图 · 下载

逻辑上下文 256K，不代表每一步都读取全部历史。 长历史由 KVMem 存在 Host RAM，按检索结果调入 GPU；这减少了重复预填充，但不等于已完成满 256K 验收，也不保证每个任务都更快。

30 秒了解

桌面端： 仓库同时包含 desktop/ 的 Pmod 图形工作台（Tauri 2 + Vue 3.5），提供对话、模型配置、显存监控和 OpenAI 兼容网关；安装包构建脚本在 scripts/build-inno-installer.ps1。这是可选前端，不改变引擎和默认 Agent。

v1.1.0 更新

验证引擎 SHA-256：

8b2c195e32e3b58a3584b284679c990a07986691967f1b939b0fe31351559012

两项底层引擎改动

• 启动器默认开启；NINFER_KVMEM_OVERLAP_PREDECESSOR=0 可恢复 v1.0.0 选页。
• 选页诊断日志默认关闭：只有显式设置 NINFER_KVMEM_RANK_AUDIT_DIR=<目录> 才导出每代分数/入选状态和最终页名；目录可能含 prompt 相关页号，不要上传公开日志。

同谱系关闭态峰值为 11,230 / 11,242 MiB；110K 高 2 MiB，不能表述为严格零增量。只复测这两个用例，不宣称所有长任务都已解决。

畸形工具外壳最小修复。 现场回答是完整 <tool_call> 外壳内的 =job_output>，缺少 function 开标签且参数标签不合法；旧解析器把它当普通文本，dsh 随后正常 stop。新逻辑只识别“整个回答除空白外恰为这种完整外壳、合法函数名、parameter 起始和完整结束”的情形，送入已有的 malformed_tool_call 错误路径；不猜测、不执行原参数，错误参数中附正确 Qwen 标签例子和 intended_function。普通文字、Markdown 围栏/行内代码、截断外壳和合法 job_output 保持原路径。完整 C++ 解析器套件与新增回归通过；现场字符串逐字节回放只产生错误占位，不执行 job_output 或 write。

部署与 dsh 更新

• 默认 KV 改为 RK4V4 + GDN FP32。 日常 39,168 / 6,144 配置峰值 11,220–11,236 MiB，相对原日常 11,168 MiB 增加 52–68 MiB，仍在 +100 MiB 约束内；运行时余量只有约 12 MiB。短上下文 39 题相对 BF16 的 TV 为 0.0262、预测翻转 0（NVFP4 为 0.0288 / 1）；真实内容 189,954-token 多轮 24/24。公开示例保留更保守的 36,864 / 3,840 起步档。
• dsh 状态卡 v0.1.2。 在显著工具结果后追加确定性状态卡（目标、当前文件、最近尝试、最后错误、代码签名/常量摘要）：错误立即、写入每次、shell 每 3 次，上限 1,900 字符。它不修改历史、工具参数、系统提示、采样或 KV。v0.1.2 修复嵌套 tool-result.content，并在会话包含图片后停止注入，避免改变视觉会话边界。
• 5 次多文件重构 A/B：P0 均值 15.8 步 / 23.4 次调用 / 0.8 次重复 / 43,164 上下文 / 260 秒；baseline 16.0 / 25.4 / 2.40 / 53,825 / 348 秒；两边 5/5 测试通过。步数只下降 1.3%，范围重叠，n=5 不构成统计显著；方向性信号是重复调用、上下文、输出和耗时更低。pruner 阈值放宽和 pruner-bridge 仍是实验项，未并入日常。

已知问题

多图 + compaction 后的一个请求在 prefill 阶段报：

scatter: expected src [D,V], indices [V], dst [D,T]

99 条消息、7 个 media，HTTP 500；--recover-invariant-failures 恢复了引擎，但失败会话继续会复用同一压缩历史并再次失败。当前处理是开新会话，并使用 v0.1.2 的媒体保护。根因在视觉/状态张量路径，与 RK4V4 / GDN FP32 不是同一路径；本版不宣称已修复多图压缩场景。

安装与回退

• 源码标签：v1.1.0。
• 引擎附件：ninfer-5070ti-win-x64-sm120a-v1.1.0.zip；压缩包 SHA-256 daa2a6c5ab0c6a1715d839fcaf3ee4954c6c19d2641f9ee9aec6de083a3bae4a，内含引擎 8b2c195e…。
• dsh 单独包：dsh-state-card-v1.1.0.zip，SHA-256 cf37d659dd7439841dda362c0c341ff04377655592e822cadc524f3fd8bf2ab1；含 state-card v0.1.2、单测和手动 profile 片段；源码安装器已默认接入。
• 上一版回退：v1.0.0 引擎 71259a21f7b525ca7477193a292e4d3623cc58b9efd785005ee934cc29673507；v0.1.5 引擎 38bc4d8c6be07afd6c74b902cc33403bf2ee139a2c50129d363d68d74a7609d6。
• 只 git pull 不会替换旧 exe；升级已有安装需重新执行 setup.ps1。引擎仍显示 1.0.0 底座版本号，请以 SHA-256 和标签识别。

快速开始

方式 A：源码安装（推荐）

需要 Node.js 24+、VC++ x64 运行库、兼容 CUDA 13 的 NVIDIA 驱动，以及一个含 MTP 的 v3 .ninfer 模型。

git clone https://github.com/CSUNX233/Sparkle-Qwen27b-Kvmem-ninfer.git
cd Sparkle-Qwen27b-Kvmem-ninfer
powershell -NoProfile -ExecutionPolicy Bypass -File .\setup.ps1 `
  -ModelPath "D:\Models\qwen3.8-27b-gsq-rco-iq3-xxs.ninfer"
.\start.cmd

首次启动会下载固定哈希的引擎/依赖、加载权重并捕获 CUDA Graph。启动完成后，dsh 私有登录 URL 在 runtime/logs/dsh.stdout.log；不要公开这个 URL。

方式 B：引擎附件

下载上面的 v1.1.0 ZIP，把 ninfer-serve.exe 放到 runtime/engine/，再运行 setup.ps1 完成依赖与配置。引擎附件不含模型、Node、dsh 或运行 DLL，不是完整整合包。

默认端口

实测数据

以下不是统一基准：不同测试使用了不同二进制、端口和夹具。完整数据与限制见 v1.1.0 质量保真记录 和 benchmarks/evidence/v1.1.0/。

短上下文保真（39 题，首 token 分布）

同配置重复运行逐位相同。thinking-off 下 3^5-2^6 会固定答 211；日常 xhigh 路径 4/4 正确，不能用 thinking-off 判断日常质量。

显存（整卡峰值，nvidia-smi）

这是维护者机器的全池进阶档，不是公开默认保证；运行时余量只有约 12 MiB。若 OOM，先把池降到 38,912 / 38,400。

长上下文与真实内容

工具/JSON 回归

22 条工具/JSON 与 v1.0.0 同分 20/22、同失败题；xhigh 下两道路线算术 4/4；66K 输入 + 3,668 token 长输出无 OOM。

硬件与模型

推荐 32GB 系统内存、SSD、兼容 CUDA 13 的驱动。不同架构需适配内核与依赖，改 exe 文件名不会改变 GPU 支持。

显存不足时

1. 开启混合显卡模式，让桌面/浏览器尽量使用核显。
2. 在 NVIDIA 控制面板中只对实际引擎关闭 CUDA - Sysmem Fallback Policy。
3. 关闭无关后台 GPU 应用。
4. 仍不足，配套缩小页池与检索窗口（如 34,560 / 1,536），保留 sink/recent/HostKV。
5. NVFP4 不是省显存选项；本版默认 RK4V4 已比同池 NVFP4 少约 20 MiB。

保留 KVMem 的 7 GiB Host KV，它与驱动自动回退不是一回事。缩检索窗口可能降低历史召回，切换 KV 格式也不保证相同输出。完整步骤

工作原理

请求 → dsh Agent / 工具 → 缓存守卫 → NInfer 引擎
                                      ├─ GPU 热页（sink + recent + retrieve）
                                      ├─ Host KV（冷历史，按需回迁）
                                      └─ MTP3 推测解码

• KVMem 把长历史 KV 留在 Host RAM，按检索结果把需要的页调入 GPU；不是每步重读全部历史。
• MTP3 用 3 个 draft token 做推测解码，减少 decode 步数；日常保持原采样与 xhigh。
• 缓存守卫 保持已发送前缀稳定，减少重复预填充；它不能让不同 token 前缀安全共享 KV。
• dsh Agent 提供编辑前校验、多动作账本、工具结果保真和状态卡；这些是行为/上下文层改动，不替代引擎质量。

文档地图

已知限制

• 没有完成满 256K 验收。 逻辑容量是 262,144；实际 dsh 压缩阈值约 184K，长历史中段通过检索选页。
• 232K 随机串压力不代表真实任务。 多轮结果不稳定且跨格式共性，不作为质量承诺；真实内容 190K 为 24/24。
• 多图 + compaction 的 scatter 失败尚未在引擎层修复。 处理方式是开新会话；详见 已知问题。
• 状态卡 n=5 不构成统计显著。 步数基本持平，收益主要在重复调用/上下文/耗时。
• 本次预编译引擎只覆盖 Windows x64 / sm120a。 30/40 系与其他模型需自行构建/验证。
• 搜索需要互联网。 dsh 的网页/搜索不是离线索引，站点改版或验证码会导致失败。
• 私有原始请求、会话和日志留在本机。 公开目录只保留脱敏汇总。

历史版本

在 v0.1.5 的模型、NVFP4、39168/6144 页池、MTP3、xhigh、采样和回答惩罚设置不变的前提下，发布查询层与 agent 执行层升级：

• related-tool-head、suffix refresh=tail、QUERY_ASSEMBLE=1；真实 116,907-token 故障历史完整路径/合法 read-edit 1/4 → 4/4，留出 8 seeds 4/8 → 8/8。
• edit-guard 单文件精确替换执行前校验；task-ledger 多动作任务剩余提醒；结构化反馈后一次恢复 10/10（generic 0/10）。
• 因果 8/8、短续接 10/12、7/12 持平；旧延迟压力首轮仍 2/4；H7/H8/H11 拒绝并归档。
• 验证引擎 71259a21…；源码标签 v1.0.0。详见 Release Notes 与 路径查询实验。

在 v0.1.4 上移植 C2.1：滚动长锚点、同 lineage 锚点消费、冷页最多 32 页批量回迁。12 项定向回归通过；两个约 68K 夹具各 7 次请求，压缩前后藏针 7/7、状态/代码 6/6；最后一次压缩后续接复用 58,330/58,459 tokens，耗时 1.93/2.77 秒。整卡峰值约 11,176/11,174 MiB，无同条件 v0.1.4 对照。完整记录

v0.1.0–v0.1.4 的检索上下文、semantic history、NVFP4、工具解析、采样/惩罚和 C2.1 前序修复保留在源码与 [Release Notes](docs/RELEASE_NOTE