Gemma4 RTX 4070 性能基准评测 | AI生成和翻译

Home 2026.04

综合评测：RTX 4070 运行 Gemma4 —— 完整问题排查与基准测试

系统配置

组件 详情
操作系统 Ubuntu，Linux 6.8.0-107-generic x86_64
GPU NVIDIA RTX 4070（12GB 显存），CUDA 13.0，驱动 580.126.20
内存 总容量 62GB，可用约 57GB
CPU 32 核心
llama.cpp 提交版本 94ca829b6，构建参数 GGML_CUDA=ON、GGML_CUDA_FA=ON，Release -O3
模型 gemma-4-26B-A4B-it-UD-IQ2_M.gguf（9.3GB）

根本原因：CUDA Flash Attention 崩溃

现象： 在 llama_decode 过程中，ggml_backend_cuda_buffer_set_tensor 反复出现 CUDA 错误。

原因： Gemma4 具有异构架构：

修复方法： --flash-attn off —— 强制使用回退路径，将 V 缓存填充至 2048 维，此方法工作正常。

基准测试结果

所有配置均在 --flash-attn off 下测试，模型完全加载（IQ2_M 9.3GB）。

配置 上下文长度 -ngl GPU/CPU 层数 显存占用 提示词处理速度 生成速度 最大测试提示词长度
全 GPU 4,096 99 31/0 11.3GB 127 词元/秒 92 词元/秒 27 词元
全 GPU 8,192 99 31/0 11.5GB 1,718 词元/秒 92 词元/秒 5,906 词元
混合 16,384 26 26/5 10.2GB 1,286 词元/秒 32 词元/秒 13,436 词元
混合 32,768 20 20/11 9.2GB 793 词元/秒 15 词元/秒 26,828 词元

失败配置： | 配置 | 原因 | |——–|——–| | 32K + ngl 99 | 启动时 OOM —— 计算缓冲区分配失败 | | 16K + ngl 99 | 推理过程中 OOM —— MUL_MAT CUDA OOM |

关键观察

  1. 生成速度随 CPU 卸载线性下降 —— 每个层移至 CPU 导致速度下降约 7 词元/秒。32K 配置比 8K 慢 6 倍，因为 11/31 的层在 CPU 上运行。

  2. 提示词处理保持高速 —— 即使在 32K 上下文且大量 CPU 卸载的情况下，提示词处理仍有 793 词元/秒，因为它是批处理的且得益于并行性。

  3. V 缓存填充开销 —— 在没有 FA 的情况下，V 缓存将每层的 V 嵌入填充到 2048 维，无论实际大小如何。这会浪费显存：
    • 非 SWA KV（5 层）：8K 时 320MB，32K 时 960MB
    • SWA KV（25 层）：800-900MB（受滑动窗口大小限制）
  4. 32K / ngl 20 配置下的显存分配明细：
    • 模型（20 个 GPU 层）：约 6.1GB
    • 非 SWA KV 缓存：约 960MB
    • SWA KV 缓存：约 900MB
    • 计算缓冲区：约 1.0GB
    • 总计：约 9.0GB —— 留有 3GB 余量
  5. IQ2_M 质量 —— 这是一种激进的 2 位量化。模型产生了推理轨迹（reasoning_content），但在大多数测试中实际的 content 响应为空，这表明模型将词元预算用在了思维链上。可能需要 --override-kv 或提示词调优。

建议

优先级 操作
立即使用 若需速度（92 词元/秒）用 8K/ngl 99，若需长上下文（15 词元/秒）用 32K/ngl 20
质量 考虑使用 IQ3_S 量化版本（11GB）+ 4K 上下文 + ngl 99 —— 质量更好，仍能装入显存
关注上游 关注 llama.cpp 关于 gemma4 FA 修复的 PR —— 重新启用 FA 可节省约 200-400MB 的 V 缓存填充开销，可能实现全 GPU 速度下的 16K 上下文
生产环境 更新 /home/lzw/llama.sh 以反映你最终选择的配置
提示词格式 服务器自动检测到的聊天格式为 peg-gemma4 并启用了思考功能 —— 若想获得无推理轨迹的直接答案，请传递 "thinking": false 或调整系统提示词

当前状态

服务器运行于 http://192.168.1.36:8081，配置为 32K 上下文，ngl 20，flash-attn off。状态稳定，已测试至 26,828 词元。

Back Donate