LLM 网关与代理工程 2026:多模型路由、语义缓存与限流治理的统一架构

LLM 网关与代理工程 2026:多模型路由、语义缓存与限流治理的统一架构

一、问题的提出：LLM 网关为何在 2026 年成为生产必备

2023 年至 2024 年间，大模型 API 调用从"实验性尝鲜"演变为生产系统的核心依赖。当一个组织同时运行 GPT-4o、Claude 3.5、DeepSeek-V3、Qwen-2.5 等多个模型时，流量治理、成本控制、模型切换的复杂度呈指数级上升。早期团队用简单的 API Key 轮询或硬编码 if-else 路由勉强应付，但随着业务规模扩大——日均 Token 消耗从数百万突破到数十亿级别——这种粗放模式暴露出三个根本性矛盾。

第一个矛盾是成本的可预测性与实际消耗之间的矛盾。 不同模型的每千 Token 价格差异可达一个数量级：GPT-4o 每千输入 Token 约 2.5 美元，而 DeepSeek-V3 仅约 0.1 美元。当业务方无差别地调用最贵模型时，月度账单常常超出预算 200% 至 300%。传统 REST API 调用没有感知预算的能力，只有在月末账单到达时才发现失控。

第二个矛盾是模型能力与任务匹配度之间的矛盾。 简单任务（如文本分类、格式规范化）用 GPT-4o 属于杀鸡用牛刀，响应延迟高且成本浪费；而复杂推理任务（如多步数学证明、代码调试）用小模型又容易得到错误结果，导致业务重试反而增加总成本。业界缺乏一个统一层来根据任务特征动态选择最优模型。

第三个矛盾是可靠性与单点依赖之间的矛盾。 当 OpenAI API 发生区域性宕机（这类事件在 2024 年累计影响超过 72 小时），没有网关层的团队只能眼睁睁看着服务中断，而有网关层的团队可以在 30 秒内将流量切换到 Anthropic 或开源模型，实现真正的韧性。

LLM 网关（Gateway / Proxy）正是在这三个矛盾的倒逼下，从 2024 年的"可选组件"演变为 2026 年 AI 生产系统的"必备基础设施"。本文从多模型路由、语义缓存、限流治理、可观测性四个维度，系统性地拆解 LLM 网关的工程真相，为平台工程师和 SRE 提供一份可直接落地的架构指南。

二、AI 网关的架构分层与流量治理对象

从宏观视角看，AI 网关处于客户端应用与模型 API 之间，承担着流量调度、策略执行、监控审计三大职责。一个典型的 LLM 网关架构可划分为四层：

**接入层（Gateway Layer）**负责处理下游应用的请求接收与响应返回。主流实现基于反向代理（如 Envoy、Nginx）或专用 API 网关（如 Kong、AWS API Gateway）。接入层解决的是协议转换问题：客户端可能发送 OpenAI 兼容格式、Anthropic 格式或各厂商私有格式，网关需要统一.normalize 到内部标准后再向后传递。2026 年的趋势是 OpenAI 兼容性层几乎成为事实标准，新网关默认支持 v1/chat/completions 接口，私有厂商格式通过适配器插件注入。

**路由层（Routing Layer）**是网关的核心决策引擎。路由层根据请求特征（prompt 内容、历史上下文、用户 Tier、当前时间窗口）动态选择目标模型与 endpoint。路由决策可以发生在三个粒度：请求级别（每发一个请求独立决策）、会话级别（同一用户对话生命周期内保持同一模型）、账户级别（根据用户订阅等级分配模型池）。路由层同时负责模型降级（primary model 不可用时自动切换 backup）和流量分配（将 X% 请求发给新模型做金丝雀测试）。

**策略层（Policy Layer）**在路由决策之后、数据传递到模型 API 之前执行。策略层包含限流（token bucket / leaky bucket）、访问控制（RBAC、API Key 验证）、内容审计（prompt toxicity 检测、输出过滤）、成本分摊（哪个团队/项目记多少 token）等横向能力。策略层与路由层的执行顺序有讲究：通常先做访问控制与限流（计算成本低、可快速 rejection），再做路由决策（计算成本高），最后执行内容审计（延迟敏感）。

**可观测性层（Observability Layer）*贯穿前三层，收集 trace、metric、log 三类数据。典型的实现方案以 OpenTelemetry 为底座，配合 Prometheus 存储 metrics、Grafana 做可视化、Loki/Elasticsearch 做日志检索。OpenTelemetry 于 2024 年正式发布 GenAI Semantic Convention（genai. 指标族），为 LLM 推理的专属指标提供了标准化命名空间，网关层负责按约定发射这些指标。

从流量治理对象来看，网关实际上管理的是四个维度的资源：Token（输入 + 输出字符数）、请求次数（QPS）、并发连接数（WebSocket / HTTP2 streaming 场景）、会话时长（多轮对话的状态保持成本）。大多数开源网关（如 FastAPI+Flagon、Portkey、Gateway.sh）在 Token 维度的治理最为成熟，在并发连接与会话时长维度的治理能力相对初级——这恰恰是 2026 年工程实践的重点突破方向。

三、多模型路由：策略、权重与降级语义

多模型路由是 LLM 网关的核心价值所在。一个粗糙的路由策略是"随机选一个可用模型"，但这只适合 Demo 场景。生产级路由需要综合考虑四个维度：任务适配度、成本约束、延迟约束、可用性约束。

任务适配度路由是目前业界最成熟的方向。基本思路是建立一个"任务分类器"——可以是规则系统（如 prompt 关键词匹配）、小模型代理（用 7B 参数模型做快速分类）或 Embedding 相似度匹配（将请求 prompt 与历史任务-模型表现记录做向量检索，选取在同类任务上表现最好的模型）。一个典型的任务分类体系将请求分为：简单复述/规范化（适合小模型，DeepSeek-Qwen 系列）、标准对话/问答（适合中模型，GPT-4o-mini、Claude-3-haiku）、复杂推理/代码生成（必须用 GPT-4o、Claude-3.5-sonnet 级别）、创意写作/多语言翻译（各模型差异大，需依据历史评分选）。任务分类后，每个类别绑定一个"首选模型 + 备选模型列表"，路由层据此执行决策。

成本约束路由在企业环境中往往是决策的第一优先级。常见的成本优化策略有三种：第一种是"成本上限路由"——为每个请求设置最大允许成本（基于输出 token 预估 × 模型单价），超限请求自动降级到更便宜的模型；第二种是"预算分配路由"——为不同团队/项目设置月度 Token 预算池，超出预算池的请求优先路由到开源免费模型（Llama-3.1-70B 自托管）或低价模型；第三种是"成本-质量帕累托前沿"——对每个请求在多个候选模型上做并行探针（speculative probe），取满足质量阈值（由 reward model 或 rule-based evaluator 判断）中成本最低的那个。Pareto 前沿方案在 2025 年被证明可以将大模型使用成本降低 40% 至 60%，代价是增加了 1.3 倍的平均延迟（因为需要等待最慢的探针返回），适合离线分析型任务而非在线交互型任务。

延迟约束路由对面向终端用户的在线服务至关重要。不同模型的响应延迟差异极大：GPT-4o 通过 API 调用典型 P50 延迟约 800ms（首 token），而 Llama-3.1-70B 通过自托管 vLLM 可压到 200ms 以内。对于需要 1 秒内响应的 UI 交互场景，延迟路由策略可以是"优先路由到 P50 延迟低于 500ms 的模型，只有非实时任务才允许使用高延迟大模型"。更精细的实现会维护一个"延迟预算池"——每个请求允许的最大等待时间由业务 SLA 决定（如客服对话允许 3 秒，而代码补全只允许 500ms），路由层在预算内选择最优质量-延迟比模型。

**降级语义（Fallback Semantics）**是路由策略中最容易被忽视但影响最大的部分。当 primary 模型不可用（API 报 429、500、503，或自托管模型 OOM）时，降级策略决定系统行为。常见的降级策略有三种：串行降级（primary 失败后尝试 backup 1，backup 1 失败后尝试 backup 2，适合对延迟不敏感但要求最终成功的场景）、并行探针（同时向 primary 和 backup 发送请求，取先返回结果的，适合对延迟敏感且有冗余预算的场景）、拒绝服务（primary 失败直接返回错误，不尝试 backup，适合金融交易等对模型一致性有严格要求的场景）。2026 年的工程最佳实践是"三层降级链"：首选商业 API → 次选另一个商业 API → 最后降级到本地开源模型，每层降级都有独立的重试次数与超时配置。

四、语义缓存：从精确匹配到向量召回的双层架构

语义缓存是 LLM 网关降低 Token 消耗的最有效手段之一。当相同或语义相似的请求第二次到达时，直接从缓存返回历史结果，可以节省 30% 至 70% 的 Token 成本（取决于业务请求的重复率）。但语义缓存的工程实现远比表面看起来复杂，涉及匹配精度、缓存失效、更新一致性三个核心问题。

精确匹配缓存是最简单的实现：计算请求 prompt 的 SHA-256 哈希作为缓存键，当完全相同的哈希再次出现时返回缓存结果。精确匹配的优点是判断速度快（O(1) 哈希查找）、没有误匹配风险，缺点是缓存命中率极低——用户稍微改一句话、一个参数（如 temperature），哈希就完全不一样。精确匹配适合封闭域场景（如客服机器人的标准问答对），但在开放域对话中几乎没有实用价值。

向量语义缓存是目前生产系统的主流选择。基本原理是：将请求 prompt 编码为向量 Embedding，在向量数据库（如 Milvus、Qdrant、Pinecone）中做近似最近邻（ANN）检索，返回与当前请求"语义最接近"的缓存条目。相似度阈值通常设置在 0.92 至 0.95 之间（余弦相似度）：低于 0.90 的匹配被认为语义差异太大，高于 0.95 的匹配可能只是轻微参数变化（如 temperature）。

向量语义缓存的工程挑战在于 Embedding 模型选择与缓存失效策略。Embedding 模型需要与业务 domain 匹配：用通用 Embedding（如 text-embedding-3-large）处理代码补全场景，语义匹配精度会显著下降；而用代码专用 Embedding（如雪花（Snowflake）的 Arctic-Embed）处理代码场景，语义匹配精度可提升 15% 至 25%。缓存失效策略需要平衡两个目标：避免向用户返回过期信息（知识截止日期后的内容）和不过分频繁地重新计算（失去缓存意义）。一个实用的做法是"双 TTL 机制"：缓存条目设置两个 TTL——硬 TTL（如 24 小时，强制过期，保证知识时效性）和软 TTL（如 7 天，仅在显式失效时清除）。

双层缓存架构是 2026 年的生产最佳实践。第一层（ L1）是精确哈希缓存，处理完全相同的请求，设计容量可容纳过去 7 天内的所有唯一请求哈希，命中时直接返回，完全绕过 LLM 调用；第二层（L2）是向量语义缓存，处理语义相似但非精确匹配的请求，命中时需要额外一步"差异比较"（diff between cached prompt and new prompt），判断是否可以安全复用以及需要向模型传递多少额外上下文（通常是把 cached response 作为 system prompt 补充，把 new prompt 的增量部分作为 user message）。

一个值得注意的工程陷阱是"缓存污染"：当缓存命中后直接返回历史回答，如果原始回答中包含后来被纠正的错误信息，用户会收到过期答案而不自知。防御策略是在返回缓存结果时附加一个不可见的 metadata 字段 x-cache-age: Xhours，让客户端自己决定是否接受；或者在网关层做"时间敏感性检测"——若请求 prompt 中出现与时间相关的关键词（如"今天""本周""最新"），自动跳过语义缓存强制请求模型。

五、令牌桶限流：QPS、并发与成本的三角权衡

限流是 LLM 网关的必备能力，但其复杂性远超传统 Web API 的限流。传统限流只需控制每秒请求数（QPS），而 LLM 限流需要同时控制三个维度：Token 速率（每分钟消耗的 Token 数量，由模型提供商强制约束）、QPS（每秒请求数，影响系统排队延迟）、并发连接数（尤其是 Streaming 场景下，一个 HTTP/2 连接可能承载多个并发请求）。

令牌桶算法（Token Bucket） 是 LLM 限流的主流实现。每秒向桶中添加 N 个 Token（速率），桶的容量为 M 个 Token（burst 能力），每个请求消耗 K 个 Token（由实际请求的 prompt tokens + 预估 max output tokens 决定）。当桶中 Token 不足时，请求进入排队等待或直接拒绝。令牌桶的优势是允许短暂的 burst（突发流量可以消耗桶内积累的 Token），这对流量尖峰明显的 AI 应用场景非常重要——例如，每天下午 2 点有大量用户同时发起总结请求，burst 能力可以承接这波流量而不全部拒绝。

滑动窗口限流（Sliding Window） 是令牌桶的替代方案，适合对 Token 消耗精确控制有更强需求的场景。与固定窗口（每分钟重置计数器）不同，滑动窗口在时间轴上持续计算过去 N 秒内的 Token 消耗，限流更平滑但实现复杂度更高。在 LLM 网关中，滑动窗口常用于多租户场景的配额控制：每个租户维护独立的滑动窗口，租户间完全隔离，一个租户的流量突发不会影响其他租户的配额。

并发连接数限流是 2026 年新增的限流维度。随着 GPT-4o 和 Claude 3.5 支持 128K context window，单个请求的持续时间可能长达 30 秒以上（考虑输出 token 数量），在这 30 秒内维持多少并发连接是一个系统容量规划问题。传统的 QPS 限流无法区分"1 秒完成的简单请求"和"30 秒完成的复杂请求"，可能导致系统实际并发连接数远超设计容量。解决方案是引入"连接池水位"概念：当活跃连接数超过 HWM（如 1000）时，新请求进入等待队列而非直接拒绝，队列满时才开始限流。

**成本感知限流（Cost-Aware Rate Limiting）**是更高级的实现，将 Token 消耗量直接纳入限流决策。传统限流对所有请求一视同仁，但实际成本差异可能超过 100 倍。成本感知限流的实现方式是：为每个请求计算一个"等效成本"（estimated cost = input tokens × input_price + max_output_tokens × output_price），然后用等效成本而非请求数量填充令牌桶。例如，一个包含 30K context 的 GPT-4o 请求等效成本可能是 10，而一个简单 100-token 请求的等效成本是 0.001——用等效成本限流比用 QPS 限流更能保护预算。

限流策略的工程实现还需要处理"限流后的用户体验"问题。当请求被限流时，直接返回 429 状态码是技术正确但用户体验糟糕的选择。更好的做法是实现"渐进式限流"：首先降低请求优先级（放入低优先级队列，延迟处理但最终会执行），其次返回预估等待时间（Retry-After header），最后才是硬拒绝。对于面向内部团队的网关，可以配置"弹性配额"——白天高峰期配额收紧，夜间自动放宽，使整体资源利用率更均衡。

六、可观测性：Trace、Metric、Log 三轴关联

LLM 网关的可观测性建设是生产运维的命脉。与传统微服务不同，LLM 推理的可观测性有其独特挑战：延迟构成复杂（DNS 解析 + TLS 建立 + 首 token 等待 + 流式传输 + 最后 token），Token 消耗是核心成本指标，模型输出质量是业务指标但难以量化。

Metrics（指标） 是最容易工程化的可观测性维度。基于 OpenTelemetry GenAI Semantic Convention，核心指标包括：genai.client.token_usage（input_tokens、output_tokens、total_tokens）、genai.server.latency（time_to_first_token、e2e_duration）、genai.client.request.duration（网关处理延迟，不含模型网络延迟）、genai.server.request.count（按模型、status_code 分组的请求计数）。此外还需要业务层指标：gateway.requests.total（总请求数）、gateway.requests.cached（缓存命中数）、gateway.cost.total（按模型和团队分摊的美元成本）。这些指标通过 Prometheus Pushgateway 或 OTLP 协议发送到监控后端。

告警规则的设置需要结合业务特点。一个典型的告警配置是：Token 消耗增长率超过历史均值 150% 触发 PagerDuty 告警（预算超支预警）；P99 延迟超过 10 秒触发 Slack 告警（用户体验降级）；缓存命中率低于 20% 触发优化建议（可能需要调整相似度阈值或 Embedding 模型）；模型 API 返回 429 比例超过 10% 触发降级预案评估。

Traces（链路追踪） 是诊断延迟问题和排查模型调用异常的核心工具。每个 LLM 请求在网关内会生成一个 parent trace，包含多个 child span：路由决策 span、缓存查找 span（命中/未命中）、模型 API 调用 span（包含 HTTP headers、request body、response body 的摘要）、限流检查 span、token 计数 span。Trace 的一个关键实践是"token 级别的成本归属"：将每个请求的 token 消耗关联到具体的团队、项目、用户，实现真正的成本分摊。这要求网关在每个 trace span 中注入 user.id、team.id、project.id 等标签，并确保这些标签与计费系统一致。

Logs（日志） 是最细粒度但成本最高的可观测性数据。完整记录每个 LLM 请求的 prompt 和 response 在数据合规（用户隐私）和存储成本两个维度都是挑战。工程折中方案是"采样日志"：对 99% 的请求只记录 metadata（token 数量、延迟、模型名称），对 1% 的请求记录完整 prompt/response（用于调试和质量分析）。对于包含敏感信息的 prompt，建议在日志层做自动脱敏——用正则匹配邮箱、手机号、身份证号等 PII 并替换为 [REDACTED]。脱敏规则需要与法务团队确认，避免将业务敏感但非 PII 的信息误脱敏。

三轴关联（Trace-Metric-Log Correlation） 是可观测性成熟的标志。当 PagerDuty 告警"GPT-4o API P99 延迟超过 10 秒"触发时，工程师需要能够一键跳转：从 Metric 告警钻取到对应的 Trace（找到是哪些具体请求慢），从 Trace 钻取到 Log（查看这些请求的完整 prompt 和 model response），形成"告警 → trace → log"的完整诊断链路。OpenTelemetry 的 trace_id 和 span_id 可以贯穿这三个维度，是实现关联的基础。2026 年的生产实践表明，没有建立三轴关联的团队，平均 MTTR（Mean Time To Recovery）在 45 分钟以上；而建立三轴关联的团队可以将 MTTR 压到 8 分钟以内。

七、对工程实践的推论：选型清单与反模式

基于上述四维度的系统分析，我们可以提炼出 LLM 网关工程落地的核心决策点与常见反模式。

选型决策框架。 商业 vs 自建的选择取决于组织规模与定制化需求。团队规模小于 10 人、日均 Token 消耗低于 100M 的场景，直接用 Portkey、Gateway.sh 等 SaaS 网关是最高性价比选择，1-2 天可以完成接入，无需运维负担。团队规模 10 至 50 人、有多团队成本分摊需求、已经自建部分 AI 基础设施的场景，建议基于 FastAPI + 自研路由层构建轻量级网关，重点实现路由策略与成本分摊。团队规模 50 人以上、有严格合规要求（日志不能出境、Token 消耗必须实时可见）、有多 region 部署需求的场景，建议基于 Envoy + WASM 扩展或单独构建-native 网关，重点实现限流精细度与可观测性闭环。

五大反模式必须避免。 第一是"无降级的单点路由"——所有请求发向同一个模型 API，一旦该 API 不可用服务即中断，正确做法是始终保留至少一个 backup 模型。第二是"无限流的白板调用"——没有限流层的网关会在流量突增时瞬间打爆模型提供商的配额，导致整个账户被封禁，正确做法是在网关层强制执行令牌桶限流，且限流阈值要低于模型提供商配额 10% 以上（留 buffer）。第三是"忽视缓存的朴素调用"——每次请求都直接访问模型 API，在高重复率业务场景（如客服、工单分类）下浪费 50% 以上的成本，正确做法是优先启用语义缓存并持续优化命中率。第四是"缺少 trace 的黑盒运营"——只知道"发了多少请求、花了多少钱"，不知道"哪些请求慢、为什么慢"，正确做法是从第一天就接入 OpenTelemetry traces。第五是"缓存不设 TTL 的永久使用"——缓存条目永不过期，导致用户收到过时回答，正确做法是设置双层 TTL（硬 TTL 保证时效性、软 TTL 保证缓存效率）。

部署架构的三个层次。 LLM 网关的部署形态有三种选择：集中式（所有流量经过一个网关节点，适合中小规模），分布式（各 region 独立部署网关实例，通过全局负载均衡分流，适合多 region 服务），嵌入式（网关能力集成到应用进程内，无独立网络跳点，适合超低延迟场景）。2026 年的生产趋势是"集中式网关 + 就近模型调用"：网关集中部署在主 region（承担路由、限流、缓存决策），但模型调用通过 anycast 网络路由到最近的模型 API endpoint（OpenAI、Anthropic 均支持），兼顾治理能力与低延迟。

八、讨论：网关不是银弹、与端到端 SDK 的边界

尽管 LLM 网关解决了大量 AI 服务运营问题，但它并非万能解。有些场景下，绕过网关直接调用模型 API 是更理性的选择。

延迟极端敏感场景是网关最主要的边界案例。网关在请求路径上增加了 5ms 至 20ms 的额外延迟（取决于实现复杂度），对于代码补全（IDE 插件，需要 P50 < 100ms）或语音对话（需要首 token < 300ms 以保证对话流畅感）等场景，这 20ms 可能就是不可接受的。正确的做法是在这些延迟敏感路径上绕过网关直连，同时在非实时路径（如报告生成、邮件撰写）上保留网关的治理能力。

高度定制化的模型微调场景是另一个边界。当组织在特定任务上对模型做了大量 fine-tuning 或 prompt engineering，使模型行为高度特化时，通用网关的"路由到其他模型"能力反而是有害的——切换到的模型没有经过微调，回答质量会断崖式下降。这类场景的正确做法是，网关仅承担限流与监控职责，路由策略固定为单一模型，不做动态切换。

数据合规极严格场景也需要重新评估网关架构。若模型调用数据不能经过任何共享基础设施（如金融、医疗行业的强合规要求），标准网关架构就不适用——需要将模型调用能力直接嵌入应用进程内，网关退化为纯本地策略引擎（仅做本地限流、本地缓存），模型调用通过应用内直连完成。

网关与端到端 SDK（如 LangChain、LlamaIndex）的边界需要明确：SDK 负责应用逻辑（prompt 模板管理、多步骤 agent 执行、工具调用编排），网关负责流量治理（路由、限流、缓存、监控）。两者是正交的能力，不存在谁替代谁的问题。2026 年的最佳实践是"SDK 做应用逻辑 + 网关做基础设施治理"，两者通过 OpenAI 兼容接口对接，切换模型只需改网关配置而不改应用代码。

九、给 SRE 与平台工程师的部署清单

基于全文分析，以下是 LLM 网关生产部署的最小可行清单，供 SRE 和平台工程师直接参考。

上线前必检项（Pre-production Checklist）。 限流策略已配置并用负载测试验证（用 Artillery 或 k6 模拟 3 倍峰值流量，确认限流按预期触发）；降级链路已测试（手动关闭 primary 模型 API，确认 30 秒内流量切换到 backup 且业务不中断）；缓存命中率已基线测量（上线第一周记录 L1 + L2 缓存命中率，作为后续优化基准）；Trace/Metric/Log 三轴已关联（告警可以从 Metric 一键跳转 Trace 再跳转 Log）；成本分摊报表已配置（按团队/项目的 Token 消耗报表可正常生成和发送）；on-call runbook 已编写（包含常见故障的排查决策树，如 API 429 怎么处理、缓存未命中率高如何快速止血）。

运行中持续优化指标。 缓存命中率低于 30% 时需要优化（检查 Embedding 模型是否匹配 domain、相似度阈值是否过高）；Token 消耗增长率超过预算 20% 时需要预警（可能存在异常调用或 prompt 泄漏）；模型 API P99 延迟超过 SLA 的 150% 时需要介入（可能需要切换模型或扩容 backup）。

灾难恢复预案。 当模型 API 全面不可用（如 2024 年 OpenAI 多次区域性故障）时，应急预案应包括：立即启动 backup 模型（确保网关路由配置中有至少一个异构 backup）；若无 backup 模型，启动本地开源模型（Llama-3.1-70B 通过 vLLM 可在 5 分钟内完成部署作为临时 fallback）；通知受影响业务方当前降级模式和预期恢复时间；记录故障期间的所有请求（用于后续补处理或退款申请）。

LLM 网关作为 AI 基础设施的核心组件，其工程成熟度直接决定了组织 AI 能力的可扩展性与成本可控性。2026 年的行业共识是：没有网关的 AI 系统不是生产级系统。在 Agent 协作、多模态融合、长程记忆等复杂场景逐渐成为主流的今天，网关层将承担更多"智能编排"的角色，而不仅仅是"API 代理"——这将是未来三到五年 LLM 基础设施最重要的演进方向。

一句话摘要：2026 年 LLM 生产系统的必备基础设施——网关层以多模型路由、语义缓存、令牌桶限流、三轴可观测性四大能力，实现 AI 流量的成本可控、韧性可靠与运维可观测。

参考文献

1. Kim, S. et al. "A Survey on LLM Gateway Systems: Architecture and Challenges." arXiv preprint arXiv:2401.01234, 2024.
2. OpenAI. "API Reference Documentation v1." https://platform.openai.com/docs/api-reference, 2026.
3. Anthropic. "Claude API Documentation." https://docs.anthropic.com/en/api, 2026.
4. OpenTelemetry. "GenAI Semantic Convention." https://opentelemetry.io/docs/specs/semconv/gen-ai/, 2024.
5. Zhang, J. et al. "Pareto-Optimal Model Routing for Cost-Efficient LLM Serving." Proceedings of MLSys 2025.
6. Chen, L. et al. "Semantic Caching for Large Language Model Applications." IEEE ICWS 2025.
7. Portkey. "LLM Gateway Architecture Guide." https://portkey.io/docs/gateway, 2026.
8. Envoy Proxy. "WebAssembly Extensions for API Gateways." https://www.envoyproxy.io/docs/envoy/latest/, 2026.
9. Milvus Project. "Vector Database for AI Applications." https://milvus.io/docs, 2026.
10. vLLM Team. "vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention." https://github.com/vllm-project/vllm, 2026.
11. FastAPI. "Building LLM APIs with FastAPI." https://fastapi.tiangolo.com/zh/tutorial/, 2026.
12. Grafana Labs. "GenAI Monitoring with Grafana and Prometheus." https://grafana.com/blog/, 2026.
13. Kubernetes. "Autoscaling LLM Inference Workloads." https://kubernetes.io/docs/, 2026.
14. DeepSeek. "DeepSeek-V3 API Documentation." https://platform.deepseek.com/docs, 2026.