Apple Silicon 上的 Qwen3.8-27B-Uncensored-MLX：如何选择构建版本、在 LM Studio 或 mlx-vlm 中加载，并驾驭 262K 上下文

关于orcarouter/Qwen3.8-27B-Uncensored-MLX，最需要知道的一点是：你无需选择子文件夹即可运行它。OrcaRouter 为 Apple Silicon 打造的 abliterated 版 Qw​en/Qwen3.8-27B——于 2026 年 8 月 17 日发布到 Hugging Face，所以它并不新，只是缺少文档记录——在仓库根目录保留了一份 4-bit 构建副本，特意为了让那些将一个仓库视为一个模型的工具（尤其是 LM Studio）无需任何配置就能加载它。正是这一决定，让这张模型卡在过去一个月获得了约 83,000 次下载，而同类 MLX 转换版只能获得其中很小一部分。其余一切都是真正的选择：四种精度中哪一种适合你 Mac 的统一内存，你使用哪个运行器，视觉与工具调用在你的位宽下能否保留，以及 262,144 token 的上下文窗口在你的硬件上是否物有所值。本操作手册按顺序逐一讲解这些决策。这是第一方文档——下文的大小、精度和保真度数据均为 OrcaRouter 在这款具体构建上自行测得的，所有社区数据也都明确标注为社区来源。

这个仓库里到底有什么？

这是 Qw​en/Qwen3.8-27B 的一个 abliterated 构建——一个270亿参数的稠密混合注意力模型（Gated DeltaNet线性注意力加全注意力），原生支持视觉语言，具备思考控制、工具调用、多令牌预测（MTP）头，以及262,144个令牌的上下文窗口。Abliteration 通过将拒绝方向从残差流中正交化来消除模型的拒绝行为；如果你对此不熟悉，我们关于该技术的入门指南比本页更适合作为起点，本页讲的是如何运行该构建，而非方法本身。权重采用 Apache-2.0 许可证，继承自基础模型。

不要将此仓库与 qwen-3-8-27b-mlx 混淆，后者是同一基础模型的 MLX 格式版本但没有进行 abliteration 处理。读者经常想下载其中一个却错拿另一个：本仓库是移除拒答机制的研究构建；那个则是适用于 Apple Silicon 的普通 Qw​en/Qwen3.8-27B。下载前请先核对仓库名称，以免白费下载时间。

有一个结构细节比看上去更重要：视觉塔、所有归一化层和线性注意力的 conv1d 都保持 BF16，而只有语言模型的线性层——包括embed_tokens和lm_head——被量化。这就是图像理解能力在量化后依然能保留的原因，也是为什么下文列出的磁盘大小比简单的“27B at N bits”估算要略大一些：模型有一部分从未被压缩。

决定：哪种构建适合哪款 Mac

四种精度以子文件夹形式提供——8-bit/、6-bit/、4-bit/、2-bit/——均为组大小为64的MLX仿射量化。4-bit版本额外在仓库根目录提供镜像。优先考虑Mac统一内存，其次考虑质量：

• 8位 — 磁盘占用约27.5 GB，需要配备64 GB内存的Mac（32 GB内存的机器也能加载，但留给其他程序的空间所剩无几）。与BF16源模型相比，实测余弦保真度为0.9997，实际上接近无损。当质量是首要追求且内存充裕时，选择此版本。

• 6位 — ~22 GB，适合 24–32 GB 的 Mac。保真度 0.9996，非常出色。对于大多数 48 GB 机型用户来说，这是每 GB 质量的最佳平衡。

• 4-bit——约 15 GB，在 24 GB Mac 上毫无压力。保真度 0.996，非常好。这是我们推荐的默认选项，正因如此，它就是仓库根目录中的那个版本。

• 2-bit — 约 8.7 GB，可装入 16 GB 的 Mac。保真度 0.92，且在 27B 规模下严重降级：重复循环、文本乱码、代码和中文混乱、视觉部分缺失。卡片上写得很清楚——仅限存档，不适合实际工作。16 GB 的 Mac 技术上可以加载它，但这并不意味着它可用。

磁盘占用大小并不等于内存占用。权重必须与 macOS、KV 缓存以及 Metal 的暂存缓冲区一起容纳在统一内存中，因此要留出余量。社区在配备 32 GB 内存的 M1 Pro Mac 上运行 4-bit 版本时测得：磁盘权重约 16 GB，但推理峰值达 18.5–21.7 GB；社区对 8-bit MLX 构建的测试报告显示，即使权重约为 29.5 GB，峰值也达到约 34–36 GB。来自同一社区测试的实用建议是：对于 27B 模型，16 GB 内存并非真正可选；24 GB 可在短上下文下尝试 4-bit；32 GB 才是舒适的起点。我们的 VRAM 规划文章对全系列型号给出了相同的计算。

由于仓库中所有精度的文件总计约 94 GB，请仅使用以下命令下载你需要的子文件夹：hf download orcarouter/Qwen3.8-27B-Uncensored-MLX --include "4-bit/*" --local-dir ./Qwen3.8-27B-Uncensored-MLX——将其中的精度替换为你所选择的即可。根目录下的 4-bit 副本与 4-bit 子文件夹内容重复，因此无需同时获取两者。

路径一 — LM Studio，零配置

根目录下的 4-bit 副本之所以存在，正是为了让 LM Studio 可以将整个仓库视为一个模型。搜索模型 ID，选择你想要的精度（根目录副本为 4-bit），应用会处理其余部分。三个注意事项，全部来自我们的卡片，它们就是这件事成功与失败的全部区别：

• 该仓库设有访问限制。匿名下载会返回 HTTP 401 错误。请先在模型页面上接受条款，然后将 Hugging Face 读取令牌粘贴到 LM Studio 的设置 → 集成 → Hugging Face 中。跳过此步骤，加载就会失败。

• 关闭 KV cache 量化。MLX 视觉模型在此架构上不支持该功能，如果启用，初始化期间加载会失败（跟踪记录为 mlx-engine#286）。这与针对 GGUF 构建的建议相反，在 GGUF 构建中，量化 K/V 缓存是一种合理的 VRAM 节省方式——这两种格式在此处不可互换。

• 更新运行时。 qwen3_5 架构支持已落地于 mlx-vlm 0.6.x；较旧的捆绑运行时根本无法加载这些权重。相比之下，LM Studio 的“Likely too large”标记仅表示内存警告，并非错误——如果你的统一内存满足前述指导要求，请忽略它。

在 LM Studio 中该选择哪种精度：8-bit 精度占用约 29.5 GB 磁盘空间，需要 64 GB 内存的 Mac；6-bit 精度约 22 GB，适合 48 GB 内存的机器；4-bit 精度约 16 GB，是 32 GB 内存 Mac 的正确选择。如果你希望在其它硬件上使用 llama.cpp / Ollama 路线，我们关于无审查模型的本地运行指南会单独介绍该路径。

路径二 — 从子文件夹加载 mlx-vlm 和 mlx-lm

命令行方式可直接提供精确控制，并附带一个与 Open​AI 兼容的服务器，用于代理工具。要求：pip install -U mlx-vlm（mlx-vlm ≥ 0.6.13 且 mlx ≥ 0.32；在 Apple Silicon 上会自动选择 Metal 后端）。完成上述子文件夹下载后：

python -m mlx_vlm generate --model ./Qwen3.8-27B-Uncensored-MLX/4-bit --prompt "用一句话解释量子纠缠。" --max-tokens 256

添加 --image path/to/image.png 用于视觉输入，或直接提供服务：

python -m mlx_vlm server --model ./Qwen3.8-27B-Uncensored-MLX/4-bit --port 8080

For agent frameworks that speak Open​AI-compatible APIs, mlx_lm.server is the lighter path — uv tool install mlx-lm then mlx_lm.server --model "orcarouter/Qwen3.8-27B-Uncensored-MLX", which serves at http://localhost:8080/v1 with api type openai-completions. Our card carries self-reported community configs pointing Pi, Hermes and OpenClaw at that endpoint. Those are user-supplied setups we have not reproduced, so treat them as starting points, not guarantees.

视觉在量化中幸存

由于视觉塔（vision tower）和 conv1d 保持 BF16 精度，图像理解在 4/6/8 位下得以保留。在我们的测试图像上——形状、颜色、位置、背景以及图像内文字——4/6/8 位版本都能正确描述所有内容；2 位版本只能部分理解。如果你在挑选版本且视觉能力很重要，4 位是你应该选择的下限。我们尚未发布该版本针对 Apple Silicon 的视觉吞吐量数据，因此除非 tok/s 数字来自你自己芯片类别上的一次具名运行，否则不要轻信。

保留的视觉塔也是风险面的一部分，这一点值得明说：一个还能读取图像的消融模型，并非仅涉及文本的安全问题。

工具调用与智能体使用

工具调用是基础模型的一项能力，并且它在abliteration之后依然保留，这使得该构建在对智能体系统进行红队测试时确实很有用——如果指向真实服务，也确实很危险。标准设置是mlx_lm.server端点，即上文提到的那个。任何兼容Open​AI的智能体都能调用。如果你确实要把它作为智能体来运行，请明白你启用了什么：一个无拒答模型，具备函数调用能力和262K上下文，其安全姿态与聊天模型不同；模型卡中“仅限研究”的定位正是出于这个原因。

262K上下文及其真实成本

该架构使此模型的长上下文成本异常低廉。这里的混合注意力是指48个线性注意力（Gated DeltaNet）层与16个全注意力层交错排列，且只有16个全注意力层携带经典KV缓存——线性层则改为保留紧凑的循环状态。因此，处理262,144个token的代价远低于在全注意力27B模型上的成本。这是关于基础模型的结构性事实，而非对你Mac性能的承诺。

实际上，上下文窗口是一种能力，而不是免费层。在 M4 Max 上的一次社区长上下文测试测得，短上下文时约为 63 tok/s，到 31K tokens 时降到约 11 tok/s —— 随着缓存填满，解码性能急剧下降；而在非常长的提示词上，首 token 延迟通常比原始吞吐量更是主要的瓶颈。投机式预填充和基于 ANE 的预填充改善的是输入处理，而不是解码。我们自己针对此构建在 Apple Silicon 上的 KV 缓存成本数据尚未公布；如果你需要针对自己硬件的具体数字，社区运行结果才是可靠的来源，而社区的共识是：完整的 262K 上下文是你要刻意去使用的东西，而不是默认保持开启的设置。

速度 — 实际测量的是什么

我们为这个构建只发布一个速度数据，而且它不是Apple Silicon：通过MLX CUDA后端，在单个H200上稳态约为32–37 tok/s，这证实了权重也可以在macOS之外运行。在Mac上，我们的模型卡刻意不发布tok/s，因为这取决于芯片、精度和运行器。值得了解的从业者数据，均如此标注：

• 这一确切构建，4-bit，M1 Pro 32 GB：短时间运行时生成约8.7 tok/s，预填充约41.7 tok/s（社区测试，2026年8月）。芯片较旧，但这是一个现实的下限。

在M4 Max上，oMLX原生支持MTP，使用原版未消融检查点时：文本生成53.3 tok/s，代码生成72.1 tok/s，4K上下文的预填充约273.7 tok/s；未启用MTP的原始解码约24.6 tok/s。该数据由从业者在不同检查点和运行时上实测，因此应将其视为abliterated权重可能接近的上限，而非保证。

• 在 M3 Ultra 上，采用 oMLX 双 ANE 预填充的去拒答化 oQ4e-MTP：预填充在 16K 时提升约 17.7%，在 32K 时提升约 18.9%；通过 Lightning MTP 解码，在 16K 时可达约 75 tok/s。不过，它的缺点也是实打实的：它使用了苹果私有运行时接口和近似的 INT8 权重，增加约 4 GB 峰值内存，并将模型加载时间从约 3.4 秒推至约 28 秒。这是提示词摄入优化，而非生成加速器。

MTP 头——如果你的运行器支持的话，这是一项免费的加速。

此版本将基础模型的多令牌预测草稿器放在 mtp/ 子文件夹中（架构为 qwen3_5_mtp），并且它适用于任何主精度。接受过程是无损的——使用贪心解码时，输出与不运行草稿器时完全相同——因此当它启用时，是真正的加速，且不会带来质量损失。根据我们的模型卡片，有两条设置说明：它需要一个包含 qwen3_5_mtp 草稿器的 mlx-vlm 构建（main 分支），并且你必须同时传入 --draft-model ./Qwen3.8-27B-Uncensored-MLX/mtp 和 --draft-kind mtp。仅设置 mtp_enabled 不会起任何作用。如果你的运行器不支持该草稿器，它会被忽略，模型照常运行——不会出问题。

安全 — 运行前阅读，而不是运行后

模型卡自身的免责声明异常直白，本页面也不会加以缓和。此构建的安全对齐已被大幅移除。它会遵从基础 Qw​en/Qwen3.8-27B 会拒绝的有害、不道德、冒犯性或非法请求，并且没有真正意义上的内置护栏。它严格仅用于合法研究——可解释性、AI 安全与拒答机制研究、红队测试、鲁棒性评估和受控实验。如果你做的不是这些，那么这个模型就是错误的模型。

卡片中的两个警告值得强调。首先，越狱和安全探针在去拒绝化（abliterated）模型上会轻易“成功”，这并非通过安全评估——而是拒绝方向被移除后模型的预期行为。没有拒绝并不代表安全。其次，保留的视觉、工具调用和262K上下文将攻击面扩展到图像理解和智能体使用：一个能读取截图并调用工具的无审查模型，比仅限聊天的去拒绝版本构成更广泛的风险。低比特量化在此基础上又增加了第三层不稳定性——在2比特下，乱码输出甚至可能被误认为拒绝，这本身就是一种令人困惑的失败。

{{1}}您对使用和输出承担全部责任与义务。{{/1}} Apache-2.0 许可证继承自基础模型，但这并不改变上述事实：它允许使用，却不会让您的部署变得安全。{{2}}任何将此部署给最终用户、未成年人或任何生产环境的人，都必须首先添加自己的审核、安全与防滥用层，并遵守适用法律。{{/2}} {{3}}对于真正运行它的研究人员，实际的防护措施是：隔离（最好离线）的环境；不指向真实服务的代理工具；不向最终用户暴露；以及在输出流向别处之前先进行审查。{{/3}}

当本地不是答案时

本地化正是这个构建的意义所在——权重文件存放在你的磁盘上，没有按 token 计费的成本，也不会有任何数据离开你的机器。但本地化同时也是一道天花板：它仅支持 Apple Silicon，你必须接受量化后的质量，而且机器繁忙时没有任何冗余。如果你需要通过 API 调用一个未去审查（non-abliterated）的 27B 级模型来处理实际工作负载，或者你想用相同的提示词将这个本地构建与托管模型做 A/B 对比，这正是路由层要填补的缺口。OrcaRouter 将 200 多个模型放在同一个 API 密钥后面，按供应商目录价计费，并具备自动故障转移和路由 DSL——供应商宣布降价当天，我们这边就会同步生效，因为我们只是按目录价原样转传。一个 API、一次集成，你就能把尚未验证的本地方案与托管模型进行对比，而无需再单独开设账户。我们不托管这个 MLX 构建版本——按设计它就是本地权重——所以 API 是补充路径，而不是替代品。

快速决策指南

• 16 GB Mac — 说实话，不是这款。2-bit 能塞进去，但只适合存档；不管怎样你都少不了一番内存挣扎。看看更小型的无审查模型，或者社区专为 18–24 GB 机器做的 3/6-bit 混合转换版。

• 24 GB Mac — 使用 4-bit 量化，并保持上下文简短；不要同时运行视觉和长上下文。

• 32 GB Mac — 4-bit 是最佳平衡点；如果保持上下文紧凑，6-bit 也可以。

• 48 GB Mac — 带余量的 6-bit；如果不推动窗口，则为 8-bit。

• 64 GB 及以上 — 8-bit、近无损，以及 262K 上下文触手可及，但需注意上述限制。

这就是整本运行手册。该模型来自2026年8月17日，这不是发布新闻，也不需要是：83,000次下载之所以发生，是因为人们想要一份操作指南，而本页面就是那份指南。从仓库根目录开始，在LM Studio中加载4-bit版本，只有当你清楚自己在质量上付出什么代价时，才离开默认构建。如果你来自GGUF或FP8家族，相关指南涵盖了那些路径——这里的决策框架相同，但量化数学不同。

并非这个模型的又一个构建版本——Qwen3.8-Flash-Next-Uncensored是一个独立的发布版本：由Qwen3.8-Flash-Next经abliteration处理而来，后者是Qwen4架构的176B存储/6B激活混合专家（MoE）预览版。相同的abliteration技术，不同的权重，拥有自己独立的模型合集。

所有六种 27B 构建——BF16、GGUF、MLX、FP8、INT8 和 NVFP4——均收录于Qwen3.8-27B-Uncensored 合集，该合集托管于 Hugging Face。

这些权重按设计仅限本地使用。如需一个托管基线来衡量 abliterated 构建版本，Qwen3.8-27B 通过 OrcaRouter 以提供商列表价提供服务，0% 加价——即原版模型，安全对齐完好。