前兩天把 MiniMax Coding Plan 的賬單規(guī)則從頭到尾捋了一遍又對照著幾個(gè)朋友的用量記錄算了幾筆賬發(fā)現(xiàn)大部分人對這套計(jì)費(fèi)方式的理解還停留在“花一筆月費(fèi)隨便用”的階段。其實(shí) Coding Plan 的真實(shí)計(jì)費(fèi)結(jié)構(gòu)比表面看到的訂閱制復(fù)雜不少它更像是一套“固定費(fèi)用 按量配額 超額自動(dòng)疊加”的組合模型。這篇文章我不打算粘貼官方文檔而是把真實(shí)的計(jì)費(fèi)規(guī)則拆開揉碎講講配額到底怎么算、哪些地方悄悄吃 token、視頻生成和文本模型為什么單算、怎么用日志估算自己的月度成本以及我踩過的幾個(gè)賬單翻車現(xiàn)場。適合剛接觸 Coding Plan 的開發(fā)者也適合給團(tuán)隊(duì)做技術(shù)選型或成本預(yù)估的產(chǎn)品、運(yùn)營同學(xué)參考。1. 先搞懂 Coding Plan 的計(jì)費(fèi)模型才不會(huì)看錯(cuò)賬單1.1 訂閱制只是表面配額制才是本質(zhì)很多人第一次看到“Plan”這個(gè)詞就默認(rèn)它是類似視頻網(wǎng)站會(huì)員那種“交了錢隨便看”的模式。但 MiniMax Coding Plan 的底層邏輯更接近流量套餐你付一筆固定的月費(fèi)買到的是某一組資源的配額而不是無限使用權(quán)?？梢园堰@套模型類比成手機(jī)流量包。包月費(fèi)對應(yīng)“基礎(chǔ)月費(fèi)”流量配額對應(yīng)“可用的 token 數(shù) / 生成秒數(shù) / 請求次數(shù)”而超出配額之后的用量要么被限速要么按一個(gè)比套餐內(nèi)單價(jià)更高的費(fèi)率繼續(xù)計(jì)費(fèi)。關(guān)鍵就在于套餐內(nèi)給你的是一個(gè)“可用額度”而不是一個(gè)“消費(fèi)總價(jià)”。這個(gè)額度用不完不會(huì)退用超了卻會(huì)額外扣錢。所以正確理解賬單的第一步是把注意力從“我交了多少錢”轉(zhuǎn)移到“我這個(gè)月還剩多少額度”。你在 Coding Plan 后臺(tái)看到的剩余 token 數(shù)、剩余視頻生成秒數(shù)才是真正決定這個(gè)月最終賬單的核心變量。1.2 為什么文本、視頻、代碼模型要分開計(jì)費(fèi)Coding Plan 并不是一個(gè)模型獨(dú)占的套餐它通常覆蓋多個(gè)模型。從最近大家討論熱度比較高的幾個(gè)名稱來看文本推理模型比如 m3、m3.1 這類和視頻生成模型比如 h3 這類在計(jì)費(fèi)維度上完全不是一回事。文本模型按 token 計(jì)費(fèi)輸入多少、輸出多少都會(huì)折算成 token 數(shù)。視頻生成模型按“生成秒數(shù)”或“生成次數(shù)”計(jì)費(fèi)你讓它生成一個(gè) 5 秒的鏡頭消耗的是視頻算力額度。代碼相關(guān)能力可能又單獨(dú)核算或者通過工具鏈調(diào)用時(shí)按工具調(diào)用次數(shù)、上下文 token 數(shù)疊加。這樣拆分不是平臺(tái)故意復(fù)雜化而是因?yàn)閮深惸Ｐ偷耐评沓杀窘Y(jié)構(gòu)差異巨大。文本模型的核心成本在 transformer 的逐 token 解碼視頻模型的成本在擴(kuò)散模型的多步去噪和時(shí)序建模單位算力成本根本不是一個(gè)量級。理解這一點(diǎn)你就明白為什么“套餐里的文本 token 額度”不能拿去生成視頻也明白為什么視頻生成往往單獨(dú)有一個(gè)“秒數(shù)配額”的項(xiàng)目。1.3 計(jì)費(fèi)周期里的隱藏變量重置、結(jié)轉(zhuǎn)與生效時(shí)間Coding Plan 的計(jì)費(fèi)周期一般按自然月或訂購周期刷新配額。這中間有幾個(gè)容易看漏的變量配額刷新時(shí)間不一定是你下單的時(shí)間可能是每月 1 號(hào)也可能是你開通套餐的當(dāng)日。未用完的配額是否結(jié)轉(zhuǎn)我見過不少套餐是不結(jié)轉(zhuǎn)的月底自動(dòng)清零月初重新給滿。超額后的計(jì)費(fèi)窗口是從哪一刻開始生效有些規(guī)則是“用完立即按量計(jì)費(fèi)”有些是“用完繼續(xù)用月底統(tǒng)一結(jié)算”兩者對賬單波動(dòng)的體感完全不同。如果說前面幾點(diǎn)是計(jì)費(fèi)模型的“骨架”周期規(guī)則就是“血管”。不理解重置時(shí)間你很可能在月底最后一天收到了超量扣費(fèi)通知還以為是平臺(tái)算錯(cuò)了。1.4 免費(fèi)額度和試用期的“試用陷阱”很多用戶是用免費(fèi)額度或試用期入坑的。免費(fèi)額度聽起來很美好但它往往有三層限制有效期短通常在開通后的幾天到一個(gè)月內(nèi)有效過期作廢。只限指定模型免費(fèi)額度可能只覆蓋某個(gè)基礎(chǔ)文本模型不能用于 h3 視頻生成或最新 m3.1 系列。不計(jì)入套餐抵扣免費(fèi)額度用完后你可能直接進(jìn)入“按量計(jì)費(fèi)”通道而不是自動(dòng)銜接你后來購買的 Coding Plan 配額。我見過最離譜的情況是用戶先用完了免費(fèi)額度又開了套餐結(jié)果套餐配額沒有立即生效中間幾小時(shí)的請求全走了按量計(jì)費(fèi)賬單一下多了幾十塊。所以注冊后第一件事是去后臺(tái)把“免費(fèi)額度、套餐配額、按量余額”三個(gè)數(shù)字分別記下來。2. 計(jì)費(fèi)規(guī)則的核心細(xì)節(jié)四個(gè)最容易踩坑的參數(shù)2.1 輸入 token 和輸出 token 不是同一種價(jià)格幾乎所有文本模型的計(jì)費(fèi)都會(huì)區(qū)分輸入與輸出Coding Plan 里的文本模型配額也遵循這個(gè)邏輯。為什么因?yàn)槟Ｐ吞幚磔斎霑r(shí)只需要并行計(jì)算一遍而生成輸出時(shí)必須一個(gè) token 一個(gè) token 地順序解碼耗時(shí)和算力開銷大得多。所以輸出單價(jià)一般顯著高于輸入單價(jià)。舉個(gè)具體例子。假設(shè)你做一次代碼補(bǔ)全請求系統(tǒng)提示詞加上上文有 600 個(gè)輸入 token模型生成了 150 個(gè)輸出 token。賬單上不會(huì)按“750 token”計(jì)算而是 600 個(gè)輸入 token 和 150 個(gè)輸出 token 分別計(jì)價(jià)。如果只看“總 token 數(shù)”去估算成本大概率會(huì)低估。這種差異在 Coding Plan 配額里也有體現(xiàn)套餐配額可能會(huì)區(qū)分“輸入 token 配額”和“輸出 token 配額”或者統(tǒng)一給一個(gè) token 池但按不同權(quán)重抵扣。我建議在使用前先看文檔中的“token 計(jì)費(fèi)權(quán)重說明”別把“配額還剩下幾百萬 token”理解成所有 token 都等值。2.2 上下文窗口的隱藏費(fèi)用對話越長每次請求越貴這是最隱蔽的賬單增長點(diǎn)。不少人覺得多輪對話就是把新問題發(fā)給模型但實(shí)際每次請求都會(huì)攜帶整個(gè)會(huì)話歷史作為輸入。也就是說你問第 10 個(gè)問題時(shí)前 9 輪對話的 token 又被重新計(jì)算了一次輸入費(fèi)用。寫代碼時(shí)這個(gè)問題尤其明顯。如果你讓模型基于一個(gè)大型代碼倉庫做“跨文件理解”系統(tǒng)會(huì)把相關(guān)文件片段、調(diào)用鏈、報(bào)錯(cuò)棧全部塞進(jìn)上下文。表面上看你只生成了一小段代碼實(shí)際上每次請求都背著幾千甚至幾萬 token 的“上下文包袱”在跑。我做過一個(gè)測試在代碼生成場景中一個(gè)上下文約 6000 token 的請求輸出只有 200 token但賬單上消耗的輸入 token 卻是 6000。如果一天發(fā) 50 次這種請求輸入 token 就吃掉 30 萬而實(shí)際有用的輸出才 1 萬?？刂粕舷挛拈L度比優(yōu)化提示詞更能省成本。Coding Plan 的配額在上下文這個(gè)維度上同樣會(huì)“按實(shí)際消耗扣除”。不是按你“看到”的回復(fù)長度扣而是按模型實(shí)際處理的完整 token 序列扣。這一點(diǎn)請務(wù)必牢記。2.3 超額之后到底發(fā)生了什么限速、停服還是自動(dòng)扣費(fèi)不同平臺(tái)的超限策略不一樣Coding Plan 的超額機(jī)制一般有三種可能軟限流超過配額后請求變慢排隊(duì)時(shí)間拉長但不直接失敗。熔斷超過某個(gè)月的硬上限后接口直接報(bào)錯(cuò)必須等下個(gè)周期恢復(fù)。自動(dòng)按量計(jì)費(fèi)配額用完后不停止服務(wù)但會(huì)使用“按量余額”繼續(xù)跑按量單價(jià)通常高于套餐內(nèi)單價(jià)。最怕的是第三種。因?yàn)榘戳坑?jì)費(fèi)沒有“包月”的緩沖價(jià)格又是純增量計(jì)費(fèi)如果團(tuán)隊(duì)的自動(dòng)化任務(wù)在夜間跑批幾小時(shí)就能把預(yù)算燒穿。所以開通 Coding Plan 之后第一件事不是去寫代碼而是去設(shè)置預(yù)算提醒和硬性消費(fèi)上限。哪怕平臺(tái)默認(rèn)沒有強(qiáng)制上限我也建議自己在調(diào)度層加一道“單日調(diào)用量閘門”。2.4 視頻生成計(jì)費(fèi)的特殊性提示詞和時(shí)長都被計(jì)入成本結(jié)合最近很多人討論的 h3 視頻模型我發(fā)現(xiàn)大家對視頻生成的計(jì)費(fèi)誤解更深。有人以為“生成一條 5 秒視頻”就按 5 秒固定扣費(fèi)實(shí)際上視頻生成的成本還和提示詞長度、分辨率、是否使用參考圖、生成步數(shù)相關(guān)。比如“MiniMax h3 參考生視頻的分鏡怎么寫”這個(gè)需求本身就要寫較長分鏡提示詞。分鏡寫得太細(xì)輸入 token 消耗自然上升而視頻生成又按秒數(shù)或次數(shù)獨(dú)立配額。如果你采用“先寫分鏡、再逐鏡頭生成”的流程可能前面文本部分消耗了文本額度后面視頻部分消耗了視頻額度兩筆配額同時(shí)下降。另一個(gè)容易低估的細(xì)節(jié)是重試成本。畫風(fēng)不對、鏡頭運(yùn)動(dòng)不自然你重試一次就再扣一次生成配額。所以不要拿正式額度去試 prompt用免費(fèi)額度或者低配選項(xiàng)先跑通分鏡腳本再上高分辨率正式生成。3. 實(shí)操推導(dǎo)怎么算清楚自己要不要買、買哪一檔3.1 從“跑分高”到“賬單低”還差著十萬八千里最近大家都在看 m3.1 的跑分我也圍觀了不少 benchmark 對比。但必須潑一盆冷水跑分衡量的是模型能力強(qiáng)不強(qiáng)計(jì)費(fèi)模型衡量的是你用得起用不起兩者沒有直接關(guān)系。一個(gè)跑分很高的模型如果輸入輸出定價(jià)高日常高頻調(diào)用反而比跑分稍低但更便宜的舊模型更費(fèi)錢。所以選套餐前不要看跑分榜選模型要看“你的任務(wù)類型更吃輸入還是輸出更吃短請求還是長上下文”。比如做代碼補(bǔ)全高頻小請求為主應(yīng)該優(yōu)先看輸入 token 單價(jià)和套餐內(nèi)輸入配額做長文總結(jié)或智能體多輪推理輸出 token 和上下文窗口才是成本大頭跑分高帶來的少走彎路可能反而省 token。我自己的習(xí)慣是先列一個(gè)“用量灰度表”把一周內(nèi)所有請求按模型、輸入 token 數(shù)、輸出 token 數(shù)、請求次數(shù)四個(gè)字段打點(diǎn)然后用 Excel 透視表看總量。沒有這一周數(shù)據(jù)任何套餐建議都是拍腦袋。3.2 本地部署與 Coding Plan 到底哪個(gè)便宜熱詞里有很多 h3 本地部署、顯存占用、量化版的相關(guān)討論。我的看法是不要把本地部署和 Coding Plan 放在同一個(gè)成本維度里比因?yàn)樗鼈儽鹊母静皇峭环蒎X。本地部署是重資產(chǎn)模式。一張能跑 h3 的顯卡或者 AI 加速卡本身就價(jià)格不菲如果你再遇到“h3 量化版 clip 5120 與 4096 不匹配”這類適配問題還要搭進(jìn)去大量調(diào)試時(shí)間。這些硬件折舊和人工成本用“每千 token 多少錢”很難量化。Coding Plan 是輕資產(chǎn)模式。月費(fèi)固定不消耗本地算力也不占顯存。適合那些調(diào)用量波動(dòng)大、不想維護(hù)推理集群、也不愿意折騰量化部署細(xì)節(jié)的團(tuán)隊(duì)。具體怎么取舍我建議算一個(gè)“交叉點(diǎn)”本地部署的總成本硬件分?jǐn)? 電費(fèi) 運(yùn)維人工除以每月估計(jì)調(diào)用量得出單次調(diào)用成本再對比 Coding Plan 套餐內(nèi)單次調(diào)用的折算價(jià)。如果月調(diào)用量長期低于交叉點(diǎn)用套餐明顯高于交叉點(diǎn)且團(tuán)隊(duì)有推理優(yōu)化能力再考慮本地部署。3.3 三個(gè)真實(shí)場景的月度成本估算方法這里放三個(gè)我搭過的估算模型你完全可以照著自己的用量日志替換數(shù)字。場景 A代碼助手重度使用假設(shè)每天 50 次請求每次請求輸入 token 1000輸出 token 500每月按 22 個(gè)工作日算月輸入 token 50 × 1000 × 22 1,100,000月輸出 token 50 × 500 × 22 550,000假設(shè)套餐包含 300 萬輸入 token 和 150 萬輸出 token具體以官方套餐頁為準(zhǔn)那么輸入額度富余輸出有點(diǎn)緊張。一旦每天請求量翻倍到 100 次輸出直接超到 110 萬超出的部分就要走超額計(jì)費(fèi)。這類場景選套餐時(shí)重點(diǎn)看“輸出 token 配額”是否充足。場景 B短視頻團(tuán)隊(duì)批量生成視頻素材假設(shè)每周生成 20 條 5 秒視頻每段視頻的前期分鏡提示詞約 800 字。一個(gè)月約 80 條視頻視頻生成配額80 條 × 5 秒 400 秒文本提示詞消耗800 字折算成 token 大約 1000 到 1200按 80 次計(jì)算約 8 萬到 10 萬 token如果你的套餐只包含 200 秒視頻生成配額那么一個(gè)月要超一倍。這時(shí)候要么升檔要么減少重試次數(shù)。很多團(tuán)隊(duì)忽略重試一條視頻生成三次秒數(shù)配額直接被吃穿。場景 C內(nèi)容團(tuán)隊(duì)批量生成長文本假設(shè)每周寫 40 篇產(chǎn)品文案每篇輸入素材 3000 token輸出 1500 token月輸入 token 40 × 4 × 3000 480,000月輸出 token 40 × 4 × 1500 240,000這個(gè)用量其實(shí)不大但如果你用“多輪對話逐篇修改”上下文翻倍效應(yīng)會(huì)明顯放大成本。改成“每篇新開會(huì)話只攜帶必要背景”輸入 token 可以砍掉一半以上。4. 常見問題與排查技巧實(shí)錄4.1 “為什么賬單比預(yù)算高了 30%”這是最常見的翻車現(xiàn)場。排查時(shí)我習(xí)慣按三個(gè)順序查先查上下文是否被重復(fù)計(jì)入。多輪對話和智能體循環(huán)里歷史信息每輪都算輸入賬單增長曲線一般不是線性的而是加速上漲。再查是否觸發(fā)重試機(jī)制。代碼生成中一次失敗自動(dòng)重試等于同一個(gè)請求跑了兩次甚至三次。最后查配額周期。如果賬單跨了套餐重置點(diǎn)可能一部分用量在舊周期一部分在新周期看起來像雙重收費(fèi)。這三個(gè)里面上下文翻倍效應(yīng)是最容易不知不覺吃掉配額的。我建議在代碼里加一個(gè)日志中間件記錄每次請求的 prompt 字符數(shù)和返回字符數(shù)出現(xiàn)異常波動(dòng)時(shí)第一時(shí)間能定位。4.2 “為什么跑得慢被限速還是并發(fā)配額撞頂”很多用戶把“響應(yīng)慢”直接歸因于模型性能。其實(shí)在 Coding Plan 場景下更常見的原因是同周期內(nèi)并發(fā)請求數(shù)觸頂觸發(fā)了排隊(duì)機(jī)制。h3 這類視頻生成任務(wù)本身就耗時(shí)如果同時(shí)提交多條生成任務(wù)前一條沒結(jié)束后一條不會(huì)立刻處理。區(qū)分方法很簡單單發(fā)一條請求測速度。如果單發(fā)正常、并發(fā)變慢基本就是并發(fā)配額問題如果單發(fā)也慢才需要懷疑模型狀態(tài)或網(wǎng)絡(luò)鏈路。我平時(shí)做批量任務(wù)時(shí)會(huì)在代碼里加一個(gè)簡單的信號(hào)量控制并發(fā)數(shù)把一批任務(wù)打成小隊(duì)列慢慢跑既穩(wěn)定又不至于瞬間把配額打光。4.3 量化版和云端計(jì)費(fèi)的“心理賬戶”誤區(qū)看見“量化版”三個(gè)字很多人的第一反應(yīng)是“本地跑省 API 錢”。但如果你用的是 Coding Plan本地量化版并不能幫你省訂閱費(fèi)因?yàn)槟阋呀?jīng)付了月費(fèi)反過來如果你沒買套餐本地量化版又需要自己承擔(dān)所有硬件和運(yùn)維成本。熱詞里那個(gè)“clip 5120 與 4096 不匹配”的問題就是典型的本地部署適配坑量化模型的某些中間張量維度與顯卡或推理框架不匹配要么需要改代碼要么需要換精度。這種問題在云端 Coding Plan 里不會(huì)遇到因?yàn)槠脚_(tái)已經(jīng)幫你完成模型部署。要我說本地量化適合“長期大規(guī)模調(diào)用且團(tuán)隊(duì)有推理經(jīng)驗(yàn)”的人不適合“為了省一個(gè)月費(fèi)”的人。4.4 我的避坑實(shí)操清單整理幾條我用真金白銀換來的經(jīng)驗(yàn)開通套餐后第一時(shí)間修改預(yù)算提醒設(shè)一個(gè)月消費(fèi)上限的 80% 為告警線。批量任務(wù)永遠(yuǎn)放在低峰時(shí)段跑既能降低排隊(duì)概率也方便在出問題時(shí)及時(shí)熔斷。保存一份官方價(jià)格文檔的截圖或 PDF因?yàn)橛?jì)費(fèi)規(guī)則有過調(diào)整留證方便核對歷史賬單。每個(gè) API Key 單獨(dú)設(shè)置額度避免某個(gè)測試 Key 的異常流量污染整個(gè)賬戶的配額。每周花五分鐘看一次配額消耗趨勢圖不看單日絕對值看 7 日均線和增速斜率。5. 個(gè)人實(shí)操心得與最后一點(diǎn)建議最后聊聊我自己的體會(huì)。MiniMax Coding Plan 這套計(jì)費(fèi)規(guī)則其實(shí)不算復(fù)雜但它把一個(gè)很關(guān)鍵的判斷責(zé)任交給了用戶你必須在購買前想清楚“自己到底消耗什么資源”。平臺(tái)能告訴你套餐包含多少 token、多少秒數(shù)但它不會(huì)告訴你一次運(yùn)行要多長的上下文、失敗重試概率有多高、批量任務(wù)的并發(fā)峰值在哪。這些細(xì)節(jié)只能靠自己的用量數(shù)據(jù)來回答。所以我強(qiáng)烈建議每個(gè)團(tuán)隊(duì)在正式采購前先拿按量模式跑一周灰度把真實(shí) token 消耗、視頻生成秒數(shù)、并發(fā)線程數(shù)全部埋點(diǎn)再拿著這張表去對應(yīng)套餐檔位。如果你問我買哪一檔最劃算我的回答永遠(yuǎn)是先買最低檔跑兩三個(gè)真實(shí)任務(wù)再根據(jù)剩余配額倒推。這樣做看起來慢實(shí)際上比直接拍板上高檔要省錢得多。畢竟計(jì)費(fèi)規(guī)則吃得越透每一分錢才花得越值。