How Much Does It Actually Cost to Run a Local LLM? (Euros per Million Tokens, Measured)

在本地运行大型语言模型的实际成本是多少？（每百万个标记的欧元成本，实测数据） | Towards Data Science

大型语言模型

在本地运行大型语言模型的实际成本是多少？（每百万个标记的欧元成本，实测数据）

我在单块RTX 3090显卡上对八个本地模型的实际GPU电力消耗进行了测量——最便宜的模型既不是最小的，最昂贵的模型也不是最大的。

Arsen Apostolov

2026年7月14日

11分钟阅读

分享

特色图片由作者使用Google Gemini生成。

“它运行在我的GPU上，所以基本上是免费的。”我这么说，你也可能这么说过，但这种说法在有人实际测量后就不再成立了。因此我进行了测量。

这个测试环境是“ardi”——一台运行openSUSE系统的机器，配备单块RTX 3090显卡（24 GB）。我在上面运行了受控基准测试：通过ollama服务的三个本地模型，在完全相同的固定工作负载下运行，同时仪表板根据实际GPU能耗对每次运行进行计费。这不是热设计功耗估算，也不是粗略猜测——而是每10秒从nvidia-smi采样一次功率数据，并根据每次运行的实际开始→结束时间窗口进行积分计算，采用我实际的昼夜电价：白天0.30保加利亚列弗/千瓦时，夜晚0.18保加利亚列弗/千瓦时（保加利亚列弗——我的实际电费；全文按固定欧洲央行汇率换算为欧元，1保加利亚列弗≈0.5113欧元）。

每个模型得出一个数字：每百万个输出标记的欧元成本。我测试的八个模型中，有五个的成本低于托管云API。另外三个的成本却更高——而这三个模型并不像仅从参数数量来看那样显而易见。

我想要验证的主张

民间共识认为本地推理是更便宜的选择——你已经购买了GPU，额外生成的每个标记都是免费的，而云服务才是需要计费的。这个观点的每个部分都值得用数据验证，因此我特别关注这个数据：本地生成每个标记的边际能源成本，按模型分别计算，并与托管“Flash”级API为相同标记收取的费用进行对比。

为了将这个主张转化为可测量的数据而非争论，我需要保持三个要素不变：所有模型使用相同的负载、相同的硬件，以及在每次运行期间能准确读取GPU能耗的仪表。第三点在家中实现起来难度较大——这就是仪器的作用所在。

本文所有图片和图表均由作者创作。

方法

我选择了三个模型进行测试，这些模型覆盖了我在设备上实际保留的尺寸范围：gemma3:1b（微型）、gemma4:26b（Google Gemma 4，实际参数为25.8B，ollama标签中四舍五入为“26b”）和gemma3:27b（较旧的大型模型）。所有三个模型都通过ollama加载了Q4_K_M量化后的GGUF权重，因此在量化方面实现了可比性。每个模型都执行相同的固定工作负载——一个包含256个标记生成的循环，通过五个固定提示进行轮换，持续约4分钟（240秒），使GPU达到稳定状态而非基于首次冷启动进行评估。

在每个模型运行期间，我在HomeLab Monitor中将其作为带计费功能的实验进行跟踪——这是我自己开发的开源仪表盘（MIT许可证，单容器部署）。它每10秒从nvidia-smi采样一次GPU功率，并在跟踪运行期间将功率数据在运行的开始→结束时间窗口内积分计算为千瓦时，再乘以当时生效的电价（白天或夜晚）——以我配置的货币单位保加利亚列弗（BGN）进行计算。这将“这个模型的成本是多少？”从猜测转化为可测量的数值；随后我会将其转换为欧元以提高可读性。

然后进行将4分钟运行转换为可比费率的计算：

€ 每百万输出令牌 = (运行成本_BGN × 0.5113) ÷ (输出令牌 / 1,000,000)

下面的三模型生成基准测试可以端到端复现。以下是您在自己的设备上搭建它的方法。

步骤1 - 启动监控（一个容器）

在配备GPU的机器上：

COMPOSE_URL=https://raw.githubusercontent.com/SikamikanikoBG/homelab-monitor/main/docker-compose.yml
curl -fsSLO "$COMPOSE_URL"
docker compose up -d

打开 http://<hub>:9800。它会立即显示运行该服务的主机信息——CPU、内存、磁盘，以及（如果检测到GPU）每个模型的显存使用情况和实时功耗。无需任何配置。这就是计量仪表。在设置中查看它配置的货币和费率，再信任它显示的任何€数值。

步骤2 - 生成摄入密钥

基准测试脚本需要将运行结果推送到中心枢纽，因此需要密钥。进入设置 → 集成 → 创建密钥。该密钥（以hlm_...开头的字符串）仅显示一次——复制后就看不到第二次了。将其保存到环境变量中；不要直接粘贴到脚本中。

export HOMELAB_KEY="hlm_xxxxxxxxxxxxxxxxxxxx"

同一面板还提供了一个下载客户端的链接，用于步骤3中使用的Python文件，以及一个复制粘贴的快速入门指南——因此这个页面已经覆盖了接下来的两个步骤。

步骤3 - 获取轻量客户端

中心枢纽提供自己的Python客户端。它仅依赖标准库——无需任何pip安装：

CLIENT_URL=http://<hub>:9800/static/homelab_run.py
curl -O "$CLIENT_URL"

这个单文件就是完整的跟踪API。其设计刻意保持简洁：只需配置一次，然后用run上下文管理器包裹任何工作块，并在其中记录指标。

import homelab_run as homelab

homelab.configure(url="http://<hub>:9800", key="hlm_...")

with homelab.run("llm-cost-gemma3-1b",
                 params={"model": "gemma3:1b", "engine": "ollama",
                         "gpu": "RTX 3090 24GB", "num_predict": 256}) as r:
    # ...执行工作...
    r.log_metric("tokens_per_sec", tps, step=i)

当with代码块启动时，中心枢纽会标记运行开始；当代码块关闭时，它会标记结束并计算其间GPU消耗的能源成本。这个窗口就是测量范围。

步骤4 - 编写基准测试

工作负载只是在循环中调用ollama的/api/generate接口，读取ollama返回的字段，从而获得真实的每秒令牌数而不是墙钟时间估算值。两个关键字段是eval_count（生成的令牌数）和eval_duration（生成这些令牌消耗的纳秒数）：

import json, time, urllib.request

OLLAMA = "http://localhost:11434"

def ollama_generate(model, prompt):
    body = json.dumps({
        "model": model, "prompt": prompt, "stream": False,
        "options": {"num_predict": 256, "temperature": 0.7},
    }).encode()
    req = urllib.request.Request(OLLAMA + "/api/generate", data=body,
                                 headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=600) as resp:
        return json.loads(resp.read())

然后在固定时间内对每个模型进行负载测试，并用跟踪运行包裹：

def bench(model, duration_s=240):
    ollama_generate(model, "Say hello.")  # warm up - exclude the cold start
    run = homelab.run(f"llm-cost-{model.replace(':', '-')}",
                      params={"model": model, "engine": "ollama",
                              "gpu": "RTX 3090 24GB", "num_predict": 256,
                              "workload": "fixed-prompt-loop"},
                      tags=["llm-cost", "benchmark"])
    tot_out = 0
    t0 = time.time(); step = 0
    with run as r:
        while time.time() - t0 < duration_s:
            res = ollama_generate(model, PROMPTS[step % len(PROMPTS)])
            ec, ed = res.get("eval_count", 0), res.get("eval_duration", 1)  # ed in ns
            tps = ec / (ed / 1e9) if ed else 0.0
            tot_out += ec
            r.log_metric("tokens_per_sec", round(tps, 2), step=step)
            step += 1
        r.log_params({"total_output_tokens": tot_out})
    return run.id, tot_out

在计时窗口之前进行一次预热调用，可以将冷启动延迟排除在测量之外。我在不同模型之间添加的 time.sleep(15)（未显示）可确保每个计费窗口清晰分离，避免一个模型的尾部延迟影响下一个模型的计费。

第5步 - 读取运行结果并计费

为所有三个模型运行脚本并打开实验标签页。现在每个运行都是一行，携带其真实的能耗和成本数据：

点击进入某个运行记录，你可以看到该精确时间窗口的GPU功率曲线，下方有带价格标签的说明——这是欧元数值的原始计算材料：

枢纽也以编程方式公开了每个运行的成本数据，因此最终的换算也可以在脚本中完成：

pulled = homelab.pull(run_id)  # cost, energy_kwh, avg_w, power curve - cost is in BGN
eur_per_mtok = round((pulled["cost"] * 0.5113) / (tot_out / 1e6), 4)

数据结果

我之后又补充了五个模型 - GLM-4.5-Air (106B)、DeepSeek-R1-Distill (32.8B)、Seed-OSS (36B)、Devstral (24B) 和 Qwen3-Coder (30.5B) - 这些模型是从我在同一台机器上已经运行过的独立编码代理基准测试中提取的（相同GPU、相同电价、相同成本÷token方法，但使用真实多步骤代理任务代替专用240秒生成循环 - 在下文注意事项中已标注相关位置）。共八个模型，统一量级：

我对比的云服务参考数据（2026年6月列表价格）：托管的Flash类模型 - Gemini 2.5 Flash、GPT-4o-mini - 每百万输出token约0.60美元（约0.55欧元）；最便宜的层级（Gemini 3.1 Flash-Lite）约为0.40美元。

意外发现

八个模型中有五个比云服务参考价格更便宜。有三个没有更便宜 - 而这三个并非按参数数量挑选的模型。

GLM-4.5-Air 是列表中最大的模型，106B参数，每百万token成本为1.040欧元 - 真正比云API、甚至不计算任何GPU采购成本的电费都要贵。这一部分符合最初的直觉：大模型，速度慢，成本高。

但 DeepSeek-R1-Distill 的规模仅为GLM的三分之一 - 32.8B参数 - 却是整个列表中最昂贵的模型，每百万token成本达1.526欧元。它的功耗甚至比gemma3:27b还低（155W vs 283W） - 但仍是所有测试模型中每token成本最高的。

一个需要提前说明的方法论要点：用于评估的三个 gemma 模型是基于我专门为本文设计的 240 秒持续生成基准测试进行测量的。其余五个模型（包括 DeepSeek-R1-Distill）则来自更早的独立基准测试，该测试在相同 GPU 和计费标准下，使用相同的成本÷输出令牌公式，评估了真实多步骤代码代理任务（工具调用、多轮推理）。这一区别正是 DeepSeek 表现如此的原因：其在主动生成令牌时的原始生成速度为 6.7 个令牌/秒，表现尚可。但计费标准并非依据原始生成速度，而是依据 GPU 卡的墙钟时间。作为推理蒸馏模型，DeepSeek 在生成之间花费了大量时间进行推理，其有效交付率（输出令牌 ÷ 总运行时间，包含推理时间）仅为 3.7 个令牌/秒，是所有测试模型中最低的——远低于 Seed-OSS 的有效 7.1 和 GLM 的 5.0。这才是实际价格所反映的真实情况。

模型规模从来不是决定因素。真正起决定作用的是有效速度，而有效速度通常不是这些模型在基准测试中常用的指标。

决定因素

每个令牌的成本等于瓦特 ÷ 吞吐量。这就是全部公式——关键在于使用正确的吞吐量数值：

gemma3:1b 速度快（136 个令牌/秒）且功耗低（154 W），在两个维度上都很便宜，总体成本最低。Devstral 是所有测试模型中功耗最高的（320 W），但由于其速度仍相对合理，因此排名中等。对于三个专为生成设计的 gemma 模型，原始生成速度决定了价格——瓦特 ÷ 原始令牌/秒几乎能精确重构成本比例。对于五个代理基准模型，决定价格的是有效墙钟吞吐量，而非它们通常被引用的原始生成速度。按此数值计算，Seed-OSS（有效 7.1 个令牌/秒）、GLM-4.5-Air（5.0）和 DeepSeek-R1-Distill（3.7）是测试中速度最慢的三款模型，其成本排名顺序与速度排名完全一致。它们的功耗均属正常（实际功耗为 141–186 W，甚至低于部分更便宜的模型）；只是在计算工具调用和推理间隙后，它们的速度表现较差，而速度慢的模型会为每秒占用 GPU 的时间付费，无论参数数量多少。

我*并未*声称的内容

这部分内容有助于保持诚实，因此我会直截了当地说明边界：

· 这仅涉及 GPU 电力成本——测量值、边际值且数额极小。完整运行成本约等于几分钱。我未测量 CPU 或 DRAM（此主机上 RAPL 无法读取，因此这些数据为空），也明确不计入 GPU 的购买价格、空闲功耗、散热成本或我的时间。€/1M 的数据是边际能源费率，用于判断“哪个模型持续生成更便宜”，而非总拥有成本。

· 本地部署的真实成本是您购买的 GPU，而非电力消耗。3090 显卡只有在高负载且持续使用时才能摊销成本。每天仅运行几分钟的设备主要在支付闲置硅芯片的费用，而任何电力数据都无法反映这一点。边际能源视角对自身范围诚实：它只是成本的下限，而非完整账单。

· 两种测量方法（参见上文“惊喜”部分了解为何重要）。三个Gemma模型：专门的240秒持续生成基准测试。另外五个模型：单独的现实编码代理基准测试，使用相同的成本÷token公式，但衡量的是实际墙钟时间吞吐量而非原始生成速度——这或许更能反映这些模型的实际使用情况，因为真实代理工作负载包含工具调用和深思熟虑，而纯生成循环永远不会涉及这些。

· 一个GPU、一个引擎、量化后的GGUF权重。您的费率、模型、批量大小、量化方式和显卡将影响此处所有数值。表格是针对我的设备；方法才是可迁移的部分。

因此请将绝对欧元数值视为示例性参考，关注趋势才是关键发现：每token成本与有效交付速度呈正相关，这种关系与您预期的参数数量关联方式并不一致。

核心结论

选择通过质量门槛的最小且最快的模型——这才是“本地部署”真正能带来显著成本优势的领域，这与模型大小无关。Qwen3-Coder在305亿参数规模下，每token成本低于Gemma4:26b；而Gemma3:27b在270亿参数规模下，作为普通密集模型（无特殊效率优化），却在推理类模型中表现最佳。真正关键的变量是每墙钟秒交付的token数量——而非模型通常被测试的原始生成速度——要了解您模型和设备的真实表现，唯一方式就是实际测量。

我使用的工具是HomeLab Monitor——开源MIT协议，单容器部署——上述运行定价正是其实验标签默认提供的功能：

添加您的GPU主机、生成密钥后，下一次基准测试将自动计算成本——以您实际配置的货币单位显示（发布数据前务必确认货币设置）。

因此：当您选择本地模型而非API时，您是否真正知道自己的每token成本（以正确货币单位）——还是像我之前一样，只是假设GPU会让成本消失？

撰写人

查看Arsen Apostolov的所有文章

成本优化

,

深度解析

GPU

家庭实验室

大语言模型

分享本文

• Facebook分享

• LinkedIn分享

• X分享

Towards Data Science是社区出版物。提交您的见解以触达全球读者，并通过TDS作者支付计划获得收益。

更新为实际投稿URL

为TDS撰写文章

✦ 结束CTA ✦