拿到一整座倉庫的食譜之前，先確認你的冰箱有多大

2026 年 10 月 5 日，Reflection 公布了第一款開放權重模型 Beam：總參數 501B、每次運算啟用 23B，有效上下文號稱一百萬 token，主打破程式開發、推理與代理任務。消息一出，很多企業的採購會議大概已經把 Beam 寫進候選名單了。但公告裡有一句話值得慢慢讀：模型仍在最後的紅隊測試與評估，權重、技術報告和模型卡「預計稍後發布」。

翻成廚房的話，這就像有人在市場裡跟你說：這座倉庫的鑰匙會給你，但鑰匙還在打磨，而且倉庫的清單也還沒印出來。你會先搬進去，還是先量一下自家後門多寬？

食譜拿到了，不等於廚房也拿到了

「開放權重」這四個字，常被想成「整間廚房都搬給你」。其實它比較像拿到一本寫好的食譜，配方的比例都在，但食材從哪進、怎麼處理、爐具有哪些，食譜本身不會告訴你。它也跟開源軟體不是同一回事。能不能商用、能不能微調、能不能再端給別人喫，這些都要看正式授權文本怎麼寫。

Reflection 預告採 Apache 2.0 授權，但在授權檔實際發布、內容跟權重對得上之前，法務那一關其實還沒過。這跟巷口麵店掛出「本月推出新菜」一樣，菜單印出來、菜真的上桌，才算數。把「預計」寫進專案時程當作已交付，是很多廚房開天窗的原因。

五百多公升的大鍋，每次只燒二十三公升的火

Beam 是稀疏混合專家模型（MoE）。這個設計用做菜來想其實很直覺：一間備料齊全的大廚房，冰庫裡躺著五十萬公克的所有材料，但今晚這道菜，真正開火的只有兩萬三千公克。501B 是倉庫的總規模，23B 是每一口鍋實際燒起來的量。

問題是，沒被用到的料不會憑空消失。它們仍然佔著冰庫、佔著貨架、佔著電費。MoE 也一樣：只啟用一部分參數，並不會讓其他權重從 GPU 記憶體裡消失。部署還要算權重精度、量化方式、專家怎麼切、跨卡通訊、併發量這些帳。官方對「推論算力低三至四倍」的估算，也只算了生成階段的浮點運算，提示詞前處理、長上下文的注意力計算和服務開銷都沒算進去。

這就像食譜上寫「這道菜省瓦斯」，但省的只是燉的那段，備料、退冰、保溫的瓦斯都還在轉。我們先前聊湯鍋與瓦斯表的精打細算時提過，帳要算全，鍋才不會煮到一半熄火。

一百萬 token 的餐桌，坐得下不等於坐得舒服

有效上下文一百萬 token，聽起來像一張能坐下一千人的辦桌。但桌子長，上菜的時間也長。長輸入會增加前處理時間、記憶體壓力與延遲，而且這個數字到底代表訓練出來的能力、可設定的上限，還是服務端實際承諾的請求上限，公告裡並沒有說死。

基準測試成績也一樣。Reflection 公布了多項比較，但 TechCrunch 報導指出，這些效能主張尚未經獨立驗證。基準的版本、測試提示、工具設定、生成 token 數，每一項都會讓結果搬家。這跟餐廳試菜是一個道理：廚師自己說好喫，跟熟客喫了再說好喫，是兩種可信度。之前寫廚房裡請人試喫那篇時就聊過，一直自己嚐味道的廚師，最後往往嚐不出問題。

先把清單寫好，鑰匙來了才不慌

回頭看，Beam 公布的資訊能讓團隊理解定位：稀疏 MoE、23.8 兆 token 預訓練、主打程式與代理任務。但規格與效能主張是供應商發布時的說法，不是已由外部重現的結論。發布日期、使用條件、可用地區，都要以正式文件和實際取得狀態為準。

真正務實的做法，其實跟開一間新餐廳沒有兩樣：先量冰庫、先讀租約、先試做一輪菜、先把熟客找來喫一次，再決定要不要把招牌掛上去。權重到手那天，這些功課做完了的人，才煮得動那一大鍋。