1. 从 Token Plan 到 M Plan这次改动到底动了谁的蛋糕如果你最近半年一直在用 MiniMax 的 API 做多模态应用大概率对 Token Plan 这个名字不陌生。简单说它就是按 token 计费的一套额度体系文本按文本算、语音按语音算、视频再单独算一笔账单出来的时候你得拿着计算器一项一项对。我上个月帮一个做短视频批量生成的朋友核算成本光是对齐三个不同模态的计费口径就花了整整一个下午最后发现视频那部分的消耗远超预期因为提示词写长了、生成时长拉满了token 消耗直接翻倍。M Plan 的出现本质上就是把这种“分账式”的额度管理给终结了。它做的事情可以用一句话概括把全模态的额度统一到一个池子里文本、语音、视频、图像共用同一份额度按实际消耗折算扣减。这意味着你不再需要分别预估每个模态要用多少量也不用担心某个模态额度用完了另一个模态还剩一大堆。对于做多模态 Agent、内容生成工具、AI 工作流编排的开发者来说这个改动直接简化了成本模型预算控制从“多线作战”变成了“单线管理”。而这次同步解禁的 H3 视频能力是另一个值得单独拎出来说的点。H3 是 MiniMax 的视频生成模型系列之前在内测阶段就有不少人在蹲这次随 M Plan 一起放开意味着你可以直接用统一的额度去调用视频生成接口不需要再单独申请视频权限或者走另外的计费通道。我实测下来H3 在 20 系显卡上的优化做得比预期好本地推理的显存占用控制得比较克制后面会详细说这块的配置细节。这篇文章适合三类人看第一类是在做多模态应用、需要控制 API 成本的开发者第二类是想把 Claude Code 或 Cursor 接到 MiniMax 模型上、但被 API Key 配置卡住的人第三类是对 H3 视频生成感兴趣、想在自己机器上跑起来的技术玩家。我会从 M Plan 的额度机制讲起然后手把手带你走一遍 Claude Code 和 Cursor 的接入流程最后把 H3 本地部署和常见坑点一次性说清楚。2. M Plan 额度大一统机制拆解与成本核算逻辑2.1 全模态统一额度到底怎么算M Plan 的核心变化在于计费单元的归一化。以前 Token Plan 的逻辑是文本模型按输入输出 token 分别计价语音合成按字符数或时长计价视频生成按分辨率、帧数、时长综合计价。三套体系互不相通你得分别充值、分别监控、分别告警。M Plan 把这套逻辑改成了“统一额度池 模态折算系数”的模式。具体来说你充值的额度是一个统一的数值调用不同模态的 API 时系统会根据该模态的单位消耗折算成额度扣减。比如文本对话消耗 1 个单位额度语音合成可能消耗 5 个单位视频生成按秒数消耗 50 个单位——具体系数以官方文档为准但逻辑是这样的。这种设计的好处在于你只需要关注总额度还剩多少不需要分别管理多个余额。对于业务波动大的场景特别友好——这个月视频生成需求暴涨那就把额度倾斜到视频上下个月文本对话量上来了同一份额度直接切过去用不需要重新充值或者做额度转移。我拿一个实际案例算过账假设你一个月内需要生成 10 万次文本对话、5000 次语音合成、200 条 5 秒视频。在旧体系下你得分别买三个套餐而且套餐之间不能互相调剂很容易出现文本额度用完了但语音额度还剩一半的情况。在 M Plan 下你只需要买一个总额度系统按实际调用自动扣减月底看账单就是一个总数财务对账也简单得多。2.2 为什么说 Token Plan 成为历史是必然的从产品演进的角度看Token Plan 的退场其实早有征兆。多模态能力是 MiniMax 的核心卖点之一但旧的计费体系实际上在阻碍用户跨模态使用——因为每跨一个模态成本核算的复杂度就上升一个量级。很多开发者跟我聊过他们本来想做一个“文本生成脚本 语音合成配音 视频生成画面”的完整工作流但一想到要管理三套额度就放弃了转而只用文本模型。M Plan 解决的就是这个“跨模态摩擦成本”问题。当额度统一之后你调用视频生成和调用文本对话在计费体验上没有区别都是从一个池子里扣。这会直接刺激多模态组合场景的爆发——比如自动生成带配音的短视频、基于文本描述直接产出视频素材、语音对话驱动的视频编辑等等。另一个推动因素是竞争压力。国内大模型 API 市场这两年价格战打得很凶单纯拼文本 token 单价已经很难拉开差距了。M Plan 这种“全模态打包”的策略实际上是在用计费方式的差异化来建立壁垒——你在我这里可以用同一份额度做所有事去别家还得分开买对多模态重度用户来说迁移成本就上来了。2.3 额度消耗的监控与预警配置M Plan 虽然简化了计费但监控还是不能少。我建议在接入之后立刻做三件事第一在控制台设置额度预警阈值。一般建议设两个档位剩余 30% 时发提醒剩余 10% 时发告警。这样你有足够时间决定是充值还是调整调用策略。第二在代码层面做调用量埋点。每次 API 调用返回的响应头里通常会带本次消耗的额度信息把它记到日志或者监控系统里按天/按小时聚合就能看出消耗趋势。我用的是一个简单的 Python 装饰器每次调用后把消耗量写进 SQLite然后用 Grafana 拉个图一目了然。第三对不同模态设置独立的调用上限。虽然额度是统一的但你不希望某个模态意外跑飞把额度全吃光。比如视频生成接口可以设一个每日调用次数上限超过就拒绝防止代码 bug 导致无限循环调用。# 简单的额度监控装饰器示例 import functools import sqlite3 from datetime import datetime def track_quota(func): functools.wraps(func) def wrapper(*args, **kwargs): response func(*args, **kwargs) # 假设响应中有 quota_used 字段 quota_used response.get(quota_used, 0) conn sqlite3.connect(quota_log.db) conn.execute( INSERT INTO logs (timestamp, endpoint, quota_used) VALUES (?, ?, ?), (datetime.now().isoformat(), func.__name__, quota_used) ) conn.commit() conn.close() return response return wrapper注意额度预警阈值不要设得太低否则频繁告警会让你麻木。30% 和 10% 两档是我试过比较合理的配置既不会太早打扰也不会太晚来不及处理。3. H3 视频能力解禁本地部署与 20 系显卡优化实录3.1 H3 到底能做什么适合谁用H3 是 MiniMax 的视频生成模型支持文本到视频、图像到视频两种主要模式。我实测下来它在 5 秒短视频生成上的表现比较稳画面连贯性和运动自然度在同级别模型里属于中上水平。适合的场景包括短视频素材批量生产、电商商品展示视频、社交媒体内容快速产出、以及作为多模态工作流中的视频生成环节。不适合的场景也很明确需要精确控制画面细节的影视级制作、需要长时长超过 10 秒的连续镜头、以及对人物面部一致性要求极高的场景。这些场景目前还是得靠传统制作流程或者更重的视频生成方案。H3 的 API 调用方式跟其他 MiniMax 模型一致走统一的 M Plan 额度。如果你不想本地部署直接调 API 是最省事的路径。但如果你有数据隐私要求、或者想离线批量生成本地部署就是必须的了。3.2 20 系显卡的显存优化配置这是很多人关心的问题20 系显卡比如 2060、2070、2080能不能跑 H3答案是能但需要做一些优化配置。我拿 2080 Super8GB 显存实测过默认配置下会 OOM调整之后可以稳定生成 5 秒 480p 视频。关键优化点有三个第一开启 mem eff内存高效模式。这是 H3 内置的一个优化选项通过分块计算和梯度检查点来降低显存峰值占用。开启方式是在配置文件中设置mem_efficient: true或者在调用时传入mem_eff_s参数。实测下来开启后显存占用从 10GB 降到 6GB 左右2080 Super 刚好能跑。第二降低分辨率和帧率。480p、24fps 是 20 系显卡比较稳妥的配置。如果你强行上 720p即使开了 mem eff 也会很吃力生成时间会大幅拉长而且容易在中途 OOM。第三控制提示词长度。这一点很多人忽略——提示词越长模型需要处理的上下文越大显存占用也会相应增加。我实测发现提示词从 50 字增加到 200 字显存峰值会上升 15% 左右。所以建议把提示词控制在 100 字以内把关键信息说清楚就行不需要堆砌形容词。# H3 本地部署配置示例20 系显卡优化版 model: name: minimax-h3 resolution: 480p fps: 24 duration: 5 mem_efficient: true mem_eff_s: true max_prompt_length: 100 batch_size: 1 precision: fp16提示如果你用的是 20606GB 显存建议把分辨率降到 360p并且把 duration 控制在 3 秒以内。再往上就很容易 OOM 了不要硬撑。3.3 本地部署的完整步骤本地部署 H3 的流程不算复杂但有几个环节容易卡住。我按顺序列一下第一步环境准备。需要 Python 3.10、CUDA 11.8 或 12.1、PyTorch 2.1。如果你用的是 Ubuntu建议直接用 conda 建一个独立环境避免跟系统 Python 冲突。Windows 10 也能跑但 CUDA 版本要跟 PyTorch 对齐不然会报错。第二步拉取模型权重。从 MiniMax 官方渠道下载 H3 的权重文件一般是一个几 GB 的压缩包。解压后放到指定目录然后在配置文件里指向这个路径。第三步安装依赖。除了 PyTorch 之外还需要装一些视频处理的库比如 opencv-python、imageio、ffmpeg。ffmpeg 建议用系统包管理器装不要用 pip 装不然容易缺编解码器。第四步跑通推理脚本。先用官方提供的示例脚本跑一个最简单的文本到视频生成确认环境没问题。如果这一步就报错大概率是 CUDA 版本或者显存不够按前面的优化配置调整。第五步接入自己的业务代码。把推理脚本封装成函数或者服务对外提供 API。我一般会用 FastAPI 包一层这样其他服务可以直接 HTTP 调用不用关心底层的 Python 环境。# Ubuntu 下的环境准备命令示例 conda create -n h3 python3.10 conda activate h3 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install opencv-python imageio imageio-ffmpeg fastapi uvicorn sudo apt install ffmpeg3.4 生成 5 秒视频的提示词要写多少字这是被问得最多的一个问题。我的经验是80 到 120 字之间比较合适。太短了模型抓不住重点画面会很随机太长了显存占用上升而且后面的描述容易被模型忽略。一个好的提示词结构应该是主体 动作 环境 风格。比如“一只橘猫坐在窗台上慢慢转头看向镜头窗外是傍晚的城市天际线暖色调电影感”。这句话大概 40 字已经能生成比较像样的画面了。如果你要加更多细节比如光线方向、镜头运动、材质质感可以扩展到 80 到 100 字。不要做的事堆砌形容词、写抽象概念、描述多个场景切换。H3 对具体、可视化的描述响应更好对“唯美”“震撼”“史诗感”这种词基本无感。4. 免密打通 Claude Code 与 CursorAPI Key 配置全流程4.1 为什么要在 Claude Code 和 Cursor 里接 MiniMaxClaude Code 和 Cursor 是目前比较流行的两种 AI 编程工具形态。Claude Code 是命令行式的适合在终端里快速执行代码生成、文件操作、命令执行Cursor 是编辑器形态的适合在写代码的过程中做补全、重构、对话。它们默认用的是各自的模型服务但都支持自定义 API 端点。把 MiniMax 接进去的好处有两个一是可以用 M Plan 的统一额度来覆盖编程场景的消耗不用单独买编程工具的订阅二是 MiniMax 的模型在中文代码注释、中文需求理解上有优势适合国内开发者的使用习惯。4.2 Claude Code 的安装与 API Key 配置Claude Code 的安装方式取决于你的系统。macOS 和 Linux 下一般用 npm 全局安装Windows 下建议用 WSL 或者直接下二进制包。# 安装 Claude Code npm install -g anthropic-ai/claude-code # 验证安装 claude --version安装完成之后需要配置 API Key 和端点。Claude Code 默认走 Anthropic 的官方端点要切到 MiniMax 需要改两个地方一是ANTHROPIC_BASE_URL环境变量指向 MiniMax 的兼容端点二是ANTHROPIC_API_KEY填你在 MiniMax 控制台生成的 API Key。# 在 ~/.bashrc 或 ~/.zshrc 中添加 export ANTHROPIC_BASE_URLhttps://api.minimax.chat/v1 export ANTHROPIC_API_KEYyour-minimax-api-key改完之后source一下配置文件然后跑claude命令测试。如果能看到正常的对话界面并且能执行命令说明配置成功了。注意MiniMax 的兼容端点路径可能随版本变化配置前先去控制台确认最新的端点地址。另外 API Key 不要硬编码在代码里用环境变量或者密钥管理服务。4.3 Cursor 的下载、安装与中文设置Cursor 的下载安装没什么特别的官网下对应系统的安装包一路下一步就行。重点说两个高频问题中文设置和模型配置。中文设置这块Cursor 本身支持界面语言切换。在设置里搜 “language”选 “中文简体” 就行。但注意这只改界面语言不影响模型回复的语言。要让模型用中文回复需要在对话时明确说“请用中文回答”或者在系统提示词里加一句“Always respond in Chinese”。模型配置这块Cursor 支持自定义模型端点。在设置里找到 “Models” 或者 “AI Provider”添加一个自定义 provider填入 MiniMax 的 API 端点和 Key。然后在下拉框里选你配置的模型就可以在对话和补全里用 MiniMax 了。// Cursor 自定义模型配置示例settings.json { cursor.ai.customProviders: [ { name: MiniMax, baseUrl: https://api.minimax.chat/v1, apiKey: your-minimax-api-key, models: [minimax-text-01, minimax-text-02] } ] }4.4 免密打通的关键用 cc switch 做多模型路由如果你同时用多个模型比如 MiniMax、DeepSeek、GLM每次切换都要改环境变量很麻烦。我推荐用 cc switch 这类工具做模型路由它可以根据当前任务自动选择最合适的模型或者让你在命令行里一键切换。cc switch 的配置逻辑是定义一个模型列表每个模型有自己的端点和 Key然后设置路由规则。比如代码生成走 MiniMax长文本理解走 DeepSeek中文对话走 GLM。配置好之后Claude Code 和 Cursor 都指向 cc switch 的本地端点由它来转发请求。# cc switch 配置示例 providers: - name: minimax base_url: https://api.minimax.chat/v1 api_key: ${MINIMAX_API_KEY} models: [minimax-text-01] - name: deepseek base_url: https://api.deepseek.com/v1 api_key: ${DEEPSEEK_API_KEY} models: [deepseek-chat] routes: - match: code.* provider: minimax - match: .* provider: deepseek这样配置之后你在 Claude Code 里执行代码相关任务会自动走 MiniMax其他任务走 DeepSeek不需要手动切换。而且 API Key 统一在 cc switch 里管理Claude Code 和 Cursor 只需要配一个本地端点就行这就是“免密打通”的含义——工具侧不需要知道具体的 Key由路由层统一处理。5. 常见问题与排查技巧实录5.1 API Key 相关报错速查报错信息可能原因解决方法no api key for provider route deepseek-officialcc switch 里没配 DeepSeek 的 Key或者环境变量没生效检查DEEPSEEK_API_KEY是否导出重启终端401 UnauthorizedAPI Key 填错或过期去控制台重新生成 Key确认没有多余空格403 ForbiddenKey 没有对应模型的权限检查 M Plan 是否包含该模型或联系客服开通429 Too Many Requests调用频率超限降低并发或者升级套餐提高 QPS 上限insufficient quota额度用完了去控制台充值或者检查是否有异常调用消耗5.2 Claude Code 安装与升级的坑Claude Code 的安装本身不难但有几个坑我踩过Node 版本问题。Claude Code 要求 Node 18如果你系统里是 Node 16npm 安装会报错。用nvm或者n切到最新 LTS 版本就行。权限问题。在 Linux 下全局安装 npm 包可能需要 sudo但用 sudo 装完之后普通用户跑不了。建议用npm config set prefix ~/.npm-global把全局包目录改到用户目录下避免权限问题。在线升级失败。Claude Code 支持claude update在线升级但有时候会因为网络问题卡住。如果升级失败直接npm update -g anthropic-ai/claude-code手动升级就行。5.3 Cursor 响应速度慢的排查思路Cursor 响应慢通常有三个原因网络延迟、模型端负载、本地配置问题。网络延迟这块如果你用的是国内网络访问海外端点延迟会比较高。解决办法是用国内可访问的端点比如 MiniMax 的国内节点。模型端负载这块高峰期比如工作日下午响应会慢一些这是正常的。如果持续很慢可以去 MiniMax 控制台看是否有服务公告。本地配置这块Cursor 的索引和补全功能会占用本地资源。如果你的项目很大建议在设置里限制索引范围排除node_modules、dist这些目录。5.4 H3 本地部署的显存排查H3 部署最常见的报错就是 CUDA out of memory。排查顺序是第一确认mem_efficient和mem_eff_s都开了。这两个参数是独立的只开一个效果有限。第二降低分辨率和帧率。480p/24fps 是 8GB 显存的底线再往上就得换卡。第三检查是否有其他进程占用显存。用nvidia-smi看一下如果有残留的 Python 进程kill 掉再跑。第四如果以上都试了还是 OOM那就是模型本身对显存的要求超过了你的卡的能力只能换卡或者用 API。提示20 系显卡跑 H3 的时候生成一条 5 秒视频大概需要 2 到 4 分钟具体取决于你的卡型和配置。不要期望秒出这是本地推理的正常速度。5.5 多模型路由的调试技巧用 cc switch 做路由的时候如果请求没走到预期的模型按这个顺序排查先看 cc switch 的日志确认请求进来了没有、匹配到了哪条路由规则。然后检查路由规则的匹配顺序cc switch 一般是从上往下匹配第一条命中的规则生效。最后检查 provider 的配置确认 base_url 和 api_key 都正确。我一般会在 cc switch 里开 debug 日志每次请求都把匹配结果打出来这样出问题的时候一眼就能看出是哪一步不对。6. 我个人在实际操作中的几点体会M Plan 这套统一额度的设计用下来最大的感受是“不用再算账了”。以前每次做多模态项目前期花在成本预估上的时间比写代码还多现在只需要关注总额度调用的时候不用想“这个模态还剩多少”。当然这不意味着可以随便跑监控和预警还是得做只是复杂度降了一个量级。H3 在 20 系显卡上的表现比我预期好。我原本以为 8GB 显存跑视频生成会非常勉强实际调优之后发现 480p/5 秒是可行的生成质量也能接受。如果你手头有 20 系卡想试试本地视频生成H3 是一个值得折腾的方向。Claude Code 和 Cursor 接 MiniMax 的流程核心就是改端点和 Key 两个配置。真正麻烦的是多模型管理cc switch 这类工具能省不少事。我的建议是如果你只用一两个模型直接配环境变量就行如果三个以上尽早把路由层搭起来后面切换和扩展会轻松很多。最后分享一个小技巧在 Cursor 里配好 MiniMax 之后可以在项目根目录放一个.cursorrules文件把“用中文回复”“代码注释用中文”“优先用 Python”这些偏好写进去这样每次对话不用重复交代模型会自动遵守。这个文件对 Claude Code 也有效放在项目根目录就行。