FastEmbed：快速轻量级嵌入生成 - Nirant Kasliwal | 向量空间讲座
Demetrios Brinkmann
·2024年1月9日
“当事物真正相似或我们如何定义相似性时，它们彼此靠近；如果不是，它们则彼此远离。这就是模型或嵌入模型试图做的事情。”
– Nirant Kasliwal
听说过 FastEmbed 吗？它是一个游戏规则改变者。Nirant 分享了如何改进嵌入模型的技巧。你可能想尝试一下！
FastEmbed 的创建者和维护者 Nirant Kasliwal 对 OpenAI Cookbook 中的 Finetuning Cookbook 做出了卓越贡献。他的贡献延伸到自然语言处理 (NLP) 领域，已售出超过 5,000 本 NLP 书籍。
在 Spotify、Apple Podcast、Podcast addicts、Castbox 上收听本期节目。你也可以在 YouTube 上观看本期节目。
主要收获
Qdrant 的 AI 工程师 Nirant Kasliwal 参加了我们的向量空间讲座，深入探讨了 FastEmbed，一种闪电般快速的嵌入生成方法。
在本期节目中，Nirant 分享了关于增强嵌入生成的见解、技巧和创新方法。
从本集学习的 5 个关键点
- Nirant 介绍了一些改进嵌入模型的“黑客”技巧——你一定不想错过这些！
- 了解量化嵌入模型如何提升 CPU 性能。
- 深入了解 GPU 友好型量化模型的未来计划。
- 了解如何根据 MTEB 基准测试在 Qdrant 中选择默认模型，以及如何针对特定领域任务校准它们。
- 了解 Nirant 创建的 Python 库 Fast Embed 如何解决嵌入创建中的常见挑战，并提高工作负载的速度和效率。
趣闻：生产中使用的最大头部或适配器只有大约 400-500 KB——证明并非越大越好！
笔记
00:00 Nirant 在向量空间讲座中讨论 FastEmbed。
05:00 开放空中令牌昂贵且缓慢。
08:40 FastEmbed 快速轻量。
09:49 支持多模态嵌入是我们的计划。
15:21 无发现。增强模型下载和性能。
16:59 在您自己的计算设备上创建嵌入，而非云端。优先考虑控制和简洁性。
21:06 Qdrant 快速进行嵌入相似性搜索。
24:07 工程师思维：做出明智的猜测，设定预算。
26:11 使用问题和线性层优化嵌入。
29:55 使用混合精度嵌入进行快速、廉价的推理。
Nirant 的更多引语
“有学术的看法，有工程师的看法，还有黑客的看法。我将按这个顺序给你所有这三个答案。”
– Nirant Kasliwal
“工程师的思维现在告诉你，构建东西的最佳方式是根据你预见的负载或挑战做出明智的猜测。对吧。就像土木工程师根据预期车流量建造桥梁，他们显然不会建造一座能承载船只或飞机的桥梁，那是非常不同的。”
– Nirant Kasliwal
“我认为更正确的看法是，我们更好地利用了 CPU。”
– Nirant Kasliwal
文字记录
Demetrios：欢迎大家回到向量空间讲座。今天我们请来了 Nirant，他将和我们聊聊 FastEmbed。如果这是您第一次参加我们的向量空间讲座，我们喜欢展示社区和 Qdrant 社区正在做的一些很酷的事情。我们也喜欢展示 Qdrant 本身正在推出的一些很酷的东西。而 FastEmbed 就是 Qdrant 本身推出的一款产品。我的朋友 Nirant 就在这里。我将请他上台，并向他表示欢迎，简单介绍一下他的简历。那么，Nirant，你好吗，伙计？在我们开始之前，我先快速介绍一下你。
Demetrios：你是一个身兼多职的人。你目前在 Qdrant 的 Devrel 团队工作，对吧？我喜欢你穿的这件衬衫。你从 2017 年就开始研究 ML 模型和嵌入。这真是太棒了。你还是 Fast Embed 的创建者和维护者。所以你是讨论我们今天这个话题的完美人选。现在，如果有人有问题，请随意在聊天中提出，我会在 Nirant 演讲时提问。我还会借此机会鼓励所有正在观看的人加入我们的 Discord，如果您还没有加入 Qdrant 的 Discord。
Demetrios：其次，我鼓励你，如果你一直在使用 Qdrant 或在向量数据库领域，或在人工智能应用领域做一些事情，并且你想展示它，我们很乐意邀请你在向量空间讲座上发言。所以，Nirant，我的朋友，我就把时间交给你了，我将从今天嵌入创建的挑战开始说起？
Nirant Kasliwal：我认为嵌入创建并不是一个独立的难题，你可能一开始会觉得它是一个独立的难题。它实际上是两个难题。一个经典的计算难题是，你如何获取任何媒体？你可以从几乎任何形式的媒体、文本、图像、视频中制作嵌入。理论上，你可以从一大堆东西中制作嵌入。我最近看到有人用汤作为比喻。你可以用几乎任何东西做汤。所以你可以从几乎任何东西中制作嵌入。那么，我们想做什么呢？嵌入最终是一种压缩形式。
Nirant Kasliwal：所以现在我们想确保压缩捕获了我们感兴趣的东西。在这种情况下，我们想确保嵌入捕获了文本或图像的某种含义。当我们这样做时，这种捕获意味着什么？我们希望当事物真正相似或无论我们对相似性的定义是什么时，它们彼此靠近；如果不是，它们则彼此远离。这基本上是模型或嵌入模型试图做的事情。模型本身通常以一种保留其学习新事物的能力的方式进行训练和构建。你可以更快地分离相似的嵌入等等。但是当我们真正在生产中使用它时，我们不需要所有这些能力，我们不需要训练时的能力。
Nirant Kasliwal：这意味着所有为训练时间存储的额外计算、功能和一切在生产中都被浪费了。这几乎就像说每次我必须和你说话时，我都从“你好，我是 Nirant，我是一个人类”开始。这非常令人恼火，但我们一直在嵌入中这样做，而这正是 Fast Embed 主要试图解决的问题。我们从生产的角度来看待嵌入，我们说我们如何才能创建一个为速度、效率和准确性而构建的 Python 库？这些是其核心精神。我认为人们真的发现这是一个相关的问题领域。所以你可以在我们的 GitHub 问题中看到这一点。例如，有人说，“是的，我们确实做到了它所说的，是的，这是一件好事。”因此，对于 800 万个令牌，我们在 MacBook Pro M1 上花了大约 3 小时，而其他一些 Olama 嵌入花了两天多。
Nirant Kasliwal：您可以想象 800 万个令牌在开放空气中的成本以及它会多么慢，因为它们经常限制您的速率。因此，为了方便，我们制作了一个 100 万个嵌入集，它比 100 万个令牌多得多，这花费了我们数百美元。它并不昂贵，但速度非常慢。因此，作为批处理过程，如果您想嵌入大型数据集，它会非常慢。我想有人在 LinkedIn 上写了一篇更生动的版本，Prithvira 在 LinkedIn 上写道，您的嵌入将“飞速前进”，我喜欢这个想法，我们优化了速度，使其飞速前进。这就是这个想法。那么我们是什么意思？让我们给这些东西命名，对吧？所以一个是我们希望它快速轻巧。我将解释我们所说的“轻巧”是什么意思？我们希望召回率很快，对吧？我的意思是，我们从那里开始，什么是嵌入？我们希望确保相似的事物是相似的。
Nirant Kasliwal：这就是我们所说的召回率。我们经常将其与准确性混淆，但在检索意义上，我们将其称为召回率。我们希望确保它仍然易于使用，对吧？就像没有理由让它变得复杂一样。而且我们很快，我的意思是，我们非常快。其中一部分是，比如说，我们使用 BGE small En，只有英文模型。这都是每秒令牌数，令牌是模型特定的。因此，例如，BGE 计算令牌的方式可能与 OpenAI 计算令牌的方式不同，因为分词器略有不同，而且它们是在略有不同的语料库上训练的。这就是这个想法。
Nirant Kasliwal：我很乐意让你尝试，这样我就可以炫耀你尝试了。
Demetrios：那张幻灯片上的小字是什么？基准测试是我第二喜欢炫耀的方式。你第一喜欢炫耀的方式是什么？
Nirant Kasliwal：最好的方式是当有人告诉我他们在用它的时候。
Demetrios：就是这样。所以我想这是让人们尝试并使用它的一个简单方法。
Nirant Kasliwal：是的，我很乐意让你尝试。告诉我们你的体验如何，它在哪里有效，在哪里出了问题，所有这些。如果你报告问题，我很乐意，如果你骂我，我也会感激，因为那意味着你没有忽视我。
Demetrios：就是这样。我们开始吧。Bug 报告会影响你的状态。继续。
Nirant Kasliwal：我们说快速轻量。那么轻量是什么意思呢？你会看到很多这些嵌入服务器的镜像大小非常大。当我说镜像时，我通常指的是 Docker 镜像，它通常可以达到几个 GB。例如，在使用 sentence transformers 的情况下，有人用 Transformers 包和 PyTorch 检查过，你会得到一个大约 5 GB 的 Docker 镜像。顺便说一句，内存消耗并没有那么高。对。大小相当大，其中模型只有 400 MB。所以你的依赖项非常大。
Nirant Kasliwal：每次你在，比如说，AWS Lambda 上这样做，或者如果你想进行水平扩展，你的冷启动时间可能会长达几分钟。如果你在一个非常不稳定的工作负载中工作，这会非常慢且效率低下。如果你仔细想想，人们的查询量通常比，比如说，你的语料库要多得多。例如，假设你在一家电子商务外卖应用的客户支持部门。你的大部分订单量都集中在午餐和晚餐时间。这是一个非常不稳定的负载。同样，即使是时尚领域的电子商务公司也经常发现人们每天晚上，例如下班回家时，都会查看他们的订单。这是另一个高峰。
Nirant Kasliwal：所以每当你遇到突发负载时，你都希望能够水平扩展，并且希望能够快速完成。而这种速度来自于轻量级。这就是 Fast Embed 非常轻量级的原因。所以你会在这里看到我们指出 Fast Embed 只有半 GB，而（其他）是 5 GB。所以在极端情况下，这可能是 Docker 镜像大小甚至内存消耗的十倍差异。召回率，这些嵌入的好坏如何？对吧？所以我们说我们正在让它们变快，但是我们为此牺牲了多少性能呢？所以我们对我们的默认嵌入（最初是 VG small en，现在是 1.5）进行了余弦相似性测试，它们非常稳健。我们没有牺牲太多性能。大家都在吗？我需要一些声音。
Demetrios：我完全同意。聊天中有一个问题，现在是提问的时候吗？
Nirant Kasliwal：是的，请尽管问。
Demetrios：好的，这个问题是几页之前提的，所以我只是提醒你。Fast Embed 有没有计划支持音频或图像源？
Nirant Kasliwal：如果有这方面的需求，我们确实有支持多模态嵌入的计划。我们很乐意这样做。如果其中有特定的模型，比如说你想用 Clip 或 Seglip 或特定的音频模型，请在 Discord 或我们的 GitHub 上提及，以便我们相应地规划。所以，是的，这就是这个想法。我们需要具体的建议，这样我们才能不断添加。我们不希望模型太多，因为那会给我们的最终用户带来困惑，这就是为什么我们采取有主见的立场，而这实际上是一个很好的引子。为什么我们优先考虑这一点？我们希望这个包易于使用，所以我们总是会努力为您做出最佳的默认选择。这是一种非常 Linux 的说法，即我们只做一件事，并努力把这件事做到极致。
Nirant Kasliwal：在这里，比如说，如果你要查看 Qdrant 客户端，它只是像你通常那样传递所有东西。所以 docs 是一个字符串列表，metadata 是一个字典列表，ID 再次是根据 Qdrant 客户端规范的有效 ID 列表。搜索也非常简单。整个搜索查询基本上只有两个参数。你甚至可以看到一个非常熟悉的集成，比如说 langchain。我想这里的大多数人以前都以某种形式看过这个。这也很熟悉也很简单。在底层我们正在做的就是这一行。
Nirant Kasliwal：我们有一个 .embed，它是一个生成器，我们对其调用 list，这样我们实际上就得到了一个嵌入列表。你会注意到我们这里有 passage 和 query 键，这意味着我们在这里用作默认的检索模型考虑到了这些，如果有一个 passage 和一个 query，它们需要被映射在一起，并且在模型训练本身中捕获了问题和答案上下文。另一个注意事项是，我们传递了来自嵌入模型创建者本身的令牌限制或上下文窗口。所以在这个模型，也就是 BGE base 的情况下，它是 512 个 BGE 令牌。
Demetrios：关于这一点，我们上周请来了 Cohere 的 Nils，他谈到了 Cohere 的嵌入版本三，我想他称之为 V3。这个和那个如何搭配？它支持吗？
Nirant Kasliwal：目前，我们只支持开源模型，这样我们就可以直接提供这些模型。Embed V3 目前仅支持云端，因此目前不支持。但话虽如此，我们并不反对。如果需要，我们很乐意支持，以便人们可以无缝地与 Qdrant 一起使用，而 Fast Embed 会为您完成将其传递给 Qdrant、构建 schema 等繁重工作。所以这完全合理。正如我所问的，如果我们有喜欢尝试 Cohere Embed V3 的人，我们会使用它。此外，我认为 Nils 指出 Cohere Embed V3 与二进制量化兼容。我认为这是唯一官方支持这种量化的嵌入。
Nirant Kasliwal：好的，我们是二进制量化感知的，并且已经为此进行了训练。像压缩感知，我想它是这样叫的。所以 Qdrant 支持这一点。所以请，这可能值得，因为它节省了大约 30 倍的内存成本。所以这非常强大。
Demetrios：太棒了。
Nirant Kasliwal：好的，幕后故事，我想这是我最喜欢的部分。它也很短。我们实际上只做了两件事。为什么我们很快？我们目前使用 ONNX runtime，我们的配置是它可以在 CPU 上运行，而且我们仍然很快。这是因为多重处理和 ONNX runtime 本身的原因。未来某个时候，我们还想支持 GPU。我们在不同的 Nvidia 配置上遇到了一些配置问题。随着 GPU 的变化，OnX runtime 并不能无缝地更改 GPU。
Nirant Kasliwal：这就是为什么我们不允许将其作为提供者。但你可以传递它。它并非禁止，只是不是默认值。我们想确保您的默认值始终可用，并且在“快乐路径”中始终可用。我们会为您量化模型。所以当我们量化时，这意味着我们使用了一系列技巧，非常感谢 Hugging Face 的 Optimum。所以我们在量化中做了一系列优化，例如我们压缩了一些激活函数，比如 gelu。我们还做了一些图优化，我们并没有真正大量地丢弃位，例如 32 到 16 或 64 到 32 这样的量化只在需要时进行。
Nirant Kasliwal：这些大部分的性能提升来自于图优化本身。Optimum 自己也提出了不同的模式。如果有人对此感兴趣，我很乐意分享相关文档和详细信息。是的，就是这样。这些就是我们获得大部分速度提升的两个方面。我想这回到了你开头提出的问题。是的，我们确实想支持多模态。我们正在研究如何对 Clip 进行 ONNX 导出，使其与 Clip 一样强大。
Nirant Kasliwal：到目前为止，我们还没有找到任何东西。我花了一些时间研究这个问题，即生活质量升级。到目前为止，我们大部分的模型下载都是通过 Qdrant 托管的 Google Cloud Storage 进行的。我们希望支持 Hugging Face Hub，这样我们就可以更快地推出新模型。所以我们很快就会这样做。接下来，正如我所说的，我们始终将性能视为一等公民。因此，我们正在研究如何让您更改或调整冻结的嵌入，比如说 OpenAI 嵌入或任何其他模型，以适应您的特定领域。也许 Fast Embed 中有一个单独的工具包，它是可选的，不属于默认路径的一部分，因为这并不是您会一直使用的东西。
Nirant Kasliwal：我们希望确保您的训练和体验部分是分开的。所以我们会这样做。是的，就是这样。快速而甜蜜。
Demetrios：太棒了。就像 FastEmbed。
Nirant Kasliwal：是的。
Demetrios：有人提到了你需要擅长双关语，那可能是你最好的，最值得炫耀的东西。还有一个问题，我想问你。是不是当我们使用 Qdrant 客户端添加 Fast Embedding 时，它就包含了？我们不必自己做？
Nirant Kasliwal：你说的“做”是什么意思？是不是你不用指定 Fast Embed 模型？
Demetrios：是的，我想更多的是，你不需要以任何方式将它添加到 Qdrant 中，或者说它是完全分离的。
Nirant Kasliwal：所以这是客户端的。您拥有所有数据，即使在您压缩并发送给我们所有嵌入创建时，它也发生在您自己的计算设备上。此嵌入创建不会发生在 Cauldron 云上，而是发生在您自己的计算设备上。这与您应该拥有尽可能多的控制权这一理念是一致的。这也是为什么，至少目前，Fast Embed 不是一个专用服务器。我们不希望您为 Qdrant 和 Fast Embed 运行两个不同的 docker 镜像。或者说，在同一个 docker 镜像或服务器中，Qdrant 和 Discord 使用两个不同的端口。所以，是的，那比我们想要的混乱多了。
Demetrios：是的，我想如果我理解了，我对这个问题的理解有点不同，它只是说这个是 Qdrant 开箱即用的。
Nirant Kasliwal：是的，我认为这是个好办法。我们为您设置所有默认值，我们为您选择最佳实践，并且根据 MTEB 基准测试，这在绝大多数情况下都应该有效，但我们不能保证它适用于所有场景。例如，我们的默认模型是为英语选择的，并且主要在开放域开放网络数据上进行测试。因此，例如，如果您正在做一些特定领域的事情，例如医学或法律，它可能效果不佳。所以您可能仍然需要制作自己的嵌入。这就是这里的边缘情况。
Demetrios：在使用它时，您可能还需要调整哪些其他参数？
Nirant Kasliwal：使用 Qdrant 还是不使用 Qdrant？
Demetrios：使用 Qdrant。
Nirant Kasliwal：所以有一件事，我的意思是，一个是肯定要尝试我们支持的不同模型。我们支持合理范围的模型，包括一些多语言模型。第二是，虽然我们在您使用 Qdrant 时会处理这个问题。例如，假设这是您必须手动指定，比如说，passage 或 query 的方式。当您这样做时，比如说 add 和 query。我们所做的，我们在为您创建嵌入时添加了 passage 和 query 键。所以这已经处理了。因此，无论您的嵌入模型的最佳实践是什么，请确保在使用它与 Qdrant 或单独使用时都使用它。
Nirant Kasliwal：所以这是一个旋钮。第二个是，我想这是非常普遍的建议，我们会建议您从一些评估开始，比如说，一开始就用五句话，看看它们是否真的彼此靠近。在嵌入检索中，当我们将嵌入用于检索或向量相似性搜索时，一个非常重要的提醒是相对顺序很重要。所以，例如，我们不能说零九总是好的。它也可能意味着在您的领域中，最佳匹配是，比如说，0.6。所以在匹配方面没有绝对的截止或阈值。所以有时人们会假设我们应该设置一个最小阈值，这样我们就不会得到噪音。所以我建议您针对您的查询和领域进行校准。
Nirant Kasliwal：你不需要大量的查询。即使你只是，比如说，从你根据对领域的理解手写的五到十个问题开始，你也会比随机选择一个阈值做得好得多。
Demetrios：这个很好。谢谢。Shreya 在聊天中问，与 Elasticsearch 相比，延迟如何？
Nirant Kasliwal：Elasticsearch？我相信那是一个 Qdrant 基准测试问题，我不知道 Elasticsearch 的 HNSW 索引如何，因为我认为那将是公平的比较。我还相信 Elasticsearch 的 HNSW 索引对它们可以存储的带有有效载荷的向量数量施加了一些限制。所以这不是一个苹果对苹果的比较。这几乎就像比较，比如说，一页纸和整本书，因为据我所知，这通常是比率。我也可能在这方面有些过时了，但我认为这个问题背后的意图是，Qdrant 对于它所做的事情（即嵌入相似性搜索）是否足够快？它绝对是快速的。它用 Rust 编写，Twitter 针对所有相似的推文以非常大的规模使用它。他们运行一个 Qdrant 实例。
Nirant Kasliwal：所以我想如果一家像 Twitter 这样规模的公司，每天可能发布 2 到 500 万条推文，如果他们能够嵌入并使用 Qdrant 来进行相似性搜索，我想大多数人应该对这种延迟和吞吐量要求感到满意。
Demetrios：名字就说明了一切。你把它叫做 Fast Embed 是有原因的，对吧？
Nirant Kasliwal：是的。
Demetrios：我还有一个问题，是关于模型选择和嵌入大小的。考虑到可用的各种模型和嵌入大小，您如何确定最合适的模型和嵌入大小？您刚才已经提到了，可以通过选择不同的模型来调整参数。但是您如何选择哪个模型更好呢？
Nirant Kasliwal：有学术的看法，有工程师的看法，还有黑客的看法。我将按这个顺序给你所有这三个答案。所以学术的和黄金标准的方法可能是这样的：你会去看一个已知的基准，比如 Kilt K-I-L-T，或者多语言文本嵌入基准，也称为 MTEB 或 Beer，即 BEIR，这三个基准中的一个。然后你会查看它们的检索部分，看看其中哪个基准与你的领域或问题区域非常接近。所以，例如，假设你在药理学领域工作，那么客户支持检索任务的相关性几乎为零，除非你专门从事，我不知道，一个药理学订阅应用程序。所以你会从那里开始。
Nirant Kasliwal：这通常需要 2 到 20 小时，具体取决于你对这些数据集的熟悉程度。但这不会花费你，比如说，一个月的时间来做这件事。所以，为了粗略地估算一下数量级，一旦你有了这个，你就会尝试在那个子域数据集上选择最好的模型，然后看看它在你的领域中如何工作，然后从那里开始。此时，你切换到工程师的心态。工程师的心态现在告诉你，构建东西的最佳方式是根据你预见的负载或挑战做出明智的猜测。对吧。就像土木工程师根据预期车流量建造桥梁，他们显然不会建造一座能承载船只或飞机的桥梁，那是非常不同的。所以你从那里开始，你说，好的，这是我预期的请求数量，这是我的预算，你的预算通常是，比如说，延迟预算、计算预算和内存预算。
Nirant Kasliwal：例如，我提到二进制量化和乘积量化的原因之一是，使用二进制量化，您可以获得 98% 的召回率，但内存节省了 30 到 40 倍，因为它丢弃了所有无关的位，只保留了嵌入本身的零或一位。Qdrant 已经为您测量了它。所以我们知道它对 OpenAI 和 Cohere 嵌入肯定有效。所以您可能想用它来大幅扩展，同时作为一名工程师，控制您的预算。现在，为了做到这一点，您需要对三个数字有所了解，对吧？您的延迟要求、成本要求和性能要求。现在，对于性能，这是工程师最不熟悉的部分，我将给出“黑客”的答案，那就是这个。
Demetrios：这就是我一直在等的。伙计，对此我感到非常兴奋，就是这个。请告诉我们黑客的答案。
Nirant Kasliwal：黑客的答案是这样：我将分享两个技巧。一个技巧是写十个问题，找出最佳答案，然后看看哪个模型能答对这十个问题中的尽可能多。第二个技巧是，大多数嵌入模型（其嵌入维度大于或等于 768）可以通过在其上添加一个小的线性头部来优化和改进。例如，我可以获取 OpenAI 嵌入（其嵌入维度为 1536），将我的文本通过它，然后针对我自己的领域，通过添加两三个线性函数层来调整 OpenAI 嵌入，基本上是 Y 等于 MX 加 C 或 Ax 加 B Y 等于 C 这样的东西。所以这非常简单，你可以在 NumPy 上完成，你不需要 Torch，因为它非常小。头部或适配器的大小通常在几 KB 到一兆字节的范围内，也许。我想我在生产中使用过的最大的是大约 400-500 KB。就是这样。那将把你的召回率提高好几倍。
Nirant Kasliwal：所以这是一个，这是两个技巧。第三个奖励黑客技巧是，如果您正在使用 LLM，有时您可以做的是，提出一个问题并用提示重写它，然后从两者中创建嵌入，并从两者中提取候选。然后使用 Qdrant Async，您可以异步触发这两个查询，这样您就不会被阻塞，然后使用用户提出的原始问题和您使用 LLM 重写的问题的答案，并查看两个结果中都存在的结果，或者找出其他组合方法。大多数 Kaggle 玩家都熟悉集成（ensembling）的概念。这是进行查询推理时间集成的方法，这太棒了。
Demetrios：好的，伙计，我不会撒谎，这个答案比我预期的要多得多。
Nirant Kasliwal：在那里深入探讨了检索的细节。抱歉。
Demetrios：我喜欢它。谢谢。那么，当谈到，我们几周前请来了 Qdrant 的首席技术官 Andre V，他谈到了二进制量化。但是当涉及到量化嵌入模型时，在文档中您提到了量化嵌入模型用于快速 CPU 生成。您能更多地解释一下量化嵌入模型是什么以及它们如何提高 CPU 性能吗？
Nirant Kasliwal：所以，它是一种简写，意思是它们优化了 CPU 性能。我认为更正确的说法是，我们更好地利用了 CPU。但让我们谈谈我们这里所做的优化或量化，对吧？我们所做的大部分都来自 Optimum，而 Optimum 设置的方式是它们称之为级别。所以你基本上可以从，比如说，级别零（没有优化）到，比如说，99（有很多额外的优化正在发生）。这些是你可以切换的不同标志。这里有一些我记得的例子。例如，有一个规范层，你可以与之前的操作融合。然后有不同的注意力层，你可以与之前的融合，因为你不再会更新它们，对吧？所以我们在训练中做的是更新它们。
Nirant Kasliwal：你知道你不会更新它们，因为你正在用它们进行推理。所以，比如说，当有人提出问题时，你希望它尽可能快、尽可能廉价地转换为嵌入。所以你可以丢弃所有这些你很可能不会使用的额外信息。所以有很多这样的事情，显然你可以使用混合精度，大多数人听说过像 lounge CPP 这样的项目，你可以使用 FP16 混合精度或很多这样的东西。比如说，如果你只使用 GPU。所以像 FP16 这样的东西在 GPU 上效果更好。这个声明的 CPU 部分来自于我们使用的运行时 ONNX 如何允许你优化你正在使用的任何 CPU 指令集。所以，举个例子，对于英特尔，你可以说，好的，我将使用 Vino 指令集或优化。
Nirant Kasliwal：所以当我们进行量化时，我们现在是针对 CPU 进行量化的。所以我们未来某个时候想做的是给你一个 GPU 友好的量化模型，我们可以进行设备检查并说，好的，我们可以看到 GPU 可用，并首先为你下载 GPU 友好的模型。太棒了。这回答了问题吗？
Demetrios：我的意思是，对我来说，是的，但我们会看看聊天里怎么说。
Nirant Kasliwal：是的，我们来做吧。
Demetrios：大家都在那说什么。伙计，这太棒了。我非常感谢你来和我们一起探讨我们需要知道的一切，不仅是关于 Fast Embed，我认为还有关于嵌入的普遍知识。好的，回头见。非常感谢你，Naran。感谢所有前来参加的朋友。如果你想演讲，请告诉我们。联系我们，因为我们非常希望你能参加我们的向量空间讲座。
