實(shí)測(cè)百萬token上下文模型MiniMax-M1：RAG真的要被淘汰了？
我還在電腦前測(cè)試一個(gè)新模型，突然意識(shí)到一個(gè)問題讓我興奮得睡不著覺。
你有沒有想過，如果AI能"記住"一整本書的內(nèi)容，會(huì)發(fā)生什么？不是那種似是而非的"記住"，而是真正的、完整的、一字不漏的記住。
前兩天，MiniMax發(fā)布了最新模型——MiniMax-M1，直接把上下文拉到了一百萬token！
這是什么概念？我花了一晚上測(cè)試，發(fā)現(xiàn)它相當(dāng)于能一次性"讀完"300頁的書，而且全程幾乎不忘記任何細(xì)節(jié)。
從卡茲克的文章?? 作為一個(gè)每天都要處理大量文檔的人，我當(dāng)時(shí)的第一反應(yīng)是：臥槽，這不是要革命了嗎？ 更勁爆的是，這個(gè)消息一出，連VentureBeat這種美國(guó)頂級(jí)科技媒體都專門報(bào)道了。 VentureBeat報(bào)道 要知道，VentureBeat可是"美國(guó)前十科技網(wǎng)站"之一，能被他們關(guān)注說明這事兒確實(shí)不小。 說實(shí)話，我等這樣的模型等了很久很久。 很多時(shí)候，我想讓AI幫我分析一份上百頁的調(diào)研報(bào)告。結(jié)果呢？DeepSeek模型直接甩給我一句"達(dá)到對(duì)話長(zhǎng)度上限"。 DeepSeek上下文限制 那一刻我就想，什么時(shí)候AI能像人一樣，可以完整地讀完我提供的全部資料再和我交流？ 你們肯定也遇到過這種情況：想讓AI總結(jié)一篇50頁的論文，它告訴你太長(zhǎng)了；想分析一個(gè)完整的項(xiàng)目代碼，它說放不下；想處理一份詳細(xì)的商業(yè)計(jì)劃書，還是放不下... 超長(zhǎng)內(nèi)容被自動(dòng)轉(zhuǎn)為文件 或者即使可以放下，但經(jīng)常感覺給你的回答是碎片式的，遺漏了一大塊重要內(nèi)容。 因?yàn)檫@些功能背后每次都得用RAG（檢索增強(qiáng)生成），需要把文檔切成小塊，讓AI一點(diǎn)點(diǎn)處理。 AI對(duì)話和RAG 但說句心里話，這就像讓一個(gè)人戴著眼罩摸象——只能感知局部，很難把握全貌。 遇到這種要上傳資料的場(chǎng)景，我經(jīng)常懷疑AI是不是真的理解了我要表達(dá)的完整意思。 現(xiàn)在好了！百萬token直接把整頭大象都塞給AI，讓它完整地"看"和"理解"。這種感覺，就像給AI做了近視手術(shù)，突然世界都清晰了。 國(guó)內(nèi)也有公司吹過百萬上下文，但我都試過，很多都是用RAG做的假象。 各模型上下文對(duì)比 這次M1是真正原生的百萬Token上下文！我這兩天測(cè)試下來，真的是又驚又喜。 從MiniMax的報(bào)告可以看到，在長(zhǎng)上下文理解的評(píng)測(cè)標(biāo)準(zhǔn)MRCR上，M1的表現(xiàn)穩(wěn)穩(wěn)進(jìn)入第一梯隊(duì)，幾乎和谷歌Gemini比肩！ MiniMax M1 體驗(yàn) 但數(shù)字是一回事，實(shí)際體驗(yàn)又是另一回事。 我最感興趣的是TAU-bench（代理工具使用場(chǎng)景）的表現(xiàn)。這個(gè)測(cè)試很有意思，專門測(cè)試AI在復(fù)雜多輪對(duì)話中調(diào)用工具的能力。 結(jié)果讓我眼前一亮：M1不僅領(lǐng)跑所有開源模型，還戰(zhàn)勝了Gemini-2.5 Pro，和OpenAI O3分?jǐn)?shù)接近，只是稍遜于Claude 4 Opus。 要知道，OpenAI O3、Gemini-2.5 Pro、Claude 4 Opus都是海外頂級(jí)閉源模型，每個(gè)都是"神仙"級(jí)別的存在。 M1開源地址：https://github.com/MiniMax-AI/MiniMax-M1 M1不但完全開源，性能還能接近這些大佬，作為一個(gè)開源愛好者，我內(nèi)心真的很激動(dòng)。 這意味著什么？意味著我們終于有了一個(gè)既開源又強(qiáng)大的選擇，不用再受制于海外閉源模型的各種限制了！ 更讓人震驚的是訓(xùn)練成本。 得益于他們獨(dú)創(chuàng)的閃電注意力機(jī)制和CISPO強(qiáng)化學(xué)習(xí)算法，整個(gè)強(qiáng)化學(xué)習(xí)階段只用了512塊H800三周時(shí)間，總花費(fèi)53.47萬美金。 這個(gè)成本低到什么程度？比預(yù)期少了一個(gè)數(shù)量級(jí)！ API價(jià)格也很親民，32k上下文下，百萬Token不到1塊錢。還采用了分段計(jì)費(fèi)，用多少付多少。 第一時(shí)間，我就跑去了官方網(wǎng)站：https://chat.minimax.io/ 官網(wǎng)：https://chat.minimax.io/ 這里有個(gè)小細(xì)節(jié)要注意：一定要選擇chat模式并打開Thinking模式，我開始就是因?yàn)闆]注意這個(gè)設(shè)置，還在納悶怎么效果一般般。 我用官方的案例做了個(gè)迷宮生成器測(cè)試，效果真的讓我眼前一亮。 我用了下面的提示詞： Create a maze generator and pathfinding visualizer. Randomly generate a maze and visualize A* algorithm solving it step by step. Use canvas and animations. Make it visually appealing. 沒想到它真的做出來了，而且效果比我想象的還要好！ 還有一個(gè)驚喜是他們的Agent模式。我受到沃垠文章???我用MiniMax Agent做PPT，實(shí)在太爽了??的啟發(fā)，試了試讓AI做PPT，結(jié)果做得還真不錯(cuò)。 我把鏈接貼出來給大家看看：??https://agent.minimax.io/share/281365721911444?? 老實(shí)說，看到這個(gè)生成的PPT時(shí)，我在電腦前愣了好一會(huì)兒——頁面簡(jiǎn)潔干凈，審美居然還挺在線的。 我們也可以用官方API調(diào)用，官方的API性價(jià)比和穩(wěn)定性都是最好的。 官方API：https://platform.minimaxi.com/document/platform%20introduction 說實(shí)話，配置Cherry Studio的時(shí)候，我內(nèi)心是忐忑的。因?yàn)橹霸囘^太多模型，總是在關(guān)鍵時(shí)刻掉鏈子。 但M1真的給了我驚喜。我把它配置為主模型，搭配了聯(lián)網(wǎng)MCP、Arxiv論文MCP、代碼MCP、下載MCP等好幾個(gè)工具。 然后我做了個(gè)大膽的嘗試：丟給它一個(gè)超級(jí)復(fù)雜的任務(wù)——"搜索多智能體系統(tǒng)相關(guān)論文，下載第一篇PDF，然后讀取并總結(jié)要點(diǎn)"。 說完這句話，我就去刷了個(gè)短視頻，心想："看看這次又會(huì)在哪里卡住。" 結(jié)果呢？當(dāng)我回來的時(shí)候，M1不僅完成了任務(wù)，還給了我一個(gè)意外驚喜：它在Arxiv搜索失敗后，竟然自己想辦法，切換到聯(lián)網(wǎng)搜索找到了相關(guān)論文，然后下載、翻譯、總結(jié)，一氣呵成！ 自主規(guī)劃MCP調(diào)用 那一刻我真的有點(diǎn)感動(dòng)，就像看到一個(gè)聰明的助手不僅完成了任務(wù)，還超額完成了。這種感覺，用過的人都懂。 說到Claude Code，我的心情很復(fù)雜。 一方面它確實(shí)很強(qiáng)大，但另一方面門檻實(shí)在太高了： 前幾天我熬夜整理了一份claude-code終極平替指南，當(dāng)時(shí)對(duì)于長(zhǎng)上下文模型推薦的是Gemini方案。但說實(shí)話，網(wǎng)絡(luò)問題依然讓人頭疼。 Claude Code 平替指南：https://github.com/yzfly/claude-code-deepseek-quickstart 現(xiàn)在有了M1，我終于可以松一口氣了！不用翻墻，不用擔(dān)心封號(hào)，性能還不差，這種感覺真的很爽。 Claude Code 配置 我昨晚就把配置改了，跑了幾個(gè)項(xiàng)目測(cè)試，體驗(yàn)還不錯(cuò)。 如果你也想嘗試一下Claude Code，建議試試下面這個(gè)配置： 用Trae自帶模型總是遇到排隊(duì)，浪費(fèi)時(shí)間： 配置M1后，編程場(chǎng)景下的長(zhǎng)上下文處理能力大大提升： 我日常用DeepSeek和Qwen-Max，現(xiàn)在又多了一個(gè)優(yōu)秀選擇。 關(guān)于"上下文能否取代RAG"這個(gè)話題，我和很多朋友爭(zhēng)論過。但這次用了M1之后，我更加堅(jiān)信：當(dāng)模型上下文足夠長(zhǎng)時(shí)，很多復(fù)雜的RAG場(chǎng)景真的會(huì)變得極其簡(jiǎn)單。 IBM的 RAG 架構(gòu)示例，已經(jīng)算不復(fù)雜的了 為什么這么說？我給你舉個(gè)真實(shí)的例子。 前兩周，我需要分析一篇50頁的技術(shù)論文。按照以前的做法，我得把PDF切成幾塊，然后讓AI分別處理，最后再人工整合。光是這個(gè)流程就要折騰1個(gè)多小時(shí)，而且效果還不一定好。 有了M1的百萬上下文，我直接把整個(gè)PDF的內(nèi)容丟給它："幫我總結(jié)這篇論文的核心觀點(diǎn)、技術(shù)創(chuàng)新點(diǎn)和潛在應(yīng)用場(chǎng)景。"然后我就去干別的事情了，幾分鐘后回來發(fā)現(xiàn)它已經(jīng)給了我一份詳細(xì)的分析報(bào)告。 那一刻我想：這不就是我一直期待的AI助手嗎？ 于是我花了一個(gè)通宵，基于M1的長(zhǎng)上下文能力做了這個(gè)MCP： fullscope-mcp-server GitHub鏈接：https://github.com/yzfly/fullscope-mcp-server 功能很簡(jiǎn)單，但很實(shí)用： MCP功能特性 使用下面的配置就可以配置這個(gè)MCP Server，記得換成你自己的MiniMax API Key： Cherry Studio 配置MCP 把這個(gè)MCP配置到Cherry Studio以后，我測(cè)試了一個(gè)50多頁的PDF。 50頁P(yáng)DF 從發(fā)送指令到得到完整總結(jié)，只用了不到5分鐘就完成了。以前這種任務(wù)，我得花上一個(gè)小時(shí)。 看到這份完整的PDF總結(jié)時(shí)，我內(nèi)心真的很激動(dòng)。這種感覺就像又找到了一個(gè)能解決我痛點(diǎn)需求的助手。 有個(gè)小細(xì)節(jié)要注意：因?yàn)樘幚肀容^耗時(shí)，記得把超時(shí)設(shè)置調(diào)到300秒。我開始設(shè)置太短，總是中途斷掉，后來才發(fā)現(xiàn)這個(gè)問題。 去年好像是剛哥問過我，最期待大模型哪方面突破，當(dāng)時(shí)我回答的就是「真正的上下文」。 今年我們應(yīng)該會(huì)很快步入AI全員百萬上下文時(shí)代！ 今年年初Grok3發(fā)布后，我在微軟做分享時(shí)就提到一個(gè)觀點(diǎn)：當(dāng)模型上下文越來越長(zhǎng)，我們還需要現(xiàn)在這么復(fù)雜的RAG流程嗎？ 當(dāng)時(shí)很多人覺得我太樂觀，但現(xiàn)在M1的表現(xiàn)讓我更加確信這個(gè)判斷。 直接放到上下文中不就行了？為什么要繞那么多彎？ 這就是我做這個(gè)MCP Server的初衷，像Manus提出的一樣：less structure, more intelligence 讓模型的真正能力賦能AI產(chǎn)品，而不是被復(fù)雜的工程架構(gòu)束縛住手腳。 本文轉(zhuǎn)載自????????云中江樹????????，作者：云中江樹
為什么百萬上下文讓我這么激動(dòng)？
性能到底怎么樣？
成本控制更是絕了
如何體驗(yàn)？
四大實(shí)用場(chǎng)景
01 在Cherry Studio中調(diào)用
02 Claude Code的長(zhǎng)文本平替
{
"OPENAI_API_KEY": "sk-xxx",
"OPENAI_BASE_URL": "https://api.deepseek.com",
"OPENAI_MODEL": "deepseek-chat",
"Providers": [
{
"name": "deepseek",
"api_base_url": "https://api.deepseek.com",
"api_key": "sk-xxx",
"models": ["deepseek-reasoner", "deepseek-chat"]
},
{
"name": "MiniMax",
"api_base_url": "https://api.minimaxi.com/v1",
"api_key": "xxx",
"models": ["MiniMax-M1"]
}
],
"Router": {
"background": "deepseek,deepseek-chat",
"think": "deepseek,deepseek-reasoner",
"longContext": "MiniMax,MiniMax-M1"
}
}03 告別Trae排隊(duì)煩惱
04 無需RAG的長(zhǎng)文MCP Server
{
"mcpServers": {
"fullscope-mcp": {
"command": "uvx",
"args": ["fullscope-mcp-server"],
"env": {
"OPENAI_API_KEY": "xxx",
"OPENAI_BASE_URL": "https://api.minimaxi.com/v1",
"OPENAI_MODEL": "MiniMax-M1",
"MAX_INPUT_TOKENS": "900000",
"MAX_OUTPUT_TOKENS": "8000"
}
}
}
}
AI上下文的重要轉(zhuǎn)折點(diǎn)
