本地部署 260K 上下文 Qwen-3.6-35B-A3B 与 Ornith-1.0-35B 模型及 VSCode Copilot 参数调优记录

本地部署 260K 上下文 Qwen-3.6-35B-A3B 与 Ornith-1.0-35B 模型及 VSCode Copilot 参数调优记录

0x00 缘起

在本地构建编程 AI Agent 的过程中，算力约束始终是核心瓶颈。本文记录在 RTX 5060 Ti 16G 显存条件下，如何本地部署高上下文（260K）MoE（Mixture of Experts）模型并将其接入 VSCode Copilot 的工作流。

MoE 架构模型通过将计算任务动态卸载至 CPU，在有限显存下换取了更大的上下文窗口与更高的并发吞吐。实测表明，在合理调优下，35B 级 MoE 模型可稳定输出约 35 tokens/s，且显存温度可控；而同等参数量的稠密模型（如 27B）虽可全量塞入显存，但在大上下文与并发场景下易触及性能瓶颈。

本文旨在完整记录三款模型（Qwen-3.6-35B-A3B、Ornith-1.0-35B、Qwen3.6-27B）的启动参数、VSCode 对接配置、调优过程及实际表现，为同类硬件环境下的本地编程 Agent 部署提供参考。

---

0x01 环境

硬件配置：

• CPU：AMD R5 7500F
• GPU：RTX 5060 Ti 16G
• RAM：48 GB DDR5

软件环境：

• 操作系统：Windows 11 + WSL2
• 推理引擎：llama.cpp (CUDA 13.3, commit b10217-ddd4ec142)
• 集成插件：VSCode 1.131 + OAI Compatible Provider for Copilot（第三方扩展）

涉及模型：

• Qwen3.6-35B-A3B-NVFP4-Fast.gguf
• Ornith-1.0-35B-NVFP4-MTP.gguf
• ornith-1.0-35b-Q4_K_M.gguf
• Qwen3.6-27B-abliterated-i1-IQ4_XS.gguf

---

0x02 对策

本节提供各模型的完整启动命令、VSCode 参数配置及验证步骤。

2.1 Qwen-3.6-35B-A3B 配置与调优

该模型为 NVFP4 量化版本，专为高效推理优化。启动命令如下：

llama-server `
   -m "D:\Caches\Models\Qwen3.6-35B-A3B-NVFP4-Fast.gguf" `
   -ngl 99 `
   --n-cpu-moe 999 `
   --flash-attn on `
   --jinja `
   -c 260000 `
   -t 12 `
   -b 1024 `
   -ub 512 `
   --cache-type-k q4_0 `
   --cache-type-v q4_0 `
   --mlock `
   --host 127.0.0.1 `
   --port 8080

资源占用表现：

• 内存：约 36 GB
• 显存：约 8 GB（12 GB 显存设备亦可流畅运行）
• 输出速度：约 35 tokens/s

VSCode Copilot 参数配置：

在扩展中绑定 baseurl: http://127.0.0.1:8080/v1，并设置如下推理参数：

参数	值	说明
context_length	128000	上下文窗口
max_tokens	12800	最大生成长度
temperature	0.5	随机性控制
top_p	0.87	核采样阈值
top_k	17	候选词截断
min_p	0.02	最低概率阈值
frequency_penalty	0.0	频率惩罚
presence_penalty	0.1	存在惩罚
repetition_penalty	1.05	重复惩罚

接入验证：

使用 Prompt："自动编写一个 2048 游戏 Vue 项目"。模型可生成完整结构，但代码逻辑存在若干缺陷，且偶发"局部最优死循环"（复读机式输出）。

---

2.2 Ornith-1.0-35B 配置与调优

Ornith 系列提供 NVFP4 与 Q4_K_M 两种量化版本，实际表现差异微小，NVFP4 显存占用略低。

启动命令（以 NVFP4 为例）：

llama-server `
  -m "D:\Caches\Models\Ornith-1.0-35B-NVFP4-MTP.gguf" `
  -ngl 99 `
  --n-cpu-moe 999 `
  --flash-attn on `
  --jinja `
  -c 260000 `
  -t 12 `
  -b 1024 `
  -ub 512 `
  --cache-type-k q8_0 `
  -cache-type-v q8_0 `
  --mlock `
  --host 127.0.0.1 `
  --port 8080

KV Cache 使用 q8_0 精度，显存影响可控。Agent Token 输出速度约 29~35 tokens/s。

VSCode Copilot 参数配置：

模型版本	temperature	top_p	top_k	min_p	frequency_penalty	presence_penalty	repetition_penalty
NVFP4-MTP	0.7	0.95	30	0.06	0.5	0.3	1.05
Q4_K_M	0.7	0.95	30	0.06	0.05	0.0	1.16

接入验证：

使用 Prompt："修复上一版 2048 游戏的 Bug 并美化界面"。Ornith 具备较强的代码理解与修复能力，可改善部分逻辑，但仍遗留边界条件缺陷。假死现象偶有发生，但多数场景可自动恢复。

---

2.3 Qwen3.6-27B 全量上下文运行方案

针对 16 GB 显存难以同时容纳稠密模型权重与 160K KV Cache 的瓶颈，本方案采用进一步量化的 IQ4_XS 版本，并配合定制版推理引擎。

启动命令：

# 关闭非对称自动切换
$env:TURBO_AUTO_ASYMMETRIC=0

C:\Users\Megatron\Downloads\turboquant-plus-tqp-v0.3.0-windows-x64-cuda12.4\llama-server.exe `
   -m "D:\Caches\Models\Qwen3.6-27B-abliterated-i1-IQ4_XS.gguf" `
   -c 160000 `
   -ngl 999 `
   -fa on `
   -t 8 `
   -b 1024 `
   -ctk turbo4 `
   -ctv turbo4 `
   -np 1 `
   --jinja `
   --port 8080

资源表现：

• 输出速度：约 25 tokens/s
• GPU 温度：室温 28°C 环境下，负载后直冲 67°C
• 并发限制：-np 1 为单并发。若增加并发参数，速度骤降至 ~10 tokens/s，不适合作为 Agent 调度基座。

---

0x03 缘由

资源调度与 MoE 优势分析

MoE 模型通过动态激活少量专家网络，将非活跃路径的计算卸载至 CPU。在本文硬件中，表现为：

• 显存压力显著降低：16G 显存可容纳 35B 级模型权重，并留出充足空间供 KV Cache 使用（支持 260K 上下文）。
• CPU 满载换取吞吐：AMD R5 7500F 承担路由与未激活专家计算，CPU 占用率接近 100%，但 GPU 温度与显存利用率保持健康区间。
• 并发友好：MoE 架构天然适合多轮对话与工具调用，输出延迟稳定在 30~35 t/s，满足本地 Agent 的交互节奏。

稠密模型的局限性

Qwen3.6-27B 全量运行时，权重与 KV Cache 竞争显存。即使采用 IQ4_XS 量化，仍只能支撑单并发。增加并发数会引发显存交换或队列阻塞，导致生成速度断崖式下降。此外，高负载下 GPU 温度快速攀升至 67°C，长期运行对散热提出更高要求。

参数调优逻辑

编程 Agent 对逻辑一致性要求高于创意发散。因此：

• temperature 控制在 0.5~0.7，平衡代码严谨性与生成灵活性。
• min_p 与 top_k 组合截断低概率噪声词，减少语法错误。
• repetition_penalty 设为 1.05~1.16，抑制死循环与模板化输出。
• frequency_penalty 与 presence_penalty 微调和，鼓励模型引入新变量与结构，避免陷入局部最优解。

常见现象说明

• 假死/复读 ：多因 top_p 或 min_p 设置过严，导致词分布坍缩。适当放宽阈值或重启服务可恢复。
• 代码含 Bug：当前开源模型在复杂逻辑推理与多文件依赖追踪上仍存短板。建议将模型定位为"初稿生成器"，关键逻辑交由人工审查或接入外部验证工具。

---

0x04 结论

1. MoE 架构是本地编程 Agent 的首选。在 RTX 5060 Ti 16G 平台下，35B 级 MoE 模型可兼顾高上下文、高并发与稳定吞吐，是构建本地 Copilot 基座的最优解。
2. KV Cache 量化需权衡精度与显存 。q4_0 适用于极端显存受限场景，q8_0 在保持吞吐的同时显著降低长上下文下的精度损耗，建议根据任务长度动态切换。
3. 稠密模型适合深度推理，不适合高并发 Agent。27B 稠密模型需完整显存支撑，并发能力弱，更适合离线分析或单轮长文生成。
4. 参数调优需结合任务特性 。编程场景应优先保证逻辑连贯性，适当抑制随机性。死循环现象可通过调整 min_p 与 repetition_penalty 缓解。

本地部署 AI 编码助手是一场在算力、精度与延迟之间的精密平衡。本文记录的配置与参数可作为同类硬件环境的参考基线，实际效果请结合具体代码库与工作流进行微调。

---

0x05 参考

• HuggingFace 模型仓库（Qwen3.6-35B-A3B / Ornith-1.0-35B 系列）
• 部署参考视频：https://v.douyin.com/ROJQs0qf9Tk/
• Qwen3.6-27B 量化调试思路：https://blog.51cto.com/u_17705236/14585829
• llama.cpp 官方文档：https://github.com/ggerganov/llama.cpp
• OpenAI API 推理参数规范：https://platform.openai.com/docs/api-reference/chat/create

---

0x06 后记

"工欲善其事，必先利其器。"

------《论语·卫灵公》

本文所记录的环境配置、启动参数及性能数据均来自真实硬件调试，文字内容由 AI 协助结构化整理。由于本地推理涉及模型版本、驱动兼容性及个人工作流差异，请读者结合自身环境验证参数，并注意甄别极端情况下的系统稳定性。

0x07 手稿

上述内容是由本文提到的本地运行的Qwen-3.6-35B-A3B生成的, 原始手稿如下:

题目: 5060Ti 16G 本地部署 260K上下文Qwen-3.6-35B-A3B与Ornith-1.0-35B模型与VSCode Copilot本地模型编码参数调优记录

硬件:
cpu AMD R5 7500F
gpu rtx 5060ti 16g
ram 48G ddr5

软件环境
win11
wsl2
llama.cpp cuda13.3 version  b10217-ddd4ec142

如果将模型集成到本地编程Agent中, 推荐MoE模型, 速度快, 并发量高, 且输出不慢大概35tokens/s, 如果使用Qwen3.6 27B模型的话, 160k上下文单个并发可以跑到25tokens/s, 显卡温度一路飙升到67度(室温28.5度)...
但是MoE模型由于将一些计算工作卸载给CPU, 导致CPU满载, 但是节约了显卡的能力, 留出了较大的上下文空间. 本文主要记录 Qwen, Ornith 这两款35B MoE模型在VSCode中作为 Copilot本地模型的启动命令以及参数调优以及记录160K上下文全量运行Qwen3.6 27B模型的启动方法.

当然, 本博文又作者写初稿, 本地的Qwen-3.6-35B-A3B完成最终的终稿.

1. Qwen-3.6-35B-A3B折腾记录
这个模型要作为编程Agent作为本地用, 这个模型使用的NVFP4量化版本的模型文件, 名称为: Qwen3.6-35B-A3B-NVFP4-Fast.gguf, 在hugging face中可以拉取到. 启动命令为如下:
llama-server `
   -m "D:\Caches\Models\Qwen3.6-35B-A3B-NVFP4-Fast.gguf" `
   -ngl 99 `
   --n-cpu-moe 999 `
   --flash-attn on `
   --jinja `
   -c 260000 `
   -t 12 `
   -b 1024 `
   -ub 512 `
   --cache-type-k q4_0 `
   --cache-type-v q4_0 `
   --mlock `
   --host 127.0.0.1 `
   --port 8080

这个会吃36G左右的内存, 与8G左右的显存, 12G显存也能够够用, 这个配置方式来源:  https://v.douyin.com/ROJQs0qf9Tk/ , 确实好用. 实测输出35tokens/s.

这个模型若配置到VSCODE(version 1.131)中, 需要下载OAI Compatible Provider for Copilot插件, 然后配置好本地的地址, 例如我写的baseurl:http://127.0.0.1:8080/v1. 然后选择对应的模型就可以.
这个模型表现优秀, 能够正确调用各种tools, 但是有时候会陷入局部最优解, 不断进行死亡循环, 进行复读机式的输出.....
下面记录我用的参数:
Context Length:128000
Max Tokens:12800
T:0.5
TopP:0.87
TopK:17
MiniP:0.02
Frequency Penalty: 0
Presence Penalty:0.1
Repetition Penalty:1.05

coding任务是让其自动的写一个2048的游戏, 最终写出了一个华丽的Bug百出的Vue项目游戏, .... 
假死也常有....
期望有大神能够给出更好用的参数
但是, 听说Ornith 的编程能力很强, 下面记录Ornith的折腾记录

2. Ornith-1.0-35B折腾记录
这次模型文件有两个, 一个是NVFP4量化版本, 另一个是Q4KM量化版本, 实际使用没有感觉太明显的不同... 似乎NVFP4更节省显存, 但是假死两个也都假死... 模型名称如下:
Ornith-1.0-35B-NVFP4-MTP.gguf
ornith-1.0-35b-Q4_K_M.gguf

这两个模型依旧拥抱脸能够下载, 启动参数如下:
llama-server `
  -m "D:\Caches\Models\Ornith-1.0-35B-NVFP4-MTP.gguf" `
  -ngl 99 `
  --n-cpu-moe 999 `
  --flash-attn on `
  --jinja `
  -c 260000 `
  -t 12 `
  -b 1024 `
  -ub 512 `
  --cache-type-k q8_0 `
  --cache-type-v q8_0 `
  --mlock `
  --host 127.0.0.1 `
  --port 8080

这里kv cache用了q8的量化精度, 对于显存的占用也不明显, 没有尝试fp的精度, agent token输出速度大概30左右(29~35 t/s), 下面是OAI的参数:
2.1 Ornith-1.0-35B-NVFP4-MTP.gguf
Context Length:128000
Max Tokens:12800
T:0.7
TopP:0.95
TopK:30
MiniP:0.06
Frequency Penalty: 0.5
Presence Penalty:0.3
Repetition Penalty:1.05

这个参数调了很久, 实测还是会出现假死, 心累了.... 但是出现假死很多情况下还能活过来, 很神奇..... 这个模型是让其修复之前Qwen写的Bug并美化界面, 结果修的还行, 还是有Bug.....

2.2 ornith-1.0-35b-Q4_K_M.gguf
Context Length:128000
Max Tokens:8192
T:0.7
TopP:0.95
TopK:30
MiniP:0.06
Frequency Penalty: 0.05
Presence Penalty:0
Repetition Penalty:1.16

这个参数也可以, 这个出现的假死情况要比1.1的情况好一些, 但是也是一般吧, 能用, 能自动跑起来

这个2048游戏最终用的DeepSeek V4 Flash给修bug了,花了4百万tokens, 0.34CNY .... 还是都是Bug, 但是接入这个模型是真TM的快, ....., 真TM舒服.... 这个硬件配置下自动化的写代码, 太折磨了, 关键我还得给电脑开空调, 我服了.... 主要是折腾乐趣吧

3. Qwen3.6-27B-abliterated-i1-IQ4_XS 本地全量运行
这是在本地运行一个进一步量化的Qwen3.6-27B的模型, 原始模型能够被显存塞下,但是没有太多空间给kv cache, 但是这个版本的模型进一步量化,留出了一些空间支持更大的上下文空间
模型名称:Qwen3.6-27B-abliterated-i1-IQ4_XS.gguf, 拥抱脸能够下载, 调试思路参照: https://blog.51cto.com/u_17705236/14585829


启动代码示意:
# 依然先确保关闭自动升级
$env:TURBO_AUTO_ASYMMETRIC=0

C:\Users\Megatron\Downloads\turboquant-plus-tqp-v0.3.0-windows-x64-cuda12.4\llama-server.exe `
   -m "D:\Caches\Models\Qwen3.6-27B-abliterated-i1-IQ4_XS.gguf" `
   -c 160000 `
   -ngl 999 `
   -fa on `
   -t 8 `
   -b 1024 `
   -ctk turbo4 `
   -ctv turbo4 `
   -np 1 `
   --jinja `
   --port 8080

这个能够跑到25token/s, 非常得劲虽然不快, 但是GPU温度上升很明显,45°直扑67° (室温28度), 心疼gpu没有太折腾, 但是据说这个稠密模型质量很高, 还要进一步搞搞. 不过这个模型不推荐用来作为编程agent, 因为如果修改参数np增加并发量, 速度会到10tokens/s.... 不太适合并发...

以上就是主要手稿内容

跑路了...

期待有大神能够给一套参数, 让这个东西不死机...

多参数优化问题好麻烦, 手动调参好麻烦...

不过, 是否使用某种算法对模型参数自动调参, 或许是一个很好的课题.