2015 年旧 PC 运行 Gemma 4 可行性测评

Gemma 4 挑战：撰写 Gemma 4 参赛文章

这是 Gemma 4 挑战赛「撰写 Gemma 4 相关文章」赛道的参赛作品。

在老旧硬件上本地运行现代 AI 模型，听起来几乎不可能。但随着 Gemma 4 这类小型模型以及 Ollama 等工具的出现，即使是在日渐老化的机器上，本地 AI 也开始变得出乎意料地易于使用。

我还保留着那台 2015 年购买的老式台式电脑。它的性能依然足以用于开发，甚至还能运行一些我最喜欢的游戏。如今，它感觉就像家庭中的一员（事实上，它比我最大的孩子年龄还大）。

它唯一始终无法真正胜任的事情，就是在本地运行 AI 模型。但现在的模型似乎对老旧 CPU、GPU 和有限内存友好了许多，因此我终于决定用 Gemma 4 试一试。

我想围绕 Gemma 4 创作一个完整的系列。首先，我会探索如何在老旧硬件上本地运行 Gemma 4，并对其进行基准测试，看看它是否真的可用，以及哪种模型变体最适合我的具体配置。之后，我想构建一个真正有用的应用，让 Gemma 4 成为应用的核心。

选择合适的 Gemma 4 变体 Gemma 4 基础知识

Gemma 4 基础知识

安装并运行 Gemma 4

基准测试 速度基准测试 推理基准测试 知识基准测试 代码生成 结构化输出（JSON）指令遵循 系统指标

结构化输出（JSON）

指令遵循

选择合适的 Gemma 4 变体

在选择合适的变体之前，先来看看我的旧电脑配置：

这说明了什么？

我们应该保持现实，把注意力放在较小的模型上。根据网上的一些建议：

Gemma 4 内存要求

凭借 24 GB 内存和 i5-6400 CPU，我应该能够相当轻松地运行 E2B 和 E4B。26B 模型很可能已经超出了这套系统实际能够承受的范围，而 31B 变体对于这套配置来说更是遥不可及。

Gemma 4 基础知识

如果你想知道 E2B 或 E4B 之类的术语是什么意思：

“B”代表数十亿参数，用于描述模型的规模。

“E”代表有效参数。

这些模型专为边缘设备和本地部署而设计，也就是说，它们经过优化，可以在消费级硬件上高效运行。

简单来说，参数是模型在训练过程中学习到的内部数值。它们代表数据中的模式，模型会利用这些模式生成回答。

你可以把参数理解为模型学习和泛化模式的能力，而不是模型所存储的事实性知识。

2B → 约 20 亿个参数

4B → 约 40 亿个参数

26B → 约 260 亿个参数

安装并运行 Gemma 4

首先，我们需要下载 Ollama，它将充当本地的“AI 服务器”。Ollama 负责模型下载、硬件优化和模型管理，因此我们真正需要关注的只有提示词。

它可能是弥合“拥有一台电脑”和“拥有一个私有的本地 ChatGPT”之间差距的最简单方式。

安装 Ollama 后，可以运行以下命令来下载并启动两个 Gemma 4 模型：

ollama run gemma4:e2b
ollama run gemma4:e4b

E2B 安装完成：

ollama run gemma4:e2b
pulling manifest
pulling 4e30e2665218: 100% ▕██████████████████████████████████████████████████████████▏ 7.2 GB
pulling 7339fa418c9a: 100% ▕██████████████████████████████████████████████████████████▏  11 KB
pulling 56380ca2ab89: 100% ▕██████████████████████████████████████████████████████████▏   42 B
pulling c6bc3775a3fa: 100% ▕██████████████████████████████████████████████████████████▏  473 B
verifying sha256 digest
writing manifest
success

E4B 安装完成：

PS C:\Users\dbalc> ollama run gemma4:e4b
pulling manifest
pulling 4c27e0f5b5ad: 100% ▕██████████████████████████████████████████████████████████▏ 9.6 GB
pulling 7339fa418c9a: 100% ▕██████████████████████████████████████████████████████████▏  11 KB
pulling 56380ca2ab89: 100% ▕██████████████████████████████████████████████████████████▏   42 B
pulling f0988ff50a24: 100% ▕██████████████████████████████████████████████████████████▏  473 B
verifying sha256 digest
writing manifest
success

总计需要为 Ollama 本身预留约 6.5 GB 的空间，此外还需要额外的 7.2 GB 或 9.6 GB，具体取决于你安装的模型。

模型下载完成后，就可以立即在终端中开始对话：

>>> Send a message (/? for help)

下次运行：

ollama run gemma4:e2b

ollama run gemma4:e4b

Ollama 会直接加载已经下载好的模型，你可以立即开始对话。

注意：Ollama 还允许你直接在 VS Code Copilot Chat 中使用本地模型。只需运行：

ollama launch vscode

plaintext 然后在 VS Code 中选择你的本地模型。更多详情：Ollama VS Code Integration

我想对这些模型进行基准测试，了解它们在我的旧电脑上处理不同类别的提示词时，实际会消耗多少 CPU、内存和 GPU 资源。我还想比较这两个模型的回答质量和生成速度。

为了避免混杂不相关的指标，我将评估拆分为多个聚焦于不同方面的基准测试类别。

每张基准测试表都用于衡量模型行为的某一个特定方面，而不是试图一次评估所有内容。

这一点很重要，因为 AI 模型的不同方面表现差异很大：

性能（每秒 token 数，TPS）反映模型生成文本的速度。

推理质量反映模型解决问题和遵循逻辑的能力。

结构化输出的可靠性反映模型遵循 JSON 等严格格式的一致性。

将这些指标合并到同一个基准测试中会产生误导性的结果。例如，一个 JSON 任务可能仅仅因为输出较长而显得“较慢”，并不代表模型实际上更慢。

因此，每张表都使用经过精心设计、与待测指标相匹配的提示词：

速度测试使用相似且可比较的提示词，以公平衡量 token 生成吞吐量（每秒 token 数）。

推理测试使用多步骤逻辑和问题解决任务来评估正确性与推理质量，而不是速度。

结构化输出测试会强制执行严格的 JSON 格式规则，以衡量模型遵循 schema 的能力和输出可靠性。

代码生成测试会在实际的 C# 和 .NET 场景中评估代码的正确性、可编译性和代码结构。

知识测试评估模型对事实的回忆能力，以及对地理或通用领域知识的基本理解。

指令遵循测试衡量模型遵守字数限制和语言限制等明确约束的能力。

每个基准测试部分都包含模型的完整输出，让读者能够独立审查并验证结果。

CPU 和内存使用率等系统指标是在持续运行模型的会话期间测量的，而每次回答对应的指标则是在执行各条提示词时分别记录的。

在每项基准测试开始之前，我都会先向模型发送 4 条提示词进行预热。这样可以确保模型已加载到内存中，使 Ollama 能够在测试期间更加稳定地利用 CPU、内存和 GPU 资源。

所有基准测试均使用 Ollama 0.23.2 版本、默认模型设置，并在 PowerShell 终端中运行。

通过设置详细输出级别，Ollama 可以公开每次推理请求的详细运行时指标：

/set verbose

每条提示词执行完毕后，Ollama 都会输出详细的运行时指标，例如：

total duration:       1m56.4241285s #This represents full request lifecycle latency.
load duration:        1m6.4841917s #This primarily represents model initialization overhead and is most visible during cold starts or after the model has been unloaded from memory.

# This measures input ingestion speed (how quickly the model encodes and understands the prompt before generating output).
prompt eval count:    19 token(s)
prompt eval duration: 912.2499ms
prompt eval rate:     20.83 tokens/s

# This is the model’s output generation speed, measured in tokens per second. It is the primary indicator of inference performance.
eval count:           357 token(s)
eval duration:        48.4355362s
eval rate:            7.37 tokens/s

加载时长表示模型初始化所需的时间，而总时长包含请求的完整生命周期。

提示词评估指标衡量输入处理速度，评估速率则表示 token 生成吞吐量。

在本次基准测试中，评估速率被用作主要的性能指标，其他指标则用于反映系统开销。

为表述清晰，基准测试表对这些指标的名称做了轻微调整：

Prompt Tokens/s = prompt eval rate
Generation Tokens/s = eval rate

为了提高结果的一致性，我会针对每个模型将每条提示词运行四次，并计算平均值。

REST API（Representational State Transfer）是一种架构风格，定义了软件组件应该如何通过互联网进行通信的一套规则。它充当标准化接口，允许不同应用程序通过关注由唯一 URL 标识的资源（如用户或产品）来相互交互。客户端和服务器之间的通信通常使用标准 HTTP 方法完成——如 GET（用于检索数据）、POST（用于提交新数据）、PUT（用于更新数据）和 DELETE（用于删除数据）——使通信高效、可扩展且无状态。

Docker 是一个平台，使用容器化技术将应用程序及其所有依赖项打包到称为容器的标准化隔离单元中。这些容器确保应用程序在任何计算环境中都能一致且可预测地运行，解决了环境不兼容的常见问题。这种可移植性使得在开发和生产系统中部署和扩展应用程序变得更加简单高效。

REST API（Representational State Transfer 应用程序编程接口）本质上是一套规则和指南，规定了两个独立的软件如何通过互联网进行通信和数据交换，充当 Web 服务的通用翻译器。REST 不需要复杂的专有方法，而是将所有信息组织成容易识别的"资源"（如用户或产品），通过特定的 URL 寻址。要与这些资源交互，系统使用标准 HTTP 动词：GET 读取数据，POST 创建数据，PUT 更新数据，DELETE 删除数据。因为它依赖这些简单、标准化的方法——并且使用 JSON 或 XML 等格式组织数据——REST 使 Web 高度模块化且可扩展，确保任何客户端应用程序，无论其底层语言如何，都能可靠高效地从任何服务器访问和操纵数据。

Docker 是一个平台，使开发者能够容器化应用程序，将代码、运行时、库和所有依赖项捆绑成一个称为容器的单一可移植单元。这些容器将应用程序打包到一个一致、隔离的环境中，通过确保应用程序在任何底层操作系统上都运行相同的方式，有效解决了"在我的机器上可以工作"的问题。这种可移植性使部署极其可靠高效，使开发者能够快速构建、测试和扩展应用程序，跨越任何机器或云环境。

2B 模型明显更快地完成了两项任务，在 56 秒内完成了 Docker 总结，在 64 秒内完成了 REST API 解释。4B 模型较慢，Docker 总结用时约 65 秒，REST API 解释用时接近 2 分钟（116 秒）。

2B 模型的 REST API 解释和 Docker 总结响应在技术上都是正确的。但对于非技术用户来说，答案可能显得太短，没有额外背景很难完全理解。

4B 模型的响应速度始终较慢，尽管性能差异在不同提示之间变化显著。对于 REST API 解释，用时近乎两倍（116 秒对比 64 秒），而对于 Docker 总结，差异则小得多（65 秒对比 56 秒）。输出令牌生成也滞后，平均约 5 TPS，而 2B 模型约为 6.7 TPS。尽管吞吐量较低，4B 模型为两个主题都生成了更详细、更容易理解的解释。

使用简单逻辑和多步问题求解任务来评估推理性能。在本节中，正确性和推理质量的优先级高于执行速度。

这是一个经典的距离、速度和时间问题。我们需要先找到单程距离，然后加倍得到总行程距离。

### 逐步推理

**1. 定义变量：**
* 设 $D$ 为 A 市和 B 市之间的距离（单位：公里）。
* A 到 B 的速度（$v_1$）：$60 \text{ km/h}$
* B 到 A 的速度（$v_2$）：$90 \text{ km/h}$
* 总时间（$T$）：$5 \text{ 小时}$

**2. 表示每段行程的时间：**
使用公式：$\text{时间} = \frac{\text{距离}}{\text{速度}}$

* **A 到 B 的行程时间（$t_1$）：**
$$t_1 = \frac{D}{60}$$

* **B 到 A 的返程时间（$t_2$）：**
$$t_2 = \frac{D}{90}$$

**3. 建立总时间方程：**
两段行程的时间之和等于总旅行时间：
$$t_1 + t_2 = T$$
$$\frac{D}{60} + \frac{D}{90} = 5$$

**4. 求解 D 的方程：**
为了将左边的分数相加，找到 60 和 90 的公分母。60 和 90 的最小公倍数（LCM）是 180。

* 转换分数：
$$\frac{D \times 3}{60 \times 3} + \frac{D \times 2}{90 \times 2} = 5$$
$$\frac{3D}{180} + \frac{2D}{180} = 5$$

* 合并分数：
$$\frac{3D + 2D}{180} = 5$$
$$\frac{5D}{180} = 5$$

* 化简分数 $\frac{5}{180}$：
$$\frac{D}{36} = 5$$

* 求解 $D$：
$$D = 5 \times 36$$
$$D = 180$$

A 市和 B 市之间的单程距离是 $180 \text{ 公里}$。

**5. 计算总行程距离：**
总行程距离是从 A 到 B 的距离加上从 B 到 A 的距离（往返行程）。
$$\text{总距离} = D + D = 2D$$
$$\text{总距离} = 2 \times 180$$
$$\text{总距离} = 360 \text{ 公里}$$

---
### 答案：
总行程距离是 **360 公里**。

这是计算剩余金钱的方法：

### 1. 计算住宿费用
*   **费用：** 每晚 €70
*   **时长：** 3 晚（4 天行程）
*   **计算：** $€70 \times 3 = €210$

### 2. 计算交通费用
*   **费用：** 每天 €15
*   **时长：** 4 天
*   **计算：** $€15 \times 4 = €60$

### 3. 计算食物费用
*   **每天餐次：** 2 顿
*   **每顿费用：** €12
*   **每天食物费用：** $2 \times €12 = €24$
*   **总食物费用（4 天）：** $€24 \times 4 = €96$

### 4. 计算总支出
*   **住宿：** €210
*   **交通：** €60
*   **食物：** €96
*   **总支出：** $€210 + €60 + €96 = €366$

### 5. 计算剩余金钱
*   **初始预算：** €450
*   **总支出：** €366
*   **剩余金钱：** $€450 - €366 = €84$

***

**答案：** 你还剩 **€84** 用于活动和购物。

此问题需要使用关系式 $\text{时间} = \frac{\text{距离}}{\text{速度}}$ 并根据总旅行时间建立方程。

### 第 1 步：定义变量

设 $D$ 为 A 市和 B 市之间的距离（单位：公里）。
*   $R_{\text{去}} $（A 到 B 的速度）：$60 \text{ km/h}$
*   $R_{\text{返}}$（B 到 A 的速度）：$90 \text{ km/h}$
*   $T_{\text{总}}$（总时间）：$5 \text{ 小时}$

### 第 2 步：表示每段行程的时间

计算去程行程（$T_{\text{去}}$）和返程行程（$T_{\text{返}}$）的时间。

$$T_{\text{去}} = \frac{D}{R_{\text{去}}} = \frac{D}{60}$$

$$T_{\text{返}} = \frac{D}{R_{\text{返}}} = \frac{D}{90}$$

### 第 3 步：建立总时间方程

时间之和必须等于 5 小时：
$$T_{\text{去}} + T_{\text{返}} = T_{\text{总}}$$
$$\frac{D}{60} + \frac{D}{90} = 5$$

### 第 4 步：求解单程距离（$D$）

为了合并分数，找到 60 和 90 的最小公倍数（LCM）。
LCM$(60, 90) = 180$。

使用公分母重写方程：
$$\frac{D \cdot 3}{180} + \frac{D \cdot 2}{180} = 5$$

合并各项：
$$\frac{3D + 2D}{180} = 5$$
$$\frac{5D}{180} = 5$$

将分数 $\frac{5D}{180}$ 化简为 $\frac{D}{36}$：
$$\frac{D}{36} = 5$$

两边同乘 36 来求解 $D$：
$$D = 5 \times 36$$
$$D = 180 \text{ 公里}$$

A 市和 B 市之间的单程距离是 180 公里。

### 第 5 步：计算总行程距离

总行程距离是从 A 到 B 的距离加上从 B 到 A 的距离。

$$\text{总距离} = \text{距离}_{A \to B} + \text{距离}_{B \to A}$$
$$\text{总距离} = D + D = 2D$$
$$\text{总距离} = 2 \times 180 \text{ 公里}$$
$$\text{总距离} = 360 \text{ 公里}$$

***

### 答案

总行程距离是 **360 公里**。

（验证：去程时间 = 180/60 = 3 小时。返程时间 = 180/90 = 2 小时。总时间 = 3 + 2 = 5 小时。这与给定信息相符。）

这是计算所有固定支出以确定供自由支配开支用的剩余余额的计算。

### 💰 计算明细

**1. 住宿费用（3 晚）：**
$$€70 \text{ 每晚} \times 3 \text{ 晚} = €210$$

**2. 交通费用（4 天）：**
$$€15 \text{ 每天} \times 4 \text{ 天} = €60$$

**3. 食物费用（每天 2 顿，4 天）：**
$$€12 \text{ 每顿} \times 2 \text{ 顿} \times 4 \text{ 天} = €96$$

**4. 总支出：**
$$\text{住宿} + \text{交通} + \text{食物}$$
$$€210 + €60 + €96 = €366$$

5. 剩余预算（用于活动/购物）： $$\text{总预算} - \text{总支出}$$ $$€450 - €366 = €84$$

---

答案： 您将有 €84 剩余用于活动和购物。

两个模型都正确解决了推理任务，并展示了可靠的多步推理和计算能力。4B 模型通常产生更结构化和精致的解释，特别是在逻辑谜题中，额外的格式设置和最终验证步骤提高了可读性和推理的透明度。

2B 模型虽然不那么冗长，但往往提供更直接、简洁的推理。在旅行预算场景中，它更简洁的分解方式可以说使计算更容易跟随，而不需要不必要的格式化或额外的评论。

总体而言，两个模型在这些基准测试任务中的推理差异相对较小。4B 模型强调呈现、结构和答案验证，而 2B 模型优先考虑简洁性和效率。

此基准测试评估模型如何检索事实信息以及如何在实际旅行相关场景中应用该知识。

旅行规划任务结合了事实地理知识与情境推荐质量，使其比坐标检索任务具有更低的确定性。

捷克共和国布尔诺的近似 GPS 坐标是：

**纬度：** 49.1435° N
**经度：** 16.5035° E

根据您从奥洛穆茨出发，以及约束条件（3 小时车程、适合家庭、5 月 3 天），我建议：

### 目的地建议：奥地利盐湖地区（侧重于萨尔茨堡/哈尔施塔特地区）

### 为什么这个目的地理想：

1.  **车程时间：** 盐湖地区从奥洛穆茨很容易到达，通常需要约 **2.5 到 3 小时** 的车程，完全符合您的出行时间窗口。
2.  **家庭吸引力和活动：** 该地区以其壮观的阿尔卑斯山景色、原始湖泊、迷人的村庄和丰富的历史而闻名。它提供了适合家庭的自然、温和徒步和文化游览的完美组合。
    *   **活动：** 湖上游船、参观著名湖泊如沃夫冈湖、温和徒步，以及探索历史城堡（如萨尔茨堡附近的城堡）。
3.  **5 月时机：** 5 月是访问的绝佳时机。夏季高峰期的人群已经消散，意味着您可以享受美丽的风景和户外活动，人口较少，气温比 7 月中旬或 8 月更易控制。
4.  **3 天行程：** 您可以轻松规划三天来专注于不同的地区：
    *   **第 1 天：** 探索主要城镇（如萨尔茨堡）或湖滨村庄。
    *   **第 2 天：** 专注于风景活动（例如，湖上游船或中等徒步）。
    *   **第 3 天：** 参访独特、如画的地点（如著名的哈尔施塔特地区，虽然稍微远一些，或探索该地区迷人的村庄）。

***

### 替代建议（更近/更容易）：斯洛伐克布拉迪斯拉发

如果您更喜欢稍微更近、更都市化、易于步行的行程，**布拉迪斯拉发** 是一个绝佳选择。

*   **优点：** 车程非常容易（少于 2.5 小时）、迷人的老城、绝佳的河滨步道和多样化的食物选项。
*   **缺点：** 与奥地利选项相比，开阔的阿尔卑斯自然风景较少。

捷克共和国布尔诺（主要城市中心）的近似坐标是：

**纬度：** 49.1919° N
**经度：** 16.6904° E

*（注：坐标可能会根据城市中心内的具体点而略有不同，但这些是
一般城市中心的准确坐标。）*

从奥洛穆茨出发、在 5 月内、保持在 3 小时驾驶半径内的最佳家庭友好目的地是 **波兰克拉科夫** 或周围的小波兰地区。

***

### 为什么克拉科夫是 5 月家庭旅行的理想选择：

**1. 5 月的完美时机和活动：**
5 月是晚春——天气通常温和，鲜花盛开，人群不如高峰期夏季密集。这使得户外探索（漫步、骑行、参观公园）变得理想。

**2. 可控的规模和广泛的吸引力：**
克拉科夫拥有一个出色的、可步行的老城（Stare Miasto），视觉上迷人且家庭易于游览。与庞大的首都城市不同，它的规模足够紧凑，可以在 3 天内彻底探索而不会感到仓促。

**3. 优秀的家庭活动多样化：**
这趟旅程提供了完美的活动组合：

*   **历史探索：** 参观瓦维尔皇家城堡庭园（孩子们可以探索城堡庭院和花园）以及探索精心保存的主广场。
*   **自然和公园：** 这座城市被美丽的公园和绿色空间所环绕，可在长时间观光后让孩子们活动。
*   **一日游：** 您可以轻松规划到附近地点（如 **奥斯维辛**，适合年长儿童的历史课程）的半日游，或探索迷人的小镇 **卡齐米日**（犹太区，拥有独特的市场和氛围）。

**交通说明：** 车程直接，通常需要 2.5 到 3 小时，具体取决于交通状况和边境检查。

在地理知识任务中，两个模型都返回了布尔诺的近似坐标，而不是精确的城市中心值。2B 模型生成的坐标明显偏离中心布尔诺，而 4B 模型返回了更准确的、更接近城市中心的位置。

旅行规划任务揭示了约束处理中更大的局限性。2B 模型建议了萨尔茨堡地区，这大幅超过了请求的 3 小时车程限制。但它对布拉迪斯拉发的替代建议更好地符合车程约束，并且对家庭导向的旅行仍然相关。

4B 模型建议了克拉科夫，更接近请求的车程限制，但仍然稍微超过，大约为 3.5 小时的车程。尽管车程估计不准确，两个模型都为其建议的目的地生成了通常相关且适合家庭的活动建议。

总体而言，4B 模型展示了更好的事实精确性和更强的约束感知能力，尽管