連結 https://github.com/ggml-org/llama.cpp/pull/22673 已經合併 直接pull編譯即可 參數範例摘要 啟動草案MTP預測與平行量設定(2) llama-server -hf [model-with-mtp] --spec-type draft-mtp --spec-draft-n-max 2 同時啟用MTP與ngram(適用於非CUDA環境) llama-server -hf [model-with-mtp] \ --spec-type draft-mtp --spec-draft-n-max 3 \ --spec-type ngram-mod --spec-ngram-mod-n-match 24 \ --spec-ngram-mod-n-min 48 --spec-ngram-mod-n-max 64 上面比較短的寫法 llama-server -hf [model-with-mtp] --spec-default \ --spec-type draft-mtp --spec-draft-n-max 3 我在qwen3.6-27B-mtp q4km 在 --spec-draft-n-max 3時 使用現有工作流中的三種典型負載 context/output 長長 長短 短長 三種組合測試後得出下列結論 prefill速度大約下降40%~50% decode速度上升約 6%~30% #要視生成類型而定 落差很大 說實話考慮到額外記憶體的開銷 這不是非常讓人滿意的數字 這可能與我採用的量化和任務類型有關 在reddit的說法是Q8以上和任務類型為程式語言這類高格式性的任務 帶來的收益會更顯著 Q4km以下的分析任務和創意寫作任務可能會接近零收益甚至負收益 https://www.reddit.com/r/LocalLLaMA/comments/1t9gcar/mtp_benchmark_results_the _nature_of_the/ 我大量使用長context推論 因此目前對我來說整體是負面收益的 期待後續的最佳化 但目前是否划算 依然取決於每個人自己的任務類型 是否適合這種推理方式 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.229.28.82 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/AI_Art/M.1778965214.A.D92.html 就像所有的壓縮法都不保證可以越壓越小 總是會有一些極端狀況... 速度會下降是原本就能預想的 因為要維護兩份kvcache 但是幾乎直接腰斬就是代表幾乎沒有可以重用的部分 這可能是因為qwen並非原生的投機解碼模型 而是用小模型來當大模型的草稿 缺乏架構上的統一和最佳化 之後可能會有效率更高的模型和更好的最佳化實作 所以現在合併這個PR可能只把支援性框架做出來 而不是馬上就能適合所有人 ※ 編輯: patvessel (125.229.28.82 臺灣), 05/17/2026 12:08:04 推 Kroner: 關節痛按摩有效嗎？ 05/17 12:54推 Kroner: 喔喔喔，UC2 真的是超讚的啦 05/20 00:44推 Kroner: 樓下關節痛都吃鞏固力 05/20 01:57推 Kroner: UC2神招啊，吃下去就對了 05/20 10:19推 Chricey: 剛開始吃UC2，期待 05/20 12:22推 Chricey: 關節痛這種東西，比鬼還可怕！ 05/20 13:40