从 RTX 3060 本地部署 Qwen，到折腾自己的网络安全 AI Agent

最开始折腾本地大模型，其实没想那么复杂。

无非是觉得云端模型的 Token 消耗有点快，尤其是平时做代码审计、Android 逆向，经常需要让 AI 阅读大量源码、追踪调用链，有时候一个任务跑下来，Token 就消耗了不少。

既然自己有一台还算不错的电脑，为什么不尝试把模型部署到本地？

最开始的想法很简单：本地部署一个大模型，再接入 Claude Code，尽量实现类似使用云端模型的编码体验。最好断网也能用，模型没有额外的订阅费用，想跑多久就跑多久。

但真正开始折腾之后才发现，部署模型只是第一步。

从模型选择、量化版本、显存分配，到上下文长度、专家缓存，再到 Agent 的任务调度，前前后后花了不少时间。中途也遇到过下载中断、启动失败、显存不足、API 超时等各种问题。

现在回头看，这次折腾最大的收获，反而不只是成功运行了一个本地模型，而是逐渐摸索出了一套适合自己日常安全研究的 AI 工作流。

这篇文章就记录一下整个过程。

一、先看看我的硬件配置

先交代一下硬件，不然很多后续的参数调整没有参考意义。

我的主机配置：

• CPU：Intel i5-12600KF
• GPU：NVIDIA RTX 3060 12GB
• 内存：128GB DDR4
• 硬盘：NVMe SSD
• 系统：Windows 11

这套配置有一个比较明显的特点：内存比较充足，但是显存只有12GB。

这也是后面调优过程中最大的限制。

本地运行大模型，并不是简单地看模型有多少参数。尤其是 MoE（混合专家）架构，模型的专家权重、KV Cache、推理过程中的临时显存，以及其他辅助模块，都会影响实际运行情况。

所以我一开始就没有考虑传统意义上的全量 GPU 加载，而是选择能够利用系统内存、SSD 和 GPU 协同工作的方案。

最终选择了 Strata。

二、为什么选择 Strata？

之前也看过 Ollama、LM Studio 等本地模型运行方案。

但这次的目标不是简单地运行一个聊天模型，而是希望尽可能发挥 MoE 模型的能力，同时利用有限的显存运行更大的模型。

后来找到了 Strata：

项目地址：https://github.com/Niko1221/Strata

它比较吸引我的地方是：

1. 支持 Windows 和 NVIDIA 显卡。
2. 可以利用系统内存和 SSD 存储专家权重。
3. 支持 GPU 专家缓存，可以根据显存情况动态分配。
4. 支持较长的上下文。
5. 提供本地 API，可以接入其他 AI 客户端。

对于我这种显存只有12GB，但系统内存有128GB的配置，比较合适。

Strata 的安装也没有想象中复杂。

下载项目后，通过 START-HERE.bat 启动，第一次运行会自动检查硬件、安装 Python 依赖、获取推理引擎，并根据选择下载模型。

模型下载完成后，还会进行相应的预处理，并下载 MTP（多 Token 预测）所需的辅助文件。

最后生成对应的启动配置。

正常启动后，本地 API 默认运行在：

http://127.0.0.1:8080

而且提供兼容 OpenAI 和 Anthropic 的接口，这意味着后续不一定非要使用 Strata 自带的聊天页面。

这一点对后续接入 Claude Code 非常重要。

三、先跑通原版，再折腾 Uncensored 版本

最开始我并没有直接上 Uncensored 版本，而是先使用原版 Qwen3.8-Flash-Next 的 IQ3_S 量化版本。

原因很简单：先确认整套环境能够正常运行。

如果一开始就同时折腾模型、量化、推理引擎和各种参数，出现问题后很难判断究竟是哪一部分导致的。

原版跑通之后，我开始尝试切换到 Uncensored 版本。

最终选择的是：

Qwen3.8-Flash-Next-GSQ-RCO-abliterated-IQ3_XXS

这个版本使用 IQ3_XXS 量化，模型文件分成两个 GGUF 分片。

这里有一个需要注意的地方：IQ3_XXS 并不是说模型只需要3GB显存，而是量化方案。实际运行时仍然需要处理大量专家权重，只不过可以通过 Strata 的内存和显存调度机制进行分配。

下载过程也不算顺利。

最开始使用 Hugging Face 下载，出现过 SSL 握手异常、Xet 下载中断等问题。有一次已经下载了几十 GB，最后还是因为连接问题中断。

后来又尝试调整下载方式、使用断点续传，以及 ModelScope 镜像等方案。

这里就不展开每次下载失败的细节了，反正最终还是把模型文件完整准备好了。

但下载成功不代表就能正常启动。

Uncensored 版本还涉及模型预处理、Expert Profile、MTP 等组件的适配。中途出现过缺少参数、Verify 所需显存不足、专家缓存无法分配等问题。

尤其是 Expert Profile。

Strata 会根据专家路由信息建立 Profile，用于决定哪些专家更值得放进 GPU 缓存。

如果没有正确准备好相关文件，或者显存不满足要求，就可能导致启动失败。

这一阶段最大的经验就是：不要看到模型文件下载完成就认为部署结束了，真正复杂的是后面的推理引擎配置。

四、真正花时间的地方：上下文和显存调优

模型成功启动之后，才进入真正的调优阶段。

我最开始使用的上下文长度并不高，后面逐渐从32K调整到128K，再尝试提升到192K。

为什么这么在意上下文？

因为我的主要用途不是普通聊天，而是代码审计和逆向分析。

一个稍微复杂的 Java 项目，可能涉及大量 Controller、Service、Mapper、工具类和第三方组件。

如果上下文太短，AI 就需要不断压缩之前的分析结果，或者反复读取相同的文件。

对于长时间运行的审计任务来说，这会增加不少额外成本。

所以我希望尽可能提高上下文长度。

但问题也随之出现了。

上下文越大，占用的 KV Cache 就越多，而 RTX 3060 只有12GB显存。

Strata 的 GPU 显存不仅要放 KV Cache，还要考虑 MTP、推理缓冲区以及专家缓存。

这几部分都在竞争有限的显存。

我还专门尝试过让模型保持更多专家在显存中。

最开始看到专家缓存有两千多个，感觉运行效果不错。后来调整上下文后，专家数量有时变成500多个，有时又超过1000个。

一开始我还以为是不是模型出了问题。

后来才逐渐理解，这里显示的专家数量，并不是模型总共拥有多少专家，而是当前实际驻留在 GPU 缓存中的专家数量。

模型完整的专家权重仍然存在于其他存储层中。

GPU 缓存更多的专家，通常意味着更高的缓存命中率，减少从 PCIe 或其他存储层读取权重的次数，从而改善推理速度。

所以专家数量变化，不代表模型能力或者质量跟着发生了同等程度的变化。

它更多反映的是当前显存分配情况。

而且专家缓存并不是一个固定值。

每次启动时，Strata 都会根据当前可用显存、上下文配置、KV Cache 和其他模块的占用情况进行分配。

因此，即使使用相同的启动参数，如果后台还有其他程序占用显存，最终能够缓存的专家数量也可能不同。

我的最终调优方向

经过多轮调整，目前主要使用的配置包括：

• 模型：Uncensored IQ3_XXS
• 上下文：192K（196608）
• KV Cache：INT8
• Expert Cache：auto
• Prefill：auto
• MTP：开启，Spec 4
• PCIe Fraction：0.20
• Pool Workers：5
• Adapt Every：1
• Adapt Swaps：80
• Adapt Decay：0.97

这里有几个参数值得单独说一下。

1. max-context

这个参数决定了上下文容量。

我从32K一路调整到128K，后面又尝试192K。

上下文越大，理论上能够容纳更多代码、历史分析记录和工具输出，但也会增加显存占用。

2. kv

我目前使用的是 int8。

Strata 还支持其他 KV Cache 精度，例如 q4_0。

降低 KV Cache 精度可以节省显存，但也需要考虑精度方面的取舍。

3. expert-cache

目前使用 auto，让 Strata 根据实际情况分配专家缓存。

对于12GB显存来说，手动追求一个固定的专家数量并不一定是最合理的方案。

4. pcie-frac 和 pool-workers

这两个参数也经过了多次调整。

前者涉及专家读取时的 PCIe 资源分配，后者影响专家池的工作线程数量。

目前保留的参数是在实际运行中逐步调整出来的，不是单纯照搬其他人的配置。

192K 上下文的代价

这里还要说一个非常现实的问题。

虽然最终能够将上下文提高到192K，但显存并不会因此变多。

模型运行时，RTX 3060 的显存占用经常达到11GB以上。

这意味着我基本上很难一边运行模型，一边正常玩大型游戏。

之前也遇到过 Strata 启动失败，日志直接提示没有足够的显存分配专家缓存。

当时排查下来，除了模型本身的占用，Windows 桌面、浏览器、其他应用也会占用一部分显存。

所以现在我已经接受一个现实：

12GB显存可以通过内存和 SSD 协同运行更大的模型，但并不意味着能够同时兼顾高上下文、大量 GPU 专家缓存和大型游戏。

这也是后面如果继续升级硬件，我会优先考虑更大显存显卡的原因。

五、接入 Claude Code，让本地模型真正参与开发

模型能够正常运行之后，下一步就是接入 AI 编码工具。

我之前一直比较习惯 Claude Code 的工作方式。

它不仅仅是一个聊天窗口，还能读取项目文件、执行 Shell 命令、编写代码、调用工具，并且可以通过 Skill 扩展工作流程。

所以我希望保留这套使用体验，只把背后的模型换成本地 Qwen。

Strata 已经提供了本地 API，因此核心思路就是：

Claude Code → 本地 API 接口/路由层 → Strata → Qwen

通过设置 Anthropic 相关的环境变量，例如：

• ANTHROPIC_BASE_URL
• ANTHROPIC_AUTH_TOKEN
• ANTHROPIC_MODEL

让 Claude Code 将模型请求发送到本地服务。

如果涉及不同 API 协议，也可以增加路由或协议转换层。

完成接入之后，就可以在原来的项目目录中使用 Claude Code，让它调用本地模型进行代码分析和开发。

这一步完成后，整个项目才真正有了实用价值。

因为我需要的并不是一个只能回答问题的本地聊天机器人，而是一个能够理解项目、操作文件、调用工具，并且持续推进任务的 Agent。

不过，这里也出现了一个新的问题。

六、长时间运行之后，我发现真正的瓶颈并不在模型

最初使用的时候，我遇到过不少奇怪的状态。

例如：

• Waiting for API response
• API Error: Server error mid-response
• Beaming...
• Reticulating...

有些任务运行一段时间后，会突然出现 API 超时。

尤其是当我调整 Clash 网络模式、关闭代理或者启动游戏前后，有时就会出现请求异常。

这里需要区分两件事。

本地模型推理本身并不需要访问公网，但 Claude Code 与本地 Strata API 之间仍然需要保持正常的本机通信。

如果代理配置、网络切换或客户端请求链路出现问题，仍然可能导致 API 请求中断。

所以，即使模型已经完全在本地运行，也不代表整个 Agent 工作流完全不受网络和客户端状态影响。

不过，随着后续不断调整，我发现了一个比网络问题更值得关注的事情。

真正的瓶颈，已经逐渐从模型推理能力转移到了 Agent 的任务管理和调度机制。

七、Skill 确实有用，但单模型架构下不适合盲目追求多 Agent 并发

这部分是我目前觉得最有价值的实践经验。

我平时主要使用本地模型做游戏逆向和 Web 后端代码审计。

这两类任务有一个共同点：任务链路很长。

例如一个逆向任务，可能需要：

1. 分析游戏程序集。
2. 定位关键函数和数据结构。
3. 编写 C# 探针程序。
4. 编译并运行探针。
5. 收集运行结果。
6. 根据结果继续修正分析。
7. 最后形成完整的分析报告。

其中有些步骤需要 AI 推理，有些步骤只是普通程序执行。

如果没有 Skill，模型很容易在复杂任务中遗漏步骤，或者反复尝试已经失败的方法。

所以我专门设计了面向代码审计和逆向分析的 Skill，把任务拆分、证据验证、工具调用和结果记录等流程固化下来。

效果比最初单纯让模型自由发挥好很多。

现在已经能够依靠 Skill 的引导，让本地模型持续推进几个小时的逆向和代码审计任务。

但是，随着任务变复杂，我也开始尝试多个 Agent 协作。

理论上，可以让主 Agent 拆分任务，再让几个子 Agent 分别负责不同的工作。

例如一个分析反编译结果，一个研究设备数据结构，一个编写验证脚本。

但实际运行后发现，我目前只有一个本地模型推理实例。

多个 Agent 最终还是要竞争同一个模型服务。

看起来是在并行分析，实际上模型推理请求仍然需要排队。

有时一个子任务还没完成，另一个任务已经开始等待；有时还会出现请求超时、重复启动任务等情况。

对于我目前的硬件和单模型架构来说，这种方式并不理想。

我现在更倾向于让主 Agent 负责整体分析，模型推理任务按照顺序执行，而不是为了追求多 Agent 数量强行并发。

八、一个很重要的经验：让脚本负责调度，不要什么都交给 Agent 判断

后来我逐渐调整了整个工作流。

以前的思路是：

主 Agent 分析任务 → 拆分多个子 Agent → 子 Agent 执行 → 主 Agent 等待结果。

现在更倾向于：

主 Agent 分析任务 → 生成执行计划 → 脚本负责启动和监控 → 确认任务完成 → 主 Agent 读取结果并继续分析。

为什么要这样调整？

举个实际例子。

假设 Agent 编写了一个 C# 探针程序，需要读取游戏目录中的 DLL，并进行数据结构扫描。

这个程序可能运行几十分钟，甚至几个小时。

其实这段时间不需要模型一直参与。

完全可以由 Python 或 PowerShell 脚本负责：

• 启动进程。
• 记录 PID。
• 检查进程是否存活。
• 监控输出文件。
• 设置超时时间。
• 获取退出码。
• 判断任务是否真正完成。
• 将结果交给主 Agent。

这样就避免了模型反复判断任务是否结束，也避免了因为长时间等待而浪费上下文。

还有一个细节：不要仅仅根据输出文件是否存在来判断任务完成。

最好同时检查进程状态、退出码、文件大小和结果内容。

否则可能出现进程还没有退出，但文件已经生成；或者进程已经异常结束，却留下了不完整的输出。

我现在越来越认可一个原则：

AI 负责思考和分析，脚本负责执行和调度。

尤其是安全研究这种长时间任务，确定性的程序比让 Agent 自己判断什么时候等待、什么时候继续可靠得多。

这并不是说 Agent 不需要自主决策，而是应该把适合程序处理的事情交给程序。

把模型的上下文和推理能力留给真正需要思考的部分。

九、目前这套本地方案，已经能做什么？

经过前面这些折腾，目前已经能够实现：

• 本地运行 Uncensored Qwen 模型。
• 使用较长上下文进行代码分析。
• 通过 Claude Code 调用本地模型。
• 使用 Skill 引导逆向和代码审计流程。
• 编写、编译并执行 Python、C# 等辅助程序。
• 通过脚本管理长时间运行的任务。
• 将中间结果保存到文件，避免全部依赖对话上下文。

对于我平时的工作来说，已经有比较实际的帮助。

尤其是一些需要反复读取文件、分析调用链、编写验证脚本的任务，本地模型可以持续参与整个过程。

当然，这并不意味着它已经可以完全替代云端模型。

本地模型的推理速度、复杂问题的分析能力，以及长任务中的稳定性，仍然需要结合具体任务验证。

而且，单模型推理实例仍然是目前最大的架构限制。

不过至少已经从最初的本地聊天，逐渐变成了一套能够参与实际安全研究的工作流。

十、下一步：从 Claude Code 转向 Pi Agent，自己开发网络安全专用 Agent

目前我已经开始考虑下一阶段的方向。

继续围绕 Claude Code 调整配置，当然也可以解决一部分问题。

但我越来越觉得，Claude Code 本身的工作流和 Agent 管理机制，并不完全符合我现在的需求。

即使后端模型已经换成自己的本地模型，客户端仍然有自己的执行逻辑、工具调用方式、子 Agent 管理和上下文处理机制。

本地模型不受某些云端模型内容限制，并不意味着客户端的所有限制也随之消失。

所以接下来准备先尝试开源的 Pi Agent。

项目地址：

https://github.com/badlogic/pi-mono

我希望先基于 Pi 熟悉它的 Agent 执行机制、工具系统和扩展方式，再逐步把之前积累的 Skill 和脚本调度体系迁移过去。

如果这条路能够跑通，后面就不打算仅仅停留在使用现成的 Agent 客户端了。

我更希望基于 Pi 自己开发一个网络安全专用 Agent。

它不需要像通用编程 Agent 一样什么都做，而是围绕实际安全研究场景设计。

例如：

Web 后端代码审计

自动分析 Spring Boot 等项目，定位入口、追踪调用链、识别危险函数，并结合实际代码和验证结果输出审计结论。

Android 逆向

围绕 APK、JNI、SO 文件进行分析，辅助定位签名校验、算法实现、关键函数和动态 Hook 点。

游戏逆向

针对程序集、数据结构、运行时探针等工作，建立一套可以持续执行和验证的分析流程。

自动化任务调度

把长时间运行的扫描、编译、探针和文件分析任务交给脚本管理，由 Agent 负责分析结果和决定下一步。

最终希望形成一套专门服务于安全研究的本地 AI 工作台。

当然，这些目前还只是下一阶段的计划，并不是已经实现的功能。

最后说几句

回头看这次折腾，最开始只是想节省一点云端模型的 Token。

后来从部署模型，到调整量化和上下文，再到接入 Claude Code、设计 Skill、解决长任务调度问题，整个方向已经发生了变化。

我现在反而觉得，本地部署模型只是基础，真正值得投入时间的是如何围绕模型构建一套可靠的工作流。

模型负责理解和推理，Skill 负责约束专业流程，脚本负责确定性执行，Agent 负责组织整个任务。

这几部分组合起来，才真正有机会在实际工作中发挥价值。

当然，12GB 显存还是有不少限制，单模型架构也无法满足我对多 Agent 并发的需求。

但至少已经证明了一件事：一台普通的消费级电脑，也可以通过合理的模型选择、推理优化和工作流设计，搭建一套真正能够参与逆向分析和代码审计的本地 AI 环境。

接下来准备从 Pi Agent 开始，继续折腾自己的网络安全专用 Agent。

这次就不只是部署模型了。

而是想真正做出一套自己能长期使用、能够不断扩展的工具。