一位国内开发者近日在社区分享了将大模型部署至 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。
在Reddit的LocalLLaMA社区中，开发者针对Qwen3.6-35B-A3B与Gemma4-26B-A4B两款热门开源大模型在本地部署时的表现展开了讨论。发帖者分享了其在Radeon 9070 XT显卡上使用最新版llama.cpp进行推理的实际体验。测试表明，虽然Qwen3.6在生成质量和回答效果上表现出色，但Gemma4在运行速度上具有显著优势。这一对比反映了当前本地大模型部署的核心痛点：在模型参数量、活跃参数量（如A3B与A4B）以及硬件适配之间寻找平衡。对于使用AMD显卡及llama.cpp的开发者而言，Gemma4在推理效率上表现更佳。这一讨论为开发者在选择本地模型时，提供了关于“生成质量”与“响应速度”权衡的重要参考。
近日，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 模型提供了一个兼顾速度、容量与长文本稳定性的优秀选择。
开发者在RTX 5080 (16GB)上测试了Qwen3.6 35B MoE（Q4_K_XL量化），在128k长上下文（模拟真实编程Agent）下速度达56 tok/s。令人意外的是，尽管llama.cpp最新合并了多Token预测（MTP）支持，但在该高上下文配置下MTP并未带来性能提升。这为本地长文本推理优化提供了重要参考。