重點不只是「小模型」，而是把長上下文留在裝置端

iFLYTEK（科大訊飛）全資子公司詞元星火於 2026 年 9 月 1 日推出並開源兩款面向邊緣端的通用語言模型：Spark（星火）X2.5-4B 與 Spark X2.5-1.7B。兩者最大的賣點，是宣稱可在本地裝置上原生支援最長 100 萬 Token 的上下文視窗。

公司稱這是同類邊緣模型中的首例；這項「首創」定位屬於業者主張，尚不等於經第三方獨立驗證的結論。2

這兩款模型採用混合注意力（hybrid-attention）架構，並針對 AI Agent／工具調用、程式設計、數學推理與指令遵循進行調校。iFLYTEK 也表示，它們對比同等規模的開源模型具競爭力，但公告中未提供完整的獨立對照測試結果。2

為何本地端的 100 萬 Token 值得注意？

處理長文件時，常見做法是把使用手冊、政策文件或大型程式碼庫切成多個片段，再依問題檢索部分內容。這種方式實用，但也可能讓模型漏掉另一段中的例外條款、限制條件或程式相依關係。

iFLYTEK 以售後服務手冊為例：若模型能一次讀入整份手冊，便可在退換貨、故障處理、例外情形、物流、資料清除及費用歸屬等不同章節之間交叉判讀。公司的論點是，這可避免文件切塊後，各章節脈絡彼此割裂。2

不過，上下文視窗夠大，並不自動代表模型推理可靠或答案必然正確。實際導入前，仍應針對自己的文件與設備測試檢索品質、長文回應延遲、記憶體需求，以及模型是否真的能正確套用散落在全文各處的規則。

業者提出哪些本地應用與成績？

Spark X2.5 的目標場景包括智慧硬體、車載系統、機器人與物聯網裝置；這些環境往往對網路連線、延遲或資料處理位置有較高要求。3

iFLYTEK 將其定位為可用於本地生產力工作的智慧助手，但目前釋出資訊未列出完整的辦公自動化功能清單，也沒有專門的辦公任務基準測試。2

公司另提出以下能力與測試主張：

• **程式設計：**Spark X2.5-4B 宣稱在演算法實作、程式碼補全與程式碼生成上，可與參數量為其 2 至 3 倍的雲端模型競爭。2
• **智慧家庭：**Spark X2.5-1.7B 在 Domux 智慧家庭測試集上，據稱達到 90.3% 的端到端指令執行正確率，平均回應時間為 0.85 秒。這是特定命名測試集上的業者報告成績，不能直接視為真實環境的普遍保證。2
• **機器人與邊緣控制：**模型被定位為可在裝置端協助操作／控制、目標追蹤與導航決策，降低對持續雲端連線及固定腳本流程的依賴。2

訓練規模與部署工具鏈

依 iFLYTEK 說法，兩款模型全程使用國產算力平台訓練，使用約 20 兆 Token 的多樣化預訓練資料，後續再經監督式微調與強化學習處理。2

公告列出的相容項目包括：

• **硬體：**NVIDIA、華為、海光（Hygon）與 Hemo
• **推論框架：**vLLM、SGLang、llama.cpp
• **部署途徑：**Ollama、LM Studio
• **增量微調：**LLaMA-Factory

實際速度與記憶體占用仍會受到模型版本、量化設定、使用的上下文長度及目標硬體影響。2

權重在哪裡？API 免費到何時？

iFLYTEK 表示，模型權重、程式碼庫與部署文件均已公開，並可透過 Hugging Face 與 GitHub 取得；同時也在其 Starry MaaS 平台提供相關 API 的限時免費使用。26

但公告未說明免費方案的截止日期或額度。對打算以此規劃產品或測試排程的開發者而言，最好先確認當前存取條件，而不是把促銷內容當作長期資源。

導入前的實際判斷

Spark X2.5 的差異點，不只是開源或 1.7B、4B 這類相對精簡的模型規模，而是把小型邊緣模型與業者宣稱的原生百萬 Token 上下文結合在一起。若這項能力能在實務部署中成立，對於希望私密地在本地分析完整手冊、技術檔案或程式碼庫的團隊，確實可能很有吸引力。

下一步仍是實測：拿具代表性的長文件任務、實際裝置與既有工作流程來驗證，而非只看上下文長度這一項規格。

重點不只是「小模型」，而是把長上下文留在裝置端

iFLYTEK（科大訊飛）全資子公司詞元星火於 2026 年 9 月 1 日推出並開源兩款面向邊緣端的通用語言模型：Spark（星火）X2.5-4B 與 Spark X2.5-1.7B。兩者最大的賣點，是宣稱可在本地裝置上原生支援最長 100 萬 Token 的上下文視窗。

公司稱這是同類邊緣模型中的首例；這項「首創」定位屬於業者主張，尚不等於經第三方獨立驗證的結論。2

這兩款模型採用混合注意力（hybrid-attention）架構，並針對 AI Agent／工具調用、程式設計、數學推理與指令遵循進行調校。iFLYTEK 也表示，它們對比同等規模的開源模型具競爭力，但公告中未提供完整的獨立對照測試結果。2

為何本地端的 100 萬 Token 值得注意？

處理長文件時，常見做法是把使用手冊、政策文件或大型程式碼庫切成多個片段，再依問題檢索部分內容。這種方式實用，但也可能讓模型漏掉另一段中的例外條款、限制條件或程式相依關係。

iFLYTEK 以售後服務手冊為例：若模型能一次讀入整份手冊，便可在退換貨、故障處理、例外情形、物流、資料清除及費用歸屬等不同章節之間交叉判讀。公司的論點是，這可避免文件切塊後，各章節脈絡彼此割裂。2

不過，上下文視窗夠大，並不自動代表模型推理可靠或答案必然正確。實際導入前，仍應針對自己的文件與設備測試檢索品質、長文回應延遲、記憶體需求，以及模型是否真的能正確套用散落在全文各處的規則。

業者提出哪些本地應用與成績？

Spark X2.5 的目標場景包括智慧硬體、車載系統、機器人與物聯網裝置；這些環境往往對網路連線、延遲或資料處理位置有較高要求。3

iFLYTEK 將其定位為可用於本地生產力工作的智慧助手，但目前釋出資訊未列出完整的辦公自動化功能清單，也沒有專門的辦公任務基準測試。2

公司另提出以下能力與測試主張：

• **程式設計：**Spark X2.5-4B 宣稱在演算法實作、程式碼補全與程式碼生成上，可與參數量為其 2 至 3 倍的雲端模型競爭。2
• **智慧家庭：**Spark X2.5-1.7B 在 Domux 智慧家庭測試集上，據稱達到 90.3% 的端到端指令執行正確率，平均回應時間為 0.85 秒。這是特定命名測試集上的業者報告成績，不能直接視為真實環境的普遍保證。2
• **機器人與邊緣控制：**模型被定位為可在裝置端協助操作／控制、目標追蹤與導航決策，降低對持續雲端連線及固定腳本流程的依賴。2

訓練規模與部署工具鏈

依 iFLYTEK 說法，兩款模型全程使用國產算力平台訓練，使用約 20 兆 Token 的多樣化預訓練資料，後續再經監督式微調與強化學習處理。2

公告列出的相容項目包括：

• **硬體：**NVIDIA、華為、海光（Hygon）與 Hemo
• **推論框架：**vLLM、SGLang、llama.cpp
• **部署途徑：**Ollama、LM Studio
• **增量微調：**LLaMA-Factory

實際速度與記憶體占用仍會受到模型版本、量化設定、使用的上下文長度及目標硬體影響。2

權重在哪裡？API 免費到何時？

iFLYTEK 表示，模型權重、程式碼庫與部署文件均已公開，並可透過 Hugging Face 與 GitHub 取得；同時也在其 Starry MaaS 平台提供相關 API 的限時免費使用。26

但公告未說明免費方案的截止日期或額度。對打算以此規劃產品或測試排程的開發者而言，最好先確認當前存取條件，而不是把促銷內容當作長期資源。

導入前的實際判斷

Spark X2.5 的差異點，不只是開源或 1.7B、4B 這類相對精簡的模型規模，而是把小型邊緣模型與業者宣稱的原生百萬 Token 上下文結合在一起。若這項能力能在實務部署中成立，對於希望私密地在本地分析完整手冊、技術檔案或程式碼庫的團隊，確實可能很有吸引力。

下一步仍是實測：拿具代表性的長文件任務、實際裝置與既有工作流程來驗證，而非只看上下文長度這一項規格。