最近 OpenRouter 平台上线了一个新的推理服务商名字叫 Makora。做过多模型聚合调用的人应该都清楚OpenRouter 上多一家服务商不是简单的“模型列表变长了”而是意味着你在模型选型时又多了一个后端、一个定价维度以及一类延迟表现。这篇文章会从 OpenRouter 的实际用法出发把“新推理服务商上线后怎么用起来”这件事讲清楚包括如何发现和筛选新上线的服务商、如何用标准 OpenAI 兼容接口调用、如何把这类服务商接入 Claude Code、Dify 等现有工具以及 429 限流、模型列表里找不到模型这些高频问题怎么处理。如果你平时已经在用 OpenRouter 做多模型调用这篇文章可以直接收藏如果你只是刚注册账号想搞懂 OpenRouter 怎么用、API Key 怎么创建、怎么把推理服务商接到自己的代码里也能照着把基础流程跑通。内容以通用工程流程为主具体定价、额度、模型清单和区域可用性都以你打开 OpenRouter 时实际看到的信息为准。1. 核心能力速览项目说明事件OpenRouter 平台上线 Makora 推理服务商平台定位OpenRouter聚合多家模型提供方的统一 API 网关核心价值统一接口、模型路由、统一计费、多服务商切换API 兼容性OpenRouter 提供 OpenAI 兼容接口可用 OpenAI SDK 或 requests 调用调用方式HTTPS API路径符合/api/v1/chat/completions等规范新服务商的意义增加模型后端选择可对比成本、延迟与稳定性适合人群需要多模型调用、成本对比、工具接入的开发者前置条件能正常访问 OpenRouter、有账号和 API Key注意事项各服务商模型可用性、定价、区域网络表现需实时查看这里要先说清楚一个基本概念OpenRouter 本身不做模型训练它更像一个模型网关。各家推理服务商把模型接入平台后OpenRouter 负责把用户请求转发到对应后端再把结果统一返回给调用方。所以 Makora 作为新服务商上线实际含义是OpenRouter 的可用模型池里新增了来自该服务商的模型你可以通过 OpenRouter 的同一个 API 去调用它而不用单独注册它的原始平台。从工程角度看这个架构有三个直接好处。第一调用端只需要维护一套接口规范模型厂商的差异被挡在网关后面。第二计费被统一了你不需要在多个服务商之间分别充值、分别统计消费。第三可以做路由和降级一个服务商不稳定时可以在网关层快速切换。这三个点在 Makora 这类新服务商上线后尤其有用因为你可以非常快地把它拉进对比池里做测试。2. 适用场景与使用边界2.1 适合场景从 OpenRouter 的设计目标来看这类聚合平台重点解决三个问题模型选择困难不同服务商的模型能力、价格、上下文长度都不一样靠人工逐个维护成本太高。接口碎片化不同厂商给不同 SDK每接入一个服务商就要重新写一段请求逻辑。故障转移一个服务商不可用时可以在网关层面切换到备选。Makora 上线以后你可以在 OpenRouter 的模型列表里找到它提供的模型然后做同一组输入、同一组参数下的横向对比。这个“横向对比”能力很重要因为它直接影响成本决策同样是处理一批文本A 服务商可能延迟低但价格高B 服务商可能便宜但输出质量一般。没有统一网关时做这种对比要写多套调用代码现在一次 API 调用就能切换。2.2 不适合场景聚合 API 也不是万能的。如果你需要私有化部署、数据完全不出内网那么云端的聚合 API 并不适合因为请求必然经过 OpenRouter 转发。如果你的业务对最低时延有硬性要求跨区域公网转发不一定比直连厂商更稳。如果只是偶尔调用一次可能不值得先充一大笔钱先用小额度测试更稳妥。2.3 合规与安全边界使用任何第三方推理服务商都要注意几个边界输入数据可能经过平台转发涉及敏感业务数据前先评估脱敏方案和隐私政策。要确认服务商对生成内容的版权、使用要约是否清晰。不要用真实个人信息、他人肖像、版权文本去做无授权测试。如果业务要求内容审核、合规留痕还要结合自身业务规范做复审。新服务商上线的早期文档和模型行为描述不一定完整。遇到信息不明确的地方宁可先小规模测试也不要直接把生产流量切过去。3. 环境准备与前置条件虽然 OpenRouter 是 API 服务不涉及本地显卡、CUDA 和模型文件但正式开始前仍要做一轮环境清单检查。项目建议网络能稳定访问 OpenRouter API不同网络环境下连通性和时延差异较大请按实际测试为准账号注册 OpenRouter 账号完成邮箱等验证API Key在后台创建 API Key并保存好余额新账号可能有一定测试额度具体以平台为准正式测试前建议先确认余额开发环境Python 3.8、curl、Postman 或任意 HTTP 调试工具工具链可选Claude Code、Dify、cc-switch、one-api 等注意一点OpenRouter 的模型调用是在云端完成的本机不需要 GPU、显存、显卡驱动。这也是它和本地部署模型最大的区别。你想要测试推理延迟关注的是网络 RTT、服务商排队情况和模型生成速度而不是本地显存占用。“OpenRouter 国内能用吗”这类问题的答案取决于你的实际网络出口到 OpenRouter API 的连通性。有的网络环境访问正常有的则可能因为网络波动出现超时、429、连接不上等情况。更稳妥的判断方式是先通过 curl 或网页控制台做一次连通性测试再决定是否投入正式业务。不要把别人的网络表现直接当成你的网络表现。4. 启动与接入思路OpenRouter 没有本地启动器它本身就是远程服务。所谓“启动”对应的是这样几个步骤打开 OpenRouter 页面登录。在 Model 或 Providers 区域查找 Makora 以及它提供的模型。创建 API Key。通过 curl / SDK 发起第一次请求。4.1 生成 API Key在 OpenRouter 控制台创建 API Key一般步骤是进入 Keys 页面创建新 Key设置权限和用途然后保存。创建完成后把 Key 放到环境变量里避免写死在代码中。export OPENROUTER_API_KEYsk-or-v1-xxxxxx注意API Key 通常在创建时完整展示一次后续再打开只能看到脱敏信息。忘记完整内容就重新创建一个旧 Key 可以撤销。4.2 查看模型列表请求模型列表接口可以看到当前 OpenRouter 可用的模型以及包括 Makora 在内的服务商信息curl https://openrouter.ai/api/v1/models \ -H Authorization: Bearer $OPENROUTER_API_KEY | jq .data[].id如果 jq 没安装可以去掉| jq...直接看 JSON。正常响应里会包含大量模型 ID通常采用“服务商/模型名”的格式。你可以在返回结果里搜索makora关键词确认该服务商是否有模型、是否处于上线状态。如果确实搜不到可能说明该服务商的模型没有对当前账号开放或者还没正式上架到模型列表。4.3 第一次 Chat 请求用 curl 发一个简单的对话请求curl https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d { model: makora/具体模型ID, messages: [ {role: user, content: 用一句话介绍 OpenRouter} ] }这里makora/具体模型ID需要替换成实际模型 ID。如果模型 ID 不对接口会返回模型不存在或不可用的错误此时去模型列表里确认准确 ID。需要特别提醒的是不要照抄网络上的旧模型 ID。聚合平台上的模型 ID 会随时更新新服务商刚上线时ID 也可能在短时间内调整。一切以/api/v1/models返回值为准。4.4 在 Dify / 自定义应用中配置如果你在使用 Dify 这类 LLM 应用平台通常会提供一个“OpenAI API 兼容”接入入口。这时你可以把 OpenRouter 当作一个兼容后端来配置API Base URL 填https://openrouter.ai/api/v1。API Key 填 OpenRouter 的 Key。模型名填 OpenRouter 上能查到的准确 ID。配置完成后先做一个最简单的对话测试确认应用平台能连通 OpenRouter再继续配置多轮对话、知识库或工作流。这里要强调一下Dify 的 Chatflow 是否支持多轮对话推理取决于 Dify 版本和你选择的模型是否支持消息历史传递不能只看 OpenRouter 这一侧。5. 功能测试与效果验证新服务商上线后建议按下面的测试矩阵快速验证而不是直接丢到生产环境。这样能更快发现模型不可用、接口不兼容、限流策略异常等问题。5.1 连通性测试目的确认 API 能通、Key 有效。操作调用/api/v1/models确认返回 200。用一个极短对话请求确认 Chat 接口可用。判断标准返回 JSON包含模型列表或正常文本响应。如果返回 401、403说明 Key 无效或权限不足。如果返回 429说明触发限流或额度不足。5.2 基础对话测试目的确认该服务商的模型能正常生成内容。操作用 curl 请求发送一句“你好”。观察返回内容是否完整、是否有明显延迟。设置max_tokens为较小值控制返回长度避免长文本等待。5.3 特殊参数测试OpenRouter 是 OpenAI 兼容接口常规参数和 OpenAI 大体一致{ model: 当前服务商模型ID, messages: [ {role: system, content: 你是一名测试助手}, {role: user, content: 请输出 3 个关于推理服务的建议} ], temperature: 0.7, max_tokens: 256, top_p: 0.9 }建议观察temperature、top_p是否被模型接受。平台是否返回参数说明或警告。返回的usage字段中 token 统计是否合理。不同服务商对相同参数的解释不一定一致同一个请求在不同服务商上的结果可能不同。跨服务商对比时尽量固定同一套参数这样对比才有意义。5.4 上下文长度测试目的验证模型在长文本场景下的表现。操作输入一段 2000 字左右的资料让模型做摘要。观察是否超出上下文限制。逐步增加文本长度找到模型可稳定处理的边界。判断标准如果提示词超过模型最大上下文接口通常返回参数错误。可以在模型详情里查看上下文参数。5.5 多轮对话和工具调用测试如果你的场景涉及 Agent 或多轮对话建议测连续多轮对话确认历史消息是否正常传递。Function Calling / Tool Calling 是否可用。在 Dify、Claude Code 等框架里是否正常工作。这类功能在聚合 API 上不是每个模型都支持。Makora 新服务商模型是否支持以平台模型详情页标注为准不要假设它一定具备完整的 Agent 能力。6. 接口 API 与批量任务6.1 为什么要在接口层做控制OpenRouter 这类网关模式天然适合做批量任务你只需要维护一套请求代码把模型名换成不同服务商的模型即可。但批量调用和单次调用不一样必须提前考虑限流、超时和重试。6.2 Python 批量调用示例下面给出一段通用 Python 示例可以用于批量发送推理请求import os import time import requests API_KEY os.getenv(OPENROUTER_API_KEY, ) API_URL https://openrouter.ai/api/v1/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } def call_model(prompt, model_id当前服务商模型ID, max_tokens256): payload { model: model_id, messages: [{role: user, content: prompt}], max_tokens: max_tokens } try: resp requests.post(API_URL, headersheaders, jsonpayload, timeout120) if resp.status_code 200: data resp.json() return data.get(choices, [{}])[0].get(message, {}).get(content, ) else: print(resp.status_code, resp.text) return None except Exception as exc: print(request error:, exc) return None tasks [ 总结 OpenRouter 的核心优势, 给出一个 API 降级测试方案, 解释什么是模型路由 ] for idx, task in enumerate(tasks, 1): result call_model(task) print(f任务 {idx}: {result}) time.sleep(1) # 控制频率降低限流概率这里没有使用 OpenAI SDK直接用 requests方便你复制到任意环境测试。如果你已经装了openaiSDK也可以把base_url指向 OpenRouter参数基本兼容。6.3 批量任务建议批量任务不要一把梭建议按以下思路做控制并发先 1 并发确认稳定后再逐步加。加入重试遇到 429、503 时做指数退避重试例如 1s、2s、4s。记录日志任务 ID、模型 ID、请求时间、返回码、token 消耗。设置预算批量任务前先估算 token 成本。import time def call_with_retry(prompt, model_id, retries3): for attempt in range(retries): result call_model(prompt, model_id) if result is not None: return result wait 2 ** attempt print(f第 {attempt 1} 次失败等待 {wait}s) time.sleep(wait) return None6.4 从接口层面筛选服务商OpenRouter 支持在请求中指定服务商或排除某些服务商。例如provider参数中的order、allow、disallow字段。具体字段以最新文档为准但思路是通用的想让请求优先走 Makora可以设置提供商排序。想避免某些不稳定服务商可以用排除列表。想降低成本可以按价格从低到高路由。这个能力很适合对比测试你可以在固定模型的前提下测试不同服务商返回结果的差异。6.5 用 OpenAI SDK 接入如果你用的是 OpenAI Python SDK可以像下面这样切换到 OpenRouterfrom openai import OpenAI client OpenAI( base_urlhttps://openrouter.ai/api/v1, api_keyos.getenv(OPENROUTER_API_KEY) ) response client.chat.completions.create( model当前服务商模型ID, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)SDK 的好处是已经封装了请求和响应解析适合直接嵌入到现有项目。缺点是你需要确认所用 SDK 版本与 OpenRouter 的兼容性特别是一些较新的 Agent 参数不同 SDK 版本差异较大。7. 资源占用与性能观察OpenRouter 是云 API本机资源占用很小。真正需要观察的是这三件事延迟、成本、稳定性。7.1 延迟一次请求的完整耗时由几个部分组成客户端到 OpenRouter 的网络 RTT。OpenRouter 到服务商的内部转发时间。模型排队和生成时间。返回内容的传输时间。测试时不要只看总耗时最好同时看time命令测出的总耗时。服务端返回中的usage字段。从请求发出到返回第一个 token 的耗时一般叫 TTFT。聚合 API 未必直接暴露这些字段但你可以用日志估算。7.2 成本计量聚合平台一般按 token 计费。对比服务商时不能只看单次价格还要看上下文长度输入越长成本越高。输出长度输出 token 是否受限。缓存命中平台是否提供 prompt caching 机制。限流同一价格下限流配置可能不同。建议做一个小表格记录服务商模型输入价格输出价格单次耗时质量评价7.3 稳定性稳定性不能通过一次请求判断。更稳妥的方式是连续跑 50 到 100 次请求统计失败率。在不同时间段测试观察高峰时段是否更容易 429。长时间跑批量任务观察是否有偶发超时。如果发现某个服务商在网络波动时表现得明显不稳定可以在路由层面把它调整为备选。7.4 token 用量的价值token 用量不仅是计费依据也是判断调用是否正常的依据。如果一个请求返回内容很短但usage显示消耗了大量 token说明提示词和系统指令占用了大量上下文如果返回报错但usage里有内容说明部分 token 已经被计费。批量任务里建议把每次请求的 usage 写入日志方便后续做成本归因。8. 常见问题与排查方法这里把 OpenRouter 使用中最常见的问题列成一个排查表问题现象可能原因排查方式解决方案请求返回 401/403API Key 无效、未设置或权限不足检查环境变量、重新创建 Key撤销旧 Key创建新 Key 并设置到环境变量请求返回 429触发限流、额度不足或账户未充值检查账户余额、查看限流响应头降低并发、增加重试、补充余额模型 ID 找不到模型 ID 写错、模型下线或未开放调用 /models 列表确认 ID使用列表中的准确 ID请求超时网络波动、服务商响应慢、长输出用 curl 单独测试分段排查增加超时时间、换模型、换网络再试返回内容为空或截断max_tokens 过小、模型逻辑异常检查 usage 字段和返回状态调整 max_tokens重新请求页面能打开但 API 不通网络环境对页面域名与 API 域名支持不同分别测试页面和 API 域名的连通性以 API 域名连通性为准判断充值失败或支付受限支付渠道不稳定、账户信息未完善查看平台支付提示联系客服按平台支持的支付方式操作保持账户信息准确在工具配置里找不到服务商模型工具缓存了旧模型列表、模型未在工具支持的列表里刷新工具配置手动填写模型 ID手动填入准确模型 ID或等待列表刷新8.1 429 限流再说明OpenRouter 429 是很多人都遇到过的错误。最常见的几个原因免费或低额度账户的配额较紧。同时发了大量并发请求。某个服务商自身也在限流。处理思路很简单在代码里统一封装重试逻辑。根据响应头里的Retry-After或错误信息调整等待时间。如果只是测试把并发改成 1逐条请求。不要一遇到 429 就认为是 OpenRouter 的问题。先看请求频率再看账户余额最后再看具体服务商的限流状态。8.2 模型列表里找不到服务商模型“为什么我在 OpenRouter 配置后找不到某个模型”这个问题通常不是配置错了而是模型 ID 不准确需要去/models接口刷新。模型暂未开放或仅对特定地区、特定账户开放。工具里缓存了旧的模型列表。处理方式是用/models接口直接搜索关键词拿到准确 ID 后手动配置。不要依赖网页页面上的模糊搜索接口返回的 JSON 是最新的。8.3 Claude Code / cc-switch 接入问题如果你想把 OpenRouter 上的模型接入 Claude Code常见做法是通过环境变量或配置工具指定自定义 Base URL 和 API Key。cc-switch 这类工具的价值在于可以集中管理多套 API 配置在 OpenAI 兼容接口、不同服务商之间快速切换。下面是一个通用配置思路Base URL 填https://openrouter.ai/api/v1。API Key 填 OpenRouter 的 Key。模型名填 OpenRouter 上能查到的准确 ID。不要把模型名写成不存在的名称。配置完成后先用最简单的对话确认连通性再逐步测试工具调用、多轮对话和文件处理等高级功能。如果配置后仍然报模型找不到优先刷新模型列表。8.4 网络连通性判断流程可以按这个流程做一次快速判断打开 OpenRouter 网页确认账号能登录。用 curl 请求https://openrouter.ai/api/v1/models确认 API 可访问。如果网页正常但 API 超时检查本地代理、防火墙和 DNS。如果 API 延迟高可以试着换一个网络出口再测试。如果请求返回 429优先看频率和余额。这个流程能帮你把“平台问题”和“本机网络问题”区分开避免在错误的方向上排查。9. 最佳实践与使用建议9.1 先小规模验证新服务商上线不要一上来就把生产流量切过去。先用 10 个以内请求验证基础能力再决定是否扩大测试。这里的“小规模”不仅指请求数量少也指单次请求的 token 量要小避免一次性消耗过多额度。9.2 固定一套基线 Prompt跨服务商对比时把所有测试 Prompt、参数、输出长度固定下来。否则对比结果很容易失真。建议整理一份独立的测试集包含简单问答、长文本摘要、代码生成、多轮对话这几类覆盖常见业务场景。9.3 把凭证和代码分离API Key 放环境变量或密钥管理服务里不要写进代码仓库。特别是团队协作时泄露 Key 会导致超额计费。如果发现 Key 泄露第一时间在控制台撤销并重建。9.4 建立批量任务的日志体系批量任务至少要记录请求 ID。模型 ID。时间戳。返回状态码。token 用量。失败原因。有了日志后续排错和成本复盘都会轻松很多。批量任务跑完之后还可以用日志里的 token 总量和平台账单对一下及时发现计费异常。9.5 设置预算和告警聚合平台的计费是实时累积的。建议在平台设置消费上限或提醒。在代码层统计 token 消耗及时发现异常。批量任务前先测一次单条成本再估算总成本。如果你是在团队里统一使用 OpenRouter最好让所有人都用同一个计量方式避免月底账单对不上。9.6 关注生成内容合规通过 OpenRouter 使用第三方模型生成内容仍然由开发者或企业负责落地审核。涉及人脸、声音、版权文本、用户数据的场景务必确认授权和合规边界。特别是做内容生成类产品时输出内容需要经过人工或规则审核后再对外发布。10. 总结与下一步这次 OpenRouter 上线 Makora 推理服务商给多模型调用带来的不是简单的“多了一个模型按钮”而是多了一个可以对比的推理后端。如果你是做模型选型、成本对比或工具接入的开发者最值得先做的一件事是登录 OpenRouter进入模型列表搜一下 Makora确认它提供的模型 ID 和支持能力然后用一个最小请求跑通。最容易踩的坑是模型 ID 写错、直接拿旧配置请求新服务商以及忽略限流和超时。下一步可以继续做三件事一是建立一套按服务商维度记录的测试表格把延迟、成本、质量分数沉淀下来二是把 OpenRouter 接到现有工具链比如 Claude Code、Dify 或自定义 Agent验证实际业务场景三是持续跟踪新服务商上线后的稳定性至少在切换生产流量前完成一轮批量压力测试。建议收藏备用等新服务商稳定后直接按这套流程验证。