大语言模型在生产环境中面临成本高和延迟大的挑战，核心原因在于输入输出 Tokens 的数量。优化策略包括将提示词拆分为决策与执行分层架构以减少冗余；优先使用 Python 等传统编程工具处理语言检测、数学计算等简单任务；利用 SQL 或 Python 代替 LLM 进行数据处理；监控最终提示词规模并使用 LangSmith 等工具分析；在 Agent 设计中权衡复杂度与收益。此外，生产环境需引入缓存、降级策略及人工审核机制，确保系统稳定高效。
大语言模型（LLMs）被视为人工智能领域的里程碑式突破，但要将其应用于实际生产环境并确保稳定、高效地运行并非易事。模型的使用成本和响应延迟是目前将 LLMs 应用于生产环境中的核心难题之一。本文旨在解析导致高成本和高延迟的根源，并提供经过实战验证的优化策略。
在构建基于 LLM 的应用时，无论解决方案多么复杂，实质上所有组件最终都会汇总成一条长长的文本信息——'指令性提示词'（Instructional Prompt），传递给 LLM。使用 LangChain 等框架虽然简化了逻辑抽象和组件调用，但开发者需时刻警惕输入信息的膨胀。
一个典型的 LLM Agent 接收到的输入通常包含以下部分：
这些内容的总和构成了最终的 Token 消耗基础。因此，理解 Prompt 的结构是优化的第一步。
LLMs 的响应延迟和使用成本主要取决于输入和输出处理的 Tokens 数量，而非任务本身的逻辑难度。
从成本角度看，Input Tokens 通常是 LLMs 使用成本的'大头'。以主流模型定价为例，Input Tokens 的价格虽仅为 Output Tokens 的三分之一左右，但在复杂任务中，提示词长度往往远超面向用户的 Output Tokens 长度。在使用 LLM Agents 时，约 80% 的 Tokens 来自 Input Tokens，主要包括初始提示词和 Agent 推理过程中的中间消耗。
延迟主要受 Output Tokens 影响。处理 Output Tokens 的时间大约是 Input Tokens 的 200 倍。这意味着生成大量回复会显著增加用户等待时间。对于 To C 领域，面对成千上万次的即时对话需求，成本控制与响应速度直接决定项目成败。
在构建任何 LLMs 应用程序时，除了初始提示词模板之外，至少还需要以下组件，它们都会增加 Token 消耗：
如果依赖最简单的 Agent&Tools 架构，系统的扩展性可能较差。对于每一种可用的工具，都需要在每次调用 Agents 时发送诸如 API 文档之类的详细说明。在准备新系统组件时，需要评估每次调用增加多少个 Tokens 是值得的。
建议实践： 利用 LangSmith 等工具深入分析每次调用的具体 Token 分布。启用调试功能查看最终发送给模型的完整 Prompt，这能帮助我们发现冗余信息并及时消除漏洞。
初次接触时，大语言模型可能令人感到无所适从，但归根结底，我们打交道的仍是软件。这意味着应当事先预料到会出现错误，管理和控制软件系统设计中的抽象层次和模块化程度。
试图用单个提示词来处理更复杂的问题，如同编写难以维护的'意大利面条式代码'。在构建应用时，性能提升的一个关键点是将提示词拆分为两个部分：
这种架构使得我们在每次调用时，首先选取需要使用的特定任务提示词，而无需随附沉重的执行指令，从而平均减少超过 60% 的 Tokens 使用量。
在使用 LLMs 时，最大的误区是忘记可以利用编程来解决问题。一些最大的性能提升，是通过使用 Python 函数在 LLMs 调用的上下游处理简单任务。
示例：语言检测
指示 LLMs 保持回答与用户发送的消息相同的语言，LLMs 仍可能默认回复英文。我们无需借助 LLMs 来检测目前的对话使用的是什么语言，利用 Google Translate API 或简单的 Python 库（如 langdetect）可以更快、更准确地完成这项任务。
from langdetect import detect
def detect_language(text):
try:
return detect(text)
except:
return 'en'
# 获取检测结果后，明确传入提示词
language = detect_language(user_input)
prompt = f"Please respond in {language}."
一旦确定了输入语言，就可以明确地将其传入指导性提示词中，从而减少在 LLMs 的调用过程中需要处理的工作量。
集成了工具的 Agent 能够将 LLMs 的能力提升到新的层次，但同时它们也非常消耗 Tokens。Agent 通常至少需要调用 LLM 两次：第一次是为了规划如何使用工具，第二次则是解析这些工具的输出以便给出最终答案。这一特点意味着，我们在设计提示词时节省的每一个 Token，实际上都会带来双倍的效益。
对于某些较为简单的任务，采用 Agent 的方式可能是'用牛刀杀鸡'，而直接使用带有 Completion 的简单指导性提示词可能就能够达到相似的结果，且速度甚至还能快上一倍。
相较于早期的 GPT-3.5，最新顶尖大语言模型在处理基础数学公式时已有很大进步，但它们更擅长编写 Python 或 SQL，无需数以万亿计的模型参数，就能以 100% 的准确率执行复杂的数学运算。
向 LLMs 传递大量数字会消耗大量 Tokens，在最好的情况下，每 3 位数字都会转换为一个 Token；若数值庞大，单个数字就可能占用多个 Tokens。想要更低成本、更高效率地分析数学运算，窍门在于如何运用 LLMs 理解问题及手头数据，继而转译为 SQL 或 Python 这类更适合进行数学分析的编程语言。
实施流程：
为了跨越从概念验证到生产级应用的鸿沟，还需考虑以下工程化细节：
对于重复出现的相同 Prompt，应建立缓存层。许多企业级应用通过 Redis 存储常见问答对的哈希值，避免重复调用 LLM。
当 LLM 服务超时或成本过高时，系统应具备降级能力。例如，切换到小参数量的本地模型，或直接返回预设的标准答案，保证用户体验不中断。
在高价值任务（如金融、医疗建议）中，必须引入人工审核环节。LLM 生成的内容应先经过规则引擎过滤，再由人工确认后方可发布。
理性看待 LLMs 技术，扬长避短，与其他技术工具形成合力，而非将其视为解决一切问题的'灵丹妙药'。通过拆分提示词、结合传统编程工具、精细化监控 Token 消耗以及合理的架构设计，企业可以更好地将 LLMs 技术应用于生产实践，有效降低落地成本并提升响应速度。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online