GPU 卸载研究笔记llama.cpp 的做法与我们的差异—— 为什么 llama 卸载快、我们上传慢30-98 秒/张量、如何改进2026-08-11 研究记录。参考llama.cpp 源码D:\svn\ucp\ai\main\llama.cpp静态阅读。背景我们的 GPU 卸载测试llmx_诊断GPU推理完整初始化时每张量上传 30-98 秒——机器被拖垮。结论我们的上传设计CPU 反量化 逐张量上传与 llama 的零拷贝设计有本质差异。一、llama.cpp 的 GPU 卸载方式源码核实1.1 零拷贝内存映射核心llama-model.cpp 关键路径// 权重 buffer 分配直接把 mmap 的模型文件区域映射为 GPU backend bufferif(ml.use_mmapuse_mmap_bufferbuffer_from_host_ptr_supported){ggml_backend_buffer_t bufggml_backend_dev_buffer_from_host_ptr(dev,(char*)addrfirst,last-first,max_size);}模型文件 mmap 到内存已有的映射GPU backend 直接借用宿主内存指针buffer_from_host_ptr——CUDA 的 UVA/按需传输不反量化、不转置、不逐张量拷贝——权重以量化格式q8_0/q4_k 块原样留在映射区域显存不足时部分卸载-ngl 层数控制只卸部分层1.2 GPU 端量化 GEMV权重保持量化格式q8_0 34B 块等在 GPU 显存GEMV 内核mmvq.cu在 GPU 上反量化计算vec_dot 系列不需要 f32 反量化中间体——省显存、省传输、省 CPU 反量化1.3 关键设计点设计点llama.cpp权重格式量化块原样上传时机初始化时按需buffer 借用CPU 工作仅 mmap buffer 映射GPU 端量化 GEMV 内核反量化显存管理部分卸载层粒度二、我们的设计llmx与差异2.1 当前实现GPU推理.cpp GPU缓存添加// 1. CPU 反量化16 线程并行q8_0 块 → f32// 2. 列主序跳跃写权重列主序[行 列×输出维]每元素跳 4×输出维 字节// 3. cudaMalloc每张量一次// 4. cudaMemcpy H2Df3222.4GB 权重 → CPU 反量化 → 2.8GB f32或 fp16 1.4GB291 次 cudaMalloc 291 次上传上传后 f32 常驻显存推理时 cuBLAS GEMM列主序2.2 差异对比llama.cppllmxCPU 反量化无量化原样22.4GB 全量反量化上传数据量化块按需f32 2.8GB逐张量布局行主序原样列主序转置GPU 内核量化 GEMVmmvqcuBLAS f32 GEMM显存部分卸载全量投影2.8GB2.3 慢/卡顿的候选根因分析候选分析验证列主序跳跃写每元素跳 4×输出维 字节——缓存/TLB 压力纯 CPU 基准1MB 0.9ms / 64MB 7.3ms——不是根因CPU 反量化 22.4GB16 核全速 内存带宽饱和——机器卡顿主因用户生产任务被抢占理论 ~1-2 秒但全核占用拖垮机器逐张量 cudaMalloc ×291显存碎片/压力环境显存被其他进程占用时未验证需插桩逐张量上传 ×291G2 验证 35MB 5ms——快已排除综合30-98 秒/张量的确切原因未锁定——需插桩分段计时待插桩三、改进方向受 cuBLAS 约束——无自定义 CUDA 内核能力我们的约束cuBLAS 只支持 f32/fp16 GEMM无量化内核→必须反量化上传。可改进反量化限核上传反量化用 4-8 核慢但机器不卡——用户环境任务重行主序顺序写 → 分块转置反量化按行主序顺序写缓存友好再 32×32 tile 转置到列主序fp16 默认上传 1.4GB减半——传输/显存压力减半数值待 GPU 测试验证批量分配一次 cudaMalloc 大 buffer消除 291 次分配 碎片插桩分段计时反量化/分配/上传各自耗时——精确定位 30-98 秒长期方向若有 nvcc/CUDA 工具链量化块原样上传22.4GB 显存不够——需部分卸载自定义量化 GEMV 内核mmvq 式——但显存预算 6GB 内只能卸载投影的 fp16 表示四、结论llama 的零拷贝 mmap 方案不适用于我们需要 CUDA 自定义内核 量化 GEMV——超出现有能力我们 30-98 秒/张量的根因未锁定——列主序已排除基准 0.9ms/1MB——最可能反量化全核占用 显存压力综合最小改进限核反量化 fp16 上传 插桩定位机器卡顿的直接原因上传反量化 22.4GB 全核全带宽——这是设计上不可避免的初始化开销llama 通过零拷贝规避——我们只能降低并行度换机器可用性研究记录llama 方案分析 我们的差异 根因候选 改进方向。插桩代码待批准后运行定位。三、2026-08-12 更新验证后上传性能结论修正291 张量上传实测0.1-0.9 秒/张量限核 4 32×32 分块转置 行主序顺序写优化后——之前 30-98 秒/张量的结论已过时当时的根因 16 核全速反量化 22.4GB 拖垮机器 版本不匹配卡死。GPU 卸载验证通过2026-08-12分步验证版本 12.0 匹配/预热 OK/上传 291/291/GEMM 位级一致/引擎 f32fp16 logits 一致/多轮记忆正常——系统未崩——五重防护生效。操作方式对齐 llama.cppLLMX_GPU_LAYERS 层粒度——–ngl 语义。详细见 docs/13 第四章与 docs/00 M3。补充2026-08-13卸载层位报告对齐 llamaoffloaded N/N——LAYERS1/5/20 验证一致llmx 主程序端到端验证20/41 报告正确——生成一致——3.8 tok/s 传输主导全量首次启动约 6 分钟一次性上传。 GPU 卸载研究笔记：llama.cpp 的做法与我们的差异
GPU 卸载研究笔记llama.cpp 的做法与我们的差异—— 为什么 llama 卸载快、我们上传慢30-98 秒/张量、如何改进2026-08-11 研究记录。参考llama.cpp 源码D:\svn\ucp\ai\main\llama.cpp静态阅读。背景我们的 GPU 卸载测试llmx_诊断GPU推理完整初始化时每张量上传 30-98 秒——机器被拖垮。结论我们的上传设计CPU 反量化 逐张量上传与 llama 的零拷贝设计有本质差异。一、llama.cpp 的 GPU 卸载方式源码核实1.1 零拷贝内存映射核心llama-model.cpp 关键路径// 权重 buffer 分配直接把 mmap 的模型文件区域映射为 GPU backend bufferif(ml.use_mmapuse_mmap_bufferbuffer_from_host_ptr_supported){ggml_backend_buffer_t bufggml_backend_dev_buffer_from_host_ptr(dev,(char*)addrfirst,last-first,max_size);}模型文件 mmap 到内存已有的映射GPU backend 直接借用宿主内存指针buffer_from_host_ptr——CUDA 的 UVA/按需传输不反量化、不转置、不逐张量拷贝——权重以量化格式q8_0/q4_k 块原样留在映射区域显存不足时部分卸载-ngl 层数控制只卸部分层1.2 GPU 端量化 GEMV权重保持量化格式q8_0 34B 块等在 GPU 显存GEMV 内核mmvq.cu在 GPU 上反量化计算vec_dot 系列不需要 f32 反量化中间体——省显存、省传输、省 CPU 反量化1.3 关键设计点设计点llama.cpp权重格式量化块原样上传时机初始化时按需buffer 借用CPU 工作仅 mmap buffer 映射GPU 端量化 GEMV 内核反量化显存管理部分卸载层粒度二、我们的设计llmx与差异2.1 当前实现GPU推理.cpp GPU缓存添加// 1. CPU 反量化16 线程并行q8_0 块 → f32// 2. 列主序跳跃写权重列主序[行 列×输出维]每元素跳 4×输出维 字节// 3. cudaMalloc每张量一次// 4. cudaMemcpy H2Df3222.4GB 权重 → CPU 反量化 → 2.8GB f32或 fp16 1.4GB291 次 cudaMalloc 291 次上传上传后 f32 常驻显存推理时 cuBLAS GEMM列主序2.2 差异对比llama.cppllmxCPU 反量化无量化原样22.4GB 全量反量化上传数据量化块按需f32 2.8GB逐张量布局行主序原样列主序转置GPU 内核量化 GEMVmmvqcuBLAS f32 GEMM显存部分卸载全量投影2.8GB2.3 慢/卡顿的候选根因分析候选分析验证列主序跳跃写每元素跳 4×输出维 字节——缓存/TLB 压力纯 CPU 基准1MB 0.9ms / 64MB 7.3ms——不是根因CPU 反量化 22.4GB16 核全速 内存带宽饱和——机器卡顿主因用户生产任务被抢占理论 ~1-2 秒但全核占用拖垮机器逐张量 cudaMalloc ×291显存碎片/压力环境显存被其他进程占用时未验证需插桩逐张量上传 ×291G2 验证 35MB 5ms——快已排除综合30-98 秒/张量的确切原因未锁定——需插桩分段计时待插桩三、改进方向受 cuBLAS 约束——无自定义 CUDA 内核能力我们的约束cuBLAS 只支持 f32/fp16 GEMM无量化内核→必须反量化上传。可改进反量化限核上传反量化用 4-8 核慢但机器不卡——用户环境任务重行主序顺序写 → 分块转置反量化按行主序顺序写缓存友好再 32×32 tile 转置到列主序fp16 默认上传 1.4GB减半——传输/显存压力减半数值待 GPU 测试验证批量分配一次 cudaMalloc 大 buffer消除 291 次分配 碎片插桩分段计时反量化/分配/上传各自耗时——精确定位 30-98 秒长期方向若有 nvcc/CUDA 工具链量化块原样上传22.4GB 显存不够——需部分卸载自定义量化 GEMV 内核mmvq 式——但显存预算 6GB 内只能卸载投影的 fp16 表示四、结论llama 的零拷贝 mmap 方案不适用于我们需要 CUDA 自定义内核 量化 GEMV——超出现有能力我们 30-98 秒/张量的根因未锁定——列主序已排除基准 0.9ms/1MB——最可能反量化全核占用 显存压力综合最小改进限核反量化 fp16 上传 插桩定位机器卡顿的直接原因上传反量化 22.4GB 全核全带宽——这是设计上不可避免的初始化开销llama 通过零拷贝规避——我们只能降低并行度换机器可用性研究记录llama 方案分析 我们的差异 根因候选 改进方向。插桩代码待批准后运行定位。三、2026-08-12 更新验证后上传性能结论修正291 张量上传实测0.1-0.9 秒/张量限核 4 32×32 分块转置 行主序顺序写优化后——之前 30-98 秒/张量的结论已过时当时的根因 16 核全速反量化 22.4GB 拖垮机器 版本不匹配卡死。GPU 卸载验证通过2026-08-12分步验证版本 12.0 匹配/预热 OK/上传 291/291/GEMM 位级一致/引擎 f32fp16 logits 一致/多轮记忆正常——系统未崩——五重防护生效。操作方式对齐 llama.cppLLMX_GPU_LAYERS 层粒度——–ngl 语义。详细见 docs/13 第四章与 docs/00 M3。补充2026-08-13卸载层位报告对齐 llamaoffloaded N/N——LAYERS1/5/20 验证一致llmx 主程序端到端验证20/41 报告正确——生成一致——3.8 tok/s 传输主导全量首次启动约 6 分钟一次性上传。