Fireworks Ultrafast 跑 DeepSeek 每秒逾1500 Token：11秒寫遊戲，速度該怎麼看？
Fireworks Ultrafast 官方示範 DeepSeek V4.1 Flash 1017 每秒逾1521 Token、11秒生成俄羅斯方塊。本文拆解輸出速度、首字延遲與完整任務時間的差異，說明等候名單狀態、比較條件及開發者的測試方法。
Fireworks Ultrafast 想縮短模型把程式碼一行一行送出來的時間。輸出加快後，開發者可以更頻繁地修改原型，但整個專案還有執行、檢查與修正，時間不會全部依同一倍數縮短。
Fireworks 在 10 月 21 日的官方 X 示範中表示，DeepSeek V4.1 Flash 1017 在這套服務上可達每秒超過 1,521 個 Token，並用十一秒生成俄羅斯方塊。
Token 是模型計算文字輸出的單位，一段中文、英文單字或程式符號可能被拆成不同數量。每秒多少 Token，首先描述的是文字產生的一段速度，不是所有工作的總完成時間。
官方原貼也稱這次示範比 Claude Opus 5.5 快七倍，但未列出完整比較設定。服務連到等候名單，截至 10 月 22 日，還不能由這則公告認定所有帳號都能直接使用。
對需要快速產生長輸出的開發者，我認為它值得申請測試。若要據此規劃正式服務，則需要把首字延遲、可用性、費用與結果品質放回同一份測試，才能知道工作究竟改善多少。
這幾種速度要分開，才能理解示範中的十一秒能替流程省掉哪一段。
Fireworks Ultrafast 示範了什麼？先分清模型與服務
這次新消息是 Fireworks 的推論服務示範，而非 DeepSeek 又發布一個同名模型。模型決定如何產生內容，推論服務則負責把模型放到設備上執行，接收請求並把結果送回來。
原貼指定的是 DeepSeek V4.1 Flash 1017，其中日期型號用來區分模型版本。即使使用同一家公司的模型，不同檢查點也可能有不同能力，所以效能紀錄應保留完整名稱，不能只寫「DeepSeek 很快」。
Fireworks 這次附上一段遊戲生成影片，並把每秒超過 1,521 Token、十一秒和七倍列為示範重點。這些是服務商對案例的說明，本文沒有把它改寫成自己測出的結果。
同一個模型可能由不同服務商提供，也可能由使用者自行架設。硬體、運算精度、排程、快取與服務負載都可能影響表現，因此模型名稱相同，是比較的起點，還不是條件已完全相同的證明。
這與模型開源、推論引擎開源有何不同
模型開放權重，表示可以依授權取得訓練後的核心參數。推論引擎公開，則讓開發者取得部分執行工具，但仍要自己準備硬體和服務。這次公告談的是 Fireworks 提供的快速推論入口。
所以，看到這段影片的人不需要先自行重建同一套硬體，才能理解 Ultrafast 的用途。但若想知道加速方法或重現相同結果，就需要更多公開條件，不能從畫面自行推測用了哪種壓縮技術。
延伸閱讀：DeepInfer 開源：DeepSeek 把推論引擎公開，離自己架設 AI 服務還差什麼？
同一模型放到不同服務可以有不同速度，因此比較時必須先問量的是哪個指標。
每秒1521 Token、首字時間與整體等待有何差別
輸出速度只覆蓋文字產生的一段，使用者的完整等待還包含其他步驟。即使文字一旦開始就送得很快，請求也可能先經過排隊、讀取輸入和準備運算，這些時間不一定反映在輸出速率裡。
Fireworks 的效能量測文件明確把首 Token 時間、端到端回應時間、生成速率與吞吐量分開。這些指標都與速度有關，但回答的是不同問題。
首 Token 時間通常簡稱 TTFT，意思是送出請求後，多久收到第一個輸出單位。對即時對話介面，這段空白容易被使用者察覺，因此不能只用後續輸出很快來替代。
端到端時間則看到整份回應結束為止。若一份回答很長，Ultrafast 的生成加速可能較明顯，但若回答很短，前面的排隊與讀取時間可能占較大比例，兩種工作需要不同觀察方式。
以下整理幾種容易混淆的數字，方便對照產品需求。
| 指標 | 回答的問題 | 比較時需要保留的條件 |
|---|---|---|
| 首 Token 時間 | 多久開始有回應 | 輸入長度、排隊與服務負載 |
| 生成 Token／秒 | 開始輸出後送得多快 | 輸出長度、計算方式 |
| 端到端時間 | 整份回應多久結束 | 請求起訖、是否串流 |
| 每秒請求數 | 同時能服務多少工作 | 併發量與錯誤率 |
表格最後一列關心的是多人使用時的容量。單一請求很快，與同時服務很多請求仍能維持速度，是兩種不同的服務表現，因此商用測試不能只做一次單人展示。
串流也會改變感受。串流是讓結果逐步送出，使用者不用等整篇完成才看到文字，但它不會自動減少模型需要產生的內容，也不代表後續工具已經完成工作。
指標分清楚後，才能回頭判讀十一秒遊戲與七倍比較。
11秒遊戲與7倍比較：哪些條件仍未公開
官方示範支持特定案例的快速輸出，尚不足以建立通用的模型或服務排名。要把「七倍」帶到自己的工作，至少要知道比較的兩端實際做了多少內容，以及計時從哪裡開始。
原貼沒有列出完整提示、輸入與輸出長度，也沒有交代每秒數字是平均值、峰值，或排除了哪些前置時間。這些差異都會影響倍數，因此不能只靠一個輸出速率反推整體等待。
官方影片的起始畫面有揭露一項差異：Opus 標示使用 Anthropic API，也就是供程式呼叫的介面，並採預設思考。DeepSeek 則標示關閉思考。因此這段 Ultrafast 示範並非相同思考設定的比較，七倍不能單獨歸因於服務端加速。
其他完整設定仍需要更多紀錄。即使已知道模型與思考模式，也還有輸入長度、服務負載和計時方式等因素，所以這段畫面尚不足以讓外部使用者重做同條件比較。
生成遊戲程式，還有後面的驗收
俄羅斯方塊是一個容易看出用途的示範，因為程式輸出後能直接呈現互動結果。但若要把它當作可交付作品，仍要確認旋轉、碰撞、計分、重新開始等行為，以及在目標環境中能否正確執行。
這些檢查與生成文字是不同步驟。如果模型只花十一秒把程式送完，不能因此把檢查和修正的時間也算成零。不過，若快速輸出讓人更快開始測試，它仍可能縮短整個修改循環。
對開發者來說，比較有用的問題是多久拿到一份「符合需求、可以繼續使用」的結果。若某端很快卻需要多次補救，另一端慢一點但一次符合要求，最後的時間排序就可能改變。
因此這段 Ultrafast 示範最適合拿來提出測試假設：對長程式輸出，它可能減少等待。至於自己的程式任務能縮短多少，還需要相同規格和驗收條件，才能得到可用答案。
這些條件決定了示範結果可以帶進哪一種工作。
哪些應用較可能受益？長輸出與多輪修正
需要產生大量文字、且有人檢查結果的工作，最可能直接感受到解碼加速。例如程式原型、文件初稿或多個版本的內容草案，都有一段明顯的文字輸出等待，縮短它能讓後續檢查提早開始。
但改善比例取決於這一段原本占多少。下面用一個純粹的假設算例說明，它不是 Fireworks 或任何模型的實測，也不拿來推估這次服務的實際速度。
假設某個工作要輸出三千個 Token，兩個服務分別以每秒三百與一千五百個 Token 產生內容，只算這段生成時間，就是十秒與兩秒，後者在這個環節快五倍。
若其他工具與檢查固定需要三十秒，整個工作則從四十秒降到三十二秒，少了八秒，約縮短兩成。因為剩下三十秒沒有改變，整體改善不會跟輸出速率一樣成為五倍。
這個算例的意義，是幫開發者找出值得加速的環節。如果原本多數時間在等長輸出，換更快服務可能有感；如果時間主要花在搜尋、資料庫或外部工具，解碼就不是最大的等待來源。
多輪修正則可能放大短等待的累積。每次改提示、產生程式、執行測試都要等一段時間，若同一天反覆很多次，即使每輪只省幾秒，也可能改善操作節奏，但仍要用真實使用紀錄估計。
這也適合與模型能力分開看。加速讓人更快取得結果，能力決定結果是否符合要求，兩者可以一起改善，卻不能只量前者就替後者下結論。
延伸閱讀：Mercury 3 擴散語言模型發布：每秒逾千 Token，速度、價格與百萬上下文怎麼看？
若要判斷自己的任務能不能得到這些改善，就要把它做成可重複的測試。
開發者如何設計自己的速度對照
有效的 Ultrafast 比較要固定輸入、輸出要求和測試端點，並把時間與品質一起記錄。Fireworks 官方效能文件也建議使用接近正式工作的請求，在不同併發量下測試，避免只選最短提示做單次展示。
可以先挑幾種真實工作，保留完整提示、輸入長度、期望輸出和驗收標準。程式任務就用相同測試，文件任務則確認必要資訊是否完整，避免較短但漏答的結果因耗時少而看似勝出。
量測時分別記第一個輸出到達時間、最後一個輸出結束時間和產生量。這樣才看得出改善是在開始回應之前，還是後面的生成階段，也能發現長輸入是否讓首字等待明顯增加。
同時看中位數與較慢的請求
只報平均值容易忽略少數長等待。中位數代表一半請求比它快、一半比它慢；較高百分位則幫助團隊看見慢請求的尾端，對需要穩定互動的產品尤其有用。
官方工具範例也會記錄錯誤率。若為了提高總請求數而增加併發，卻出現大量失敗或需要重試，使用者感受到的服務並沒有因此變好，所以吞吐量必須和錯誤情況一起看。
部署暖機也要一致。官方建議正式量測前先送出幾個請求，確認模型已載入。如果產品本來就會頻繁冷啟動，也應另做冷啟動測試，而不是把兩種情況混成一個漂亮平均值。
Fireworks 另外公開一般模型品質驗證流程，包括格式、工具呼叫、數值比較與多輪任務。這能說明公司如何看待服務正確性，但不應直接當成這次候補功能已公布的完整驗證報告。
網路與用戶端也可能成為瓶頸。官方用戶端優化文件建議在專用部署重用連線，並觀察高併發下的錯誤。這屬一般部署建議，尚不能替代 Ultrafast 自己的服務限制與測試。
若自己的程式每次重新建立連線，或因限流反覆重試，量到的結果會包含這些額外等待。記錄請求開始、第一段輸出和結束時間，能幫團隊分辨應該改善用戶端，還是需要服務商處理。
同樣重要的是不要強迫每個模型產生相同字數卻忽略內容。可以先固定需求與檢查標準，再同時記實際輸出量，因為較冗長的答案可能拉長時間，而被截斷的答案也可能因提早停止看似更快。
測出速度之後，還要確認服務能否在需要的時候取得。
候補名單階段，適合怎麼規劃導入
目前適合把 Ultrafast 當測試候選，正式排程仍須以實際開通與價格條件為準。公告連到候補表單，表示有興趣的人可以登記，但表單本身沒有承諾供應量、開通時間或商用條件。
截至 10 月 22 日，原貼沒有列出這項入口的專屬費率與完整服務限制，所以不應拿一般平台價目表替它填上一個價格。實際取得權限後，還需要核對計費方式與可用的模型版本。
對正在做原型的團隊，可以先把測試資料和計時方式準備好。等服務開通，就能直接比較相同任務，不必到時才決定要測什麼，也比較不容易只留下對宣傳案例有利的結果。
如果正式產品已經有使用者，則先保留現有可用入口，再用小量代表性工作評估新服務。這個安排的目的，是讓速度改善有完整對照，而不是在尚未掌握供應條件時改寫整個交付計畫。
我的判斷是，長輸出和反覆原型值得優先測，短回答、重工具或高併發工作則要各自量測。只有當較快的結果也能通過同樣檢查，服務加速才會轉成工作上的改善。
Fireworks Ultrafast 常見問題
Fireworks Ultrafast 已經全面開放嗎？
公告目前連到等候名單，不能據此認定所有帳號都已能使用。
每秒1521 Token 等於整個專案快七倍嗎？
不等於。輸出生成、工具執行和檢查修正是不同環節，整體改善取決於各環節原本占多少時間。
這是新的 DeepSeek 模型嗎？
原貼指定 V4.1 Flash 1017，這次討論的是服務端的推論示範，而不是另一個新模型發布。
先測可用結果的時間，再看速度倍數
Fireworks Ultrafast 的示範讓快速長輸出成為值得測試的選項，但每秒數字和完成工作仍有距離。適合的下一步，是固定自己的任務和檢查條件，把首字、生成、錯誤與總時間一起比較。
當結果品質和服務條件都符合需求，再決定導入，會比直接套用七倍更有依據。想追蹤推論服務、模型價格與開發工具更新，可以免費訂閱 AI 郵報。
