新闻、仓库与研究，按时间排列。
Hugging Face 社区发布 Feyospace-v1.1-Abliterated-security-MTP-UD-Q4_K_S，这是基于 OBLITERATUS/feyospace-s1-obliterated 的 GGUF 量化版，面向本地网络安全研究、代码分析与工具辅助调查。该构建采用 UD-Q4_K_S 混合精度布局、面向安全的 importance-matrix 校准，并保留 MTP 头以支持投机解码；上游模型约 28B 参数、Qwen3.5 架构、Apache-2.0 许可，最大上下文 262,144 tokens。该卡未提供此量化版的 benchmark 结果，最终张量清单与质量保留情况尚待验证。
huihui-ai 基于 Aleph-Alpha/Kolibri-1-BF16 制作了 abliterated 无审查版本，全程用 llama.cpp 的 GGUF 完成，不依赖 Transformers。已用 llama.cpp 重新量化并上传 Q2、Q3、Q4、Q5、Q6、Q8 和 BF16 版本。原版 llama.cpp 暂不支持 kolibri1 架构，需应用仓库内提供的补丁并检出 commit 836d571 后编译。
一位用户在 N1X 128GB（88GB VRAM）Windows on Arm 设备上，通过 WSL3/Ubuntu-26.04 调优 Qwen3.8-Flash-Next-W4A16-AutoRound-hybrid 模型并取得满意结果。虽然生成速度（tk/s）不算最快，但面向智能体的并发表现好于预期。
dealignai 在 Hugging Face 发布 Ornith-1.5-122B-UNCENSORED 的 NVFP4-Infernix 格式导出，这是去 refusals 版本的量化模型，基于 Qwen3.5-122B-A10B 架构（48 层、256 个路由专家每层取 top 8），附带 MTP 与 DFlash2 drafter。模型经逐字校验与 checkpoint 无失配，可在单张 RTX 5090（32 GB）上运行，约需 70 GiB 主机内存和 76 GB 磁盘空间，速度仍待优化测定。
Hugging Face 用户发布 Qwen3.8-Flash-Next 越狱版（orcarouter/Qwen3.8-Flash-Next-Uncensored）的 UD-Q4_K_XL 风格量化，复刻官方 Unsloth 类型表，主干 5.03 BPW、总计 108.39 GiB，附带 MTP draft head（Q8_0）与视觉塔（BF16），原生上下文 262,144，Apache-2.0。在 AMD Strix Halo 上以 Gufo 与 Halogen 实测 decode 32~40 tok/s，MTP 推测解码正常；缺 MTP head 会静默关闭推测解码，吞吐掉 30%+。
开发者推出 ThousandML 平台，用自研免校准量化 CQ 4-bit 做 QLoRA 微调以降低 GPU 成本。在 Qwen3.8-27B 的 Alpaca 微调对比中（单张 NVIDIA A40 48 GB，LoRA r=32、500 步），CQ 最终验证损失 1.0315 优于 Unsloth NF4 的 1.2484，且峰值显存略低，但每步耗时 27.60 s 远慢于 NF4 的 3.20 s，速度仍在优化中。已发布 thousandml/Qwen3.8-27B-CQ-4bit 等多个 CQ 4-bit 底座模型及复现脚本。
nchapman 在 Hugging Face 上发布 Huihui-Qwen3.5-0.8B-abliterated-W4A16-GPTQ，这是一个基于 Qwen3.5 0.8B 的 abliterated 多模态 GPTQ 量化模型，支持 image-text-to-text 任务。模型可通过 Transformers、vLLM、SGLang 加载部署，并提供 OpenAI 兼容 API 与 Docker 运行方式。
Hugging Face 上架 nchapman 发布的 Huihui-Qwen3.5-2B-abliterated-W4A16-GPTQ，这是一个 2B 参数、W4A16 GPTQ 量化的 abliterated 多模态模型，支持图像-文本到文本任务。文档给出 Transformers、vLLM、SGLang 及 Docker 的部署示例，并支持通过 OpenAI 兼容 API 调用。
BoldingBuilds 放出 OrcaRouter 去 GLM-5.3-Flash-Uncensored（320B 总参数/18B 激活 MoE、288 路由专家、1M 上下文）的 imatrix GGUF 量化，含 IQ3_XXS、IQ2_M、IQ2_S、IQ2_XXS 四档，并修正共享专家与 attention 量化配方使 IQ2_S 等通过全部 48 项一致性测试。量化权重上实测 JailbreakBench 有害拒绝率 0.040（OrcaRouter FP8 为 0.120，base 为 0.930），HumanEval pass@1 0.927；作者指出空输出会计为服从，提醒评测时必须同时报告空输出数，文件已适配 mainline llama.cpp 与 LM Studio 模板。
Hugging Face 用户 mradermacher 上架 Minecraftism-4B-Thinking-Uncensored 的 i1-GGUF 量化模型仓库。模型采用 GGUF 格式，页面提供了下载统计与硬件兼容性信息，用户需登录后可添加自己的硬件配置。
作者开源 llm-inference，一个面向可测量的 LLM 服务栈，包含从零实现的 continuous batching 引擎、OpenAI 兼容服务器、开环负载生成器和自动生成报告的实验集。在 T4 上对 Qwen/Qwen2.5-0.5B-Instruct 实测，continuous-32 达 6 req/s SLO 容量，为 vLLM（12 req/s）的 50%，静态 KV 槽位加 CUDA graphs 后升至 10 req/s 达 vLLM 下界 83%；附逐 token 正确性测试、精度（fp16/int8/nf4）对比与复现脚本，仓库 MIT 协议。
推荐理由：作者自建推理服务栈并与 vLLM 同卡对比，给出 SLO、CUDA graphs 和前缀缓存的消融数据，可复现。
nchapman 在 Hugging Face 发布 Huihui-Qwen3.5-4B-abliterated-W4A16-GPTQ，这是一个 abliterated 的 4B 多模态 GPTQ 量化模型，支持 image-text-to-text 任务。页面给出 Transformers、vLLM、SGLang、Docker Model Runner 等多种部署方式，均可通过 OpenAI 兼容 API 调用。
MishraNepali 发布 OrcaSAQ-2-Cyber-27B-Uncensored 的 GGUF Q2_K 量化版本，可在 Hugging Face 获取。该模型支持通过 llama.cpp、vLLM、Ollama、Docker Model Runner 等多种工具本地运行，并可启动 OpenAI 兼容 API 服务器供 LM Studio、Jan、Pi、Hermes、OpenClaw 等客户端调用。
一位 Reddit r/LocalLLaMA 用户用 8x T4 服务器部署 Qwen 3.5-9B Q5_K_XL，实现 87k 上下文、44 个 slot、单用户 35-40 tps，现想用 QLoRA 微调约 500 GB 的图像、扫描件、PDF、Word/Excel 数据。他持有 Mi50、V620、3060 等多块显卡但多台主板存在启动兼容问题，纠结于 3060 组合还是单价约 700 美元的单卡 R9700，并询问 unsloth 是否支持 Intel GPU。
KaedeTai 将 SC117 制作的 abliterated 版 Occamy-1.0 从 BF16 GGUF 反向转回 HF 布局并量化为 MLX 4-bit，约 20 GB。仓库装回 Accio-Lab 原版的 vision tower，并从 KaedeTai/Ornith-1.5-35B-A3B-BigBang-MTP-zh-mlx-4bit 原样移植 MTP 草稿头；该头在 Occamy 上草稿接受率达 65.6%（每周期 2.13 个 token），高于其原本干的 Ornith 主干的 64.9%。作者用逐张量逆变换脚本还原 llama.cpp 转换改动，42 个对照张量中 40 个与未去对齐基座逐位一致，其余两个正是消融所改的矩阵。
推荐理由：作者给出了逐张量校验和同机对照的 TMMLU+ 分数，可以核对这套 GGUF 转 MLX 加移植 MTP 头的转换质量与速度收益。
R0U5 在 Hugging Face 发布 Qwen2.5-7B-Instruct-abliterated-64k，这是基于 huihui-ai 消融模型与 mradermacher GGUF 量化的元数据修复版，非新增消融。仓库将 context_length 重新声明为 65536 并添加 YaRN rope scaling 元数据（factor 2.0），以满足 Hermes Agent 64,000 token 最低上下文要求，权重与上游量化逐位一致。经 llama.cpp 验证 12 个拒绝测试提示 0 拒绝，Q4_K_M 版本 4.68 GB。
/u/iam31337 在 RTX PRO 4000 Blackwell SFF（24 GB，工厂 70 W 无辅助供电）上用修改版 VBIOS 将功率提至 120 W，Qwen3.8 27B 生成从 35.04 提升到 58.53 tok/s（+67%），Qwen3.6 35B A3B 显存 +33.3% 时生成 +19.8%。158 次请求、每配置仅 1-3 次，两模型量化与投机解码设置不同，非严格受控对比；作者提醒 120 W 超出 PCIe 75 W 槽位预算，属实验性结果。全文与 CSV 见 https://piszczek.pl/blog/rtx-pro-4000-blackwell-sff-120w-qwen-benchmark
推荐理由：作者实测同一款卡上两个模型的功耗超频收益差异，给出具体功率与频率参数，并坦承样本量与量化设置的局限。
作者在 RTX 4090 24 GB + 48 GB RAM 的 Windows 机器上对 Strata 0.1.43 运行 Qwen3.8-Flash-Next IQ3_S 量化包做了系统性网格调参，附完整 JSON 配置。三个关键参数 --adapt-async 1、--kv-resident 20480、STRATA_ADAPT_LAG=2 合计把 160k 上下文下的解码速度提升 45%；同时给出负面结果，--expert-cache 按 MiB 而非槽位设置（填满显存时 −72%）、--ple-io ram 在 48 GB 下 −90%、--no-prefill-borrow −46%。
推荐理由：作者用自建 A/B 测量流程在 RTX 4090 上逐项测了 Strata 各参数的真实增益与坑位，附完整可用配置。
abliterated 版模型 yuanyeyuanye/llm-qwen3.8-flash-next-abliterated-iq4xs（UD-IQ4_XS 量化）现可通过 llama.cpp 加载，支持 llama serve 启动兼容 OpenAI 的本地服务器与 llama cli 终端推理。模型也可经 Ollama、Docker、Lemonade 拉取运行，并能接入 Pi、Hermes、OpenClaw 等工具，覆盖 macOS、Linux 与 Windows 平台。
dealignai 在 Hugging Face 发布 Nanbeige4.3-33B 的 UNCensored GGUF 版本，移除基础模型的拒绝行为，提供 Q6_K（25.3 GB）、Q4_K_M（18.7 GB）、IQ2_XXS（8.7 GB）三种量化，均附带基于 1M token 校准内容的 imatrix，保留原生 think on/off 与 512K 上下文。与同量化基础版对比，MMLU chat 下降 Q6_K −1.74pp、Q4_K_M −1.09pp、IQ2_XXS −4.53pp；6 提示多轮合规测试三个量化均为 6/6 通过、0 次拒绝。
推荐理由：原文给出三种量化的 MMLU 前后对照和多轮拒绝率实测，读者可据此评估去掉拒绝行为的能力代价。
一位 r/LocalLLaMA 用户拥有 140TB 存储和搭载 640GB A100 GPU 的服务器，在 Hugging Face 被接管后打算下载最重要的模型，已计划包括 GLM5.3 (Flash)(abliterated) 和 DS4 Flash 等，并询问还需保存哪些模型和量化版本以备将来使用，也想涉足图像和视频模型。
一位 r/LocalLLaMA 用户拥有 140TB 存储和搭载 640GB A100 GPU 的服务器，在 Hugging Face 被接管后打算下载最重要的模型，已计划包括 GLM5.3 (Flash)(abliterated) 和 DS4 Flash 等，并询问还需保存哪些模型和量化版本以备将来使用，也想涉足图像和视频模型。
用户在 Epyc 7402P、256GB DDR4 ECC 3200 八通道内存平台上测试了四张 R9700 运行 Strata 和 DeepSeek Flash-V4.1-1017 IQ2_XS，发现受 R9700 内存带宽偏慢影响 prefill 环节最耗时，且系统内存占用偏低。Radiance 曾将 Flash Next 在 R9700 上的 prefill 和 tok/s 性能提升 3-4x，Niko 表示该优化将很快进入 Strata。
一位 r/LocalLLaMA 用户在运行 Swift 1.5 Qwen Flash Next 的 GSQ RCO IQ3XXS 量化版本，但因模型偶尔拒答，想再准备一个 Abliterated 版本，仅在少数场景下使用。由于存储空间只剩不到 1TB，他询问能否只下载两个版本之间变化的权重并合并，避免完整双份下载。
FRENCHFAKER 发布首个 abliterated 版 Nanbeige4.3-33B GGUF，用 refusal-direction ablation 移除原始模型对进攻性安全请求的拒绝行为。50 条有害提示词基准上拒绝率从 80%（40/50）降至 8%（4/50），安全/渗透测试类提示词拒绝率约 0%，推理与工具调用保持完整；IQ4_XS 量化约 17 GB，可在单张 24 GB GPU 上以约 33 tok/s 运行，基于 Apache-2.0 许可。
推荐理由：原文给出拒绝率前后对照和逐层消融方法，读者可据此评估这个去对齐版本的可靠程度。
3hs4n 发布 Qwen3.8-Flash-Next-Uncensored 的 MLX 优化量化版，目标模型采用 affine 2-bit/group-128 重建，搭配 Inco AI 的 BF16 DFlash2 草稿模型，完整下载 74.048 GB。在 M1 Max 64 GiB 实测中，代码与数学 warm 解码达 37.62 和 33.69 tokens/s，约为基线的 1.70× 和 1.56×，文本仅 1.048×；固定 50 题 GSM8K 子集全部答对且与原生参考一致，进程峰值内存 42.12 GiB。
推荐理由：作者实测了 M1 Max 上代码与数学解码的加速倍数和内存峰值，并给出 32/48/64 GiB 的可行性判断，便于评估本地部署。
Hugging Face 用户 3hs4n 发布 Qwen3.8-Flash-Next-Uncensored 的 MLX 优化量化转换包，基于 360 GB BF16 源检查点，专家投影采用 affine 2-bit/group128，其余投影为 8-bit/group64，文件约 72.8 GB。验证含 50 题 GSM8K 子集、烟雾测试（15/18 通过）及文本生成约 23.5 tokens/s 的计时结果；模型采用原生 qwen4_exp 多模态实现，可配合 run_qwen38_unsloth.py 以 16384 上下文运行。
/u/nathannguyennng 解锁了 RTX 3080 20GB 的 reBAR 与 P2P，/u/No-Refrigerator-1672 在双卡张量并行下用 vllm 0.32.0 实测验证。8k 到 261900 token 长度的 prompt 预填充速度较原厂提升 71%-115%，其中 P2P 相对仅 gpu_unlock 另有最多约 70% 提升；开启 MTP 后 decode 速度基本在噪声范围内无明显变化。作者提示 3080 用户在长 prompt 场景（含 agentic coding）可关注该解锁，且需双卡均有完整 PCIe 连接才能获得同等收益。
推荐理由：作者实测了 reBAR 与 P2P 解锁在双 RTX 308 20GB 张量并行下的 TTFT 与 ITL 数据，可看清该解锁对长上下文预填充的实际收益边界。
mradermacher 在 Hugging Face 上发布了 Minecraftism-4B-Uncensored 的 i1 量化 GGUF 版本，模型可在仓库页面直接下载使用。该模型参数规模为 1.92M，仓库卡片暂缺 yaml metadata，硬件兼容性需登录后查看。
meshapplied 发布开源工具 Goethe，可将带 NVIDIA GPU 的 Linux 机器变成自托管 API，兼容 OpenAI、Anthropic 和 LiteLLM 客户端，数据留在自有硬件上。模型基于 SGLang 运行，支持 continuous batching、prefix caching 和 CUDA graphs，并内置面向 Blackwell、Hopper、Ada 和 Ampere 的 NVFP4 内核，4-bit 模型显存占用约为全精度四分之一；支持按客户端发 key、限速与撤销，模型重启后自动恢复加载，仓库采用 Apache-2.0 许可，链接 https://github.com/meshapplied/goethe。
推荐理由：原文给出了从安装到共享 API 的完整命令流程，并说明基于 SGLang 加自研 NVFP4 内核的推理方案，便于自建 GPU 推理服务时参考。
understudy-lm 项目发布了仅从目标 LLM 的文本输出训练的推测解码草稿模型，无需 logits、隐藏状态或更小的同族模型，草稿一次猜测 4 个 token，由目标模型一步验证，输出不变。发布的草稿针对 Qwen3.5-4B 训练，实测每步接受 1.58 个 token，投影加速 1.43x；在 llama.cpp 下因需逐 token 起草并恢复状态反而更慢（27 到 36 tok/s 对 69 tok/s），需支持 lookahead heads 的运行时才能兑现。
推荐理由：只靠目标模型的文本训练推测解码草稿模型，不用 logits 和隐藏状态，并给出接受的实测与局限说明。
HAYAT 35B-A3B Uncensored (GGUF) 上架 Hugging Face，是 Windows 本地优先 AI 助手 HAYAT 的主模型，权重与 HauhauCS/Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive 完全一致，基于 Qwen3.6-35B-A3B，HAYAT 仅添加含系统指令与采样设置的 Modelfile。
Sagarkun 发布 Qwen-Image-2.1 Uncensored 的多格式量化版本，基于 Qwen/Qwen-Image-2.1 原始权重，提供 GGUF、Safetensors 和 MLX 格式，其中 Q4_K_M GGUF 仅 4.60 GB 且被推荐为体积与质量的最佳平衡。该版本无内置安全检查或内容过滤，可直接生成成人及敏感图像；文本编码器可卸载至系统内存以节省 9–17 GB VRAM，需搭配 ComfyUI 与 ComfyUI-GGUF 使用，采用 Qwen Research License。
sanasol2008 基于 orcarouter/Qwen3.8-Flash-Next-Uncensored 的 BF16 权重制作了 Sushi 格式 3bpw 实验性量化包，路由专家采用 EXL3 K3 编码，未额外做 abliteration 或微调。完整下载约 79.22 GiB，在 Apple M3 Max 48 GiB 上冷解码 11.88 tok/s、热解码 12.88 tok/s，慢于 2bpw 版本；校准误差相对 2bpw（相对 Frobenius 误差 0.029 对 0.064）更低，支持 262144 上下文配置上限。
Qwen3.8-27B-abliterated 的 NVFP4 GGUF 量化版本（27B 参数）已在 Hugging Face 上架，支持 image-text-to-text 多模态输入。文档给出 Transformers、llama.cpp、vLLM、SGLang、Ollama、Docker 等多种本地部署与 OpenAI 兼容 API 调用方式。
abenzerps 发布 XHToken/Spark-X2.6-4B 的混合精度 GSQ-RCO GGUF 量化版，面向 llama.cpp 本地推理。RCO 将 36 个 sigmoid 注意力门控和 9 个全局注意力投影保留为 BF16，GSQ 依 Hessian 灵敏度校准优化每层精度，推荐 IQ3_M（2.28 GB）。4-bit KV cache 下 131k 上下文约需 3.5–4 GB 显存，支持 llama.cpp 与 Ollama，采用 Apache-2.0 许可。
hurui200320 在 GitHub 公开的 llm-ops 仓库用于管理 NAS 上的本地 LLM 部署，模型按模型族与变体目录存放 GGUF 文件和 sha256 校验文件。维护脚本以公共容器镜像 ghcr.io/hurui200320/llm-ops-toolbox:latest 发布，内置 check_updates、verify_checksums 和 download_hf 命令。另有 fetch-templates.sh 脚本可单独同步聊天模板，避免为更新模板重新下载 30GB 模型；访问 gated 仓库需设置 HF_TOKEN。
一位 LocalLLaMA 用户在 r/LocalLLaMA 询问 KV cache 量化的实际影响：其通过 strata 运行 qwen flash next 3.8 iq3xxs，KV cache 用 q8、262k 上下文，想扩到 300-400k 但显存不够，担心 q4 cache 质量下降。评论区多推荐 8k4v 方案，发帖人表示将尝试，否则维持 q8。
huihui-ai 基于 deepseek-ai/DeepSeek-V4.1-Flash-1017 发布 abliterated 去审查版本，完全用 llama.cpp 的 GGUF 完成 abliteration，未依赖 Transformers。仅 abliterate 第 11 至 28 层（0 起始索引）的 18 个 attn_output_b 张量，专家系统未改动；UD 系列来自 unsloth 的 GGUF。模型安全过滤大幅降低，建议用于研究或受控环境，支持 262144 上下文长度。
Reddit r/LocalLLaMA 用户提醒量化模型制作者和用户尽快备份自己的量化模型文件，并建议有条件的人制作 torrent 分享备份。帖子未说明具体风险原因，也未提及具体模型或版本。