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