先说清楚这篇文章的边界AiiOnly Token Plan 是一个按 token 计费的多模型接入方案Standard 档是其中一档套餐。它对外暴露的核心能力是用一套 API Key通过统一的 OpenAI 兼容接口去调用多个厂商的模型。这个“兼容 OpenAI 协议”的定位很关键因为它意味着我几乎不需要为每个模型单独写一套 SDK 适配代码只要换base_url和model名称就行。需要提前说明几点避免读者被误导我没有拿到 AiiOnly 内部的路由实现细节也不清楚它在后端如何做模型分发和计费这些我都不会编。12 款模型的具体清单会随平台调整本文不写死名单而是用变量管理。我实测的环境是 Python 3.11 PyCharm 2024.1openai库用的是 1.x 系列openai1.30。如果你用 0.x 版本的openai代码会不兼容因为 1.x 把ChatCompletion.create改成了client.chat.completions.create。这三点先摆出来后面的内容才有可信度。为什么要在 PyCharm 里做这件事我平时的主力 IDE 就是 PyCharm不太想为了试模型切到别的工具。而且我更关心的是“工程里怎么用”不是“网页聊天窗口里怎么问”。所以我要验证的是三件事这套接口能不能作为普通 Python 依赖被项目直接调用多个模型能不能共用一份客户端封装而不是每接一个模型就复制粘贴一遍在脚本、Web 服务、Agent 这三种典型形态下写法差异到底在哪。下面按这个顺序展开。先解决最底层的连接问题。环境准备与密钥配置PyCharm 里新建项目解释器选 3.11。装依赖pipinstallopenai1.30python-dotenv fastapi uvicornAgent 部分我后面用的是自己写的最小循环没有强依赖 LangChain但如果你想用 LangChain可以额外pip install langchain langchain-openai这一点我会在 Agent 小节里说明取舍。密钥不要写进代码。在项目根目录建.envAIIONLY_API_KEYsk-xxxxxxxxxxxxxxxx AIIONLY_BASE_URLhttps://your-aiionly-endpoint/v1AIIONLY_BASE_URL这里我故意写成占位符因为不同账号拿到的接入地址可能不同我不确定你的具体地址这一点我没有验证请以你控制台里显示的实际地址为准。唯一可以确定的是它需要是 OpenAI 兼容的/v1风格地址否则下面的代码要改。【注意】.env一定要加进.gitignore。我见过太多人把 key 提交上去了这不是小问题。第一层封装一个能换模型的客户端先别急着写业务先把“换模型”这件事抽象掉。核心思路是把所有模型的名字集中在一个配置文件里业务代码只认别名不认具体模型 ID。# config.pyimportosfromdotenvimportload_dotenv load_dotenv()API_KEYos.getenv(AIIONLY_API_KEY)BASE_URLos.getenv(AIIONLY_BASE_URL)# 别名 - 真实模型 ID 的映射# 具体 ID 请以你的控制台为准这里只是结构示例MODEL_MAP{fast:gpt-4o-mini,strong:gpt-4o,reason:claude-3-5-sonnet,cheap:deepseek-chat,# ... 其余模型按同样方式补全到 12 个}为什么用别名而不是直接用模型 ID因为在业务代码里写死gpt-4o之后一旦你想换成别的模型做对比就得全局搜索替换。用别名后改一行MODEL_MAP就够了。这是我做多模型项目最省事的一个习惯。然后是客户端封装# llm_client.pyfromopenaiimportOpenAIfromconfigimportAPI_KEY,BASE_URL,MODEL_MAP _clientOpenAI(api_keyAPI_KEY,base_urlBASE_URL)defchat(alias:str,messages:list,stream:boolFalse,**kwargs):model_idMODEL_MAP.get(alias,alias)return_client.chat.completions.create(modelmodel_id,messagesmessages,streamstream,**kwargs,)这里有几个设计判断值得说MODEL_MAP.get(alias, alias)的意思是如果你传的本来就是真实模型 ID也允许直接透传。这样调试时不用非得去配置里加一条。**kwargs保留透传能力比如temperature、max_tokens、top_p不同模型支持程度不一样交给调用方决定。客户端做成模块级单例。OpenAI客户端内部维护连接池每次调用都 new 一个会浪费连接也没必要。【关键结论】多模型接入的成本大头不在调用本身而在“统一抽象”。只要你把模型 ID 收敛到一个映射表里后面加第 13 个模型就是加一行配置的事。形态一批处理脚本最简单的形态就是脚本。假设我要用同一批 prompt 跑多个模型做对比代码大概长这样# run_compare.pyfromllm_clientimportchat PROMPT用一句话解释什么是向量数据库。defrun_one(alias:str)-str:respchat(alias,messages[{role:user,content:PROMPT}],temperature0.3,)returnresp.choices[0].message.contentif__name____main__:foraliasin[fast,strong,reason,cheap]:try:print(f[{alias}]{run_one(alias)})exceptExceptionase:print(f[{alias}] 调用失败:{e})这段代码里我特意加了 per-model 的 try/except。原因是多模型接入时不同模型对参数的容忍度不一样。有的模型不接受temperature0有的对超长 prompt 会直接报错。一个模型挂了不应该让整个批处理崩掉这是很实际的工程考虑。【踩坑提醒】不同模型对temperature的取值区间和默认值可能不同。你如果为了“公平对比”统一设成某个值最好先确认每个模型都接受这个值否则会收到参数校验错误。我遇到过有的模型只接受特定整数范围这一点具体到每个模型我没有逐一验证建议你跑之前先在单模型上试一下。形态二FastAPI 服务脚本跑通之后下一步是把它变成一个 HTTP 服务。用 FastAPI 是因为它轻、类型提示友好、异步支持好。# main.pyfromfastapiimportFastAPIfromfastapi.responsesimportStreamingResponsefrompydanticimportBaseModelfromllm_clientimportchat appFastAPI()classChatRequest(BaseModel):alias:strfastmessages:liststream:boolFalseapp.post(/chat)defdo_chat(req:ChatRequest):ifnotreq.stream:respchat(req.alias,req.messages,streamFalse)return{content:resp.choices[0].message.content}defgen():forchunkinchat(req.alias,req.messages,streamTrue):deltachunk.choices[0].delta.contentifdelta:yielddeltareturnStreamingResponse(gen(),media_typetext/plain)if__name____main__:importuvicorn uvicorn.run(app,host0.0.0.0,port8000)这里有两个点必须讲清楚流式输出的处理方式。OpenAI 兼容接口的流式返回是一串 chunk每个 chunk 的choices[0].delta.content可能是None比如第一个 chunk 通常只有 role最后一个 chunk 通常只有 finish_reason。直接yield会往客户端塞None所以要先判断。这个细节很多人第一次写流式接口都会忽略。同步还是异步。我上面用的是同步的def do_chat。因为openai1.x 同时提供了同步和异步客户端我这里用的是同步客户端所以路由函数用def而不是async def让 FastAPI 把它丢到线程池里执行避免阻塞事件循环。如果你要用AsyncOpenAI那路由函数才应该写成async def。【注意】不要用同步客户端配async def路由。那样会把整个事件循环卡住并发一上来服务就废了。这是异步框架里最常见的错误之一。启动服务uvicorn main:app--reload--port8000测试curl-XPOST http://localhost:8000/chat\-HContent-Type: application/json\-d{alias:fast,messages:[{role:user,content:你好}],stream:false}形态三Agent 循环Agent 形态和前面两种的本质区别是它需要多轮工具调用模型返回的不只是文本还可能是“我要调用某个工具”的指令。所以这里的关键是解析模型的 tool_calls 并回填结果。我没用 LangChain是因为这种最小循环自己写反而更清楚依赖也少。如果你要上 LangChainlangchain-openai里的ChatOpenAI也支持自定义base_url接入方式和上面一样只是封装层更厚。# agent.pyimportjsonfromllm_clientimportchat TOOLS[{type:function,function:{name:get_time,description:获取当前时间,parameters:{type:object,properties:{}},},}]defget_time():importdatetimereturndatetime.datetime.now().isoformat()TOOL_IMPL{get_time:get_time}defrun_agent(alias:str,user_input:str,max_turns:int5):messages[{role:user,content:user_input}]for_inrange(max_turns):respchat(alias,messages,toolsTOOLS)msgresp.choices[0].message messages.append(msg)ifnotmsg.tool_calls:returnmsg.contentfortcinmsg.tool_calls:fnTOOL_IMPL.get(tc.function.name)resultfn()iffnelsef未知工具:{tc.function.name}messages.append({role:tool,tool_call_id:tc.id,content:json.dumps(result,ensure_asciiFalse),})return达到最大轮数仍未结束这段代码里最关键的一行是messages.append(msg)。模型的 tool_calls 响应必须原样塞回消息历史里否则下一轮请求会因为缺少对应tool_call_id的上下文而报错。这个规则来自 OpenAI 的 function calling 协议很多兼容实现也遵守它。【踩坑提醒】不是所有模型都支持 function calling。我把 12 款模型接进来的时候其中一部分只支持纯文本对话传tools参数会直接报错或者被忽略。所以如果你的 Agent 要跑在多个模型上得先确认哪些模型支持工具调用——这一点具体到每个模型的兼容性我没有全部验证请在控制台的模型说明里确认。三种形态的对比形态优点缺点适用场景脚本上手快、调试方便、无额外依赖无法并发、无状态管理批量跑 prompt、模型效果对比FastAPI 服务可并发、易集成、支持流式需管理服务进程、要处理超时重试给前端或其他服务提供统一入口Agent 循环能多轮工具调用、可完成复杂任务依赖模型 function calling 支持、轮数难控需要调用外部工具的自动化任务实际遇到的问题问题一模型名对不上。我一开始以为映射表里的 ID 可以直接照抄文档结果发现部分模型的可用 ID 和控制台显示的名字不完全一致。解决办法是直接用别名透传能力去单测确认哪个 ID 能通再写进映射表。问题二超时和重试。多模型接入时不同模型的响应速度差异很大。openai客户端默认有超时设置但如果你不显式配置某些慢模型会直接超时。我在客户端构造时加了timeout参数_clientOpenAI(api_keyAPI_KEY,base_urlBASE_URL,timeout60.0)60 秒是个经验值不是官方推荐值具体设多少要看你的模型和 prompt 长度。问题三计费不透明。Standard 档是按 token 计费的但我没办法在代码里实时看到某个请求花了多少 token。好在 OpenAI 兼容接口的响应里通常带usage字段respchat(fast,messages[{role:user,content:hi}])print(resp.usage.prompt_tokens,resp.usage.completion_tokens)能不能拿到取决于服务端是否返回这个字段我这边实测部分模型返回了部分没有这一点我没有逐个确认。我对这套方案的整体判断AiiOnly Token Plan 的 Standard 档本质上是一个“多模型网关”。它的价值不在于模型本身有多强而在于把多厂商的接入成本压到了一个 API Key 一个 base_url。对于我这种想在项目里横向对比多个模型、又不想维护 12 套 SDK 的场景这个定位是合适的。但有几个前提你必须接受你依赖的是 OpenAI 兼容协议。协议之外的模型特性比如某些厂商独有的参数可能用不了。你无法控制路由策略。同一个别名背后具体走哪个模型、有没有降级取决于平台实现我不清楚它的细节。计费和限流是黑盒。你能看到的是 usage看不到的是它怎么算的。如果你只是想在 PyCharm 里快速试几个模型Standard 档够用。如果你要做生产级的多模型容灾、成本控制那你需要自己在应用层再做一层路由和降级——这一点无论用哪个网关都成立。最后留个问题当你有 12 个模型可选时真正的难点已经不是“怎么调通”而是“怎么决定哪个请求该走哪个模型”。这属于应用层策略网关帮不了你只能自己设计。
