Beam 1.0 開放權重落地：Apache 2.0、Mirror CLI 與部署版本怎麼選？

Beam 1.0 這次的新聞重點，是開放權重與相關工具已經可以取得。Reflection 在 2026 年 10 月 16 日公布權重、分詞工具、參考實作與 Mirror CLI，讓先前預告往實際部署推進。

看模型發布時，很多人會把「宣布能力」和「可以自己下載運行」當成同一件事。但對開發者而言，兩者之間可能還隔著權重、執行框架與硬體支援。

Beam 在十月上旬已經介紹過模型，這次則把可用版本和生態整合公開。因此，如果你之前因為無法自行部署而觀望，現在值得重新檢查條件。

官方把模型、執行工具與合作夥伴放在一起，想建立代理工作生態。不過這不是另一套取代 Windows 或 macOS 的作業系統，仍要依照實際工具和端點理解。

對需要開放模型、可控制執行環境的團隊，這次更新有實際意義。若只是想試幾個問題，先透過服務入口比較，可能比立即架設大型模型更省時間。

要決定怎麼開始，先看這次真正交付了哪些檔案與工作能力。

Beam 1.0 這次釋出的內容與先前預告差在哪裡？

這次把模型可取得性往前推了一步。根據 Reflection 官方公告，釋出內容包括權重、分詞工具與參考實作，並提供不同數值格式版本。

權重是模型訓練後學到的數值，分詞工具則把文字轉成模型處理的單位。兩者配合執行程式，才形成可以實際使用的系統，而不是只有一份能力介紹。

模型與工具需要一起核對

同一套權重，若使用錯誤的提示格式或工具介面，實際表現可能受到影響。因為模型訓練時接觸的是特定工作形式，部署時就需要保留對應條件。

所以開源發布值得看的，不只是下載檔案大小，還包括有沒有範例、模型卡與可運作的參考流程。這些資料會影響團隊從研究到試作所花的時間。

官方也釋出 Mirror CLI，讓開發者有一條接近其工作設計的使用路徑。CLI 是透過文字指令操作的工具，適合把檔案與程式工作接進既有開發環境。

大型模型的活躍參數與設備需求不同

Beam 官方模型資料列出約 5,010 億總參數、230 億活躍參數，採用專家混合架構。這表示每次處理資料只啟用部分專家，但仍需要安排整體權重的儲存與存取。

官方 Beam 模型卡還界定它以文字作輸入與輸出，主要針對英文開發。這和能讀取專案文字、呼叫工具不矛盾，但不能因此當成原生圖片或影片理解模型。

例如代理要分析掃描報告，可能需要先由其他工具辨識成文字，再交給模型。這是可以設計的工作流程，不是本次釋出已證明它能直接看懂每張原圖。辨識錯字也會影響後續推論。

模型卡列出一百萬 token 的上下文，描述單次可容納的資料範圍。它不是所有設備都能低成本開滿的保證，也不代表放進去的每一條資訊，都能在長任務中同樣可靠地取回。

因此不能把 230 億當成全部設備需求。對自行部署的團隊，應依選擇的格式、硬體與服務規模估算，而不是只拿活躍參數和小模型相比。

如果目前沒有對應設備，先用託管端點測任務品質，仍然可以提供有價值的判斷。確認值得導入之後，再研究自架成本，能減少一開始的投入。

BF16、FP8 與 NVFP4 怎麼影響部署？

這些名稱描述模型數值的儲存與計算格式，位元較少通常能減少空間與部分運算負擔。但實際速度與品質，仍取決於硬體和執行框架是否支援。

可以把它想成用不同精細度保存大量數字。數字變精簡，檔案可能更小，但不能直接假設每個設備都會同樣加速，也需要檢查任務表現。

先選硬體能有效執行的格式

BF16、FP8 與 NVFP4 並不是單純的品質等級選單。若某種低精度格式需要特定硬體支援，在不相容環境裡，就可能無法取得預期效果。

因此部署順序應該是先確認設備與推論框架，再選官方提供的相容版本。因為相容性決定能否執行，不能只因下載檔比較小就直接選擇。

三種格式可以先這樣比較。硬體欄參考 NVIDIA 對低精度格式的說明，描述原生運算支援，不是 Beam 在每款顯示卡都已測通的清單。

NVFP4 的縮放資訊也占空間，因此不能只用四除以十六，就認定整體服務記憶體必然剩四分之一。選定版本之後，還要看其他層使用的精度、對話狀態與框架配置。表格沒有提供任何速度保證。

下面整理這些格式在評估時應該關注的方向。

表格中的項目互相影響。例如增加對話長度或同時使用人數，就可能提高記憶體需求，所以不能只拿模型檔大小決定伺服器規格。

推測解碼需要看完整配置

官方也提供用於加速的 drafter。這類組件先提出候選，再由主要模型檢查，目的是降低逐步產生內容的等待。

但額外組件也需要資源，效果會隨任務與硬體改變。因此比較速度時，應記錄是否使用它，以及總記憶體和品質有沒有一起驗證。

若只引用最快示範，卻沒有說明配置，讀者就無法知道自己的環境能否重現。部署決定最好回到可重跑的設定，而不是只看一個速度數字。

Mirror CLI 為何和模型權重一樣重要？

代理需要的不只是回答能力，還包括工具、檔案與工作狀態。Mirror CLI 把這些能力放進使用流程，讓模型有機會持續推進較長的任務。

官方介紹涵蓋檢視活動、批准工具、續接工作與平行代理等方向。這些功能會影響使用者能否理解代理正在做什麼，也決定遇到中斷時如何接續。

官方也說明 Mirror 可以接不同的檢查點或端點，並透過專案指示、技能、MCP 連接與擴充調整流程。這讓模型能力和工作環境分開管理，換一個端點時，仍可以檢查哪些設定需要一起改。

Mirror 的產品層由 Python 前端處理，透過本機連接與 Rust 代理核心溝通。這是官方公布的架構分工，不能單憑使用某種程式語言，就推論整個代理在所有工作都比較快。

工作紀錄能減少交接猜測

假設代理修改了一個專案，但使用者稍後才回來看。如果只留最後一句完成訊息，很難知道它讀過哪些檔案、執行哪些檢查，以及還有哪些問題。

活動紀錄則能幫助使用者回到工作脈絡。因為代理可能做很多步，紀錄應該讓人找到重要改動與證據，而不是要求逐字讀完整段對話。

對團隊來說，這也影響接手工作的人。能看見改動、指令與結果，就比較容易判斷下一步，避免把已經失敗的做法重新跑一次。

批准工具需要明確範圍

讓代理能使用終端機或外部工具，會把影響帶出文字回答。因為它可能讀寫檔案或連接服務，所以批准應對應這次要做的行為。

例如修一個測試錯誤，只需要相關資料夾與測試指令，不必同時開放所有正式系統。範圍越清楚，使用者也越容易判斷代理是否照需求工作。

這些設計不會讓錯誤消失，但能讓錯誤更容易被發現與處理。因此導入代理時，工具控制與可觀察性應和模型成績一起評估。

從授權到自有任務建立導入清單

Beam 權重以 Apache 2.0 釋出，提供了相對明確的開源使用起點。實際採用時，仍應保存當次版本的授權與模型卡，並分開看外部服務、輸入資料和媒體權利。

模型授權不代表託管服務免費，也不會替團隊提供設備維運。因此自架與雲端比較，應把服務、人工和基礎設施一起算進去。

先比較一個能驗收的程式任務

可以選一個已有測試的程式庫，要求修正具體錯誤，並保留不可改動的部分。因為成功條件明確，團隊就能看出模型是否真的改善工作。

執行後檢查差異、測試與執行紀錄，再記錄人工修正時間。若程式能通過測試，卻順手改掉不相關內容，也應算進導入成本。

用完整任務時間衡量速度

代理任務還包含搜尋、讀檔與測試，所以文字生成速度只是其中一部分。若較快模型經常走錯方向，整體完成時間可能反而更長。

可以固定同一組需求，分別測試託管與自行部署配置。這樣比較得到的是你真正需要的工作效率，也比較容易決定是否值得擴大設備。

從一個可取得的端點開始，再決定是否自架

如果尚未準備伺服器，可以先依官方文件選一個實際可用的服務入口，用固定任務確認輸出與工具流程。之後下載權重時，再對照格式、模型版本與執行設定，才知道比較的是不是同一種條件。

例如託管版本已能修好某個程式問題，自架卻無法完成，就先檢查提示格式、工具與加速設定。找到差異之前，不能直接把落差歸因為權重品質。整個代理還包含模型之外的執行環境。

需要客製化的團隊，也應區分已能取得的工具和接下來才釋出的配方。官方十月十六日公告提到自我蒸餾配方預計在之後幾天發布，所以不能只憑公告出現這個方向，就假定完整訓練步驟已經到齊。

延伸閱讀

延伸閱讀：Reflection Beam 發表：501B 開放模型預告，23B 活躍參數代表什麼？

延伸閱讀：Muse Spark Open 開放權重：兩台 Mac Studio 能跑，企業採用還要看什麼？

Beam 1.0 常見問題

這是 Beam 第一次發表嗎？

不是。模型先前已介紹，這次重點是開放權重與工具可取得，應把預告和實際釋出分開。

Apache 2.0 代表所有相關服務都免費嗎？

不代表。權重授權與託管服務、運算設備和其他素材各有條件，需依實際用途分別確認。

有活躍參數較少，就適合一般電腦嗎？

不能直接這樣推論。整體權重、上下文和執行配置仍會決定設備需求，應對照官方部署文件測試。

先確認能重現的配置，再決定部署規模

Beam 這次讓開放模型從預告走到可以實際研究的階段。對開發者，先用一個具體任務確認品質，再比較格式、工具與維護成本，較容易做出有依據的選擇。

想持續追蹤開放模型、代理工具與部署實務，可以免費訂閱 AI 郵報，把每次發布連到自己的工作需求。

資料來源

• 官方原始公告／文件
• 官方原始公告／文件
• X 發布與討論原帖