本地 LLM 的意外应用

Reddit r/LocalLLaMA 新闻
local-llm battery-test smartphone agentic-ai vision-language-model robotic-arm qwen

摘要

一位智能手机电池评测员使用两个本地 LLM（Qwen3.6 模型），运行在高端 NVIDIA GPU 上，驱动一个视觉语言智能体，自主控制机械臂进行逼真的电池耗电测试，实现了低于两秒的延迟。

我刷新了 YouTube，发现我最喜欢的评测者上传了 78 款智能手机的电池测试视频：https://youtu.be/MpgUFrsIWSQ 该作者说他们开始使用机械臂来模拟用户操作手机，但希望通过智能体 AI 进一步增强效果。云端 AI 延迟太高，因此本地大模型成了完美解决方案。他购买了 RTX PRO 6000 和 H20，仅仅为了运行 Qwen3.6 27B 和 35B-A3B。为了一个智能手机电池测试，真是疯狂的投资。他还搭建了自己的定制 5G 基站，用于控制 5G 耗电测试，但这与本版无关。 转录：我们的 Battery Life 5.0 模型正是基于这个想法构建的。我们增加了一个视觉语言模型。工业相机拍摄的画面直接输入该模型。模型识别屏幕上的内容、按钮位置、可用操作以及下一步该点哪里。它自主做出所有决策，就像给我们的电池测试机器人注入了灵魂和个性。现在它的手机操作更加逼真和人性化。于是我们开始行动。首先要解决的是算力问题。如何驱动一个操作手机的智能体？电池测试的时间精度极高。机械臂在等待，如果模型响应多花一秒，整个测试序列就会节奏全乱。我们还必须避免网络波动影响结果，因此基于云的智能体被立即排除。所以我们硬着头皮在本地进行推理。我们花费了数十万人民币搭建集中推理服务器，配备了一块 NVIDIA H20 计算卡和一张 RTX PRO 6000 Blackwell。它运行两个模型。一个是 Qwen3.6-35B-A3B，这是一个混合专家模型，速度极快，适合处理快速滚动和大量浏览，例如微博、淘宝和小红书的 feed。另一个是密集型的 Qwen3.6-27B 模型，体积更大、更精确，用于处理精细操作：定位特定屏幕、寻找特定按钮、关闭弹窗等。我们还让两个模型协同工作。如果 A3B 失去头绪（例如产生幻觉或误读屏幕信息），它不会卡住，而是立即调用 27B 模型进行复核。更精确的 27B 能一眼发现错误。因此即使 A3B 出错，也有后备方案。在我们的测试中，从手机操作智能体接收到图像到计算机械臂轨迹，整个过程耗时不到两秒，远低于云端模型的延迟。本地部署模型的优势显而易见。 编辑：结果链接 https://socpk.com/batlife
查看原文

相似文章

利用移动NPU的高效端侧扩散大语言模型推理

arXiv cs.LG

本文提出了llada.cpp，一种NPU感知推理框架，用于在智能手机上加速扩散大语言模型（dLLM）。它引入了三种技术——Multi-Block Speculative Decoding、Dual-Path Progressive Revision和Swap-Optimized Memory Runtime——以使dLLM推理与移动NPU特性对齐，实现了相比CPU基线17-42倍的延迟降低。

大语言模型与本地AI硬件的推理引擎（2026版）

X AI KOLs

本文提供了一份全面的指南，针对2026年本地AI硬件上的大语言模型推理引擎，解释了如何根据硬件策略、工作负载和服务模型进行选择，并涵盖了诸如llama.cpp、MLX、ExLlamaV2/3、vLLM、SGLang、TensorRT-LLM和NVIDIA Dynamo等引擎。

Qwen3.6 27B 在 vLLM 中的表现比在 llama.cpp 中更差

Reddit r/LocalLLaMA

一名用户报告称，Qwen3.6-27B 模型在使用 llama.cpp 时比使用 vLLM 表现更好且更可靠，并指出尽管进行了大量配置，vLLM 仍出现工具调用错误和“被切除脑叶”的行为。