Spark3 洩漏：科大訊飛的 1.7B 與 4B 小型模型正被接入 vLLM

Spark3 沒有公開權重、沒有模型卡、沒有公告——然而本週卻有一個 pull request 出現在 vLLM 推理引擎中，以極其詳細的方式描述了兩個模型：Spark3-1.7B 和 Spark3-4B。vLLM 儲存庫中的 pull request #53373「[Model] Add Spark3 Model」新增了對 Spark3 架構的原生服務支援：滑動視窗注意力、具有四個等級的可控思考預算、兩種尺寸均原生支援百萬 token 上下文，以及一個指向 iFLYTEK 的模型 ID。這些都沒有得到供應商證實，也沒有任何東西已正式發布。這是一篇「目前已知資訊」的文章：pull request 是真的，而在 iFLYTEK（或任何發布 Spark3 的單位）真正公開權重之前，這些模型據稱能做到的一切都尚未得到驗證。

洩漏：一個讀起來像規格表的 pull request

訊號來源是一個公開的 vLLM PR，由 GitHub 使用者 KnightYao 提交（一位駐於合肥、列屬中國科學技術大學的貢獻者），截至 2026 年 8 月 23 日仍未合併。vLLM 維護者於 8 月 22 日要求修改，並附註「hold for discussions」。這個 PR 尚在早期階段且備受爭議，這對這類整合來說是正常的——而且，以一個實驗室外無人能下載的模型而言，這份框架 PR 也異常地詳盡。

此 diff 涉及八個檔案。它在 vLLM 的模型執行器中新增了 Spark3ForCausalLM 實作，在 vLLM 的設定與模型登錄檔中註冊了原生 Spark3Config，支援滑動視窗注意力與完整注意力，外加逐頭的注意力輸出閘控、tensor 與 pipeline 並行的權重載入，以及一個 Spark3 XML 工具解析器，使模型的工具呼叫能以結構化方式解碼。它也在 vLLM 的支援模型文件中新增了一列，將該檢查點列為 XHToken/Spark3-1.7B。該描述甚至宣稱此整合已通過基準測試：在作者的測試環境中，500 個並發請求、100% 成功率、每秒約 106 個請求，以及每秒 13.5K 個輸出 token。這些數字是撰寫 PR 的人自行回報的，並非獨立基準測試的結果，因此應以此角度來解讀。

為什麼 iFLYTEK 是顯而易見但未經證實的母公司

PR 中沒有任何內容點名供應商。但它註冊的 checkpoint ID「XHToken/Spark3-1.7B」位於 Hugging Face 上的 XHToken 組織底下，而該組織正是 iFLYTEK 的：組織頁面將其列為公司，連結到 opensource.iflytek.com，目前顯示零個公開模型及零個公開資料集。「XH」是 iFLYTEK 模型家族「星火」(Xinghuo, "Spark") 的自然縮寫。再加上作者的合肥地點——iFLYTEK 總部位於合肥——這個推論在供應商證實之前，已經幾乎是最強而有力的推論了。

這符合科大訊飛（iFLYTEK）近期的模式。該公司於2026年2月發布的Spark X2，明確瞄準教育、醫療、汽車及智能體（Agent）應用場景，其端側模型產品線SparkAuto-EMM提供從0.5B到7B的小型尺寸。在此新聞稿出現的兩天前，即8月21日的中期業績發布會上，科大訊飛表示，一款完全基於國產算力打造的全新旗艦通用模型即將推出，分階段版本預計「8月底」上線，並將在10月的1024開發者日上全面發布。Spark3-1.7B和Spark3-4B究竟屬於該分階段發布的一部分，抑或是獨立的邊緣計算產品線，這份新聞稿並未給出答案，仍是懸而未決的問題。

這些模型據說是什麼

PR 的主張，全部未經證實：

• 兩種尺寸。 Spark3-1.7B 和 Spark3-4B。兩者都被描述為效率優先的設計，採用滑動視窗注意力機制，而非密集的全注意力佈局。

• 兩者皆原生支援 1M token 的上下文。這不是擴展模式的承諾——PR 表示該上下文是架構原生的，這代表一個小到可在單一 GPU 上合理運行的模型，將能承載一百萬 token。

• 四級思考預算。推理可設定為無、低、中或高，這是一種可切換思考的設計，讓應用程式能在推理深度與每次呼叫的延遲和成本之間進行取捨。

• 支援200多種語言，並具備中文考試實力。該新聞稿宣稱具備強大的K-12與高考問答表現——這是iFLYTEK的標誌性特色，鑑於該公司的教育業務——並涵蓋200多種語言。

• 編寫程式與代理導向。宣稱具備與其規模相符的強大程式碼生成、工具使用、多步驟執行及長上下文推理能力，並由同一 PR 中所包含的 XML 工具解析器提供支援。

1.7B模型上的原生1M上下文，才是值得注意的部分

上下文長度一直是小型模型的瓶頸所在。在當前的開源權重（open-weight）格局中，1.7B–4B 模型通常配備 32K–256K 的原生視窗：Qwen3 的小型 checkpoint 原生為 32K，可透過 RoPE 縮放達到 131K；即便是 Qwen3.5 在小尺寸版本上改進至原生 256K，也是近期才有的進展。百萬 token 的上下文迄今仍是大型模型的專利——GLM 的 1M 上下文 checkpoint 參數量高達數千億。如果 Spark3 真的能在 4B 模型上實現原生 1M 視窗，那將是非常罕見的規格；而滑動視窗注意力（sliding-window attention）架構正是讓它在記憶體上變得廉價的關鍵。但必須同時提出的警語是：原生 1M 這種宣傳數字在 PR 稿上很容易寫，要在實務上做出價值卻很難。長上下文品質——模型是否真的能找出並運用 700K token 之前的事實——與視窗能容納多少 token 是兩個不同的問題，而目前尚無獨立的評測存在。

可控的思考預算之所以重要，也是基於同樣的理由。四個推理等級（無／低／中／高）是一種可切換思考的設計，呼應 Qwen3 的開啟／關閉思考模式，但更豐富：與其做二元選擇，應用程式可以針對每次請求挑選一個等級——翻譯時不需思考，多步驟的代理回合則用高等級——只為自己需要的推理付費。對代理型或批次型工作負載而言，這正是把「能力強但昂貴」的小型模型變成成本受控模型的旋鈕。

訓練後的配方符合2026年的模式

該新聞稿稱，Spark3 在後訓練階段使用了「擴展式強化學習與 MOPD」。MOPD——多教師同策略蒸餾（Multi-Teacher On-Policy Distillation）——是一項真實且當前正在使用的技術，於 arXiv 論文（2606.30406）中有詳細描述：先訓練並行的領域專精 RL 教師模型，然後在學生模型自身的軌跡（rollouts）上將它們蒸餾回單一學生模型，針對每個提示（prompt）最小化與正確教師模型之間的逐 token 反向 KL 散度。這是 2026 年的方法，讓單一模型能同時繼承數學、程式編寫與代理（agent）技能，而不會讓不同的 RL 訓練互相衝突；MiMo Flash V2、DeepSeek V4 和 Nemotron 3 Ultra 等模型的後訓練也曾公開歸功於此技術。Spark3 引用相同方法，使其歸屬於那一世代——小型模型、前沿的後訓練技術。這也表示「強大的程式編寫與代理能力」宣稱背後有合理的機制支撐。不過，合理並不等於已證實：在權重釋出且獨立評測運行之前，這些宣稱仍僅是廠商單方面的說法。

真正未知的是什麼

幾乎所有帶有日曆的東西：

• 發布日期。 在 Hugging Face 上沒有權重，沒有公告，沒有時間表。XHToken 組織今天空空如也。

• 廠商確認。 iFLYTEK 對 Spark3 未發表任何言論。XHToken 組織連結是強而有力的證據，而非官方聲明。

• 這是否為階段性旗艦。 iFLYTEK 新旗艦的「8月底」階段性版本可能就是這款——或者無關。新聞稿完全沒有提供任何日期。

• 定價與授權。未揭露任何資訊。iFLYTEK 的 Spark 系列歷來大多透過 API 提供服務，而非開放權重，因此 Spark3-1.7B 與 Spark3-4B 究竟是開放檢查點，還是內部服務目標，仍是個待解的問題。

• 每一項基準測試。PR 中的吞吐量數據是作者自己的服務測試，並非獨立評估，而且沒有任何排行榜為該模型評分，因為目前並無公開的模型存在。

看什麼

XHToken 的 Hugging Face 組織是值得關注的發布管道。如果這個模型是真的，它的權重——或至少一張模型卡——應該會出現在那裡，而該組織從零個公開儲存庫變成一個，這是最重要的訊號。一旦出現，有幾件事需要檢查：

• 上下文數字。是原生 1M，還是透過 RoPE 擴展並在品質上有所取捨？PR 說的是原生；模型卡才是最終定案之處。

• 思考預算 API。四個推理層級以何種方式公開——作為取樣參數、聊天模板欄位，或獨立模型變體——決定了其實際使用的難易度。

• 授權條款。開放權重將使 Spark3 成為首個低於 5B 參數、原生支援 1M 上下文且可自行託管的模型；僅限 API 的發布則會使其成為不同類型的產品。

• iFLYTEK 的發布時間表。 階段性旗艦產品承諾於八月底前推出，全面發布則在 10 月的 1024 開發者日。如果 Spark3 屬於其中任何一個，官方描述將說明新聞稿未提及的部分。

• 此 PR 是否合併。vLLM 支援作為品質訊號和基礎設施都很重要：作為首個原生支援 Spark3 的執行環境，它讓模型在權重發布當天即可於生產環境中運行。

開發者現在應該做什麼

什麼都沒有。沒有模型可以呼叫，沒有權重可以下載，沒有 API 金鑰需要配置——任何聲稱今天就能提供 Spark3 的工具，所提供的其實是別的東西。你現在能做的，是決定當它出現的那一天你要如何評估它，因為這個模型的承諾非常容易檢驗：一個能讀取一百萬個 token、並以四種深度進行推理的 1.7B 或 4B 模型，要嘛是真正全新的小型模型類別，要嘛只是規格表上的故事，而兩者的差異，花一個下午在你自己的工作負載上就能測量出來。

那也是路由層真正體現價值的地方。在 OrcaRouter 上，模型不是你要承諾綁定的契約，而是目錄中的一個條目，你透過同一個 API 呼叫它，而供應商的標價以零加成方式直通——因此，當新模型出現在供應商目錄中時，它的真實價格當天就會在我們這端上線，想試用它不需要第二次整合，也不需要重新議價。對像 Spark3 這樣未經證實的模型，明智的做法與你對任何有潛力、剛冒出頭的新模型會採用的做法如出一轍：{{1}}在路由 DSL 中把它放在自動故障轉移之後，讓一部分流量打到它，並在規則的另一側保留一個經證實的模型，如此一來，糟糕的評測結果、授權上的意外，或令人失望的長上下文結果，都只是路由變更，而不是一場事故。{{/1}}一個金鑰、一個端點、200 多個模型——而當 Spark3-1.7B 或 Spark3-4B 真正可執行時，直通與故障轉移機制也會像對待任何其他模型一樣，同樣適用於它。

老實說，這段總結只是一句話，而非定論：本週一份框架 PR 宣稱 iFLYTEK 有兩款原生百萬級 token 上下文的小模型，以及四級思考預算，但至今沒有任何權重證據發表來支撐這些說法。盯緊 XHToken org，盯緊 iFLYTEK 八月底的承諾，等到權重真的釋出時，先用帶故障轉移的路由規則跑一遍，再決定是否讓生產路徑押注在它們上面。這就是面對「洩漏」的完整打法——相信基礎設施，驗證模型，並且讓退出成本保持在最低。