开发者实测推理引擎加速选项对模型输出的损害
一位开发者在RTX 5090等硬件上测试Basalt引擎的路由偏置与专家跳过两项加速选项,发现其显著改变模型输出:Q8_0在默认设置下KLD从0.031升至0.401,最差设置下达1.616,top-1一致率降至56.8%。
llama.cpp 是一个开源的本地大模型推理项目,支持 GGUF 格式模型在 CPU、GPU 及多种设备上运行。近期报道包括:修复 Pocket-TTS 组件中由恶意 mmproj 文件触发的堆越界写入漏洞(升级至 b11796)、合并张量转换 PR #31028 导致需重新转换 GGUF 文件、llama server 默认端口从 8080 改为 9931。此外,Cohere 宣布其 North Micro Vision Instruct 视觉编码器已并入 llama.cpp,社区还在讨论 IQ2_K 至 IQ6_K 新量化类型。
一位开发者在RTX 5090等硬件上测试Basalt引擎的路由偏置与专家跳过两项加速选项,发现其显著改变模型输出:Q8_0在默认设置下KLD从0.031升至0.401,最差设置下达1.616,top-1一致率降至56.8%。
开发者发布Betelgeuse(基于llama.cpp的分支),在RTX 3060 12GB加16GB DDR4内存的普通PC上,以22 tok/s持续速度(峰值48 tok/s)运行68GB的Qwen 3.8 Flash Next MoE量化模型,且无门控剪枝、保持100%比特一致。此前标准llama.cpp在该配置下仅约1.47 tok/s。
用户测试显示,在llama.cpp v0.8.0上为Qwen3.8-Flash-Next启用DFlash2草稿模型后,解码速度几何平均提升约17%:代码+18%、列表+39%、散文略降3%。DFlash2草稿头仅约350MB,远小于MTP的2.2GB,且支持视觉输入。
llama.cpp的Pocket-TTS组件被曝存在堆越界写入漏洞,恶意mmproj文件即可触发,攻击需本地访问且利用代码已公开。升级至b11796版本可修复,但根治性补丁仍未合并。
开源项目llama.cpp合并了名为“convert时合并张量”的拉取请求(#31028),由贡献者am17an提交。该改动可能意味着用户需要重新转换已有的GGUF模型文件。
用户展示用8GB显存加24GB内存运行ISTA DASLab的3.5 BPW Qwen-Flash-Next Coder量化版,借助MoE卸载和磁盘n-gram实现262K上下文,预填充约70 T/s、生成约8 T/s。该量化剪除一半专家,等效1.89比特/参数,但实际权重仍为3.5 BPW。
ISTA-DASLab采用GSQ-RCO量化方法发布DeepSeek-V4.1-Flash-1017的GGUF量化版本,已上线Hugging Face。由于原始架构支持尚未合并,llama.cpp暂不支持该模型。
一名开发者在LocalLLaMA分享称,可自行搭建推理引擎:通过GLSL将GGUF Q4分页载入WebGL2计算缓冲,直接在网页内运行;但分词器与词表处理极为繁琐,调试困难。该实验显示浏览器端本地推理可行,但工程成本高。
一名用户在多款本地推理框架中测试LFM2.5-24B-A2B量化模型,称其在Hermes代理任务中生成代码有缺陷、功能缺失,并在部分框架下反复循环,认为其表现不佳。
一位用户在二手约2000欧元的PC(RTX 3090、128GB DDR4、i9-9900X)上,用1-bit量化的DeepSeek-V4.1-Flash-1017配合llama.cpp,以7.2 tok/s运行了这个748B参数模型。110GB的Engram表留在NVMe上按需读取,从而装入内存。用户称输出存在物理错误,实用价值有限,Qwen模型在其设备上表现更好。
Eagle-4 在 Qwen 3.8 27B 上实现 3.59 倍加速,超越 DFlash2 的 2.80 倍和 DSpark 的 2.57 倍。目前仅支持 Qwen 3.8 27B,但社区期待其集成到 llama.cpp/vLLM。
AnyLanguageModel 1.0正式发布,可替代苹果Foundation Models框架,让开发者通过统一API在系统模型、llama.cpp、MLX、Core ML本地模型及OpenAI、Anthropic等托管服务间切换。同期发布的swift-huggingface 1.0与swift-xet 1.0加速模型下载。
Cohere员工Nick Frosst在r/LocalLLaMA发帖称,团队已将North Micro Vision Instruct视觉编码器的llama.cpp支持合并,至此Cohere所有最新架构均可兼容llama.cpp。该视觉模型是Cohere多款新品的基座;此外语音转文字模型Cohere Transcribe已上线Unsloth与Unsloth Studio供微调。
从v0.7.0版本起,llama server的默认端口由8080改为9931。未显式设置端口的用户在升级时会遇到不兼容问题,而将8080硬编码的工具也需相应调整。
LocalLLaMA社区讨论llama.cpp新增IQ2_K、IQ3_K、IQ4_K、IQ5_K和IQ6_K量化类型。其文件体积与Q系列量化相当,KLD明显改善,但性能略有下降,且生成IQ量化速度较慢。目前测试数据仅来自单一模型。
开发者借助llama.cpp RPC,将560B MoE的Ling 3.1 Flash(每token激活25B参数)分载于四台DGX Spark,使用Atomic Chat首发的Q4 GGUF,因当时无vLLM官方FP4版本。作者预计带宽与速度表现不佳,希望与124B的Ling 3.0 Flash对比实际体验。
LocalLLaMA用户称,常见GGUF中置于SSD的PLE(n-gram表)被大幅量化,影响模型表现;其用ple_fp8_pack.py打包FP8版PLE后,iq3_s量化模型出错明显减少且速度不变,仅多占磁盘。所需safetensors文件来自Qwen FP8仓库,打包后通过--ple-gguf参数加载。
一名荷兰用户讲述自2025年3月起在本地运行大模型的经历:从Mistral Nemo起步,沿用SillyTavern与llama.cpp,并升级为双RTX 5060 Ti 16GB,期待llama.cpp支持张量并行与NVFP4。
一名LocalLLaMA社区用户发布长文,介绍Qwen 3.6 27B借助llama.cpp可实现的十项用法,包括自制小应用、自定义聊天前端、ReAct循环和MCP工具等。作者称该模型是其首个智能体,并希望帮助新用户快速上手开源模型。
PS5LM项目利用llama.cpp的Vulkan后端,在越狱PS5的RDNA 2 GPU上运行GGUF模型,并作为本地服务器提供OpenAI和Anthropic兼容API。
AnythingLLM将后端从Ollama迁移到AMD的Lemonade嵌入式SDK和llama.cpp。此举反映出本地LLM推理工具链的整合,AMD开发者对此表示欢迎。
AWS发布指南,介绍如何在Amazon SageMaker AI上使用llama.cpp部署决策模型,帮助开发者在托管环境中运行轻量级推理。
开源医疗AI工具包OpenMed发布3.0版,采用Apache-2.0许可,数据全程留在本地、可离线运行。新版本加入Patient Journey功能,可将病历、FHIR、HL7、检验CSV等多来源数据整合为单一患者时间线,并对存疑信息拒绝猜测、保留双版本以待人工审核。
开发者发布开源Mac应用DigUp,利用Google DeepMind的EmbeddingGemma 2在本地按内容搜索文本、图像、音视频,基于llama.cpp与Metal,采用865MB Q8_0 GGUF模型,无需Python,免费且为MIT许可。
一位开发者分享,通过预测MoE专家路由加速CPU/GPU卸载,在RTX 3060 12GB加16GB内存上以约21 tok/s运行68GB的Qwen 3.8 Flash Next量化模型,且未做门控剪枝、保持比特精确。热缓存下可达24 tok/s以上,相比原版约1.4-2.1 tok/s大幅提升。
一名用户用8张二手Radeon Pro V620(共256GB显存)搭建约2800美元的推理主机,并通过定制vLLM分支运行Qwen3.8-Flash-Next,解码速度达每秒60至100个token,预填充超过每秒3000个token,比llama.cpp快约8倍。
有用户在单张RTX 4090上对比了Laya、d1 3B、Clef-Flash 9B和Lev 4B四款新开源决策模型。任务为逐词识别9,534词维基文本中的蜈蚣名称:Laya每词耗时3.9毫秒、约32秒处理7,980词、准确率97.4%,为整体最快;Lev最慢但任务命中率最高。
llama.cpp 相关演讲登上舞台,该项目由 Georgi Gerganov 主导,是本地运行大模型的重要推理框架。具体内容未在帖文中详述。
开发者am17an向llama.cpp提交PR #29887,为存放在主机内存中的MoE专家层增加GPU缓存,有望显著加速无法完全装入显存的混合专家模型推理。
llama.cpp合并请求为GLM 5 Flash MTP添加支持,用户现可在本地运行该模型。该更新由贡献者pwilkin提交。