Gemma 4B Q5 性能评估 | AI生成和翻译
旅程与发现：在 RTX 4070 上运行 gemma-4-E4B-it-Q5_K_M.gguf
我们开始时的状况
- 之前的模型：
gemma-4-26B-A4B-it-UD-IQ2_M.gguf— 一个使用激进 IQ2_M 量化的 26B MoE 模型 - 新模型：
gemma-4-E4B-it-Q5_K_M.gguf— 5.5GB，采用 Q5_K_M 量化（质量高得多） - 硬件：RTX 4070（12GB 显存），20 层卸载到 GPU，32k 上下文长度，端口 8081
切换过程
终止了旧进程（PID 135703），启动了新进程。服务器在约 5 秒内正常启动，提供 4 个槽位，每个槽位分配了 32768 个令牌的上下文长度。模型加载过程中未出现问题。
测试 1：中等长度提示词（约 7.3k 令牌）
- 200 个重复的主题描述
- 结果：成功，处理了 7320 个提示令牌
- 总共耗时约 14.8 秒
- 服务器保持稳定
测试 2：重度提示词（约 26k 令牌）
- 310 段密集的技术文本 — 逼近 32k 的极限
- 结果：成功，处理了 26157 个提示令牌
- 关键发现：这是一个思考型模型。响应包含
reasoning_content（内部思维链）和content（最终答案）。当max_tokens只设置为 100-200 时，所有预算都用于了思考 — 可见的content是空的 - 速度：约 10.8 个令牌/秒的生成速度，约 92 毫秒/令牌
- 提示词缓存生效：第二次请求命中了缓存（26156/26157 个令牌被缓存），提示词评估时间降至仅 96 毫秒（针对那 1 个新令牌）
- 内存：在处理重度提示词时，RSS 从约 5GB 增长到约 6.5GB — 完全在该机器 64GB RAM 的承受范围内
测试 3：超限提示词（约 76k 令牌）
- 800 段文本，超出了 32k 上下文限制
- 结果：服务器返回了 HTTP 400 错误，并附有清晰的信息：“请求（76612 个令牌）超过了可用的上下文大小（32768 个令牌）”
- 没有崩溃，没有挂起，没有数据损坏。服务器在之后继续正常服务
关键发现
| 指标 | 数值 |
|---|---|
| 模型磁盘大小 | 5.5 GB |
| 量化方式 | Q5_K_M（高质量） |
| 负载下的 RSS | 约 6.5 GB |
| 生成速度 | 约 10.8 令牌/秒 |
| 提示词评估（已缓存） | 26k 已缓存令牌仅需 96 毫秒 |
| 思考型模型 | 是 — 使用 reasoning_content 字段 |
| 稳定性 | 所有测试中均无崩溃 |
| 上下文限制处理 | 优雅的 400 错误 |
观察总结
-
E4B 对比 26B-A4B：模型名称 E4B 暗示这可能是一个比之前运行的 26B-A4B 更小或不同的 MoE 配置。Q5_K_M 量化比 IQ2_M 质量高得多 — 压缩伪影更少，输出质量更好，代价是文件体积更大。
-
思考模型行为：如果你通过 API 客户端使用它，需要注意思考令牌会占用
max_tokens的配额。需要将max_tokens设置得更高（例如 1024+），以便为推理后的实际输出留出空间。 -
性能稳健：约 10.8 令牌/秒的速度对于交互式聊天是可用的。提示词缓存是一个不错的加分项 — 重复或相似的提示词能获得近乎即时的提示词评估。
-
在 32k 上下文限制下无崩溃：你所问的主要问题 — 它能很好地处理长提示词。即使请求超过限制，服务器也能保持稳定。