企业官网建设流程全解析

很多朋友第一次听到 AI 网关，第一反应往往是“这不就是 API 网关套了个马甲吗？”——这个判断对了一半。API 网关管的是接口路由、鉴权、限流，这些 AI 网关都继承；但 AI 网关真正要解决的，是模型切换、Token 计费、流式响应、多模态格式适配这些和 AI 强绑定的问题。这篇文章我准备从一个实际场景切入，拆开讲讲为什么多模型时代，应用层需要这样一个“中间层”，也把我在项目里踩过的坑和存下的经验一并分享出来。

什么人适合读这篇文章：正在做 AI 应用、纠结要不要上多模型，或者已经在为多模型的接入和维护头痛的研发、架构师、技术负责人。如果你还停在单模型阶段，读这篇文章的好处是能提前看清未来要面对的问题，避免在架构上走回头路。

1. 多模型时代的真实困境

1.1 你以为是自由选择，实际是被模型厂商“绑架”

我参与过一个智能客服项目，起步阶段只接了一家模型 API，团队当时的约定是“非必要不换模型”。理由是简单：代码里到处是模型 SDK，换模型的工作量太大，不想碰。结果半年后，模型厂商调价，账单翻倍，产品组慌了，要求立刻切换模型。

我翻了一下代码，SDK 的实例被散落在四十多个文件里，有的直接 new 客户端，有的依赖全局单例，有的把模型返回的错误码写死在业务判断里。真要换模型，先要梳理所有调用点，再逐个适配新 SDK，还要针对新模型的参数语义调整业务逻辑——保守估计一个多月，期间所有 AI 功能冻结。

这种困境的本质是架构问题，不是“换哪家模型”能解决的。任何单一模型厂商的 API，一旦和业务代码深度耦合，你就失去了议价权和选择权。模型在快速迭代，价格在波动，能力边界在扩展，而你却因为改不动代码，只能被动接受。

1.2 多模态把复杂度推向新高度

最近多模态模型讨论度很高，图像识别、语音问答、视频理解这些能力正在快速融入产品。但多模态带来的复杂度，比纯文本高了一个量级。

先说输入格式。同一张图片，有的模型要求 base64 字符串，有的要求可访问的 URL，有的要求 multipart 表单，还有的模型对图片尺寸、格式、压缩比例都有严格限制。音频输入更麻烦，采样率、编码格式、声道数，各家要求都不一样。如果你的应用同时支持文本、图片、语音问答，每一种输入类型、每一家模型都要写一套适配逻辑，代码会迅速膨胀到不可维护。

再说输出。多模态模型的输出不只是文本，还有结构化数据、内联图片、引用标注等。不同模型对这些内容的编码方式不一致，上层应用想要统一解析，难度不小。

当模型数量从 1 变成 3、5、10，差异会呈指数级放大。客户端不可能也不应该去适配每一家模型的每一个细节。所以在应用和模型之间插入一个中间层，让差异在这个层次收敛，同时让上层面对统一接口，几乎是多模型应用的必然选择。

2. AI 网关的核心能力拆解

2.1 统一协议：让所有模型看起来“一样”

AI 网关最基础、也最值钱的能力，是协议归一化。它做的事情很朴素：把各家模型厂商不同的 API，统一转换成你自定义的标准格式。业务代码只和标准格式打交道，模型切换变成改网关配置，而不是改业务代码。

具体落到实现层面，至少有三件事要做。

统一请求格式。不同模型的请求参数差异很大，model、messages、temperature、max_tokens 这些字段，命名、位置、可选性都不一样。网关要做一层映射，把标准请求翻译成目标模型的方言。

统一响应格式。模型返回的原生结果五花八门，有的把文本放在 choices[0].message.content，有的放在 content[0].text，有的带 usage，有的不带。网关统一转成标准响应结构，上层就不需要关心字段差异。

统一流式协议。OpenAI 的 SSE 格式，Anthropic 的事件流，国产模型自己的流式协议，差异很大，网关要把它们收敛成一种格式再透传给客户端。这块是很多团队自己造轮子时最容易翻车的地方，后面我会详细说。

我在多个项目里的体会是，统一协议是整个 AI 网关里性价比最高的投入。它一开始看起来像是“多一层转发，多一层性能损耗”，但实际带来的收益远超那点损耗——团队不再依赖任何一家模型 SDK，核心业务逻辑和模型实现彻底解耦。

2.2 智能路由与容灾：把“该用哪个模型”决策上收

统一协议解决的是“怎么换”的问题，智能路由解决的是“该用哪个”的问题。路由本质上是一个决策系统，它根据请求的特征决定请求走哪条模型通道。

常见路由策略大体分几类。按任务类型走，简单分类、信息抽取走便宜的小模型，复杂推理走高性能大模型，图片理解任务走多模态模型；按用户维度走，免费用户走低成本模型，付费用户走顶级模型；按实时状态走，主模型超时或报错时自动切换备用模型。

这些策略如果写在业务代码里，很快会变成一团乱麻，因为团队的策略是经常调整的。放网关里用配置驱动，灵活性就高得多。

容灾是路由策略里最刚需的一环。模型厂商的可用性，说实话很难用 SLA 完全兜住。我遇到过模型服务连续五个小时返回 5xx 错误，如果应用没有故障转移能力，线上业务直接瘫痪。网关在检测到主模型异常时，能自动把请求切到备用模型，对调用方面完全透明。

多 Key 轮转也算容灾的配套能力。模型厂商对单个 API Key 都有速率限制，多个 Key 轮转能显著提高整体吞吐。网关在请求分配时按权重轮转 Key，遇到 429 错误自动换下一个 Key，这是接入模型时最常见的硬需求。

2.3 成本治理与可观测性：没有数据的网关等于没做

很多团队把 AI 网关当成一个“转发器”，我觉得这是对网关价值的最大浪费。网关最适合做的事，是对 AI 调用做精细化成本治理。

先说 Token 监控。模型计费的核心单位是 Token，一个请求的输入 Token、输出 Token、缓存命中 Token，直接影响成本。独立应用可以通过模型返回的 usage 字段做粗粒度统计，但多应用、多团队共用模型资源时，就必须在网关这一层统一采集。网关要知道每一个 API Key 消耗了多少 Token，哪个应用、哪个功能在烧钱，才能回答“钱花在哪了”这个问题。

再说配额与限额。网关可以给每个 API Key 设置配额，超过阈值的请求自动降级或拒绝。也可以设置单次请求的 Token 上限，防止业务代码里出现“越权调用”——我见过一次线上事故，一个低端功能因为上限设置不当，把整个月的模型预算打光了。

可观测性方面，日志和指标要在网关层标准化。请求延迟、模型返回耗时、Token 消耗、错误码分布、缓存命中率，这些指标统一采集之后，才能做有效的成本分析和容量规划。没有数据支撑的网关，本质上就是一个只能转发不能治理的黑盒子。

2.4 多模态网关的进阶能力

多模态模型普及之后，网关又多了一个职责：输入标准化。客户端不必关心目标模型接受什么格式，只需把原始数据丢给网关，网关负责预处理。

以图片为例：客户端传原始图片文件，网关判断目标模型的输入要求，自动完成 base64 编码、URL 生成、尺寸压缩、格式转换。音频同理，统一转码、降采样、时长截断等操作放在网关层完成。这样客户端保持轻量，模型升级带来的格式调整，只影响网关配置，客户端不需要跟着变化。

更深入地看，多模态网关还承担多模型能力协商的职责。一个请求里同时包含文本和图片，不同模型的混合输入能力不一样，有的支持图文联合推理，有的只支持单一图片。网关根据模型能力做预处理和路由，用户感知不到背后的切换。

做多模态网关有一个容易忽略的细节：图片和音频的体积。图片动辄几 MB，音频更是几十 MB 级别，网关转发时需要考虑体积优化和传输压缩。这里我试过用预签名 URL 代替直接 base64 传输，实测下来能把网关转发耗时降一个量级，后面避坑部分细说。

3. 自建一个最小可用 AI 网关

3.1 选型：开源优先，但别迷信

现在市面上的 AI 网关方案不少，我按适用场景简单分一下。

第一类是通用 API 网关加 AI 插件，代表有 Higress、Apache APISIX、Kong。这些项目本身是成熟的流量网关，AI 插件让它具备了模型代理、协议转换、Key 管理能力。适合已经在用这些网关、不想再引入新组件的团队。

第二类是专门的 AI 网关/代理项目，代表是 LiteLLM。它支持上百种模型服务，统一接口格式，内置负载均衡、预算管理、日志记录。特别适合多模型接入需求明确的团队，PyPI 上直接装，配置简单，社区活跃。

第三类是自研。不推荐所有团队一上来就自研，因为你面对的问题大概率已经被开源项目解决过了。但如果你有特殊需求，比如私有化部署的协议定制、多模态输入深度预处理，开源项目扩展点不一定够用，自研反而更可控。

我的建议是：先用开源项目搭起基础能力，验证业务场景，再根据实际需要决定是否二次开发。不要一上来就用重型方案，也不要为了炫技自研轮子。

LiteLLM 的配置比较轻量，我贴一个最小配置示例，读者可以感受一下这类工具的上手成本。

# config.yaml model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/openai_key - model_name: claude-3.5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/anthropic_key - model_name: vision-model litellm_params: model: openai/gpt-4o-mini api_key: os.environ/openai_key

配置里定义了三个模型入口，业务侧统一通过 LiteLLM 的 /openai 风格接口调用，客户端只需要改 base_url，不用动代码。模型切换就是改配置和重启服务，真正做到了业务和模型解耦。

3.2 自研一个轻量网关的代码骨架

我理解有的读者希望搞清楚内部原理，所以我用 Python 写过一个轻量版网关，大约 400 行，技术栈是 FastAPI 加 httpx。核心功能包括统一协议、多 Key 轮转、按模型名路由、流式转发。这里贴出核心代码骨架，并解释每一块的设计意图。

# app.py 简化版 AI 网关核心逻辑 from fastapi import FastAPI, HTTPException, Request from fastapi.responses import StreamingResponse, JSONResponse import httpx from pydantic import BaseModel app = FastAPI() # 模型映射表：标准模型名 -> 上游服务配置 MODEL_ROUTES = { "chat": { "url": "https://api.openai.com/v1/chat/completions", "api_keys": ["sk-xxxx", "sk-yyyy"], "timeout": 60, }, "claude": { "url": "https://api.anthropic.com/v1/messages", "api_keys": ["ak-xxxx"], "timeout": 90, }, } # Key 轮转：简单取模 + 状态记录 def get_next_key(mapping: dict) -> str: if "current_key_index" not in mapping: mapping["current_key_index"] = 0 keys = mapping["api_keys"] key = keys[mapping["current_key_index"] % len(keys)] mapping["current_key_index"] += 1 return key def normalize_request(body: dict) -> tuple: """把标准请求转换为目标模型方言，这里以 OpenAI 与 Claude 为例""" model_name = body.get("model", "chat") messages = body.get("messages", []) if model_name == "claude": # Claude 需要 system 字段单独拆出来 system_content = "\n".join( m["content"] for m in messages if m.get("role") == "system" ) filtered_messages = [m for m in messages if m.get("role") != "system"] return { "model": "claude-3-5-sonnet", "system": system_content, "messages": filtered_messages, "max_tokens": body.get("max_tokens", 1024), "stream": body.get("stream", False), }, MODEL_ROUTES["claude"] # 默认走 OpenAI 兼容协议 return body, MODEL_ROUTES["chat"] async def forward_request(request: Request): """核心转发逻辑：解析、映射、转发、响应""" body = await request.json() target_body, route = normalize_request(body) api_key = get_next_key(route) headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json", } async with httpx.AsyncClient(timeout=route["timeout"]) as client: if body.get("stream"): # 流式转发：把上游 SSE 数据流原样透传给客户端 req = client.build_request( "POST", route["url"], json=target_body, headers=headers ) upstream_response = await client.send(req, stream=True) return StreamingResponse( upstream_response.aiter_raw(), status_code=upstream_response.status_code, media_type="text/event-stream", ) resp = await client.post(route["url"], json=target_body, headers=headers) if resp.status_code == 429: raise HTTPException(status_code=429, detail="rate limited") return JSONResponse(content=resp.json(), status_code=resp.status_code) app.add_api_route("/v1/chat/completions", forward_request, methods=["POST"])

这段代码有几个重要的设计决策。

Key 轮转不是简单随机，而是带状态的取模轮转，这样能保证每个 Key 被均匀使用。生产环境建议做成独立的 KeyManager，记录每个 Key 的速率限制和剩余配额，否则多个 worker 进程各轮各的，限流依然会出现。

normalize_request 是协议转译的核心。不同模型的参数差异都是在这样一个小函数里收敛的。你需要维护一个映射表，把标准请求映射到各家模型的方言。Claude 的 system 字段要单独拆出来，这是常见差异点。

流式转发用 httpx 的 build_request 再 send(stream=True)，直接把上游的字节流透传，不做二次解析。这样可以最大化吞吐，但代价是失去对流式内容的统计能力。如果你需要流式 Token 计数，就得在网关层自己解析 SSE 事件，成本会高一些。

3.3 部署与验证：怎样才算落地成功

自建网关之后，第一件事是本地跑通，第二件事就是做回放验证。回放验证的含义是：把你线上真实的请求日志拿出来，对着新网关跑一遍，对比结果是否和原模型一致。这一步非常重要，因为网关层最怕出现“转发没问题但语义变了”的隐性 bug。

回放方式很简单：把这些真实请求用工具重放到网关，对比返回内容。我习惯用 drift 检测来做相似度对比，文本类请求用编辑距离和语义相似度的组合评估，如果偏差过大，就去检查 normalize_request 里的映射逻辑。

部署形态上，我推荐 Docker 单容器起步。FastAPI 加一个进程跑 HTTP 服务，前面加个 Nginx 做 TLS 终止就够了。如果请求量上来了，横向扩展网关实例，注意此时 Key 轮转和限流要做在共享存储上，比如 Redis，否则每个实例各自维护 Key 状态，会出现限流不均的问题。

压测工具我推荐 locust，原因是它脚本写起来简单，便于模拟真实的多模态请求分布。压测时关注的指标不只是 QPS，还有 P95 延迟和错误率。网关每多一跳，延迟一定会有增加，你要做的不是追求零损耗，而是把额外延迟控制在可接受范围内。按我的经验，本地到网关再到模型，额外延迟控制在 20ms 以内是合理的，多数情况下连 10ms 都不到。

4. 常见问题与避坑实录

4.1 高频问题速查表

这里整理成两张表：模型接入类、稳定性类。每一项背后都是线上事故攒下来的经验。

这个表格是经验总结，展开说几个。

4.2 流式响应是自研网关最容易翻车的地方

流式响应翻车的主要原因是超时和断连。模型做长文本生成时，SSE 的事件间隔可能很长，如果网关的读超时设置得太短，会在两次事件之间把连接断掉。客户端收到的流就中断了。解决方法是按模型类型配置不同的读超时，长推理模型要放宽。

另一个坑是流式响应的错误处理。很多模型 API 在流式过程中返回错误，其实是放在 SSE 事件里的，状态码却是 200。如果你的网关只判断了 HTTP 状态码，就会把带错误内容的 SSE 透传给客户端，客户端解析出奇怪的结果。正确做法是网关层对 SSE 事件做轻量解析，既能统计 usage，又能检测错误事件，把错误转为合适的 HTTP 状态码返回。这需要一点额外开发，但值得。

4.3 多模态数据的体积处理

多模态数据最现实的问题是体积。一张几 MB 的图片转成 base64 之后，体积会膨胀约 33%，加上 JSON 包装，一个请求的 body 会非常大。网关做转发时，如果直接透传，上游模型接口被拖慢，还容易触发网关层 body 大小限制。

我试过两种优化策略。第一种是在网关层对图片做压缩和格式转换，用 Pillow 把大图缩放到 512 以内，JPEG 质量压到 80。实测下来，图片体积可以从 3MB 骤降到 200KB 左右，转发速度提升非常明显，模型侧识别精度下降可以忽略。第二种是对音频做转码和时长截断，只发送有效片段，避免把整个音频文件丢给模型。这两种策略在多模态网关里几乎必备。

还有一种思路更极端但很有效：把媒体文件先上传到对象存储，请求 body 里只带预签名 URL。模型服务多数支持 URL 输入，这样网关转发的请求非常轻量。缺点是多一次上传流程，客户端要稍微多写点代码，但在大文件场景下收益远大于成本。

4.4 成本治理的一些细节心得

成本治理最容易犯的错误是把所有请求都路由到最强的模型。通用大模型能力最强，但是贵、慢；小模型便宜、快，但能力上限低。如果不做路由策略，默认全走大模型，预算会很快失控。

我的建议是：在网关里预设一套“默认小模型、按需大模型”的路由规则。高价值复杂任务才走大模型，简单任务一律小模型。这个策略改起来很快，一个配置项就能生效，但它的省钱效果非常可观。

另一个细节是 Token 上限。很多模型请求失败不是因为网络，而是因为输出 Token 超过上限。网关在转发前可以做一次预校验，把 max_tokens 限制在合理范围，防止业务代码里出现一次性输出上万 Token 的调用。

还有缓存。模型调用结果在某些场景下是可缓存的——比如用户问题固定、期望答案不变。网关层可以做精确命中缓存，也可以做语义缓存。精确命中缓存实现简单，直接以消息哈希为 key。语义缓存成本高一些，需要嵌入向量化，但特定场景下收益巨大。这些能力都属于“加分项”，先把前面的基础能力做扎实，再考虑缓存。

4.5 安全与合规：网关是最后一道闸

模型 API Key 的管理是安全重点。千万不要把模型 API Key 下发到客户端，一定要放在网关或服务端。网关在中间层，天然适合做 Key 隔离：客户端只持有网关颁发的应用 Key，网关背后管理真实的模型 API Key。

多租户场景下，应用 Key 要隔离权限：某个 Key 只能调用特定模型，只能消耗特定额度。网关在转发前做鉴权校验，防止一个团队的 Key 越权调用高成本模型。

内容安全上，可以在网关层挂敏感信息过滤。请求出去之前做一次脱敏处理，比如把身份证号、手机号替换为掩码；响应回来之后再做一次内容合规检测。这些逻辑放网关层，各个应用就不用各自实现了。

值得强调的是，网关层做安全过滤要格外注意性能损耗。字符串匹配和规则过滤还好，如果上大模型进行内容审核，延迟和成本都会显著增加。建议按风险级别分级处理：普通文本用规则过滤，高危场景才上模型审核。

5. 多模态模型复现与应用侧的角色分工

5.1 复现模型的团队先别急着写代码

多模态模型是当前热词，很多团队想自己复现或者微调一个多模态模型。但我要提醒一句：如果你在做多模态 AI 应用，先把多模态的输入处理和多模型路由想清楚，再考虑代码层面的复现。因为应用侧的瓶颈往往不在模型权重，而在数据流动的流畅度。

我在项目里见过团队花大量精力微调模型，却忽略了数据管线：图片上传经常失败、音频转码格式不兼容、模型输入输出状态码混乱。这些问题用 AI 网关就能解决，把精力省下来放到真正影响业务体验的地方。

这里给一个判断标准：如果你的多模态请求成功率低于 95%，先不要怀疑模型能力，先检查数据链路。图片有没有被正确压缩？音频采样率是否符合模型要求？每一家模型对输入格式的偏好是否被正确处理？这些问题的答案，大概率在网关层能找到。

5.2 本地模型与云端模型的统一编排

如果你确实要做多模态模型的本地化部署和复现，网关也有独特价值：把本地模型和云端模型编排在一个统一入口之下。数据敏感度高的请求走本地模型，需要强大推理能力的请求走云端模型，网关按数据属性自动路由。这样既满足了数据隐私要求，又保留了调用顶级模型的能力。

这本质上是将“模型路由”这一能力从按任务类型扩展到按数据流向。技术实现上与第 3 章的自研思路完全一致，只是多一个本地推理服务作为上游节点。配置里加一行路由规则，就能完成编排。

6. 最后再分享一点个人体会

我在实际项目中的体会是：AI 网关不是一个锦上添花的组件，而是多模型时代的架构必需品。它解决的不是某一个模型的问题，而是整个应用如何与模型生态共处的问题。如果你正在设计新的 AI 应用，从一开始就把网关层的边界划出来，后面会省下大量重构成本。

最后分享一个小技巧：网关的配置文件一定要做好版本管理和评审流程。模型路由策略、Key 轮转权重、成本限额，这些配置的变更直接影响线上成本和稳定性。把配置当代码一样对待，走 PR 评审，能避免很多“改了个配置引发线上事故”的惨剧。

另外，网关不是越复杂越好。很多团队一上来就追求语义缓存、A/B 测试、模型编排，结果维护成本比收益还高。我的建议是分阶段推进：先做协议统一和 Key 管理，跑通之后再逐步加路由策略、成本治理和多模态预处理。每加一个能力，都要有明确的数据来证明它值得，而不是为了一些看起来很酷的架构概念提前负债。多模型时代的好消息是，选择越来越多，坏消息是，选择的成本都堆在应用侧。一个务实的中间层，能把这些成本消化在网关这一层，让业务代码安心做业务，这大概就是 AI 网关最有价值的地方。