LLM API 接入工程实践：选型、定价与缓存设计
调用一次 LLM API 很容易——用多数提供商的 SDK，大约五行代码。但真实用户出现后，让调用保持快速、便宜、可靠，才是真正的工程：对话变长时成本叠加、限流在最糟的时机出现、无状态 LLM 端点每次请求后都会忘记对话状态。
这篇指南覆盖 LLM API 提供什么、如何定价、怎么选提供商和接入模型，以及如何在调用外围构建缓存、重试和记忆层。
LLM API 做什么、怎么收费
LLM API 本质是"推理即服务"：你通过 HTTP 发送提示词，提供商在自己的硬件上运行模型，通常按 token 计费，此外也存在预置（provisioned）、工具、运行时和自托管等定价模式。除核心的 chat/completions 端点外，多数提供商还提供向量嵌入（相似度搜索）、函数调用（结构化工具调用）、视觉和多模态输入、流式输出、以及异步批处理。
提供商一般按每百万输入/输出 token 分开报价：OpenAI 的 gpt-5.6-sol 为每百万输入 5 美元、输出 30 美元；Anthropic 的 Claude Sonnet 5 为输入 2 美元、输出 10 美元。批处理能大幅降成本，例如 Anthropic Batch API 按标准价格 50% 收费。输出 token 通常比输入贵，长对话会推高输入成本——会话状态一节会讲裁剪和摘要。
如何选 LLM API 提供商
真正影响用户体验的是速度：首 token 到达有多快、之后 token 流式输出的顺畅程度、高负载下 API 的表现。平均响应时间快还不够，尾部延迟（偶发慢响应）同样会烦人，而且不同提供商差异很大。
质量也很重要，但很难用一个分数钉死。登顶公开榜单的模型也可能在你自己的任务上表现不佳，可靠的测试方式是看它在你自己的提示词和数据上的表现，而不是别人设计的基准排名。质量、速度、成本三者互相牵制：追求最高质量通常意味着更慢或更贵的模型，优化速度与成本则可能牺牲质量——通常只能得到三者中的两个。
最后考虑数据处理：提供商保留你的输入输出多久、数据存在哪里、提供什么合规保证。处理受监管数据时，这些细节比基准分数更重要。
四种接入模型
提供商常把同一模型通过多个入口提供，四种接入模式覆盖大多数场景，权衡点是运营控制与提供商便利性：
- 专有 API（OpenAI、Anthropic）：按 token 即付即用，运维负担最小，能拿到前沿模型，但权重专有，迁移成本最高；
- 云中介接入（Bedrock、Azure OpenAI、Vertex AI）：通过现有云账号计费，提供云 IAM、驻留控制和预置吞吐量选项；
- 开源模型推理 API：按 token 无服务器访问开放权重模型，常可在多个提供商间路由；
- 自托管开源模型：完全掌控数据和权重，代价是无论硬件忙闲都要承担固定 GPU 成本，还需要真正的 MLOps 人力。
一个实用的做法是拆分：推理密集步骤用前沿 API，分类和检索用更便宜的开源模型访问，既降成本又保留强模型处理更关键的任务。
集成 LLM API 的机制
无论哪种接入模式，集成机制都相似。提供商用 bearer token 或 API key 鉴权，应安全存储并按环境分离。交互式应用通常用服务器发送事件（SSE）流式输出 token，让用户看到生成过程而不是等待完整响应。
结构化输出尽量依赖提供商 SDK，多数支持 schema 解析（Python 的 Pydantic、JavaScript 的 Zod），让代码类型与 JSON schema 保持同步。工具调用是一个简单循环：定义工具 → 模型选择工具 → 应用执行 → 把结果发回。把模型生成的任何工具调用都当成用户输入对待，执行前必须校验。
重试前要分类错误：限流（429）和服务器错误（5xx）通常是临时的，用指数退避加抖动重试；400 坏请求和 401 鉴权失败不会自己变好，重试只会浪费钱和额度。
用缓存削减成本与延迟
重试保证运行，缓存则能显著减少重复推理的开销。两层缓存特别有效，而且可以叠加：提供商侧提示词缓存和语义缓存。
提示词缓存复用模型对重复提示前缀的工作，跳过静态系统提示词、工具定义和参考文档的重复处理。提供商对写缓存收少量溢价，对读缓存前缀给大幅折扣，重复上下文越多省得越快。注意：缓存前缀的任何改动都会使之后的内容全部失效。
语义缓存更进一步：不要求提示词完全一致，按含义匹配。应用把每个提示词转成向量嵌入，与缓存条目比对，相似度足够高就直接返回缓存响应，完全不调用 LLM。在生产负载中，调好的语义缓存能让很大比例的请求直接从缓存返回，成本和延迟都大幅下降。
Redis 在这里的位置：数据驻留内存，缓存查找在亚毫秒级，足以直接放在请求路径上；同一个平台既做常规缓存和会话，又支持向量搜索和语义缓存，不需要另起炉灶。Redis 把这块封装为面向 AI 应用的管理式上下文引擎 Redis Iris：语义缓存服务 Redis LangCache 按含义匹配查询并返回缓存响应，目前处于公开预览。
限流、重试与会话状态
缓存减少调用次数，限流决定频繁调用时会发生什么。提供商通常同时在多个维度限流（如每分钟请求数和每分钟 token 数），先撞到哪个天花板就停在哪。失败的请求往往照样计入配额，盲目重试 429 只会让坑更深。
会话状态是另一件需要自己掌握的事。多数 LLM API 无状态，每次请求都要重发完整对话历史，后果是对话变长时 token 成本堆积，上下文过长后质量下降。部分提供商开始提供服务端管理的会话状态，但很多团队仍自建存储，以便裁剪、摘要和跨服务共享上下文。这个存储要快，因为应用通常每次请求都会读。Redis 天然契合——内存存储、支持字段级过期；Iris 在此基础上提供 Redis Agent Memory 双层服务：短期交互历史加长期记忆（偏好与历史会话），让 Agent 跨轮次和会话保持上下文。
来源：Choosing & integrating LLM APIs: a practical guide - Redis