优化大型语言模型以提高成本效率
explainpaper.com 的创建者 Aman Jha 最近分享了令人大开眼界的账单，使用他的流行的 OpenAI 驱动的论文摘要和问答应用程序一个月。
对于一些开发人员来说，OpenAI 成本正在超过 AWS 成本，成为云基础设施支出的首要项目。 OpenAI API 和 LangChain 等框架上的大量开发人员活动创造了一种新的应用程序类别。大型语言模型 (LLM) 使得为 HN 构建聊天机器人和创建可以进行复杂情感对话的 AI 成为可能。
LLM 使用消费定价模型，该模型根据应用程序和 AI 之间交换的文本字符（令牌）的数量收费。每个 AI 都有一个固定的“令牌窗口”，用于模型可以为当前任务保留的上下文长度。例如，GPT-4 可以使用 8,192 个令牌来存储聊天的对话历史记录。即使上下文长度是固定的，提示长度和响应长度也是不可预测的。这些独特的计费参数为使用 LLMS 的开发人员带来了一系列新的成本优化技术。
其中一些 LLM 成本优化技术包括：
Prompt Engineering 提示工程 Caching with Vector Stores 用向量存储缓存 Chains for Long Documents 长文档链 Summarization for Efficient Chat History 高效聊天记录的总结 Fine Tuning
让我们更深入地研究定价模型，然后看看如何使用这些技术来提高 LLM 应用程序的成本效率。
OpenAI、Anthropic 和 Cohere 的定价
OpenAI 有不同定价的文本和图像 API。在这篇文章中，我们将重点关注文本 API，包括 Text Completion 、 Embeddings 和 Fine-tuning 。虽然 OpenAI 率先上市，但 Anthropic 和 Cohere 提供了类似的 API 来与他们的 LLM 进行交互。
Token
文本 API 按令牌收费，其中 OpenAI 将令牌定义为大致“四个字符”。要了解一段文本中有多少标记，您可以使用标记器。将此段落粘贴到 Tokenizer 计数为 77 个标记，因此此文本块将花费 0.00231 美元传递给 GPT-4。
OpenAI Pricing
下表中的前三个模型用于 Completions API，用于回答问题、总结文档和生成文本。嵌入和微调 API 用于为模型提供额外的上下文和训练数据。
API Name Model Series Context Window Price Per 1,000 Tokens 每 1,000 个代币的价格 text-davinci-003 GPT-3.5 4,096 $0.02 gpt-3.5-turbo GPT-3.5 4,096 $0.002 gpt-4 GPT-4 8,192 $0.06* embedding GPT-3 4,096 $0.0004 fine tuning GPT-3 4,096 $0.12
- GPT-4 对提示和完成有不同的定价，每 1000 个提示令牌收取 0.03 美元，每 1000 个完成令牌收取 0.06 美元。
您可以看到目前最便宜的型号是 gpt-3.5-turbo，它与 ChatGPT 中运行的型号相同。新的 GPT-4 模型要贵得多，但提供更强的逻辑推理能力，并具有更大的令牌窗口。嵌入和微调 API 运行 GPT-3 系列中最古老的模型。
Anthropic and Cohere Pricing
让我们来看看两家初创公司 OpenAI 竞争对手的定价。每百万代币的人为价格，而 Cohere 使用“生成单位”。下表将这些标准化为 1,000 个令牌。 Anthropic 的 Claude 是一个大型语言模型，它也有一个“即时”版本，该版本将是更小、更快的模型。 Cohere 按任务并可能按模型分离它们的端点，因此生成和汇总端点具有不同的定价。
API Name Model Series Context Window Price Per 1,000 Tokens 每 1,000 个代币的价格 claude-v1 Anthropic Claude 9,000 $0.0086 claude-instant-v1 Anthropic Claude 9,000 $0.00145 command-xlarge Cohere Generate $0.0025 summarize-xlarge Cohere Summarize 8,192 $0.005
你可以看到 claude-instant-v1 比 gpt-3.5-turbo 稍微便宜一点，而 Cohere 的端点稍微贵一点。 AI 领域目前发展得非常快，但您可以在 LessWrong 的这篇文章中了解如何比较不同模型的性能。
Optimizing Large Language Models
鉴于这些定价维度，成本优化的目标是使用最少数量的代币高质量地完成任务。下面的技术大致按照从最容易到最难实施的顺序排列。
Prompt Engineering 提示工程
提示是指示模型做什么的起点。例如，我们一直在试验一个问答机器人，它包含如下提示，改编自 Supabase Clippy 提示：
You are a very enthusiastic AWS solutions architect who loves to help people!
Given the following sections from the AWS documentation,
answer the question using only that information, outputted in markdown format.
If you are unsure and the answer is not explicitly written in the documentation,
say "Sorry, I don't know how to help with that."
Context sections:
{context}
Question: {question}
Answer as markdown (including related code snippets if available):
Example prompt for a Q&A bot. 问答机器人的示例提示。
提示包含在令牌计数中。在上面的示例中，每次用户向我们的聊天机器人提交问题时都会发送此提示。提示工程是一个新兴领域，它试图通过修改提示来从 LLM 中发现并产生最佳结果。您可以使用提示工程来大致控制返回的令牌数量。
对于 GPT-3.5，我们似乎可以指定令牌的数量，并且模型会将其响应保持在该数量以下。对于 GPT-4，根据段落数指定输出量并使用“简洁”、“总结”等短语效果更好。 通过这种方式，您可以为您的应用程序建立“令牌预算”，然后根据您拥有的用户数量和他们的平均使用情况来估算将发送的消息数量。
Caching with Vector Stores 用向量存储缓存
向量存储是存储大量数字的数据库。它们是使用 LLM 的关键基础设施，正确使用它们可以节省大量成本，而不是对基础模型进行许多 API 调用。
流行的矢量数据库包括 Pinecone、Weaviate 和 Milvus。您可以将矢量数据库在这些应用程序中的作用视为“大型语言模型的缓存”。
preprocessed_content = remove_newlines('file')
chunks = split_into_chunks(preprocessed_content, chunk_size)
vector_store = pinecone.VectorStore(index_name="markdown-chunks")
for i, chunk in enumerate(chunks):
vector_store.set_item(str(i), chunk)
Loading markdown documents into a vector store using Python. 使用 Python 将降价文档加载到矢量存储中。
通过将文档语料库拆分为块，为每个块创建嵌入，并向量化输入的用户查询，可以减少需要传递给模型以回答问题的上下文量。
在上面的代码中，我们有一个预处理步骤，在将它们加载到向量存储之前删除换行符等元素。这通过减少存储空间需求进一步降低了成本，因为清理后的数据占用的空间更少。加载的文档更少也意味着更低的 Embeddings API 成本，即每 1,000 个令牌 0.0004 美元。
Chains for Long Documents 长文档链
如果文本量大于最大上下文长度怎么办？换句话说，您可能有一个大的 PDF 文档或一组损害产品文档的降价文件。对于 explainpaper.com，用户可能会要求 AI 总结整篇论文。
要完成这样的任务，您可以使用重复调用 LLM 并在成本和性能方面进行不同权衡的链。来自 Data Independent 的 Greg Kamradt 回顾了这些技术以及如何在 YouTube 视频中实施它们。
Map Reduce - 这个经典过程将大文档拆分为较小的文档，为每个部分创建摘要，然后创建这些摘要的摘要，直到您获得整个文档的摘要。虽然这可以并行快速完成，但它也会丢失大量信息并需要调用许多 API。
Refine - Refine 一次构建一个部分的摘要，将每个先前的摘要同步附加到当前部分。这样可以更好地维护文档的上下文，但需要更长的时间才能完成。它使用比 map reduce 更少的令牌并且更便宜。您可以将其视为 O(N) 搜索答案。
Map Re-Rank 地图重新排序——如果问题不是“总结整个文档”，地图重新排序是最具成本效益的方法。它一次总结 2 个部分，并选择其中包含答案的置信度最高的摘要。您可以将此方法视为 O(log(N)) 搜索答案。
虽然这些技术目前是最先进的，但它们可能不会持久。 GPT-4 有一个带有 32K 令牌窗口的变体，每 1,000 个令牌 0.12 美元。这意味着您可以将大约 50 页文本放入 1 个标记窗口。
Summarization for Efficient Chat History 高效聊天记录的总结
如上所述，大型语言模型的一个限制是“令牌窗口”，它是 GPT4 的大约 8K 令牌或 GPT3.5 的 4K 令牌。对于聊天机器人，该窗口是模型将拥有的关于它正在执行的聊天对话的所有“知识”。显然，这对于像编码代理这样的用例来说是有问题的，它可能在整个长时间的会话中与程序员在一起，或者支持可能有数百条消息的聊天。
即使对话可以容纳在聊天窗口中，今天的聊天机器人“记住”对话的方式是将对话的整个历史记录传递到令牌窗口中。这意味着在典型的聊天机器人实施中，对话进行的时间越长，成本就越高。这张图直观地展示了这里发生的事情。
为了节省代币，我们可以使用聊天 API 本身。聊天中的每 N 条消息，您都可以获取之前的整个对话并对其进行总结，使用摘要作为恢复对话的上下文并减少传递给 API 的令牌计数并节省资金。请在此处查看示例实现。
但这有一个问题。您可能会丢失聊天中的关键信息，尤其是当摘要在多个 N 大小的窗口中进行时。一种最终仍能省钱的更先进的技术是为聊天历史创建向量，并为每次聊天创建一个当前对话的向量，并从存储的聊天历史中查找所有最相似的向量。然后可以将这些作为提示的上下文传递给 API。
Fine Tuning
在某个时候，您拥有的数据可能足够专业，以至于 Fine-tuning API 变得有意义。换句话说，您可能希望模型在不进行嵌入或汇总的情况下已经知道它需要的上下文。这方面的一个例子是保险索赔的聊天机器人。一家大型保险公司可以选择根据自己的数据简单地微调他们的模型。
要了解此处的定价，您需要了解微调端点按每 1000 个令牌收费，但会多次通过数据进行训练。默认情况下， n_epochs 设置为 4，这意味着微调数据的成本大约是您拥有的数据量的 4 倍。
请注意，在撰写本文时，可用于此端点的模型数量有限。对数据进行微调后，访问特定端点的成本也会更高。来自 OpenAI 的 DaVinci 模型每 1,000 个令牌的训练成本为 0.03 美元，每 1,000 个令牌的查询成本为 0.12 美元。
Conclusion: Models Rule Everything around Me 结论：模型统治着我周围的一切
上述成本优化技术的一个有趣方面是，每个技术都使用模型本身来降低成本。无论是通过即时工程、嵌入、总结还是微调，构建高效 LLM 应用程序的关键是将优化卸载到模型并让 AI 为您完成工作。
在某些方面，这就像软件工程的任何其他部分一样，您可以通过将计算移近数据来节省资金。例如，在数据工作中，与在后端迭代结果相比，开发人员可能在他们的数据库中有更复杂的 SQL 查询。尽管我们似乎正在进入技术行业的新时代，但很高兴看到构建具有成本效益的应用程序的基本原理保持不变。
资料来源：