GPU卸载与上下文扩展结果 | AI生成和翻译

Home 2026.04

综合总结

设置过程

初始状态（根据您的信息）：

步骤 1 — 增加 GPU 层数

从 ngl 20 提升至 ngl 35（会话开始时已完成），然后推至完全卸载：

ngl VRAM 使用量 GPU 层数 CPU 层数
20 ~2,695 MiB 20 / 43 23
35 ~5,030 MiB 35 / 43 8
43 ~5,182 MiB 43 / 43 0

从 ngl 35 提升至 43（完全卸载）仅增加了 152 MiB 成本 —— 基本上是免费的。推理过程中再无 CPU↔GPU 数据传输。

步骤 2 — 上下文长度：32k → 64k

使用 -c 65536 重新启动。KV缓存翻倍，但对VRAM的影响不大：

上下文长度 VRAM（空闲时） VRAM（处理长提示后）
32k ~5,030 MiB ~5,182 MiB
64k ~6,118 MiB ~6,646 MiB

上下文长度翻倍的成本：空闲时增加 936 MiB，处理 6 万 token 推理时额外增加 528 MiB。仍有 5GB+ 的剩余空间。

步骤 3 — 长提示压力测试

第一次测试（32k 上下文时期）：12,020 token 提示 → 6.9 秒成功

64k 上下文测试：

提示 token 数 占 64k 上下文的百分比 生成长度 总耗时 生成速度
20,025 30% 385 tok 7.5s 51.6 tok/s
40,025 61% 383 tok 14.1s 27.1 tok/s
60,025 92% 444 tok 20.2s 22.0 tok/s

所有测试均未崩溃。

性能分析

速度与上下文深度的关系：

20k 提示 → 51.6 tok/s  （基线）
40k 提示 → 27.1 tok/s  （比20k下降 47%）
60k 提示 → 22.0 tok/s  （比20k下降 57%）

这是预期内的 —— 注意力计算复杂度为 O(n²)，因此随着 KV 缓存中的 token 增多，生成速度会变慢。不过模型质量并未下降 —— 在所有长度下回答都保持连贯。

预填充吞吐量（根据总时间粗略估算）：

预填充很快，因为它在 GPU 上是并行化的；生成是瓶颈。

最终服务器配置

llama-server \
  -m gemma-4-E4B-it-Q5_K_M.gguf \
  --flash-attn off \
  -ngl 43 \          # 完全 GPU 卸载
  -c 65536 \         # 64k 上下文
  --host 0.0.0.0 \
  --port 8081
资源 使用量 空闲量
VRAM（总量 12,282 MiB） ~6,646 MiB 空闲约 5,600 MiB
上下文长度 65,536 tokens 最多可达 131,072（模型上限）
GPU 层数 43/43 完全卸载

潜在后续步骤（如需更高速度）：

Back Donate