QEngine RTX 5090 基準測試報告達 504 Tok/s，優勢受快取形態影響

QEngine RTX 5090 基準測試顯示，Qwen3.8-Flash-Next 每秒可達 504 個 token，但這項峰值附帶會改變競爭格局的條件。一名 LocalLLaMA 用戶在兩張 RTX 5090 顯示卡上測試 QEngine 1.3.1，並報告其單串流解碼表現大幅領先，亦即單一對話的生成速度。同一項比較顯示，QEngine 在代理提示延遲測試中與 Strata 大致持平，但 Strata 處理較長的基準提示速度更快。

測試者以 Relative-Ant-9249 的帳號發文，將功勞歸於開發者 bpx03，並明確指出 QEngine 是他人的項目。他們的本地推論基準測試在同一部工作站上比較多個引擎。這使報告具參考價值，但它仍是由用戶自行進行、未經獨立重現的比較。

核心取捨已相當明顯：最快的輸出串流，並不必然代表整段對話的等待時間最短。重複提示有利於 QEngine 的自適應快取；在報告中的測試裡，長輸入則有利於 Strata；而保留閒置對話又會以另一種方式改變延遲。要在這些引擎之間作選擇的開發者，需先找出真正中斷其工作流程的是哪一種延遲。

QEngine RTX 5090 基準測試實際量度了甚麼

504 tok/s 的結果屬於特定工作負載、記憶體配置及軟件版本。 它既不是整項比較的平均值，也不保證每個回應都能達到這個速度。

這部工作站配備兩張 RTX 5090 顯示卡，每張擁有 32 GB 視像記憶體，另配 Threadripper PRO 3975WX 處理器。測試者報告系統配有 251 GB RAM，設定的上下文長度約為 262,000 個 token。Token 是模型處理及生成的文字單位，並非字詞數量的直接計算。

QEngine 使用 Flash-Next 的 INT4 AutoRound 建構版本，這是一種以四位元整數權重表示的壓縮模型。測試者表示，他們將 CUDA 編譯目標由架構 86 改為 120，並使用 nvcc 13.3 及 g++-13。他們稱沒有作出其他原始碼改動，而從啟動到開始提供請求服務的間隔為 53 秒。

這是一份令人鼓舞的可移植性報告，但成功編譯並不代表已確立一般硬件支援。它只證明該用戶成功讓這個建構版本在這部機器上運行，並不表示在不同主機板、驅動程式、記憶體配置或作業環境中，均有相同表現。

測試將敘述文字輸出與程式碼輸出分開，而這個分別在整體結果中相當重要。使用預設配置時，QEngine 據報以 370 tok/s 生成敘述文字，生成程式碼則為 439 tok/s。將其對話快取移至系統 RAM 後，這兩項數據分別升至 406 和 504 tok/s。

Strata 的 ISTA IQ3_S 配置據報在敘述文字輸出達 214 tok/s，程式碼輸出達 293 tok/s。其 UD-IQ4_XS 配置則分別為 180 和 239 tok/s。這些是不同的壓縮模型建構版本，因此不能把比較視為純粹量度引擎實作方式。

經調校的 bucko vLLM 配置在敘述文字輸出達 135 tok/s，程式碼輸出為 141 tok/s；其隨附配置則量得 120 和 118 tok/s。測試者亦列出一個 Infernix 配置，其速度為 14–18 tok/s，但未提供對應的提示處理量度。

這些數字顯示在該工作站上的報告差距相當顯著，同時亦說明標題數字的限制：504 tok/s 是列出的最高程式碼生成結果。同一引擎的敘述文字結果較低，而其預設記憶體配置亦比 RAM 配置慢。

報告表示，所有引擎均使用相同的基準測試腳本及提示。連結的社群服務配置指南為測試生態提供背景，但連結至基準測試項目並不能獨立驗證已提交的結果。

因此，最可辯護的描述應該具體而明確：QEngine 1.3.1 在該用戶測試的配置中，於單串流生成表現領先，而其最高報告速度出現在程式碼生成。若要作出關於最快可用引擎的更廣泛主張，則需要更完整的比較範圍及可重複的獨立測試。

重複提示令生成速度優勢更難概括

QEngine 報告中的優勢具有意義，但該基準測試同時獎勵一般流量未必能重現的行為。 測試者直接指出這個限制，因此它是解讀結果的關鍵。

根據帖子內容，QEngine 的專家快取會因應近期使用情況調整。專家快取會保留模型中經常需要的部分，讓引擎毋須反覆從其他位置擷取。重複相同提示會為這個機制提供有利的工作負載。

這一點之所以重要，是因為基準測試會在不同運行中重複提示。近期使用因而成為預測未來使用的有效指標，可減少模型資料的搬移。所得的生成速度描述的是有利的運行條件，而不是每一種可能對話的表現。

測試者將此與 Strata 的快取作比較，並稱後者已保存約 99.5% 的路由專家權重。在其說法中，重複提示因此為 Strata 帶來較少額外好處。這個解釋來自測試者，本文未有獨立證實。

帖子亦提供一項較早、來自多樣化流量的觀察：單串流速度約為 300–400 tok/s。經測試者代理工作負載處理的請求，據報介乎 330–470 tok/s。這些數字仍然很快，但令 504 tok/s 的標題數字看來更像有利情況，而非典型預期。

標題形容其相對下一個最佳受測引擎的優勢約為 1.5–1.9 倍。正文則在考慮工作負載差異後，採用約為 Strata 1.4–1.9 倍這個較寬的估計。兩個範圍都不應被視為可套用至無關硬件或提示的通用倍數。

這正是 QEngine 與 Strata 變成工作負載問題之處。反覆生成相近程式碼的開發者，可能受惠於與在無關文件之間切換的人不同的快取模式。來源未有說明任一模式需持續多久，量得的優勢才會改變。

有用的獨立比較應同時保留兩種條件。重複提示可揭示近期活動能預測未來需求時，引擎可達到的表現；多樣化提示則可揭示它如何處理較不配合的一連串請求。

兩種條件都不應在每次評估中自動獲得優先。重複情況可以代表具共享指令及重複工作的真實應用；多樣性則可代表在程式開發、研究、文件審閱及陌生項目之間切換的個人助理。

實際問題在於，有利條件一旦從標題中消失。只看到 504 tok/s 的讀者，可能預期剛切換工作後便能立即得到這個速度。現有證據並不支持這種預期。

因此，QEngine RTX 5090 基準測試要求競爭引擎說明其在可比較快取條件下的行為，亦要求基準測試作者清楚揭示這些條件。缺乏這類披露，效能排名可能掩蓋排名存在的原因。

對買家及開發者而言，相關問題是他們的實際工作有多常近似重複基準測試。答案決定峰值應佔多少比重。對部分工作流程而言，速度稍低但表現一致，可能比速度較高但波動更大的方案更合適。

在答案開始前，Strata 仍具競爭力

QEngine 的生成速度領先，並未轉化為整個請求流程的明確領先。 報告中的提示處理結果，令 Strata 在輸入變長時處於較強位置。

Prefill 是指模型開始生成回應前處理輸入的階段。在約 10,000 個輸入 token 時，QEngine 的預設配置據報處理速度約為 5,700 tok/s。其 RAM 快取配置在該輸入長度達約 6,200 tok/s。

Strata 的 ISTA IQ3_S 配置據報在較短輸入長度處理速度約為 5,100 tok/s。然而，在約 90,000 個 token 時，它達到約 10,000 tok/s。QEngine 的預設配置在該較長輸入長度量得約 7,300 tok/s。

帖子未有提供 QEngine RAM 配置在 90,000 token 時相對應的 prefill 數字。這個缺漏應維持為缺漏，而不應從其較短輸入表現推斷。現有量度支持一個分歧結果：QEngine 在較短提示領先，Strata 則在較長提示領先。

這個分別對編程助理有直接應用意義。處理小量近期對話的助理，與審閱大型程式庫上下文的助理，在閱讀階段所佔時間比例不同。更快的生成對兩者都有幫助，但無法消除處理輸入所需的時間。

代理測試再加入一個重要界線。它涵蓋一個 12 回合的工具使用序列，上下文增加至約 35,000 個 token。在 prefix caching 運作時，QEngine 1.3.1 據報以 1.75 秒讀取最後一回合的提示。

Prefix caching 指重用提示中未有改變的開頭部分的運算結果。Strata 的相應結果為 1.7–1.9 秒，因此 QEngine 位於該報告範圍之內。測試者恰當地將兩個引擎形容為在這項量度中持平。

經調校的 bucko 配置在同一項報告比較中需時 4.36 秒。這顯示受測配置之間存在差異，但並不能為每個 vLLM 部署確立結果。配置、模型表示方式及工作負載仍是比較的一部分。

同樣重要的是，報告數字量度的是提示閱讀階段，而非執行工具、檢查結果、生成後續指令及完成任務所需的完整時間。一個快速階段可以改善代理表現，卻未必決定代理的整體完成時間。

因此，QEngine 與 Strata 在已披露的量度中沒有單一贏家。QEngine 在生成方面領先，而 Strata 在快取代理提示方面保持競爭力，並在報告中的長輸入 prefill 測試較強。這比把一切簡化為每秒輸出 token 數量更有用。

對維護本地助理的團隊而言，壓力在於營運層面。他們需要確定用戶主要是在等待輸入處理、答案生成還是外部工具。引擎變更只能處理引擎實際可控制的等待時間部分。

這個結果亦挑戰本地推論示範的展示方式。快速湧現的程式碼串流容易展示，也容易理解；但在串流開始前較不顯眼的延遲，在反覆工具互動期間可能同樣重要。

將閒置對話保留在 RAM 會改變另一種等待

最實際的結果，可能是恢復較舊對話的能力，而非最高生成速度。 QEngine 的 RAM 配置據報能在中間流量出現後，保留有用狀態。

KV 快取會儲存與注意力機制相關的鍵和值，讓模型可重用較早前 token 的運算結果。在這項測試中，QEngine 可將該快取保存在已釘選的系統 RAM 中，即為可預留作穩定傳輸的主機記憶體。測試者表示，一個 13.5 GB 的資源池可提供約一百萬個 token 的累計快取容量。

這個資源池大小不同於個別對話所設定的內容長度上限。累計容量是指資源池可在不同工作階段保留多少對話狀態，並不代表此基準測試曾測試一段包含一百萬個 token 的單一對話。

閒置工作階段實驗以八段各約 58,000 個 token 的對話開始。測試者其後傳送約 400,000 個 token 的其他流量，再回到原先的對話。此流程用以檢驗機器處理其他內容後，先前工作是否仍可隨時恢復。

據報，在 RAM 中保留快取後，全部八段對話均維持暖啟動狀態，亦即其保留狀態仍可重用。首次回覆時間介乎 1.56 至 2.01 秒。這衡量的是使用者重新開啟工作時遇到的延遲，而非輸出串流最終的速度。

據報，在視像記憶體中保留快取時，僅兩段對話維持暖啟動。其餘六段需要再次處理輸入，耗時 8.7 至 9.4 秒。測試者報告的冷啟動參考值為 8.85 秒，令實際影響一目了然。

在持續進行的專案之間切換的開發者，會認得這種模式。一段對話保留除錯調查，另一段包含實作檢視，還有一段追蹤另一項功能。關鍵好處在於，即使注意力轉移到其他地方，已處理的工作仍得以保留。

同樣的區分亦適用於可搜尋知識庫。尋找合適資料與恢復模型先前的運算，是兩個不同問題，儘管兩者都會影響人們多快能重返有用的工作。

來源指出，當視像記憶體配置必須再次處理舊輸入時，答案仍然正確。觀察到的代價是延遲，而非有文件記錄的答案正確性下降。這個區分可避免將每次快取未命中都視為推理失敗。

同時亦存在併發取捨，這裏的併發是指同時服務多個串流。在八個併發串流、每段內容長度為 64,000 個 token 的情況下，據報 RAM 配置每個串流產生 124 tok/s。視像記憶體配置則達到每個串流 139 tok/s。

測試者將此概括為：儘管單串流提升約 10%，在此併發工作負載下卻慢約 10%。他們亦披露每種模式只啟動一次並只執行一輪。這足以識別出值得研究的取捨，但不足以確立其完整分布情況。

更廣泛的技術議題不止於此引擎。混合快取文件描述針對 Flash-Next 的處理方式，並將其聲稱的驗證範圍限於文字生成。模型支援、狀態保留及工作負載覆蓋範圍，都需要明確檢視，而非根據產品名稱作假設。

對個人助理而言，保留閒置工作的重要性可能超過較低的併發輸出速度。對共享服務而言，平衡或會剛好相反。報告結果令兩種可能性都值得評估，但未將任何一種確立為預設選擇。

品質檢查及競爭引擎限制了勝出說法

報告支持進一步測試 QEngine，而非宣稱它能產生更佳答案或擊敗所有替代方案。其自身的品質檢查及討論串已確立這些限制。

據報，助理測試在 QEngine 1.3.1 上完成了 44 項任務中的 44 項。較早的 1.3 測試在低投入設定下完成 44 項中的 42 項。測試者謹慎看待這個小差異，沒有將其描述為已確立的品質改善。

編碼比較更需要謹慎地歸屬版本。一個候選發行版本在測試者的編碼測試集上完成了 30 項任務中的 26 項。Strata 配置分別完成 24 項及 25 項，而其中一個配置的重複結果介乎 24 至 26 項。

測試者明確表示，編碼檢查尚未在 1.3.1 上重新執行。因此，它不能作為支撐標題所指確切版本的直接品質認證。它只提供較早版本的背景，以及比較中觀察到的變異程度。

合理的結論是，這些有限檢查未有顯示 QEngine 壓縮模型在編碼方面存在明顯劣勢。它們並不能確立所有任務上的品質相等，也未顯示生成速度的改善能保留生產應用程式所需的每一種行為。

量化，即壓縮模型數值權重，令引擎比較更加複雜。不同的壓縮版本可同時改變效能及輸出。比較完整部署配置的基準測試回答了一個實務問題，但不能孤立所有成因。

競爭範圍同樣並不完整。在討論中，Basalt 的開發者建議測試一個專為 NVIDIA Blackwell 硬件設計的引擎。該開發者報告的是另一部機器及另一項基準測試的效能，因此那些數字不能納入原始排名。

不過，Blackwell 推理支援的存在，對解讀「最快引擎」這個說法仍然重要。QEngine 在發帖者測量的配置中領先。未受測試的替代方案仍是未受測試，無論其開發者是否在其他地方報告了有前景的數字。

來源討論串亦包含熱烈的用戶反應及設定協助請求。這些回應反映出興趣，但熱情和個人經驗都不能獨立重現該基準測試。第二部工作站需要有文件記錄的測試，其擁有者的經驗才可支持同一效能說法。

版本漂移帶來另一個驗證問題。於查核時，QEngine 原始碼儲存庫描述版本 1.3.2 及額外的 Flash-Next 功能。這些目前的描述不應追溯套用到受測的 1.3.1 版本。

該儲存庫稱此專案為 source-available，並記錄其重點針對 RTX 3090 硬件。其建置說明仍標示架構 86，並將其他 GPU 型號列為未經測試。這令發帖者在 5090 上的編譯成為個別結果的有用證據，而非一般相容性承諾。

因此，獨立重現應保留實際的軟件修訂版本、模型檔案、編譯器選項及啟動配置。將所有項目更新至最新版本或可產生有趣結果，但回答的是另一個問題。可重現性有賴保留已測量的內容。

QEngine 現時面對的壓力，是將一份有前景的用戶報告轉化為可靠的運作模式。競爭者面對的壓力，則是以可比較的工作負載及透明配置作回應。兩項工作都不能僅靠貼出無關硬件上的較大數字完成。

三項結果可令下一次比較更有用

下一項有用證據，是跨工作負載、更可重現的比較，而不是另一個孤立的峰值。三個具體訊號可加強或削弱對這份報告的解讀。

第一，應留意另一部雙卡 RTX 5090 工作站上的獨立重現。有用的結果會列明確切的 QEngine 修訂版本及模型建置，然後報告重複提示與不同提示的結果。若在兩種條件下均重現實質的生成優勢，便可加強該優勢能超越原始機器的論據。

若在不同提示下優勢較小，會收窄該論據，但不會令原始測量失去意義。這將顯示近期工作負載歷史解釋了較多觀察到的結果。此資訊有助使用者根據自身流量選擇引擎。

獨立測試亦應保留敘事輸出與程式碼輸出的區別。將兩者合併為一個平均值，會掩蓋原始報告已揭示的差異。分開報告結果，讓讀者有更大機會將基準測試配對至其應用程式。

第二，應留意同一部機器上的比較，當中包括如 Basalt 般專注於 Blackwell 的替代方案。原發帖者的結果並未確立該引擎在排名中的位置。在相同條件下測試它，可填補討論中提出的具體缺口。

可信的比較應披露壓縮模型建置及品質設定的差異。除生成速度外，亦應包括提示處理延遲及恢復工作階段行為。否則，新勝者會承襲舊標題同樣的模糊之處。

若 QEngine 在擴展後的競爭範圍中保持領先，競爭說法便會更有力。若另一引擎在生成速度相當的同時改善長輸入或恢復工作階段的延遲，選擇便會更取決於應用程式行為。任何一種結果，都比比較不相容的截圖更具資訊價值。

第三，應留意針對閒置工作階段保留及併發生成的重複混合工作負載測試。報告中的 RAM 結果吸引人，因為它處理了工作階段之間的中斷。其併發減速亦顯示，這項好處需要在持續使用下評估。

重複執行可揭示隨著對話累積及活動改變，暖啟動工作階段恢復是否仍然一致。它們亦可顯示引擎再次處理舊輸入、遇到故障或降低每串流速度的頻率。這些測量將檢驗記憶體配置背後的實際價值。

若恢復表現一致而併發效能可接受，便可加強 RAM 支援對話狀態的論據。若變異頻繁或減速更大，則會將其吸引力限於較輕量的工作負載。任何結果都不需要假裝每個本地助理都服務同一種請求模式。

對考慮作出改變的開發者而言，QEngine RTX 5090 基準測試提供了一個可信的調查理由，同時附帶異常明確的限制。其最大貢獻，是顯示生成速度、提示延遲及對話恢復可朝不同方向變動。

在取代現有引擎之前，請比較使用者實際經歷的等待時間。保留一段具代表性的長對話，引入無關流量，並量度原始工作恢復時會發生甚麼。除了重複提示外，也要納入不同任務，並保留反映所需完成工作的品質檢查。記錄受測版本及配置，避免日後更新抹去比較的意義。QEngine RTX 5090 基準測試為這種評估提出了具說服力的理由，但最終選擇仍取決於來自你工作負載的證據。你的助理花更多時間在生成答案、閱讀愈來愈長的提示，還是恢復你原本以為它會記得的對話？