小模型的强大集群 —— Daniel Svonava，Superlinked
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00审稿人：Denise RQ
00:00:12好了。
00:00:14我想大家能听到我说话。
00:00:15我肯定能听到我自己的声音。
00:00:19谁坐得离前面近一点就能得一件T恤。
00:00:21我是认真的。
00:00:22这里有个装满T恤的袋子。
00:00:25提问环节也有。
00:00:26也许最后会留一些时间提问。
00:00:28只要你提问，同样也能拿到T恤。
00:00:31如果你能猜出这张幻灯片背景是什么，
00:00:35也能拿一件T恤。
00:00:39有人猜吗？
00:00:42这个可视化的是什么？
00:00:44背景里的这张图。
00:00:49没有人吗？
00:00:50有人见过 Transformer 模型吗？
00:00:55对，位置编码。
00:00:57非常好。
00:00:58这位先生，这件T恤归你了。
00:00:59好的。
00:01:00所以今天我们主要讨论小型开源模型，它们现在表现相当出色，以及当你想要在自己的云端部署一大批这类模型时，它们会带来哪些独特的挑战。
00:01:15我们讨论的所有内容基本都是开源的。
00:01:19完全可以自己动手。
00:01:20这些东西你只需要运行一条命令，就能掌控整个技术栈。
00:01:26所以这里面没有任何专有闭源的拼图碎片。
00:01:31我们这就开始吧。
00:01:33行。
00:01:34好的。
00:01:35这个能用。
00:01:36好。
00:01:37那么说到小模型。
00:01:38我们所指的小模型是什么？
00:01:40你知道，取决于你问谁，我的理解基本上是那些能够在两到三代前的 NVIDIA 硬件上运行的模型。
00:01:49整个模型可以装进单个 GPU 中，因此它们很容易进行推理部署。
00:01:56这些 GPU 随处可见，而且价格也很亲民。
00:02:01大多数人会认为，好吧，既然是小模型，那在结果质量方面肯定会有所妥协。
00:02:10希望我能在这次演讲中很好地向大家证明，实际上对于特定任务，你可以达到甚至超越前沿模型的性能，同时还能获得其他所有显而易见的好处，对吧？
00:02:22数量级的成本节省，以及可能非常巨大的延迟或吞吐量提升。
00:02:35所以这是我们喜欢展示的图表之一。
00:02:38这是随着时间推移的人工分析智能指数。
00:02:42而他们通常不会向你展示的是，这里面其实有一个你应该了解的开源模型细分梯队，对吧？
00:02:49比如 GLM 5.2 等等，那些拥有约 7500 亿参数的前沿开源模型。
00:02:57但与此同时，还有一些小型开源模型紧跟在大模型和前沿水平的后面。
00:03:04你可以看到，现在前沿模型的收益正在递减，而小模型正在迎头赶上，对吧？
00:03:10所以你会看到这种收敛、顶端饱和以及小模型的增长趋势。
00:03:16而且，比方说 Qwen 3627B 的性能已经达到了 GPT 5.1 左右的水平。
00:03:23所以如果你有一个工作流，有一个原本可以用 GPT 5.1 运行的流水线，
00:03:29现在你就可以把它迁移到小模型上，享受我们讨论过的所有好处。
00:03:35所以小模型不再是吴下阿蒙了。
00:03:38现在，这也关乎你如何使用小模型，对吧？
00:03:44你不能直接把那个 270 亿参数的 Qwen 36 当作那种完全通用、可以随便提示它做任何事情的模型来用。
00:03:53不，你需要采用这样一种方法：从通用模型的工作负载中拆分出具体的任务切片。
00:04:00针对每个任务，找出开源社区里最适合该任务的模型。
00:04:05运行一些评估，可能还要做一些我们接下来会讨论的适配。
00:04:08然后，这就是你如何达到合适的质量标准并将其真正推向生产环境的方法。
00:04:15这里有一个合同审查代理的例子，它使用了 9 个不同的模型。
00:04:20当你转而为自己的架构使用小模型时，你的工作负载和智能体就会呈现出这种形态。
00:04:28你会开始发现，与其用一堆不同的请求或一个模型去狂轰滥炸某个 API，
00:04:36你宁愿使用一组模型舰队。
00:04:38接着你的问题就是：我该如何部署所有这些不同的东西，才能不让负责基础设施的同事崩溃呢？对吧？
00:04:45而这还只是你可能在运行的其中一个智能体。
00:04:48你们公司里可能还有十个这样的智能体。
00:04:51所以我们如何处理这种基础设施规模的膨胀，可以说是这样。
00:04:57现在，对于我提到的所有那些不同任务，都有一个开源模型正静静地等在那里准备被使用。
00:05:05从 OCR 到文档问答、图像标注、生成 SQL 到代码审查。
00:05:14都有专门针对这些任务进行微调和训练的开源模型。
00:05:19你知道，如果你使用一个经过训练来识别越南语收据 OCR 的开源模型，那个项目肯定见过最多的越南语收据，对吧？
00:05:28总有人花时间收集了尽可能多的数据。
00:05:32所以在那个任务上，该模型的表现几乎会胜过其他任何东西。
00:05:35在 Hugging Face 上有几十万个这样的模型，对吧？
00:05:41所以这些都摆在那里，而且基本都是免费的，大多采用相当宽松的许可证。
00:05:46所以模型是存在的，这不是瓶颈。
00:05:50而且，我们从 2024 年起就一直在谈论开源 AI。
00:05:56但到目前为止它并没有真正普及开来。
00:05:59就它在企业中的应用程度而言，基本上等于“开源 AI 就等于 AWS Bedrock”。
00:06:05除非你看看 Bedrock 里的模型目录，你会发现可用模型的种类非常受限。
00:06:14这些模型通常很旧，往往落后于最先进水平两到三年。
00:06:19而且当你在 Bedrock 中进行任何微调时，你实际上并不拥有微调或训练后的产物。
00:06:25所以你无法将其作为你业务中的真正优势来利用。
00:06:29它基本上还是留在 Bedrock 的基础设施上进行服务。
00:06:32因此，现在说到专有模型，如果你在开源基础设施（如 VLLM、SGLang 等不同解决方案）上进行小模型推理服务，
00:06:41就要知道这些东西并没有针对任何特定模型或任何特定硬件模型组合进行过调优。
00:06:48你必须自己去做调优，对吧？这就是所谓的“自己动手”。
00:06:51所有这些工具在发布时都附带了关于如何实际进行调优、参数扫描、贴合你的流量特征等方面的指南。
00:07:00每当你试图采用其中一个工具时，这就好比是一个开放式的研究项目。
00:07:05所以这真的不是那种你拿来就能当成常规工程项目、
00:07:10然后一周后就能建好高性能服务基础设施的东西。
00:07:14事情不是这样的。
00:07:15这也是开源工具的典型问题，对吧？
00:07:19就是 DIY 的成分有点太多了。
00:07:21而且，除了这些工具没有针对小模型进行预调优之外，使用一堆不同模型的小模型工作负载和流量，
00:07:32实际上颠覆了推理集群的运作方程，对吧？
00:07:37通常情况下，当你试图部署一个大模型时，你的问题是：我该如何在多个 GPU 之间共享该模型？
00:07:44我如何在顶层部署一个路由器，让它理解所有这些工作节点的状体、KVCache 状态等等，
00:07:51然后自上而下地做出路由决策，比如“这个请求去这个工作节点”或“去这组工作节点”，等等，对吧？
00:07:59这是一个非常自上而下的架构。
00:08:01但如果你有很多小而快的请求，而且数量庞大，这种自上而下的路由就会成为瓶颈，对吧？
00:08:09因为路由器持有的工作节点状态有点滞后，如果你在顶层靠这种前置决策来完美平衡每个工作节点上的本地队列，
00:08:16就会很难让工作节点保持饱和。
00:08:26因为有太多的小请求了，对吧？
00:08:29而且，我们针对小模型和这类流量对 vLLM 和 SGLang 路由器进行了实验，
00:08:37发现在持续负载下，很难将 GPU 利用率提升到 20% 或 30% 以上。
00:08:44问题在于批次大小没有正确调整，基本上就是因为存在那个路由瓶颈。
00:08:51第三个问题是，对于小模型，你从 LoRA 和整个模型适配中获益匪浅。
00:08:57因此你必须服务的流量包含了很多找上门来的人，他们会说：
00:09:03“嘿，我有 10 个 LoRA。如何在我们的服务技术栈中使用它们？”
00:09:08或者，“我昨晚做了个自定义微调。你知道，我想把它投入生产环境。”
00:09:14 AI 工程师与基础设施人员之间为了将这些 LoRA、
00:09:21自定义模型部署上线而进行的沟通，才是最耗时的环节。
00:09:24基本上，这种沟通就是扼杀组织效率的头号杀手，对吧？
00:09:30理想情况下，你会希望基础设施工程师做好他们的本职工作，同时也希望 AI 工程师做好他们的本职工作。
00:09:37并且在日常运营中他们不需要互相沟通。
00:09:41这样一来，基本上就不会互相拖后腿了。
00:09:45而围绕小模型的这种模型适配需求打破了这种平衡，并引发了大量的来回扯皮。
00:09:51这倒是个问题，对吧？
00:09:54所以这些都是与“我们有很多小模型”相关的一些挑战。
00:09:58我们该如何构建集群？又该如何高效地进行推理服务？
00:10:02所以这个问题我们已经研究了一段时间了。
00:10:05其实我是丹尼尔，来自Superlinked。我刚才好像跳过了自我介绍。
00:10:09我们是一家位于旧金山的、有风投支持的公司。
00:10:13在过去的几年里，我们一直致力于构建人工智能驱动的搜索、文档处理系统以及智能体。
00:10:20而我们最大的痛点一直是推理，特别是刚才我描述的那类问题。
00:10:26因此，我们不断进行迭代和探索，尝试了各种集群拓扑结构，以便在不同的环境中运行庞大且广泛的小模型集群。
00:10:37因为有时你需要将某些平台部署在某个环境中，而那里究竟有什么资源往往是个未知数。
00:10:44你知道的，小模型让事情变得简单了，因为在任何环境中，获取一些 L4 或少量 GPU 配额要容易得多。
00:10:52所以接下来——我将简单介绍一下我们最终确定下来的集群拓扑结构。
00:10:58顺便说一句，整个项目采用 Apache 2.0 协议，完全开源。
00:11:03大家可以直接拿去进行封装，这样你就是一家推理初创公司了。
00:11:08从控制平面一直到在 GPU 上运行的底层程序，全部都是开源的。
00:11:14所以我们没有任何保留。
00:11:18这种拓扑结构基本上就是有一个网关。
00:11:21与预先决定任务去向的路由器不同，这里有一个网关负责解析部分请求，并向请求附加一些元数据。
00:11:30将该请求插入共享队列以及一些辅助通道中。
00:11:36我稍后会详细讲讲这一点。
00:11:37然后，工作节点从这个集中式队列中拉取数据，而不是把数据推送给工作节点。
00:11:44通过这种方式，它们能够更好地实现资源饱和利用。
00:11:47然后是工作节点的设置——我想我有一张相关的幻灯片——它将描述我们如何基本上将不同模型架构的复杂性
00:11:57转化为一组协调的工作节点，它们不会产生冲突的 Python 环境要求之类的问题。
00:12:03所以这就是整体的拓扑结构。
00:12:06这就是一个请求的生命周期。
00:12:11所以也许我只挑其中的几个要点来说明一下。
00:12:15你知道的，我们不喜欢 OpenAI 那种 API 标准的一个地方在于它使用了 base64 编码的 JSON格式。
00:12:25这对小模型不利，对高吞吐量也不利。
00:12:28因此我们全程使用 MessagePack，一种二进制格式。
00:12:31这样我们就可以通过实际的 API 网关推送所有多模态数据。
00:12:37所以不会出现诸如“二进制数据走这边，请求走那边”的情况。
00:12:42然后集群需要访问你的云存储来开始加载一些二进制数据、图像或视频。
00:12:48我们将其全部编码并通过网关推送出去。
00:12:53接着，网关会将其中一些较重的部分分离出来，以免堵塞内部队列，并在请求排队的过程中将其卸载到云存储中。
00:13:02所以它会把一些超过一兆字节的请求拆分出去，然后在后端使用云存储。
00:13:09但作为用户，你把所有的比特和字节都推送到 API 层，正因如此，它拥有一个非常干净的接口。
00:13:19所以基本上整个技术栈都是 REST，即网关 REST、工作节点 REST，然后在本地通过 socket 连接到不同的运行时。
00:13:30我们基本上采用 PyTorch、Candle 和 SGLang 作为运行时。
00:13:35然后当我们进行优化时——我待会会讲到——我们要确保无论使用哪种运行时
00:13:43以及在该运行时中运行的代码都是最高效的。
00:13:47为此我们基本上有一个自动研究循环。
00:13:50不过是的，一个请求的生命周期大致就是这个样子。
00:13:54还有一个小细节是，你真的希望确保作为请求首先接触到的网关不要做太多工作。
00:14:05因为这样它就会成为瓶颈，对吧？
00:14:07所以你甚至不需要解析整个请求。
00:14:09你希望能够观察数据包并弄清楚即将到来内容的总体形态，进行标注，
00:14:16然后你拥有众多工作节点，无论你有多少个工作节点、成百上千个 GPU，它们都可以查看队列状态并从中拉取任务。
00:14:25队列使用的是 NATS Jetstream，这个东西每秒可以处理数百万个请求。
00:14:32所以，它很难成为瓶颈。
00:14:35所以，是的，理想情况下，你不希望在穿梭于所有这些不同组件的过程中不断进行序列化和反序列化。
00:14:42基本上这就是显而易见的事情。
00:14:45这是一个展示集中式排队背后理念的小动画，对吧？
00:14:51因此，与自上而下的路由器试图恰到好处地填满本地队列（这基本上是不可能的）不同，
00:15:01整个理念是：我们能否以某种方式集中排队，让工作节点自己去承担形成批次的任务，
00:15:09并根据它们对批次成本的预测来构建批次，从而变得更加高效？
00:15:15现在，有一个小细节和题外话，一旦你开始研究这些事情，你就会意识到要预测从共享队列中取出多少个项目才能使批次真正达到最优规模，其实是非常困难的。
00:15:30因此，你会希望有一种机制，能在你发现“哦，我好像多拉取了一点”时，允许你把一些东西放回队列中。
00:15:35如果你发现自己拉取得稍微多了一点。
00:15:37而那是一个网络枢纽，对吧？
00:15:39所以这就会是个问题。
00:15:40为此，我们针对本地有多块 GPU 的机器进行了专门的优化，对吧？
00:15:46因此这里有一个额外的机器本地排队元素，它利用了这样一个事实：在一台机器上的多个 GPU 上运行的本地进程可以与队列进行一点来回协商，
00:15:59而在网络上传输的话，这会增加额外的毫秒级延迟。
00:16:03所以我们不会通过网络进行这种操作，只有当我们将工作节点同置在多 GPU 机器上时才会这么做。
00:16:11而且，我的意思是，我们这里讨论的不是 5% 的性能差异，对吧？
00:16:16所以，当你集中队列后，集群的吞吐量可以直接翻倍。
00:16:19所以这非常显著。
00:16:22我刚才提到了三个不同的运行时。
00:16:25所以，基本上，要么就是，比方说对于仅编码器的模型，我们编写 PyTorch 代码。
00:16:33然后我们对其进行优化，并且我们有一个负责优化的自动研究循环。
00:16:38Candle 也是如此。
00:16:39我们不久前开始尝试使用 Candle。
00:16:42我们目前仍然无法让它的性能接近 PyTorch 的水平。
00:16:45所以它更像是一个研究项目。
00:16:47这纯粹是依赖项的问题，你看，带有 PyTorch 的工作节点 Docker 镜像大约有 12 GB。
00:16:54而使用 Candle 的工作节点二进制文件、静态链接的二进制文件可能只有那个的大约 10%，对吧？
00:17:01如果你关心从冷启动状态唤醒并在多台不同机器上加载这些镜像，
00:17:08把体积从 12 GB 缩减到 1 GB 左右会带来巨大的差异。
00:17:13所以这就是使用 Candle 的动机所在。
00:17:15只不过要获得与 PyTorch 相同的性能实在是太难了。
00:17:20然后我们把 SG-Lang 作为一种默认的基准。
00:17:25我们的表现应该至少和 SG-Lang 一样好，前提是对我刚才提到的所有参数进行最优调整，你必须进行这种调整。
00:17:34这里有一些数据。
00:17:37因此，举个例子，当我们用 socket 以及我们的 Rust 边车包装 SG-Lang 时，
00:17:43实际上我们可以提升纯 SG-Lang 的性能，仅仅因为我们在批处理方面做了一些 SG-Lang 原生并未做的事情。
00:17:54或许你也能让它做到这一点。
00:17:57如果你在 SG-Lang 中开发自定义插件之类的内容，
00:18:00那么你大概能匹配我们的性能，因为，你知道的，
00:18:04你可以把相同的逻辑直接塞进 SG-Lang 的核心服务器中。
00:18:07但这样一来，你就是在开发只能与 SG-Lang 配合使用的自定义代码了。
00:18:11小模型带给我们的整体经验是，运行时是极其多样化的，对吧？
00:18:16你并不想把自己局限在任何一个特定的运行时上，因为，你知道的，
00:18:22我们现在大约有 50 种不同的适配器，针对不同的模型进行了参数化。
00:18:28因此你需要以某种方式处理这种底层复杂性。
00:18:32而解决的方法可能不是为某个特定运行时构建一堆插件。
00:18:36而很可能是某种抽象，在我们的案例中，这就是 Rust 边车概念以及 socket。
00:18:47现在我要谈谈其他一些数据，但在关于基准测试的语言中，你知道的，
00:18:53拐点（knee）这个概念指的是，当你在服务器上不断增加流量，
00:18:57当你向它请求越来越高的吞吐量时，
00:19:01它会给你提供越来越高的吞吐量，这时性能是呈线性上升的。
00:19:05然后在某个时刻，你会达到这样一个点：你请求更多，但产出却不再增加了。
00:19:09于是吞吐量趋于平缓，而延迟开始飙升。
00:19:12我们将这个点称为“拐点”，它是基准测试中的一个有用概念，
00:19:17因为它大致就是饱和点，对吧？
00:19:20也就是在不损害延迟的前提下的最大性能。
00:19:23所以，只是想让大家了解在相对较小的硬件上可能实现的效果，对吧？
00:19:32以及不同类型的小模型。
00:19:34所以这些是在 RTX Pro 6000 上测得的数据。
00:19:37我们通常会使用 NVIDIA L4、A100、RTX Pro 6000、H100 这一档的硬件。
00:19:46再次说明，这些 GPU 在任何云平台上都更容易按需获取。
00:19:52大多数大洲都有相应的配额，你知道的。
00:19:56对于这类应用，你基本上可以获得，对于嵌入模型来说，
00:20:01甚至高达，比方说，数亿个参数，
00:20:05你可以实现每秒编码数干万个 tokens 并转化为嵌入向量，对吧？
00:20:12所以想象一下，你现在正坐在那儿，在OpenAI API上调用文本嵌入树。
00:20:17相反，你可以只用一块GPU，每秒就能将五十万个Token推送到里面并获取向量。
00:20:26对吧？
00:20:28就像，这能联系起来吗？
00:20:31你每秒将五十万个Token推送到一块甚至算不上特别大的单块GPU上，
00:20:38以此来为你的搜索系统获取向量嵌入，这可比把所有这些都推送到某个托管的嵌入端点并支付高出几个数量级的费用要好得多。
00:20:49对吧？
00:20:50而且对于这些调用，你可以获得低至几十毫秒的延迟，对吧？
00:20:55如果你使用Cohere、OpenAI等公司的API，延迟通常是几百毫秒，对吧？
00:21:02这并不是什么火箭科学。
00:21:03你知道的，只需少数几台GPU以及围绕它们的一些基础设施，你就能实现巨幅的成本节省、显著的延迟改善，并且运维相对轻松，对吧？
00:21:17所以这真的是触手可及的成果，如果你想从开源模型和小模型入手，嵌入模型绝对是不二之选，对吧？
00:21:26但不仅限于此。
00:21:27比方说，你想看看命名实体识别。
00:21:33你想看看多向量搜索，甚至是文本生成或结构化输出等任务，对吧。
00:21:42你可以从特定任务的生成模型中获得每秒数千个Token的输出，就像底部显示的那样，单块GPU大约每秒能处理五百个左右。
00:21:58所以，假设你正在生成合成数据，正在为微调和评估生成标注，千万不要在托管端点上做这些。
00:22:11这是一个完美的任务，因为一切都在你的掌控之中。
00:22:14你可以监控质量。
00:22:16这绝对是在你自己的基础设施上运行开源模型的绝佳场景。
00:22:20然后，你知道的，如果围绕这些GPU构建的基础设施足够合理，你将获得与GPU数量成正比的线性扩展。
00:22:31现在，关于小模型服务，还有另一个思路，通常情况下，你每个模型会配备一个工作线程池，对吧？
00:22:44你有一组工作线程、一组节点，它们带有GPU，你把这些启动起来，然后预加载模型。
00:22:51模型需要加载好几分钟，因为它们有数百亿个参数。
00:22:55于是你很高兴，行吧，它们终于加载完了，现在我有一个工作线程池了。
00:22:59这种心态对于小模型来说其实并不适用。
00:23:02对，对，快点。
00:23:04还剩多少时间？
00:23:06超时六分钟了。
00:23:07哦，超时六分钟了。
00:23:08好的。
00:23:09行吧。
00:23:10所以在同一块GPU上打包多个模型会更快。
00:23:12这就是关于如何仍然固定一些模型，但同时又根据内存压力来实现懒加载和驱逐机制的故事。
00:23:26你需要弄清楚如何将两者结合起来。
00:23:28这里还要简单谈谈自动化研究。
00:23:32我们拥有用于添加新模型支持及其性能优化的自动化研究循环。
00:23:39我们构建了大量内部工具来进行测量，并将数据反馈到这些自动化研究循环中，从而不断提升指标。
00:23:47也许最重要的是，当我们发布对某个模型的支持时，所有的调优都已经完成了，对吧？
00:23:53所以不存在什么“我们来做个参数扫描吧”的情况。
00:23:55我们基本上为整个集群打包好了端到端的配置。
00:24:00这就是自动化研究循环的设置。
00:24:03这里有一个元循环来构建测试框架，然后运行该循环。
00:24:08顶部还有一个仪表盘，帮助你理解它的工作原理。
00:24:12为此我们定制了用户界面。
00:24:15其中一个产出是一个Lora，训练它只花了80美分，作为概念验证，它将德语法律文本的检索质量提升了18%。
00:24:27就是这样。
00:24:29所以小模型很好。
00:24:30它们相对容易部署。
00:24:32它们实际上便宜得多，也快得多。
00:24:35而且很聪明。
00:24:36那个二维码通往我刚才介绍的我们集群的GitHub仓库。
00:24:43给我们点个Star吧。
00:24:44祝大家自托管愉快。
00:24:45谢谢大家。
00:24:46谢谢。
00:24:47谢谢。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video