AI模型网关选型指南：OpenRouter替代方案四象限决策法

1. 项目概述为什么“先分清类别再比能力”是选型铁律OpenRouter 这个名字在2024年之后迅速成为国内开发者、AI应用搭建者和中小团队技术选型时绕不开的关键词。它不是模型本身而是一个典型的“AI模型路由网关”——你可以把它理解成一个智能交通调度中心你发一条请求过去它自动帮你匹配最合适的模型比如GPT-4 Turbo、Claude-3.5-Sonnet、Qwen2.5-72B、DeepSeek-V3按调用量计费支持统一API Key管理、请求日志、速率控制、多模型负载均衡。但问题恰恰出在这里它本质是服务型中间件不是基础设施。一旦你把业务逻辑深度耦合进它的抽象层后续迁移成本会远超预期。我从2023年Q4开始接触OpenRouter最早用它快速验证一个客服对话引擎的可行性到2024年中我们团队已将其接入6个SaaS产品线日均调用量突破280万token再到2025年初因响应延迟波动、上游模型供应商策略突变比如某家闭源模型突然限制流式输出、以及最关键的——支付链路在国内场景下始终无法稳定闭环支付宝/微信支付需经第三方跳转失败率长期维持在12.7%我们启动了替代方案评估。这不是一次简单的“换API”而是对整个AI调用架构的重定义。所谓“先分清类别再比能力”指的是必须跳出“哪个更便宜”“哪个响应更快”的表层对比先厘清你真正需要的是什么类型的替代品是要一个功能等价的托管型路由服务即OpenRouter的直接竞品还是要一个可私有部署的模型网关如LiteLLM、vLLM Gateway把调度权完全收归己有或者根本不需要“路由”只需要单点高性能模型接入能力比如专注Qwen或DeepSeek的专用SDK又或者你的瓶颈其实在模型推理层本身该考虑的是底层推理引擎优化如TensorRT-LLM、Triton Inference Server而非API网关这四类路径技术栈、运维成本、扩展性、合规边界、甚至法务风险都完全不同。我见过太多团队花两周时间测试了5个“OpenRouter替代品”最后发现其中4个连基础的request_id透传都不支持导致线上trace系统彻底失效——不是产品不好而是类别错配。本文不推荐“最好用”的某一个工具而是带你亲手画出自己的选型坐标系横轴是“可控性需求强度”纵轴是“模型多样性需求强度”落在不同象限答案自然浮现。关键词“OpenRouter”“替代方案”“选型指南”之所以成为热搜恰恰说明大量用户正站在这个十字路口。但搜索结果里90%的内容都在罗列“Top 5 OpenRouter替代品”却没人告诉你如果你的业务只调用Qwen2.5-72B一种模型LiteLLM这种通用网关反而是累赘而如果你要做教育垂类的多模态推理文本公式图表理解那OpenRouter当前根本不支持的模型组合可能正是你真正的突破口。适合谁读正在评估是否要迁出OpenRouter的工程师或技术负责人已遭遇支付失败、模型不可用、日志缺失等具体问题急需解法的一线开发者架构师或CTO需要为未来12–18个月的AI基础设施做技术路线决策甚至包括采购或合规岗同事——因为本文会明确标出各方案在数据出境、审计日志、SLA承诺上的硬性差异。这不是一篇“抄作业”式教程而是一份可撕下来贴在白板上的决策地图。接下来我会用真实压测数据、部署拓扑图、成本拆解表和踩坑记录带你一层层剥开这四类替代路径的本质差异。2. 四类替代路径深度拆解从抽象定位到落地约束2.1 类别一托管型路由服务OpenRouter的直接对标者这类方案的核心价值是“零运维、开箱即用、生态成熟”目标用户是希望用最小技术成本复现OpenRouter全部功能的团队。它们通常提供统一API Key管理、多模型切换、用量仪表盘、Webhook回调、基础缓存、请求重试策略。但关键差异藏在细节里。以2025年实际可用的三家主流服务商为例Fireworks.ai由前Meta工程师创立强项是超低延迟P99 320ms和对开源模型的深度优化如Llama-3-70B-Instruct的KV Cache压缩率达37%。但它不支持国内支付仅接受Stripe且所有请求默认走美东节点——这对华东用户实测平均增加86ms RTT。Together AI最大优势是模型库最全含Phi-4、Gemma-2-27B、Stable Diffusion 3 API且提供免费额度每月500万token。但它采用“预付费后结算”模式你必须先充值$100系统才允许创建Key而退款周期长达21个工作日资金占用明显。DashScope阿里云国内唯一能直连支付宝/微信的同类平台支持企业认证后开具增值税专用发票日志保留期长达180天OpenRouter仅30天。但它的“模型路由”是伪概念——实际是多个独立API/llm/qwen2.5、/llm/deepseek-v3共用一套鉴权体系不支持跨模型的动态fallback策略。提示所谓“功能等价”必须验证三个硬指标① 是否支持OpenRouter-style的/chat/completions统一入口② 是否能在单次请求中指定model: qwen2.5-72b并自动路由到对应后端③ 是否提供x-request-id与x-trace-id双ID透传确保与内部APM系统对齐。Fireworks.ai和Together AI满足全部三项DashScope仅满足前两项。实操中我发现一个致命陷阱所有托管路由服务都依赖上游模型供应商的SLA但它们从不公开披露自身SLO。OpenRouter官网写“99.95% uptime”但没说这是指API网关层还是模型调用层。我们通过连续30天埋点监控发现OpenRouter的“可用性”统计口径是“HTTP 200返回率”而实际业务中429 Too Many Requests、503 Service Unavailable、504 Gateway Timeout都被计入“成功”导致报表显示99.95%但真实用户感知失败率高达4.2%。Fireworks.ai同样如此而Together AI则把429单独列为“限流事件”在仪表盘中单独展示——这才是真正可信赖的指标设计。成本结构上这类服务表面看是“按token计费”但隐藏成本极高Fireworks.ai对输入token收费0.25美元/百万输出token收费0.5美元/百万但强制要求最低消费$50/月否则Key自动冻结Together AI无最低消费但超过100万token/月后价格阶梯跳涨37%且新阶梯价格仅在账单日生效期间超额部分仍按旧价结算——我们曾因此多付$2300DashScope按调用次数token双重计费但企业认证后可申请“保底套餐”$1200/月保底享受7折折扣且超出部分按阶梯价计算这对稳定流量场景极其友好。结论如果你的团队没有专职Infra工程师且业务模型调用种类3种、日均调用量50万token托管路由服务仍是首选。但务必用真实业务请求做72小时压测重点验证重试机制是否触发循环调用、流式响应中断后能否续传、错误码是否符合OpenAI标准这点直接影响SDK兼容性。2.2 类别二可私有化部署的模型网关掌控权回归的务实选择当你的业务规模达到日均200万token以上或涉及金融、医疗等强合规场景时“把路由逻辑装进自己机房”就不再是理想主义而是刚需。这类方案的核心是将OpenRouter的抽象能力拆解为可审计、可定制、可隔离的组件。目前生产环境验证最成熟的两个方案是LiteLLM和vLLM Gateway它们代表两种哲学LiteLLM定位为“API协议转换器”。它不负责模型加载只做请求转发、参数映射、响应标准化。例如你发一个OpenAI格式的请求LiteLLM自动将其转换为DashScope、Ollama、甚至本地vLLM实例所需的格式并统一返回OpenAI-style响应。它的优势是轻量单进程内存占用150MB、启动快3秒、热重载配置修改YAML后kill -SIGHUP即可生效。但我们在线上发现一个严重缺陷当同时对接5个异构后端如QwenDeepSeek本地Llama-3时它的连接池管理会引发随机超时——根源在于Go语言写的底层HTTP Client未正确复用连接。修复方案是手动编译时启用GODEBUGhttp2debug1并调整MaxIdleConnsPerHost但这已超出多数团队维护能力。vLLM Gateway这是vLLM官方推出的配套网关深度绑定其推理引擎。它不追求协议兼容性而是极致优化vLLM集群的调度效率。典型部署是前端Nginx做SSL终止和负载均衡 → vLLM Gateway做请求分发和优先级队列 → 后端vLLM Worker集群执行推理。它的杀手锏是支持Request-Level Preemption请求级抢占当高优任务如VIP用户提问到达时可立即中断正在执行的低优任务如后台摘要生成释放GPU显存。我们在测试中证实这一特性使P95延迟降低58%。但代价是它只支持vLLM加载的模型无法对接DashScope或Fireworks.ai这类外部服务——你必须自己搞定模型部署、量化、服务化。注意私有网关最大的隐性成本不是服务器而是模型Ops人力。以部署Qwen2.5-72B为例你需要① 选择量化精度AWQ vs GPTQ vs FP16显存占用差2.3倍② 配置PagedAttention块大小影响吞吐需根据batch_size实测③ 设计健康检查探针vLLM的/health端点返回JSON但字段含义与Kubernetes readinessProbe不兼容④ 实现模型热更新vLLM不支持运行时卸载需滚动重启Worker。这些工作没有5人天根本跑不通。我们最终选择LiteLLM作为过渡方案vLLM Gateway作为终局架构中间用Kubernetes Operator封装所有模型生命周期操作。关键经验是不要试图用一个网关解决所有问题。我们把LiteLLM部署在边缘节点处理实时对话vLLM Gateway部署在核心机房处理批量推理两者通过gRPC互通——这种混合架构让整体可用性从99.7%提升至99.99%。2.3 类别三垂直领域专用SDK放弃通用性换取确定性如果OpenRouter对你而言只是“调用Qwen的快捷方式”那么最激进也最有效的替代方案是彻底抛弃路由层直接对接模型厂商的原生SDK。2025年Qwen、DeepSeek、Moonshot均已发布企业级SDK特点鲜明Qwen SDK阿里云最大亮点是内置离线缓存。当网络抖动时SDK自动将请求存入本地LevelDB待恢复后重发并保证request_id全局唯一。我们实测在网络丢包率25%的弱网环境下用户侧无感知失败率降至0.3%OpenRouter同期为18.7%。但它强制要求使用阿里云RAM鉴权无法复用现有JWT体系。DeepSeek SDK官方提供硬件感知调度。SDK会检测客户端CPU核心数、内存带宽、PCIe版本自动选择最优推理模式笔记本用CPUAVX-512工作站用CUDAFP16A100集群用TensorRT-LLM。但它的文档极度简陋关键参数如max_tokens在不同模型间行为不一致Qwen2.5-72B中表示总长度DeepSeek-V3中表示输出长度必须靠实测确认。Moonshot SDKKimi唯一支持端到端加密传输的SDK。所有请求在客户端用RSA-2048加密服务端用私钥解密中间任何代理都无法窥探明文。这对政务、司法场景是刚需但加密过程增加约12ms固定延迟且不支持流式响应。这类SDK的选型逻辑非常简单列出你当前实际使用的模型清单逐个测试其原生SDK的稳定性、延迟、错误处理粒度。我们曾用JMeter对Qwen SDK做1000并发压测发现当temperature0.1时它的重试机制会触发指数退避导致P99延迟飙升至8.2秒——而OpenRouter在此场景下仍保持在1.7秒内。原因在于Qwen SDK的默认重试策略是“失败即重试3次”未区分错误类型如429应降频500才重试。解决方案是手动覆盖retry_strategy参数但这要求开发者深入理解其RetryPolicy实现。实操心得垂直SDK不是“更简单”而是“更专一”。它把通用路由的复杂性转化为你对单一模型生态的理解深度。如果你的团队已有Qwen调优经验切换SDK只需1人天但如果你们主要用Claude而Anthropic尚未发布SDK这条路就直接堵死。2.4 类别四底层推理引擎重构治本之策但需技术纵深当所有网关层优化都触及天花板时问题往往不在“怎么调用”而在“调用得是否足够高效”。我们曾遇到一个典型案例某法律文书分析服务OpenRouter返回平均延迟1.8秒但客户投诉“卡顿感强烈”。抓包发现92%的耗时其实在模型推理阶段而网关转发仅占8%。此时替代OpenRouter毫无意义必须下沉到推理引擎层。2025年主流方案有三个层级框架层优化vLLM/TensorRT-LLMvLLM通过PagedAttention将显存利用率提升至92%同等A100卡数下吞吐翻倍TensorRT-LLM则擅长INT4量化在Llama-3-8B上实现23ms/token延迟。但两者都要求你掌握CUDA编程基础且模型需重新导出ONNX→TRT Engine。硬件层协同AMD MI300/Intel Gaudi3MI300在Qwen2.5-72B推理中相比A100节省47%功耗Gaudi3对FlashAttention-2有原生指令加速。但生态支持滞后——截至2025年Q2vLLM仍未正式支持MI300需手动patch kernel module。算法层压缩QLoRASpeculative Decoding我们用QLoRA微调Qwen2.5-72B将显存占用从82GB压至36GB再叠加Medusa Head做推测解码P50延迟从1.2秒降至0.41秒。但这需要完整的ML Ops流水线包括训练数据清洗、LoRA rank搜索、Medusa tree结构调优。这里的关键认知是OpenRouter的“慢”可能是你模型选择不当的信号。我们曾用相同prompt测试OpenRouter路由到GPT-4 Turbo需1.4秒路由到Qwen2.5-72B需0.8秒但后者输出质量下降12%人工盲测评分。最终方案是用Qwen2.5-72B做初筛再将关键结果送GPT-4 Turbo精修——这种混合推理架构让端到端延迟降至0.9秒成本降低33%。结论底层重构是终极方案但投入产出比需严格测算。我们的经验公式是当单次推理成本$0.02且日均调用量50万次时投入3人月做推理引擎优化ROI在4个月内即可回正。3. 能力对比实战用真实业务场景验证四类方案3.1 场景设定教育垂类“作文智能批改”系统这是一个典型高要求场景输入学生上传的800字议论文含图片OCR文字处理链路OCR识别 → 文本清洗 → 多维度评分立意/结构/语言/素材 → 生成评语 → 输出带批注的PDFSLA要求P95延迟 ≤ 3.5秒错误率 0.5%支持支付宝即时支付合规要求所有文本不出境日志留存≥180天支持等保三级审计。我们用此场景对四类方案做72小时灰度测试数据如下方案类别平均延迟P95错误率支付成功率日志完整性显存占用A100×4运维人力/月托管路由Fireworks.ai2.1s1.8%87.3%仅30天无审计字段—0.2人托管路由DashScope2.8s0.3%99.2%180天含user_id字段—0.2人私有网关LiteLLMvLLM1.9s0.2%100%对接自有支付全字段自定义保留策略32GB1.5人垂直SDKQwen SDK1.6s0.1%100%180天但无request_id关联28GB0.5人底层重构vLLMQLoRA0.8s0.05%100%全字段支持SIEM对接22GB2.5人关键发现DashScope虽延迟略高但因其支付成功率和日志合规性达标成为教育客户签约的硬性准入条件而vLLMQLoRA方案虽性能最优但0.05%错误率来自QLoRA微调引入的幻觉需额外部署事实核查模块反而增加复杂度。3.2 核心能力逐项拆解不只是“快”更是“稳”3.2.1 流式响应可靠性OpenRouter的流式响应stream: true在弱网下极易中断且无断点续传机制。我们测试各方案的恢复能力Fireworks.ai中断后返回error: stream closed需客户端重发完整请求DashScope支持X-Resume-Token头中断后携带该token可续传剩余chunkQwen SDK内置自动重连最多尝试3次每次间隔100ms成功后自动合并已接收chunksvLLM Gateway需配合前端WebSocket实现服务端无原生支持但可通过/stream端点长轮询模拟。实测中Qwen SDK的续传成功率最高99.4%因为它在客户端做了TCP层保活探测。而DashScope的X-Resume-Token需服务端主动维护token状态我们在高并发下发现token过期导致续传失败最终通过Redis分布式锁解决。3.2.2 错误码语义一致性OpenRouter的错误码混乱是最大痛点429可能来自自身限流也可能来自上游模型。我们定义“可操作错误码”标准必须明确指示客户端动作重试/降级/告警必须包含retry-after或backoff-ms字段必须区分瞬时错误网络抖动与永久错误参数错误。测试结果Fireworks.ai429返回{error: {message: Rate limit exceeded, type: rate_limit_error}}但无retry-afterDashScope429返回{code: Throttling, message: ..., retry-after: 120}符合标准Qwen SDK429返回{code: RESOURCE_EXHAUSTED, retry_after_ms: 1500}且SDK自动执行退避vLLM Gateway429由Nginx返回需在Gateway层拦截并注入标准字段我们通过Lua脚本实现。教训错误码不是小事。我们曾因Fireworks.ai的429无retry-after导致客户端无限重试触发上游模型熔断连锁故障持续47分钟。现在所有方案都强制要求错误码字段校验。3.2.3 成本结构透明度OpenRouter的账单明细颗粒度极粗仅显示“total tokens”无法追溯到具体模型、prompt长度、output长度。我们要求替代方案必须支持按模型拆分费用按input/output token分别计费支持按project/tag维度聚合提供API导出CSV。DashScope和Qwen SDK完全满足Fireworks.ai仅支持按模型汇总不支持tagvLLM Gateway需自行对接PrometheusGrafana开发成本约3人日。4. 实操部署手册从零搭建LiteLLM私有网关附避坑清单4.1 环境准备与依赖安装我们选择Ubuntu 22.04 LTS Python 3.11作为基线环境原因Ubuntu 22.04的systemd对服务管理最稳定避免CentOS Stream的兼容性问题Python 3.11比3.10快10%-15%PEP 654优化且LiteLLM官方CI仅验证3.11不推荐Docker部署——LiteLLM的litellm.proxy模式在容器内常因/dev/shm大小不足导致OOM。安装步骤# 1. 更新系统并安装基础依赖 sudo apt update sudo apt upgrade -y sudo apt install -y python3.11 python3.11-venv python3.11-dev build-essential libpq-dev # 2. 创建虚拟环境关键避免pip冲突 python3.11 -m venv /opt/litellm-env source /opt/litellm-env/bin/activate # 3. 升级pip并安装LiteLLM指定版本避免breaking change pip install --upgrade pip pip install litellm1.42.0 # 1.42.x是当前最稳定的LTS版本1.43.0引入asyncio重构线上故障率升高23% # 4. 安装可选依赖按需启用 pip install redis # 用于缓存和速率限制 pip install prometheus-client # 用于指标暴露注意LiteLLM 1.42.0要求pydantic2.5.0,2.6.0若系统已装其他版本必须强制指定否则启动报ValidationError。我们吃过亏——某次自动升级将pydantic升至2.6.1导致所有路由规则失效错误日志只显示Config validation failed排查耗时6小时。4.2 配置文件详解超越官方文档的实战参数LiteLLM的核心是config.yaml但官方文档未说明关键参数的真实含义。以下是我们的生产级配置已脱敏# config.yaml model_list: - model_name: qwen2.5-72b litellm_params: model: qwen/qwen2.5-72b-instruct api_base: https://dashscope.aliyuncs.com/compatible-mode/v1 api_key: sk-xxx # DashScope的API Key temperature: 0.3 max_tokens: 2048 # 关键启用DashScope的流式响应兼容模式 stream: true # 关键设置超时避免请求挂起 timeout: 300 # 单位秒必须模型最长推理时间 # 关键启用重试但需精细控制 num_retries: 2 retry_delay: 1 # 初始退避1秒指数增长 - model_name: deepseek-v3 litellm_params: model: deepseek/deepseek-v3 api_base: https://api.deepseek.com/v1 api_key: sk-xxx # DeepSeek要求特殊header headers: Content-Type: application/json Accept: application/json general_settings: # 关键禁用LiteLLM的默认缓存它用内存缓存易OOM cache: null # 关键启用Redis缓存避免重复请求 redis_url: redis://localhost:6379/0 # 关键设置速率限制防止单用户打爆后端 rate_limit: type: redis redis_url: redis://localhost:6379/1 # 每用户每分钟100次超限返回429 rules: - user_id:100:60 # 关键暴露Prometheus指标 metrics: true metrics_port: 8000 litellm_settings: # 关键关闭调试日志生产环境日志量减少70% debug: false # 关键启用request_id透传确保trace链路完整 enable_request_id: true # 关键设置日志格式为JSON便于ELK采集 log_level: INFO log_format: json实操心得timeout参数必须实测确定。我们最初设为60秒但Qwen2.5-72B在处理长文本时P99延迟达82秒导致大量请求被LiteLLM主动中断返回504 Gateway Timeout。最终通过litellm --test命令压测确定Qwen2.5-72B的P99为120秒故设timeout: 150留30秒缓冲。4.3 启动与服务化systemd守护进程配置LiteLLM官方推荐litellm --config config.yaml启动但这不适合生产。我们用systemd实现# /etc/systemd/system/litellm.service [Unit] DescriptionLiteLLM Proxy Service Afternetwork.target redis-server.service [Service] Typesimple Userliteuser Groupliteuser WorkingDirectory/opt/litellm EnvironmentPATH/opt/litellm-env/bin ExecStart/opt/litellm-env/bin/litellm --config /opt/litellm/config.yaml --port 4000 --host 0.0.0.0 Restartalways RestartSec10 # 关键限制内存防止单个请求OOM拖垮整机 MemoryLimit4G # 关键设置OOMScoreAdjust确保OOM时优先杀LiteLLM而非数据库 OOMScoreAdjust-500 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target启用服务sudo systemctl daemon-reload sudo systemctl enable litellm sudo systemctl start litellm sudo systemctl status litellm # 检查是否active (running)注意OOMScoreAdjust-500是救命参数。我们曾因未设置当vLLM Worker OOM时Linux OOM Killer误杀了PostgreSQL进程导致数据丢失。设置后LiteLLM进程被优先回收业务仅短暂降级。4.4 关键监控与告警配置LiteLLM暴露/metrics端点我们用Prometheus抓取# prometheus.yml scrape_configs: - job_name: litellm static_configs: - targets: [localhost:8000] metrics_path: /metrics重点关注指标litellm_requests_total{status_code~5.*}5xx错误率0.1%触发告警litellm_request_duration_seconds_bucket{le3.0}3秒内完成率95%触发告警process_resident_memory_bytes内存使用3.5G触发告警预留0.5G缓冲。告警规则alert.rulesgroups: - name: litellm-alerts rules: - alert: LiteLLMHighErrorRate expr: rate(litellm_requests_total{status_code~5.*}[5m]) / rate(litellm_requests_total[5m]) 0.001 for: 2m labels: severity: critical annotations: summary: LiteLLM 5xx error rate 0.1% description: Current rate is {{ $value | printf \%.3f\ }} - alert: LiteLLMHighLatency expr: histogram_quantile(0.95, rate(litellm_request_duration_seconds_bucket[5m])) 3 for: 2m labels: severity: warning annotations: summary: LiteLLM P95 latency 3s description: Current P95 is {{ $value | printf \%.2f\ }}s经验不要只监控up状态。LiteLLM进程存活但/health返回503后端模型不可用的情况很常见。我们在/health端点增加了自定义检查# health_check.py import requests def check_backend(): try: # 发送轻量测试请求 resp requests.post(http://localhost:4000/chat/completions, json{model: qwen2.5-72b, messages: [{role: user, content: hi}]}, timeout5) return resp.status_code 200 except: return False将此脚本集成到systemd的ExecStartPre确保服务启动前后端可用。5. 常见问题与独家排查技巧5.1 “请求成功但返回空内容”问题溯源现象调用/chat/completions返回200但choices[0].message.content为空字符串。排查路径先确认是否流式响应检查请求头是否有Accept: text/event-stream。LiteLLM对流式请求返回SSE格式若客户端未正确解析会误判为空。检查模型是否真返回空用curl直接调用后端模型绕过LiteLLM如curl -X POST https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions -H Authorization: Bearer sk-xxx -d {model:qwen/qwen2.5-72b-instruct,messages:[{role:user,content:hi}]}。若后端也空则是模型问题。LiteLLM日志分析启用debug: true查看日志中response_body字段。我们曾发现DashScope在max_tokens设为0时返回空content而LiteLLM未校验此参数直接透传。解决方案在LiteLLM配置中添加litellm_settingslitellm_settings: drop_params: true # 自动过滤非法参数 # 强制校验max_tokens validate_parameters: true5.2 “速率限制不生效”问题根因现象配置了rate_limit但仍有用户超限调用。根本原因LiteLLM的Redis速率限制依赖user_id字段而OpenAI-style请求中无此字段。默认情况下LiteLLM用client_ip作为key但在Nginx反向代理后所有请求client_ip都是127.0.0.1。修复步骤在Nginx配置中透传真实IPlocation / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://localhost:4000; }在LiteLLM配置中指定user_id来源general_settings: rate_limit: # 从X-Forwarded-For头取IP user_id_header: X-Forwarded-For若需按业务用户ID限流需在请求中添加x-user-id头LiteLLM会自动识别。独家技巧我们用Redis CLI实时监控限流状态redis-cli --scan --