调用一次 LLM API 并不难。对大多数模型服务来说，借助官方 SDK，往往几行代码就能完成第一次请求。

真正困难的是，当应用开始面对真实用户之后，如何让这次调用持续保持足够快、成本可控并且稳定可靠。随着对话轮次增加，上下文越来越长，Token 成本会不断累积；流量上升后，Rate Limit 往往会在最不合适的时候出现；而很多 LLM API 本身又是无状态的，每次请求结束后都不会记住上一轮发生了什么。

因此，一个真正可以进入生产环境的 LLM 应用，远不只是“选一个模型然后调用 API”。除了模型本身，还需要考虑访问方式、缓存、重试、限流、会话状态、模型路由和可观测性等一整套外围工程能力。

本文将从 LLM API 的能力和计费方式出发，讨论如何选择模型与服务商、不同 API 接入模式之间的差异，以及如何构建围绕模型调用所需的缓存、重试和 Memory 层。

LLM API 提供什么，又是如何计费的

要理解 LLM 应用外围为什么需要这么多工程能力，首先要弄清楚 API 本身提供了什么。

从本质上看，LLM API 是一种“推理即服务”（Inference as a Service）：应用通过 HTTP 将 Prompt 发送给服务商，由服务商在自己的计算基础设施上运行模型，再将推理结果返回给应用。

目前最常见的计费方式仍然是按照 Token 使用量收费，不过实际市场上也存在预置吞吐量（Provisioned Throughput）、工具调用、运行时资源以及自托管等其他计费模式。

除了最基础的 Chat 或 Completions 接口之外，大多数主流模型服务商还提供 Embedding、Function Calling、视觉和多模态输入、流式输出以及 Batch Processing 等能力。因此，LLM API 已经不再只是一个“输入文本、返回文本”的接口，而逐渐成为一套完整的模型推理服务平台。

Token 计费通常会分别计算输入和输出，并以每百万 Token 为单位报价。例如，根据公开价格：

OpenAI 的 gpt-5.6-sol 输入价格为每百万 Token 5 美元，输出为每百万 Token 30 美元。Anthropic 的 Claude Sonnet 5 输入价格为每百万 Token 2 美元，输出为每百万 Token 10 美元。

对于不要求即时返回的任务，Batch API 通常还能进一步降低成本。例如 Anthropic 的 Batch API 价格约为标准调用价格的 50%。

不同厂商的具体价格并不相同，但有一个普遍规律：输出 Token 往往比输入 Token 更贵，而长对话会不断放大输入成本。因为在传统无状态 API 中，每一轮调用都需要重新发送此前的对话历史。

这也是为什么 LLM 应用一旦进入持续对话场景，会很快遇到上下文裁剪、对话摘要和 Session 管理问题。

如何选择 LLM API 服务商

很多团队在选择模型时首先会看 Benchmark，但真正决定用户体验的，往往首先是性能表现。

这里的“性能”不只是平均响应时间，还包括首 Token 延迟（Time to First Token，TTFT）、后续 Token 的生成速度，以及系统在高并发负载下是否仍然稳定。

平均响应时间很快，并不代表实际体验一定好。如果一个服务偶尔出现非常慢的请求，即使平均值仍然不错，这些长尾延迟（Tail Latency）仍然可能明显影响用户体验。而不同模型和服务商之间，长尾延迟的差异往往非常明显。

模型质量同样重要，但它又很难通过一个统一的分数判断。

某个模型即使长期位于公开 Benchmark 或排行榜前列，也不意味着它一定适合你的业务任务。对于生产系统来说，更可靠的方法通常是使用自己的 Prompt、数据集和真实业务任务进行评测。

换句话说，模型选型应该建立在自己的 Eval 上，而不是完全依赖第三方排行榜。

实际选型时，需要在质量、延迟和成本之间寻找平衡。这三个维度往往彼此制约：更高质量的模型通常意味着更高成本或更长延迟，而极端追求低成本和低延迟，又可能牺牲任务质量。

很多情况下，这三个目标很难同时做到最优。

除此之外，还必须考虑数据处理方式。不同模型服务商对于 Prompt、输出内容的保存时间、数据所在区域以及合规承诺都有不同规定。如果应用涉及金融、医疗、政府或其他受监管数据，那么这些因素的重要性通常远高于 Benchmark 上几个百分点的差距。

LLM API 的几种主要接入方式

选定模型之后，还有一个经常被忽略的问题：通过什么方式访问它。

同一个模型往往可以通过不同的平台和基础设施获得。实际项目中，常见的接入方式大致可以分为四类，它们之间的核心差异是运营控制权和服务便利性之间的取舍。

最直接的是模型厂商自己的专有 API，例如 OpenAI 或 Anthropic。这类方式通常采用按 Token 付费，几乎不需要自己维护推理基础设施，也可以较早使用最新的前沿模型。但模型权重并不开放，对特定厂商 API、功能和接口的依赖也更强，因此迁移成本通常较高。

第二类是通过云厂商访问模型，例如 Amazon Bedrock、Azure OpenAI 或 Vertex AI。这样做的优势在于可以直接继承现有云环境中的 IAM、网络、安全、账单、数据驻留以及预置吞吐量等能力，对于已经高度依赖某一家云平台的企业尤其方便。

第三类是开放权重模型（Open-weight Model）的托管推理 API。应用仍然按照 API 或 Token 使用量付费，但底层运行的是开放权重模型。有些平台还会在多个推理服务商之间进行路由，从而在价格、性能和可用性之间进行优化。

最后一种方式是自行托管开放权重模型。这种模式提供最高程度的控制能力：模型权重、数据路径、部署区域和推理基础设施都掌握在企业自己手中。但与此同时，GPU 资源会形成相对固定的成本，无论硬件处于高利用率还是空闲状态都需要承担，并且还需要真正的 MLOps 能力负责模型部署、扩缩容、升级、监控和故障处理。

在实际系统中，并不一定需要只选择其中一种模式。一个常见策略是将复杂推理、规划和高价值任务交给能力更强的 Frontier Model，而将分类、信息抽取、简单判断或检索辅助任务交给成本更低的模型。

这种分层使用模型的方式，往往能够在不明显影响最终质量的情况下显著降低推理成本。

如何把 LLM API 集成进应用

无论最终选择哪一种访问模式，应用侧的基础集成方式通常比较类似。

模型服务商一般会使用 Bearer Token 或 API Key 对请求进行认证。生产环境中，这些凭证应该存储在专门的 Secret 管理系统中，并且按照开发、测试和生产环境分别管理，而不是直接写入代码或配置仓库。

对于需要即时交互的应用，通常还会采用 Server-Sent Events（SSE）进行流式输出。这样用户可以在模型生成过程中立即看到内容，而不是等待整段回答全部生成完成。

如果应用需要结构化输出，优先使用服务商 SDK 提供的 Schema 解析能力会更加可靠。例如 Python 中可以结合 Pydantic，JavaScript / TypeScript 中则经常使用 Zod。这样可以让应用中的类型定义和模型返回的 JSON Schema 保持一致，减少手工解析和字段不一致的问题。

Tool Calling 的工作流程也相对固定：应用首先向模型定义可用工具，模型根据请求决定是否调用某个工具；应用实际执行工具，再将执行结果返回给模型，由模型继续生成后续回答。

这里有一个非常重要的安全原则：模型生成的 Tool Call 应当像用户输入一样被验证。

LLM 并不是可信执行环境。模型给出的工具名称、参数、路径甚至 SQL 都不能因为“来自模型”就直接执行。应用仍然需要进行参数校验、权限控制、输入过滤和业务规则检查。

错误处理同样需要区分错误类型，而不是简单地“失败就重试”。

429 Rate Limit 和 5xx 服务端错误通常属于临时错误，可以采用指数退避（Exponential Backoff）并加入 Jitter 后重试。相比之下，400 Bad Request 或 401 Unauthorized 一般意味着请求参数或认证配置本身有问题，继续重试既不会解决问题，还会浪费调用额度和系统资源。

用缓存降低 LLM API 的成本和延迟

重试机制解决的是可靠性问题，而缓存解决的是另一个更现实的问题：如何减少重复推理。

对于 LLM 应用，目前有两类缓存尤其值得关注，而且两者可以同时使用：Prompt Caching 和 Semantic Caching。

Prompt Caching 主要解决重复上下文的问题。

很多 LLM 请求虽然用户问题不同，但前面往往包含大量完全相同的内容，例如 System Prompt、Tool 定义、企业知识、参考文档或固定规则。如果模型每次都重新处理这些内容，就会产生大量重复的 Prefill 计算。

Prompt Caching 会复用此前已经计算过的 Prompt 前缀，从而避免重复处理相同上下文。服务商通常会对缓存写入收取一定费用，而后续读取同一个缓存前缀时给予较大折扣。

在大量请求共享长 System Prompt 或工具定义的场景中，这种方式可以明显降低成本。

但它也存在限制：缓存通常依赖 Prompt 前缀完全一致。一旦前面的内容发生变化，后面的缓存内容可能全部失效。因此，想充分利用 Prompt Caching，Prompt 的组织方式本身也需要进行工程设计。

Semantic Caching 则进一步突破了“完全相同字符串”的限制。

它并不要求用户输入完全一致，而是判断两个问题在语义上是否足够相似。应用首先将 Query 转换为向量 Embedding，然后在缓存中搜索相似历史请求。如果相似度超过设定阈值，就可以直接返回之前生成的答案，而不再调用 LLM。

例如“如何重置密码”和“我忘记密码了，怎么重新设置”虽然文字不同，但语义非常接近。如果业务允许复用同一答案，Semantic Cache 就可以直接命中。

对于大量重复性较强的生产工作负载，一个配置合理的 Semantic Cache 可以直接处理相当一部分请求，从而同时降低模型调用成本和端到端延迟。

Redis 在这类场景中具有天然优势。由于数据主要保存在内存中，缓存查询可以保持非常低的延迟。同时，Redis 本身已经支持 Vector Search，因此常规缓存、Session State、向量检索和 Semantic Cache 可以运行在同一套数据基础设施上。

Redis 目前还将这一能力进一步封装为面向 AI 应用的托管上下文服务 Redis Iris。其中的 Redis LangCache 提供 Semantic Caching，通过语义匹配判断请求是否可以直接复用已有结果，从而让应用无需自行维护 Embedding 生成和向量检索流程。

目前 LangCache 仍处于 Public Preview 阶段。

Rate Limit、重试和 Session State

缓存能够减少 API 调用次数，但无法完全消除调用。因此，一个生产级 LLM 应用仍然需要正确处理 Rate Limit。

模型服务商通常不会只限制一个指标，而是同时限制多个维度，例如 Requests Per Minute（RPM）和 Tokens Per Minute（TPM）。哪个指标先达到上限，哪个就会成为系统瓶颈。

需要特别注意的是，失败请求本身也可能计入配额。

因此，当系统遇到 429 时，如果所有实例立即开始高频重试，很容易形成 Retry Storm，不但不能恢复服务，反而会进一步消耗剩余额度。这也是为什么指数退避和随机抖动非常重要。

除了 Rate Limit，另一个必须由应用自己负责的问题是 Session State。

大多数 LLM API 默认都是无状态的。模型不会自动记住用户上一轮问了什么，所以应用通常需要在每次请求时重新发送必要的对话历史。

随着对话增长，这会带来两个直接问题。

首先是成本。历史消息越长，每一轮请求的输入 Token 就越多。

其次是质量。上下文并不是越长越好。当大量历史内容不断积累，真正重要的信息可能被淹没在冗余上下文中，模型的注意力和回答质量反而可能下降。

虽然部分模型服务商已经开始提供 Server-managed Conversation State，但很多团队仍然选择自己管理会话状态。这样可以根据业务需求主动进行历史裁剪、摘要压缩、跨服务共享以及长期 Memory 管理。

由于几乎每一次用户请求都需要读取 Session，这个存储层的延迟非常重要。Redis 作为内存数据平台非常适合承担这一职责，同时还能为数据设置灵活的过期策略。

Redis Iris 在此基础上提供了 Redis Agent Memory，采用短期与长期两层 Memory 结构：短期 Memory 保存当前交互历史，长期 Memory 则保存用户偏好以及跨 Session 的历史信息，使 Agent 可以在不同轮次甚至不同会话之间保持上下文。

相比之下，如果 Session 只保存在应用进程内，一旦进程重启数据就会丢失，而且在负载均衡、多实例部署或 Multi-Agent 架构中也很难共享。

在模型 API 之外构建 GenAI Gateway

缓存、重试、Rate Limit 和模型路由分别解决不同问题。

当应用规模逐渐扩大，涉及的团队、模型和服务商越来越多时，一个自然的演进方向是将这些能力抽象成共享基础设施层，也就是通常所说的 GenAI Gateway。

GenAI Gateway 位于业务应用和模型服务商之间。模型路由、Guardrails、身份认证、审计、限流、缓存和可观测性都可以在这一层统一处理，而不需要每个业务服务分别实现。

Uber 就曾构建自己的 GenAI Gateway，为公司内部约 60 个 LLM 使用场景 提供统一服务。

在 Gateway 中，模型路由通常是最重要的成本优化手段之一。

并不是所有请求都需要能力最强、价格最高的模型。如果 Router 能够识别任务复杂度，就可以只将真正困难的问题发送给昂贵模型，而把简单任务交给更便宜的模型处理。

如果路由策略足够准确，这种方式往往可以明显降低整体推理成本，而不会让用户明显感知到质量下降。

可观测性同样非常重要。

生产环境不应该只知道“这个月 API 花了多少钱”，而应该进一步追踪每一次请求的 Token 使用量，并能够将成本关联到具体功能、模型、用户甚至业务租户。

只有做到这个粒度，团队才能真正知道哪些功能正在消耗推理预算，也才能判断 Prompt 优化、缓存或模型路由是否真正有效。

一些 GenAI Gateway 也会使用 Redis 作为共享数据层，用于 Semantic Cache、Rate Limit 和跨实例状态管理。

不过，Gateway 并不是所有项目的必选项。

如果系统只涉及少量模型和少数团队，直接在应用中实现这些能力往往更加简单，同时还能减少额外的网络跳转和架构复杂度。关键在于，即使暂时不建设统一 Gateway，也应该让缓存、路由、限流和模型调用之间保持足够松耦合，避免未来扩展时不得不整体重构。

真正的 LLM 架构远不止一个 API

选择 LLM API 时，不能只比较每百万 Token 的价格。

真正需要综合考虑的是延迟、任务级质量、数据处理方式以及模型访问模式。一个价格便宜的模型，如果响应速度不稳定、任务准确率不足或者无法满足企业的数据要求，并不一定意味着更低的总体成本。

而模型选定之后，真正的工程工作才刚刚开始。

生产级 LLM 应用需要通过缓存减少重复推理，通过 Backoff 和 Rate Limit 管理保证调用稳定，通过外部 Session Store 为无状态 API 提供上下文能力，并在系统规模扩大后进一步引入模型路由、统一网关和可观测性。

从这个角度看，LLM API 本身只是 AI 应用架构的一部分。

Redis Iris 试图将这一外围 Context Layer 封装为托管服务，包括 Semantic Caching、Agent Memory 和支持字段级过期的 Session Storage，底层同时提供 Vector Search 能力。

对于本身已经使用 Redis 进行缓存或 Session 管理的团队而言，这意味着 AI Context Layer 可以建立在既有数据基础设施之上，而不一定需要为每一种需求重新引入一套独立系统。