LlamaCpp在VRAM充足时调用CPU的原因解析
在Windows Server上运行Qwen2.5-27B模型时，即便设置了高GPU层数（-ngl 99）且VRAM在加载时已占22.6GB/24GB，推理时GPU满载的同时仍会出现CPU突发占用。这种现象主要源于几个方面：上下文缓存管理、特定计算层的硬件兼容性、提示词处理阶段的并行计算策略，以及量化模型中非标准算子的回退。摸清显存与内存的协同机制，能帮助开发者更有效地优化单卡服务器的大模型推理性能与资源分配。
Qwen3.8-Flash-Next 在双 3090 上的推理性能优化实践
在双 RTX 3090 GPU 与 DDR4 内存环境下，针对 Qwen3.8-Flash-Next 模型进行推理性能优化的技术细节。作者通过 llama.cpp 框架，结合 UD-Q4_K_XL 量化、专家缓存（expert cache）技术以及 MTP（Multi-Token Prediction）堆叠，成功将解码速度从 25-29 t/s 提升至 37-41 t/s。 核心技术要点包括： 1. 硬件配置：利用双 RTX 3090（PCIe 3.0）与 Xeon E5-2696 v4 处理器，将 48 层专家层置于主机内存，其余部分置于 GPU。 2. 性能调优：通过修复专家缓存 PR 中的 Bug、优化加载时间以及解决内存热节流问题，实现了显著的吞吐量增长。 3. 实践价值：该方案展示了在消费级硬件上运行大规模上下文（261k context）模型的工程可行性，并提供了可构建的优化分支供开发者参考。
Apple Watch 成功本地运行 Qwen 大模型
一位国内开发者近日在社区分享了将大模型部署至 Apple Watch 的极客尝试。该项目通过伞头文件（Umbrella Header）将 C++ 编写的 llama.cpp 桥接至支持 watchOS 的 Swift 程序中，成功在 Apple Watch S8 上本地运行了 Qwen3.5-0.8B-Q4_K_M 模型。在硬件表现上，Apple Watch S8 搭载的芯片在纯 CPU 计算下达到了约 0.27 token/s 的推理速度，峰值算力约为 iPhone 6s 的八成。虽然目前速度较慢、实用性有限，但该尝试验证了端侧小模型（SLM）在超便携可穿戴设备上运行的可行性。作者指出，若在支持 Metal 框架的新款 iPhone 上运行，速度可达上百 token/s。目前该项目已在 GitHub 开源（ETOS-LLM-Studio），支持 iOS 和 watchOS。
Qwen3.6与Gemma4本地推理实测对比
在Reddit的LocalLLaMA社区中，开发者针对Qwen3.6-35B-A3B与Gemma4-26B-A4B两款热门开源大模型在本地部署时的表现展开了讨论。发帖者分享了其在Radeon 9070 XT显卡上使用最新版llama.cpp进行推理的实际体验。测试表明，虽然Qwen3.6在生成质量和回答效果上表现出色，但Gemma4在运行速度上具有显著优势。这一对比反映了当前本地大模型部署的核心痛点：在模型参数量、活跃参数量（如A3B与A4B）以及硬件适配之间寻找平衡。对于使用AMD显卡及llama.cpp的开发者而言，Gemma4在推理效率上表现更佳。这一讨论为开发者在选择本地模型时，提供了关于“生成质量”与“响应速度”权衡的重要参考。
Gemma-4 APEX量化实测：长上下文表现优异
近日，Reddit 社区用户分享了针对 Gemma-4 26B A4B 模型的 APEX 量化版本（APEX-I-Compact，约 15GB）的实测体验。在 16GB 显存的显卡上，通过 llama.cpp Vulkan 运行，该量化模型在高达 90,000 的超长上下文窗口下，依然跑出了 38 tps 的高速度，且未出现生成死循环或明显的质量退化。相比之下，此前使用的 Unsloth ud-q5kxl 量化版本（大小为 21.2GB）在 50,000 上下文时就会出现死循环。这一测试结果表明，APEX 量化技术在保持模型精度的同时，极大地优化了显存占用与长上下文处理能力。对于使用消费级显卡（如 16GB 显存）的本地大模型开发者而言，APEX 量化版 GGUF 模型提供了一个兼顾速度、容量与长文本稳定性的优秀选择。
RTX5080跑Qwen3.6：128k上下文56t/s
开发者在RTX 5080 (16GB)上测试了Qwen3.6 35B MoE（Q4_K_XL量化），在128k长上下文（模拟真实编程Agent）下速度达56 tok/s。令人意外的是，尽管llama.cpp最新合并了多Token预测（MTP）支持，但在该高上下文配置下MTP并未带来性能提升。这为本地长文本推理优化提供了重要参考。