Cloudflare AI Gateway 与 LiteLLM 的比较，首先是运维模式的选择。两者都可以位于应用与模型供应商之间，但由谁运行这个中间层，会改变事故响应、权限设计、部署工作以及团队能够保留的证据。原型运行成功，并不能回答这些问题。
如果托管网关符合你的权限、数据和路由要求，而且团队希望避免再维护一项服务，可以选择 Cloudflare AI Gateway。如果自行运行代理能解决明确的部署或控制需求，而且团队有能力承担基础设施责任，可以考虑 LiteLLM。迁移生产流量前，应让两者处理同一套应用工作流。
设想一个同时提供交互式助手和后台摘要功能的客服应用。助手需要及时响应和可预期的错误提示，摘要任务则可以等待。让两者经过网关很有帮助，但如果将其视为完全相同的负载，就更难推导容量、回退和支出控制策略。
下文是一份采购与实施指南。文中的设计示例均为假设，并不声称任何一款产品在所有情况下都更快、更便宜或更安全。
Cloudflare AI Gateway 与 LiteLLM：先定义边界
Cloudflare 将 AI Gateway 描述为用于观察和控制 AI 应用流量的服务，功能包括缓存、限流与回退。LiteLLM 将其网关 描述为自行托管、向模型供应商提供统一接口的服务器。这些说明确立了大体的部署选择，却不能证明每个端点或功能的行为都相同。
应用仍负责用户身份、允许执行的业务任务以及答案验证，供应商仍决定模型行为。网关是两者之间的控制点，也有自己的凭据、配置与故障模式。
比较功能清单前，应先画出这一边界。对客服应用而言，网关可以路由请求并记录用量，但不能仅因模型提出要求，就认定某位员工有权阅读另一位客户的客服记录。
我们已有的 AI Gateway 指南 介绍了常见的成本控制思路。本文关注的是团队能够支持哪种运维模式，以及如何证明其适用。
先比较责任，再比较功能
| 决策 | Cloudflare 托管路径 | 自行运维的 LiteLLM 路径 |
|---|---|---|
| 网关基础设施 | 评估托管服务契约 | 负责部署、容量与服务恢复 |
| 应用授权 | 保留在应用及关联系统中 | 保留在应用及关联系统中 |
| 供应商兼容性 | 测试所需供应商及端点 | 测试所需供应商及端点 |
| 运维证据 | 明确可访问日志及导出安排 | 明确日志、存储、访问及备份安排 |
| 变更控制 | 对网关配置和应用假设进行版本管理 | 对代理部署、依赖和配置进行版本管理 |
这是一份责任矩阵，并非功能完全一致的承诺。商业版本、服务套餐和可选功能会影响实际可用能力。应要求查看真正准备部署的配置，不能拿一边的付费功能与另一边的基础配置作比较。
如果选择自行运维，请阅读当前的 LiteLLM 生产部署指南 。进程在笔记本上成功启动，与服务在实例重启或依赖故障后仍能正常运行，是不同的要求。
为两个候选方案提供相同的请求契约
创建一小组有代表性的应用请求，包含实际端点结构、必需的响应字段、流式行为、工具使用及取消预期。除非已明确安排使用客户信息，否则应从评估数据集中移除这些信息。
如果生产环境依赖工具调用或结构化响应，仅测试纯文本成功案例并不足够。网关接受请求，并不能证明每个字段都能经过路由完整保留，也不能证明应用可以解释结果。
应分别记录应用截止时间与上游超时。如果浏览器已停止等待，而供应商仍在处理，团队就需要知道应该取消、丢弃还是核对后续结果。不能让重试策略悄悄将工作量翻倍。
预期结果必须独立于网关。缺少权限、理应拒绝的请求，经过任一候选路径都必须被拒绝；应该得到可用答案的请求，经任一路径返回后，也必须通过相同的应用验证。
将回退作为产品行为变更来测试
回退意味着可能由另一个模型或部署生成答案。即使 HTTP 响应看似正常，措辞、结构化输出与工具选择仍可能改变。应模拟上游故障，测试完整的应用路径。
对客服助手而言，可接受的回退或许是只提供答复草稿，不执行账户操作。对摘要任务而言，等待指定模型可能更稳妥。正确选择取决于业务任务，而不是让每个请求都显示成功的愿望。
确定谁可以更改路由和凭据
网关可能成为供应商访问权限的集中点。应将调用已批准路径的权限，与添加供应商、更改路由或查看请求内容的权限分开。记录权限如何授予、撤销与复核。
需要独立归因或撤销访问时，应使用不同的应用身份。不直接暴露业务含义的工作负载标识符，有助于解释账单，无须为每个请求添加个人信息。不能将客户端任意提供的元数据视为可信授权依据。
凭据轮换需要演练。先更换测试凭据，确认旧凭据已失效，再验证受支持的应用路径仍然成功。还应检查轮换不完整时普通用户看到的错误信息。
无论选择哪种方案，都应要求提供实际日志配置的证据。展示令牌用量的仪表盘截图，并不能证明提示词不会被存储、导出遵循同一策略，或只有指定员工可以阅读日志。
让比较结果有据可查
| 测试 | 应保留的证据 | 阻止上线的情况 |
|---|---|---|
| 正常应用请求 | 已验证结果及端到端耗时 | 必需响应字段丢失 |
| 上游拒绝或中断 | 选定路径、故障类别及用户结果 | 悄悄路由到批准策略之外 |
| 凭据过期 | 拒绝结果及运维告警 | 未记录的绕过方式仍然有效 |
| 客户端取消 | 请求生命周期及后续结果 | 后续工作无法归因 |
| 配置回滚 | 已恢复的路径及重新执行的验收案例 | 恢复依赖个人记忆 |
应从用户发出请求开始，测量直到应用得到结果的全过程。仅观察网关延迟，会掩盖供应商延迟与应用验证开销。在具有代表性的并发条件下运行相同案例，日志与路由配置应与生产环境一致。
报告中应区分网关故障与上游故障。否则，某个供应商事故可能仅因发生在特定测试时段，就让其中一个候选方案显得不可靠。应保留足够的请求上下文以解释观察结果，同时避免留下不必要的内容。
为实施和持续运维编制预算
真正有意义的比较，是交付该工作负载的总成本。托管服务应计入集成、配置、使用费用、导出与持续复核；自行运维还需计入托管、部署维护、依赖更新、备份及事故响应人员的投入。
要求以 GBP 提供方案报价，并明确负载假设。说明预期请求组合、载荷大小、响应长度、并发量与故障场景。仅根据每月请求数量报价，无法解释长响应或重复尝试的成本。
| 工作包 | 有用的交付成果 | 主要范围因素 |
|---|---|---|
| 兼容性评估 | 已测试的请求与响应契约 | 端点及供应商的多样性 |
| 权限与路由 | 版本化策略及撤销测试 | 身份与路径数量 |
| 运维配置 | 告警、日志选择及运行手册 | 证据与支持要求 |
| 迁移 | 受控切换及回滚证明 | 与现有应用的耦合程度 |
不要将较低的供应商账单直接等同于更便宜的运维模式。如果代理需要团队无法提供的专业维护，这种责任缺口就应纳入采购决策。同样，如果托管服务无法满足应用确实需要的要求，它也不适合。
先迁移一项边界明确的负载
选择结果容易验证、回滚方式明确的工作负载。在商定的试用期间保留原有路径，并定义由哪个配置选择网关路径。记录谁有权更改该选择项。
迁移时不要同时开启所有优化。先建立基线路径，再分别评估缓存、回退与其他控制。这样才容易找出是哪项变更导致答案变化或出现新故障。
交接资料应包括经过测试的请求示例、已部署配置、凭据责任归属、日志决策与事故处理流程。另一位工程师应能复现具有代表性的故障，并将负载恢复到已知可用的路径。
我们可以通过范围明确的 AI 集成试点 评估这些边界。一份实用的需求说明应列出应用、必需供应商、权限约束，以及必须保持正确的结果。提供这些信息并索取网关实施方案 ，让比较反映你的实际运维要求。
常见问题
Cloudflare AI Gateway 与 LiteLLM 是同类产品吗？ 两者都可作为模型流量的中间层，但运维模式至关重要。Cloudflare 提供托管网关服务，LiteLLM 则提供自行托管网关的文档。应比较实际准备使用的部署方式、端点支持与控制措施，不能假设所有功能行为相同。
哪种网关更便宜？ 这取决于用量、选定功能及运行集成的成本。在相同负载假设下，比较供应商费用、网关相关费用、基础设施与维护投入。较低的服务账单仍可能伴随更高的支持负担。
更换网关时可以不修改应用吗？ 有时初始连接改动很小，但兼容性仍需测试。即使基本请求格式看起来熟悉，流式响应、工具调用、错误、元数据及供应商专有字段仍可能影响应用。
网关会取代应用权限吗？ 不会。客户记录与业务操作的授权应保留在应用和关联系统中。允许一次模型请求，并不代表允许读取所有记录或执行所有工具。
应该立即启用回退吗？ 只有在备用路径通过该负载的验收案例后才启用。回退模型可能返回格式有效、行为却不同的响应。对于某些后台任务，等待比悄悄更换模型更合适。
试点应该交付什么？ 试点应交付经过测试的请求契约、责任矩阵、配置与日志决策、具有代表性的故障结果，以及经验证的回滚方案。除了成功案例，还应说明尚未解决的要求。
比较网关时可以使用真实客户提示词吗？ 应先使用脱敏或合成案例。如果确实需要生产内容，应约定谁可访问、内容经过哪里、保留什么以及如何删除。不要仅为了让评估显得真实，就引入敏感内容。