Qwen3.6-35B-A3B 越狱版本地部署：无审查 GGUF、llama.cpp 与安全边界

零度博客最近介绍了一款热度很高的本地模型：Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive。原文把它称为“越狱版”“无审查”开源模型，并给出了 GGUF 量化包、llama.cpp 启动方式和 Agent 对接思路。

这类模型值得关注，但更适合冷静理解：它的重点不只是“限制少”，而是把几个本地 AI 关键能力放到了一起：

MoE 架构下的 35B 级模型。
GGUF 量化后可在消费级显卡上运行。
通过 llama.cpp 提供 OpenAI API 兼容接口。
搭配 mmproj 支持多模态视觉输入。
可以接入 Hermes、OpenClaw 等本地 Agent 工具。

如果你关心本地模型，这篇更值得看的不是“越狱”噱头，而是它代表的趋势：本地模型正在从“能聊天”走向“能接入工具、能看图、能做 Agent 后端”。

这个模型是什么

原文提到的模型全名是：

1

Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive

从名字可以拆出几个关键信息：

Qwen3.6：基于 Qwen 系列模型。
35B：总参数规模约 35B。
A3B：每次推理激活参数约 3B，属于 MoE 思路。
Uncensored / Aggressive：经过更少安全限制或更激进风格调整的版本。
GGUF：面向 llama.cpp 等本地推理工具的量化格式。

这里要特别注意：Uncensored 并不等于“更可靠”。它通常意味着模型更少拒答，也更可能生成不受约束、未经事实核验或有风险的内容。对技术研究来说可以实验，但不适合直接接入公开服务、生产系统或无人值守任务。

为什么 35B 模型还能在本地跑

很多人看到 35B 会以为必须用服务器或高端多卡机器。原文强调的关键点是：这个模型采用 MoE 架构。

MoE 可以简单理解为：模型总参数很大，但每次推理不会激活全部参数，而是只激活其中一部分专家。原文称它每次实际运行大约激活 3B 参数，因此在一定量化下，速度和显存压力会比传统 dense 35B 模型低很多。

再叠加 GGUF 量化后，它就有机会在消费级显卡上运行。原文提到最小量化版本约 11GB，6G/8G 显存也能尝试，但更建议至少 8G 显存。

更现实的理解是：

6G 显存：可以尝试低比特量化，但上下文和速度都要降低预期。
8G 显存：更适合入门测试，建议选更小量化。
16G 显存：体验会明显宽松，适合更长上下文和更多 GPU offload。
24G 显存：更适合 Q4_K_M、Q4_K_P 这类质量更好的量化版本。

本地模型能不能“好用”，不能只看能不能启动，还要看上下文长度、生成速度、显存余量、KV cache、是否启用多模态、并发需求和实际任务类型。

llama.cpp 部署思路

原文推荐使用 llama.cpp，原因是它支持 Windows、Linux、macOS，也支持 NVIDIA CUDA、AMD、Intel、Vulkan 和纯 CPU 等多种后端。

一个典型启动方式类似：

1
2
3
4
5
6
7
8
9


llama-server.exe ^
  -m "模型路径.gguf" ^
  --mmproj "mmproj.gguf" ^
  -ngl 999 ^
  -c 131072 ^
  -n 8192 ^
  --host 127.0.0.1 ^
  --port 8080 ^
  --jinja

几个参数值得单独理解：

-m：主模型 GGUF 文件路径。
--mmproj：多模态投影文件，启用视觉能力时需要。
-ngl：尽量把层 offload 到 GPU，具体效果取决于显存和后端。
-c：上下文长度，越大越吃内存和显存。
-n：单次生成 token 上限。
--host 127.0.0.1：只监听本机，安全性比暴露公网高。
--port 8080：本地 API 服务端口。
--jinja：新版 Qwen 模型常需要正确聊天模板，否则可能出现格式错乱、重复或中文异常。

这里最容易踩坑的是上下文长度。-c 131072 看起来很诱人，但长上下文会显著增加 KV cache 占用。低显存机器不建议盲目拉满，应该先用较小上下文跑通，再逐步增加。

多模态能力怎么用

原文提到这个版本支持多模态视觉识图，可以分析图片、截图、OCR、复杂 UI 和代码截图。

在 llama.cpp 里，多模态通常需要主模型和 mmproj 文件配套。没有正确加载 --mmproj 时，前端里的图片上传能力可能不可用，或者模型无法正确理解图像。

多模态本地模型的实用场景包括：

分析截图里的 UI。
OCR 识别图片文本。
阅读代码截图或报错截图。
给本地 Agent 提供视觉输入。
在不上传云端的情况下处理隐私图片。

但它也有边界：视觉理解不等于严格 OCR，不适合作为唯一事实来源。涉及账单、合同、证件、医疗图像等高风险内容时，仍然需要人工复核。

OpenAI API 兼容接口

llama.cpp 的 llama-server 可以提供类似 OpenAI API 的本地接口。原文给出的本地 base URL 是：

1

http://127.0.0.1:8080/v1

这意味着很多支持自定义 OpenAI-compatible provider 的工具，可以把请求转到本地模型上。API key 通常可以随便填一个占位值，具体取决于客户端是否强制校验。

这类能力的意义很大：

不需要云端 API key。
不产生按 token 计费。
数据可以留在本机。
可以接入本地 Agent、代码助手或聊天前端。
可以作为 OpenAI API 的本地替代后端做实验。

但不要把本地接口直接暴露到公网。即使模型在本地，API 一旦开放到局域网或公网，也可能被别人滥用，导致机器资源被打满，甚至让模型输出你不希望生成的内容。

对接 Hermes 和 OpenClaw 的意义

原文提到，将这个本地模型接入 Hermes 或 OpenClaw，才能真正体现它的价值。

这句话的意思是：模型本身只是推理核心，Agent 工具才负责把它接到真实任务里。比如：

写代码。
调用工具。
读取文件。
分析图片。
联网搜索。
执行多步骤任务。
维护长上下文工作流。

本地模型如果只用来聊天，价值有限；如果能稳定作为 Agent 后端，才更接近“本地 AI 工作站”。

不过，无审查模型接入 Agent 时要更谨慎。Agent 能操作文件、运行命令、访问网页、调用工具时，模型的输出会转化为真实动作。模型越少限制，越需要外层权限控制、人工确认和审计日志。

无审查模型的风险边界

这类模型最大卖点通常是“少拒答”。但少拒答也意味着更大的风险。

需要注意几件事：

它可能更容易输出违法、危险或误导性内容。
它可能不会主动提醒安全边界。
它可能在高风险问题上给出过度自信的建议。
它可能被提示词诱导执行不合适的任务。
它不适合直接面向公众开放。

更稳妥的做法是：

只在本机或受控局域网内测试。
不把它接入高权限工具。
不让它自动执行删除、支付、发帖、批量提交等不可逆操作。
给 Agent 工具设置文件、命令、网络和浏览器权限边界。
对高风险输出保持人工复核。

换句话说，越是“自由”的模型，越需要外层系统约束。

适合谁尝试

这类模型适合以下用户：

想研究本地大模型部署的人。
有 8G 以上显存，愿意折腾 GGUF 和 llama.cpp 的用户。
想把本地模型接入 OpenAI-compatible 客户端的人。
关注本地多模态、截图分析和 Agent 后端的人。
想离线处理部分隐私数据的开发者。

不太适合以下场景：

完全不想调参数的新手。
需要稳定生产 SLA 的服务。
对安全合规要求高的团队。
需要严格事实可靠性的业务流程。
想把模型直接公开给外部用户的人。

简单结论

Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive 这类模型的出现，说明本地 AI 的能力边界正在快速往前推：消费级显卡可以跑更大模型，GGUF 量化让部署门槛下降，llama.cpp 让本地模型具备 OpenAI API 兼容接口，多模态和 Agent 工具又把它从聊天推进到任务执行。

但不要把它只理解成“越狱模型”。更有价值的角度是：本地 AI 正在成为可组合的基础设施。模型、推理引擎、API 服务、前端、Agent 工具、权限控制，会一起决定最终体验。

如果你要尝试，建议先从低风险本地测试开始：选合适量化，降低上下文长度，确认 --jinja 和 --mmproj 配置正确，再接入客户端。等稳定后，再考虑接入 Agent 工作流。

参考资料：

零度博客原文：https://www.freedidi.com/24284.html
llama.cpp GitHub：https://github.com/ggml-org/llama.cpp