LLM对接与模型调用优化：从连接复用到成本控制的工程实践

做 LLM 对接这件事真正花时间的从来不是把 800 行 demo 跑通而是跑通之后怎么让它稳定、省钱、不泄露密钥、还能扛住线上流量。我见过太多团队第一天调通了模型接口第二天就被并发打挂第三天的账单直接翻了几倍。这里面的坑几乎全集中在“模型调用优化”这几个字上。这篇内容是我自己对接 LLM 模型、做 RAG 知识库、搞 Agent 应用过程中整理下来的实操笔记。覆盖直连 API 与本地模型的调用方式、连接复用、成本控制、向量数据库集成、密钥防护以及一批真实踩过的报错。适合正在做 LLM 应用、想把模型调用从“能跑”提升到“能上线”的开发者和架构师也适合刚入门、想系统理解 LLM 对接链路的小白。1. 先想清楚LLM、Agent、AI 模型到底在优化哪一层1.1 三者关系别搞混很多刚接触的人会问常说的 DeepSeek 到底属于哪个Agent 和 LLM 又有什么区别。先说结论DeepSeek 是一个大语言模型属于 LLMLLM 是 AI 模型这个大概念下的一类主要是用海量文本训练出来的语言模型而 Agent 是跑在 LLM 之上的应用架构它利用模型做推理、规划、调用工具最终形成一个能自主完成任务的闭环。所以你在做“LLM 对接与模型调用优化”时首先要分清楚你优化的是模型层、服务层还是应用层。模型层关心的是量化、微调、上下文长度服务层关心的是连接复用、并发、超时、密钥应用层关心的是 RAG 检索、Agent 工具调用、Prompt 设计。这篇博文重点放在服务层和应用层因为绝大多数团队的痛点都出在这两层。1.2 对接技术选型对接 LLM 的常见方式有三种官方 SDK 直连、HTTP API 调用、统一网关接入。官方 SDK 直连开发快但换模型供应商时要改代码且 SDK 内部的重试和日志往往不可控。HTTP API 调用所有模型都暴露 HTTP 接口用 httpx、requests 或 aiohttp 实现可定制程度高是目前最通用的方式。统一网关接入把各家模型 API 包一层对外暴露你自己的接口内部做协议转发、鉴权、限流、日志适合中大型项目。我建议哪怕是小项目也至少做一层薄封装不要直接在业务代码里到处写模型供应商的 SDK。原因很简单模型供应商的 API 升级、换 key、切模型如果只在一处封装影响范围可控如果散落四处每次都是灾难。你甚至可以把模型调用封装成接口时顺便解决“重复初始化”的问题后面会细说。2. 模型调用优化核心单例、连接复用与并发控制2.1 每次请求都重新初始化模型是最大的隐形开销这是我见过最高频的问题“我每次处理一个用户请求就初始化一次模型结果延迟高得离谱”。这不是模型推理慢而是模型加载和连接建立的开销被你重复支付了。举个例子使用本地模型服务时模型文件可能几个 GB 甚至几十个 GB加载进显存需要几秒到几十秒如果每次请求都重新加载等于把推理时间放大了几十倍。用云端大模型 API 也没有好到哪里去每次新建 HTTP 连接、重新握手、重建会话同样会占用大量时间。正确的思路是全局单例 连接复用。模型对象只加载一次之后所有线程和协程共享HTTP 客户端复用连接池不要每次请求都从零创建。包括不太相关的 CLI 工具场景也一样想给命令行工具包一个 HTTP 接口不要每次请求都启动一个子进程去执行 CLI而要先把模型服务本身常驻再把 CLI 逻辑作为薄壳透传。2.2 将模型调用封装成常驻服务我习惯的做法是用 FastAPI 包一层独立的模型服务进程启动时初始化模型客户端或加载本地模型后续请求只走推理路径。核心代码大概长这样# model_holder.py from functools import lru_cache import httpx lru_cache(maxsize1) def get_llm_client() - httpx.AsyncClient: # 全局只初始化一次连接池复用 return httpx.AsyncClient( timeouthttpx.Timeout(connect5.0, read120.0, write60.0, pool30.0), limitshttpx.Limits(max_connections200, max_keepalive_connections50), ) def get_model_instance(): # 如果是本地模型在这里加载权重全局缓存 ...然后在接口层直接调用这个单例。这样有几个好处进程内永远只有一份模型实例内存不会随并发线性增长HTTP 连接池复用后握手开销大幅下降将来做多模型切换时只需要改封装层不用动业务代码。如果你用的是 OpenAI SDK、DeepSeek 这类官方 SDK也别直接 new 一个新 client 塞给每个请求它们是线程安全的和 SQLAlchemy 的 engine 一样全局复用就好。2.3 超时、重试和熔断参数模型调用不能裸奔。AI 服务的响应本身就存在长尾一旦某个时间段请求量大了供应商端也会限流所以调用方必须做好三件事超时、重试、熔断。我的经验参数是连接超时 3 到 5 秒读超时按场景设为 30 到 120 秒重试次数不超过 3 次重试间隔用指数退避加随机抖动例如 1 秒、2 秒、4 秒。注意重试只对网络错误、5xx、429 限流生效对 400 这类参数错误重试多少次都没用。熔断更关键。如果模型服务已经不稳定继续发请求就是在烧钱还会拖垮你的业务。建议在封装层维护一个简单的熔断状态连续失败达到阈值直接快速失败一段时间等模型服务恢复后再放量。很多团队的模型调用接口看起来不稳定不是模型不行而是缺少重试和熔断把偶发错误放大成了雪崩。3. 降低 token 成本从 Prompt、缓存到模型路由3.1 成本构成LLM 调用成本主要来自三块输入 token、输出 token、额外的重试开销。很多人只盯着输出 token其实输入 token 才是隐性刺客。每次请求都带上一大段系统 Prompt、几十个历史消息、若干示例积少成多月账单会很可观。所以优化成本的第一步是记录每次请求的真实 token 数按用户、按场景、按模型维度统计。没有账单拆分一切成本优化都是拍脑袋。3.2 Prompt 与样本效率优化样本效率优化听起来高深落到 LLM 场景其实很朴素用更少的示例达到同样的效果。我有几个实践能用一个示例说清楚绝不用三个。示例要贴近真实场景不要把每个字段都塞进去。系统 Prompt 里的固定内容能合并的合并能删的删。不要为了显得“专业”在 Prompt 里写一堆空话模型不看空话但会计费。举个例子一个商品检索 Agent 的 Prompt如果从 800 token 压到 300 token每天十万次请求成本直接下降 60% 以上而效果基本不变。这里的关键不是压 Prompt 字数而是去掉冗余格式和重复指令保留真正影响行为的约束。3.3 模型路由与缓存把不同任务路由到不同模型是最直接的成本优化方式。简单分类用一个轻量模型排重和摘要可以用中等模型复杂推理才用旗舰模型。很多模型供应商提供多个版本价格能差几十倍不要让所有请求都打最贵的模型。缓存也不能省。对重复度高的请求在封装层做语义缓存或直接缓存结果能省掉大量 token。比如知识库问答中同一个问题在一周内会被反复问到命中缓存后就不再调用模型延迟从几秒降到几毫秒成本归零。我建议至少做一层基于问题和答案文本的精确缓存有条件再上基于向量相似度的语义缓存。4. 知识库场景RAG 与向量数据库集成优化4.1 RAG 链路LLM 对接最典型的应用是 llm wiki 知识库。我的标准 RAG 流程是文档解析、切片、向量化、入库查询时做向量检索、重排、拼接上下文、调 LLM 生成。很多人的 RAG 回答不准确问题不在模型而在链路。链路里最容易被拖累的是两个环节一是把整篇文档都塞进上下文导致输入 token 爆炸二是向量检索召回的内容和相关问题不匹配模型被迫基于错误材料回答。所以 RAG 优化的核心是“让模型只看该看的东西”而不是单纯提升模型能力。4.2 向量数据库选型与调参向量数据库集成与优化关键参数就几个分块大小、重叠大小、检索 top_k、相似度阈值。分块不要过大我一般控制在 300 到 600 个 token 之间重叠 50 到 100 个 token这样能保证语义完整又不会让向量检索的粒度太粗。向量数据库的索引类型也要注意。数据量小可以用暴力检索准确性高数据量大必须用 HNSW 这类近似索引但要调好 M 和 ef_search 参数。M 太小时召回率会下降ef_search 太大时延迟会上升。我见过一个项目把 HNSW 的 ef_search 调到最大结果单次查询耗了几十毫秒整条链路被拖到秒级完全没必要。配合 hybrid search 更稳向量检索和关键词检索各拿一部分结果再做融合排序长尾准确率会明显提升。4.3 Query 改写与重排用户问题往往很短直接拿原问题做向量检索并不理想。比如用户问“它对这块业务的配置怎么改”裸检索基本找不到。我通常在检索前加一个轻量模型改写步骤把问题转换为更完整、更适合检索的形式。重排也很重要。第一轮向量检索可以多召回一些候选比如 top 50然后用一个重排模型或 LLM 对候选重新打分只取 top 3 到 5 条作为上下文。这样既保住召回率又能控制输入 token 和噪声。RAG 做得好不好七分在检索三分在生成。5. 密钥与鉴权信息治理5.1 密钥泄露的几条路径“使用 LLM 时如何防止密钥等鉴权信息泄露”这是每个对接过模型的人都应该问的问题。密钥泄露最常见的路径是写死在代码仓库、打进前端包、打印到日志、被团队成员误提交到公开仓库。写死在配置文件里是不可接受的。任何人的本地 .env 文件、任何测试环境的变量都有可能被复制、被覆盖、被提交。密钥一旦进了 Git 历史即使后来删掉也等于没删必须轮换。5.2 线上方案我的建议是密钥统一放到密钥管理服务或环境变量中应用启动时注入不要出现在代码里。模型调用尽量走自己的后端网关业务侧通过网关鉴权后由网关持有模型供应商的密钥。如果有外部用户直接使用你的模型代理接口一定不要把你的上游密钥直接透传给用户侧脚本。日志里做脱敏打印请求参数时把 Authorization 头和 API Key 字段全部替换成星号。网关方案的额外好处是你可以在网关层控制每个用户的额度防止内部密钥被滥用。很多团队忽略这一点谁拿到 key 都能直接调用月底账单爆炸才发现。5.3 鉴权效率优化有些人会担心走网关加一层鉴权会不会增加延迟。实际上你完全可以用短时效 token 缓存内部凭证比如对模型供应商的凭证做进程内缓存有效期 55 分钟剩 5 分钟提前刷新。这样大多数请求不用重新走供应商的鉴权握手又没有泄露风险。鉴权和安全不该靠每次请求都验一遍来保证靠的是密钥管理制度的严格性。6. 常见报错与性能排查实录6.1 报错速查表报错表现常见原因处理方式provider rejected the request schema or tool payload函数调用或工具调用的 JSON Schema 格式不对模型不识别检查 tool 参数里的 type、properties、required 是否符合模型要求的 schemallm request failed: user-friendly information本地模型服务返回了不友好的错误结构通常缺少 status 和 message 字段在封装层统一解析响应不要把供应商原始错误直接抛给上层请求超时模型推理慢或服务端排队区分连接超时和读超时按场景调整读超时并加超时重试返回内容被截断输出 token 上限设置过小调高 max_tokens同时关注成本并发一高就报限流超过了供应商的每分钟请求限制加本地令牌桶限流同时做退避重试tool payload 解析失败模型返回的 JSON 里有换行或嵌套转义用容错 JSON 解析并允许模型按标准 markdown 代码块返回 JSON这里最值得展开的是 provider rejected the request schema or tool payload。这个报错基本都是工具的 function calling 格式不匹配。官方文档里的 schema 长得很简单实际写起来各种类型嵌套、enum 枚举、additionalProperties 是否开启都会导致严格模式拒绝。我遇到这种问题时会先把 tool 定义简化到最小逐步加字段用二分法定位是哪个字段触发了 rejection。6.2 性能瓶颈排查模型调用慢不要只盯着模型本身。我用链路追踪把每个环节的耗时拆出来通常瓶颈藏在四个位置DNS 解析和 TCP 握手网络层问题换连接池或换供应商接入点。模型服务排队云端 API 的排队时间需要看供应商响应头里的 queue 时长。向量检索数据库慢查询检查索引类型和 top_k。重排和上下文拼接重排模型延迟过高或被检索结果长度拖累。如果 RAG 底层还依赖关系型数据库做结构化筛选慢 SQL 优化同样重要。给候选 id 列表加上索引把大查询拆成批量小查询能明显降低整条链路的延迟。不要以为上了向量数据库就万事大吉混合检索里那部分 SQL 往往是隐性杀手。6.3 真正的优化思维最后说一个我自己的体会。网上很多“系统优化”的内容比如清理电脑垃圾、改系统配置和 LLM 调用优化完全是两回事。LLM 优化不是把某个参数调到最大而是做取舍延迟、成本、质量、安全四者不可能同时拉满。你能做的是把每个环节的任务拆清楚让模型只处理非它不可的部分其余交给缓存、检索和规则。我在实际项目中养成的习惯是每次上线前都会检查一遍模型调用封装层看连接池是否复用、超时重试是否合理、密钥是否只在服务端出现、日志是否脱敏。这几个点查完线上事故率会低很多。如果你现在正被某个模型调用问题卡住比如并发上不去、账单超标、RAG 答非所问不妨按这篇文章里的链路重新梳理一遍。模型本身的能力是一部分但调用方式、数据准备和工程防护往往比“换一个更大更强的模型”更值得花时间。