新闻、仓库与研究，按时间排列。
Praecise 在 GitHub 发布 praecise-engine，一个位于应用与推理后端之间的加速层，通过推测解码、硬件感知调优和统一服务接口加速 token 生成，首个支持的后端是 llama.cpp。实测显示 n-gram 自推测在结构化文本上带来 1.5 到 3.5 倍提升（SQL 3.5x），对散文无收益；托管后端（vLLM、SGLang、TensorRT-LLM、transformers）因掌握解码循环而无法被插入推测解码。项目还包含 praecise-host 沙箱化多引擎托管、job 引擎、视频感知管线等组件，整体采用 Apache-2.0 许可。
推荐理由：原文给出实测数据说明推测解码在结构化文本上值1.5到3.5倍、在散文上无收益，并解释了托管后端为什么在结构上无法做推测解码。
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 包。
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 显卡。
ojas1542 在 GitHub 开源 MyInferenceLayerFoundation，一套完全跑在单台 Mac 上的个人 AI 技术栈，用 llama.cpp 本地服务 Qwen3.5 9B（128K 上下文）和 Qwen3 Embedding 0.6B，前置一个 Go 推理层。
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。
推荐理由：原文完整列出了安装方式和监控、基准、自动调参等功能清单，可用于评估这套自托管面板是否覆盖本地推理运维需求。
/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 部署。
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 统一内存。
Reddit 用户 /u/jacek2023 发帖称 Flint 模型已合并进 llama.cpp，PR 在 6 小时后被合并，GGUF 版本托管在 unsloth/flint-GGUF。
GitHub 上的独立社区研究项目 Maxxxel/v100-volta-ai-optimization-lab，在单张 NVIDIA Tesla V100-SXM2（16 GB HBM2）上研究推理性能、agent 可靠性与能效。项目基于 CUDA 12.8 与 llama.cpp/GGUF，累计覆盖 130 个模型挑战者、32 种附加技术、108 个合格因子范围，证据快照为 Matrix revision 237。项目与 NVIDIA、Ollama 等无隶属关系，研究仍在进行，未得出通用最优模型结论。
richardbrownmiami-commits 的 Mr-Red 项目推出面向 Redmi 9 的 32-bit Android（armeabi-v7a）离线 AI 实验构建，基于 llama.cpp 做 CPU 推理，GGUF 模型文件放在 APK 外，支持导入最大 2 GB 的模型，权重通过 memory-mapping 降低 RAM 占用。首个里程碑是可复现的 32-bit 构建，1.5 GB GGUF 能导入但不保证能在 Redmi 9 上加载，实际速度与稳定性需在真机测量。
/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 代码。
一位 Reddit r/LocalLLaMA 用户在 RTX 3080（10GB）+ RTX 3060（12GB）双卡上用 llama-server 运行 Qwen3.8-27B-pi Q4_K_M 量化模型，配合 MTP 草稿推理实现 30-40 tok/s 生成速度，平均 MTP 接受率约 0.75，上下文 75776。该配置用于 Kotlin/Android 的 agentic coding，作者称 dflash2 草稿反而比 MTP 更慢，并征求进一步优化建议。
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 实测，方法可迁移到其他老卡本地部署场景。
BigMoeOnEdge 作者发布自适应流式 Planner，作为 llama.cpp 之上的资源调度层，在手机、Mac、Windows 笔记本等设备上运行远超内存的 MoE 模型，并提供 OpenAI 兼容本地服务器。实测 Qwen3.6-35B-A3B 在 12GB Android 手机上解码 10 tok/s、NPU prefill 100-300+ tok/s，16GB Mac 上 Planner 将解码从 7 提升到 25-30 tok/s、2000-token prompt 从 21 秒降到 3.4 秒；DeepSeek V4 Flash 284B 在 12GB 手机上 1 tok/s。作者考虑向 llama.cpp 提 PR 集成。
GitHub 仓库 Schaefer42740/llama-terminal-completion 发布 LlamaTerm，一个用 Go 编写的终端 AI 助手，单二进制启动小于 100ms，可用 lt ask 提问、lt cmd 生成 shell 命令。支持 Ollama、LM Studio、llama.cpp、OpenAI、Azure OpenAI，内置多步工具循环的 lt agent、RAG 索引、命名角色与会话、MCP 服务器接入、结构化 JSON 输出和视觉输入，工具调用带确认、危险命令检测与审计日志。
hchen3807 在 GitHub 发布 LlamaServerLauncherAvalonia，一个基于 Avalonia UI 和 .NET 8 的跨平台桌面应用，用于启动和管理 llama.cpp 服务器实例。功能包括多实例管理、基于 GGUF 张量表的 VRAM 占用估算（与实际加载对比）、HuggingFace 下载、基准测试对比、MCP 服务器挂载、OpenAI 兼容的按需模型代理、ComfyUI 显存释放集成及硬件监控。项目地址：https://github.com/hchen3807/LlamaServerLauncherAvalonia
推荐理由：这个 llama.cpp 图形启动器把 VRAM 估算拆到每个张量块，并在加载后与实际占用对比，读者可以据此判断估算是否可信。
一位用户在 Lenovo Legion 笔记本的 RTX 5090 Laptop GPU（24 GB VRAM）上运行 Linux Mint 跑本地 LLM 时，遭遇与 NVIDIA Xid 8 相关的 GPU 挂起。llama.cpp 的相关 issue 指出这是 CUDA graph 求值挂起问题，可用 GGML_CUDA_DISABLE_GRAPHS=1 规避，但会降低性能。用户使用 7.1.13 内核和 595.99.02 驱动，新内核与新驱动均未能正常工作，问题尚无修复。
miminashi 在 GitHub 发布 llm-server-ops，这是一套基于 Claude Code Skills 的 LLM 推理服务器运维工具集，管理 7 台 GPU 服务器上的 llama-server 及相关资源，涵盖 gpu-server、llama-server、discord-notify 三个技能。默认启动 Qwen3.6-35B-A3B-GGUF:UD-Q4_K_XL 模型，上下文长度 131072；aws-gpu01/02 以 RPC 分散配置运行 13 GPU / 200GB。支持 OpenAI 兼容 API、ttyd 监控（7681/7682 端口）及可注册为全局 Claude Code 插件。
Reddit 用户询问在 RDNA2 GPU 上运行本地 LLM 时，除 llama.cpp 外是否有性能更好的替代方案或分支。多数 AMD GPU 相关项目依赖仅 RDNA3 及以上才支持的 WMMA，图像视频生成有时可用 triton 绕过，但 RDNA2 上功能能否使用全凭情况；strata 虽有 RDNA2 路径并成功运行其试用的 coder 模型，但仅适用于一个特定大模型。用户希望找到 Windows 下可用的方案。
llama.cpp 自 v0.7.0 起，llama server 容器内默认端口从 8080 改为 9931（ggml）。未显式设置端口的用户升级后将遇到破坏性变更，硬编码 8080 端口的测试工具也可能受影响。
LocalPilot 是一款硬件感知的 Python 应用，可检测本机 CPU、RAM、VRAM 与 Metal/CUDA 加速能力，按兼容性筛选模型并自动配置 llama.cpp、vLLM、Ollama、LM Studio、Docker Model Runner 等推理后端与执行服务。它提供 6 步引导式安装向导、终端内流式聊天（ChatScreen）、25 类结构化错误码的错误恢复系统，支持 TUI 与 CLI 双界面，可通过 pipx、pip 或 uv 安装。
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%，可自行判断适用场景。
作者 /u/msalsas 发布了 llama-doctor，一个 CLI 工具加实时面板，可指向运行中的 llama.cpp 或 Unsloth Studio 服务器，拉取 /metrics、/props 和 /slots，给出按严重度分级的问题诊断，涵盖 prefill 与 decode、队列压力、prefix cache 复用率和内存余量。退出码映射到严重度，可用于 cron 门控；工具只读、仅依赖标准库、需 Python 3.10+，代码在 https://github.com/msalsas/llama-doctor，作者欢迎 PR，尤其是能让工具崩溃的服务器场景。
推荐理由：作者开源了一个读取 llama.cpp 运行指标并按严重度分级诊断问题的 CLI 工具，退出码可直接接入 cron 做自动门控。
Reddit 用户 /u/ethertype 转发了 llama.cpp 提议的新量化类型 IQ2_K、IQ3_K、IQ4_K、IQ5_K 和 IQ6_K。要点包括：文件大小与 Q-quants 相同，KLD 相比 Q-quants 明显改善，但性能略有下降，且生成 IQ 量化较慢；附 PR 链接 https://github.com/ggml-org/llama.cpp/pull/30715 和测试模型 https://huggingface.co/eaddario/IQ2_K-IQ6_K-Test-Models。
GitHub 仓库 MobitSolidity/marfin-llm 提供面向 CPU 本地运行、波斯语–英语双语金融 LLM 的主系统提示词（SYSTEM_PROMPT.md v2.0）及配套治理文档，涵盖 RAG、MCP/tool calling、TradingView 集成、券商连接与模拟/实盘交易门控。仓库按阶段推进，当前处于 Phase 8，包含决策日志 D-0001–D-0123、Phase 4 失败归因脚本、Phase 6 红队评测（51/51 mutants killed）以及选定 Q4_K_M 量化的 Ollama Modelfile 等部署与安全组件。