多模型

10 月 9 日的行业新闻里有个容易被忽略的细节：谷歌在发布 Gemini 企业智能体的同时，把 Anthropic 的 Claude Opus 5 与 Sonnet 5.5 集成进了 Gemini Business，而 Antigravity CLI 这个命令行编码工具，成了这套多模型智能体的主要入口。也就是说，你可以在同一个终端里，让 Gemini 负责规划、Claude 负责写代码，而不用在两个工具间倒腾。对每天写代码的人，这是值得当晚就试的东西。 CLI 怎么装、怎么登录鉴权？ 先装 CLI，再用谷歌云账号登录鉴权。关键一步是在配置里勾选允许调用第三方模型——默认只走自家模型，要手动打开 Claude 模型开关。鉴权后用一个空目录启动，它会自动扫描项目结构、读说明文档，生成一份初始任务理解。第一次跑建议挑一个干净的小仓库，别直接拿生产大仓上来试。 第一条任务该怎么下才稳妥？ 别一上来让它「重构整个项目」。先下一个边界清晰的小任务，例如给某个脚本加日志并写两个单测。观察它怎么拆步骤、在不同模型之间怎么分工——通常规划和读代码走一家，生成代码走另一家。你可以在对话里随时说「这段用 Opus 5 重写」来手动切换模型，这种按片段指定模型的自由度，是单一编码工具给不了的。 多角色交接有哪两个坑？ 第一，CLI 默认会读取并上传仓库里的文件到对应模型后端，涉密项目先在配置里把工作目录限定在子文件夹，避免把无关密钥文件带进上下文。第二，多模型串联时，各家的上下文是各自维护的，上一步的分析不会自动喂给下一步，重要结论要显式复述或写进共享文件，否则模型间会「失忆」。 这套多模型终端值不值得今晚试？ Antigravity CLI 的意义不在「又一个编码智能体」，而在于它把「按任务选模型」做成了默认。对开发者来说，今晚就能做的事：建个干净分支，让它跑一个小重构，顺便看看多模型分工到底省不省时间——比读十篇评测都直观。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：AntigravityCLI

做 AI 应用最烦的一个现实是：某家模型半夜抽风，你的服务就挂。如果代码里只写死一个供应商，故障时只能干等。OpenRouter 的思路是把上百个模型聚到一个网关后面，对外仍是 OpenAI 协议——你只换模型名，不用改代码。它真正值钱的不是「模型多」，而是容灾与路由这两件事。 两件值得做的事 第一，fallback 链。应用里不要只配一个模型 id，而是配一个降级序列：首选 GPT-6 级别的模型，超时或报错就自动切到 DeepSeek，再不行切到本地小模型。因为走的是同一套协议，客户端几乎无感。 第二，按任务选档位。分类、打标签这种简单任务，故意路由到便宜模型；写文案、做推理才走贵的。OpenRouter 的模型列表里价格标注得很清楚，你可以在网关层按请求类型做分流。 一个必须知道的坑 数据会经过 OpenRouter 这一层中转。涉及客户隐私、合同、未公开财务数据的请求，别把敏感原文直接发给经过第三方路由的接口。这类流量要么走供应商直连，要么走你自己的 LiteLLM 网关。便利和合规，永远要自己权衡。 判断 OpenRouter 这类聚合层的价值，在模型价格战的 2026 年被放大了——谁家便宜、谁家稳定，随时可能变。把多模型路由做成一层可配置的策略，而不是写死在代码里，是应用韧性的一部分。但记住它是中立的管道，不是你数据的保险箱。 补充一个成本细节：聚合层的价格有时和官价有偏差，促销或缓存命中价不一定同步。月底对账时，拿 OpenRouter 的账单和你预估的 token 量对一遍，尤其当你同时开了 fallback——某家故障时流量切到贵的那家，账单会比预期高，提前知道才不会措手不及。 把路由做成可配置的策略，而不是写死的代码，应用的韧性才立得住；谁便宜、谁稳定，随时可能变，策略层替你接住这些变化。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：OpenRouter

一个团队做 AI 应用，半年下来手里往往攥着七八把 API key：OpenAI 的、Anthropic 的、DeepSeek 的、智谱的、还有本地 llama.cpp 的。每接一家，代码里就多一套字段名、一套错误码、一套计费口径。LiteLLM 要解决的就是这个：它对外只暴露 OpenAI 兼容协议，对内把各家模型翻译成同一套调用格式。 它到底统一了什么 一套 SDK：代码里只写 client.chat.completions.create(...)，模型名写成 deepseek/deepseek-chat、gemini/gemini-2.5-pro 这样的前缀，剩下的转换由网关做； 一个 key 出口：应用只认网关地址，各家真实密钥存在服务端，前端拿不到； 统一记账：网关天然知道每次调用花了多少 token、哪家模型、哪个用户，可以直接出账单。 起一个网关 最省事的是用它的 proxy 模式：写一个 config.yaml 列出模型与对应环境变量里的密钥，然后 litellm --config config.yaml --port 4000。应用把 base_url 指向 http://localhost:4000，就像在调一个 OpenAI。 再往上走，可以开它的后台 UI，按团队、按 key 分组限额——市场部的 key 每天最多花 50 元，研发的 key 不限速但要记账。 为什么这件事值得做 Manus 2.0 把 Token 成本砍掉两成多，靠的是框架优化。但如果你连「谁在花、花在哪」都看不见，优化就是盲人摸象。一个统一网关是把账单从黑盒变成仪表盘的前提。等哪天你要在 GPT-6 和 DeepSeek 之间按价格动态切换模型，这个网关就是路由层——没有它，多模型容灾只是纸上谈兵。 补一个排障细节：网关层最容易出问题的是超时。长任务（Agent 跑十几步）很容易超过默认的短 HTTP 超时，导致前端报错但后端其实还在跑。把网关和客户端的超时都调到五分钟以上，并开启流式响应，长任务的体验才顺。另外，key 分组限额要配告警，别等账单来了才发现某个测试 key 被循环调用。 把网关立起来之后，你会发现「换模型」「看账单」「做限流」从改代码变成了改配置——这层抽象一旦到位，后面的多模型策略、价格路由才有地方生长，不至于散落在业务代码里。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：LiteLLM网关

10 月 7 日，马斯克在社交平台发了一条意味深长的说明：从今往后，Grok Bot 将针对任何特定任务使用最佳后端模型，包括 Claude Opus 5.5、Midjourney、Suno 以及其他领先 API，标准只有一个——哪一个最可能给用户最好的结果。据 9to5Mac 同日报道，Grok Bot 已经可以调用 Claude Opus 5.5。OpenAI 没有被点名，但也没有被明确排除。 从「自研全家桶」到「任务导向调度」 这是一次立场的大转弯。xAI 过去的叙事是靠自研 Grok 模型打天下，现在公开承认：自家模型不是每个任务都最强。技术上，Grok Bot 将从「以自研模型为主」转向「任务导向的多模型混合架构」——文本推理重的活交给 Claude Opus 级后端，出图走 Midjourney，音乐走 Suno，其他领先 API 按需接入。 这背后是一个越来越普遍的产品判断：用户要的是结果，不是某个品牌的模型。智能体真正的价值，在于当好一个「调度层」。 谁在当壳，谁在当芯 把这件事放大看，行业分工正在清晰化：一端是模型厂，拼单点能力与性价比；一端是入口厂，拼流量、数据与调度体验。Grok Bot、ChatGPT、Gemini 智能体都在抢「壳」的位置，而壳下面可以挂任何模型。 谷歌云在 Gemini 智能体里接 Claude、xAI 在 Grok Bot 里接 Claude，本质是同一件事：模型正在变成可替换的零件，入口和工作流才是粘性所在。 这对Anthropic反而是好消息——自家旗舰模型不必独占入口，照样能通过各家智能体被大规模调用。模型厂与入口厂的边界，正在从「谁吃谁」变成「互相成就」。 判断 「谁好用用谁」看似对自家模型不自信，实则是更成熟的产品战略——与其硬撑全栈，不如把调度做到最好。对开发者，这意味着模型路由层会成为标配：一个智能体根据任务自动挑后端，按成本与质量动态切换。接下来要观察的，是这种多模型调度在账单和数据合规上，能不能跑得比单模型更干净。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Grok Bot

引言 随着AI应用使用的模型和供应商越来越多，统一管理这些AI服务成为一个迫切需求。AI网关应运而生，它就像API网关一样，为所有AI服务提供统一的入口、路由、负载均衡和监控。本文将对比2026年主流的AI网关方案。 什么是AI网关 核心功能 统一API：一个接口访问所有模型 智能路由：根据任务选择最佳模型 负载均衡：在多个供应商间分配流量 成本控制：监控和限制API费用 缓存：缓存常见查询结果 安全：认证、限流、内容过滤 监控：统一的可观测性 架构 客户端 → AI网关 → 模型供应商 ├→ OpenAI (GPT-5) ├→ Anthropic (Claude 4) ├→ 智谱 (GLM-5) ├→ 自托管 (vLLM) └→ 阿里 (Qwen 3) 主流AI网关 1. LiteLLM 最流行的开源AI网关： from litellm import Router # 配置多供应商 router = Router(model_list=[ {"model_name": "gpt-5", "litellm_params": {"model": "gpt-5", "api_key": "..."}}, {"model_name": "claude-4", "litellm_params": {"model": "claude-4-opus", "api_key": "..."}}, {"model_name": "glm-5", "litellm_params": {"model": "glm-5", "api_key": "..."}}, ]) # 智能路由 response = router.completion( model="gpt-5", # 或 "auto" 自动选择 messages=[{"role": "user", "content": "你好"}] ) 功能： 100+模型供应商支持 OpenAI兼容API 成本追踪 限流和配额 重试和故障转移 缓存 2. Portkey 企业级AI网关： ...

FastChat 概述 FastChat（原 Vicuna 项目）是 LMSYS Org 开发的开源大模型对话平台，核心功能： 多模型对话：同时与多个模型对话，横向对比输出质量 Web UI：基于 Gradio 的聊天界面，支持流式输出 OpenAI 兼容 API：提供标准 API 接口 分布式架构：Controller-Worker 分离，支持多 GPU 节点 模型竞技场：Chatbot Arena 盲测打分系统的开源实现 FastChat 的定位更偏向模型评测和对比，而非纯生产服务。如果你想搭建一个多模型对比平台，FastChat 是最合适的开源方案。 架构解析 ┌─────────────┐ │ Controller │ (中心调度) └──────┬──────┘ ┌────────────┼────────────┐ │ │ │ ┌─────┴─────┐ ┌───┴─────┐ ┌───┴─────┐ │ Worker 0 │ │Worker 1 │ │Worker 2 │ (模型推理) │ Vicuna-13B│ │LLaMA-70B│ │Qwen-14B │ └───────────┘ └─────────┘ └─────────┘ │ │ │ ┌─────┴─────────────┴─────────────┘ │ Gradio Web Server / API │ └─────────────────────────────────┘ Controller：注册中心，管理所有 Worker 的模型信息，做负载均衡 Worker：加载模型，处理推理请求，可分布在多台 GPU 机器 Web Server：Gradio 界面 + REST API 安装 pip install fschat[model_worker,webui] 或从源码安装最新版： ...

LiteLLM 是什么 LiteLLM 是一个统一的 LLM 代理层，用一套 OpenAI 兼容 API 调用 100+ 个模型提供商。它解决的核心问题是：每个 LLM 提供商的 API 格式都不一样。 提供商 API 格式 认证 流式格式 OpenAI /v1/chat/completions Bearer token SSE Anthropic /v1/messages x-api-key SSE (不同结构) Google Gemini /v1/models:generateContent API key JSON streaming Bedrock /model/{id}/invoke AWS Sig v4 Event stream DeepSeek /v1/chat/completions Bearer token SSE LiteLLM 把这些全部统一成 OpenAI 格式。你的应用代码只对接 LiteLLM，换模型只改配置不改代码。 快速部署 Docker 部署 docker run -d \ --name litellm-proxy \ -p 4000:4000 \ -v $(pwd)/config.yaml:/app/config.yaml \ -e LITELLM_MASTER_KEY=sk-1234 \ ghcr.io/berriai/litellm:main-latest \ --config /app/config.yaml 配置文件 # config.yaml model_list: # OpenAI 模型 - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY # DeepSeek（OpenAI 兼容格式） - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY api_base: https://api.deepseek.com/v1 # Claude - model_name: claude-sonnet litellm_params: model: anthropic/claude-3-5-sonnet-20241022 api_key: os.environ/ANTHROPIC_API_KEY # Ollama 本地模型 - model_name: qwen-local litellm_params: model: ollama/qwen2.5:14b api_base: http://host.docker.internal:11434 # 负载均衡：同一模型名指向多个后端 - model_name: fast-model litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: fast-model litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY litellm_settings: # 缓存 cache: true cache_params: type: redis host: redis port: 6379 # 限流 max_budget: 100 # 每日 $100 上限 budget_duration: 1d router_settings: routing_strategy: least-busy # 负载均衡策略 num_retries: 3 timeout: 30 fallbacks: - model: gpt-4o fallback_to: [deepseek-chat, qwen-local] 启动验证 # 测试 OpenAI 兼容 API curl http://localhost:4000/v1/chat/completions \ -H "Authorization: Bearer sk-1234" \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-chat", "messages": [{"role": "user", "content": "Hello"}], "stream": false }' 核心功能 负载均衡 同一 model_name 配置多个后端，LiteLLM 自动分流： ...