企业官网建设流程全解析

有一段时间，我所在的项目组把大模型推理服务从原来的业务集群里拆出来独立部署，紧接着就遇到了一连串之前没想过的麻烦。客户端直连模型服务，地址散落得到处都是；某个版本升级想灰度，后端一换地址前端就要跟着改；高峰期并发一上来，模型服务直接被部分慢请求占满，快请求也进不来；月底对账的时候，各个业务方报的Token消耗数还和模型侧日志对不上。折腾了快两个月，我们终于意识到，大模型推理场景需要的不再是传统的微服务网关，而是一个懂模型语义、懂流式协议、懂成本计量的AI网关。

这篇文章就是基于那段实践做的复盘，从定位、职责、架构演进三个层面展开，适合正在建设AI推理基础设施的后端团队、平台工程师，以及准备把大模型能力开放给内部业务的同学参考。我会尽量讲清楚每个设计背后的“为什么”，也会把踩过的坑和排查思路一并放出来。

1. 场景定位：大模型推理为什么需要独立的AI网关

1.1 传统API网关在大模型场景下的天然短板

很多团队一开始的想法是“我们已经有API网关/K8s Ingress了，直接用不就行了”。实践下来会发现，传统网关和LLM推理流量的匹配度很低，不是配置问题，而是模型假设不同。

传统API网关是为短连接、请求-响应式微服务设计的。客户端发一个HTTP请求，网关转发，后端几百毫秒内返回，连接即释放。网关只需要看HTTP头，不需要理解报文内容。负载均衡也是按“请求数”来做的，一个请求被转发到某个实例之后，这个请求占用的后端资源在毫秒级就释放了。

但大模型推理是完全不同的流量模型。一次生成请求可能持续几秒甚至几十秒，响应是SSE流式返回，整个过程中连接一直挂着。更关键的是，后端每个实例的资源占用不是“处理完一个请求就释放”那么简单——GPU显存、算力、KV Cache都是长期共享资源。传统网关按QPS做均衡，结果就是慢请求、快请求混在一起，资源分配完全失控。

我打个比方：传统网关像写字楼的访客登记台，来一个人登记一下，见完就走，访客和会议室没有长绑定关系。LLM网关更像医院的分诊台，每个病人在诊室待很长时间，占用医生的精力和设备资源，而且有的病人要半小时，有的要三分钟，你不能只按“来一个叫一个”的方式处理。

1.2 成本视角：推理请求的昂贵属性改变了网关的职责边界

另一个被低估的点是成本。一次普通API请求的成本可以忽略不计，但一次大模型推理请求要消耗GPU时间，长文本、长输出的对话请求成本更高。如果网关还像传统网关一样“转发就算完事”，那流量控制、配额管理、成本分摊就全都失控了。

我们当时遇到过这样的情况：某个业务方写了个低效的循环调用，在摘要场景里反复请求同一个模型，单日成本直接翻了几倍。传统网关的限流是按请求数做的，对这种“单请求很贵但数量不多”的消耗方式几乎没有感知。AI网关必须有能力从模型语义层面感知成本——一个请求的输入Token数是多少、输出Token数预计多少、这个模型和这个参数的单价是多少。把这些信息纳入网关的决策逻辑，才能做到真正的预算保护。

这一点是我理解“AI网关定位”最重要的入口：它不只是流量的入口，更是成本的控制点。

1.3 AI网关的三种基本角色

经过一段时间的梳理，我习惯把AI网关的定位拆成三个角色。第一个角色是“模型流量的统一入口”。所有内部业务方不直接感知后端模型服务地址，只和网关约定的模型名、版本号打交道，后端扩缩容、迁移、切换都不影响调用方。第二个角色是“策略执行点”。路由、灰度、限流、排队、优先级、熔断这些策略统一收口到网关，而不是散落在各个业务代码里。第三个角色是“计量审计点”。每次调用消耗多少Token、花费多少钱、是哪个租户哪个业务发起的，网关留痕，便于成本核算和问题回溯。

这三个角色并不是并列关系，而是一个递进关系。先做到统一入口，才能谈策略执行；先把策略执行做到位，计量审计才有意义——因为你只有在入口做了限流和配额，计量出来的数据才是受控的、可信的。

2. 职责拆解：AI网关到底要做哪些事

2.1 模型路由与版本灰度：让调用方不感知后端变化

模型路由是AI网关最基本的职责，但做起来比预想中复杂。网关对外暴露的是一个“逻辑模型名”，比如summary-v1，内部维护一张路由表，把逻辑名映射到真实的模型服务地址和版本号。

这里有个容易忽略的点：模型升级不是简单的换一个地址，而是要处理Prompt兼容性。我们当时升级某个模型版本时，发现新版对一些特殊指令的响应格式有变化，业务方解析出来的结果直接报错。如果网关不做灰度，直接把流量切过去，就是线上事故。所以网关对于路由层的设计，至少要支持：同一逻辑名下多个版本并存，按权重分配流量；按请求特征做分流，比如特定API Key走新版本；支持一键回滚，路由配置修改后立即生效。

在做这个功能时，我体会到路由表不能做成静态配置，必须动态下发。我们的做法是配置存到配置中心，网关监听变更，秒级生效。灰度过程中要能够观察对比不同版本的成功率、延迟、Token消耗分布，所以网关还需要把“模型版本”作为标签打进日志和指标里，否则灰度数据根本没法对比。

2.2 流控、排队与优先级：QPS不是关键指标

传统限流看QPS，比如每秒最多100个请求。但在大模型场景，看QPS会误导，因为每个请求的耗时差异巨大。一个只生成几十个Token的请求和一个生成上千Token的请求，对后端资源的影响完全不同。更准确的指标是：当前正在并发处理的请求数、每个请求的已耗时时长、以及后端实例的吞吐上限。

我倾向于把网关的流控做成“并发控制 + 排队 + 优先级”的组合。具体来说，网关设定模型服务允许的最大并发数，比如8；超过并发上限的新请求进入排队队列，而不是直接放行；队列内部按优先级排序，重要业务的请求插队到前面；当请求在队列里等待超过阈值时，直接拒绝或返回一个提示让客户端稍后重试。

我们还有一个实际场景：某个模型服务被内部批量任务大量占用，正常用户请求一直处于饥饿状态。后来在网关里做了优先级队列，把实时交互请求放在高优先级，把离线批量任务放在低优先级，问题才解决。没有这层控制，后端的扩容和优化都是徒劳。

2.3 流式响应的代理与Token计量：边转发边统计

这是AI网关和传统网关差异最明显的地方。大模型API普遍使用SSE（Server-Sent Events）流式返回结果，客户端会收到一段一段的数据，每段包含若干Token。网关在中间要做的不只是字节转发，而是要解析流式数据、做计量。

为什么要解析而不是盲目转发？因为只有解析了SSE数据帧，网关才能知道当前流已经产出了多少个Token、请求是否正常结束、是否发生了中断。Token计量功能需要在网关内部统计整个流式过程中的Token总数，在流结束时输出准确的用量记录。否则就会出现我们遇到过的尴尬局面：客户端明明收到了一半响应就断了，但模型侧日志显示完整生成了，网关却什么都说不出来。

流式代理还有一个容易踩坑的点：客户端断连。用户可能因为网络原因中途断开，但上游模型服务还在继续生成，如果不做处理，GPU资源白白浪费。网关要能够感知下游断开，并主动向上游发送停止信号，尽快释放连接。这块做不好，高峰期会出现大量“客户端已经走了但模型还在烧钱”的情况。

2.4 面向模型语义的可观测性与审计

传统网关的监控指标是QPS、延迟、错误率、5xx占比。AI网关还需要加入模型特有的指标：TTFT（首Token时间），即从发出请求到收到第一个Token的时间，这是用户感知延迟的最核心指标；生成吞吐，用Tokens/s衡量，反映后端实例的实际处理能力；每次请求的输入Token数、输出Token数、总Token数；排队等待时间，反映网关流控是否健康；按租户、按业务方的Token消耗和成本预估。

审计方面，网关要记录每一次调用的完整链路：谁调的、调的哪个模型、用的什么参数、消耗多少Token、耗时多久、返回状态如何。这些日志既用于对账，也用于问题回溯。我们遇到过业务方反馈“我明明没调用这么多次”，查了网关日志才发现是有个定时任务在夜间批量重试。如果没有网关这层审计数据，这种问题基本无解。

3. 架构演进：从直连时代到网关的演进路径

3.1 早期直连时代：功能散落、策略失控

我们早期是完全没有网关的，业务方通过模型服务暴露的CLI或HTTP接口直接调用。这个阶段的架构最简单，扩展性最差。每个业务方都要自己管理服务地址，自己处理超时重试，自己实现限流，自己记录Token用量。结果就是所有策略都在业务代码里各自为政，有的团队做了缓存，有的没有；有的团队重试三次，有的重试十次；出了故障，大家都在群里互相推诿。

这个阶段最痛的还不是功能缺失，而是“变更成本”。模型服务一旦迁移或升级版本，所有调用方都要跟着改代码，有些人改了，有些人没改，线上就出现新旧版本混用。所以直连模式只适合早期Demo和实验阶段，一旦有多个业务方接入，就必须引入统一的网关层。

3.2 统一代理时代：数据面先行

第二阶段是独立部署一个代理服务，所有模型调用统一走代理。这个阶段做的事情主要是：统一服务入口，对外暴露固定地址；实现基础的路由转发，支持按模型名转发到不同后端；加一套基础的限流和鉴权；统一记录访问日志。

在这个阶段，架构上其实就一个“胖网关”，配置是静态的，路由也好、限流也好，都是网关本地文件。好处是立竿见影——调用方不再感知后端变化，网关有了全局流量视图。坏处也明显：每次改限流策略、加一个新模型，都要改网关配置并重启，操作风险高；数据面和控制面耦合在一起，策略的调整不够灵活。

我们在这个阶段挨过一次教训：某个版本升级需要调整限流阈值，结果改配置的时候不小心把并发上限写错，重启后直接把线上流量全部拒绝。那次事故之后，我们下定决心把控制逻辑从网关进程里拆出去。

3.3 控制面与数据面分离：AI网关走向平台化

第三阶段是控制面与数据面分离。数据面仍然负责转发流量，但路由、限流、灰度、配额这些策略统一放到控制面管理。控制面负责解析配置、处理策略变更，并通过下发机制同步到数据面，数据面无需重启即可生效。

这个架构的好处是：策略调整变得安全、快速，不需要动数据面进程；多个网关实例之间配置一致，不会出现“A实例限流100，B实例限流1000”的诡异情况；灰度、切换、配额变更可以做成操作界面，而不仅仅是改配置文件。对平台团队来说，控制面和数据面分离也是“网关平台化”的关键一步，因为你可以开始对网关做权限管理、变更审计、批量操作了。

需要注意的是，控制面下发配置时要考虑一致性问题。网关实例在运行过程中可能会短暂使用旧配置，这就需要在设计时明确策略版本号和下发节奏。我们遇到过限流配置已经改了，但因为某些网关实例没拉取到新配置，导致限流失效的情况。所以控制面不仅要下发配置，还要有配置有效性的检查机制。

3.4 可编程网关与Agent化：演进的下一个方向

现在比较新的演进方向是让网关具备更强的可编程能力——不只是“配置驱动”，而是“策略即代码”。网关暴露插件机制，开发人员可以写自定义逻辑来处理请求，比如按业务自定义的规则改写Prompt前缀、按对话上下文动态选择模型、与外部系统联动做更复杂的计量配额。

更进一步，有些网关产品开始引入Agent化思路，网关不只是被动等待流量，而是主动感知后端模型集群的状态——比如某个模型服务排队过长，网关主动把流量切换到备用模型；某个实例返回了减速信号，网关自动拉低流量权重。这个方向本质上是把原来的“人肉运维决策”逐步自动化。

从演进路径来看，核心驱动力就一句话：调用方越来越关注模型语义，而基础设施必须跟上。从直连到统一代理，是解决连通性问题；从代理到控制面分离，是解决运维问题；从配置驱动到可编程，是解决灵活性问题。每一步都在往“让模型调用像内部基础设施一样可管可控”这个目标靠拢。

4. 工具选型与落地实践：开源方案和自研如何权衡

4.1 开源网关项目还是自研：先看边界再看成本

现在市面上已经有不少开源的AI网关项目，也有云厂商托管的网关服务。我的建议是不要一上来就自研，先把边界想清楚。如果你只需要统一入口、基础限流、Token计量和日志，开源方案大概率够用；如果你有强烈的定制需求，比如独特的排队策略、与内部框架深度集成的鉴权逻辑、基于内部计费系统的配额联动，那开源自研的改造工作量会很大，这时候考虑自研或深度二次开发。

我们当时评估了很久，最终选了一部分自研，一部分复用开源组件的方式：HTTP转发、SSE处理这些通用能力用成熟组件，路由策略、成本计量、灰度控制这些偏业务的能力自己写。切割的标准是“是否和内部系统强耦合”。只要需要对接内部现有系统的，就自己写；纯技术能力，能复用就复用。

4.2 部署拓扑：网关放在哪个位置

部署拓扑上，我推荐把AI网关放到业务入口和模型服务之间，形成“客户端 → 接入层 → AI网关 → 模型服务”的链路。接入层负责常规的HTTP鉴权、跨域、防攻击等通用能力，AI网关专注于模型语义相关的策略。两者职责分离，互不干扰。

有没有必要把AI网关再往前面挪，直接对外暴露？我的看法是，除非是面向外部合作伙伴开放模型能力，否则没必要。内部团队直接把AI网关当作统一入口使用，鉴权逻辑仍放上一层，这样模型服务的暴露面最小，安全风险最低。

还有个实践细节：AI网关实例要和模型服务尽量近，减少网络跳数带来的延迟。我们最初把网关放在另一套集群里，跨网络访问模型服务，TTFT硬生生高了几十毫秒。后来调整到与模型服务同区部署，延迟才降下来。对于首Token延迟敏感的场景，网络路径上的每一毫秒都值得抠。

4.3 落地路线建议：控制面先行、数据面逐步收口

落地节奏上，我建议分三步走。第一步，先接流量，统一入口。不管后端是什么形态，先把AI网关部署起来，把模型服务的地址全部收口到网关，业务方改为通过网关调用。这一步只做转发和日志，不急着上线复杂的限流和灰度，目的是让链路跑通、数据沉淀下来。第二步，上策略。有了流量数据之后，开始配置路由、限流、配额、灰度策略。这个时候做决策就有据可依了，不再是闭着眼睛拍阈值。第三步，做计量和平台化。把Token计量、成本核算、审计报表做起来，再逐步把控制面独立出去，形成可管理、可审计的网关平台。

这个顺序是刻意的。如果第一天上线就开全功能，出问题根本没法排查；如果先做计量再做路由，业务方可能已经因为直连模式形成了路径依赖。先收口流量，再逐步加策略，是风险最小的路径。

5. 常见问题与排查技巧实录

5.1 SSE流中断导致模型侧超额计费

现象：客户端上报的Token消耗远小于模型侧日志记录的消耗，而且高峰时段特别明显。排查发现，网关对SSE流没有做中断处理，当客户端断开连接后，网关仍然维持上游连接，模型继续生成到完整结束，Token照常计费。

修复方案：网关需要监听下游连接状态，一旦感知到客户端断连，立即向上游发送取消信号。另外在网关层要对TTFT和总耗时设置合理超时，避免上游“死等”成僵局。这个问题的本质是：网关不能只当中转，要有连接生命周期管理能力。

5.2 并发控制失效：限流阈值设了但没生效

现象：明明在网关里设置了并发上限，模型服务的负载还是很高。排查发现，多个网关实例是独立计数的，每个实例都允许8个并发，三个实例加起来就是24个并发，远高于预期。

修复方案：如果是并发级别的控制，必须使用分布式计数器，把所有网关实例的并发统计汇总到同一个存储（比如Redis），才能做到全局精确限流。如果只是做单实例的粗粒度限制，那要明确告诉业务方这个阈值是按实例生效的，不具全局意义。这个坑提醒我们：部署架构会直接影响控制逻辑的有效性。

5.3 灰度流量分布不均：权重配置正确但实际偏斜

现象：设置了5%的流量到新版本，但实际观察新版本的请求占比经常超过10%。排查发现，灰度分流逻辑是按请求的哈希值取模来定的，如果请求ID的哈希分布本身不够均匀，小比例分流就会偏差很大。

修复方案：要么改用一致性哈希并且扩大桶数量，要么在灰度比例较小的情况下，用专门的流量复制或按特定调用方白名单的方式验证。如果只是临时验证新版本，用指定API Key或指定参数走新版本的方案，比按百分比灰度更精准。

5.4 健康检查“假阳性”：端口活着但模型已经不可用

现象：网关的健康检查一切正常，但转发过去的请求大量超时。排查发现，健康检查只做了TCP或HTTP端口探测，但模型服务因为显存溢出已经处于半死不活状态，进程还在，端口还开着，就是不响应推理请求。

修复方案：健康检查要包含“就绪态”检查，即通过一个轻量级推理请求或内部状态接口来确认模型真正可用。同时网关要具备熔断能力，当某个后端实例连续超时超过阈值，自动摘除流量，不再往这个实例上打。

5.5 客户端重试引发的重复计费

现象：业务方报障称某个请求只发了一次，但网关日志显示同一请求被转发到了后端两次，计费也算了两次。排查发现是客户端把请求超时时间设置得太短，首Token延迟稍高就触发了客户端重试，而网关和模型侧没有幂等能力。

修复方案：在网关层支持请求去重，基于请求ID判断是否已经转发过；同时协调客户端合理设置超时时间，避免首Token延迟的正常抖动直接诱发重试。这个问题的本质是：AI请求的耗时天然不稳定，超时策略必须比普通API更宽容。

踩过几次坑之后，我的体会是：AI网关本质上不是在“转发请求”，而是在管理一种昂贵、长连接、流式返回的特殊资源。过去我们习惯的网关思维，很多假设都需要重新审视。如果这篇复盘能帮你少走几步弯路，那就值了。后面如果你们团队也在建设类似的网关能力，欢迎一起交流踩坑心得。