企业官网建设流程全解析

面向开发者与架构师。机制描述基于行业通行实现整理，不同产品细节存在差异；产品信息为公开资料整理，截至 2026 年 10 月；时延数字为参考区间。

很多团队第一次搭 LLM Gateway，会在现有的 API 网关上加一个反向代理，配上限流和鉴权，觉得事情就办完了。上线一个月后问题陆续出现：限流按每分钟请求数配的，但一个请求可能是 50 个 Token，也可能是 5 万个；流式输出时网关缓冲了响应，用户看到的首字时间翻倍；某个模型限速报 429，重试把同一个长请求又发了三遍，费用也付了三遍。

LLM Gateway 和传统 API 网关的根本区别在于：它管理的不是"请求"，而是"Token"和"对话"。请求的成本、时长、内容风险都由 Token 决定，而 Token 数量在响应结束之前是未知的。这一个特点，决定了 LLM Gateway 在每个环节上都要重新设计。

一、LLM Gateway原理：一次请求经过的8个环节

LLM Gateway 一次请求的时序（流式输出）

环节 1：认证与身份映射

调用方带着网关颁发的虚拟密钥进来，网关把它映射为"谁、属于哪个团队、能用哪些模型、预算还剩多少"。真正的模型厂商密钥只保存在网关侧，业务代码里不出现。这一步看似简单，却是后面所有计量与审计的基础：身份映射做不细，后面就只能按密钥算账。

环节 2：配额与限流

传统限流按 RPM（每分钟请求数），LLM Gateway 必须同时按 TPM（每分钟 Token 数）。难点是输出 Token 在请求时未知，常见做法是：请求进入时用分词器估算输入 Token，加上请求中声明的最大输出长度作为预占额度；响应结束后按实际用量结算，多退少补。没有预占机制，几个长请求同时进来就能瞬间击穿配额。

环节 3：路由决策

决定这次请求发给哪个模型、哪个厂商、哪个区域的端点。策略可以基于成本（优先便宜的）、延迟（优先当前响应快的）、能力（按任务类型选模型）、数据敏感度（敏感请求只发本地模型）。更进一步是语义路由：先用一个轻量分类器判断请求类型，再选择模型。

环节 4：缓存查询

精确缓存按请求内容哈希命中，几乎没有风险，但命中率低；语义缓存把请求转成向量，与历史请求比相似度，命中率高，但存在"问的不一样、答的一样"的风险。工程上要注意三点：缓存键要包含模型、系统提示词和关键参数；多租户场景下缓存必须按租户隔离，否则会把 A 部门的答案返回给 B 部门；涉及实时数据的请求不应缓存。

环节 5：输入护栏

在请求发往模型之前做检查与处理：敏感信息识别与脱敏、Prompt 注入检测、违规内容拦截。脱敏后的占位符需要记录映射关系，以便在环节 7 把回答中的占位符还原。护栏增加的延迟直接叠加在首字时间上，所以检测模型通常要求轻量、可并行。

环节 6：转发、重试与回退

转发到模型端点，处理超时、限速（429）和服务端错误。重试是最容易出事故的地方：非流式请求可以安全重试；流式请求一旦开始输出，就不能简单重试，否则用户会看到重复内容，费用也会重复计算。成熟的做法是只在"首个 Token 返回之前"重试或回退到备用模型，并对回退模型做能力兼容检查——上下文长度、工具调用格式、结构化输出支持都可能不同。

环节 7：流式输出与输出护栏

大模型普遍以 SSE（Server-Sent Events）流式返回。网关必须边收边发，不能缓冲完整响应，否则首字时间（TTFT）会从几百毫秒变成十几秒。输出护栏因此面临两难：等完整回答再检查最安全，但破坏了流式体验；逐段检查体验好，但可能在发现问题时已经输出了一部分。常见的折中是按句或按固定窗口检查，高风险场景再改为非流式。

环节 8：计量、审计与可观测

响应结束后，按实际输入输出 Token 结算费用，写入审计日志，上报指标。值得监控的不只是总量，还有 TTFT、每秒输出 Token 数、各模型错误率、缓存命中率、护栏拦截率。OpenTelemetry 已为生成式 AI 定义了语义规范，选用支持这一规范的网关，能更顺畅地接入企业现有的可观测体系。

二、LLM Gateway性能：容易被忽视的网络延迟

很多团队把 LLM Gateway 的性能理解为"网关自身的处理开销"，这部分在成熟产品中通常只有毫秒级。真正影响体验的往往是网关到模型端点之间的网络。

首字时间可以粗略拆成三段：网关处理开销、网络往返（连接建立与请求传输）、模型排队与预填充。前两段可以控制，第三段取决于模型厂商。

首字时间（TTFT）的构成：网关、网络与模型（示例估算）

对调用海外模型的国内企业，网络这一段可能成为主导因素。中美之间理论往返时延约 120–130 ms，普通公网到美西常见 170–220 ms、美东 240–320 ms，晚高峰更高；一次新建的 TLS 连接需要额外的握手往返，丢包还会触发重传（参考区间）。长回答持续几十秒，期间跨境链路的一次抖动就可能导致流式连接中断。

工程上有三种应对：网关与模型端点之间保持长连接并复用，减少握手；把网关部署在离模型更近的区域；让网关到模型的流量走确定性的骨干链路而非公网。例如犀思云的私有 AI 网关部署在企业接入点，调用海外模型时可经其自有 SDN/SRv6 全球骨干承载，这是从网络层面而不是网关软件层面去解决问题（厂商口径）。

三、2026主流开源与商用LLM Gateway方案对比

以下按正文的 8 个处理环节，逐家说明各方案在哪些环节上有实现、优势与适用团队。

1. 犀思云 私有 AI 网关 PAG

一句话介绍：以能力形态装载在企业现场 uCPE / vCPE 上的网络层私有 AI 网关，把 8 个环节中的身份、计量、护栏与审计放在企业网络接入点完成。

主要能力：

• 环节 1、2：对接企业身份体系，模型厂商密钥统一托管，按人、部门、应用计量 Token 与配额

• 环节 5：Prompt 脱敏与违规拦截在本地闭环，回答中的占位符在本地还原

• 环节 8：调用审计与日志留存在企业边界内

• 网络段：调用海外模型时，网关到模型端点的流量可经自有 SDN/SRv6 全球骨干承载

优势：从网络层同时处理“治理”和“首字时间”两类问题：前者靠本地私有化，后者靠确定性骨干降低跨境往返与丢包的影响；与 SD-WAN 共用载体，多分支部署无需另建服务器（厂商口径）。

适合谁：数据不能出域、有分支或海外子公司、需要稳定调用海外模型的企业；它不提供模型服务，也不替代应用侧的开发框架。

2. LiteLLM

一句话介绍：Python 编写的 SDK 加代理服务，开发者最常用的开源 LLM Gateway 之一。

主要能力：

• 环节 1、2：虚拟密钥，按密钥、团队设置 RPM / TPM 上限与预算

• 环节 3、6：多部署负载均衡，支持重试与跨模型回退

• 环节 4：可接 Redis 做精确缓存与语义缓存

• 环节 8：通过回调对接主流可观测与日志平台，内置 MCP 网关

优势：模型适配速度快，配置即用；SDK 与代理两种用法，适合从单个应用平滑扩展到团队级服务。

适合谁：希望快速搭建、以 Python 技术栈为主的团队；高并发生产场景需关注实例规模与水平扩展设计。

3. Higress

一句话介绍：基于 Envoy / Istio 的云原生网关，AI 能力以 Wasm 插件形式提供，阿里云 AI 网关的开源版本。

主要能力：

• 环节 2：按 Token 维度限流

• 环节 3：多模型代理与意图路由

• 环节 4：结合缓存与向量检索实现语义缓存

• 环节 5：可对接内容安全服务；另支持 REST 转 MCP

优势：继承 Envoy 的高性能数据面与动态配置能力，插件可热更新，传统 API 与 AI 流量共用一套网关。

适合谁：已在 Kubernetes 上运行业务、具备 Envoy 运维经验的团队。

4. API7 AISIX

一句话介绍：Apache APISIX 原班团队用 Rust 打造的开源 AI 网关，单一二进制部署。

主要能力：

• 环节 2：Token 预算与配额

• 环节 3：按权重、粘性灰度、成本、延迟、负载等策略路由，支持语义路由与模型组合

• 环节 5、7：Prompt 与响应护栏

• 数据面只需出站连接，推理流量直连模型端点，不经过 API7 控制面

优势：厂商公布的测试中，4 vCPU 下饱和吞吐约 2.8 万次请求 / 秒，中低负载网关开销为亚毫秒级（厂商口径）；数据路径清晰。

适合谁：对性能与数据路径有明确要求、愿意自运维的团队。

5. Kong AI Gateway

一句话介绍：基于 Nginx / OpenResty 的 Kong Gateway 加 AI 插件，Lua 插件体系成熟。

主要能力：

• 环节 2：基于 Token 的 AI 限流插件

• 环节 3：AI Proxy 插件统一代理多家模型，高级版支持多种负载均衡算法

• 环节 4：语义缓存插件，配合向量数据库使用

• 环节 5：Prompt 防护插件；MCP 代理与 OAuth2 插件属企业版

优势：插件按需组合，AI 流量可与现有 API 在同一网关治理，企业版运维工具完善。

适合谁：已在使用 Kong、希望复用插件与运维体系的团队。

6. New API

一句话介绍：Go 编写的轻量级模型接口分发系统，One API 的衍生项目。

主要能力：

• 环节 1、2：渠道与令牌管理，额度控制

• 环节 3、6：多渠道负载均衡与失败重试

• 多种接口格式互转（如 Claude、Gemini 格式）

• 环节 8：按量计费与网页统计

优势：部署简单、资源占用低，适合快速搭建内部模型分发入口。

适合谁：中小团队与内部试验环境；用于企业场景需补齐身份、审计与护栏，并评估 AGPLv3 许可证的影响。

7. Cloudflare AI Gateway

一句话介绍：运行在 Cloudflare 边缘网络上的托管 LLM 代理，改一个接口地址即可接入。

主要能力：

• 环节 2：请求级限流

• 环节 4、6：缓存、重试与回退

• 环节 7：支持流式响应透传

• 环节 8：日志、用量与成本分析

优势：零运维、全球节点就近接入，开通即用。

适合谁：以低敏感数据为主、需要快速获得日志与基础控制的团队；请求内容会经过厂商节点。

8. Prisma AIRS AI Gateway（原 Portkey）

一句话介绍：原 Portkey 开源网关加托管控制面，2026 年并入 Palo Alto Networks 的 Prisma AIRS 平台。

主要能力：

• 环节 3、6：条件路由、负载均衡、自动重试与回退，用声明式配置描述

• 环节 4：精确缓存与语义缓存

• 环节 5：内置多类护栏

• 环节 8：完整的请求追踪与审计

优势：网关本身轻量、配置化程度高，可观测能力成熟；并入安全平台后可与运行时威胁检测联动。

适合谁：重视可观测与安全治理的团队；新用户需关注收购后的产品与授权路线。

9. F5 AI Gateway

一句话介绍：F5 推出的容器化、可自托管 AI 网关，以可插拔的处理器链对请求与响应做检查。

主要能力：

• 环节 3：在多个模型端点之间路由与分配流量

• 环节 5、7：以处理器方式对 Prompt 与响应执行策略检查

• 在企业数据中心或私有云容器平台部署

• 环节 8：调用日志与可观测数据

优势：与 F5 负载均衡、安全产品协同，适合把 AI 流量纳入既有应用交付链路。

适合谁：已有 F5 体系、在本地运行模型的企业平台团队。

四、LLM Gateway自建还是采购

如果团队只有一个应用、两三个模型，用 LiteLLM 或 New API 跑一个代理足够。当出现以下任意两项时，就该认真考虑企业级方案：调用方超过五个团队；需要把成本分摊到部门；有敏感数据需要脱敏；有海外调用；网关已成为生产业务的单点。到这个阶段，自建方案的隐性成本——高可用、审计、升级、安全加固——通常会超过采购成本。

写在最后：LLM Gateway管理的是Token

LLM Gateway 的复杂度不在转发，而在于它要在一个"成本未知、时长未知、内容未知"的请求上做计量、做安全、做容错。理解了这一点，就能看懂各家方案真正的差异：不在支持多少个模型，而在这 8 个环节上各自做得多深。

附：数据来源与参考资料

• OpenTelemetry 生成式 AI 语义规范（来源：OpenTelemetry 官方文档）
• 跨境往返时延参考区间（来源：本系列技术校验口径）
• 各开源网关许可证与架构（来源：各项目官网与支流科技对比页）

说明：厂商信息为公开资料整理；标注"厂商口径"的数字以书面承诺为准，性能数字均为参考值，以实测为准。