企业官网建设流程全解析

最早让我意识到 LLM 网关不是可选项，是团队把四个业务系统接到同一个大模型服务那天。每套系统都要配置密钥，都要写自己的超时和重试逻辑，都要维护一套几乎一样的工具函数。某个模型接入方调整了计费策略，我们不得不逐个服务改配置，改完还要各自验证。

那之后我理解了：直连模型在小规模时很舒服，一旦参与方变多，真正缺的不是某次调用是否成功，而是一个可以统一执行策略的位置。LLM 网关就是这样一个位置。但把网关放进生产环境两个月后，我又意识到另一件事：真正难的从来不是把网关搭起来，而是围绕它做架构权衡。路由、鉴权、限流、可观测、成本核算，每一个看起来都简单，真正落到生产里，全是取舍。

1. 先想清楚：LLM 网关到底在解决什么问题

1.1 从直连到网关：问题从“能用”变成了“可控”

很多人第一次接触 LLM 网关，是因为要切换模型供应商。直连模型时，切换往往意味着改动代码、调整请求格式、重新发布服务；如果接入了多个业务系统，这个动作会被放大很多倍。网关出现后，路由规则集中在一处，切换模型似乎只需要改配置。

但这只是最表层的收益。直连接入的真正问题是：密钥管理、超时策略、重试逻辑、成本归属、访问审计这些横切关注点，散落在每个业务服务里。每个服务的实现方式还不一样，有的把 key 写在环境变量里，有的存在配置中心，有的直接写死在代码里做联调。等到线上出问题，你很难说清某个请求到底用的是哪个 key、哪个模型、哪个版本。

LLM 网关之所以值得讨论，不是因为它能把请求“转发”得更快，而是因为它提供了一个集中控制点，让这些横切关注点有了统一落地的地方。这也是我把网关理解成“策略执行面”的原因。

1.2 网关不是代理，而是策略执行面

在网关里，你可以看到这样的变化：

这张表并不是说直连模式一无是处。如果你只有一个应用、一个模型、几个人维护，直连反而比引入网关简单得多。但一旦出现“多应用、多模型、多供应商、多团队”这些条件，网关的集中控制能力就会从锦上添花变成必需品。

这里的关键区分在于：网关不是在请求路径上加一个“中间人”，而是在访问模型之前加一道策略边界。身份认证、密钥保护、路由判断、配额校验、成本计量，这些能力如果放到每个业务服务里，维护成本会随着接入方数量线性增长；放到网关里，增长的是网关本身的复杂度，这是可控的。

需要说明的是，网关也不能解决所有问题。它解决的是“请求怎么被安全、可控、可观测地送到模型服务”，而不是“应用怎么写出更好的 prompt”。如果业务方不理解自己需要什么模型、什么参数，再强的网关也只是让错误发生得更规范。

2. 生产化之前，先做六个架构取舍

2.1 同步转发还是异步缓冲：请求路径上的第一选择

网关最常见的形态是同步代理：客户端请求到网关，网关转发给模型服务，拿到完整响应后再返回客户端。这个模式语义简单，和直连模型几乎一样，适合大多数实时对话和生成场景。

但有些团队会在网关层加入异步缓冲，比如把生成任务丢进队列，让请求先返回“任务已受理”，再由后台任务去调用模型。这样做的好处是可以吸收峰值流量，缺点是改变了请求语义：客户端不再等一个结果，而是需要轮询任务状态、等待回调或主动查询结果。这个变化会影响上游系统的设计，不是简单改一个网关配置就能完成的。

我的建议是：在网关的第一版里，先老老实实做同步转发。异步化可以作为后续优化手段，但不要一开始就叠加。原因是异步化会引入任务存储、状态管理、结果暂存和失败恢复，这些都是新的故障点。如果原始需求只是“让用户在前端看到生成结果”，同步转发加适当的超时控制，比异步队列简单得多。

2.2 无状态还是有状态：会话上下文不该由网关存储

LLM 应用最常见的状态是会话上下文。用户不断追加消息，应用需要把历史消息拼进请求里。有人会问：能不能让网关记住每个会话的历史，下次自动补上？

这种设计在 demo 阶段很有吸引力，但在生产环境会带来很大负担。网关一旦存储会话，就要处理并发写、过期清理、多实例共享、权限隔离等问题。它实际上变成了一个“会话数据库”，而不是网关。而会话历史的更新频率很高，如果所有应用都通过网关维护上下文，网关的存储和同步成本会快速增长。

我更建议让业务服务或专门的状态层去维护会话上下文，网关只负责转发当前这个请求，以及记录这次调用发生了多少 token、对应哪个应用、结果是否成功。你可以让网关记录“做过什么”，但不要让网关记住“用户聊到了哪里”。职责分离之后，网关才能保持无状态，水平扩展也更容易。

2.3 路由策略放在哪一层：不是所有请求都由网关决定模型

网关层做路由并不总是对的。如果一个系统只有一个应用和一个模型，路由放在代码里最简单；如果业务方自己就需要根据用户属性选择不同模型和 prompt 模板，这部分判断放在应用层反而更灵活。

网关层的路由价值在于：当多个应用共享同一个模型接入策略时，路由规则可以被集中管理。这样模型供应商变化、主模型故障、灰度切换都不需要业务服务发布版本。换句话说，路由策略的对象应该是“模型资源”，而不是“业务语义”。

一个常见误用是：把业务上的模型选择逻辑（比如“这个用户应该用强推理模型”）写死在网关规则里。一旦业务判断变复杂，网关配置会迅速膨胀，最后变成一座没人敢改的改造山。业务逻辑应留在应用层，网关层只做“这个应用允许调用哪个模型、失败后走哪个备用模型”这类资源级策略。

2.4 限流与配额：按请求数限流是不够的

LLM 网关的限流不能只按每分钟请求数来设计。不同模型、不同请求的耗时和 token 消耗差异很大，如果只限制请求数，一个业务方可以用大量短请求打满模型上下文，另一个业务方的长文本请求反而被误伤。

实际落地时，通常会组合使用几类配额：按应用的 QPS 限制、按用户维度的频控、按模型维度的全局并发限制，以及按预算维度的 token 用量限制。限流的作用不只是防止击穿，更重要的是保证多个团队共享模型容量时，某一个应用不会饿死其他应用。

第二个容易忽略的点是：限流指标和计费指标经常不一致。网关日志里的 token 数，和模型服务账单里的 token 数，因为重试、缓存、系统提示词、tokenizer 版本等原因可能对不上。所以配额要想清楚：是按网关观测到的 token 限流，还是按账单口径限流。这个问题最好在设计初期就明确，否则后期校准成本很高。

2.5 可观测性：日志、追踪、token 计量

网关接入后的第一个明显变化是日志量暴增。每次调用都要记录输入、输出、模型名、耗时、错误码、token 数，如果按全量日志保存，一周后存储成本就会让你重新做取舍。

一个相对合理的分层是：

• 指标层：QPS、错误率、P95/P99 延迟、token 消耗速率，用监控系统做聚合和告警。
• 追踪层：给每次调用生成 trace id，贯穿业务服务、网关和模型服务，便于排查链路问题。
• 日志层：记录请求元信息和异常明细，敏感内容做脱敏或采样保存，不把全部输入输出都留成明文。

这里还要考虑 token 计量。为了让成本按团队、按项目分摊，网关最好在请求进入时就带上应用标识、项目标识和调用方标识，并定期把 token 用量汇总到成本报表。否则月底对账时，你只能看到一张总账单，却说不清是哪条业务线花的钱。

2.6 配置管理：从“能改”到“能安全地改”

网关的配置内容通常包括上游模型地址、密钥引用、路由规则、限流阈值和超时参数。第一版可以写成静态配置文件，但生产环境会很快遇到一个问题：改配置需要重启网关，重启期间可能有请求中断。

动态配置中心是更常见的选择。但动态化也带来新的要求：配置变更要有版本记录、灰度策略和快速回滚能力。否则一次误改路由规则，可能让全部业务流量走到错误的模型供应商。对于密钥，不要直接把明文写进配置文件或代码仓库，而是用密钥管理服务或环境变量注入。网关既然把密钥集中起来了，就必须比业务服务更认真地对待密钥的存储和轮换。

提醒：不管用静态配置还是动态下发，都要为配置项增加“前置校验”。一个常见的低级事故是：路由规则里写了一个不存在的模型名，配置下发成功，线上所有调用都开始报错。这种问题可以在配置发布前通过模拟请求或语法校验拦截掉。

3. 从单条链路到生产网关：最容易踩的四个坑

3.1 超时和重试：重试不当会放大故障

大模型接口的一个典型特点是延迟波动大。正常情况下可能 1 秒返回，模型负载高时可能 20 秒甚至更久。应用侧为了稳定，常常习惯性地加大重试次数。如果网关不加总控，模型服务一抖动，所有应用同时重试，流量会成倍压到模型服务上，最终把一个小故障放大成整体不可用。

这里需要区分几种避免风险的机制：超时控制保证单次请求不会无限占用连接；重试策略解决临时网络错误；熔断机制在连续失败时主动切走流量。真正生产化的网关不能只配置 timeout 和 retry，还要配置最大重试次数、重试退避时间和熔断阈值。更重要的是，重试要考虑请求是否具备幂等性。如果上游已经写了消息，业务上重试又发了一次，结果可能是重复生成。

3.2 流式响应：网关会拖慢首字时间

现在很多生成场景都使用流式输出。客户端希望看到文字一点点出现，而不是等几十秒拿到完整结果。网关直接透传这种流式响应看起来不难，但真正实现时会有不少细节。

例如，网关如果先等待模型返回完整响应再转发给客户端，首字延迟会明显变高，流式体验就没了；如果网关逐块转发，又要处理客户端断开连接、上游异常中断、部分内容已发送等情况。更麻烦的是，某些网关此时无法准确统计 token 数或错误信息。实际项目里，很多“接入网关后变慢”的问题，不是模型变慢，而是网关对流的缓冲策略不匹配。

验证流式转发时，建议把“客户端看到第一个 token 的时间”作为一个核心指标。如果这个值明显高于直连模型，先检查网关是不是在等完整响应。

3.3 密钥和权限：集中的地方就是攻击目标

网关把原本分散的密钥集中管理后，安全风险并没有消失，而是集中到了网关这个点。如果网关本身权限过大、审计缺失、不受控，后果往往比密钥分散时更严重。

生产化至少要做到几点：网关服务只通过密钥管理服务读取敏感信息，应用侧不直接持有模型供应商 key；网关管理端的访问要结合内部身份认证和权限审批；所有密钥读取、配置变更、路由修改都要留审计日志。不要把“应用不用管 key 了”等同于“安全了”。那只是把安全责任从很多个点转移到少数几个点，这几个点反而需要投入更多保护。

3.4 成本核算：token 统计和账单对不上是常态

几乎所有团队在第一次看到模型账单时，都会对比网关里统计的 token 数和账单里的 token 数，然后发现对不上。差异来源很多：重试请求可能被重复计费；系统提示词可能在网关统计时未计算；流式接口的 token 统计口径不同；还有部分模型服务会计算缓存命中或候选 token。想精确到一两个 token 很难。

更务实的做法是，把 token 统计当作一个“近似测量”而不是“精确计费”。关键不是抹平每一分钱，而是能看清趋势：哪个应用在涨、哪个模型最贵、哪个时间段用量异常。差异只要在一个可接受的区间内（比如 5% 到 10%），就可以接受。如果差异很大，优先排查重试、缓存和模型版本三个方向。

当网关接入后出现问题，先别急着改参数。按这个顺序判断：先看客户端是否真的收到了模型返回；如果模型返回正常，问题在网关转发或流处理；如果模型本身超时，先看上游模型服务负载；如果只有部分应用报错，看路由和白名单；如果全部报错，优先检查配置和密钥。这样能少走很多弯路。

4. 落地路径：从最小可用网关到工程化

4.1 第一版：先把一次转发跑通

建议从最简单的路由开始：一个应用，一个上游模型，一个 API key。目标是验证请求能走通，日志能记录，token 能统计。此时不要设计复杂路由，也不要预留太多扩展抽象，先做最小闭环。

示例配置可以是这样（这里只是示意结构，不同网关实现会有差异）：

gateway: upstreams: - name: primary-llm base_url: https://llm.internal.example.com/v1 api_key_env: LLM_PRIMARY_KEY routes: - name: chat path: /v1/chat/completions upstream: primary-llm timeout_seconds: 60

在真实项目里，你可能不需要自己写 YAML，而是通过控制台或 API 创建路由。但核心流程是一样的：先确认上游配置、路由前缀、鉴权方式和超时参数。跑通之后，用一条测试请求验证三个东西：返回内容是否正确、网关日志是否有 trace id、token 用量是否被记录。这一步过了，再继续加功能。

4.2 第二版：上线前补上四件套

网关从 demo 走向生产，至少要先补齐四样东西。

• 审计日志：能回答“谁、在什么时间、调用了哪个模型、消耗了多少 token”。
• 限流配额：在应用维度设置上限，避免某一个接入方把共享容量打满。
• 告警：对错误率、P95 延迟、配额耗尽、上游模型不可用设置告警。
• 回滚：路由配置和网关版本要支持回滚，最坏情况下还能快速切回直连模式。

这四样东西单独看都不难，但缺一个都会在线上给你上一课。比如没有告警时，某个模型供应商故障可能持续半小时才被发现；没有回滚时，一次错误的配置变更可能需要紧急重新发布。很多团队第一周都花在“补全这些基础设施”上，这很正常，也是网关生产化过程中最值得投入的部分。

4.3 第三版：多团队自助接入和灰度发布

当接入方从一两个变成十几个，网关团队不可能继续帮每个应用手动配路由。这时候要考虑自助接入面和模型资源目录：让业务团队自己申请模型权限、创建应用标识、查看自己的调用量和成本。

灰度发布也很重要。模型供应商或模型版本切换时，不要一次性全量切过去，而是按应用、按请求比例逐步放量。具体做法可以是：先用一个内部应用的流量做冒烟，再灰度到指定应用，最后观察 24 小时后全量上。这个渐进过程比一次性切换安全得多。

不过第三版的复杂度明显更高，不是每个团队都需要。如果接入方很少、业务模式稳定，停留在第二版完全够用。生产化不是把网关功能堆得越多越好，而是让它在当前组织规模和业务节奏下足够可靠。

5. 什么样的场景其实不需要自建网关

5.1 单一模型、单一团队：直连仍然是最优解

如果只是一个小团队在做一个应用，模型供应商也只有一个，直连模型通常更简单。没有网关的情况下，密钥由应用自己管理，延迟少一跳，故障面也小。这时候引入网关，相当于把整个系统的可用性又依赖在一个新组件上，还要额外维护路由、日志和权限。除非是为了提前建立规范，否则收益不明显。

5.2 已经有一套 API 网关：先扩展现有体系

很多公司内部已经有成熟的 API 网关，负责统一入口、鉴权、限流和可观测。LLM 调用本质上也是 API 调用，所以在这套网关之上叠加模型路由和 token 计量，比单独再维护一套 LLM 网关更省成本。需要注意的只是：新增的 LLM 能力要和现有网关的权限模型、日志体系保持一致，避免出现两套标准。

5.3 想快速验证模型场景：托管能力可能更合适

如果你所在平台已经提供了模型服务的统一入口、密钥管理和用量统计，第一阶段可以直接用这些托管能力。自建网关更适合在需要跨供应商统一策略、或需要按内部项目做复杂成本分摊时再介入。这里没有哪个方案绝对正确，关键是不要为了“搞一套自己的网关”而重复造轮子。

5.4 判断是否自建的最小信号

可以把下面几个问题当作检查清单：

• 是否超过一个业务系统接入大模型？
• 是否需要同时管理多个模型供应商或模型版本？
• 成本是否需要按团队、项目或用户维度分摊？
• 是否有审计与合规要求，需要完整记录每次调用？
• 是否有人愿意长期运维网关，并处理配置变更、版本升级和告警？

如果这五个信号你至少中了三个，自建网关才值得认真考虑。如果只中一个，我会建议先用更轻的方案。

6. 把网关放进系统后，我重新理解了生产化

6.1 LLM 网关和传统 API 网关不是一回事

虽然都是“网关”，但 LLM 网关面对的是高延迟、高成本、流式和部分结果不确定的模型调用。传统 API 网关的很多默认策略，比如重试、超时、缓存，放在 LLM 场景下反而会帮倒忙。传统接口失败通常可以安全重试，模型调用却可能产生费用、重复写入或不可恢复的上下文；传统接口对缓存很友好，模型生成结果却大多不可缓存，而且不同用户的请求几乎没有可以复用的公共部分。

这意味着引入 LLM 网关时，不能直接把现成网关的经验原样搬过来。需要重新审视每一个策略的代价：重试要控制最大次数，超时不能设太短也不能过长，缓存仅在极有限的场景（比如固定系统提示词、embedding 向量查询）才有价值。运维 LLM 网关的人，不仅要懂网络和网关，还要理解模型调用本身的概率性和高成本特征。

6.2 抽象会带来新的运维负担

网关是对模型访问的一种抽象，但抽象不会消除复杂度，只是把复杂度搬到了一个更集中的位置。使用网关之后，你仍然要面对超时、重试、限流、密钥、日志、成本这些问题，只不过从“每个应用各算一份”变成了“网关统一处理”。如果网关团队投入不足，它可能成为新的瓶颈点。

所以每次在架构评审里听到“我们加一个网关就都解决了”，我都会提醒一句：网关能解决一部分管理问题，但它本身也变成了一台需要被管理的机器。它需要发布、升级、监控、权限控制、配置管理和故障轮值。这些工作如果没人负责，网关会在上线三个月后开始有人抱怨。

6.3 生产化的核心是让变化可控

我第一次理解这一点，是通过一次线上故障。当时模型供应商发布了新版本，我们想灰度切换，却发现路由配置没有版本回滚能力，只能整体切换。幸运的是问题在低峰期发生，回切很快。但那次之后我意识到，生产化的核心不是追求高级功能，而是让变化可控。

LLM 网关也一样。它的长期价值不在于把某个请求转发得多快，而在于让以下几件事变得可控：模型供应商切换、不同团队的成本分摊、应用权限收敛、线上故障时的快速降级。这些能力不像一个新功能那样显眼，但一旦业务规模上来，它们会决定你能不能安全地迭代。

如果你的团队没有一个人愿意长期维护网关，那它迟早会从“生产基础设施”变成“新的技术债来源”。这也是我判断该不该自建网关时最看重的一条。

6.4 下一步：先跑通，再治理，最后工程化

如果你正打算引入 LLM 网关，我的建议是不要从复杂的架构开始。先把一条路由跑通，看清楚延迟、日志和成本；然后把限流、审计、告警和回滚补上；最后再考虑多团队自助接入和灰度发布。这个过程可以被简化成三个词：先跑通，再治理，最后工程化。

真正值得投入精力的地方，不是你选择了哪个网关产品，而是你想清楚了这个网关要承担多大职责、边界在哪里、由谁维护、出问题怎么回退。架构选择最终服务于业务组织方式，而组织方式决定了网关做多厚。