16GB显存极限挑战：RTX 5070 Ti 本地部署 Qwen3.6-27B (Q4) 调优指南与实测报告
-
超长的上下文并不适合所有工作。建议够用就行。比如65K 就可以接入 Hermes 。就可以做很多项目了。没有64K 也可以作弊接入。效果是没有什么影响的。优化后 (-ngl 50 -c 96K)：这个值是需要你生成一些问题跑满96K才能知道是否稳定。我深度测试了几个模型 都不是很理想 受限于你的预留显存 在 KV 上升后大多数的模型都会变慢。或少数预留过少OOM。希望看到你更深入的测试。
-
超长的上下文并不适合所有工作。建议够用就行。比如65K 就可以接入 Hermes 。就可以做很多项目了。没有64K 也可以作弊接入。效果是没有什么影响的。优化后 (-ngl 50 -c 96K)：这个值是需要你生成一些问题跑满96K才能知道是否稳定。我深度测试了几个模型 都不是很理想 受限于你的预留显存 在 KV 上升后大多数的模型都会变慢。或少数预留过少OOM。希望看到你更深入的测试。
@williamlouis 我测试过了，65k可以接入Hermes ，但频繁触发上下文压缩，使用体感很差。其实个人感觉128k是比较合适的值，我在q3上测试过128k，上下文压缩在可接受的程度。个人完全不建议64k。问题是128k在16g上跑q4，卡成狗了。
-
@stxpnet 我不在乎，本来就是在线和本地双模型协同模式，在上一篇q3模型里提到过。主力是deepseek v4 flash，本地模型主要用来执行。这样能省不少tokens耗用。本地想要用得爽，32g打底，48g合格，128g畅玩。但也说不准，模型优化后，体积大幅减小？
-
@gwager 我是双模式协同，不是独立本地模型。推理用deepseek v4 flash ，飞快的。执行才用本地。
-
补充，委托模式运行实况及分析，AI生成，
这是从
agent.log里精确统计的，覆盖 6月8日~6月12日（约5天）：
一、DeepSeek 云端实际消耗
模型 调用次数 输入 Tokens 输出 Tokens 缓存命中率 deepseek-v4-flash 1,468 95,736,999 594,098 96.4% deepseek-chat 158 5,258,445 48,572 96.1% 合计 1,626 100,995,444 642,670 96.4% 成本（按 V4 Flash 定价含缓存折扣）：
- 实际花费：$2.40（5天）→ 日均 $0.48 → 月均 ~$14
- 如果没有缓存：$15.53（缓存帮你省了 $13.14，占 86%）
二、委托模式的实际节省
从日志里找到了 7 次
delegate_task调用：委托任务 耗时 返回给DeepSeek的摘要 查llama.cpp更新 15.9s 2,029 chars 技能库维护 30.6s 1,284 chars 代码/配置工作 82.2s 3,193 chars 长任务 215.8s 1,788 chars 批量调试 357.0s 2,548 chars 大规模排查 385.0s 10,467 chars 多并发热点排查 444.2s 2,199 chars 合计 ~105分钟 23,508 chars 这些子 agent 在本地做的事如果走 DeepSeek 会怎样？
- 每个子 agent 内部平均做了 ~10 步工具调用（读文件、grep、curl、pip list 等）
- 这些工具调用的输入输出如果全部进 DeepSeek 上下文，约 56,000 tokens
- 但 DeepSeek 输入本来就很便宜（缓存命中只要 $0.015/M），所以美元层面的节省不大（~$0.001）
三、委托模式真正的价值
关键发现：节省大头是 DeepSeek 的 96.4% 缓存命中率，不是委托模式。
委托模式的实际好处不在省钱，在别的地方：
委托模式的核心收益：
┌─────────────────────────────────────────────┐
│ 1. 上下文清洁 子agent的工具输出不污染 │
│ 主上下文，避免过早触发压缩 │
│ │
│ 2. 并行能力 最多3个子任务同时跑 │
│ 总耗时 = 最长任务，不是总和 │
│ │
│ 3. 零网络延迟 本地 Qwen 走内网 │
│ ~13 tok/s decode │
│ 没有API超时/断连问题 │
│ │
│ 4. 隔离性 子agent OOM/卡住了 │
│ 不影响主会话 │
│ │
│ 5. 安全沙箱 subagent_auto_approve=false │
│ 危险命令自动拦截 │
└─────────────────────────────────────────────┘委托模式的核心收益： ┌─────────────────────────────────────────────┐ │ 1. 上下文清洁 子agent的工具输出不污染 │ │ 主上下文，避免过早触发压缩 │ │ │ │ 2. 并行能力 最多3个子任务同时跑 │ │ 总耗时 = 最长任务，不是总和 │ │ │ │ 3. 零网络延迟 本地 Qwen 走内网 │ │ ~13 tok/s decode │ │ 没有API超时/断连问题 │ │ │ │ 4. 隔离性 子agent OOM/卡住了 │ │ 不影响主会话 │ │ │ │ 5. 安全沙箱 subagent_auto_approve=false │ │ 危险命令自动拦截 │ └─────────────────────────────────────────────┘举两个实际例子：
-
去读 config.yaml、搜索文件、查 skill 文档——这些文件内容如果全部进 DeepSeek 上下文，会吃掉 ~8,000 tokens。委托模式下本地 Qwen 读完了只返回摘要，这些
tokens 根本没进 DeepSeek 上下文，也就不会触发 1M 窗口的过早填满。 -
那个 385 秒的委托任务，子 agent 内部可能做了 20+ 步操作（查文件、搜日志、分析数据），返回给 DeepSeek 的只有 10,467 chars 的摘要——如果这些步骤的中间结果全进 DeepSeek
上下文，大概要多占 15,000-30,000 tokens。
一句话总结： 目前的实际账单是 $14/月，省钱的 MVP 是 DeepSeek 自带的 96.4% 缓存命中。委托模式的主要价值是上下文管理 + 并行效率 + 稳定性，而不是 token 账单——因为在 96%
缓存命中率的加持下，DeepSeek 的输入成本已经低到几乎可以忽略了。deepseek-v4-flash · 5% · GPU:29°C · VRAM:15057MiB/14GB · Fan:0%
-
@williamlouis 我测试过了，65k可以接入Hermes ，但频繁触发上下文压缩，使用体感很差。其实个人感觉128k是比较合适的值，我在q3上测试过128k，上下文压缩在可接受的程度。个人完全不建议64k。问题是128k在16g上跑q4，卡成狗了。
@kevon 说:
65k可以接入Hermes ，但频繁触发上下文压缩，使用体感很差。其实个人感觉128k是比较合适的值.......问题是128k在16g上跑q4，卡成狗了。
我也是5070 Ti 使用者 + hermes
這16GB 不夠用...我都只能用笨笨的小體積或權重模型
才能湊到 KV Cache 65K ctx_size ,
但這樣笨笨地亂跑又沒意義, 被agent氣死 (跟agent 無關 只能說 llm精度太低)個人理解 基本要舒服用就是至少要Q4_K_M, 128K ctx_size
用RTX 5070 Ti 16GB x 2 會舒服非常多 -
@kevon 说:
65k可以接入Hermes ，但频繁触发上下文压缩，使用体感很差。其实个人感觉128k是比较合适的值.......问题是128k在16g上跑q4，卡成狗了。
我也是5070 Ti 使用者 + hermes
這16GB 不夠用...我都只能用笨笨的小體積或權重模型
才能湊到 KV Cache 65K ctx_size ,
但這樣笨笨地亂跑又沒意義, 被agent氣死 (跟agent 無關 只能說 llm精度太低)個人理解 基本要舒服用就是至少要Q4_K_M, 128K ctx_size
用RTX 5070 Ti 16GB x 2 會舒服非常多
