Together AI Blog

The Open Source AI Stack

8.5内容质量

TL;DR · AI 摘要

开源AI堆栈包含模型、推理、网关、Harness和工具五层,开发者可灵活切换模型并优化成本与性能。

核心要点

  • MIGHT堆栈各层独立,允许快速替换模型以适应不同任务需求。
  • MoE模型通过激活少量专家参数实现高效率,降低计算需求。
  • Harness层连接模型与代码库,支持工具集成和上下文访问。

结构提纲

按章节快速跳转。

  1. 开源模型质量提升促使开发者转向开放堆栈以获得控制权和经济性。

  2. ·MIGHT Stack架构

    堆栈分为模型、推理、网关、Harness和工具五层,各层独立可替换。

  3. 模型通过预测token生成响应,大型模型采用MoE结构提升效率。

  4. 提供模型运行基础设施,支持成本与性能的动态平衡。

  5. 工具层赋予模型执行特定任务的能力并连接代码库。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • 开源AI堆栈
    • MIGHT Stack
      • Model
        • MoE结构
      • Inference
        • 基础设施
      • Gateways
        • 负载均衡
      • Harness
        • 工具集成
      • Tools
        • 技能库

金句 / Highlights

值得收藏与分享的关键句。

#AI#开源#模型#架构#开发
打开原文

开源AI堆栈

随着开源模型的质量逐渐缩小与闭源模型之间的差距,越来越多的开发者和组织开始转向开源模型,以获得更多自主权、控制权和经济性。本文将深入探讨开发者在从闭源转向开源过程中需要考虑的开源模型AI堆栈。

使用开源模型进行智能软件开发并不需要学习如何训练模型、购买大量GPU服务器或成为机器学习专家。从应用开发者的角度来看,这一堆栈与使用闭源模型的体验出人意料地相似。你有一个能回答提示的模型,以及一个管理你与模型之间交互的工具层。

如果你已经了解如何使用Claude Code,那么你距离使用开源模型可能比想象中更近。

MIGHT堆栈

该堆栈可以划分为以下五个部分:

  • 模型:负责解析请求并决定执行操作的组件。
  • 推理:模型实际运行的基础设施和推理服务提供商。
  • 网关和路由器:决定每个请求由哪个模型或服务提供商处理的层级,平衡成本、速度和能力。
  • Harness:管理对话的应用程序,为模型提供工具访问权限,并将其连接到代码库。
  • 工具(技能和MCP):指导模型完成特定任务的知识,包括为模型和Harness提供相关上下文信息。

这些层级相互独立,使得每个层级都可以根据开发工作流选择更适合的技术方案。这种设计使开发者能够在新模型发布后立即进行实验。

新模型层出不穷。有些速度更快,有些成本更低,有些在特定任务上表现异常出色。如果切换模型只需几分钟而非重建整个工作流,开发者就能真正进行模型实验。

本文将逐一解析堆栈的每个层级,解释其功能,并探讨如何进行定制化。我们先从模型层级开始。

模型

模型通过预测最可能的下一个标记来生成响应,其依据是训练数据。在我们的堆栈中,模型作为智能层,负责推理、决策以及决定代码库中需要做出的更改。

模型的规模多种多样,一般来说,更大的模型通常具备更强的能力、更好的推理能力和更可靠的复杂任务表现。目前领先的开源模型大多是专家混合(MoE)模型,包含许多专业化的“专家”,但每次生成标记时只会激活其中一小部分。这种设计使它们能够拥有更大的参数量,但实际运行时只需激活较少的参数,从而减少计算需求。

大型模型

大型模型通常由参数数量和训练时使用的计算资源来定义。这些模型具有非凡的能力,可以从训练数据中识别模式、关系和抽象概念。实际上,“大型”通常还意味着模型在更多数据上训练了更长时间,并使用了显著更多的计算资源。

这种额外的容量带来了几个重要的优势。大型模型在多步骤推理方面表现更出色,它们需要同时跟踪多个约束条件,并根据问题的早期部分做出决策。这使它们在面对模糊或未明确指定的任务时成为理想选择,因为它们可以借助更广泛的学习模式来补充缺失的细节。

一个大型开源模型的典型例子是 Kimi K3,该模型拥有 1.8T 总参数量和 104B 活跃参数。当需要执行复杂任务时,应选择 Kimi K3 这样的大型模型,例如:

  • 重构现有的认证系统
  • 将代码库升级到新框架
  • 审查拉取请求
  • 分析 SQL 数据库为何突然变慢

大型模型的优势在于其在不同类型工作中的鲁棒性。它们可以在编写代码、解释系统、调试问题和规划更改之间无缝切换,而无需严格的指令范围。这使它们在代理式工作流中特别有用,因为模型需要决定下一步该做什么,而不仅仅是遵循单一指令。

大型模型还能更好地利用更长的对话。当它们一次性接收到大量文件、日志或信息片段时,能够保持连贯性,并在整个输入中连接相关细节。

这可能会让你认为更大的模型总是更好,但实际上大模型和小模型之间存在权衡。接下来,我们将探讨选择小模型而非大模型的一些原因。

小模型

小模型与大模型的差异更多体现在它们能舒适处理的模糊性程度,而非质量本身。

当任务明确且范围严格限定时,小模型的表现可以与大得多的模型相媲美。如果你通过明确表达需求来消除模糊性,它们会变得极其高效。

小模型在明确指定的任务中表现出色,因为它们不需要猜测你的架构、推断隐藏需求或探索多种可能解释。它们只需按给定指令执行即可。

一个小型开源模型的例子是 GLM 5.3 Flash,该模型拥有 320B 总参数和 18B 活跃参数。与 Kimi K3 相比,它的规模约为 1/6,成本约为 1/20。

当任务狭窄且明确时,这些模型的表现令人惊讶地出色,例如:

  • 将此函数修改为接受另一个选项
  • 为这个文件编写测试
  • 解释一个特定错误
  • 检查这个 50 行函数的潜在缺陷
  • 重命名这个 API 并更新其调用方

这些任务的模糊性很小。模型不需要深入理解你的整个代码库,也不需要在多种架构方案中做出抉择。

小模型最重要的优势是运行速度显著更快且成本更低。

它们生成每个 token 所需的计算资源更少。实际上这意味着更低的延迟响应和每请求成本显著降低。对于许多日常编码任务,这种速度差异会立即显现,因为模型响应迅速,迭代更快,你可以频繁运行而无需担心成本。

与其认为大模型优于小模型,不如将这些模型视为工具箱中两种不同类型的工具。

更大的模型可能在解决问题时更加可靠,但也可能慢几倍或成本更高。如果较小的模型能够正确完成相同的单文件修改,几乎没有理由选择更大的模型。

随着时间的推移,开始将模型选择视为工具选择,而非选择优胜者。

从少量大模型和小模型入手,通过反复使用学习它们的能力和局限性。你很快会形成对代码库中哪些任务可以分配给不同规模模型的看法。

接下来,我们将探讨寻找模型的最佳途径。

模型选择

新模型每周都会发布,自行评估所有模型显然不现实。

The Open Frontier 和 Artificial Analysis 等排行榜有助于发现可用模型,并大致了解模型在智能性、编码能力、速度和价格等方面的对比情况。

不要花太多时间试图在排行榜上找出最佳模型。基准测试将大量行为压缩成单一评分,而你实际的工作负载要具体得多。总体排名稍低的模型可能在你每天进行的编码工作中表现优异。

作为参考,目前最流行的开源模型包括 GLM 5.3 Flash、DeepSeek V4 Flash、Kimi K3 和 MiniMax M3。但这些模型更新速度非常快。

在选定几个模型进行尝试后,下一步是找到提供这些模型的服务商。

推理服务商

由于开源模型可以跨生态系统使用,你可以选择它们的运行环境。最简单的入门方式是使用云推理服务商和云网关。

这些服务商的工作方式是:你向它们发送 API 请求,它们在自己的 GPU 上运行模型。你根据发送给模型的输入和模型输出的 token 数量付费。

这使得云服务商非常适合实验。如果你想尝试新模型,只需创建 API 密钥、指定模型名称,即可开始发送请求。Together AI 等服务商提供大量模型目录,单个账户即可访问许多不同规模的模型。

运行相同模型的两个服务商通常应产生相似结果,尤其是在使用相同模型版本和采样设置时。性能、价格、延迟和 API 功能可能有所不同,但底层模型本质上是相同的。

这种分离意味着你可以先根据模型的行为选择模型,再根据价格或性能选择服务商或网关。

网关和路由器

并非所有推理服务商都统一托管模型,这不幸意味着你无法为每个模型使用单一推理服务商。网关和路由器通过提供跨多个推理服务商的多种模型访问来解决这个问题。如果你想在闭源模型和开源模型之间进行路由,这尤其有用。

网关位于多个推理服务商之前,通过单一 API 聚合它们,让你可以跨不同后端路由请求、比较价格和延迟,并在不修改代码的情况下切换模型。它充当你与底层推理服务商之间的翻译和路由层。值得探索的两个流行云网关是 https://openrouter.ai/ 和 https://vercel.com/ai-gateway 。

你也可以使用类似 https://www.litellm.ai/ 的工具,在本地或自己的服务器上运行自己的路由器。这些路由器为你提供一个单一的 API 端点,可以让你在已设置的多个推理服务提供商账户之间进行路由。

选定推理服务提供商或云网关后,下一步是设置你的工具链。

工具链

工具链是你交互的堆栈部分。它通常是运行在你电脑上的一个程序,位于你、代码库和模型之间。它维护对话,并为模型提供可以与现实世界交互的工具。

假设你提出问题:

这个代码库中认证功能是在哪里处理的?

工具链会将这个问题发送给模型。

模型可能决定要回答这个问题,首先需要在代码库中搜索 auth、session 或 login 等关键词。它会要求工具链执行这些搜索。

工具链在你的电脑上运行搜索命令,并将结果返回给模型。

基于这些结果,模型会要求工具链从多个文件中读取代码。工具链会将这些文件的内容添加到与模型的对话中。

经过几轮这样的交互后,模型收集到足够的信息来回答你的认证问题。它可以列出代码库中所有包含认证代码的文件和具体行数。

关键的一点是,模型不会搜索你的文件系统或执行 shell 命令。模型决定应该发生什么,而工具链是实际执行操作的部分。

这意味着编码代理的质量不仅取决于模型本身。

优秀的工具链知道如何暴露工具、收集相关上下文、管理长时间对话、应用补丁、显示更改、在适当的时候请求权限,并在命令失败时进行恢复。

相同的模型在不同的工具链中使用时,表现可能会有明显差异。

选择工具链

与模型类似,可选的工具链列表也在不断增长。

这些工具链有不同的形式,包括基于终端的 CLI 工具链、在 IDE 内运行的编辑器扩展,以及提供更可视化界面的网页或桌面应用程序。

它们在理念上也有显著差异。

一个工具链可能暴露数十个功能、集成、后台代理和项目管理工具。另一个可能仅提供基本的对话、shell 和文件编辑功能。没有哪种方式本质上更好。

以下是几个支持开源模型的流行工具链:

  • PI: https://pi.dev/
  • OpenCode: https://opencode.ai/
  • Amp: https://ampcode.com/

大多数工具链都使切换提供商或模型变得容易。事实上,这通常是开源工具链的一个卖点。切换模型通常只需要一条命令或一次配置更改。

对于闭源工具链如 Claude Code 和 Codex,你可以使用 TogetherLink 等工具将其连接到当今流行的开源模型。

选定工具链后,下一步是根据你的工作流程进行定制。

工具(技能和 MCP)

工具链还可以通过技能和 MCP 服务器进行扩展。这些是有用的附加组件,可以为工具链与模型共享的指令和工具提供支持。

技能是可重复使用的指令,用于告诉模型如何执行特定任务或使用特定工具。与将所有内容放入一个大型提示中不同,技能可以在需要时由框架加载,从而为模型提供部署应用、代码审查或使用框架等任务的专业知识。你可以在 https://www.skills.sh/ 网站上发现社区贡献的技能。

MCP(Model Context Protocol 的缩写)是一种标准,通过通用接口将AI代理连接到外部工具和数据源。这些服务器使框架能够与数据库、API、文件系统和开发工具等交互,而无需为每个工具单独进行定制集成。你可以在 https://mcp.so/ 网站上找到现有的MCP服务器。不同提供商也有自己的MCP服务器,例如Together AI的服务器地址是这里。

接下来,我们将探讨如何在框架中有效处理上下文。

上下文管理

当你开始在不同模型之间切换时,上下文变得尤为重要。

上下文是当前对话中与模型共享的所有内容。它包括你的提示、模型的先前响应、框架附加的文件、shell输出、搜索结果、工具调用以及会话期间积累的任何其他内容。

模型能处理的上下文有最大限制。即使在达到这个硬性限制之前,过长的对话也会变得不那么有用。

一个编码会话可能从一个明确的任务开始,最终积累二十个文件、几次失败的尝试、多页的测试输出以及不再相关的讨论。

此时,模型在每次响应时都必须处理所有这些内容。

提高模型输出质量最简单的方法之一是了解何时停止当前会话并开始新对话。

新会话

你可以对代理工作流程做出的最简单改进之一是更频繁地启动新线程。

例如,完成一个任务后,在开始下一个任务前确保启动新会话。或者,如果你尝试了一种方法并希望从不同角度重新考虑问题,应该从头开始。

即使切换模型,也建议从头开始。

这是因为对话本身会影响模型解决问题的方式。将新模型放入一个长期的调试会话中时,它会继承前一个会话中的所有假设、实验和死胡同。

规划、实施与审查

值得尝试的一种工作流程是将提示拆分到三个不同模型中,每个模型有特定目标:第一个模型负责规划,第二个模型负责实施,第三个模型负责审查。

大型模型是出色的规划者。它们能够将开放式的提示分解为明确且独立的任务。

从那里开始,使用小型模型逐一实施每个任务。为每个任务创建新会话,以保持上下文简洁聚焦。如果任何任务对小型模型来说过于复杂,可以切换到大型模型让它完成工作。

最后,当所有任务完成后,可以使用大型模型审查所有工作。如果审查过程中发现问题,整个过程可以重复进行。根据审查反馈创建新的规划会话,使整个流程可以循环往复。

这种方法的一个优势在于,你无需将其转化为正式系统。熟练使用不同模型的能力,使你可以在日常开发中快速在规划、实现和审查之间切换。

为实验而构建

理解堆栈的分层结构,使你能够轻松尝试不同模型、提供商和工具链,而无需改变整个工作流程。在大多数情况下,更换模型只需修改一个配置值。切换提供商只需将相同工具链指向不同的 API 端点。即使进行更结构性的更改(例如引入路由器或网关),也可以在不干扰日常工作的前提下实现。

这种分离消除了采用新模型时通常遇到的摩擦。你无需承诺使用单一系统,而是可以将模型视为稳定工作流程中的可替换组件。你的工具链保持一致,工具和快捷方式保持不变,仅底层智能层发生变化。这使得在实际任务中快速测试模型、比较实际成本和延迟,并逐步建立对哪些模型最适合哪些类型问题的直觉变得容易。

你可以通过升级模型、切换提供商或添加路由层,持续迭代你的技术栈,而不会影响日常开发工作的节奏。

开放堆栈

开放模型最令人兴奋的部分不仅仅是提供了更多可选模型。真正重要的是整个技术栈变得可组合。

你可以根据任务选择模型,根据价格和性能选择提供商/网关,根据工作习惯选择工具链,并根据工作流程需求用所需的技能和工具扩展该工具链。

例如,你的编码技术栈可以是 OpenCode 作为工具链,GLM 5.3 Flash 在 Together AI 上运行,使用 grill-me & hallmark 技能构建优秀用户界面,以及 Playwright MCP 进行浏览器自动化。

这些组件无需来自同一家公司。如果下周出现更好的模型,你只需替换它而无需更换其他部分。使用开源权重模型时,你还可以选择将模型迁移到其他地方,甚至在自己的设备上运行(例如通过 ollama 等工具在个人电脑上运行)。

这就是开放模型更大的承诺。

你无需选择 AI 编码产品,而是可以构建自己的 AI 编码技术栈。