Kimi-K2.5 的初步測試通過 KTransformers+SGLang,在一個混合的 4x RTX Pro 6000 Blackwell + 640GB/1.5TB CPU 記憶體卸載上進行。計算由 Lium pods 提供: - 19.97 輸出 tok/s @ 10 個並發請求 - 平均 TTFT: ~120s - 中位數 TTFT: ~102s 需要調整 KT 標誌以進一步優化此設置,這在很大程度上取決於整體系統的 CPU 核心數量和可用 RAM。GPU <-> PCIe <-> RAM 的互連是最明顯的瓶頸。 每個 MoE 層的專家數量在 GPU 上: --kt-num-gpu-experts=128 專門用於 MoE 推理的 CPU 核心: --kt-cpuinfer=104 CPU 專家與 GPU 工作重疊: --kt-max-deferred-experts-per-token=2 每個預填充塊的最大標記數: --chunked-prefill-size=32658 禁用 CUDA 圖捕獲: --disable-cuda-graph
Yannick Nick
Yannick Nick2026年2月25日
在8個RTX Pro 6000 Blackwells上運行Kimi-K2.5,計劃最終通過KTransformers+SGLang在4個相同的GPU上測試CPU/GPU混合推理設置。 非常好奇與在4個GPU上量化的Kimi-K2.5適配相比,混合設置的整體性能如何。混合設置需要接近768GB的RAM。 首先,這裡是使用合成編碼代理樣式工作負載的8個GPU的基準,目標是2k-45k的輸入標記,80-3k的最大輸出標記,並且最多支持10個並發請求。SGLang的--mem-fraction-static標誌設置為0.90。 基準平均吞吐量: ~74輸出標記/秒 @ 10個並發請求
KTransformers+SGLang 標誌以重現工作: ========== export CUDA_VISIBLE_DEVICES=0,1,2,3 export OMP_NUM_THREADS=1 export MKL_NUM_THREADS=1 export OPENBLAS_NUM_THREADS=1 export NUMEXPR_NUM_THREADS=1 export VECLIB_MAXIMUM_THREADS=1 python -m sglang.launch_server \ --model-path <HF_PATH>/models--moonshotai--Kimi-K2.5/snapshots/3367c8d1c68584429fab7faf845a32d5195b6ac1 \ --kt-weight-path <HF_PATH>/models--moonshotai--Kimi-K2.5/snapshots/3367c8d1c68584429fab7faf845a32d5195b6ac1 \ --kt-cpuinfer 104 \ --kt-threadpool-count 2 \ --kt-num-gpu-experts 128 \ --kt-max-deferred-experts-per-token 2 \ --kt-method RAWINT4 \ --kt-gpu-prefill-token-threshold 400 \ --kt-expert-placement-strategy uniform \ --trust-remote-code \ --mem-fraction-static 0.90 \ --served-model-name kimi_k2 \ --tool-call-parser kimi_k2 \ --reasoning-parser kimi_k2 \ --disable-radix-cache \ --disable-chunked-prefix-cache \ --enable-mixed-chunk \ --tensor-parallel-size 4 \ --enable-p2p-check \ --disable-shared-experts-fusion \ --chunked-prefill-size 32658 \ --max-total-tokens 120000 \ --attention-backend flashinfer \ --disable-cuda-graph \ --host 0.0.0.0 \ --port 8000
136