最近两天朋友圈里讨论最多的开源模型，基本就是小米的 MiMo v2.6 了。开源榜冲到第一，价格直接挂在了 OpenRouter 上，不用申请内测就能用，这对做 AI 应用、搞 Agent 开发的同行来说算是个不小的信号。我连着测了两个晚上，把接入流程、价格逻辑、容易踩的坑都跑了一遍，这篇就当是给同样在观望的你们交个底。
1. MiMo v2.6 到底是什么：从开源榜第一名说起
先把这个名字拆开看。MiMo 是小米开源的大语言模型系列，v2.6 是最新放出来的版本，在不少开源模型聚合榜上热度排到了第一。作为开源模型，它的核心卖点不是“又一个千亿参数怪兽”，而是把推理能力、代码生成能力、工具调用能力这些日常高频场景做扎实了，同时把模型权重开源出来，让开发者自己部署、微调、集成。
1.1 这个第一名，分量在哪里
网上聊开源榜第一名，很容易陷入“参数多就是强”的误区。其实对一个做工程的人来说，榜单第一名背后更实际的意义是三件事：一是社区验证度高，说明模型不是小范围自嗨；二是配套生态完善，模型卡、权重、示例代码、评测结果齐全；三是复现成本明确，OpenRouter 上的按量计费、官方仓库里的部署脚本，都意味着别人已经帮你蹚过一遍流程。
热词里反复出现的“mimo模型不能传图片”“mimo v2.6”“开源排行第一”，本质上都指向同一个需求：大家想知道这个模型到底能不能写代码、能不能做 Agent、能不能替代现在手里正在用的付费闭源模型。从我实测的结果看，它在代码生成和中文长文本理解上确实有独到之处，尤其是工具调用（Function Call）的稳定度，比不少同类开源模型要高一截。
1.2 为什么大家更愿意讨论它，而不是闷头评测
观察这两天社区里的帖子，讨论 MiMo v2.6 的人分三类：一类是纯好奇的普通用户，想知道它和手机内置的语音助手有什么区别；一类是独立的 AI 应用开发者，关注 OpenRouter 上的价格和 API 稳定性；还有一类是研究型玩家，想拿权重下来自己跑一套私有部署。
对最后一类人来说，MiMo v2.6 最吸引人的点在于：它保持了开源模型“可改、可控、可下线运行”的底子，但能力又追上了商业模型的日常水平。过去开源模型和商业模型之间那道“差一个档次”的沟，在 v2.6 上被填平了不少。当然，它也有明显的边界，比如它不支持图片输入、上下文长度有上限、OpenRouter 免费额度的节奏很抠门，这些细节我会在后面一节一节点破。
2. 别把两个 MiMo 搞混：它为什么不能传图片
我先去热词里看了一眼，“mimo信道容量图像”“mimo模型不能传图片”这些搜索词混在一起，就知道有很多人把两个 MiMo 弄混了。一个是通信领域的老牌 MIMO（多输入多输出天线技术），负责信号传输，天天讲信道容量；另一个是小米的 MiMo 大语言模型，负责文本生成和代码推理。名字撞了，但赛道完全不相干。
2.1 文本模型的边界：图片进不来，这是设计选择
小米 MiMo v2.6 目前是纯文本模型，意味着它只能处理文本输入，不能直接读图、识别照片、做图像理解。很多人在对话窗口里丢了一张截图，发现模型回复“我无法查看图片”，就开始质疑它“能力不行”。这个判断其实不准，模型是否支持图片输入取决于多模态能力的训练与对齐，v2.6 没有做这块，从架构和产品定位上讲是主动取舍，而不是缺陷。
我在 OpenRouter 上测试时试过用 Base64 图片数据走 OpenAI 兼容的消息格式，得到的反馈是图片内容被忽略，只把文本部分送入模型。官方文档也明确标注了 supported modalities 里只有 text，没有 image。如果你需要模型看懂截图、解析图表、识别验证码，那么 MiMo v2.6 并不是这个场景的选择，建议直接去找支持视觉的模型，而不是在这里硬拗。
2.2 代码与工具调用，才是它真正的主场
如果你仔细看 MiMo v2.6 的榜单成绩和社区评价，会发现它的长板非常聚焦：代码生成、代码解释、结构化输出、函数调用。这恰恰是 Agent 开发最需要的底座能力。
举个例子，我让它写一个批量重命名文件的 Python 脚本，要求支持正则表达式和冲突自动改名。它给出的代码不仅逻辑正确，还主动加上了 pathlib 处理路径跨平台问题，并且把错误处理分支写完整了。这种“主动补充工程细节”的行为，在多数开源模型里很少见。做应用集成的时候，我把一个 JSON Schema 丢给它，让它根据需求生成对应的 Python dataclass 定义，生成结果可以原样落盘直接编译通过，几乎没有返工。
所以，如果你要用它是为了聊天、解闷、写文案，它表现中规中矩；但如果你是要构建一个自动化的程序生成器或者一个复杂 Agent，那它才是真正打开后厨给你看到做法的那种模型。
3. 挂在 OpenRouter 上以后，价格是怎么算的
OpenRouter 对国内开发者来说不算陌生，它本质上是一个模型网关：帮你聚合几十家模型服务，只提供一个统一的 API 入口和一致的计费方式。这次 MiMo v2.6 挂在 OpenRouter 上，意味着你不用去小米自家的平台注册、也不用找内测通道，只要有一个 OpenRouter 账号和 API Key，就能用 OpenAI 兼容的接口调用它。
3.1 OpenRouter 入口的价值：一次接入，全家通用
以前我们要用某个新模型，往往要去对应平台的官网，申请密钥、看文档、适配 SDK，繁琐不说，每个平台的接口风格还不一样。OpenRouter 把这个痛点一刀切掉：你只需要用一套 OpenAI 格式的 API，就能把平台上的所有模型都当服务用。也就是说，你接入 MiMo v2.6 的代码，和以后接入别的模型，基本是同一套代码，只需要改模型标识符。
我在实际项目中就用这种方式做过模型切换：同一个函数，把 model 参数从别的模型改成xiaolai/mimo-v2.6（具体标识符以 OpenRouter 页面为准），其余代码一行不用动，新模型立刻上线。这件事对独立开发者特别友好——你不需要为每一个模型供应商写一套 SDK 适配层，省下来的时间可以放到业务逻辑上。
3.2 单价到底是多少，输入输出怎么计费
价格方面，OpenRouter 的计费方式是标准的按 token 付费，分为输入（prompt）和输出（completion）两个价位。以目前页面上的公示价格来看，MiMo v2.6 的定价大概在一个非常有竞争力的档位，输入价格在每百万 token 十几美分到二十几美分之间，输出价格在每百万 token 几十美分级别，具体以 OpenRouter 模型页面的实时报价为准。
很多人第一次用 OpenRouter 时会被“每百万 token”这个单位唬住。我这么给你折算：一篇大约 1000 字的文章，转换成 token 大概在 700 到 900 之间，一百万 token 约等于一千多篇文章的输入量。所以哪怕你每天调几千次 API，只要不是大批量跑长文总结，月成本基本可以控制在几美元以内。对比一些闭源旗舰模型动辄每百万输出 token 好几美元的定价，MiMo v2.6 确实便宜到可以“开着调试”。
3.3 充值、额度和密钥：第一次上手最容易卡住的三个环节
在 OpenRouter 上跑通第一次请求，需要做三件事：注册账号、充值额度、创建 API Key。注册不多说，邮箱就能搞定；充值支持信用卡和其他常见方式，最低充值额度很低，先充几美元足够测试。
这里要特别提醒：OpenRouter 的 API Key 只会在创建时完整显示一次，刷新页面后就再也看不到了。所以创建后要立刻复制到一个安全的地方，比如密码管理器。密钥的权限分为两种，一种是只读的（查看余额和用量），一种是可调用的（发请求），建议开发时用一个专属 Key，上线后做环境变量管理，不要把 Key 硬编码进前端代码里。
4. 完整接入流程：从网页调试到 Python 代码调用
理论部分聊得差不多了，下面进入实操。我这边把整个过程分成三步：先用网页聊天快速试能力，再用 curl 验证接口，最后写一段 Python 脚本作为生产环境的基础模板。
4.1 第一步：在 OpenRouter 网页端快速试水
打开 OpenRouter 的模型列表，搜索 MiMo v2.6，进入模型详情页，可以直接在右侧聊天框里测试。这个网页测试不消耗必要的额度，相当于一个免配置的试用区。你可以在这一层把需求场景验证一遍，比如让它写一个 SQL 查询、解释一段晦涩的代码、或者按指定格式输出 JSON，确认它的风格和你的预期是否一致。
我在这个阶段踩过一个小坑：网页端的系统提示词是默认值，它会强制模型以某种语气回复。如果你后续在 API 里设置了自定义 system prompt，反馈出来的说话风格跟网页端测试时会有明显差异。所以网页测试只适合看“能力上限”，不适合看“最终效果”，最终的 prompt 调优一定要在 API 层做。
4.2 第二步：用 curl 验证 API 连通性
拿到 API Key 后，最快验证请求通道的方式就是 curl。下面是一个最小化的请求示例，你只需要把YOUR_API_KEY替换成自己的密钥就可以：
curl https://openrouter.ai/api/v1/chat/completions \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "xiaolai/mimo-v2.6", "messages": [ {"role": "system", "content": "你是一个严谨的工程师，回答要简洁、准确。"}, {"role": "user", "content": "用 Python 写一个函数，计算斐波那契数列的第 n 项，要求时间复杂度 O(log n)。"} ] }'执行完以后，你会收到一个 JSON 响应，里面包含choices[0].message.content，那就是模型生成的结果。响应里还会带 usage 字段，包含 prompt_tokens、completion_tokens 和 total_tokens，这三个数值用来核对账单、估算成本非常有用。
注意模型标识符xiaolai/mimo-v2.6只是我按常见命名习惯写的示例，OpenRouter 上实际使用的具体标识符请以模型详情页的 API 字段为准。不同接入方可能有不同的路由名，拼错模型名会直接返回模型不存在或不可用的错误。
4.3 第三步：Python 脚本接入，搞定一个生产可用模板
curl 验证通过后，就可以进入正式的开发环节。用 Python 接入 OpenRouter 非常简单，可以直接用openai库，因为 OpenRouter 兼容 OpenAI 的调用协议，只需要把 base_url 指到 OpenRouter 的地址即可。
from openai import OpenAI client = OpenAI( api_key="YOUR_API_KEY", base_url="https://openrouter.ai/api/v1" ) response = client.chat.completions.create( model="xiaolai/mimo-v2.6", messages=[ {"role": "system", "content": "你是一个擅长代码审查的资深工程师。"}, {"role": "user", "content": "请审查下面的代码，指出潜在问题并给出修改建议：\n\n```python\ndef get_user(user_id):\n return db.query(f\"SELECT * FROM users WHERE id = {user_id}\")\n```"} ], temperature=0.3, ) print(response.choices[0].message.content)这段代码跑通之后，你就会发现一个很棒的体验：base_url一行指过去，之前写过的所有 OpenAI 生态代码都可以共用。做 Agent 时，你需要把response里的 tool_calls 字段自己解析出来，OpenRouter 会原样透传模型返回的 function call 结构，不会做额外加工，这比某些平台擅自改协议要省心得多。
在生产环境里，我还要补两个细节：一是加超时和重试，网络请求总有抖动，建议用tenacity做指数退避重试；二是对 usage 做日志记录，方便月底对账，也能及时发现自己写的 prompt 是不是太啰嗦导致 token 消耗失控。
5. 高频问题与排查实录
接入和使用过程中，我在各种社区群里收集了一批高频问题，也把这些问题和自己踩过的坑放在一起整理成了一份速查表，按热度排序，你如果遇到类似情况可以直接来对照。
5.1 为什么我发图片过去，模型说看不到
这基本是最近问得最多的一条。正如前文所讲，MiMo v2.6 是纯文本模型，OpenRouter 在透传请求时会忽略图片内容，只保留文本。如果你的业务必须要视觉理解能力，请换多模态模型。如果只是偶尔想发截图给它，让它识别文字或图表，那这条路走不通，建议先用 OCR 把文本提取出来再送进模型，效果反而更可控。
5.2 余额扣得比预期快，问题出在哪
OpenRouter 按 token 计费，很多人刚上手时觉得“我就问了几句，怎么余额少了这么多”，原因通常有三类：一是没有注意 system prompt 的长度，每轮请求都会把 system prompt 完整算进输入 token；二是把整个对话历史都跟着每次请求一起发，历史越长，输入 token 越多；三是设置了很高的 max_tokens，即使模型回答很短，空隙也被填充符号消耗掉。
我的做法是：system prompt 尽量精简，写清角色和约束即可，别放长篇背景说明；对话轮次超过五轮后，做历史裁剪或摘要压缩；max_tokens 按实际需要设置，不要默认给满。
5.3 接口报 404、400、429，分别是哪里出问题
这三个状态码覆盖了绝大多数接入问题。404 基本是模型标识符写错，或者你所在地区/账号在 OpenRouter 侧没有该模型的访问权限，先去模型详情页复制准确的 model 字段；400 是请求体格式有问题，最常见的错误是 messages 缺少 role 字段，或者 content 是数组但格式不被接受；429 则是触发了速率限制或额度不足，需要查看余额，并降低请求频率。
我在社区里还看到有人报 CORS 错误，那是因为把 API 请求直接发到了浏览器直连场景，但 OpenRouter 的 Key 不应该暴露在纯前端代码里。正确的做法是前端请求自己的后端服务，由后端持有 Key，转发给 OpenRouter。这不仅是安全要求，也是计费主体明确的保证。
5.4 OpenRouter 密钥找不到了怎么办
密钥创建后只能看一次，如果真弄丢了，没有找回的选项。正确做法是回到 API Keys 页面，把旧的 Key 删除，新建一个。新旧 Key 之间没有继承关系，删除旧 Key 后所有用它发起的请求都会立刻失效。所以如果你在多个环境里用了同一个 Key，换新之后要记得把所有环境变量一次性更新，别漏了某台服务器。
6. 写在最后：我对 MiMo v2.6 的实操体会
个人测下来的感觉，MiMo v2.6 不是那种“什么都能聊一点”的万金油模型，而是在代码生成、结构化输出、工具调用这些工程向能力上显得特别扎实。它的风格是“解决问题优先”，不太跟你绕弯子，这在写程序、拼流程、做数据提取的时候非常舒服。最直观的例子是我让它把一份乱七八糟的招聘启事转成结构化 JSON，字段映射、类型推断、枚举归一化都做得干净利落，几乎没有需要手工修改的地方。
如果你现在正准备搭一个新的 Agent 应用，预算有限，又不想完全依赖某一个闭源厂商的 API，那么把 MiMo v2.6 通过 OpenRouter 接进来作为主模型，是一个非常值得试的起点。它可以帮你把业务先跑起来，等数据积累到一定量级，再考虑拿权重做私有化部署，这样的路径会让你的成本和技术风险都更可控。
最后分享一个小经验：OpenRouter 上同一个模型，通过不同 provider 路由，实际返回的速度和稳定性可能肉眼可见有差别。如果发现某一天请求特别慢，可以在请求头里加上路由偏好参数，或者在模型页面查看各个 provider 的状态，主动选一个当前延迟更低的节点。这种控制力，反而是开源模型挂在公共网关上时的隐藏优势。
