新闻、仓库与研究，按时间排列。
用户在 16GB VRAM 上用 llama.cpp 测试 NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB-GGUF（IQ2_XSS 官方量化），20k 输入、贪心解码下 v0.7.0 达 168.8 tok/s，为各构建方案最佳，其余变体差异在噪声范围内。Strata 风格的专家路由 profiler 经 #30594 可用于 llama.cpp，但混合模式因 PCIe Gen5 x16 上传快于 CPU 计算而降至 89–98 tok/s；GPU 缓存预热后命中率约 82%。专家缓存 7.5 GB 为安全上限，draft 默认设置（每步 3 token、无置信阈值）最优。
mradermacher 在 Hugging Face 上提供 NeoHorse-1-9-Uncensored-i1-GGUF 量化模型（如 Q4_K_S 版本），可通过 llama.cpp 直接运行。该模型支持 llama serve 启动本地 OpenAI 兼容服务器，也可在 Ollama、Docker Model Runner、LM Studio、Jan、Pi、Hermes、OpenClaw 等工具中使用。
Costume/christAIn-uncensored-Q4_0-GGUF 由 Emmet-Allen/christAIn-uncensored 经 llama.cpp 转换为 GGUF 格式，通过 ggml.ai 的 GGUF-my-repo 空间生成。模型可通过 llama-cli 或 llama-server 直接调用，server 模式支持 -c 2048 上下文设置，也可在 llama.cpp 仓库中按步骤编译后运行推理。
hokanosekai 发布 llama.kt，一个 Kotlin/Android JNI 绑定，可在设备端加载任意 GGUF 模型运行推理，无需服务器或云端，原生 C++ 引擎提取自 llama.rn 并以纯 Kotlin API 重新暴露。在 OPPO（MediaTek Dimensity 900）上验证，Qwen2.5-0.5B（q4_K_M）CPU 约 20 tok/s；实测显示稠密模型在大核 CPU 上最快，Vulkan 仅对 Gemma 3n/4 更优，8GB 级设备可用上限约 4B 量化模型。多轮对话通过 KV cache 前缀复用，4 轮后 TTFT 保持 1.7–2.4s，而完整重预填充约需 48s。
推荐理由：作者在真机上给出多款模型的 CPU 与 Vulkan 后端实测数据，读者可据此判断这类端侧 GGUF 推理方案的实际可用规模。
一位用户在本地运行 SillyTavern 并通过自建服务器连接 llama.cpp 使用 Qwen3.6 时遇到输出不稳定问题：模型有时只输出一行，有时输出大段 "Here is a thinking process" 思考块和乱码标签。用户尝试了 jinja 模板、"derive from model metadata" 选项、在 System Prompt 添加标签以及 --reasoning-budget 0 参数均无效，且角色扮演中的 Impersonating 功能完全无法使用，在论坛求助通用模板。
Reddit 用户 returnity 发布自维护的 Qwen3.8-Flash-Next 聊天模板 v1.4/v1.5，修复了工具参数 JSON 字符串渲染失败、空块重放等问题，并移植 27B Sharp 的简洁块形成可选的 terseness 模式。实测在 llama.cpp 上 Flash-Next UD-Q5_K_XL、thinking off 时回答 token 减少 61%，thinking on 时减少 40%；作者提醒简洁模式会略降准确率。
donghanasd 在 Hugging Face 发布 Huihui-Qwen3.8-27B-Coder390-EfficientThink-abliterated 的韩语校准混合精度 GGUF，约 12.60 GB、3.69 bits per parameter，从上游 BF16 GGUF 直接量化。量化使用 708 个 512 token 块收集的 importance matrix，张量精度分配沿用 Qwen3.8-27B-Ridge-GGUF，保留 tokenizer、chat template 和 MTP tensors，未做韩语额外训练也未验证韩语质量提升。
GitHub 上的 ollama-dl 工具可从 Ollama 库直接下载模型，无需安装 Ollama。安装 uv 后运行 `uv run -m ollama_dl llama3.2` 即可自动装依赖并下载 Meta Llama 3.2 默认最新版本，也可指定 llama3.2:1b 等具体版本。下载的 GGUF 文件可直接在 llama.cpp 中运行推理。
Mellum2.1 是 Mellum2 Thinking 的下一版本，架构不变，为 12B 总参数、2.5B 激活参数的 MoE 模型，主要工作在强化学习后训练：新增数学、竞赛编程、科学、工具使用和软件工程的 RL 任务，并在真实代码仓库中用 shell 和文件编辑工具训练智能体能力。模型支持 131,072 上下文长度、64 个专家（激活 8 个），采用 bfloat16 精度，以 Apache 2.0 许可开源。
webmp3 在 Hugging Face 上提供 Sakura-FLUX.3-Image-Klein-TextEncoder-Uncensored-GGUF 模型，默认量化版本为 Q4_K_M。该模型可通过 llama.cpp 的 llama serve / llama cli 直接运行，也支持 Docker、Ollama、LM Studio、Jan、Pi、Lemonade、Hermes Agent、OpenClaw 等多种本地部署方式。
Drama3 现已获得 audio.cpp 支持，在 RTX 5090（Q4_k）上全速运行最高可达 5 倍实时速度，采用 CPU weight offload 分级释放模式时低于 8 GB VRAM 也能达到约 2 倍实时速度（RTF 0.484）。该模型还支持 Vulkan 和 Metal，目前仍存在多说话人生成出现异常静音、Vulkan 触发 token 上限等问题，需更多迭代才会进入正式版本，社区贡献者欢迎参与优化。
Ternary 发布基于 Qwen 3.5 的 Bonsai 2 系列模型，提供 2B、4B 和 9B 三个规格。模型现已支持原版 llama.cpp 运行，并支持 dFlash、MTP 与 MLX 以提升 TPS，iOS 上可通过 LocallyAI 最新版测试。作者计划验证其是否延续以往 Bonsai 模型的循环行为，并与 Qwen 3.5 1.7B/0.8B 对比表现。
GitHub 上的 local-mailroom-sandbox 是一个本地优先的 LLM-Mailroom 流水线实验沙盒，可在 Ollama、vLLM、llama.cpp 或 LM Studio 上离线运行 classify → extract → report → archive 全流程，需要 API 时可切换 OpenRouter。默认模型为 Ollama 的 qwen3:8b（回退 qwen3:7b），流水线为 13 节点 LangGraph 状态机，评分用 vendored 的 llm-dojo-scoring，追踪用 Langfuse，存储为本地 SQLite。
开发者在 Reddit r/LocalLLaMA 发布终端编程智能体 Fade v0.5，MIT 协议开源。它同时运行两个智能体：对话智能体与用户讨论规划，Builder 在侧栏写代码，无需等待任务完成；每次改动生成测试等证明并自动重跑验证，通过后以 git commit 落地。支持 Pi 所兼容的任意模型（含 llama.cpp 本地模型），两个智能体可用不同模型。
Damel91 发布 llama-runtime v0.4.1，一个面向 llama.cpp / llama-server HTTP 服务的 Python 库（发行名 runtime-llama），需 Python 3.11+，唯一运行时依赖为 requests。它为文本生成、流式输出、结构化对话、推理内容分离、工具调用与 MCP 数据契约、嵌入任务前缀与批量调度提供统一客户端 API，支持副本发现、并发准入与背压控制，采用 Apache-2.0 许可证。
推荐理由：为 llama.cpp 推理服务提供统一的 Python 客户端层，把流式输出、工具调用与嵌入批处理封装成可复用接口。
LiquidAI 的 LFM2.5-24B-A2B 在 Pi Agent 中表现可靠，作者用它替换 Ornith 1.5-35B 后运行良好。在 AMD W7900 上经 llama.cpp（ROCm）实测持续约 95 tps，Q8 量化加 128k 上下文占用 30GB 显存，机械性长任务稳定通过。
Agent Lab 是一个 local-first 工作台，用于测试小语言模型在有界项目工作上的表现，由 harness 提供工作区、受限工具目录、workflow gates、持久化和独立任务评估器。默认通过 llama.cpp 运行本地 GGUF 推理，当前配置指向 Gemma 4 E2B，也可选用 OpenAI 兼容 API。项目定位为学习与演示用途，输出的是 harness 各部分对小型模型增益的证据。
Reddit 用户转发 ggml-org/llama.cpp 的 Pull Request #29353（am17an 提交的 cuda/hip GDN chunked kernel），并附多组推理速度对比。RTX PRO 6000 Blackwell 上 Qwen3.5-35B-A3B-Q8_0 在 2048/4096 prompt tokens 下分别提升 20.6% 和 17.8%，RTX 5090 上同模型 Q4_K_S 提升 16.4%-17.9%，RTX 4090 提升 10.8%-11.1%，Qwen3.8-27B 在多卡上提升约 0.9%-6.4%，Spark GB10 上各模型提升约 3.4%-5.7%。
Jakevin 在 Hugging Face 发布 abliterated 版 LiquidAI/LFM2.5-24B-A2B 的混合精度 GGUF，移除了大部分拒绝行为。模型按 IQ3_M/Q4_K/Q8_0 混合量化，对第 14–39 层的 out_proj 和专家 w2 权重应用双向投影拒绝方向。需 llama.cpp b9810+ 的 lfm2moe 支持，8k 上下文下生成约 83 tok/s、峰值内存约 10.9 GB，采用 LFM Open License v1.0。
candor-lab 在 Hugging Face 发布 Llama 3.2 3B Instruct 的去对齐版本，通过 Candor 权重编辑工具对注意力和 MLP 输出矩阵做 rank-1 修改，移除模型拒绝指令的方向。实测显示该文件对 288 个有害提示词只拒绝 6 个，而普通 Q4_K_M 量化版拒绝 161 个；团队指出该权重此前经过 4-bit 量化，再次量化会损失 30-45% 的编辑效果，因此将 49 个被编辑矩阵保留在 Q8_0。测量基于 StrongREJECT、Alpaca 提示词与 GSM8K，在 llama.cpp llama-server 中以实际发布文件进行，结果与 heretic 的最佳试验无统计显著差异。
推荐理由：发布方实测了量化后文件的拒绝率与 KL 散度，指出先量化后去对齐会让编辑效果损失三到四成。
作者发布 Llamaforge v0.16，这是一个驱动上游 llama.cpp 的浏览器控制面板，不改动 llama.cpp 本体。加载模型前按本机实测大小显示模型在各 GPU 上的落位，不合适会提示，支持多模型同时运行且主模型占用最快 GPU、worker 模型避开该卡。v0.16 新增 embers 本地 agent，夜间读取指定来源生成 wiki 和晨间简报，每条论断必须逐字引用来源并由代码对照快照校验，不匹配即丢弃；agent 无浏览器和工具，除非开启推送否则数据不出本机。
推荐理由：作者实测了 llama.cpp 面板的多 GPU 显存预估与本地 agent 引用校验机制，读者可了解其部署与防幻觉做法。
D2ziggy/Qwen2.5-1.5B-Instruct-abliterated 已通过 ggml.ai 的 GGUF-my-repo 转换为 Q8_0 GGUF 格式并上线 Hugging Face，可用 llama.cpp 的 llama-cli 或 llama-server 直接加载运行，服务端示例上下文长度为 2048。模型卡还给出从 GitHub 克隆 llama.cpp、用 LLAMA_CURL=1 编译及 LLAMA_CUDA=1 等 GPU 标志的构建步骤。
44sunsetsf 公开 DAT300 第 7 组项目，在 Raspberry Pi 集群上用 llama.cpp 跑 Llama-3.2-3B-Instruct Q4_0，对比流水线并行与张量并行并定位瓶颈：单台 decode 受内存带宽限制（1.85 tok/s），2 台 TP 每个 token 同步 56 次，原版在 4/8 台时全经主控中转，模拟 8 台时每 token 有 4164 次串行网络延迟。其 fork 的 dat300 分支实现任意 2/4/8/16 台直接 allreduce，模拟 8 台时串行延迟次数少 19 倍；rpc-server 用 -t 3 后 2 台 TP 从 2.31 提到 2.93 tok/s，输出层改 Q4_0 再快 9% 至 3.19，困惑度仅差 0.6%。
/u/naklitechie 把上周的磁盘流式加载 MoE 专家方案接到 llama.cpp 自带的 WebGPU 后端，Qwen3-Next 80B-A3B（48.4 GB Q4_K_M GGUF）在 Chrome 标签页中成功运行，MacBook Pro M4 Pro 上加载 48 秒、解码 2.9 tok/s，并称是概念验证。方法是把 GGUF 一次性下载到浏览器 OPFS 私有存储，GPU 只保留稠密层、KV cache 和每层固定数量的专家槽位，路由选中的专家不在槽位时从磁盘按 LRU 换入；分页开关下 OLMoE 与 LFM2 各 9 段对话回复完全一致，对 Metal 后端 9 条中 4 至 8 条一致，差异来自 WebGPU 与 Metal 的舍入。
推荐理由：作者给出各模型的加载时间、解码速度和分页正确性对照数据，可据此评估在浏览器标签页里跑 MoE 的实际可用度。
hotdogs/Ternary-Bonsai-2-27B-Abliterated-Hemmingway-1-MTP 模型已在 Hugging Face 发布，默认量化版本为 Q2_0。文档给出 llama.cpp 的 macOS、Linux、Windows 安装方式及本地 OpenAI 兼容服务器启动命令，并说明在 Ollama、Docker Model Runner、Pi、Lemonade、Hermes Agent、OpenClaw 等工具中加载该模型的具体配置步骤。
伦敦一位全科医生开发了全本地运行的临床助手 OpenConsult，在单张 RTX 4090 上实测如何把自动提问的响应压到 3 秒内。MedGemma 27B (Q4_K_M) 每轮需 18 秒，Gemma 4 26B-A4B QAT 降至 5 秒且临床评分相当；vLLM 比.Ollama 和 llama.cpp 快至 3.5 秒，但占用 94% 显存；把一轮的两次调用合并发送后 vLLM 降到 2.8 秒。模型输出约 170 tokens/秒，另测了 Qwen3.6-35B-A3B、Nemotron 3.5 Lightning 和 gpt-oss-20b，Gemma 4 仍最快。项目以 AGPL-3.0 开源，作者在征求进一步提速与 CPU offload 建议。
Reddit 用户 regunakyle 发帖询问如何本地运行 vLLM 发布的 d3 决策模型系列，llama.cpp 已支持。帖主询问决策模型对量化是否敏感（参照 qwen-2.5-coder FIM 模型建议 Q8 而非 Q4 的经验）、是否比模型本身占用更多 VRAM，以及是否应像 MoE 模型一样把权重拆分到 RAM——帖主认为其基座 qwen 是 dense 模型，应仅存于 VRAM。
一位 Reddit 用户分享 Strata 推理加速体验：加载 qwen3.8-flash-next-unsloth-ud-q4_k_xl、fp16 KV、130k 上下文时，长提示预填充（PP）从 llama.cpp 的 10 分钟缩短到 23 秒，文本生成速度约 3 倍（约 57 tok/s），expert cache 命中率 94.5%。用户连续使用约 10 天，结果稳定，且近期更新后速度进一步提升。
GitHub 项目 PEPAR 用本地 LLM 翻译 arxiv 等英文论文网页，替代已部分收费的 papago 和忽视上下文的 Chrome 翻译。后端采用 Python 3.11 与 Flask，通过 llama.cpp 搭配 Intel Arc Pro B50 16GB 运行 gemma4-12b；关闭 thinking 模式后请求耗时从 150 秒降至 13 秒。项目用 Tailscale 内网部署，支持失败块重译、任务进度显示与 Docker 打包发布。
一名高中生用自研 C++ 引擎（llama.rn 的 fork）通过 USB RPC 把 Ternary-Bonsai-2-27B（2.06 bpw / 6.52 GiB，PPL 14.26）分层部署到两台 Android 手机上集群运行，集群模式速度约 2.8 tok/s，单机 Xiaomi 15 达 5.6 tok/s。权重以三值（-1, 0, 1）存储在 Hadamard 旋转基中，运行时在 ARM CPU 上应用 Hadamard 变换，只需加减运算、无 MAC 操作，最高温度约 30°C。
MorinoNushi 发布 GLM-5.3-Flash（320B 总参/18B 激活 MoE，MIT 协议）的去对齐 LoRA 适配器 V3，用 heretic-gguf 对量化 GGUF 权重做 Optuna 优化的方向性消融。有害提示拒绝率从 V2 的 35/140 降至 14/140（10.00%），KL 0.2380 也低于 V2 的 0.3030；适配器约 86 MB，无需改动或重新量化约 160 GB 基座权重，可直接在主线 llama.cpp 上以 --lora 方式加载，不再需要 fork 或补丁。
推荐理由：原文给出消融方法、拒绝率与 KL 前后对比数据，读者可以据此判断 V3 相对 V2 实际去掉了多少拒绝行为。
Reddit 用户 vitamins1000 在双 A100 80GB（PCIe Gen4 x8）+ EPYC 7402P 的 Proxmox 直通配置上运行 llama.cpp 和 qwen3.8 flash next UD-Q4_K_XL，上下文设为 1835008（7 个 262k slot）。单用户生成速度约 50-70tk/s，但 2-3 用户并发时骤降至 10-15tk/s。楼主用于长会话 agentic 编码场景，询问是换 vLLM 还是每卡各跑一个 qwen3.6-35b-a3b，并倾向 MoE 模型。
Northlatch Labs 开源 Kestrel，一个面向 Intel Mac 加 AMD 独显（含 Hackintosh）的本地大语言模型应用，内置 AMD 补丁版 llama.cpp 和 SwiftUI 界面。RX 6700 XT 上 Qwen3-8B 生成从 0.6-2.6 t/s 提升到约 61 t/s，支持多会话、Agent 工具与 MCP、OpenAI 兼容 API、图像生成（beta）和多 GPU 拆分；仓库地址 https://github.com/0xda7/kestrel，许可 GPL-3.0。
推荐理由：原文给出 RX 6700 XT 上各模型的实测算速和与 Apple Silicon 的对照数据，可以据此评估 Intel Mac 加 AMD 显卡跑本地大模型的可行性。
Reddit 用户在 16GB VRAM 上以 Q4 量化运行 unsloth/Qwen3.8-27B-UD-IQ4_XS，实现 262k 上下文、q4_0 KV 缓存和视觉能力，MTP 基准约 80t/s、pp 1500。关键在于修改版 llama.cpp-adaptive-kv-streaming 分支，将 KV 流式传输到系统内存的 1.5GB arena；262k 全上下文时约 20t/s、pp 400t/s，作者称对许多人仍属可用。
Helminiak 发布的 LLM-Setup 仓库旨在把本地大语言模型部署从零散命令整理为可复现、可回滚的工程化配置。内容涵盖 llama.cpp、LM Studio、vLLM 等运行时的启动配置、OpenAI 兼容本地 API、GPU/CPU offload、KV-cache 与上下文窗口实验、基准测试脚本及 speech-to-text 与 RAG 文档。基准测试须记录模型与量化版本、GPU 层数、tokens/second 等信息以区分性能变化与配置漂移。
GitHub 仓库 Lzh-Function/LLM-app 提供在 WSL2 + Dev Container 环境下运行本地 LLM 的一套工作环境，集成聊天、图片提问、网页检索、语音对话、语音作品制作与本地 Codex。环境基于 RTX 5070（VRAM 12GB）、64GB RAM 实测构建，支持 Qwen3.5-9B、Gemma 4、Bonsai 2、Qwen3.8 Flash Next 共 4 个模型，其中 Flash Next 上下文默认 128K，Codex 分别为 Qwen3.5-9B 提供 131,072 token、Bonsai 2 提供 98,304 token。
JakeATX 发布面向 RTX 3090 / 3090 Ti（SM86）的 llama.cpp 分支 llamAmpere v0.5.4，运行带 MTP draft head 的 Qwen3.8-27B。v0.5 新增压缩 KV 缓存 SJ-KVaRN（4/4、3/3t、3/2t 配置），4/4 下比 v0.4 的 tq5_0/turbo4 缓存 KL 低 41%、缓存显存多 2%，262,144 token 上下文在 24 GB 单卡 4/4 配置下峰值 21,924 MiB；100K 深度任务基准上 tq5_0/turbo4 较 v0.4 提速 +8.41% ± 5.76%，SJ-KVaRN 4/4 为 +6.77% ± 2.68%。
推荐理由：原文给出了SJ-KVaRN压缩KV缓存的KL对比、显存占用和多种配置的实测tokens/s数据，读者可据此评估在单张RTX 3090上跑27B模型长上下文的可行性。
/u/asfbrz96 在 Strix Halo（Radeon 8060S、128 GB）上为 llama.cpp fork strix-llama.cpp 开出 rdna35-perf 分支（10 commits，仅 ROCm/HIP）。prompt processing 比 Vulkan 快 21–54%、比原版 ROCm 快 8–174%，领先幅度随上下文深度扩大；生成速度与 Vulkan 打平或落后 2–3%。作者用 KL 散度和 32k 困惑度验证输出质量不变，主要改动包括 RDNA3.5 flash attention kernel、量化 GEMM 调优、MoE 与 Gated DeltaNet 的 decode 融合。
推荐理由：作者给出三种模型在 0k 到 128k 多档深度下的完整实测表，并用 KL 散度和困惑度验证输出未变，数据可直接复现。
Hunter174 发布面向 Godot 4.4 的 GDExtension SaLMoN，通过 llama.cpp 本地运行 GGUF 模型，提供聊天、SemIf 风格语义决策和嵌入向量三类能力，运行时无需 Python、云推理、API 密钥或网络。目前为开发预览版，需从源码构建；Windows 上 Godot 4.4.1 全新导入已通过实测，Godot 4.5+ 全新 headless 导入因上游回归暂不支持（issue #11）。异步加载与推理每节点最多 32 个未完成请求、8 个已加载模型；AVX2 测试机上 native 调优把 Qwen3-0.6B 语义演示从约 16 秒降到 2 秒以内。
推荐理由：原文给出了完整 API 契约、构建步骤与实测数字，开发者可据此评估在 Godot 4.4 本地跑 GGUF 模型的可行性。
thehiddenone 在 GitHub 发布 Kōdo，一个把自然语言转为可运行代码的 AI 编码助手，采用多智能体 LLM 工作流，以 VS Code 扩展加本地 Python 服务器形式运行，支持 llama.cpp 下运行 GGUF 本地模型，也支持 Anthropic、OpenAI、DeepSeek、OpenRouter、AWS Bedrock 等云模型。内置约二十多个模型条目的目录、按显存与内存的硬件适配检测、可断点续传的下载管理器，以及 grammar 约束的工具调用解析等本地可靠性加固。
推荐理由：README 直言引导模式尚未完整验证、本地小模型仍逊于前沿模型，读者可以据此判断项目的真实成熟度而非宣传口径。