
# 从跑通不可能任务到再提速50%的全参优化！你也可以这么设置: 4060 8G笔记本调通Qwen3.6-35B+c128k+agent tooling，好卡更要起飞~


>8GB 显存跑 35B 模型、128K 上下文，听起来像天方夜谭。但，选好模型量化版本，选好调试工具，选好全量参数，你就可以把4060调校到极致！本地Agent越来越近，就等我换机换卡了🤣~LOL


----

## 从懒得跟风到隐约兴起


还记得2025 年春节 DeepSeek-R1 面世爆火后，Ollama 迎来本地部署热潮，不少人尝试本地该模型。一时间，大家查资料、啃技术、安装调试、运行晒图，和今年的全球龙虾热潮有得一拼。

彼时模型量化本地部署需要亲自动手，而且繁琐之余，还运行卡顿。这也和前段时间的龙虾本地模型适配一样。

虽然而今的本地模型和Ollama的安装调试连接已全面迭代更新，更是随着模型一齐补齐 Agent 调用底层能力。但是，在同期想要实现工具调用、完整思维链推理与长效上下文留存却很难。

我也借助 Ollama 一键试跑过 Qwen3.5-9B、Gemma4 系列小模型，日常闲聊流畅丝滑，但8K、32K 上下文上限完全达不到 Agent 落地标准。完全跑不了。

当然，微氪党的设备也是大众消费级的：一台 Honor MagicBook，RTX 4060 Laptop 8GB，Intel Ultra 5 125H，24GB 内存。

直到 5 月 Qwen3.6 稠密版 27B、35B稀疏 MoE 架构先后开源，搭配同期扎堆上新的多款优质本地模型Gemma4全系列、新版 DeepSeek-R1 蒸馏一众高性价比选型，硬件门槛持续下探。再叠加 MTP、Unsloth、dFlash 等加速技术全面成熟，你可以明显感到热度和落地度在不断提升。

而同期全网各类实测测评层出不穷，印象很深还有一篇实测：M5 Max，在飞行全程断网环境下离线跑通超大参数量本地大模型，小参数本地部署的帖子更是落英缤纷。

我就暗暗感觉到，本地agent是个方向。

最后点燃这个火花的，当然是如今的智能体agent（龙虾/WB等）的普及，我是全程在WB上做的。省去了自己查资料、啃技术、调试安装，如今就靠想法和口喷，我这破机器也实现了不可能任务的幻想，真正的全参满血加强~


----

## 不可能的任务


行业基准结论：**纯 GPU 全加载、无优化，4060 8G 无法实现 35B+64K 上下文**。 因为原生硬件先天瓶颈（无任何优化前提下，理论不可行）

但是，最新三重底层技术优化后可以让它理论可行（**稀疏 MoE 架构 + 极致量化 + 缓存优化 + 内存卸载**）：


- RTX4060 8G：负责注意力计算、活跃专家、部分 KV 缓存（占用 7.2~7.8GB，不爆显存）

- 32GB + 内存：存放闲置专家权重 + 溢出 KV 缓存，内存当扩展显存，CPU 按需动态调度读写数据


**但是又但是，** 

落到！**笔记本电脑！128k上下文目标！内存只有24G！**：**这是行业公认边界，！无法落地场景！**

微氪党配置正是：一台 Honor MagicBook，RTX 4060 Laptop 8GB，Intel Ultra 5 125H，24GB 内存 （俺们支持国产）

但是又但是再但是，

我从三步大换装起步，从32K跑通到128K，再二轮迭代优化50%+，说真的，我自己也不敢相信的一天，跳脚得高兴。

是的，我也不敢相信，且听我慢慢道来>>>（没有下回分解，但我想好三次优化，下回，嘻嘻）


----

### 全量调优的震撼结果


评测设计的五个维度17个指标，真真实实全面大幅提升！


|维度数|包括|
|:-:|:-:|
|🚀 性能|5|短提示速度、长生成速度、提示处理、首字延迟、Agent 调用|
|⏱ 时间|2|启动(text)、启动(MTP)|
|💾 资源|3|VRAM 余量、系统内存、线程争抢|
|🔧 系统|2|进程优先级、MTP 推测解码|
|📊 能力|4|Draft 命中率、多模态支持、引擎、上下文|


|关键维度概览|调优前|调优后|提升|
|:-:|:-:|:-:|:-:|
|短提示速度|20.4 tok/s|**30 tok/s**|🚀 **+47%**|
|长生成速度|17.6 tok/s|**27.1 tok/s**|🚀 **+54%**|
|长提示处理(116K)|399 tok/s|**700 tok/s**|🚀 **+75%**|
|首字延迟|687 ms|**373 ms**|⬇️ **-46%**|
|启动时间(text)|21 秒|**3 秒**|🚀 **-86%**|
|MTP 推测解码|❌ 不可用|**✅ 稳定跑通**|🔬 突破|
|Agent 工具调用|20 tok/s|**30 tok/s**|🚀 **+50%**|

**所有测试均开启推理模式的，测试数值偏差可能源于冷热启动**

***17维度的全参优化表格，请见章节—— “但这还不是终点：引入MTP+全参调优再提 46%”**

就我这4060卡，看完你也可以做到的。我相信用更好的消费级显卡配置，更是起飞了！


----

## 起点：换血三板斧先跑通35B+c32K


因为**总结网上共识：**- 8GB VRAM 跑 7B Q4 → 上下文极限 **8K~16K**，32K 已是天花板。

Mission Impossible就从此起步。

### 第一板斧：选好模型策略——稠密小模型换稀疏大模型


**之前走过的弯路：**


|尝试过的模型|参数|上下文|结果|
|:-:|:-:|:-:|:-:|
|Qwen3.5-9b|小模型|调不高|❌|
|MiniCPM|小模型|调不高|❌|
|**Qwen3.6-35B-A3B**|**35B MoE**|**128K 成功**|**✅**|

**为什么大模型反而行？**

关键在 MoE（Mixture of Experts）架构。这个模型虽然总参数 34.6B，但推理时**每次只激活 3B 参数**（256 个专家中选择 8 个）。它的 VRAM 占用逻辑完全不同：


- **小稠密模型**（如 7B Q4）：模型本身占 ~4-5GB，全部加载，上下文=剩余 VRAM 的博弈

- **大稀疏模型**（35B MoE IQ3）：模型大部分通过 mmap 映射在系统内存，GPU 只放核心层（~3GB），上下文同样吃 VRAM 但**模型部分不跟你抢**


结果就是：**35B MoE 在 8GB 显卡上的上下文表现，反而比 7B 稠密模型更好。**

>核心公式：MoE 模型总参数量 ≈ 存储需求，但活跃参数量 ≈ 计算需求。VRAM 瓶颈在后者不在前者。


### 第二板斧：选好量化策略——Q4换UD IQ3


**之前：** 执着于 Q4_K_M和Q4_K_S之间的选择，认为"4-bit 以上才有质量"。

**现在：** 使用 **Unsloth Dynamic 2.0 IQ3_S**：


- IQ3_S = 3.4375 bpw（bits per weight），文件仅 12.7 GB

- UD（Unsloth Dynamic）通过逐层动态量化 + 重要性矩阵补偿精度

- 实际 MMLU 差距仅 2~4%，但省出 **4GB 磁盘 + 更多 VRAM 余量**


**经验教训：** 量化不是越高越好，**"够用且留有余量"才是目标**。多出来的 VRAM 给上下文，比给模型精度收益大得多。

附注：Agent调用上下文是首要考虑，因此后续KV量化，我反而选择8bit的精度，而不是通常4bit的压缩精度，这也是**模型量化策略和上下量化策略的平衡与协调**

### 第三板斧：模型工具进阶——和小白时的Ollama说bye


毫不客气的说，这是最重要的环节。

**本质上不是引擎换了**（Ollama 底层也是 llama.cpp），而是**控制权归还**了。


|控制维度|Ollama|
|:-:|:-:|
|上下文 `-c`|默认 2048，上限受限|
|并行槽位 `-np`|**隐藏不可调**|
|自动校验 `-fit`|❌ 不暴露|
|内存锁定 `--mlock`|❌ 不暴露|
|内存映射 `--no-mmap`|❌ 不暴露|
|KV Cache 压缩 `--cache-type`|固定 q8_0|
|跳过预热 `--no-warmup`|❌ 无法跳过|

**Ollama 的设计哲学：** "开箱即用，替你做好决定"。

对 95% 用户这是好事，但你的场景（8GB 显卡跑 35B 模型冲 128K）已经是**极限工况**，Ollama 的保守默认值成了天花板。

**原生 llama.cpp 的设计哲学：** "给你所有旋钮，风险自负"。

这让极限优化成为可能——`-fit off` 就是最典型的例子，Ollama 永远不会给你这个选项。

我们后续50%，全参调优全靠它！


----

### c32K起点成功配置和128K实测外推的失败


下载 b9536（CUDA 13.3 版）+ 配套 CUDA runtime DLL。核心参数设置如下：

```
bin\llama-server.exe ^
 -m "models\Qwen3.6-35B-A3B-UD-IQ3_S.gguf" ^
 --mmproj mmproj-BF16.gguf ^
 -c 32768 ^
 -ngl 999 ^
 --n-cpu-moe 35 ^
 --flash-attn on ^
 --jinja ^
 --host 127.0.0.1 ^
 --port 8080
```
**关键参数说明：**


- `--n-cpu-moe 999`：这是关键！它会将 MoE 架构中的专家层强制卸载到内存。

- `-ngl 35`：允许尽可能多的层卸载到 GPU。


正如前文所述，我们没有做做简单的粗暴的修改，就是上下文我们没有进一步量化，保持了默认的8bit，（没写类似- `--cache-type-k q4_0 ）。

**我们的第一次计算（-np auto=4，默认参数）：**


|组件|32K实测|128K等比外推|
|:-:|:-:|:-:|
|模型（GPU 部分）|3018 MiB|3018 MiB|
|KV Cache|340 MiB|1360 MiB (×4)|
|RS Buffer|251 MiB|251 MiB|
|计算缓冲区|258 MiB|258 MiB|
|mmproj（最坏情况）|—|1134 MiB|
|**总计**|**~3867 MiB**|**~6021 MiB**|
|RTX 4060 可用|7106 MiB|6630 MiB|
|**结论**|✅ 够|❌ 不够|

自动参数拟合（`-fit on`）验证了这个结论——128K + `-ngl 999` 被直接拒绝启动。


----

## 逐步攀升，进军128K：最简单的逻辑，最简单的调参


>**大 MoE 模型Unsloth Dynamic 2.0 的 IQ3_S省下来的 4GB，可以刚好给了 128K 上下文的**，这么好的机会，我一定要把握住


|尝试|参数|结果|原因|
|:-:|:-:|:-:|:-:|
|32K|默认|✅|初始基准|
|128K|-np auto(4)|❌|自动校验拒绝|
|96K|-np 2 + --no-warmup|✅|降并行槽位|
|128K|-np 1 + --no-warmup + -fit off + --no-mmap + --mlock|✅|**组合拳成功**|

### 📌 核心配置：六个参数把 128K 塞进 8GB


先上初步配置，再一个个拆：

```
-c 131072                     # 128K 上下文
-np 1                         # 单并行槽位
--no-warmup                   # 跳过启动预热
-fit off                      # 关掉自动校验
--no-mmap --mlock             # 禁 mmap + 锁内存
-t 12 -b 1024 -ub 128         # 线程 + 批处理
--cache-type-k q8_0           # KV Cache 压缩
--flash-attn on               # Flash Attention
```
这里面没有"神级参数"，每个都只省了一部分，但加起来刚好够用。

### 🔧 -np 1：省最多的一刀——来自最简单的逻辑


`-np` 控制的是并行槽位数。默认 auto 自动设为 4，但**本地死宅单用户**用根本不需要 4 个槽位。降到 1，KV Cache 直接缩小一半以上。这一步省了将近 1GB VRAM。

### 🔧 --no-warmup：省启动峰值


启动时模型会跑一次空推理解析预热，这一下能占 1~2GB 的瞬时 VRAM。加上 `-np 1` 已经足够，跳过它，代价只是第一次请求慢几百毫秒。

### 🔧 -fit off：让自动校验闭嘴


默认情况下，llama.cpp 启动时会检查"这组参数会不会爆显存"。如果觉得会爆，而且你又锁死了 GPU 层数（`-ngl 999`），它就拒绝启动。128K + 全 GPU 刚好在它的拒绝名单上。

但自动校验不知道我们已经用 `-np 1` + `--no-warmup` 省了 2GB+ 空间。关掉它，128K 顺利加载。Nvidia-smi 看还剩 977MB——确实紧，但没爆。

**注意**：`-fit off` 不是 `--no-fit`。正确的参数名是 `-fit off`。

### 🔧 --no-mmap + --mlock：解决性能隐患


启动日志里有一条提示：`tensor overrides to CPU are used with mmap enabled - consider using --no-mmap for better performance`。这是说模型通过 mmap 加载的部分和 CPU 计算之间有性能瓶颈。加上 `--mlock` 一起用，把模型锁在物理内存里，防止 Windows 把它 swap 到硬盘。


----

### 📌 初步效果：首次拿下时的性能


#### 128K 下的实际表现：


|场景|提示速度|生成速度|首字延迟|
|:-:|:-:|:-:|:-:|
|短问答（7 token）|29.5 tok/s|**20.4 tok/s**|373 ms|
|长分析（66 token）|**83.4 tok/s**|**18.4 tok/s**|792 ms|
|含图片多模态|125 tok/s|21.4 tok/s|—|

20 tok/s 的生成速度，日常对话和文档分析都够用。

#### Agent 能力


|测试|结果|
|:-:|:-:|
|单工具 weather API|✅ 正确输出 `tool_calls` 格式|
|双工具并行（机票+天气）|✅ 一次调用两个函数|
|思考链 (`reasoning_content`)|✅ 完整输出推理过程|
|复杂 JSON schema 解析|✅ 嵌套对象解析正确|

至此，不可能任务，已经初战告捷，没有关闭thinking，没有用Q4降低上下文质量，8G笔记本显卡+24G内存上，我们跑通了128K上下文的35BMoE模型！


----

## 但这还不是终点：引入MTP+全参调优再提 46%


20 tok/s 只是开始。下午我把网上能找到的所有参数配置审计了一遍，逐项测试，成功把速度推到**短提示 30 tok/s、长生成 25.7 tok/s，全维度提升 42~96%**。

### 线程分离 -tb 6


原理很简单：默认批处理和生成共用 12 线程，互相打架。改成 `-tb 6` 让它们各用各的线程。长生成 +25%，**整轮调优单个参数最大收益**。

### 批次翻倍 -ub 1408 + GPU轮询 + 批处理优先


物理批次从 256 翻到 1408，长提示处理从 399 飙到 **634 tok/s**。但这还不够——我又加了两个参数继续压榨：


- **`--poll 100`**：GPU 轮询模式，减少 CPU 等待 GPU 通知的延迟，大提示再快 **+4.5%**

- **`--prio-batch 3`**：批处理线程设为实时优先级，再快 **+5.6%**


两者合力，116K 超长提示冲到 **700 tok/s**，比最初快了 **75%**。满格128K首次处理从最早估测的 5.5 分钟压到了约 3 分钟。

为了找到这个甜点，我从1024到2048逐项测试了6个点位：


|配置|启动|短提示|长生成|结论|
|:-:|:-:|:-:|:-:|:-:|
|-b1024-ub512|✅|30|25.7|旧基线|
|-b1024-ub1024|✅|28|23.5|✅ 可用|
|**-b1280-ub1280**|✅|**30**|**25.7**|✅ 次优|
|**-b1408-ub1408**|✅|**26~31**|**27.1**|🏆 **甜点**|
|-b1536-ub1536|✅|26~31|24.8|✅ 可用|
|-b1792-ub1792|✅|31|21.3|⚠️ 生成降|
|-b2048-ub2048|✅|28|⏰ 超时|❌ 生成崩|

### MTP 推测解码


最难也最精彩的一个。Qwen3.6 内置的 MTP 头一次能预测多个 token，跳过自回归步骤。但 MTP 模型文件大 2GB、多了 753 个小张量，8GB VRAM 塞不进去。试了 5 次都失败，第 6 次找到关键组合：

```
--fit on --fit-target 1536     # 留 1.5GB 给 MTP 头分配
--spec-draft-n-max 2           # 只预测 2 个
不加 --mlock                   # 16GB 内存锁不住 15GB
```
打开后速度直接跳到 30 tok/s!!!，Draft 命中率 69%~100%。

### 解耦图像模型


为了换取给MTP模型需要新增的空间，我又去掉 mmproj（视觉模型），同时启动从 21 秒降到 3 秒。换之的是，整理成两个启动脚本：`run_qwen36-mtp.bat`（纯文本最优）、`run_qwen36-img.bat`（多模态，稍慢）。其实还有个纯text无mtp版，速度虽慢一点，但是它启动快，只要3秒。

### 其它调参优化


加上 `--prio 2`，进程优先级拉高，不被 Windows 抢。`--cache-ram 2048`，prompt cache 从 8GB 压到 2GB，释放 6GB 系统内存。再加上 `--poll 100`（GPU 轮询减少延迟）和 `--prio-batch 3`（批处理线程实时优先），大提示再提速 10%。`--no-host`（小显存上反而降速 ❌。

### 全维度提升一览


|维度|共识/起点|首次跑通|二调最终（vs首次）|关键参数|
|:-:|:-:|:-:|:-:|:-:|
|**模型**|❌ 不可能|IQ3_S|MTP IQ3_S|UD 动态量化+MTP|
|**引擎**|Ollama|llama.cpp|llama.cpp|底层全控制|
|**上下文**|256~512|128K ✅|128K ✅ 不变|`-c 131072`|
|**短提示**|—|20.4 tok/s|**30 tok/s 🚀 +47%**|MTP + `--spec-draft-n-max 2`|
|**长生成**|—|17.6 tok/s|**27.1 tok/s 🚀 +54%**|`-tb 6` + `-b 1408 -ub 1408`|
|**提示处理(96K)**|—|399 tok/s|**700 tok/s 🚀 +75%**|`-ub 1408` + `--poll 100` + `--prio-batch 3`|
|**首字延迟**|—|687 ms|**373 ms ⬇️ -46%**|`-ub` 累积提升|
|**启动(text)**|—|21s|**3s 🚀 -86%**|去 mmproj|
|**启动(MTP)**|—|21s|**16s ⬇️ -24%**|去 mmproj + fit 计算 + MTP 初始化|
|**VRAM 余量**|8GB 不够|紧|**+200MB ✅**|去 mmproj|
|**系统内存**|—|prompt cache 8GB|**2GB ✅ -75%**|`--cache-ram 2048`|
|**线程争抢**|—|混用 12 线程|**分离 ✅**|`-tb 6`|
|**进程优先级**|—|默认|**高 ✅**|`--prio 2` + `--prio-batch 3`|
|**MTP 推测解码**|❌ 不可用|❌ 未试|**✅ 稳定跑通 🔬**|`--fit-target 1536`|
|**Draft 命中率**|—|—|**短100% / 长72%**|MTP 头工作正常|
|**Agent 调用**|—|✅ 可用|**30 tok/s 🚀 +50%**|MTP 加速也作用于 agent|
|**多模态支持**|—|单一 bat|**双 bat 分离**|img 与 mtp-text 分离|
|**总体提升（短提示）**|—|20.4|**30 🚀 +47%**|17 个维度全面提升|


----

## 实测：链式多工具调用（核心场景，Agent 主力能力）


调完参数不做实测就是纸上谈兵。我让Workbuddy设计了一个 Agent 典型场景来验证真实表现，然后用Qclaw调用本次模型完成测试：

### 测试设计


用三份本地测试文件（两项目笔记 + 一月度统计表），要求模型分步完成：


1. 依次读取三份文件，提取各自内容

2. 整合对比两个项目的预算、周期、成果、待解决问题

3. 输出结构化简报


全程要求：分步执行，不得跳过步骤，不得编造数据。

### 实际表现 ✅


模型严格按"读A → 读B → 读统计表 → 整合输出"的顺序执行，每一步都真实调用了文件读取工具获取数据，没有跳步。整合输出时自动生成了五段式结构化简报：

![image.png](https://developer.qcloudimg.com/http-save/yehe-8749249/ab1cb2d0e059a987dcd13a0ff96bd767.png)


|维度|结果|
|:-:|:-:|
|工具调用流程|✅ 按顺序执行，不跳步|
|数据准确性|✅ 所有数值与源文件完全一致|
|整合逻辑|✅ 对比维度合理，差异提炼准确|
|输出格式|✅ 表格规整，无格式错乱|
|编造数据|✅ 无编造，全部可溯源|

WB评价，它还怀疑了一下，然后完全折服了：

![image.png](https://developer.qcloudimg.com/http-save/yehe-8749249/efe0720368b8584c4bfe65eb67da7c64.png)

![image.png](https://developer.qcloudimg.com/http-save/yehe-8749249/3aeda6b0aadb564ce9678acd0c57eb2e.png)

生成速度体感流畅（约 30~40 秒完成全套流程），得益于 MTP 推测解码在整个 Agent 调用周期中持续生效，没有出现反复重算降速的问题。

测完这把心里就有底了——这配置不只是跑分好看，实际干活也一样稳。

4060 8G的显卡上，本地Agent上线啦~


----

## Afterword


从"8GB 不可能"到 30 tok/s，从 Ollama 默认参数到 17 个维度全部调满，从被网上共识劝退到把 MTP 的 753 个张量硬塞进显存——这一天下来，我自己回头看也有点恍惚。

其实没有什么"神级参数"。每个改动都只推了一点点边界：`-np 1` 省一点、`--no-warmup` 省一点、`-tb 6` 快一点、`-ub 1408` 再快一点……每一个百分比都是挤出来的。MTP 更是试了 5 次才找到那把对的钥匙。

最让我意外的是 MoE 模型本身——越是大模型，在某些维度上反而比小模型更友好。35B 的稀疏架构在 8GB 上竟然跑得比 7B 稠密模型还欢。这大概是今天最大的认知刷新。

当然还有没做完的事。TurboQuant 的 KV 压缩、多模态+reasoning 的 token 预算问题、以及 BeeLlama 分支上那些更激进的加速方案，都列在"第三轮优化"的清单上了。但那是因为极限永无止境，不是今天做的还不够。

所以你要是有张差不多的卡，别被网上的"不可能"吓住。下个 llama.cpp，拉个 GGUF，把上面的参数一行行敲进去——你会惊讶于手里这台机器能做到什么程度。

本地Agent，这个方向越来越近了。


----

模型：Qwen3.6-35B-A3B-UD-IQ3_S（Unsloth Dynamic 2.0） | 框架：llama.cpp b9536 | 启动脚本：run_qwen36.bat | 时间：2026-06-06



8GB 显存跑 35B 模型、128K 上下文，听起来像天方夜谭。但，选好模型量化版本，选好调试工具，选好全量参数，你就可以把4060调校到极致！本地Agent越来越近，就等我换机换卡了🤣~LOL

原创—从跑通不可能任务，到再提速50%的全参优化！你也可以这么设置: 4060 8G笔记本调通Qwen3.6-35B+c128k+agent tooling

人工智能

硬件

开发工具

4060显卡8GB显存也能跑通35B大模型+128K上下文！通过MoE架构、极致量化和缓存优化，实现短提示30tok/s、长生成27.1tok/s的性能飞跃。本地Agent工具调用和多模态支持全面突破，消费级硬件也能玩转大模型推理。

配置审计

内存映射

智能体

Windows

Agent

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

原创—从跑通不可能任务，到再提速50%的全参优化！你也可以这么设置: 4060 8G笔记本调通Qwen3.6-35B+c128k+agent tooling-腾讯云开发者社区-腾讯云

原创—从跑通不可能任务，到再提速50%的全参优化！你也可以这么设置: 4060 8G笔记本调通Qwen3.6-35B+c128k+agent tooling

原创—从跑通不可能任务，到再提速50%的全参优化！你也可以这么设置: 4060 8G笔记本调通Qwen3.6-35B+c128k+agent tooling

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐