d1（2分钟阅读）

# Thread by @liquidai on Thread Reader App Source: https://threadreaderapp.com/thread/2105003472332693869.html ## More from @liquidai Liquid AI 头像 (https://threadreaderapp.com/user/liquidai) 8月24日 今天我们发布 Pipette —— 一个面向端侧智能的模型评测套件，与 @ArtificialAnlys 合作推出。 大多数基准测试平台都针对云端部署的基础模型进行优化，用以测量其核心能力和速度表现。Pipette 为整个领域提供了一种通用且可复现的方式，用于测量 AI 模型在手机、笔记本电脑、PC、AI 盒子和嵌入式硬件等设备上的质量、速度、延迟和内存占用。 > Pipette 是开源的 > 在 Pipette 中，模型以"模型 + 量化 + 运行时 + 设备"的组合形式在同一接口下进行比较。 > 内置一个经过验证的基准测试结果仓库，目前已包含 10k+ 条结果，覆盖 35 个模型类别、7 种量化级别、llama.cpp 运行时和 4 类设备。 > Pipette 是一个动态平台，从第一天起就接受新的贡献，可添加新设备、运行时、模型系列和量化级别。 🧵Image (https://pbs.twimg.com/media/HQfxwNma4AETD1r.jpg) 今天发布的内容： 1. 一个用于探索和对比端侧模型性能的交互式仪表板：pipette.liquid.ai (https://pipette.liquid.ai/) 2. 一个公开数据集，包含 10k+ 条结果，涵盖模型、量化级别、运行时和设备的 1000+ 种测试配置。查看当前的覆盖情况：pipette.liquid.ai/coverage (https://pipette.liquid.ai/coverage) 3. 面向 macOS、Windows、iOS 和 Android 的基准测试客户端，可在目标设备上运行带版本管理的基准测试定义：github.com/Liquid4All/pip... (https://github.com/Liquid4All/pipette-clients) 4. 一个配套的 Artificial Analysis 仪表板，展示 Pipette 的测试结果和聚合基准评分：artificialanalysis.ai/hardware-infer... (http://artificialanalysis.ai/hardware-inference-stack/mobile-phones) 5. 基于 Apache 2.0 许可的开源基础设施，用于基准测试管理、执行、提交和评分： github.com/Liquid4All/pip... (https://github.com/Liquid4All/pipette-mgmt) github.com/Liquid4All/pip... (https://github.com/Liquid4All/pipette-clients) github.com/Liquid4All/pip... (https://github.com/Liquid4All/pipette-scores) 6. 可直接在设备上运行基准测试的 iOS 和 Android 原生应用。 iOS App：apps.apple.com/us/app/pipette... (https://apps.apple.com/us/app/pipette-by-liquid/id6772314671) Android app：play.google.com/store/apps/det... (https://play.google.com/store/apps/details?id=ai.liquid.pipette) 2/ 视频封面 上手指南：首次公开发布涵盖来自多家供应商的约 35 个模型类别，支持 7 种 llama.cpp 量化级别。 笔记本和台式机的测试覆盖全部四个级别，而目前手机端的测试覆盖所有量化级别。发布内容包含从 256 到 8,192 token 的上下文长度（在设备内存允许的范围内）。 当前测试设备包括配备 M5 Max 的 MacBook Pro、iPhone 17 Pro、Samsung Galaxy S26 Ultra，以及 AMD Ryzen AI Max+ 395 + Radeon 8060S（即将上线）。更多模型、运行时和设备即将到来。 > 如果你在挑选模型，请仔细查看你计划上线的运行时、量化方式和设备。 > 如果缺少该配置，请在你的硬件上运行 Pipette 客户端，帮助测试第三方提交流程。 > 每一条被接受的提交，都会扩充数据集中所覆盖的配置。 > 我们鼓励模型供应商、运行时开发者、硬件团队和应用开发者测试他们关心的配置。 > 如果有什么你想测量但还没有的，请提一个 issue 告诉我们。 3/ 视频封面 阅读 4 条推文 Liquid AI 头像 (https://threadreaderapp.com/user/liquidai) 8月20日 今天，我们发布 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 的 DSpark 草稿模型。这些模型提供了一条投机解码路径：以微小的内存增加换取大幅的解码速度提升，同时不改变输出质量。 一个轻量级草稿模型提议一组候选 token，目标模型在一次前向传播中完成验证。在 batch size 为 1 的情况下，跨 MATH500、GSM8K、HumanEval、MBPP 和 MT-Bench 的结果为： > H100 上吞吐量最高提升 3.18 倍：LFM2.5-8B-A1B 在 MATH500 上，428 → 1362 tok/s > M4 Max MacBook Pro 上最高提升 2.87 倍：LFM2.5-1.2B-Instruct 在 HumanEval 上，136 → 389 tok/s > LFM2.5-2.6B 的平均表现：H100 上提升 2.67 倍（323 → 864 tok/s），端侧提升 2.27 倍（61 → 139 tok/s） > 在贪心解码下，生成序列在构造上与基线完全一致，因此基准准确度不变。 每个草稿模型约有 300M 参数，其嵌入层和 LM 头与目标模型共享。收益在智能体（agentic）工作负载中最为明显：模型会在每次工具调用前进行推理，而用户需要等待整个过程——在 BFCL 多工具场景中，DSpark 将 LFM2.5-2.6B 的延迟平均降低了近 50%。 🧵 使用 llama.cpp 和 Metal 在配备 M4 Max 的 MacBook Pro 上测量，FP16 GGUF 权重，batch size 1，temperature 0： > LFM2.5-1.2B-Instruct：平均提升 2.54 倍，138 → 350 tok/s > LFM2.5-2.6B：平均提升 2.27 倍，61 → 139 tok/s > 首日即提供 GGUF 检查点，且 LFM 兼容的 DSpark 集成已上游开源至 llama.cpp 在智能体工作负载中，模型会在每次工具调用前进行推理，而用户需要等待整个过程。这正是投机解码收益最大的地方：在 BFCL 多工具场景中，DSpark 将 LFM2.5-2.6B 的延迟平均降低了近 50%。 2/Image (https://pbs.twimg.com/media/HQLeuANbgAMRlVR.png) 一个并行草稿主干在一次前向传播中提议一组 token，一个马尔可夫链头为相邻的草稿 token 之间引入依赖关系，目标模型则一次性验证整组 token。 我们遵循 DSpark 的配方，并使用了扩展后的数据混合，包含 SFT、对话、代码和函数调用数据。每个草稿模型和每一项消融实验均在 @AMD MI325x GPU 上训练。 消融实验确定了架构： > 5 层，块大小为 9，第一版仅使用注意力机制 > 每个草稿模型训练 15 个 epoch，在每个 epoch 追踪验证损失和接受率 > 10 个草稿 token 的平均接受数：LFM2.5-8B-A1B 为 6.95，LFM2.5-1.2B-Instruct 为 5.02，LFM2.5-2.6B 为 4.81 3/ 阅读 4 条推文 Liquid AI 头像 (https://threadreaderapp.com/user/liquidai) 8月19日 今天，我们发布 LFM2.5-230M、LFM2.5-350M、LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B 的更新版 4-bit 检查点，这些模型采用量化感知蒸馏（Quantization-Aware Distillation，QAD）进行训练。这些检查点在保留 Q4_0 格式低内存占用和高解码吞吐量的同时，找回了因 4-bit 量化而损失的精度。 这四个检查点均达到了其 BF16 平均值的约 97%。 🧵Image (https://pbs.twimg.com/media/HQFyrq4aAAAeYaK.jpg) 训练后量化（PTQ）压缩的是一个已经训练好的模型，而不会针对量化误差进行再训练，这会在较低精度下损害模型质量。QAD 的解决方式是在训练过程中模拟量化，并让由此产生的量化学生模型去拟合全精度教师模型。最终的检查点仍然是标准的 Q4_0 GGUF 格式，因此无需专用的推理运行时。 （2/4） 在 230M、350M、1.2B 和 2.6B 上，精度恢复率分别为 BF16 到 Q4_0 质量差距的 70.6%、73.4%、65.5% 和 48.4%。 230M 和 350M 的 QAD Q4_0 检查点在跨 MacBook Pro、NucBox EVO-X2、Samsung Galaxy S26 Ultra 和 Raspberry Pi 5 的基准测试中，其质量在评测误差范围内与 Q5_K_M 相当，而解码吞吐量高出 4-33%。1.2B 和 2.6B 的 QAD Q4_0 检查点在这些设备上的质量与 Q4_K_M 相当，吞吐量高出 3-14%。 （3/4） 阅读 4 条推文 Liquid AI 头像 (https://threadreaderapp.com/user/liquidai) 7月7日 今天，我们发布 Antidoom —— 一个开源方法，用于消除推理模型中一种常见的失败模式：死循环（doom loop）。 采用该方法前后的死循环发生率对比，各项评测得分全面上升： > LFM2.5-2.6B 的早期检查点：10.2% → 1.4% > Qwen3.5-4B：22.9% → 1%（贪心采样） 🧵 死循环是指模型生成一段内容后，不断重复这一段，直到上下文窗口耗尽。小型推理模型在困难的数学和编码任务上最容易触发死循环。 常见的修复方法只是权宜之计。应用 repetition_penalty 可能会降低质量；强化学习则需要校准好的奖励和高成本的 rollout。 （2/6）Image (https://pbs.twimg.com/media/HMoUmBGXUAAwNHE.jpg) 我们的方法是外科手术式的。这种循环几乎总是从某一个被过度训练的 token 开始，通常是模型过度生成的插入语（"Wait"、"So"、"Alternatively"）。 我们只重新训练这一个 token，让它更倾向于连贯的替代表达，同时基本保留其余的概率分布不变。 （3/6）Image (https://pbs.twimg.com/media/HMoUnEZW0AIAU6u.jpg) 阅读 6 条推文 Liquid AI 头像 (https://threadreaderapp.com/user/liquidai) 3月31日 今天，我们发布 LFM2.5-350M。350M 参数，即可实现智能体循环。 一个为可靠数据提取和工具使用而训练的 350M 模型 —— 在这个规模上，模型通常难以做好这两件事。 量化后小于 500MB，专为计算、内存和延迟受限的环境而构建。 🧵Image (https://pbs.twimg.com/media/HEwWZTlaoAAjOVx.jpg) LFM2.5-350M 在 28T token 上配合扩展的强化学习训练而成，相比 LFM2-350M 是一次质的飞跃： > 指令遵循：18.20 → 40.69 > 数据提取：11.67 → 32.45 > 工具使用：22.95 → 44.11 这些才是生产环境中真正重要的能力。 重要的不是参数量，而是你真正能运行它：> 可在 CPU、GPU 和移动端运行 > 快速、高效、低延迟 > 结构化输出稳定一致 > 可靠的函数调用和智能体工作流 这支持一种不同的部署模式：将高频、结构化的工作负载移得离数据更近——在设备端、本地部署或边缘端，而不是将一切都路由到云端的大模型。 阅读 6 条推文 Liquid AI 头像 (https://threadreaderapp.com/user/liquidai) 3月5日 > 平均 385ms 完成工具选择。 > 13 个 MCP 服务器，共 67 个工具。 > 14.5GB 内存占用。 > 零网络调用。 LocalCowork 是一个在 MacBook 上运行的 AI 智能体。开源。 🧵Image (https://pbs.twimg.com/media/HCqDtQAbwAACYjP.jpg) 构建一个本地 AI 智能体听起来很棒，直到你整天都在用它。难点不在于让模型理解你，而在于让它快速选出正确的工具，快到让整个体验感觉是交互式的。 于是我们在笔记本电脑上对 LFM2-24B-A2B 进行了测试，构建了一个名为 LocalCowork 的开源桌面智能体。 一切都在本地运行： > 模型 > 工具 > 数据 没有云端。没有 API 密钥。没有任何东西离开这台机器。 阅读 6 条推文