指南：CUDA 下 MoE 模型推理結(jié)果不可復(fù)現(xiàn)問題的根因與解決方案)
ik_llama.cpp 修復(fù)指南CUDA 下 MoE 模型推理結(jié)果不可復(fù)現(xiàn)問題的根因與解決方案【免費(fèi)下載鏈接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp本指南圍繞 ik_llama.cpp 倉庫中 Issue #249 展開使用llama-perplexity對(duì)同一 MoE 模型如 DeepSeek-Lite多次運(yùn)行會(huì)得到不同的 PPL 值而 token 生成TG在同一隨機(jī)種子下卻可以復(fù)現(xiàn)。文章將帶你定位問題根源CUDA 端mul_mat_id間接矩陣乘中src1行復(fù)制順序的隨機(jī)性剖析 PR #283 的修復(fù)方案基于行映射的確定性拷貝并給出可復(fù)現(xiàn)驗(yàn)證與性能基準(zhǔn)的完整命令行操作。問題現(xiàn)象MoE 模型的 PPL 為什么每次都不一樣在 github-data/issues/249 中作者ikawrakow報(bào)告了一個(gè)影響所有版本的穩(wěn)定復(fù)現(xiàn)問題使用同一 MoE 模型實(shí)測(cè)于 DeepSeek-Lite反復(fù)運(yùn)行l(wèi)lama-perplexity每次得到的 PPL 值都不同使用相同隨機(jī)種子進(jìn)行 token 生成TG時(shí)結(jié)果可以復(fù)現(xiàn)該問題在主線 llama.cpp測(cè)試于 build 4858 / 1e2f78a0中同樣存在并非 ik_llama.cpp 引入的改動(dòng)所致。這一現(xiàn)象對(duì)依賴 perplexity 做量化對(duì)比、回歸測(cè)試的用戶影響很大如果 PPL 本身不可復(fù)現(xiàn)就無法用它作為穩(wěn)定的模型質(zhì)量度量指標(biāo)。值得注意的是問題僅出現(xiàn)在prompt 處理PP階段而 TG 階段正常這為后續(xù)定位指明了方向。根因分析mul_mat_id與src1行復(fù)制的隨機(jī)順序MoEMixture of Experts模型的前向傳播中每個(gè) token 會(huì)經(jīng)由 router 被分發(fā)到不同的專家expert子網(wǎng)。在 ggml/CUDA 后端中這一步通過間接矩陣乘mul_mat_id實(shí)現(xiàn)src0是拼接在一起的專家權(quán)重張量src1是輸入激活ids張量記錄每個(gè) token 應(yīng)當(dāng)路由到哪個(gè)專家。在舊的實(shí)現(xiàn)里PR #283 修復(fù)之前CUDA 后端依賴一個(gè)名為k_copy_src1_to_contiguous的 kernel把src1的行按專家分組復(fù)制到連續(xù)內(nèi)存中以便后續(xù)逐專家執(zhí)行矩陣乘。該 kernel 存在兩個(gè)問題使用原子遞增atomic increment分配目標(biāo)行號(hào)多個(gè)線程塊并發(fā)搶行號(hào)導(dǎo)致行被寫入連續(xù)內(nèi)存的順序取決于調(diào)度競(jìng)態(tài)即作者所說的順序取決于星星今天如何落下depends on how the stars have fallen today該 kernel 被調(diào)用n_as次n_as為專家總數(shù)例如 DeepSeek 系列有 256 個(gè)專家每層都要重復(fù)執(zhí)行這一低效拷貝拖慢了 PP 吞吐。由于浮點(diǎn)加法不滿足結(jié)合律行復(fù)制順序不同會(huì)帶來不同的舍入誤差累積最終導(dǎo)致llama-perplexity每次運(yùn)行得到略有差異的 PPL——這正是非確定性的來源。修復(fù)方案PR #283 的確定性間接矩陣乘PR #283「CUDA: better MoE implementation」從根上替換了這套基于原子操作的拷貝機(jī)制。核心改動(dòng)位于 ggml/src/ggml-cuda.cu1. 在主機(jī)端預(yù)計(jì)算專家計(jì)數(shù)與行映射新增的prepare_row_mappigs見 ggml/src/ggml-cuda.cu#L2824-L2869不再讓 GPU kernel 用原子操作搶行號(hào)而是在主機(jī)端通過cudaMemcpyAsync把ids張量回讀ids_host先cudaStreamSynchronize確保數(shù)據(jù)就緒遍歷ids統(tǒng)計(jì)每個(gè)專家的 token 數(shù)moe_counts并計(jì)算前綴和cum_moe_counts構(gòu)建緊湊的mmid_row_mapping行映射表記錄每個(gè)目標(biāo)行的(id, iid1)坐標(biāo)一次性拷貝到設(shè)備端因此每個(gè)目標(biāo)行在連續(xù)緩沖區(qū)中的位置是編譯期可確定的不再依賴 GPU 調(diào)度競(jìng)態(tài)。對(duì)應(yīng)地寫回階段使用k_copy_dst_from_contiguouskernelggml/src/ggml-cuda.cu#L2789-L2804依據(jù)行映射把結(jié)果行寫回原始張量的正確位置全程確定性。2. 用 CUDA graph 的間接拷貝替代逐專家 kernel 啟動(dòng)修復(fù)后的ggml_cuda_mul_mat_idggml/src/ggml-cuda.cu#L2874整體流程為拷貝src1行到連續(xù)內(nèi)存 → 對(duì)每個(gè)專家執(zhí)行mul_mat→ 把結(jié)果寫回。同時(shí)代碼中還保留了啟發(fā)式分支ggml/src/ggml-cuda.cu#L3240src1-ne[2] 32*src0-ne[2]時(shí)選用mul_mat_id實(shí)現(xiàn)說明后端會(huì)根據(jù) token 數(shù)與專家數(shù)的比例在兩種實(shí)現(xiàn)間自動(dòng)選擇。3. 附帶收益PP 吞吐提升PR 作者在 DeepSeek-Lite 上實(shí)測(cè)修復(fù)后 PP 速度提升約 10%并推斷對(duì)于專家數(shù)量 4 倍于 DeepSeek-Lite 的 DeepSeek-R1 收益可能更大。原因在于舊實(shí)現(xiàn)中k_copy_src1_to_contiguous被調(diào)用了n_as次原子遞增本身又慢新實(shí)現(xiàn)把拷貝合并為一次性確定性拷貝減少了 kernel 啟動(dòng)開銷。驗(yàn)證方法PPL 可復(fù)現(xiàn)性與基準(zhǔn)測(cè)試PR 評(píng)論區(qū)中社區(qū)用戶ubergarm在 Threadripper Pro 24 核 單張 RTX A600048GB上提供了完整的驗(yàn)證流程。以下命令可直接用于你自己的環(huán)境復(fù)測(cè)模型路徑、--n-gpu-layers請(qǐng)按實(shí)際調(diào)整。1. 驗(yàn)證 PPL 可復(fù)現(xiàn)性連續(xù)運(yùn)行兩次llama-perplexity使用相同種子與參數(shù)CUDA_VISIBLE_DEVICES0, \ ./build/bin/llama-perplexity \ --model /path/to/DeepSeek-R1-IQ2_K_R4.gguf \ -ctk q8_0 \ -mla 2 -fa \ -amb 512 \ -fmoe \ --ctx-size 512 \ --ubatch-size 512 \ -f wiki.test.raw \ --seed 1337 \ --n-gpu-layers 63 \ --override-tensor expsCPU \ --threads 24測(cè)試者實(shí)測(cè)兩次運(yùn)行的逐 chunk PPL 序列完全一致最終結(jié)果均為Final estimate: PPL 3.6989 /- 0.02106證明修復(fù)后 PPL 可復(fù)現(xiàn)。關(guān)鍵參數(shù)說明參數(shù)含義-ctk q8_0KV cache 使用 Q8_0 8-bit 量化-mla 2啟用 MLAMulti-head Latent Attention優(yōu)化路徑DeepSeek 系模型專用-fa啟用 Flash Attention-amb 512每個(gè) batch 的異步內(nèi)存拷貝緩沖大小token 數(shù)-fmoe啟用 MoE 專用優(yōu)化路徑與本次修復(fù)直接相關(guān)--seed 1337固定隨機(jī)種子保證采樣路徑一致--override-tensor expsCPU將專家權(quán)重強(qiáng)制放在 CPU用于對(duì)照實(shí)驗(yàn)--ubatch-size 512微批次大小PP 階段每步處理的 token 數(shù)2. 驗(yàn)證 PP 性能使用llama-bench對(duì)比修復(fù)前后CUDA_VISIBLE_DEVICES0, \ ./build/bin/llama-bench \ --model /path/to/DeepSeek-R1-IQ2_K_R4.gguf \ -ctk q8_0 \ -mla 2 -fa 1 \ -amb 512 \ -fmoe 1 \ -p 512,4096 -n 0 \ -gp 512,64 \ -gp 4096,64 \ -r 2 \ --n-gpu-layers 63 \ --override-tensor expsCPU \ --threads 24注意--override-tensor expsCPU時(shí)專家全部跑在 CPUPR 作者明確指出此時(shí)不應(yīng)看到性能差異這正是對(duì)照組的意義。要讓 GPU 端修復(fù)發(fā)揮效果至少要讓部分專家跑在 GPU 上——例如多 GPU 用戶davidsyoung在 16×3090 配置下實(shí)測(cè) PP 吞吐有明顯提升。llama-bench的-p 512,4096指定兩種 prompt 長(zhǎng)度-n 0表示不生成 token-r 2表示重復(fù) 2 次取均值-gp指定 GPU 上的 prompt 長(zhǎng)度與 batch。這類測(cè)試工具的實(shí)現(xiàn)可參考 examples/llama-bench/llama-bench.cpp 與 examples/perplexity/perplexity.cpp。深度補(bǔ)充代碼審查中的異步拷貝同步之爭(zhēng)PR #283 的代碼審查Review環(huán)節(jié)圍繞 ggml/src/ggml-cuda.cu 中一行被注釋掉的cudaStreamSynchronize展開其中包含值得深入理解的 CUDA 并發(fā)知識(shí)審查者JohannesGaessler指出ids_host與rmapping是函數(shù)內(nèi)的棧上/堆上臨時(shí)對(duì)象cudaMemcpyAsync只是把主機(jī)指針排隊(duì)等待拷貝函數(shù)返回后內(nèi)存即失效若不顯式同步理論上可能產(chǎn)生偶發(fā)段錯(cuò)誤或拷入垃圾數(shù)據(jù)作者ikawrakow的回應(yīng)是ids行號(hào)在后續(xù) kernel 調(diào)用中仍會(huì)被使用而 CUDA stream 保證設(shè)備端 kernel 按序執(zhí)行因此排隊(duì)的 memcpy 必然在后續(xù) kernel 使用這些數(shù)據(jù)之前完成從而隱式同步該問題進(jìn)一步記錄于 Issue #313審查者進(jìn)一步澄清k_copy_dst_from_contiguous這類 kernel 只使用設(shè)備指針其數(shù)據(jù)有效性由 CUDA stream 的次序保證自動(dòng)同步而cudaMemcpyAsync涉及主機(jī)內(nèi)存生命周期兩者語義不同。這段討論是理解為什么有的拷貝需要顯式同步、有的不需要的經(jīng)典案例也解釋了最終代碼中prepare_row_mappigs在第一次回讀ids時(shí)保留cudaStreamSynchronize、而第二次主機(jī)→設(shè)備拷貝時(shí)選擇依賴后續(xù) kernel 隱式同步的取舍。經(jīng)驗(yàn)總結(jié)現(xiàn)象定位MoE 模型 PPL 不可復(fù)現(xiàn) TG 可復(fù)現(xiàn)的組合強(qiáng)烈指向 PP 階段 CUDA 間接矩陣乘的并發(fā)拷貝路徑根因k_copy_src1_to_contiguous的原子遞增導(dǎo)致src1行寫入連續(xù)內(nèi)存的順序隨機(jī)浮點(diǎn)累加舍入誤差隨之漂移修復(fù)以主機(jī)端預(yù)計(jì)算的行映射prepare_row_mappigsmmid_row_mapping替代 GPU 原子操作使拷貝順序完全確定同時(shí)因消除了n_as次低效 kernel 啟動(dòng)而帶來約 10% 的 PP 提速DeepSeek-Lite 實(shí)測(cè)驗(yàn)證用固定--seed連續(xù)運(yùn)行兩次llama-perplexity對(duì)比逐 chunk PPL 序列用llama-bench做 PP 吞吐對(duì)照注意--override-tensor expsCPU會(huì)使 GPU 端差異不可見。如果你正在用 ik_llama.cpp 在 CUDA 上跑 DeepSeek 等 MoE 模型做量化對(duì)比或回歸測(cè)試建議確認(rèn)本地構(gòu)建已包含 PR #283 的修復(fù)ggml_cuda_mul_mat_id中使用prepare_row_mappigs的實(shí)現(xiàn)再做一次上述雙跑驗(yàn)證即可獲得可復(fù)現(xiàn)、可信的 PPL 基準(zhǔn)?！久赓M(fèi)下載鏈接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 ik_llama.cpp 修復(fù)指南：CUDA 下 MoE 模型推理結(jié)果不可復(fù)現(xiàn)問題的根因與解決方案
ik_llama.cpp 修復(fù)指南CUDA 下 MoE 模型推理結(jié)果不可復(fù)現(xiàn)問題的根因與解決方案【免費(fèi)下載鏈接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp本指南圍繞 ik_llama.cpp 倉庫中 Issue #249 展開使用llama-perplexity對(duì)同一 MoE 模型如 DeepSeek-Lite多次運(yùn)行會(huì)得到不同的 PPL 值而 token 生成TG在同一隨機(jī)種子下卻可以復(fù)現(xiàn)。文章將帶你定位問題根源CUDA 端mul_mat_id間接矩陣乘中src1行復(fù)制順序的隨機(jī)性剖析 PR #283 的修復(fù)方案基于行映射的確定性拷貝并給出可復(fù)現(xiàn)驗(yàn)證與性能基準(zhǔn)的完整命令行操作。問題現(xiàn)象MoE 模型的 PPL 為什么每次都不一樣在 github-data/issues/249 中作者ikawrakow報(bào)告了一個(gè)影響所有版本的穩(wěn)定復(fù)現(xiàn)問題使用同一 MoE 模型實(shí)測(cè)于 DeepSeek-Lite反復(fù)運(yùn)行l(wèi)lama-perplexity每次得到的 PPL 值都不同使用相同隨機(jī)種子進(jìn)行 token 生成TG時(shí)結(jié)果可以復(fù)現(xiàn)該問題在主線 llama.cpp測(cè)試于 build 4858 / 1e2f78a0中同樣存在并非 ik_llama.cpp 引入的改動(dòng)所致。這一現(xiàn)象對(duì)依賴 perplexity 做量化對(duì)比、回歸測(cè)試的用戶影響很大如果 PPL 本身不可復(fù)現(xiàn)就無法用它作為穩(wěn)定的模型質(zhì)量度量指標(biāo)。值得注意的是問題僅出現(xiàn)在prompt 處理PP階段而 TG 階段正常這為后續(xù)定位指明了方向。根因分析mul_mat_id與src1行復(fù)制的隨機(jī)順序MoEMixture of Experts模型的前向傳播中每個(gè) token 會(huì)經(jīng)由 router 被分發(fā)到不同的專家expert子網(wǎng)。在 ggml/CUDA 后端中這一步通過間接矩陣乘mul_mat_id實(shí)現(xiàn)src0是拼接在一起的專家權(quán)重張量src1是輸入激活ids張量記錄每個(gè) token 應(yīng)當(dāng)路由到哪個(gè)專家。在舊的實(shí)現(xiàn)里PR #283 修復(fù)之前CUDA 后端依賴一個(gè)名為k_copy_src1_to_contiguous的 kernel把src1的行按專家分組復(fù)制到連續(xù)內(nèi)存中以便后續(xù)逐專家執(zhí)行矩陣乘。該 kernel 存在兩個(gè)問題使用原子遞增atomic increment分配目標(biāo)行號(hào)多個(gè)線程塊并發(fā)搶行號(hào)導(dǎo)致行被寫入連續(xù)內(nèi)存的順序取決于調(diào)度競(jìng)態(tài)即作者所說的順序取決于星星今天如何落下depends on how the stars have fallen today該 kernel 被調(diào)用n_as次n_as為專家總數(shù)例如 DeepSeek 系列有 256 個(gè)專家每層都要重復(fù)執(zhí)行這一低效拷貝拖慢了 PP 吞吐。由于浮點(diǎn)加法不滿足結(jié)合律行復(fù)制順序不同會(huì)帶來不同的舍入誤差累積最終導(dǎo)致llama-perplexity每次運(yùn)行得到略有差異的 PPL——這正是非確定性的來源。修復(fù)方案PR #283 的確定性間接矩陣乘PR #283「CUDA: better MoE implementation」從根上替換了這套基于原子操作的拷貝機(jī)制。核心改動(dòng)位于 ggml/src/ggml-cuda.cu1. 在主機(jī)端預(yù)計(jì)算專家計(jì)數(shù)與行映射新增的prepare_row_mappigs見 ggml/src/ggml-cuda.cu#L2824-L2869不再讓 GPU kernel 用原子操作搶行號(hào)而是在主機(jī)端通過cudaMemcpyAsync把ids張量回讀ids_host先cudaStreamSynchronize確保數(shù)據(jù)就緒遍歷ids統(tǒng)計(jì)每個(gè)專家的 token 數(shù)moe_counts并計(jì)算前綴和cum_moe_counts構(gòu)建緊湊的mmid_row_mapping行映射表記錄每個(gè)目標(biāo)行的(id, iid1)坐標(biāo)一次性拷貝到設(shè)備端因此每個(gè)目標(biāo)行在連續(xù)緩沖區(qū)中的位置是編譯期可確定的不再依賴 GPU 調(diào)度競(jìng)態(tài)。對(duì)應(yīng)地寫回階段使用k_copy_dst_from_contiguouskernelggml/src/ggml-cuda.cu#L2789-L2804依據(jù)行映射把結(jié)果行寫回原始張量的正確位置全程確定性。2. 用 CUDA graph 的間接拷貝替代逐專家 kernel 啟動(dòng)修復(fù)后的ggml_cuda_mul_mat_idggml/src/ggml-cuda.cu#L2874整體流程為拷貝src1行到連續(xù)內(nèi)存 → 對(duì)每個(gè)專家執(zhí)行mul_mat→ 把結(jié)果寫回。同時(shí)代碼中還保留了啟發(fā)式分支ggml/src/ggml-cuda.cu#L3240src1-ne[2] 32*src0-ne[2]時(shí)選用mul_mat_id實(shí)現(xiàn)說明后端會(huì)根據(jù) token 數(shù)與專家數(shù)的比例在兩種實(shí)現(xiàn)間自動(dòng)選擇。3. 附帶收益PP 吞吐提升PR 作者在 DeepSeek-Lite 上實(shí)測(cè)修復(fù)后 PP 速度提升約 10%并推斷對(duì)于專家數(shù)量 4 倍于 DeepSeek-Lite 的 DeepSeek-R1 收益可能更大。原因在于舊實(shí)現(xiàn)中k_copy_src1_to_contiguous被調(diào)用了n_as次原子遞增本身又慢新實(shí)現(xiàn)把拷貝合并為一次性確定性拷貝減少了 kernel 啟動(dòng)開銷。驗(yàn)證方法PPL 可復(fù)現(xiàn)性與基準(zhǔn)測(cè)試PR 評(píng)論區(qū)中社區(qū)用戶ubergarm在 Threadripper Pro 24 核 單張 RTX A600048GB上提供了完整的驗(yàn)證流程。以下命令可直接用于你自己的環(huán)境復(fù)測(cè)模型路徑、--n-gpu-layers請(qǐng)按實(shí)際調(diào)整。1. 驗(yàn)證 PPL 可復(fù)現(xiàn)性連續(xù)運(yùn)行兩次llama-perplexity使用相同種子與參數(shù)CUDA_VISIBLE_DEVICES0, \ ./build/bin/llama-perplexity \ --model /path/to/DeepSeek-R1-IQ2_K_R4.gguf \ -ctk q8_0 \ -mla 2 -fa \ -amb 512 \ -fmoe \ --ctx-size 512 \ --ubatch-size 512 \ -f wiki.test.raw \ --seed 1337 \ --n-gpu-layers 63 \ --override-tensor expsCPU \ --threads 24測(cè)試者實(shí)測(cè)兩次運(yùn)行的逐 chunk PPL 序列完全一致最終結(jié)果均為Final estimate: PPL 3.6989 /- 0.02106證明修復(fù)后 PPL 可復(fù)現(xiàn)。關(guān)鍵參數(shù)說明參數(shù)含義-ctk q8_0KV cache 使用 Q8_0 8-bit 量化-mla 2啟用 MLAMulti-head Latent Attention優(yōu)化路徑DeepSeek 系模型專用-fa啟用 Flash Attention-amb 512每個(gè) batch 的異步內(nèi)存拷貝緩沖大小token 數(shù)-fmoe啟用 MoE 專用優(yōu)化路徑與本次修復(fù)直接相關(guān)--seed 1337固定隨機(jī)種子保證采樣路徑一致--override-tensor expsCPU將專家權(quán)重強(qiáng)制放在 CPU用于對(duì)照實(shí)驗(yàn)--ubatch-size 512微批次大小PP 階段每步處理的 token 數(shù)2. 驗(yàn)證 PP 性能使用llama-bench對(duì)比修復(fù)前后CUDA_VISIBLE_DEVICES0, \ ./build/bin/llama-bench \ --model /path/to/DeepSeek-R1-IQ2_K_R4.gguf \ -ctk q8_0 \ -mla 2 -fa 1 \ -amb 512 \ -fmoe 1 \ -p 512,4096 -n 0 \ -gp 512,64 \ -gp 4096,64 \ -r 2 \ --n-gpu-layers 63 \ --override-tensor expsCPU \ --threads 24注意--override-tensor expsCPU時(shí)專家全部跑在 CPUPR 作者明確指出此時(shí)不應(yīng)看到性能差異這正是對(duì)照組的意義。要讓 GPU 端修復(fù)發(fā)揮效果至少要讓部分專家跑在 GPU 上——例如多 GPU 用戶davidsyoung在 16×3090 配置下實(shí)測(cè) PP 吞吐有明顯提升。llama-bench的-p 512,4096指定兩種 prompt 長(zhǎng)度-n 0表示不生成 token-r 2表示重復(fù) 2 次取均值-gp指定 GPU 上的 prompt 長(zhǎng)度與 batch。這類測(cè)試工具的實(shí)現(xiàn)可參考 examples/llama-bench/llama-bench.cpp 與 examples/perplexity/perplexity.cpp。深度補(bǔ)充代碼審查中的異步拷貝同步之爭(zhēng)PR #283 的代碼審查Review環(huán)節(jié)圍繞 ggml/src/ggml-cuda.cu 中一行被注釋掉的cudaStreamSynchronize展開其中包含值得深入理解的 CUDA 并發(fā)知識(shí)審查者JohannesGaessler指出ids_host與rmapping是函數(shù)內(nèi)的棧上/堆上臨時(shí)對(duì)象cudaMemcpyAsync只是把主機(jī)指針排隊(duì)等待拷貝函數(shù)返回后內(nèi)存即失效若不顯式同步理論上可能產(chǎn)生偶發(fā)段錯(cuò)誤或拷入垃圾數(shù)據(jù)作者ikawrakow的回應(yīng)是ids行號(hào)在后續(xù) kernel 調(diào)用中仍會(huì)被使用而 CUDA stream 保證設(shè)備端 kernel 按序執(zhí)行因此排隊(duì)的 memcpy 必然在后續(xù) kernel 使用這些數(shù)據(jù)之前完成從而隱式同步該問題進(jìn)一步記錄于 Issue #313審查者進(jìn)一步澄清k_copy_dst_from_contiguous這類 kernel 只使用設(shè)備指針其數(shù)據(jù)有效性由 CUDA stream 的次序保證自動(dòng)同步而cudaMemcpyAsync涉及主機(jī)內(nèi)存生命周期兩者語義不同。這段討論是理解為什么有的拷貝需要顯式同步、有的不需要的經(jīng)典案例也解釋了最終代碼中prepare_row_mappigs在第一次回讀ids時(shí)保留cudaStreamSynchronize、而第二次主機(jī)→設(shè)備拷貝時(shí)選擇依賴后續(xù) kernel 隱式同步的取舍。經(jīng)驗(yàn)總結(jié)現(xiàn)象定位MoE 模型 PPL 不可復(fù)現(xiàn) TG 可復(fù)現(xiàn)的組合強(qiáng)烈指向 PP 階段 CUDA 間接矩陣乘的并發(fā)拷貝路徑根因k_copy_src1_to_contiguous的原子遞增導(dǎo)致src1行寫入連續(xù)內(nèi)存的順序隨機(jī)浮點(diǎn)累加舍入誤差隨之漂移修復(fù)以主機(jī)端預(yù)計(jì)算的行映射prepare_row_mappigsmmid_row_mapping替代 GPU 原子操作使拷貝順序完全確定同時(shí)因消除了n_as次低效 kernel 啟動(dòng)而帶來約 10% 的 PP 提速DeepSeek-Lite 實(shí)測(cè)驗(yàn)證用固定--seed連續(xù)運(yùn)行兩次llama-perplexity對(duì)比逐 chunk PPL 序列用llama-bench做 PP 吞吐對(duì)照注意--override-tensor expsCPU會(huì)使 GPU 端差異不可見。如果你正在用 ik_llama.cpp 在 CUDA 上跑 DeepSeek 等 MoE 模型做量化對(duì)比或回歸測(cè)試建議確認(rèn)本地構(gòu)建已包含 PR #283 的修復(fù)ggml_cuda_mul_mat_id中使用prepare_row_mappigs的實(shí)現(xiàn)再做一次上述雙跑驗(yàn)證即可獲得可復(fù)現(xiàn)、可信的 PPL 基準(zhǔn)?！久赓M(fèi)下載鏈接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考