24GB 显存单用户只快 1.2 倍：L4 跑 Gemma 4 的真实并发收益

核心洞察

这篇文章最有意思的点是：24GB 的 L4 在单用户场景下只比 8GB 的桌面卡快 1.2 到 1.3 倍，模型只占了显存的零头，剩下的全在空转。真正拉开差距的是并发，64 个请求同时打进来，L4 才把 3050 甩开 1.6 倍。如果你只关心一件事，看这个：草稿模型的最佳长度不是固定的，卡越慢，能猜的 token 越少，1650 Ti 只能猜 1 个，3050 猜 2 个，L4 才敢猜 3 个。

---

核心结论

1. 单用户场景下，24GB 显存的 NVIDIA L4NVIDIA的GPU型号，用于加速机器学习推理。 仅比 8GB 的 RTX 3050 快 1.2 到 1.3 倍，因为 4-bit 量化的 Gemma 4 E2B 仅占用 3.9GB、E4B 仅占用 6.7GB 显存，单用户生成瓶颈在显存带宽而非容量。

2. 草稿模型的最佳推测长度由显卡性能决定而非模型本身：GTX 1650 Ti 只能猜 1 个 token，RTX 3050 猜 2 个，L4 才能猜 3 个；L4 上验证 3 个猜测几乎免费，而慢卡每次猜测开销更大。

3. 64 并发请求时 L4 的总输出吞吐是 RTX 3050 的 1.61 到 1.65 倍（E2B 达 918.9 tok/s，E4B 达 778.1 tok/s），这才是 24GB 大显存真正体现价值的地方。

4. 草稿模型不改变答案质量：GSM8KGrade School Math 8K benchmark for evaluating mathematical reasoning capabilities of language models. 和 BFCLBerkeley 函数调用基准（Berkeley Function Calling Leaderboard），用于评估模型调用工具/函数的能力。 基准上带与不带草稿模型的逐题配对差异 95% 区间均包含零，同一套 GGUF 文件在三张卡上答案一致。

5. 成本上单用户用 L4 spot 实例每百万输出 token 约

这篇文章最有意思的点是：24GB 的 L4 在单用户场景下只比 8GB 的桌面卡快 1.2 到 1.3 倍，模型只占了显存的零头，剩下的全在空转。真正拉开差距的是并发，64 个请求同时打进来，L4 才把 3050 甩开 1.6 倍。如果你只关心一件事，看这个：草稿模型的最佳长度不是固定的，卡越慢，能猜的 token 越少，1650 Ti 只能猜 1 个，3050 猜 2 个，L4 才敢猜 3 个。

---

.07 到

这篇文章最有意思的点是：24GB 的 L4 在单用户场景下只比 8GB 的桌面卡快 1.2 到 1.3 倍，模型只占了显存的零头，剩下的全在空转。真正拉开差距的是并发，64 个请求同时打进来，L4 才把 3050 甩开 1.6 倍。如果你只关心一件事，看这个：草稿模型的最佳长度不是固定的，卡越慢，能猜的 token 越少，1650 Ti 只能猜 1 个，3050 猜 2 个，L4 才敢猜 3 个。

---

.80，而塞满 64 并发后降至 $0.25 到 $0.30，相差六到七倍；E4B 加草稿模型在 L4 上速度达 E2B 裸跑的 0.97 倍，且 GSM8K 准确率高约 3 个百分点。

先说结论：单用户别急着上云

我跑完这一轮数据，最直接的感受是：如果你就一个人用 Gemma 4 的 E2B 或 E4B，本地那张 8GB 的 RTX 3050 完全够用。它跑出了 L4 的 69% 到 81% 的速度，答案一模一样，模型文件也是同一套。

L4 是 AWS 的 g6.2xlarge 实例，24GB 显存。听起来很猛，但 4-bit 的 E2B 只用了 3.9GB，E4B 也就 6.7GB。剩下的二十来 GB 全闲着。你付的是整张卡的钱，用的是一小半。

这就是我踩过的坑：以为显存大就一定快。单用户生成的时候，每个 token 都要把模型权重读一遍，瓶颈是显存带宽，不是容量。只要模型塞得下，容量再大也不加分。

---

测试环境长什么样

三张卡，同一套 llama.cpp一个高效的C++库，专门用于在本地硬件上运行大型语言模型推理，支持多种硬件加速和优化技术。 构建（77c4540ce），同一批 GGUF 文件，同一个草稿模型，同一组测试脚本。

• GTX 1650 Ti Max-QNVIDIA 的笔记本显卡，拥有 4GB 显存，功耗较低，适合轻薄本。，4GB，笔记本
• RTX 3050 OEMNVIDIA 的入门级桌面显卡，拥有 8GB 显存，常用于轻度游戏和本地 AI 推理。，8GB，i7-5820K 台式机
• NVIDIA L4，24GB，EC2 g6.2xlarge，8 vCPU，us-east-1 的 spot 实例

模型是 Google 的 QAT 量化版，Q4_0 精确 GGUF，每个块都落在 QAT 网格上。草稿模型也是配套的 QAT assistant 版本。

L4 那台机器用的是 PyTorch Deep Learning AMI，驱动有，但没装 CUDA 编译器。make toolkit 从 NVIDIA 的 apt 源装了 CUDA 13.1，比驱动支持的版本低一个小版本。编译 llama.cpp 花了 633 秒，目标架构 sm_89。

服务启动命令长这样，E2B 为例：

llama-server -m gemma-4-E2B-it-q4_0-exact.gguf -ngl 99 -c 131072 -ctk f16 -ctv f16 -fa 1 \
  -t 4 -tb 8 --parallel 1 --reasoning off --metrics -ot 'per_layer_token_embd\.weight=CUDA0' \
  -md gemma-4-E2B-it-qat-assistant-q4_0-exact.gguf --spec-type draft-mtp -ngld all --spec-draft-n-max 2

满上下文 131072 token 加草稿模型，E2B 峰值 3952 MiB，E4B 峰值 6774 MiB。L4 总共 23034 MiB 可用。

---

单用户速度：L4 的优势没你想的大

测速脚本发六种提示词：代码、聊天、故事、解释、事实、摘要。每种 256 token，贪心解码，每个提示词重复三次，关掉提示词缓存，最后取几何平均。每个配置单独起一个服务，卡冷却后再跑。

L4 上的数据：

代码类提示词从草稿模型里获益最多，E2B 到了 2.39 倍，E4B 到了 2.55 倍（3 token 设置）。故事类最少，只有 1.31 倍和 1.38 倍。

有个数字值得单独拎出来：E4B 带草稿模型跑 129.7 tok/s，E2B 不带草稿跑 133.4 tok/s。前者是后者的 0.972 倍。也就是说，E4B 加草稿模型，速度几乎追平 E2B 裸跑，但答案质量更高。

三张卡各自的最佳设置：

---

草稿长度是卡决定的，不是模型决定的

这一点我一开始没想明白。草稿模型的猜测被接受的概率在三张卡上是一样的，变的是每次猜测的成本。

把每次回复拆成步来看，一步就是主模型对最后一个 token 加上草稿 token 做一次前向。E2B 的数据：

加速比等于每步 token 数除以步时间。L4 上 llama-bench 测了主模型一次处理 1 到 6 个 token 的时间：4 个 token 最多是 1 个 token 的 1.04 倍，在 0、8192、32768 上下文下都成立。所以在 L4 上验证 3 个猜测几乎免费，多出来的时间全是草稿模型自己的开销，每次猜测 0.75 到 1.18 毫秒。

这个开销占 E2B 一步的 33%，占 E4B 更长一步的 19%。E4B 从草稿模型获益更多，原因就在这。慢卡每次猜测付得更多，所以最佳草稿长度更短。

---

长对话：草稿模型一直有用

长上下文测试把一篇长文档的前 D 个 token 放在故事、代码、摘要请求前面，上下文开到 131072。2 个草稿 token 下的平均加速比：

不带草稿的生成速度随上下文变长而下降。L4 上 E2B 写故事，空上下文 134.1 tok/s，前置 12 万 token 时掉到 66.7 tok/s。草稿模型在两张卡上、各个深度都还在起作用。

---

多用户并发：L4 的显存终于派上用场

并发测试一次发 c 个请求，每个请求是六种聊天提示词之一，256 token，重复五次，共享上下文缓存，-c 32768 --parallel 64。总输出 tok/s：

64 并发时 L4 是 3050 的 1.61 到 1.65 倍。这才是 24GB 显存真正值钱的地方。

草稿模型（2 token）在 L4 上到 16 并发还有用，E2B 是 1.06 到 1.19 倍，E4B 是 1.15 到 1.34 倍。到 64 并发就亏了，两个模型都是 0.87 倍。并发太高的时候，草稿模型抢的资源不如留给主模型。

---

答案质量：同一套文件，同一套答案

GSM8K 有 1319 道小学数学题，每题最多 2048 token 回复。BFCL simple 有 400 个单函数调用。上下文 32768，8 并发，对比带不带草稿模型（2 token）：

逐题配对比较，草稿模型对答案的所有差异，95% 区间都包含零。3050 上同样设置跑出来 E2B 是 0.8984 / 0.9022，E4B 是 0.9340 / 0.9325。同一套模型文件，在哪张卡上答案都一样。

E4B 的 GSM8K 比 E2B 高。不带草稿高 0.0318（区间 +0.0167 到 +0.0470），带草稿高 0.0303。BFCL 两者打平。E4B 带草稿跑完 GSM8K 用 893 秒，比 E2B 不带草稿的 1014 秒还快。

---

成本：一个人用云卡是烧钱

L4 实例 g6.2xlarge 在 us-east-1，跑测试那天按需 $0.9776/小时，spot $0.8393/小时。一台机器跑满，每百万输出 token 的成本：

单用户付整张卡的钱，用 13% 到 29% 的显存。塞满 64 个请求，同样的卡每 token 成本降到六分之一到七分之一。本地卡的成本是卡钱加电费，这两项我没测。

---

大卡什么时候才值

8GB 的 3050 也能跑更大的 Gemma 4，代价是模型超出显存后速度暴跌。同一系列在同一张卡上的数据：

这三个模型 24GB 卡都能整个装下。这篇文章只在 3050 上测了它们。

---

三张卡摆一起

---

怎么选

单用户跑 E2B 或 E4B，本地 8GB 卡。它给出 L4 的 69% 到 81% 速度，答案一样，模型只占卡的一小部分。

多用户并发，L4。64 请求时输出是 3050 的 1.6 倍，spot 上每百万 token 两三毛钱。

要质量又要小模型速度，E4B 加草稿模型。L4 上生成速度是 E2B 裸跑的 0.97 倍，GSM8K 高 3 个点。

要跑 26B 和 31B，换张装得下的卡。8GB 上它们溢出到内存，掉到 34 和 4 tok/s。

---

范围说明

只测了 Gemma 4 E2B-it 和 E4B-it 的 QAT 版，精确 Q4_0 GGUF 文件和精确 Q4_0 QAT 草稿模型，纯文本，三张卡都是 llama.cpp 77c4540ce，16 位上下文缓存，关闭思考。L4 是一天的单台实例（spot g6.2xlarge，us-east-1d）。3050（i7-5820K 台式机）和 1650 Ti（笔记本）的数据来自 2026 年 10 月 14 日和 15 日，不同主机，同样的提示词和脚本，跨卡比值仅供参考。多用户测试用的是短聊天提示词和共享上下文缓存。更大的云 GPU 和 L4 上的 12B、26B、31B 没跑。

用 MCP 做本地加速卡对比这套方法，是一步一步增量验证出来的。

常见问题（FAQ）

单用户部署 Gemma 4，用 AWS L4 还是本地 RTX 3050？

单用户别急着上云。8GB RTX 3050 能跑到 L4 的 69%–81% 速度，答案完全一致，模型文件也相同。L4 的 24GB 显存在单用户下大部分空转，瓶颈是显存带宽而非容量。

草稿模型（drafter）的草稿长度该设多少？

草稿长度由显卡决定，不是模型决定。卡越慢，能猜的 token 越少：GTX 1650 Ti 最佳 1 个，RTX 3050 为 2 个，L4 才敢用 3 个。慢卡每次猜测开销更大，猜多了反而拖慢。

L4 的 24GB 显存什么时候才真正有用？

在高并发场景。64 个请求同时进来时，L4 总吞吐是 RTX 3050 的 1.61–1.65 倍，这才是大显存的价值。但并发到 64 时草稿模型反而亏，两个模型都只有 0.87 倍，资源应留给主模型。