按兴趣浏览，循来源深入。
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 的速度对比，老卡复用方案可自行复现验证。
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 和可复算测试，读者可以按需核对每个数字而不是直接信任结论。
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。
推荐理由：原文完整列出了安装方式和监控、基准、自动调参等功能清单，可用于评估这套自托管面板是否覆盖本地推理运维需求。
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 权重，去对齐只降低拒绝、不增加知识。
推荐理由：发布附带了与原版 NVFP4 权重的对照拒绝率和性能数据，读者可以据此评估去对齐带来的质量损失幅度。
作者在相同的 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 秒，数据完整可复现。
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 兼容端点。
推荐理由：这是一个可直接落地的本地小模型工具调用抢救库，安全模型讲得清楚，还交代了为何框架核心拒绝收编这一层的取舍。
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 和思考开销数据，可据此判断这个去对齐版本的实际代价。
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 图像模型本身不画这两类，出图无可见去审查效果。
推荐理由：原文给出了去对齐的具体做法和拒绝率、MMLU、出图差异的前后实测数据，还与同类去对齐 upsampler 做了对照，可按数据自行选量化档位。
pottokao 在 Hugging Face 发布 LiquidAI/LFM2.5-24B-A2B 的去对齐 GGUF 量化版，用 Heretic ARA 去审查后拒绝率从 89/100 降到 0/100，BF16 权重上 KL 为 0.260。所有 attn_output 张量保持 Q8_0，去对齐修改集中在 blk.38.attn_output；IQ3_M 档可在 16 GB 显存单卡运行，模型回答前会先思考，需留较大输出预算。
推荐理由：作者给出了用 Heretic ARA 去对齐前后的拒绝率对比和 KL 数值，并说明各量化档的显存取舍。
/u/woct0rdho 为 llama.cpp 编写了 LoRA 推理 kernel，代码见 https://github.com/woct0rdho/llama.cpp 。在 Strix Halo 上，加载 35 MB 的 LoRA（如把 Qwen3.8-Flash-Next 转成 uncensored 版的 chenrm/qwen3.8-flash-next-abliterated-lora）原本使 PP 从约 1500 降到 300 t/s，通用 kernel 提升到 1000 t/s，fused kernel 进一步到 1400 t/s。LoRA scale 可调节去审查与能力损失之间的平衡，且无需重新下载整个模型。
推荐理由：作者给出了 LoRA 推理在 Strix Halo 上从 300 到 1400 t/s 的实测数据，并开放了可复用的 kernel 代码。
作者发布 Ternary-Bonsai-2-27B-Abliterated-PQ2_0-MTP-Q4_0-GGUF，在 Hikari07jp 的 abliterated 构建基础上把 MTP 草稿头从 Q8_0（430.41 MiB）重量化为 Q4_0（227.91 MiB），使组合能在 8GB 显卡上运行，实测 RTX 3070 上 45.7 tok/s、7 724 MiB 显存。主干与 abliterated 构建逐位一致，仅 blk.64.* 不同；因 MTP 头只是草稿、输出由主模型验证，困惑度 8.4593 与无头版本 8.4557 在测量误差内，200 个贪心 token 零分歧。
推荐理由：作者给出逐字节校验和 RTX 3070 8GB 实测数据，说明把 MTP 头降到 Q4_0 后为何不损失输出质量。
jpsanders 发布 pascal-llm-stack 仓库，给出在 Ubuntu 26.04.1、kernel 7.0 上让 GTX 1060 Mobile 6 GB 运行本地 LLM 的完整脚本，包括给 NVIDIA 570 驱动打 kernel 7.0 补丁、用 CUDA 12.8 runfile 避开 apt 的驱动破坏、回退 torch 2.7.1 获取 Pascal 内核，以及用三个 cmake 参数编译 llama.cpp。
推荐理由：作者在 GTX 1060 上逐层修通驱动、CUDA 和 PyTorch 并给出 llama-bench 实测，方法可迁移到其他老卡本地部署场景。
hchen3807 在 GitHub 发布 LlamaServerLauncherAvalonia，一个基于 Avalonia UI 和 .NET 8 的跨平台桌面应用，用于启动和管理 llama.cpp 服务器实例。功能包括多实例管理、基于 GGUF 张量表的 VRAM 占用估算（与实际加载对比）、HuggingFace 下载、基准测试对比、MCP 服务器挂载、OpenAI 兼容的按需模型代理、ComfyUI 显存释放集成及硬件监控。项目地址：https://github.com/hchen3807/LlamaServerLauncherAvalonia
推荐理由：这个 llama.cpp 图形启动器把 VRAM 估算拆到每个张量块，并在加载后与实际占用对比，读者可以据此判断估算是否可信。
kevinelong 在 GitHub 发布 local-llm-lab 仓库，记录在一台 64 GB DDR5、RTX 5070 12 GB 的 Windows 桌面机上对本地大模型的系统实测，并列出 693 项检查的九套基准。最佳配置为 Qwen3.6-35B-A3B Q4_K_M 经 llama.cpp 预配置（context 131,072、--cpu-moe），以及由 Strata 流式从磁盘服务的 Qwen3.8-Flash-Next Q2_0，两者在排名指标 414/414、全部九套 692/693 上逐格持平，后者的 1,100 项知识测试快 31%。
推荐理由：作者在固定一台桌面机上实测本地模型的匹配度、速度和分数，并公开预测记录与纠错，方法可迁移到自己跑本地评测时参考。
Guillaume2561 发布 LlamaServerLauncherAvalonia，一个基于 Avalonia UI 和 .NET 8 的跨平台桌面应用，用于通过图形界面启动和管理 llama.cpp 服务器实例。功能包括 GGUF 模型元数据读取与 VRAM 占用预估、多实例管理、基准测试对比、MCP 服务器挂载、OpenAI 兼容的按需模型代理、ComfyUI 显存释放集成，以及 llama.cpp 版本下载与回滚管理。项目地址：https://github.com/Guillaume2561/LlamaServerLauncherAvalonia。
推荐理由：这个跨平台图形启动器把 llama.cpp 服务器的参数配置、VRAM 预估、基准测试和多实例管理整合到一个界面里，适合本地部署用户参考。
Fox 是一个面向并发负载的本地 LLM 服务器，可作为 Ollama 的直接替代，MIT OR Apache-2.0 双许可，改端口即可兼容现有 Ollama 与 OpenAI 客户端。它包装 llama.cpp，核心优化是并发请求间的共享前缀 KV cache 复用：新请求匹配最长共享前缀跳过 prefill，还能从正在解码的序列复制共享前缀，这是其他 llama.cpp 服务器做不到的。在 Radeon 890M Vulkan 测试中，16 客户端共享系统提示词时 TTFT p50 为 1402 ms 对 llama-server 的 8064 ms，但短独立提示词的单轮请求吞吐约为基线的 96%，反而慢约 4%。
推荐理由：README给出了共享前缀并发场景下与llama-server的对比数据和复现脚本，也坦承短独立请求反而慢约4%，可自行判断适用场景。