想象你是一栋智能大楼的新住户。楼里住着好几位各有专长的顾问——有的精通中文写作，有的擅长英文翻译，有的对数学推理特别在行。你没有他们的私人电话，也不需要记住谁住哪层。你只需要走到一楼前台，说出需求，前台就会替你转接最合适的顾问，替你控制每次咨询的时长和费用，甚至如果你问的是刚有人问过的老问题，前台直接就能把答案递给你，连顾问都不用惊动。 这个前台，就是 LLM 应用架构中的 API 网关（API Gateway）。在大模型应用的世界里，你的“大楼”背后连接着多个大模型供应商——OpenAI、Claude、国产模型……它们协议不同、计费不同、有各自的脾气（限流、不稳定）。API 网关作为唯一入口，把“该找谁、花多少钱、能不能答、答不上怎么办”这些复杂决策全部承包下来，让业务方只面对一个简单前台。

岗位关联

学会设计 API 网关，是 AI 应用架构师从“能调模型”走向“能规模化、可控成本地调模型”的分水岭。它直接决定你的 LLM 应用在生产环境中能扛多少流量、花多少钱、稳不稳定。

目录
  1. 可视化演示
  2. LLM网关特殊需求
  3. 认证鉴权
  4. Token限流
  5. 模型路由
  6. 多模型管理
  7. 缓存策略
  8. 观测与成本控制
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

LLM网关特殊需求

大楼前台并不是所有大楼都一样的。普通写字楼的前台，只需要记通讯录、收发快递；可你这栋住着 AI 顾问的大楼，前台还要管预算、看顾问谁有空、替顾问挡掉无礼的客人。传统 API 网关和 LLM 网关的差别，正在于此。

传统 API 网关负责认证、限流、转发，它转发的每个请求是“一次性”的——请求发出，响应回来，交易结束。而 LLM 网关面对的请求，每一个都要调用昂贵的大模型 API，按 Token 计费，响应是流式的、耗时的、可能不稳定的。更麻烦的是，你背后可能同时接了 OpenAI、国产模型等多个供应商，它们协议细节各不相同。

所以 LLM 网关的特殊需求可以归纳为三点：统一流量入口（所有业务方只面对一个网关）、成本和时延敏感（每个请求都烧钱、都慢）、多供应商适配（屏蔽各家差异）。这让 LLM 网关从“消息员”升级为“带预算的调度员”。

回想前台的工作台：一张通讯录（路由）、一台计时计费机（限流）、一沓常见问题答案卡（缓存）、一本流水账（观测）。这四样东西，就是 LLM 网关的全部家当。下面我们逐一展开。

LLM网关职责=路由+限流+缓存+观测\text{LLM网关职责} = \text{路由} + \text{限流} + \text{缓存} + \text{观测}
网关不是简单的请求转发器，而是集路由、成本控制、可靠性保障于一体的架构组件。
  1. 路由（Routing）决定每个请求转发给哪个大模型供应商。
    Routing:request↦modeli(i∈{1,2,…,n})\text{Routing}: \text{request} \mapsto \text{model}_i (i \in \{1,2,\dots,n\})
  2. 限流（Rate Limiting）控制单位时间内的 Token 消耗量，防止预算失控。
    Limit:Token秒≤α\text{Limit}: \displaystyle \frac{\text{Token}}{\text{秒}} \le \alpha
  3. 缓存（Caching）对重复请求直接返回结果，省去重复调用费用。
    Cache:hit⇒skip 模型调用\text{Cache}: \text{hit} \Rightarrow \text{skip 模型调用}
  4. 观测（Observability）记录每一次调用的模型、Token、时延，形成账单。
    Log:request↦(cost,latency,model)\text{Log}: \text{request} \mapsto (\text{cost}, \text{latency}, \text{model})

认证鉴权

当访客走到前台，第一件要验的事是身份。前台不仅仅记下你的名字，还要查你是不是本楼住户、有没有预约、属于哪个公司（租户）。在 LLM 网关中，这就是认证鉴权：确认调用方是合法的业务系统，并识别出它属于哪个租户。

LLM 应用的认证分为两层。第一层是身份认证：调用方在请求头携带 API Key 或 JWT Token，网关校验密钥是否有效、是否过期。第二层是租户隔离：同一个网关背后服务多个业务线，每个租户有不同的配额、不同的可用模型列表、不同的账单。比如 A 业务线配额大、可以用最贵的模型；B 业务线是试用用户，只能用基础模型。

此外，LLM 网关还多了一个传统网关没有的检查——内容安全。大模型的输入输出可能包含敏感词、个人隐私，网关要在转发前和返回后做内容过滤。就像前台不仅要验证你的工牌，还要检查你递进来的纸条上有没有写违规的话。

前台验完身份，就会在访客名录上盖一个章。有了这个章，你才能进入后面的流程——但接下来，前台要告诉你：“每一位顾问每次咨询都是按字数收费的，我先看看你今天还能咨询多少次。”

校验链:API Key→验证租户→匹配配额检查→通过内容安全扫描\text{校验链}: \text{API Key} \xrightarrow{\text{验证}} \text{租户} \xrightarrow{\text{匹配}} \text{配额检查} \xrightarrow{\text{通过}} \text{内容安全扫描}
认证不是一锤子买卖，而是一条校验链：身份 → 租户 → 配额 → 内容，任何一环不过都直接拒绝。
  1. API Key 验证检查请求头中的密钥是否存在且未被吊销，用常量时间比较防止时序攻击。
    Key∈?有效密钥表\text{Key} \stackrel{?}{\in} \text{有效密钥表}
  2. 租户匹配根据 Key 找到所属租户，获取该租户的模型白名单与配额。
    Key↦Tenant↦(配额,模型白名单)\text{Key} \mapsto \text{Tenant} \mapsto (\text{配额}, \text{模型白名单})
  3. 配额检查判断本次调用后租户的累计用量是否超过上限。
    已用量+本次预估≤租户上限?\text{已用量} + \text{本次预估} \le \text{租户上限}?
  4. 内容安全扫描对输入输出做敏感词与隐私检测，违规则拦截。
    Content→检测pass / block\text{Content} \xrightarrow{\text{检测}} \text{pass / block}

Token限流

大模型的计费单位不是“次数”，而是 Token。Token 可以理解为模型眼里的一句话被切成的碎片：英文里大约 4 个字符算 1 个 Token，中文里大约 1 到 2 个汉字算 1 个 Token。前台发给顾问的每句话、收下的每句回答，都要按 Token 数刷卡付费。

传统 API 网关的限流是“每秒多少个请求”，但 LLM 网关的限流必须升级为“每分钟、每秒钟多少 Token”。为什么？因为一次请求可能消耗 100 Token，也可能消耗 10000 Token——如果只按次数限流，一个请求就能烧掉巨额预算，之前省下的次数额度毫无意义。就像温泉馆按用水量收费而不是按进馆次数收费。

具体令牌桶算法中：网关维护一个桶，桶容量是最大突发 Token 数（burst），每秒向桶中注入固定数量的 Token（rate）。每个请求到来时，根据本次请求的预估 Token 消耗量从桶中取出相应 Token；桶空了就拒绝请求或排队。这样既允许短时间突发，又限制长期平均速率。

前台打开计时计费机，很快算出一笔账：“你今天的中文 Token 额度还剩 5000，这个问题约要 800 Token，可以进。”于是你被放行。但问题来了——该把你转给哪位顾问呢？

Tokens请求≈∑i字符数i折算系数i,放行条件:桶内Token≥Tokens请求\text{Tokens}_{\text{请求}} \approx \sum_{i} \frac{\text{字符数}_i}{\text{折算系数}_i}, \quad \text{放行条件}: \text{桶内Token} \ge \text{Tokens}_{\text{请求}}
按 Token 限流是 LLM 网关区别于传统网关最核心的点。折算系数因语言而异：英文约 4 字符/Token，中文约 1.5 汉字/Token。
  1. Token 估算将文本按语言切分并折算为 Token 数，中英文折算系数不同。
    Tokens=Ncharsk,ken≈4, kzh≈1.5\text{Tokens} = \displaystyle \frac{N_{\text{chars}}}{k}, \quad k_{\text{en}} \approx 4,\ k_{\text{zh}} \approx 1.5
  2. 桶容量检查请求的 Token 消耗量必须小于等于桶内剩余 Token。
    Remain−Tokens请求≥0\text{Remain} - \text{Tokens}_{\text{请求}} \ge 0
  3. 扣减与补充通过后从桶中扣减 Token，同时以固定速率持续向桶中补充。
    Remain(t)=min⁡(Burst, Remain(t−1)+rate⋅Δt)\text{Remain}(t) = \min(\text{Burst},\ \text{Remain}(t-1) + \text{rate} \cdot \Delta t)
  4. 超额处理桶空了，返回 429 或进入等待队列，而非直接失败。

模型路由

楼里的顾问各有所长：张顾问（基础小模型）便宜但只擅长闲聊，李顾问（通用大模型）贵但全面，王顾问（推理模型）最贵但数学极强。前台要根据你问的问题、你的预算、各顾问当前的忙碌程度，决定把你转给谁。这就是模型路由。

路由策略大体分三种。第一种是按能力匹配：简单分类任务走小模型，复杂推理走大模型。第二种是按成本与延迟权衡：如果用户不着急，就排给便宜的模型；如果用户是 VIP 且要求高质量，就上最贵模型。第三种是动态负载均衡：某个模型接口超时或报错率上升，网关自动把它摘除，把流量切到健康的备用模型上。

实际落地的路由往往是一个打分模型：为每个候选模型计算一个分数 = 任务匹配度、价格、延迟、可用性的加权和，然后选最高分者。这个分数可以静态配置，也可以根据实时观测动态调整。

前台看着评分表，把一个中文闲聊问题转给了便宜的通用模型，把一个数学题转给了推理专家，把一个英文翻译转给了擅长英文的顾问。整个过程业务方无感知，他们只知道自己问了前台一个问题。

Score(m)=∑jwj×sj(m),m∗=arg⁡max⁡mScore(m)\text{Score}(m) = \sum_{j} w_j \times s_j(m), \quad m^* = \arg\max_{m} \text{Score}(m)
路由的本质是一个多目标优化：质量、成本、延迟、可用性很难同时最优，网关在它们之间取加权平衡。
  1. 特征打分每个评价维度（如能力分、成本分、延迟分）在 0~1 之间打分。
    sj∈[0,1],j∈{能力,成本,延迟}s_j \in [0, 1], \quad j \in \{\text{能力}, \text{成本}, \text{延迟}\}
  2. 加权求和权重 w_j 表示当前场景对各维度的偏好，如“省钱模式”调高成本权重。
    Score=wcap⋅scap+wcost⋅scost+wlat⋅slat\text{Score} = w_{\text{cap}} \cdot s_{\text{cap}} + w_{\text{cost}} \cdot s_{\text{cost}} + w_{\text{lat}} \cdot s_{\text{lat}}
  3. 取最大者选分数最高的模型作为本次转发的目标。
    m∗=arg⁡max⁡mScore(m)m^* = \arg\max_m \text{Score}(m)
  4. 故障摘除若模型连续 N 次超时，将其分数置零，冻结一定时间后重试。

多模型管理

前台凭什么敢在多个顾问之间自由调度？因为它和每个顾问之间都有一本标准的“沟通手册”——每位顾问的说话方式、口音、礼节要求都不一样，但前台把它们都记在脑子里，对外永远用同一套标准话术接待访客。这就是多模型管理的协议适配层。

多模型管理要解决三件事。第一，统一协议适配：OpenAI 的接口格式、Claude 的接口格式、国产模型的接口格式各不一样，网关把它们全部翻译成统一的内部格式，业务方只对接一套 API。第二，灰度与迁移切换：当你想从模型 A 切换到模型 B，不需要改业务代码，只需在网关配置中调整路由权重——先切 5% 流量观察效果，没问题再逐步放大。第三，多 Key 负载均衡：同一个模型供应商可能申请了多个 API Key（每个 Key 有速率限制），网关把流量分散到多个 Key 上，避免单个 Key 被限流。

这套机制让你可以随时更换供应商、谈判价格、避开某个供应商的故障，而业务方代码零改动。这就是网关作为“架构缓冲层”的价值——它把不稳定的外部依赖变成一堵可替换的墙。

前台把每天的工作流程记得滚瓜烂熟，但它还有一招更省力的——有些问题刚有人问过，直接把答案递给下一个人就好，何必再麻烦顾问呢？

统一接口:业务方→网关适配层→{OpenAI, Claude, 国产模型}\text{统一接口}: \text{业务方} \to \boxed{\text{网关适配层}} \to \{\text{OpenAI},\ \text{Claude},\ \text{国产模型}\}
多模型管理的核心价值是“可替换性”：通过一层适配，让底层模型供应商成为可插拔组件。
  1. 协议翻译网关将业务方标准请求翻译为各供应商特有格式。
    Standard→translateProvider Format\text{Standard} \xrightarrow{\text{translate}} \text{Provider Format}
  2. 流量灰度按权重将流量切分到新旧模型，如新模型 5%、旧模型 95%。
    流量比例:pnew=5%, pold=95%\text{流量比例}: p_{\text{new}} = 5\%, \ p_{\text{old}} = 95\%
  3. Key 池轮转将请求在多个 API Key 之间轮流分配。
    Key=KeyPool[i mod N]\text{Key} = \text{KeyPool}[i \bmod N]

缓存策略

在 LLM 应用中，大量用户会问相似的问题。尤其是“帮我总结一下这篇文章”“这段话是什么意思”这类 prompt，可能几百人问的是同一段文本。前台如果每次都跑去惊动顾问，钱包吃不消；于是它准备了一个大抽屉：缓存。

缓存分两种。一种是精确缓存：只有请求内容完全相同时才命中，实现简单，但命中率低；另一种是语义缓存：通过向量嵌入计算请求之间的相似度，语义相同但表述略有差异的请求也能命中，比如“你好，介绍一下你自己”和“嗨，自我介绍一下吧”算同一个问题。语义缓存的命中率更高，但需要额外的向量检索成本。

缓存的键（Key）设计很关键：同一用户的同一个问题才能复用，不同用户之间的上下文不同，不能共享缓存。通常 Key = 用户ID + 模型名 + prompt 哈希。而且缓存要设置 TTL（过期时间），防止模型更新后旧的过时答案继续生效。

前台翻看抽屉，发现这个问题三分钟前刚有人问过，答案一模一样。它把答案卡片直接递给你，顾问从头到尾都没被惊动，费用单上只有一次查询。这感觉，就像问了一个问题几乎没花钱。

命中率=Ncache hitN总请求,节省成本=命中率×平均单次调用成本\text{命中率} = \frac{N_{\text{cache hit}}}{N_{\text{总请求}}}, \quad \text{节省成本} = \text{命中率} \times \text{平均单次调用成本}
缓存策略是 LLM 网关成本控制的第二大利器。精确缓存简单但命中率低，语义缓存命中率高但需权衡向量检索开销。
  1. 命中率定义命中缓存的请求数占总请求数的比例。
    hit rate=NhitNtotal\text{hit rate} = \displaystyle \frac{N_{\text{hit}}}{N_{\text{total}}}
  2. 成本节省命中缓存的请求不再调用大模型，平均节省单次调用成本。
    cost saved=hit rate×Cavg\text{cost saved} = \text{hit rate} \times C_{\text{avg}}
  3. 缓存键拼接用用户ID、模型名、文本哈希组成缓存键，保证隔离。
    key=H(user∥model∥text)\text{key} = H(\text{user} \| \text{model} \| \text{text})
  4. TTL 过期缓存条目存活超过 TTL 后自动失效。
    expire:Δt>TTL\text{expire}: \Delta t > \text{TTL}

观测与成本控制

大楼有本总账。前台每天做了什么、转给了谁、每次转接顾问花了多少“字数费”、哪位访客超标了，全记在这本账上。没有这本账，你就不知道楼里的预算到底花哪去了——这正是可观测性对 LLM 网关的意义。

观测分三个层次。第一层是调用量与时延监控：每秒请求数、平均首字延迟、最大延迟、错误率。第二层是Token 核算：每次调用的输入 Token、输出 Token、模型单价，汇总成每个租户、每个业务线的费用账单。第三层是预算告警与优化：当日费用达到预算的 80% 时告警，100% 时自动切换低成本模型或限流。

成本控制的手段是多样化的：通过限流控制总量、通过路由把流量导向便宜模型、通过缓存减少重复调用、通过灰度切走昂贵供应商。观测为这些控制手段提供决策依据——没有数据，就无法优化。

前台每晚合上账本。今天共接待 10 万次咨询，其中 30% 靠缓存直接答了，10% 被限流弹回，60% 真正转给了顾问。账单在预算内，唯一一次接近超支是在下午，前台果断把廉价模型权重拉高，松了一口气。这就是一个称职前台的一天。

单次调用成本=输入Token×Pin+输出Token×Pout,月度成本=∑单次成本\text{单次调用成本} = \text{输入Token} \times P_{\text{in}} + \text{输出Token} \times P_{\text{out}},\quad \text{月度成本} = \sum \text{单次成本}
可观测性不是事后复盘，而是成本控制的闭环反馈：监控 → 核算 → 告警 → 调优。
  1. 单次成本计算输入和输出 Token 分别按不同单价计费，输出通常更贵。
    Ci=Nin⋅Pin+Nout⋅PoutC_i = N_{\text{in}} \cdot P_{\text{in}} + N_{\text{out}} \cdot P_{\text{out}}
  2. 聚合月账单所有调用累加即得月度总成本。
    Cmonth=∑iCiC_{\text{month}} = \sum_i C_i
  3. 告警阈值当累计成本超过预算比例 β 时触发告警。
    C累计C预算≥β\frac{C_{\text{累计}}}{C_{\text{预算}}} \ge \beta
  4. 优化动作告警后切换路配置、降低缓存 TTL、或启用更多缓存。

AI 应用场景

场景一：多租户 SaaS 企业的模型网关

阶段：应用架构设计与部署

解决的问题：一家 SaaS 公司有 50 个企业客户使用其 AI 功能，客户 A 调用量巨大，客户 B 偶尔试用。如果没有网关统一管理，所有客户共用同一个 API Key，成本分不清、配额控不住，一个客户的恶意流量可能拖垮所有人的 AI 服务。传统方案只按 IP 限流，完全无法区分租户。

具体案例：某数据公司为其 AI 助手接入 API 网关。网关为每个企业客户颁发独立 API Key，并配置 Token 配额：付费高的客户每分钟 100k Token，试用客户每分钟 5k Token。网关后台统计每个客户的 Token 消耗并生成账单，当某客户连续 3 次触发限流时，自动通过 webhook 通知客户经理跟进。上线后超额费用下降了 70%。

场景二：电商客服的模型路由降本

阶段：成本优化

解决的问题：电商客服的 AI 回复质量要求分级——简单退款问题用便宜小模型即可，复杂售后纠纷必须大模型。若全部使用最贵模型，成本爆炸；若全部使用便宜模型，复杂问题体验崩溃。网关的加权路由模型可以按任务复杂度动态选择模型。

具体案例：某电商平台在网关中配置路由策略：先由小模型识别问题类型，若为高危纠纷（退款争议、投诉升级）则路由到 GPT-4 级别模型，其余问题走轻量模型。同时网关开启语义缓存，80% 的常见问题直接命中缓存。两个月后，AI 客服的 token 成本下降 60%，用户满意度反而提升 5%。

Python 演示

python95 行
import timeimport hashlib  class TokenBucket:    """Token 令牌桶，按 Token 数而非请求数限流"""     def __init__(self, capacity, rate):        self.capacity = capacity          # 桶容量（最大突发 Token）        self.tokens = capacity            # 当前桶内 Token        self.rate = rate                  # 每秒补充速率        self.last = time.time()     def consume(self, tokens):        """尝试消耗 tokens 个额度，成功返回 True，失败返回 False"""        now = time.time()        self.tokens = min(self.capacity, self.tokens +                          (now - self.last) * self.rate)        self.last = now        if self.tokens >= tokens:            self.tokens -= tokens            return True        return False  class Router:    """按任务复杂度路由到不同配置的模型"""     def __init__(self):        self.models = {            'cheap':  {'cost_per_1k': 0.001, 'score': 0.4},            'medium': {'cost_per_1k': 0.01,  'score': 0.7},            'premium':{'cost_per_1k': 0.05, 'score': 1.0},        }     def route(self, complexity):        """复杂度分数越高，路由到越贵的模型"""        if complexity < 0.4:            return 'cheap'        if complexity < 0.8:            return 'medium'        return 'premium'  class APIGateway:    """统一的 LLM API 网关"""     def __init__(self):        self.bucket = TokenBucket(capacity=5000, rate=200)        self.cache = {}     @staticmethod    def estimate_tokens(text):        """粗略估算：中文约 1.5 字/Token，英文约 4 字符/Token"""        zh_chars = sum(1 for c in text if '\u4e00' <= c <= '\u9fff')        en_chars = len(text) - zh_chars        return int(zh_chars / 1.5 + en_chars / 4) + 10     def handle(self, user_id, prompt, complexity):        """处理一次请求：缓存 -> 限流 -> 路由"""        cache_key = hashlib.md5((user_id + prompt).encode()).hexdigest()        if cache_key in self.cache:            return ('cache_hit', self.cache[cache_key], 0)         tokens = self.estimate_tokens(prompt)        if not self.bucket.consume(tokens):            return ('rate_limited', None, tokens)         model = Router().route(complexity)        cost = tokens / 1000 * self.models[model]['cost_per_1k']        answer = f"[{model} 生成的回答]"        self.cache[cache_key] = answer        return ('model_call', answer, cost)     def __getattr__(self, name):        """兼容访问模型的成本信息"""        if name == 'models':            return self.bucket.__dict__        raise AttributeError(name)     @property    def model_prices(self):        return {'cheap': 0.001, 'medium': 0.01, 'premium': 0.05}  if __name__ == '__main__':    gw = APIGateway()    for i, (uid, q, comp) in enumerate([        ('alice', '你好，在吗？', 0.1),        ('alice', '你好，在吗？', 0.1),        ('bob', '帮我推导一下这个数学证明', 0.95),    ]):        status, answer, cost = gw.handle(uid, q, comp)        print(f'请求{i+1}: {status}, 费用=${cost:.4f}')    print(f'总费用: ${gw.model_prices["cheap"] + gw.model_prices["premium"]:.4f}（仅示意）')
目的：用 60 行代码展示 LLM 网关注册、限流、路由的核心逻辑，帮助理解真实网关产品的骨架。
  1. class TokenBucket令牌桶限流器，consume() 方法模拟一次 Token 扣减；桶容量控制突发、速率控制长期均值
  2. self.tokens = min(self.capacity, ...)补充 Token 但不超过桶容量，防止长时间积累后的一次性大量消耗
  3. def route(self, complexity)按复杂度分数路由：分数低走便宜模型，分数高走昂贵模型
  4. gw.handle(user_id, prompt, complexity)网关主流程：先查缓存，再限流，最后路由，三者顺序缺一不可
  5. cache_key用用户ID加 prompt 做哈希，避免不同用户的请求相互串用缓存
  6. estimate_tokens中英文分别按不同系数折算的 Token 估算函数，和真实网关的行为一致

常见误区

误区“API 网关不就是把请求转发到后端吗？用 Nginx 反代一下就够了，何必搞这么复杂？”

正解反代只解决“转发到哪”的问题，而 LLM 网关要解决“转给谁最省钱”“能不能转”“转之前能不能缓存”等一连串决策问题。它像前台不仅要递电话，还要管预算、查身份、选顾问。反代是前台的一只手，网关是整个前台。

为何常见：传统后端服务没有 Token 计费的概念，转发就是转发；工程师容易把旧经验直接套到 LLM 场景，忽略 Token 限流和路由这些新职责。

误区“我们每秒限 100 个请求，不就行了？大模型调用也是接口调用，没啥不同。”

正解一次大模型调用可能消耗 100 Token，也可能消耗 10000 Token，两者成本相差百倍。按次数限流挡不住“单请求大量生成文本”的烧钱行为。必须按 Token 限流——就像温泉馆必须按用水量而不是进馆次数收费，否则一个大客户就能耗尽全月预算。

为何常见：因为“每秒请求数（QPS）”是所有后端工程师最熟悉的限流指标，而 Token 是 LLM 特有的计量单位，需要额外封装才能换算。

误区“缓存嘛，把用户请求当 key，把模型返回当 value 存进 Redis 就好了。”

正解LLM 缓存远不止 key-value 那么机械。首先，缓存 key 必须考虑用户隔离——不同用户问同一个问题，答案可能因为个性化上下文而不同；其次，语义缓存需要向量检索判断“意思相近”的问题；还要设置 TTL 防止模型更新后旧答案残留。缓存设计不当会导致隐私泄露、答案过期等问题。

为何常见：传统 Web 缓存（页面缓存、对象缓存）深入人心，但 LLM 缓存的“语义相似性”和“上下文隔离”是独特难点，容易想当然。

误区“请求本来就要到大模型，要好几秒，再接一个网关多一跳，延迟肯定雪上加霜。”

正解网关只做轻量决策——哈希查缓存、令牌桶扣减、配置查表，都是微秒到毫秒级操作，与大模型动辄数秒的推理时延相比可忽略。更聪明的是，网关如果命中缓存，响应是毫秒级，比直接调用模型反而快了十倍以上。网关不是拖慢，而是加速。

为何常见：人们容易把网关想象成“每请求都完整走一遍复杂路由逻辑”，实际路由是预计算好的配置表，运行时开销极小。

面试题

Q1. 与传统 API 网关相比，LLM 网关最核心的差异是？

单选题 · easy

  • A.支持更高的并发请求量
  • B.按 Token 而非仅按次数限流← 正确答案
  • C.必须部署在 Kubernetes 中
  • D.需要更强大的防火墙能力

答案：B。LLM 服务按 Token 计费，且单次请求消耗 Token 数差异巨大，因此网关必须按 Token 限流来控制成本。选项 B 正确。高并发、Kubernetes、防火墙都不是 LLM 网关区别于传统网关的本质特征。

Q2. LLM 网关中“语义缓存”比“精确缓存”的优点是？

单选题 · easy

  • A.实现起来更简单
  • B.不需要存储原始请求
  • C.能命中意思相近但表述不同的请求← 正确答案
  • D.不需要设置过期时间

答案：C。语义缓存通过向量相似度判断请求是否“同一问题”，表述不同但语义相同的请求也能命中，提高了命中率。它实现更复杂，不是更简单；同样需要存储和 TTL，所以 A、B、D 均错误。

Q3. 在 Token 令牌桶算法中，capacity 参数控制的是？

单选题 · mid

  • A.桶的物理大小
  • B.允许的最大突发 Token 数← 正确答案
  • C.每秒消耗的 Token 数
  • D.缓存的最大条目数

答案：B。capacity 即桶容量，表示允许的最大突发 Token 数——桶不满时可以一次性消耗这么多额度。rate 控制的才是每秒补充速率，所以 C 错误；它与缓存毫无关系，D 错误。

Q4. LLM 网关的模型路由策略通常考虑哪些因素？

多选题 · mid

  • A.模型能力与任务匹配度← 正确答案
  • B.单次调用的 Token 费用← 正确答案
  • C.模型的响应延迟表现← 正确答案
  • D.用户的浏览器类型

答案：ABC。路由是一个加权打分过程，能力匹配度、成本、延迟都是核心评价维度。而用户浏览器类型与模型选择无关，是无关干扰项。

Q5. 网关发现某模型服务连续超时，应优先采用哪种策略？

单选题 · mid

  • A.立即将该模型分数置零并摘除← 正确答案
  • B.把请求无限重试直到成功
  • C.直接返回 500 错误给用户
  • D.将所有流量永久切到最贵模型

答案：A。故障自动摘除是网关的可靠性机制：连续超时的模型应从候选路由中摘除，一段时间后再探测恢复。无限重试会加剧故障，直接 500 伤害用户体验，永久切最贵模型则成本失控。

Q6. 关于 LLM 网关中的缓存键设计方案，合理的是？

多选题 · mid

  • A.只使用 prompt 文本作为缓存键
  • B.使用用户ID + 模型名 + prompt 哈希← 正确答案
  • C.为缓存条目设置合理 TTL← 正确答案
  • D.所有租户共用同一份缓存通道

答案：BC。缓存键必须包含用户 ID 隔离不同用户上下文，模型名防止不同模型答案混用，故 B 正确；TTL 保证模型更新后答案不过期，C 正确。只用 prompt 会串用户数据，不同租户共用缓存会泄露信息。

Q7. 某租户每分钟配额为 60k Token，当前分钟已消耗 58k，收到一个新请求预估消耗 3k Token，网关应？

单选题 · hard

  • A.放行并继续等待
  • B.拒绝并建议稍后重试← 正确答案
  • C.放行但记录违规
  • D.自动充值后再放行

答案：B。58k + 3k = 61k > 60k，超过配额上限，网关应拒绝该请求（返回 429），建议用户稍后重试或降级。放行会突破配额约束，放行并记录违规则是自欺欺人，网关没有自动充值的职责。

Q8. LLM 网关的“协议适配层”带来的价值包括？

多选题 · hard

  • A.业务方只需对接一种统一格式← 正确答案
  • B.切换模型供应商时无需改业务代码← 正确答案
  • C.可以在不同模型间做 A/B 灰度验证← 正确答案
  • D.使所有模型的输出完全一致

答案：ABC。适配层屏蔽供应商差异，业务方只需对接标准格式，切换供应商只改网关配置，所以 A、B 正确；灰度切换流量也是适配层支持的能力，C 正确。但 D 错误——不同模型输出天然不同，适配层不改变输出内容。

Q9. 预算已用 85%，网关自动将情感分析流量路由到更便宜的小模型，这属于哪种手段？

单选题 · hard

  • A.Token 限流降级
  • B.基于预算的路由降级← 正确答案
  • C.缓存策略调整
  • D.负载均衡扩展

答案：B。根据预算告警动态调整路由权重，把流量导向便宜模型，是“基于预算的路由降级”。它不改限流额度，也不依赖增删缓存，只是路由策略的动态调整，所以选 B。

Q10. LLM 网关中按 Token 限流的原因有哪些？

多选题 · easy

  • A.模型调用按 Token 计费← 正确答案
  • B.单次调用 Token 消耗差异巨大← 正确答案
  • C.低请求数也可能产生高额成本← 正确答案
  • D.Token 限流比请求次限流更好实现

答案：ABC。模型按 Token 计费、单次消耗差异巨大（100~10000 Token）、低请求数也可能烧大钱，这三者共同决定了必须按 Token 限流。而它比请求次数限流更难实现（需要估算 Token），D 错误。