对我来说，真正有意义的并不是模型单轮聊天能跑多少 token/s，而是它能不能持续完成：

读项目 → 理解需求 → 写代码 → 跑测试 → 看报错 → 修改 → 再测试 → 打包 → 验收

折腾了一段时间以后，目前我体验最好的一套配置是：

Qwen3.8-27B GSQ-RCO IQ3_S-MTP + NInfer + DeepSeek Harness + 96K Context。

我的硬件和当前配置

主机并不是什么高端 AI 工作站：

• CPU：i5-14400F
• GPU：RTX 5060 Ti 16GB
• 内存：32GB DDR5
• 系统：Windows 10 x64

当前本地模型使用 Qwen3.8-27B GSQ-RCO IQ3_S-MTP，推理后端是 NInfer，Coding Agent 使用 DeepSeek Harness。主要参数为：96K 上下文、RK8V4 KV Cache、MTP 4、Thinking Budget 8K、单 Agent 为主、本地 API 服务。

我之前也跑过 48K 的 Q4 模型。实际体验下来，新的 IQ3_S + NInfer 方案不仅把上下文从 48K 提到了 96K，长上下文生成速度还能维持在 60 token/s 左右。这不是标准 benchmark，而是我自己真实开发时看到的运行数据。

我拿它开发了什么？

我直接拿自己在做的「服装色彩造型系统 V3」做长任务测试。这是一个用于人物形象设计和服装色彩教学的 Windows 桌面软件，包含换装、服装分区调色、花型、叠穿和 Look 管理等功能。项目从 9 月初的设计与交接到 10 月初持续迭代，前后约 4 周（断续开发）；截图中的素材栏显示约 35 件服装与配饰素材，并有 4 个独立造型 Look。

它不是只展示图片的 Demo。系统里要处理的功能包括：

• 服装与配饰穿脱、四套 Look 独立编辑
• 服装分区域换色，支持 HSL / RGB / HEX 调色和快捷色板
• 圆点、条纹、格纹、菱纹等花型，以及上传自定义花型
• 平涂 / 光影模式、SVG / Path2D 矢量服装结构、分区编辑与图层遮挡
• 保存、打开作品，Undo / Redo、复制造型、PNG 导出
• 离线授权与 60 天试用、绿色版和 Windows 安装包

所以项目涉及 Electron 桌面应用、状态管理、本地文件、IPC、授权、矢量绘图、服装几何、图层、导出、自动测试、E2E 和 Windows 进程生命周期等多个环节。

为了测试本地模型，我不是只让它在现有代码上补几行，而是整理产品需求，让本地 Qwen 根据需求参与系统实现和后续开发。这更接近测试它能否理解产品、拆分任务、实现功能、修 Bug、跑测试并完成交付。

连续长任务的实际表现

这个项目后来成了一个长链 Agent 压力测试。在一段核心开发过程中，Agent 连续参与了代码修改、测试、打包和视觉优化。一次长链记录显示：

• 9 轮以上、1100+ Agent steps
• 累计处理 6600 万+ tokens
• 生成速度约 60 token/s，缓存命中约 96%

这里的 6600 万 token 不是模型一次生成了 6600 万字，也不是一次塞进了 96K 上下文。Harness 显示的是多轮任务累计处理量，其中有大量重复上下文、工具结果和缓存命中的内容。比如一次统计里，总处理量约 6430 万，缓存读取约 6080 万，未缓存输入约 252 万，实际输出约 95 万。这个累计数不能直接拿去套 API 输出价格，但能看出长任务对上下文和缓存系统的压力。

最终测试做到什么程度？

我要求 Agent 不只写完代码，还要建立自动测试和验收流程。最终工程阶段做到：

• Unit Test：57 / 57 PASS
• E2E：74 / 74 PASS
• 安装测试：17 / 17 PASS
• Build：PASS
• Dist：PASS
• Security Scan：PASS

E2E 覆盖调色、花型、像素颜色断言、保存、打开、Undo / Redo、导出、授权、应用关闭守护、重启恢复和安装版启动。

中间还遇到过一个典型的 Electron / Playwright 问题：软件实际已经退出，但自动测试一直认为应用没有退出。模型一路排查到 Electron → Playwright → V8 Inspector → Process Transport，发现是测试环境停在 “Waiting for the debugger to disconnect...” 导致进程生命周期检测异常，最后修到了完整 74/74。只做几轮聊天很难测出这类问题。

96K 上下文的实际价值

我现在觉得，长上下文最大的价值不是一次塞一本书，而是让 Agent 有更大的工作记忆空间。开发过程中，它需要保留需求、项目结构、前面改过的文件、测试失败信息、Git / Build 状态、工具调用结果和前几轮排错结论。

48K 也能做，但复杂任务里会更早压缩。96K 让我能把一个开发阶段保持得更久。Harness 会自动 compact；有一次上下文接近 97% 后，历史约 31K tokens 被压缩，占用从 97% 降到 65%，Agent 没有重开会话，接着完成后续工作。它不是永远不压缩，而是减少压缩频率，让更多近期工程细节保持原样。

8K Thinking Cap 的作用

刚开始 Qwen 偶尔会进入很长的 reasoning：一直思考，最后把 16K 输出额度消耗得差不多，却没有真正调用工具。后来我给 NInfer 设置 default-thinking-budget = 8192，效果明显好一些。

它不是把整个 Agent 的思考限制为 8K，而是给单次模型调用设一个边界，避免单次推理占满输出空间、迟迟不进入回答或工具调用。

16GB 显存上的限制

5060 Ti 只有 16GB 显存，96K 可以跑，但余量很小。深度压测时最低剩余显存约 180MB；同时开 Electron、Playwright、浏览器、微信等使用 GPU 的程序，有过 Harness 返回 503、inference engine unavailable 的情况。后来重启 NInfer，模型又恢复了。

我现在的判断是：5060 Ti 16GB 跑 96K 可用，但属于比较极限的配置。日常可以考虑留一个约 90K 的稳定档，96K 留给特别长的任务；具体余量仍取决于模型、运行时和同时打开的程序。

本地模型的视觉短板

这套 Qwen 是 Text + MTP，没有 Vision。它能写 SVG / Path2D、算坐标、调服装几何、做图层和像素断言，但看不到自己画出来的东西是否好看。

有一次它重做人台后自动测试全过，截图里人物左肩却伸出一个巨大的米白色三角形。视觉模型检查后，我把反馈交回本地 Qwen；它发现颈部路径控制点少加了 B.cx，导致坐标从人物中心附近飞到 x≈26，Path2D 闭合后就出现了这个三角形。修完后人台恢复正常。

现在我的工作流是：本地 Qwen 连续开发 → 自动测试 → 生成截图 → 视觉模型验收 → 把结构化意见交回本地 Qwen → 继续修改。Coding 能力和视觉能力是两件事，视觉验收仍要有人或视觉模型参与。

一个提高效率的测试流程

一开始每次改一点视觉细节，我都让 Agent 跑完整 Unit、E2E、Build、Dist 和安装测试，一次微调要花四五十分钟。后来改成 Visual Fast Loop：修改 → 快速几何检查 → Build / Smoke → 截图 → 人工视觉检查。视觉确认后，再统一跑 57/57、74/74、Build 和 Dist。

这让我发现，Agent 的效率不只取决于模型 token/s，也取决于任务怎么编排。60 token/s 的模型，如果每次都做不必要的全量测试，一样会很慢。

量化模型带来的取舍

以前我觉得 27B 压到 3bit 左右，能力损失肯定很明显。但这次在长链开发、工具调用、Electron、JS、Windows、自动测试和调试中，IQ3_S 的实际表现比我预想好。更低的权重占用也给上下文和 KV Cache 留出了空间，让我从之前的 Q4 + 48K 转到 IQ3_S + 96K。

对 Coding Agent，我现在会一起看模型质量、上下文、KV Cache、推理速度、工具链、缓存和 compact 机制，而不是只看 Q4 是否一定比 Q3 聪明。对长 Agent 来说，略微量化但能跑 96K、维持约 60 tok/s 的模型，对我的工作流可能更实用。

最后的实际感受

这次折腾以后，我觉得 16GB 显存上的本地模型已经进入“能干活”的阶段。它不能替代最强云模型，也不是所有项目都能全自动完成，但已经能承担我手头的写代码、修 Bug、看日志、跑测试、Electron 开发、文档处理和长时间项目推进。

一个优点是可以让它持续做本地任务，不按云 API 的 token 用量计费；这次项目累计处理了 6000 多万 token。这个数是多轮任务的累计处理量，不等于实际输出量或一次上下文长度。本地使用的成本结构更像硬件投入加电费。

我目前最满意的组合

RTX 5060 Ti 16GB + Qwen3.8-27B GSQ-RCO IQ3_S-MTP + NInfer + 96K Context + RK8V4 KV + MTP4 + 8K Thinking Budget + DeepSeek Harness + Auto Compact。

后面我还准备继续测试 90K 与 96K 的稳定性、多 Agent 工作流、云端与本地模型 A/B、Vision Reviewer，以及多人共享推理服务。

至少对我自己来说，问题已经不是“5060 Ti 16GB 能不能跑 27B”，而是怎么让本地 27B Agent 更稳定、更长时间、更少人工干预地完成一整个任务。