16. 有没有用过大模型的网关框架？网关层解决了什么问题？
我用过 LiteLLM，它是目前最活跃的开源 LLM 网关。我理解网关本质上是架在应用和模型 API 之间的中间层，主要解决几个实际问题。
第一是多模型统一接口，业务代码只调一个地方，想换模型只改网关配置，不用动应用代码；第二是 API Key 集中管理，不用每个服务都存一份，降低泄漏风险。
第三是限流和配额，可以给不同团队分别设 token 预算，防止某个团队把整个公司的额度用光；第四是成本追踪，所有请求的 token 用量都在网关记录，方便统计哪个服务最烧钱。
还有一个我觉得挺实用的能力是语义缓存，两个用户问了语义相近的问题，直接命中缓存返回上次的结果，根本不打底层模型，省钱还降延迟。
先建立直觉：网关是什么，放在哪
在讲功能之前，先搭一个清晰的架构感知。没有网关时，你的应用直接对接各个模型 API：应用 -> OpenAI API、应用 -> Anthropic API、应用 -> 其他 API。
有了网关之后，调用链变成：应用 -> 网关 -> OpenAI/Anthropic/其他 API。
网关就是一个中间人，坐在你的应用和各个模型 API 之间。你的应用只认识网关，不需要直接对接多个 API。这个「中间人」的定位是理解网关所有功能的基础，它集中拦截和处理了所有出入流量，所以能在这个位置统一做很多事情。
没有网关时的痛点
一个稍微大一点的 AI 产品，同时用多个模型是常态：主流程用 GPT-4o，成本敏感的任务用 GPT-4o-mini 或 Claude Haiku，代码任务用 Claude Sonnet，向量化用 text-embedding-3-small。每家厂商的 SDK 不一样，鉴权方式不一样，参数格式也有细微差异。如果不做网关，这些差异会渗透到每个业务服务里。
这会带来一连串的麻烦。
首先是安全问题，API Key 散落在各个服务的配置文件里，任何一处泄露都是安全事故。想象一下：某个工程师离职，他存在本地开发机或者内部文档里的 OpenAI Key 没有及时清理，过两周被扫到，黑客拿去跑批量请求，几千美元的账单是一个晚上就能烧出来的。
然后是重复劳动，每个服务都要自己写重试和限流逻辑，你写一套我写一套，版本还不一样，出了 bug 很难排查。更糟的是，不同服务的同一个逻辑（比如「429 了要指数退避重试」）很容易各写各的，A 服务对了、B 服务错了，出问题时先要花半小时搞清楚是哪个服务的重试逻辑在作怪。
再来是成本黑箱，你想知道整个系统这个月花了多少钱、哪个团队用得最多，根本没法统计，因为各服务各记各的。月底财务来问「这笔 3 万美元的 OpenAI 账单分摊给哪个业务线」，你只能两手一摊。
最头疼的是灵活性问题，想给某个团队限制每天的调用量？得改代码。想把某个任务从 GPT-4o 换成 Claude？还是得改代码。典型的场景是：周五下班前某个工程师无意中跑了一个死循环脚本，一晚上把下一周的 token 预算吃光，周一用户打开产品全是 429 报错，这种事一年只要发生一次，你就会意识到配额管理不能指望各服务自觉。
这些问题看起来五花八门，但其实都源自同一个根本原因：没有一个集中的地方来统一管理这些「横切关注点」。
有了网关之后就完全不一样了。API Key 只存在网关这一个地方，业务服务拿到的是网关分配的虚拟 Key，根本接触不到真实密钥。想换模型？改网关的路由配置就行，业务代码一行都不用动。重试、限流、超时这些逻辑也只需要在网关实现一次，所有服务自动享受，不用各自重复造轮子。
多模型统一接口：换模型对业务代码隐形
这个功能理解起来很简单。大多数 LLM 网关（比如 LiteLLM）对外暴露一个 OpenAI 兼容的接口，你的业务代码就像调 OpenAI 一样调它，只需要把请求地址改成网关的地址，API Key 改成网关分配的虚拟 Key。
举个具体例子，假设你的业务代码原来是 openai.chat.completions.create(model="gpt-4o", ...)，接入网关后只需要改两个地方：把 base_url 指向网关地址，把 api_key 换成网关分配的虚拟 Key，其他代码一行不动。
网关收到请求后，根据路由配置决定把这个请求发到哪个实际模型，可能是 OpenAI、Azure、Anthropic，或任何其他。业务代码完全不知道底层是哪个模型在工作，「换模型」这件事对业务层彻底隐形了。这意味着你可以在不触碰任何业务代码的情况下做 A/B 测试、成本优化、模型迭代。
负载均衡和故障转移：可靠性兜底
模型 API 并不是 100% 可靠，OpenAI 会偶发 503，某个地区的节点会超时，高峰期会被限流。单独对接时，业务层需要自己处理这些异常，而且往往处理不完整。
有了网关，你可以给同一个「模型名」配置多条路由规则，主路由指向 OpenAI，备用路由指向 Azure OpenAI 或 Anthropic。当主路由连续失败达到设定的阈值时，网关自动把后续请求切换到备用路由，整个过程业务层完全无感知，用户也不会感受到任何异常。这种「多活」策略在生产环境里是保障可用性的重要手段。
限流和配额：防止一个团队把额度用光
没有配额管理时很容易出现这样的情况：研发团队为了测试跑了一个批量脚本，一个小时内消耗了当天绝大部分 token 额度，导致产品团队的用户反馈系统整个下午都在报错。
有了网关的配额管理，可以给每个团队的虚拟 Key 设置独立的 token 日预算，比如研发团队每天 100 万 token、产品团队每天 50 万 token。一旦某个团队的虚拟 Key 超出配额，该 Key 的请求直接返回 429 错误，其他团队完全不受影响，API 额度不会被「误伤」。
成本追踪和可观测性：知道钱花在哪
网关集中记录了每次调用的 token 用量、响应时间、错误率等数据，这让你可以回答「哪个接口最烧钱」「研发团队和产品团队各用了多少」「GPT-4o 和 Claude Sonnet 的 P95 响应时间分别是多少」这类问题。
有了这些数据，成本优化才有依据，比如发现某个接口消耗了 40% 的 token，但实际上可以用便宜得多的模型替代。网关通常可以直接对接 Langfuse、Prometheus 等监控系统，不需要在业务代码里手动埋点，数据天然集中。
Prompt 安全和内容过滤：统一的安全防线
在网关层可以统一做输入输出的安全校验，包括检测 prompt 注入攻击（用户试图通过特殊指令劫持模型行为）、过滤个人隐私信息（比如身份证号、手机号不应该被发送到外部 API）、内容安全审核等。
集中在网关做的好处是：不需要每个业务服务各自实现，安全策略统一更新，任何一个接入点都自动获得保护。有一个服务漏了检测这种事情不会再发生。
语义缓存：省钱的同时降延迟
普通 HTTP 缓存是精确匹配，请求内容一字不差才能命中缓存。但 LLM 的问题往往有大量语义相近的变体：「北京今天热吗」「北京现在天气怎样」「今天北京气温多少」，三个问题本质上是同一个需求，但精确匹配全部 miss，每次都要打底层模型，就是三次完整的 LLM 调用费用。
语义缓存解决的正是这个问题。它的核心原理是：把用户问题先转换成一个向量（embedding，你可以把它理解成这句话的「数字指纹」。
意思相近的句子，指纹在向量空间里的位置也接近），然后在向量数据库里做相似度搜索，如果找到一个指纹很接近的历史问题（相似度超过设定阈值），就直接把那次的答案返回，完全跳过 LLM 调用。
完整流程是：收到新问题 -> 把问题向量化 -> 在向量数据库里做相似度搜索 -> 命中则直接返回历史答案，未命中则调 LLM 并把「问题向量 + 回答」存入缓存。整个过程对业务层透明，它就像一个智能的「语义感知」缓存层。
不过语义缓存要用好，有两个工程细节需要注意。首先是相似度阈值怎么设，这是最关键的调参点。阈值设太高（比如 0.99），基本上只有一模一样的问题才能命中，缓存形同虚设。阈值设太低（比如 0.7），就可能出现「北京今天热吗」命中了「上海今天热吗」的历史答案，答非所问就尴尬了。通常在 0.85 到 0.95 之间调试，具体要看你的场景和用户提问的多样性。
另一个要注意的是缓存有效期，不同类型的内容差别很大。天气、股价这类实时信息，缓存几分钟就够了，过期必须重新查；产品 FAQ、技术文档这类比较稳定的知识，缓存几天甚至更长都没问题。
语义缓存最适合的场景是高频重复的问答，比如客服机器人，用户总是问差不多的产品问题，命中率可以非常高，省下的调用费用很可观。但对于需要个性化或者强实时性的问答，就要在网关层识别出来，直接绕过缓存走 LLM。
回到开头对话踩的雷，最常见的误区就是把 LLM 网关等同于普通的负载均衡器或反向代理。面试回答这道题，首先要说清楚网关的定位：它是架在应用和模型 API 之间的中间层，集中拦截和处理所有出入流量，所以能在这个位置统一做很多事情。
核心功能方面，必须提到的几个点：多模型统一接口（业务代码只调网关，换模型只改配置）、API Key 集中管理（不散落在各服务里，降低泄漏风险）、按团队做 token 配额（防止某个团队把整个公司的额度用光）、成本追踪（知道哪个服务最烧钱）。
如果还能提到语义缓存就更好了，这是 LLM 网关区别于普通 API 网关的一个亮点功能：用向量相似度匹配语义相近的问题，命中缓存直接返回历史答案，跳过 LLM 调用，省钱还降延迟。
要避免的误区：不要只说负载均衡和统一接口，这两个普通 API 网关也能做。面试官想听的是你对 LLM 场景特有问题的理解，比如 token 配额管理、语义缓存、prompt 安全过滤这些只有 LLM 网关才需要的能力。如果用过具体框架（比如 LiteLLM、One API），能结合实际使用经验来说会更有说服力。