使用小型模型的智能体编码工作流

好了

大家好！

我叫 Jose，今天和我一起参加会议的还有 Ian 和 Zoe。

我们都了解 LLM。

我们用它来做各种事情：查找食谱、总结 YouTube 视频内容、编写代码。

有些大语言模型 (LLM) 的规模非常庞大，例如 Gemini 模型，它们能够完成真正令人惊叹的任务。不过，在本次演讲中，我们将重点讨论小语言模型。

它们也是 LLM，因为拥有 40 亿参数的模型绝不能算小，但从现在起，我们将做出这样的区分：前沿模型和小语言模型，就像火箭和自行车。

我们将讨论小型模型，它们不一定是前沿模型的替代方案，而主要是作为前沿模型的补充。

我们将探讨小语言模型的所有优势，尤其是当它们是开放、开放权重且可下载的模型时。不过，我们先来看看成本。

为了准备这次演讲，我运行了大量基准测试，其中一项测试包含 200 个中等和困难任务，使用了近 1.31 亿个 token，而成本不到 9 美元。

我使用了 Gemma 4，因此本可以下载它并在自己的硬件上免费运行，但为了进行公平比较，我选择在商业网关上运行。

那么，前沿模型的成本是多少？

大约多出 20 到 200 倍，具体取决于词元缓存和其他因素。

因此，自行车可能不是最快的交通工具，但绝对是最高效的。

千真万确。

现在，显而易见的问题是，质量和准确性有何差异？

在这个特定的数据集中，Gemma 4 可以解决 53% 的任务。

这意味着两点。

如果您使用前沿模型来运行左侧的这些任务，可能会大材小用。

如果您使用小型模型来运行右侧的任务，则必须引导模型找到解决方案，或者使用更大的模型。

在本次演讲中，我们将帮助您充分利用每个 token。

Zoe 将引导您了解如何选择小型模型，Ian 将介绍 Gemma 模型，以便您了解如何思考这些模型可以实现的功能。

然后，我会快速演示如何在 Android Studio 中试用 Gemma 4。最后，我们将展示如何将小型模型融入日常工作流程，并分享实际的 Android 开发基准，帮助您直观了解这些模型的功能。

接下来，有请 Zoe。

非常感谢你，Jose。

所以，用一个模型来处理所有事情，有点像用大锤砸坚果，对吧？

这种方法很高效，但有点不合比例。

因此，小型模型就像是您工具箱中的新工具。

为了解需要将哪些工具引入工作流，您需要打开工具集，查看有哪些可用工具、它们的规格以及适用场景。

因此，若要选择小型模型，您需要了解小型模型。

大多数人在想到语言模型时，首先想到的都是自回归语言模型。

这是自回归的，因为根据以词元为单位分块的输入，它会从候选列表中选择最可能的下一个词元。

然后，所选的最可能出现的下一个词元会返回到输入中，以此类推。这种方法能够生成连贯且听起来很智能的回答，但也有一些注意事项，包括但不限于线性工作。

因此，我们可以采用非线性工作方式。

扩散模型采用相同的方法，但一次处理一个词元块。

就像一幅草图，逐渐变得清晰。

在这种情况下，DiffusionGemma 每次处理 256 个 token 的数据块。

因此，基本上，您会获得一个适用于整个块的通道，能够以更低的延迟生成结果。

我们的工具集包含可以写作的模型，对吧？

错误。

因此，基本上，嵌入模型本质上是将图片、文本或任何其他概念等对象转换为向量。

这样，我们就可以将坐标映射到高维空间，从而在概念上比较两个事物。

例如，如果热狗是三明治，它们可能会导致接近或最终进入一个封闭的空间。

因为如果无法查找域名，互联网可能也会瘫痪。

还有一些较小的专用模型，它们能够执行一项任务，而且执行得非常好。

举例来说，我们有可将自然语言转换为 API 调用的函数模型，有视觉模型（从名称就能看出其功能），还有可根据特定参数为输入内容评分的分类器。

好了，可供选择的选项有很多，对吧？

模型类型繁多，维度、大小、上下文窗口、功能和内存占用各不相同。一旦打开这个工具箱，考虑到所有可能性，选项就会呈指数级增长，这会让 DIY 爱好者欣喜若狂，也可能让他们陷入选择困难。

那么，如何选择小型模型呢？

首先，我们来打开一个工具箱，里面装满了可以在本地运行的开放式小型模型，即 Gemma 模型。

Ian，交给你了。

谢谢 Zoe。

正如 Jose 在开头提到的，小语言模型开箱即用，可以完成大约 50% 的任务。

但为什么您会选择本地模型呢？

因此，这可以归结为大约四个方面。

首先是隐私。

例如，您可能拥有 API 密钥、专有代码或根本无法离开笔记本电脑的内容。

第二个是延迟时间。

因此，当模型实际加载到内存（显存或统一内存）中后，计算一完成，您就会收到回答。

因此，无需与服务器进行往返时间，也不会产生额外的延迟时间。

其次是零边际成本。

因此，如果您能控制模型的运行位置，模型就会具有成本效益。

例如，在本地机器上运行某些内容时，它可能会在错误循环中执行额外的重试。

您无需支付任何费用，也不会产生任何意外的 API 费用。

最后，第四个是离线访问。

想象一下，你可以在飞机、火车、公交车或地铁上使用它，基本上只要你的硬件能运行这个模型，你就能随时随地使用它。

听起来很不错，但我们在做这些决策时，需要考虑两个主要因素。

一个是内存，另一个是速度。

大家可以看到，在这张图表中，底部的两个模型（26B 和 31B）在 BF16（16 位量化）下运行时，都需要超过 50 GB 的显存。

因此，这里的挑战在于，许多硬件无法容纳这些模型。

因此，我们采用了一种称为“量化”的过程，将精度降低到 4 位浮点数。

现在，这个价格更合理一些了。

我们说的是 14 GB 和 17 GB，对吧？

现在，这样的模型可以运行在采用统一内存的 Mac 等设备上。

现在，这种方法的挑战在于，在正常的训练后量化中，当您压缩这些权重时，模型会失去基础模型的一些准确率，而我们有一种技术可以解决这个问题。

这称为量化感知训练。

这样一来，在训练模型时，模型就会知道它将采用这些较小的尺寸，因此与之前相比，损失实际上更小。

这样，RAM 要求降低了 75%，现在它可以在这些设备上运行了。

我们还更进一步。

因此，我们采用的移动量化方法适用于许多手机，可以通过了解所有不同层的运作方式以及它们可以运作的大小，进一步缩小这些模型。

因此，我们有多种量化方法。

因此，我们从 11.4 GB 的 Gemma E2B 缩减到了 1.1 GB。

因此，现在它在中高端手机上的表现要合理得多。

接下来是速度。

因此，正如 Zoe 所说，使用自回归模型时，您是在预测下一组 token。

因此，在编码任务中，您可能会发现许多这些 token 实际上是可以预测的，例如方法签名的结尾，或者左大括号或右大括号。

因此，您可以采用一种称为“推测性解码”的技术。

这样一来，系统会使用较小的草稿模型来预测多个 token，然后由较大的模型进行验证。

之所以能在 Gemma 4 架构中实现这一点，是因为它们共享同一个 KV 缓存。

因此，您可以将其视为模型的短期记忆。

因此，实际情况是，一个较小的草稿模型会提前预测三到四个 token，然后较大的模型会查看相同的 KV 缓存，并基本上验证输出。

这样一来，性能可以提升大约 3 倍，而模型输出的质量不会有任何实际损失，因为它只是预测内容，然后决定是否通过、是否正确。

因此，这在一定程度上取决于您要执行的任务。

因此，这种方法在创意写作等任务中效果不佳，因为这些任务的变化性更大，但在 JSON 结构和编码等可预测的任务中效果非常好。

那么，具体该如何评估这些模型呢？

所以，你最可能做的就是去查看一个基准测试，比如 LiveCodeBench 或 MMLU，然后看一个分数。

但这些指标只能大致反映模型的能力。

您真正需要做的是评估其运行所在的整个堆栈。

因此，这就是您使用的模型、权重和量化方法，它是运行时的推理，因此您可能会使用 llama.cpp、Ollama 或 LiteRT 等工具，以及您使用的智能体 Harness（例如 Pi、OpenCode 或 Antigravity），然后是上下文窗口，它是您希望模型能够处理的所有数据的空间。

所有这些因素综合起来，决定了该方案是否可行。

举个简单的例子，我们在 Android Bench 上使用 Gemma 4 进行了一些测试，运行的是默认上下文长度为 32k 的 Ollama 版本。

我们发现，在其中一项测试中，模型需要查找一个 bug，但智能体框架的压缩操作会将该文件移出内存，导致模型无法完成任务，最终测试失败。

因此，只需将上下文窗口从 32k 增加到 256k，模型现在就能够将其保留在内存中，并能够通过该特定测试。

我们发现，该特定作业的成功率提高了一倍。

因此，这表明即使是这些小因素之一，也可能对该模型是否合适产生重大影响。

那么，您实际上该如何进行自己的评估呢？

以下是三个简短建议。

一种方法是，你可以获取 Git 历史记录，也就是你已经成功完成的一系列 PR，然后将它们作为提示输入提供给模型，看看模型在这些 PR 上的表现如何。

接下来，您需要一个确定性评分器，它将帮助您评估模型的输出是否正确。

我们有两个非常好的例子。

我们有编译器，也有单元测试。

无论生成什么内容，您都可以通过该工具运行，它会告诉您该特定任务是否成功。

第三个是日志轨迹。

因此，在运行智能体时，您需要能够跟踪智能体的不同行为，查看其在哪些方面成功、在哪些方面失败，并据此评估模型在交互和使用工具方面的表现。

我希望大家尝试改变提问方式，不要再问“这个模型是否和这个大型前沿模型一样聪明？”

到“此任务是否可以在此硬件上使用此特定配置完成？”

为了弄清楚这一点，我们发明了一个名为“Are we there yet?”的框架。

或 AWTY。

该框架的核心原则是，根据所有这些不同任务的就绪程度，在这一轴线上进行评分。

即模型本身、您使用的推理引擎、测试框架以及硬件配置。

这会告诉您是否已准备就绪。

例如，您可能需要了解特定任务的可靠性。

如果您连续运行 10 次，每次的结果是否相同？

您可能正在查看延迟时间。

您可能需要实时响应。

那么，您对任务执行速度的阈值是多少？

然后，您可能需要查看 RAM 要求。

因此，这不仅仅是设备拥有的 RAM，还包括设备上可用的 RAM、可分配的 RAM，以及您还需要在该硬件上运行的其他应用和工具。

那么，您可以使用 50% 的 RAM，还是只能使用 10% 的 RAM？

您会获得最后一种准备状态分数。

因此，如果显示为绿色，则表示配置已准备就绪。

如果显示为橙色、黄色或红色，则表示您可能需要更改配置。

您可能需要更快的加速器来降低延迟，也可能需要更大的模型来提升性能。

因此，我建议您查看一下。

我们目前提供的是预览版，非常期待您就此工具的实用性提供反馈。

稍后，Zoe 将详细介绍我们如何设置一些评估，现在我将把时间交给 Jose，他将向大家展示如何快速开始使用 Gemma 4。

谢谢 Ian。

所以，目前最快体验 Gemma 4 的方式可能就是通过 Android Studio。

我来为大家演示一下。

请切换到笔记本电脑。

就是这样

因此，如果我前往设置中的模型提供商页面并选择 Gemma，您就可以清楚地了解每个模型的大小。

我只需将模型下载到硬盘上。

这样，系统就会打开或启动 llama.cpp 服务器，并从一开始就为您正确配置。

不过，您也可以随意使用自己的 llama.cpp 服务器、Ollama 或 LM Studio，随心所欲。

为此，您只需来到这里，然后添加本地提供商。

此外，通过远程提供商使用小型模型也非常合理。

因此，您可以在此处添加一个，只要它与 OpenAI 或 Anthropic 兼容，您就可以连接到它。

好的，我们来看看。

现在，顺便说一下，在 Android Studio 中选择模型的方式显然是通过这个下拉菜单。

我选择了 Gemma 4 26B，然后可以提问：“什么是 ViewModel？”

好的。

因此，您需要记住一个非常重要的事情：每当您更换模型时，整个对话都会从头开始重新发送给新模型。

因此，如果您与模型生成了很长的对话，并且想要切换到新对话，您可能应该开始新对话，或者压缩对话，或者采取其他措施。

现在，我们回到幻灯片，请 Zoe 为大家介绍可以使用小型模型运行的不同工作流。

非常感谢 Jose，也感谢 Ian 为我们介绍 Gemma 模型，以及我们是否已经实现了 AGI。

我们已经了解了有哪些类型的模型，以及它们的规格，现在需要了解的是，您可以让它们执行哪些类型的工作。

第一类工作可能是您已经在做的，比如调试、问题排查等编码工作流程，或者我相信每个人（至少我）都会非常讽刺地怀念手动完成的工作，即提高测试覆盖率。

对吧？

这些都是大家可能已经在做的事情，甚至可能是在无意识中做的。

但我还是想鼓励大家，或者说我希望鼓励大家跳出这个框架，对吧？

考虑到小型模型可以采用开放权重并在本地运行，那么有什么方法可以帮您节省时间呢？

对吧？

我们讨论的是不使用火箭，那为什么我们要用大脑来表示呢？

那么，如果能突破这一限制，小模型还能做些什么呢？

有哪些工作流程可以引入这些工具，让您的生活更轻松，并让您有更多精力去做您可能更想做的事情？

例如，确保文档始终与所做的更改保持最新，或者确保在预提交钩子中包含自动回归测试，甚至确保代理在工作流中接收的上下文经过优化，从而提高运行速度。

这些就是一些示例，对吧？

归根结底，在某种程度上，只有想不到，没有做不到，或者说只有架构限制，没有其他限制，您可以考虑很多种实现方式。

不过，虽然有了规范、工具和工作流程，您是否仍然不确定该从何处着手？

这就是基准数据的用武之地。

正如 Ian 所说，通用排行榜（尤其是针对 Python 的排行榜）无法帮助您了解小型模型是否对 Android 工作流有帮助。

就像石膏板钻头可能无法让您了解混凝土钻头一样。

但您应该投资自己的评估。

您应该投入资源来测试自己的架构，但在测试之前，您可能不想投入所有资源。

这需要时间、资金和精力，因此在决定投资自己的评估之前，先查看公开的基准测试可以帮助您了解情况并缩小选择范围。

在评估基准时，您应该关注三个方面，对吧？

这有点抽象，但基本上，首先要考虑的是，这个模型执行的是哪种类型的任务，对吧？

具体程度。

它看起来像您要给它的任务类型吗？

第二点是任务的范围。

是编写文档、解决 PR，还是与您的工作类型相似的任务？

最后，系统的复杂性是否与您要提供的复杂性类似？

在这里，我们可以看到为什么 Python 基准测试无法很好地代表 Android。

因此，我们构建了 Android Bench，这是一个涵盖 Android 生态系统和 Android 工作的基准。

第一个版本包含 100 个 PR 规模的 Android 任务，您现在就可以通过 Harbor 自行运行该版本，以检查任何智能体、模型和技能组合。

我们推出了 2.0 版本，其中包含更复杂的长期任务，旨在了解前沿模型在处理您今天给它的任务时的能力。

现在，我将把时间交给 Jose，他将向大家展示我们通过这种方法取得的成果，以及一些优化小型模型使用效果的方法。

好的，谢谢你，Zoe。

好的，我们来看看小模型可以解决哪些任务，以及它们在哪些方面开始遇到困难。

我们随意将任务分为四类：小型、中型、大型和长跨度。

长跨度任务是指人类可能需要几天或几周才能完成的任务。

例如，迁移、大型重构，剧透一下，这些都无法通过小型模型完成。

至少是一次性完成。

我们稍后再谈这个。

好的，小任务。

这些作业需要读写一两个文件，不需要太多知识。

例如，小型模型非常擅长 Compose，至少擅长 Compose 的基础知识。

例如，元素之间必须有 8 dp 的间距，或者使用主题而不是硬编码颜色，或者提取字符串。

这些任务对于小型模型来说非常简单。

不过，这个实验涵盖了更高级的主题，但任务仍然很简单。

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

在这种情况下，难点在于范围，而不是知识。

因此，提示实际上告诉了我们应该优化哪个可组合项，以及它有什么问题：它在每一帧都会重组。

因此，即使是 Gemma 4 这样的小型模型，也能轻松完成这项任务。

在本例中，此过程耗时 3 分钟，并且只需更改一行代码。

好了

所以，我想我们已经对小模型有了相当清晰的认识。

我们来看看微…抱歉，是小任务。

我们来看看中等任务。

小型模型应该能够完成大部分任务。

在此任务中，来自 Pocket Casts 应用的请求中缺少用户代理，并且重试逻辑中也存在错误。

这个任务稍微难一点，因为我们同时请求了两件事，而且没有提示这些内容在代码库中的位置。

但它通过了。

耗时 10 分钟。

它修改了三个文件。

顺便提一下，通过 OpenRouter 运行此任务的费用为 6 美分。

现在，我们来看一个来自同一数据集的失败任务。

这是 Now in Android 的一个示例，其中包含一份非常全面的报告或提示，但没有提及类名或文件，因此智能体需要花费更多精力来了解应用的架构、数据层、同步机制等。因此，在这次运行中，它失败了。

所有内容都几乎正确实现，但它只是假设初始同步的值为 -1，而实际上是 0。

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

就是这么简单

如果智能体只是运行了单元测试（即现有的单元测试），这个 bug 就会被发现。

这表明，较小的模型通常会比前沿模型更早停止。

我们只是让智能体修复问题，而不是验证问题。

因此，我们或许应该修改任务，使其包含验证步骤。

我们稍后也会讨论这一点。

好的，我们来谈谈大型任务。

根据此定义，大约一半的大型任务每次都能通过。

有些失败的案例实际上是因为内容太长、太复杂，不适合小型模型，对此我们无能为力。

但有些情况下，当你查看实际发生的情况时，会发现模型已经完成了 90% 或 90% 以上的工作。

我们来选择其中一个。

我之所以选择这个，是因为它是一个不稳定的测试。

它在大约一半的运行时间内通过。

因此，我认为这代表了小模型所能达到的前沿水平。

或者，至少是 4 月份的模型。

该漏洞与 Coil 库中解析格式错误的网址有关。

如您所见，PR 描述非常全面，这很好，但它漏掉了一项要求。

我们来快速了解一下。

所有运行都检查了典型的网址编码和错误，但只有部分（一半）运行添加了针对编码错误的字符的测试，因此该测试用例就在那里。

未通过评估。

因此，所有运行结果都近乎完美，但这再次表明，小型模型并不总是能更进一步。

它们会遵循指令，但不会像前沿模型那样试图给您留下深刻印象。

您知道现在如何设置智能体的努力程度吗？

请注意，如果您使用的是小型模型，则该值设置得太低。

因此，我们将“大型任务”定义为小型模型大约有 50% 的概率可以完成的任务，这也是 Gemma 4 31B 在 Android Bench v1 数据集上可以达到的水平，Zoe 之前也提到过这一点。

那么，在讨论长跨度任务之前，我们能做些什么来帮助小型模型完成这些任务吗？

当然可以，而且这些事情根本不需要任何努力。

首先，如果您像 Ian 一样在本地使用 Gemma 4 等模型，请确保其配置正确。

例如，如果您使用 Ollama 来运行 Gemma 4，它默认的上下文窗口大小为 32,000 个 token，但实际上它支持的上下文窗口大小是这个数字的 8 倍。

当然，如果您通过 Android Studio 使用 Gemma 4，则无需进行配置。

默认情况下，它已正确配置。

在我们的评估中，启用完整上下文后，结果从 26% 提高到了 53%。

接下来，使用 Android CLI，即 Android CLI 工具，尤其是在搜索文档时。

这并非绝对，因为模型在基础知识方面表现出色，但每当您使用新的或小众的 API 时，文档都是关键。

根据我们的经验，这比使用网页搜索工具要好得多。

接下来，添加验证提示。

我们谈过这个。

告诉模型如何运行测试、有哪些类型的测试、如何管理模拟器等。您可以在 AGENTS.md 文件中执行此操作，这样所有智能体都可以使用这些指令，但无论如何，这都是一件好事。

您应该已经收到了。

但也要注意，AGENTS.md 文件不要过长，因为如果您尝试不同的智能体，就会发现有些智能体有大量的系统提示和工具说明，这似乎会降低小型模型的性能。

我们实际上尝试过使用 OpenCode 运行这些基准测试，其性能远低于 pi，这可能是因为它使用了更长的工具描述和系统提示。

接下来，添加技能，但也要移除技能。

小型模型在使用新的和冷门的 API 时可能需要一些提示，但最好不要用一般的 Compose 技能等内容来填充其上下文。

那么，长跨度任务又是什么情况？

这些任务涉及数十个文件，需要做出重大的架构决策，通常由思考模型来处理，该模型会制定计划并启动一批子智能体来执行不同的任务。

长跨度任务的示例包括：将整个应用从 XML 迁移到 Compose、从头开始创建复杂的应用，或将跨平台应用转换为原生 Android 应用。

如果我们查看 Android Bench V2 的结果（该基准专门关注长跨度任务），会发现前沿模型的得分在 3% 到 40% 之间。

因此，对于小型模型来说，我认为可以肯定地说，这超出了它们的能力范围。

不过，如果先通过前沿模型进行初始分析，然后将较简单的任务级联到较小的模型，则会大大提高 token 和点数的利用效率。

我们来看看如何做到这一点。

返回到 Zoe。

非常感谢你，Jose。

我们稍后会讨论级联，但在我向您展示一些方法或深入探究之前，我想先退一步，向您展示不同模型的编排如何为您提供帮助。

例如，编排可以帮助您避免服务中断，对吧？

因此，无论您是遇到提供商服务中断、API 速率限制，还是像 Ian 所说的那样，身处飞机或火车上，您都可以设置后备模型，这样无论是在线还是本地，您都可以在发生任何情况时继续运行。

您还可以通过编排获得更准确的回答。

例如，您可以让小型模型独立工作，并在需要一些支持时调用顾问，以获得帮助。

您还可以设置一个委员会，让不同类型的模型或不同的模型同时执行同一任务，然后评估不同的回答，以及每个模型的权重和偏差如何影响结果。

您也可以使用一个单独的模型，比方说，作为测试。

所以，这就像是同行评审。

你可以通过这个看到它。

当然，最后，编排还可以通过级联等方式帮助您提高成本效益。

基本上，您可以手动设置，例如，您可以设置一个模型用于规划，设置另一个模型用于执行，再设置一个模型用于测试。

有多种方法可以实现这一点，既可以在云端进行，也可以设置 LiteLLM 代理在本地进行。

或者，您也可以使用分类器，根据请求自动将其路由到正确类型的模型，这就是 Ian 提到的代理概念，但它是自动的。

最后，让我们回到 Jose 在演讲开始时提出的问题：小型模型和前沿模型在质量和准确率方面有何差异？

与计算机科学中的许多问题一样，答案是“视情况而定”。

不过，我想让您了解的是，这是您可以设计的东西。

您可以根据自己的设置和玩法来改变这一情况。

因此，第一步是选择合适的工具，对吧？

工具分为多种类型。

了解它们，探索它们，对吧？

然后找出他们适合哪些工作，甚至他们可以从事哪些工作。

第二点是，务必调整模型为完成任务而获取的信息范围。

例如，任务指令、为任务提供恰当的上下文（仅限恰当的上下文），以及检查自身工作的方式。

然后，您需要测试整个设置，而不仅仅是单独测试模型，因为这会产生影响，如果您使用不同的元素配置进行设置，可能会调整您获得的结果。

最后，您需要着手设置或创建自己的评估。

最后，您可以协调自行车和火箭，这样您就不必在两者之间做出选择，从而有效利用预算。

但最重要的是，您可以继续探索、继续构建、继续享受乐趣，对吧？

您可以立即开始行动，通过 Android Bench 及其提供的结果，筛选出一份模型候选名单，或者立即在 Android Studio 中开始使用 Gemma 4。

谢谢大家！