新闻、仓库与研究，按时间排列。
AtomicChat 基于 BFL 的 FLUX 3 Image Klein 提示词扩展器（9B Qwen3.5 微调）投影移除拒绝方向，发布 llama.cpp 可用的 GGUF 权重及 3MB LoRA 版本。作为聊天模型，held-out 提示词上英文拒绝率从 63% 降至 0%，俄语从 29% 降至 1%，MMLU 从 74.15% 微降至 73.95%，工具调用与长文本检索不受影响；作为 upsampler 时在 35 条敏感请求中比原版多保留 2 条内容，但 Klein 图像模型本身不画这两类，出图无可见去审查效果。
同一新闻，精选展示《AtomicChat 发布 FLUX 3 Image Klein 提示词扩展器无拒绝 GGUF 版》
HauhauCS 发布 Qwen3.8-27B 无审查 Aggressive 变体的 GGUF 量化版本，0/465 拒答，直接作答且几乎无前导语。该版本附带 HauhauCS FastMTP 32K 加速 sidecar，在 Q8_K_P 下相比禁用 MTP 最高达 3.02x 文档 TG 和 1.93x 推理 TG，比标准内嵌 MTP 高 35.2% 和 21.1%。模型保留文本、推理、agentic、图像与视频能力，原生 262,144-token 上下文，可扩展至 1,000,000，兼容 llama.cpp 等标准 GGUF 运行时。
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 后编译。
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%+。
ggml-org llama.cpp 的 Pocket-TTS 组件存在越界写入漏洞：函数 list_pockettts_state_slots 中对参数 mmproj 的操作可触发堆越界写，攻击需本地访问，公开 exploit 已可用。升级到 b11796 可修复，恶意 mmproj 现在会触发 GGML_ASSERT 中止；但 PR #29360 的根治修复仍在开放中。
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。
ps5lm_ha 是一个 Home Assistant 集成，可在越狱 PS5 的 GPU 上通过 llama.cpp 按需运行本地 LLM 推理，并提供 OpenAI 兼容 API，Qwen 3.5 9B Q6_K 约 45 tok/s。它会通过 Remote Play 唤醒主机、登录并启动 PS5LM（模型加载约 2 分钟），完成后送回待机模式，支持模型切换与以开关和服务形式接入自动化，无需云端和额外 Python 包。
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 许可。
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 上下文长度。
anujj 向 ggml-org/llama.cpp 提交 PR #29948，在 MMQ 中以交错 gate/up 行的方式融合 FFN gate/up matmuls 与 GLU。
NeonMC23 的 forgeCORE 是一个基于 llama.cpp/ggml 的轻量 Rust 抽象层，自身不含计算逻辑，负责打开 ggml backend、管理 tensor 与计算图、通过 libllama 加载 .gguf 模型，并运行 Model → Context → Batch → decode → Logits → sample 的最小 CPU 推理路径。它暴露 tokenizer、KV/state 原语（state snapshot、position shift、KV cache dtype）、GPU offload 选项（默认 CPU，无 GPU 时显式报错），并内置冻结的标量 oracle 用于交叉验证；目前 CPU 推理路径已通过验证。
一位用户在 r/LocalLLaMA 询问，€250-€300 购入两台改装 Dell Precision T5810（分别配 Xeon E5-2699 v4 22 核与 E5-2698 v4 20 核）加 32GB DDR4-2666 RDIMM 和 NVMe 转接卡，用于搭载其 Gigabyte RTX 3090 24GB 跑 llama.cpp 与 Strata 推理。计划先本地运行 Qwen 3.8 27B，后续扩至 128GB-256GB 内存以卸载约 120GB 的 Qwen 3.8 Flash Next MoE，目标 20+ tok/s；第二台兼作孩子的 Linux 学习机与 Proxmox 节点。
TensorSharp 开发者在 MiniMax-M3.1-Flash 开放权重发布当天加入支持，支持 GGUF 推理、MiniMax Sparse Attention 专用 CUDA kernel、图文输入、tool calling、多 GPU 拆分与张量并行、DSpark 投机解码和 MoE 专家 CPU offload。在 8× NVIDIA A40、双方使用相同 Unsloth UD-Q4_K_XL GGUF 的对比中，64K executor prefill 达 2,567 tok/s，对比被测 llama.cpp 分支的 262 tok/s 提升约 9.8 倍，server 首字时间从 293.4 秒降至 40.0 秒；64K decode 提升 1.49 倍，短对话 decode 基本持平。
推荐理由：开发者给出两引擎在8× A40上的prefill与decode实测，并解释长上下文差距来自稀疏注意力的实现差异，可复现。
Reddit 用户 /u/TheSpicyBoi123 发布改进 llama.cpp 对 Kepler 等 Ampere 之前 NVIDIA GPU 支持的高性能分支，目标是让旧 CUDA 硬件继续可用。在 4x Tesla K40c 上以 Q8_0 量化运行 MTP Qwen3.6-35B-A3B，从原先无法启动提升到 35 tps，修复主线上 cc35-50 的 cuBLAS 计算类型选择问题；启用 CUDA graphs 后达约 55 tps，Windows NCCL 集成带来约 5–10% 端到端提升，吞吐超 60 tps，P.P. 速度在 70-100 tps 之间波动。作者声明这是其个人系统的初步结果，并征集 Kepler、Maxwell、Pascal、Volta 等旧卡用户对比测试。
推荐理由：作者用 4 张 Tesla K40c 实测给出量化前后与启用 CUDA graphs 的速度对比，老卡复用方案可自行复现验证。
Reddit 用户更新了 ik_llama.cpp fork，并寻求社区反馈。该实现在 6GB 显存的 RTX 2060 上运行 Qwen3.6-35B-A3B-UD-Q4_K_M，短提示词生成约 45–48 t/s，28K 上下文约 37 t/s，prefill 约 430–700 t/s。由于反馈太少且代码需拆分清理，作者暂不合并到主线。
CrossWordFalcon 是一个可从网页生成完整填字游戏的工具，支持法语、英语、德语、西班牙语、意大利语和葡萄牙语，网格尺寸从 5×5 到 50×50，提供三档难度。它由本地小模型自动生成基于真实词典定义的线索，也可选用 Mistral、Claude 等云端模型并自动回退本地。程序 100% 本地运行，支持 CPU 或 GPU（含 Apple Silicon），推荐配置为 8 核、16 GB 内存和 12 GB 显存的 NVIDIA 显卡。
Adolphsson 在 Hugging Face 发布 GLM-5.3-Flash 去审查版的 GGUF 量化，基于 dealignai 的 CRACK abliteration FP8 checkpoint，采用 IQ4-Maya 配方量化，支持 1M tokens 上下文与视觉（mmproj F16），保留 MTP 草稿块可用于投机解码。全量约 156.3 GB，分 4 个分片，MIT 许可；在单张 RTX 5090 上 1M 上下文实测 28.5 tok/s，仅通过功能验证，尚未跑 MMLU 等 benchmark。
matnum 发布 local-llm-benchmarks 仓库，在 128 GB 统一内存的 AMD Ryzen AI Max+ 395（Strix Halo）上用 llama.cpp 对 10 个 GGUF 模型/量化组合在 Vulkan 与 ROCm 两个后端测吞吐、延迟、内存、功耗与 tokens-per-watt。结果显示 Vulkan 在 10/10 单元生成更快（6 个领先 2.1–18.0%），ROCm 在 9/10 单元 prefill 更快（6.2–56.8%）；MoE 模型生成速度和每瓦效率是同体量稠密模型的 5–8 倍，gpt-oss-120b（MXFP4，约 59 GiB）达 55.3 tok/s。
推荐理由：原文公开了完整测试矩阵、固定 commit 和可复算测试，读者可以按需核对每个数字而不是直接信任结论。
ojas1542 在 GitHub 开源 MyInferenceLayerFoundation，一套完全跑在单台 Mac 上的个人 AI 技术栈，用 llama.cpp 本地服务 Qwen3.5 9B（128K 上下文）和 Qwen3 Embedding 0.6B，前置一个 Go 推理层。
作者在单张 RTX 5090（400 W）加 128GB 内存的 Linux 机器上，对 Strata、Infernix、capy-flash、ninfer-ext、ninfer、llama.cpp 和 Basalt 七个 Qwen 3.8 FN 推理引擎做了基准测试，每个引擎各自转换 NVIDIA NVFP4 权重后跑相同的七个 greedy 请求，每个请求独立冷启动。
llmsyscore 在 GitHub 开源了 llm-systems-manager，一个自托管面板，用于监控、控制、基准测试和调优运行本地 LLM 的机器，采用 AGPLv3 许可证。支持 llama.cpp、vLLM、LM Studio 和 stable-diffusion.cpp，兼容 NVIDIA、AMD（ROCm 与 Vulkan）和 Apple Silicon GPU，支持 Linux 与 macOS，不支持 Windows。
推荐理由：原文完整列出了安装方式和监控、基准、自动调参等功能清单，可用于评估这套自托管面板是否覆盖本地推理运维需求。
abenzerps 基于 TokenRhythm/NeoHorse-1-9B 发布 GSQ-RCO 混合精度 GGUF 量化版本，采用 RCO 保留全部 48 个关键 SSM 参数为 BF16，并用 GSQ 按 Hessian 灵敏度校准逐层优化精度。提供 IQ2_XS 到 IQ4_XS 共 5 档文件，推荐 IQ3_M（3.75 bpw、4.20 GB）。配合 4-bit KV cache 可在 8GB 显存的消费级 GPU 上以约 6 GB VRAM 运行 131k 上下文，遵循 Apache-2.0 License。
一项针对本地 LLM 记忆提取的 120 例基准测试（60 组对照对、96 例英文主测试）显示：Hy-Memory 30B-A3B 召回率 100%（52/52），但 44 个空输出用例全部错误并产生 76 条冗余提议；Qwen3.5 4B 和 9B 更克制，空用例正确率分别为 95.5% 和 90.9%，冗余提议仅 3 条和 5 条；LFM2.5 24B-A2B 召回 76.9%，受指令示例污染和引用格式问题困扰，后验映射可修复 9/18 个无效引用字段。所有模型经 llama.cpp 在同一台 Ubuntu 机器上运行，测试不涉及速度。
dima6312 在 Hugging Face 发布了 RecursiveSI Flint 40B-A2.5B 的 abliterated 版本 NVFP4 GGUF，移除拒绝方向，面向安全研究与编码工作，需 llama.cpp b11827 及以上在 NVIDIA Blackwell GPU 上运行，权重文件 22.9 GB。对照测试显示 MITRE 拒绝率从 22% 降至 0%，Meta CyberSecEval 拒绝检查从 18/100 降至 1/100，GSM8K 与 HumanEval+ 无显著下降，pp512 与 tg128 速度差异在 3% 以内；模型基于 Apache 2.0 许可衍生自 RecursiveSI 权重，去对齐只降低拒绝、不增加知识。
同一新闻，精选展示《dima6312 发布 Flint 40B-A2.5B 的 abliterated 无对齐 GGUF 版》
作者在相同的 Opus 5.5 规划、3 worker 并行设置下，用 llama.cpp Q8_0 在 RTX PRO 6000 Blackwell 96GB 上实测三个小型 MoE 编码同一个 Three.js 万圣节连锁反应场景。Flint 40B-A2.5B 综合最优：墙钟 7:36、修复 6 次、Opus 花费 $0.41；Nemotron 3.5 Lightning 解码最快但生成约 5 倍 token、修复 16 次、花费 $0.95，其编辑成功率仅约 17%。作者指出换 worker 模型使规划者账单从 $0.41 涨到 $0.95，裸 tok/s 并不决定总耗时，且三者在单轮内都没产出完全可用的场景。
推荐理由：同一任务同机实测三个小型 MoE 当编码 worker，给出 token 消耗与 Opus 花费对比，显示编辑成功率比裸速度更影响实际耗时。
/u/nickm_27 实测 ggml-org/llama.cpp 的 PR #29864 重构 Intel XMX 矩阵引擎后，B70 在 SYCL 下投机解码速度大幅提升，测试模型为 Muse Glimmer Q6_K (30B) 搭配 DFlash2。9 项任务总耗时从 46.86 秒降至 26.68 秒，各任务 tok/s 普遍从约 36-53 提升到约 53-88；作者说明因 token 验证成本显著降低而调大了 n-max，接受率从 0.7845 降到 0.363 属预期现象。
推荐理由：作者实测了 llama.cpp 重构 Intel XMX 矩阵引擎后 B70 的投机解码速度，前后总耗时从 46.86 秒降到 26.68 秒，数据完整可复现。
开源 .NET 推理引擎 TensorSharp 在 10× NVIDIA A40 上运行 Muse Spark 816B（42B 激活参数，Unsloth UD-IQ3_XXS 量化，约 316 GiB 权重），并与 llama.cpp 对比。张量并行下 TensorSharp 达 22.6 tok/s 解码、4 并发 45.7 tok/s，层切分下 4K prefill 达 1346.8 tok/s，比 llama.cpp 快 2.07×；层切分 prefill 吞吐比张量并行高 4.6×。质量对比中 Top-1 一致率约 98.8%，功能检查层切分 13/14、张量并行 14/14 通过。
Reddit 用户 /u/Barni275 从新发布的 Ling-3.0-tiny UBTree 中提取纯 DFlash 草稿部分（丢弃 7 个 ubtree_selector 张量），使其可在原版 mainline llama.cpp 上运行，并放出转换后的 GGUF 与转换流程（yury-kapoyko/Ling-3.0-tiny-UBTree-dflash-GGUF）。小规模实测显示：散文生成从 78.8 tok/s 提升到 84.8 tok/s（+8%，接受率 0.28/2.7），Python 代码生成从 79.0 tok/s 提升到 127.2 tok/s（+61%，接受率 0.53/4.2）；转换仅需对 GGUF converter 做小补丁，其余均为原生功能。
Thinkube 的 llama-cpp 可选组件提供 LLM Gateway 背后的 llama.cpp 推理服务器，支持 1-bit 到 16-bit 量化的 GGUF 模型，容器在 8000 端口运行 llama-server，提供 OpenAI API（chat completions、completions、embeddings 等）。模型由 MLflow 管理，首次启动将 GGUF 文件复制到节点本地磁盘。镜像基于 llama.cpp release b11476 和 CUDA 13.0 构建，组件与模板均为 MIT 许可。
Thinkube 的可选组件 llama-cpp-prism 使用 PrismML 的 llama.cpp fork，支持其 Bonsai 模型的低比特 GGUF 格式 Q1_0（1-bit）、PQ2_0 和 PTQ1_0，并带专用 CUDA kernels；原版 llama.cpp 会拒绝这些文件。该组件通过同一入口在 8000 端口运行 llama-server 并提供 OpenAI API，镜像基于 fork 的 prism-b10754-2459f68 版本与 CUDA 13.0 构建，模板采用 MIT 许可。
Domyn Small 1.0 的支持已合并进 llama.cpp。该模型是 Domyn 开源的约 10B 参数推理模型，原生 32k 上下文（可经 YaRN 扩展至 131k），支持 thinking on/off 双模式推理与工具调用，采用 MIT 许可证，推理 token 消耗约为 Qwen3.5-9B 的 32% 和 OLMo-3-7B-Think 的 35%，BFCL V3 单轮成绩为 75.9 Non-Live / 68.3 Live，适合小显存环境的 agentic 部署。
团队发布开源 DNA 语言模型 Carbon-X，基于 Qwen3 14B 在 DNA 与自然语言混合语料上 midtraining 训练，在五个 DNA benchmark 上超过所测全部开源模型，并媲美 GPT-6.1 Sol，成本约低 1,000x。模型已提供 GGUF 版本，可经 llama.cpp 本地运行，支持用自然语言分析 DNA 序列、预测突变影响和生成新 DNA。
llama.cpp 的 WebGPU 后端在 PR #30914 中新增 Q2_0 量化支持。在 RTX 3060 上用 Dawn WebGPU 实测，Ternary Bonsai 1.7B Q2_0 的 pp512 从 35.03 t/s 提升到 1915.91 t/s，tg128 从 14.02 t/s 提升到 94.75 t/s；Bonsai 2 2B Q2_0 的 pp512 达 2039.89 t/s，tg128 达 71.72 t/s。
CWHISME 在 GitHub 发布跨平台桌面 AI 助手 UiharuMind，通过 llama.cpp 本地运行 GGUF 模型，也可接入任意 OpenAI 兼容 API。支持 Agent 模式（文件读写、shell、联网搜索与工作区文件夹）、角色扮演角色、群聊托管模式、截图 OCR、剪贴板历史、本地语音合成识别与图像生成，权限分只读、自动编辑、全自动三级，数据存于 ~/.uiharu，采用 Apache-2.0 许可证，当前版本为 -alpha。
推荐理由：README 完整列出了本地推理、Agent 权限分级、群聊托管和快捷工具的实现方式，可按需评估是否引入。
MUSE-CODE-SPACE 发布 toolcall-rescue，一个零依赖的纯标准库 Python 包，用于在结构化 tool_calls 字段为空时，从 qwen2.5、Gemma、Kimi、MiniMax 等本地或小型模型以纯文本输出的消息内容中恢复工具调用，支持 Ollama、llama.cpp、vLLM、LM Studio 等 OpenAI 兼容端点。
推荐理由：这是一个可直接落地的本地小模型工具调用抢救库，安全模型讲得清楚，还交代了为何框架核心拒绝收编这一层的取舍。
GitHub 项目 chkalofff/decision-qa 推出 Web 应用「Вердикт」，可向本地 LLM 提问并获取答案概率分布，通过 SGLang（/v1/decisions，MLX 后端）、Cloudflare Clef（/v1/systemone）和 llama.cpp 运行的 GGUF 模型接入，也支持任意远程云模型。多模型可同时运行并对比答案，提供 macOS 与 Windows 安装包、模型管理页面及 API 密钥管理，双模型同时运行约需 64 GB 统一内存。
orcarouter 在 Hugging Face 发布 DeepSeek-V4.1-Flash-1017 去对齐（abliterated）版的 GGUF 量化权重，提供 Mix-256G（235.8 GB 内存占用）与 Mix-128G（114.0 GB）两种构建，基于 763B 参数 MoE 模型，含 197B 参数 Engram n-gram 表常驻 SSD。去对齐后 500 条有害提示拒绝率加权均值从 0.874 降至 0.074，过度拒绝从 0.069 降至 0.006，MMLU 保持 0.91 左右不变。
推荐理由：原文给出实测 KLD、拒绝率与 MMLU 前后对比，读者可据此判断这个去对齐版本到底去掉了多少、能力是否保留。
alexwkleung 用 Heretic 对 XHToken/Spark-X2.6-4B（dense 4.1B 思考模型）做定向消融，发布 abliterated GGUF 权重，并用 llama.cpp 量化出 Q4_K_M 到 Q8_0 多档。与官方 Q8_0 对照：拒绝率从 43/44 降到 0/44（thinking 开与关均如此），GSM8K n=100 为 88/100 对 91/100，McNemar p=0.45 未检出数学回归；代价是思考开启时平均约 5k tokens（stock 529），部分超出 8192 预算，无拒绝系统提示可将其减半。
推荐理由：原文给出与官方 Q8_0 逐位对照的拒绝率、GSM8K 和思考开销数据，可据此判断这个去对齐版本的实际代价。
AbliteratedOutTheBox 是一个 llama.cpp 分支，能在加载模型的推理过程中实时执行 abliteration，无需微调、不产生额外文件，也不需要更多 VRAM。这省去了常规 abliteration 流程的繁琐操作。
Reddit 用户 /u/GapNew4766 在 M5 MacBook Pro 32GB 上用 Qwen3.5-4B（Q4_K_M、64K 上下文、llama-server）对 Pi、goose、Crush、Cline、OpenClaw、OpenCode、Hermes、Qwen Code、Codex CLI、Atomic Agent 共 10 个 Agent 框架各跑 5 个小任务，10 个中 6 个全部通过。失败不来自工具调用解析，而是精确匹配编辑无法逐字节复现旧文本导致反复重发、只修可见测试用例、数错 ERROR 行（40 vs 43）、模糊指令被字面执行写错位置；相同硬件和模型下最快框架 1m36s、最慢 17m43s，快 11 倍。