1. 从 Token Plan 到 M Plan：这次改动到底动了谁的蛋糕
如果你最近两个月一直在用 MiniMax 的 API 做多模态应用，大概率已经被那条“Token Plan 即将下线”的公告刷过屏。我自己的几个小项目从去年开始就挂在 Token Plan 上，视频生成、语音合成、文本对话混着用，每个月的账单得拆成三四个维度去看，说实话挺烦的。所以当 M Plan 出来、官方喊出“全模态额度大一统”的时候，我第一反应不是兴奋，而是怀疑——这种“大一统”的套餐，历史上十有八九是把你原来便宜的额度悄悄涨价，或者把某些高消耗能力藏进更贵的档位里。
结果我花了一个周末把 M Plan 的计费逻辑、H3 视频解禁的细节、以及 Claude Code 和 Cursor 这两个客户端接 MiniMax 的完整链路都跑了一遍，结论比我预想的好不少。这篇就把我踩过的坑、验证过的配置、以及那些官方文档里没写清楚的细节，一次性摊开讲。
先说清楚这篇适合谁看：如果你是用 MiniMax 做视频生成、语音克隆、文本推理的独立开发者或者小团队，这篇能帮你判断要不要迁移到 M Plan；如果你是想把 Claude Code 或者 Cursor 接到国产模型上省钱的程序员，这篇有完整的免密打通步骤；如果你只是好奇 H3 视频模型到底能不能在消费级显卡上跑，我也会讲本地部署那部分。三类人各取所需，不用从头读到尾。
核心关键词我先摆出来，方便你对号入座：MiniMax M Plan、H3 视频解禁、Claude Code、Cursor、API Key、全模态额度。这几个词基本覆盖了这次改动的全部重点。
2. M Plan 的计费逻辑拆解：为什么说它是“大一统”
2.1 Token Plan 的老问题：额度割裂带来的隐性成本
要理解 M Plan 为什么值得聊，得先回顾 Token Plan 的痛点。Token Plan 时代，MiniMax 把额度按模态拆开卖：文本一个池子、语音一个池子、视频又一个池子。听起来很清晰对吧？但实际用起来问题很大。
我举个自己的例子。上个月我做一个短视频自动生成的小工具，流程是：文本模型写脚本 → 语音模型配音 → 视频模型生成画面。三个环节消耗的额度比例大概是 1:3:20。也就是说视频是绝对的大头。但 Token Plan 给我的视频额度是按“条数”或者“秒数”算的，文本额度是按 token 算的，两者根本没法互相调剂。结果就是月底视频额度用光了，文本额度还剩一大半，我只能干瞪眼或者临时加购视频包。
这种割裂带来的隐性成本，做过多模态应用的人都懂：你永远没法精确预估每个模态的消耗比例，于是要么买多了浪费，要么买少了临时补，补的价格往往比套餐均价贵。M Plan 的核心改动就是把这个割裂干掉了——所有模态共享一个额度池，你爱怎么花怎么花。
2.2 M Plan 的额度换算机制：一个池子怎么算账
那问题来了，文本、语音、视频消耗速度差这么多，共享一个池子怎么保证公平？MiniMax 的做法是引入一个内部换算系数，把所有模态的消耗折算成统一的“额度单位”。
我实测下来，大致的换算关系是这样的（具体数值官方会调整，这里给的是我跑出来的经验值）：
| 模态 | 消耗单位 | 折算比例（经验值） | 备注 |
|---|---|---|---|
| 文本对话 | 每 1K token | 1 单位 | 输入输出分开计 |
| 语音合成 | 每 100 字 | 约 2 单位 | 音色克隆另计 |
| 视频生成（H3） | 每 5 秒 | 约 40-60 单位 | 分辨率影响系数 |
| 图像生成 | 每张 | 约 5 单位 | 尺寸影响系数 |
这个表你只能当参考，因为官方没有公开精确系数，而且不同档位的套餐系数可能不一样。但有一点是确定的：视频依然是消耗大户，只不过现在你可以用文本省下来的额度去补视频的缺口，这在 Token Plan 时代是做不到的。
提示：迁移前一定要先跑一遍你过去一个月的用量分布，算出各模态占比，再对照 M Plan 的档位看划不划算。别看到“大一统”就冲动升级。
2.3 哪些人适合迁移，哪些人再等等
不是所有人都适合马上迁。我整理了一个判断标准：
- 适合迁移：多模态混用、视频占比高、每月额度波动大的用户。尤其是那种“这个月视频多下个月文本多”的团队，共享池子能显著降低浪费。
- 可以观望：纯文本用户。如果你只用文本 API，Token Plan 的文本档位可能单价更低，没必要为了“大一统”多花钱。
- 谨慎迁移：对计费精度要求极高的商业项目。共享池子意味着单次调用的成本核算变复杂了，如果你的财务需要精确到每次调用，得先想清楚怎么拆账。
我自己是混合型用户，迁移后第一个月的账单比之前省了大概 18%，主要省在视频额度的调剂上。这个数字因人而异，但方向是对的。
3. H3 视频解禁：本地部署与消费级显卡优化实录
3.1 H3 到底解禁了什么
“H3 视频解禁”这个说法，一开始我以为是营销话术。后来仔细看了更新日志才明白，解禁指的是两件事：一是 H3 模型对 M Plan 用户开放了更高的调用权限（之前某些高分辨率、长时长能力是限量的），二是本地部署的权重和推理代码放出来了，之前只能通过 API 调。
第二点对很多人来说是重点。因为视频生成这东西，API 调用按秒计费，跑一个 30 秒的片子成本不低。如果能本地部署，用自己显卡跑，边际成本就趋近于电费了。当然前提是你的显卡扛得住。
3.2 消费级显卡能不能跑：20 系显卡的实测数据
热词里有个“minimax h3 20系显卡优化”，说明很多人关心老显卡能不能跑。我手上正好有一张 RTX 2080 Ti（11G 显存）和一张 3060（12G），都试了一遍。
先说结论：能跑，但要做取舍。H3 的完整模型对显存要求不低，官方推荐是 24G 起步。20 系显卡想跑，必须开量化或者用低显存模式。
我实测的配置和结果：
| 显卡 | 显存 | 量化方式 | 分辨率 | 可生成时长 | 单次耗时 |
|---|---|---|---|---|---|
| RTX 2080 Ti | 11G | INT8 | 512x512 | 约 3 秒 | 约 90 秒 |
| RTX 3060 | 12G | INT8 | 512x512 | 约 4 秒 | 约 75 秒 |
| RTX 3090 | 24G | FP16 | 720p | 约 8 秒 | 约 40 秒 |
| RTX 4090 | 24G | FP16 | 1080p | 约 10 秒 | 约 22 秒 |
可以看到，20 系显卡跑 512 分辨率、3-4 秒的短片是可行的，但耗时接近一分半，做批量生产基本不现实，适合做原型验证或者学习。真要出片，还是得 24G 显存起步。
注意：INT8 量化会损失一部分画质，尤其是快速运动场景容易出现伪影。如果你的片子对画质要求高，别在 20 系上硬扛，直接上云或者换卡。
3.3 本地部署的完整步骤
我把本地部署的流程整理成可复现的步骤，以 Ubuntu 22.04 + RTX 3060 为例：
# 1. 创建虚拟环境 conda create -n minimax-h3 python=3.10 conda activate minimax-h3 # 2. 安装 PyTorch（注意 CUDA 版本要匹配） pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 3. 安装 H3 推理依赖 pip install minimax-h3-inference transformers accelerate bitsandbytes # 4. 下载模型权重（放到指定目录） # 权重文件较大，建议用断点续传工具下载权重下载完之后，推理脚本大致长这样：
from minimax_h3 import H3Pipeline pipe = H3Pipeline.from_pretrained( "./models/minimax-h3", torch_dtype="int8", # 20系显卡用 int8 device_map="auto" ) video = pipe( prompt="一只橘猫在窗台上晒太阳，镜头缓慢推进", num_frames=24, # 约 3 秒 resolution=512, guidance_scale=7.5 ) video.save("output.mp4")几个关键参数说明：num_frames控制时长，24 帧约等于 3 秒；resolution在低显存下必须降到 512；guidance_scale越高越贴合提示词，但太高会失真，7-8 是常用区间。
3.4 提示词写多少字才够：5 秒视频的经验值
热词里有人问“minimax h3 生成 5 秒视频提示词需要多少字”。我实测下来，5 秒视频的提示词控制在 30-60 个中文字符最合适。太短了模型自由发挥，画面容易跑偏；太长了模型抓不住重点，反而稀释了核心描述。
一个好的 5 秒提示词结构是：主体 + 动作 + 环境 + 镜头语言。比如“一只橘猫在窗台上伸懒腰，午后阳光，镜头缓慢推进”。四个要素齐全，40 个字左右，出片稳定性最高。
4. 免密打通 Claude Code 与 Cursor：完整配置流程
4.1 为什么要在 Claude Code 和 Cursor 里接 MiniMax
Claude Code 和 Cursor 是目前最火的两个 AI 编程客户端。前者是命令行里的编程助手，后者是带 AI 的代码编辑器。它们默认接的是国外的模型服务，但很多人想换成 MiniMax，原因无非两个：一是成本，二是网络稳定性。
“免密打通”这个词有点误导，其实不是真的不用密钥，而是指配置一次之后，客户端自动读取环境变量，不用每次手动填。下面我把两个客户端的配置都讲清楚。
4.2 Claude Code 的安装与配置
Claude Code 的安装，不同系统不一样。Ubuntu 和 macOS 用 npm 装最省事：
# 安装 Claude Code npm install -g @anthropic-ai/claude-code # 验证安装 claude --versionWindows 10 的话，建议先装 WSL2，然后在 WSL 里按上面的步骤装。原生 Windows 支持一直不太稳定，我试过几次都有各种路径问题，WSL 是最省心的方案。
装完之后配置 MiniMax 作为后端。Claude Code 支持自定义 API 端点，你需要设置两个环境变量：
# 写入 shell 配置（~/.bashrc 或 ~/.zshrc） export ANTHROPIC_BASE_URL="https://api.minimax.chat/v1" export ANTHROPIC_API_KEY="你的 MiniMax API Key"然后source ~/.bashrc生效。这时候再运行claude，它就会走 MiniMax 的接口了。所谓“免密”，就是这一步环境变量配好之后，后续所有会话自动读取，不用重复输入。
提示：MiniMax 的 API 端点和 Anthropic 官方不完全兼容，部分高级功能（比如某些工具调用格式）可能不支持。日常写代码、解释代码、生成测试用例没问题，复杂 agent 流程要实测。
VS Code 里也有 Claude Code 的插件，装完之后在设置里搜 “Claude Code”，把 API 端点填进去就行。插件版的好处是能直接在编辑器里选中代码提问，不用切终端。
4.3 Cursor 的配置与中文设置
Cursor 的配置比 Claude Code 直观，因为它是图形界面。步骤是：
- 打开 Cursor，按
Ctrl+Shift+P（Mac 是Cmd+Shift+P）打开命令面板 - 搜索 “Cursor Settings”，进入设置
- 找到 “Models” 标签页
- 在 “OpenAI API Key” 或自定义模型区域，填入 MiniMax 的 API Key 和 Base URL
Cursor 支持自定义模型端点，把 Base URL 改成 MiniMax 的地址，模型名填 MiniMax 支持的模型标识就行。
关于中文设置，热词里问得特别多。Cursor 本身是英文界面，但AI 回复的语言可以设置成中文。方法是在设置里找到 “Rules for AI” 或者 “Custom Instructions”，填入一句：“请始终用中文回复。”这样 AI 生成的解释、注释、对话都会是中文。界面本身的汉化，目前官方没有内置，只能靠插件或者等更新。
Cursor 注册时手机号怎么填，也是高频问题。Cursor 支持邮箱注册，不一定非要手机号。如果走手机号，国内号码在部分时段可能收不到验证码，建议优先用邮箱或者第三方账号登录。
4.4 第三方 API 使用技巧与常见报错
接第三方 API 最容易遇到的报错就是热词里那个：llm-deepseek: no api key for provider route "deepseek-official"。这个报错的意思是，客户端找不到对应 provider 的 API Key。排查思路是：
- 确认环境变量名写对了（大小写敏感）
- 确认环境变量在当前 shell 会话里生效了（
echo $ANTHROPIC_API_KEY验证） - 确认客户端的配置文件里没有覆盖环境变量
还有一个常见问题是响应速度慢。Cursor 响应慢，很多时候不是模型的问题，而是网络链路的问题。可以试试在设置里调低上下文长度，或者关掉一些实时索引功能。
| 报错/问题 | 可能原因 | 解决方法 |
|---|---|---|
| no api key for provider | 环境变量未生效 | 重新 source 配置或重启终端 |
| 响应速度慢 | 上下文过长/网络链路 | 降低上下文、检查网络 |
| 模型不识别 | 模型名写错 | 对照官方文档核对标识 |
| 中文回复不生效 | 未设置 Custom Instructions | 在设置里加中文指令 |
5. 常见问题与排查技巧实录
5.1 迁移 M Plan 后的额度异常排查
迁移之后如果发现额度消耗比预期快，先别慌。我遇到过两种情况：一是旧套餐的额度没有正确结转，二是某些模态的换算系数和你预估的不一样。排查方法是拉出最近 7 天的调用日志，按模态分类统计，算出实际消耗比例，再对照 M Plan 的档位看是否合理。如果差异超过 20%，建议直接找官方支持核对。
5.2 H3 本地部署的显存溢出处理
显存溢出（OOM）是本地部署最常见的坑。除了降分辨率和开量化，还有几个技巧：一是把num_frames降到最低先跑通流程，再逐步加；二是关掉其他占显存的程序（浏览器、其他 AI 工具）；三是用torch.cuda.empty_cache()在每次生成后手动清缓存。如果这些都试了还是 OOM，那就是显卡真的不够，别硬撑。
5.3 Claude Code 与 Cursor 的协同使用
我的实际工作流是两个一起用：Cursor 负责写代码和改代码，Claude Code 负责在终端里跑命令、解释报错、生成脚本。两个客户端共用同一个 MiniMax API Key，额度也是共享的。这样一套下来，基本覆盖了从写代码到调试的全流程，而且成本比分别订阅两个国外服务低不少。
5.4 一些没人告诉你的小技巧
- Claude Code 的在线升级，用
npm update -g @anthropic-ai/claude-code就行，别去官网重新下载。 - Cursor 的免费额度有限，重度使用建议直接上付费档，或者接自己的 API Key。
- MiniMax CLI 工具可以批量测试 API 连通性，部署前先跑一遍能省很多事。
- 提示词泄露这个问题，Cursor 社区讨论很多，核心建议是别把敏感代码放进上下文，或者用本地模型处理敏感部分。
6. 我个人的迁移决策与后续扩展
回到最开始的问题：Token Plan 迁移到 M Plan，到底值不值。我自己的答案是值，但前提是你确实是多模态混用。如果你只是偶尔调一下文本 API，那这次改动对你影响不大，不用折腾。
H3 视频解禁这件事，我觉得对独立开发者是个利好。本地部署虽然对显卡有要求，但至少给了你一个不依赖 API 额度的选项。20 系显卡能跑低分辨率短片，做原型验证足够了。真要出商业片，还是云上跑更稳。
Claude Code 和 Cursor 接 MiniMax 这套组合，我用了大概三周，稳定性比我预期好。唯一要注意的是部分高级功能不兼容，遇到问题先查是不是端点不支持，别急着怀疑配置。
后续我打算把 H3 的本地部署再优化一下，试试用 LoRA 微调出特定风格的短片生成能力。如果跑通了，再写一篇详细的微调实录。这个方向目前资料不多，踩坑是肯定的，但值得试。
