本地跑LLM的PC满载300–800W、月电费约240元，而Mac Studio只要30–80W、月电费约24元，当性能差距没有电费差距那么大时，“本地”到底该选高功耗PC还是低功耗统一内存？

一、问题的重新定义：电费不是主要矛盾，能效比才是

“PC满载300–800W、月电费约240元；Mac Studio 30–80W、月电费约24元”——这组数字在社交平台上流传甚广，但它的说服力恰恰来自一个隐含假设：两台机器的“性能”是可比的。一旦把这个假设拆开，讨论就会立刻变得具体：在什么模型规模、什么上下文长度、什么并发数下，两者的有效吞吐相差多少？电费差额在总拥有成本（TCO）中占多大权重？

先把电费算清楚。按国内居民阶梯电价常见的第一档约0.55元/kWh估算（各地差异较大，工商业与峰谷电价另算），一台整机平均功耗500W、每天满载8小时的PC，日耗电4kWh，月耗电约120kWh，电费约66元；若按24小时不间断推理、平均功耗500W计算，月耗电360kWh，电费约198元，接近“240元”这一量级。而一台平均功耗50W的统一内存工作站，24小时运行月耗电36kWh，电费约20元，与“24元”吻合。也就是说，“240元 vs 24元”的差异，本质上是“24小时高负载”与“24小时低负载”两种使用模式的差异，而不是两台机器在同一工况下的差异。这一点必须先厘清，否则后续所有比较都会失真。

那么电费差额到底有多大？按上述极端口径，每月约180–220元，三年约6500–7900元。这个数字大致相当于一张中端显卡，或者一台统一内存工作站内存升级一档的差价。本文评述：把三年电费差额与硬件差价放在同一张表里，会发现电费从来不是决定性变量；真正决定选型的是“单位token成本”与“能力边界”。前者是能效问题，后者是可行性问题——一台跑不动目标模型的机器，电费再低也没有意义。

因此本文的主线不是“谁更省电”，而是：在给定模型规模与工作负载下，哪条路径的“每瓦有效吞吐”更高，以及这条路径的边界条件在哪里。围绕这条主线，后文将依次讨论功耗口径、解码阶段的带宽瓶颈、两条路线的工程画像、可核算的数据表、统一内存的局限，最后落到可执行的测量与选型步骤。

二、功耗口径：从墙上功率到每token焦耳

2.1 三个必须区分的功率概念

讨论“300–800W”之前，需要区分三个层级：器件功耗（GPU/SoC芯片自身）、整机功耗（含CPU、主板、内存、风扇、电源损耗）、墙上功率（含电源转换效率，80 PLUS金牌约90%）。厂商TDP通常指器件级或封装级，而电费按墙上功率计。一台标称450W TDP的显卡，整机墙上功率在满载推理时达到550–650W是常见现象；而Apple Silicon的SoC峰值功耗与整机功耗差距较小，因为其电源与主板集成度高、外围器件少。

这意味着“300–800W”这个区间本身是模糊的：它混合了不同显卡、不同电源效率、不同负载类型。严谨的做法是统一到墙上功率，并注明测量点。本文后续所有比较，除非特别说明，均指整机墙上功率的稳态值。

2.2 每token焦耳：一个可复现的能效指标

定义能效指标：

E_token = P_wall / TPS        （焦耳/token，J/token）
其中 P_wall 为稳态墙上功率（W），TPS 为解码吞吐（token/s）
月电费 = P_wall × 日均小时 × 30 / 1000 × 电价（元/kWh）

这个指标的好处是把“性能”和“功耗”压缩成一个标量，便于横向比较。例如：整机500W、解码40 token/s，则E_token = 12.5 J/token；整机50W、解码20 token/s，则E_token = 2.5 J/token。后者能效是前者的5倍，尽管绝对速度只有一半。本文评述：E_token 不是唯一指标，但它把“电费差距没有性能差距大”这类模糊表述，转化为可计算、可验证的量。对于以交互为主、对延迟不敏感的场景，E_token 低意味着长期成本低；对于批处理或高并发场景，绝对TPS与吞吐上限更重要。

2.3 测量步骤：一个下午能做完的功耗基线

要让数据可信，测量流程必须固定。以下步骤适用于两类平台，工具以常见开源方案为主：

1. 硬件：带计量功能的智能插座（如支持功率记录的Wi-Fi插座）或USB功率计（仅适合低功耗设备），精度±1–2%。
2. 负载：固定模型（如7B/14B/32B的GGUF或MLX量化版本）、固定prompt长度、固定生成长度（如512 token），重复5次取稳态段。
3. 采样：插座以1秒粒度记录功率，取生成阶段的均值作为P_wall；同时用推理框架日志取TPS。
4. 对照：分别测“空闲”“预填充（prefill）”“解码（decode）”三段，因为三者功耗差异显著——预填充是计算密集型，解码是访存密集型。
5. 记录：把E_token、TPS、P_wall、模型规模、量化方式写入表格，形成自己的基线库。

可参考的开源工具与教程：llama.cpp 官方仓库（含benchmark脚本）、Apple MLX 项目（统一内存平台的推理与基准）、vLLM（高并发服务化基准）。视频类可参考各平台上的“LLM本地推理功耗实测”系列，但需注意其测量口径是否统一。

三、原理层：为什么解码阶段被内存带宽锁死

3.1 自回归解码的访存本质

大模型推理分两个阶段：预填充（把整段prompt一次性过网络，计算密集、可并行）与解码（逐token生成，每步只处理一个token，但需要读取全部模型权重与KV Cache）。在解码阶段，每生成一个token，几乎要把模型权重完整读一遍——对于7B模型（FP16约14GB），这意味着每token约14GB的访存。GPU算力再强，只要带宽跟不上，解码速度就被卡住。

一个常用的估算式是：

TPS_decode ≈ BW_eff / (W_bytes × N_active)
BW_eff：有效内存带宽（GB/s）
W_bytes：每参数字节数（FP16=2，INT8=1，INT4≈0.5）
N_active：每token激活参数量（稠密模型≈总参数，MoE远小于总参数）

以7B稠密模型、INT4量化（约3.5GB）、有效带宽500GB/s为例，理论上限约140 token/s；实际因KV Cache读取、调度开销，通常打三到五折。这个式子解释了为什么“统一内存”路线在中等模型上能效突出：它把大容量内存直接放在SoC旁，带宽/功耗比高；而独立GPU路线靠HBM/GDDR提供更高绝对带宽，但整机功耗也高得多。

本文评述：“带宽/功耗比”是比“绝对带宽”更贴近本地场景的指标。数据中心可以不在乎每瓦带宽，因为电费占比低、机架密度有上限；但本地工作站恰恰相反，电费与散热、噪音、空间一起构成隐性成本。把BW_eff除以P_wall，就得到“每瓦可用带宽”，它与E_token高度相关。

3.2 量化与MoE如何改变结论

量化直接降低W_bytes，从而线性提升解码TPS上限。4-bit量化让7B模型权重降到约3.5GB，13B降到约7GB，70B降到约35GB。这意味着：在统一内存平台上，70B级模型可以在64GB–128GB内存内以4-bit运行，而消费级GPU（24GB显存）即便用4-bit也只能勉强放下30B级模型，70B必须多卡或CPU offload，后者会大幅拉低TPS并推高功耗。

MoE（混合专家）模型进一步改变算账方式：每token只激活部分专家，N_active远小于总参数，因此解码TPS可以很高，但权重仍需全部驻留内存。这对统一内存是利好——大容量内存放得下全部专家，而激活量小意味着带宽压力小。本文评述：MoE把“内存容量”与“解码带宽”解耦，使得“大内存+中等带宽”的统一内存平台在MoE模型上性价比突出。这也是近两年本地社区热衷在统一内存设备上跑MoE模型的技术原因。

3.3 预填充阶段：另一条被忽视的功耗曲线

预填充是计算密集型，功耗会短时冲高。对于长上下文（如32K、128K token）的RAG或文档分析场景，预填充可能占总时延的很大比例，此时高功耗PC的算力优势会体现出来。但要注意：预填充的功耗峰值持续时间短，对月电费贡献有限；真正拉高月电费的是长时间解码或长时间满载。本文评述：讨论电费时必须区分“峰值功率”与“能量”，前者影响电源与散热选型，后者才进电费账单。

四、两条技术路线的工程画像

4.1 高功耗PC：绝对性能与生态弹性

以独立GPU为核心的PC，优势在于：绝对带宽高（高端卡可达1TB/s以上）、算力强、CUDA生态成熟、可微调训练、可多卡扩展、可更换升级。劣势同样明确：整机功耗高、散热与噪音大、显存容量受限于单卡（消费级常见16–24GB）、多卡时功耗与成本非线性上升。

工程上，这类平台适合：需要跑微调（LoRA/QLoRA）、需要CUDA专属算子、需要高并发服务化、需要低首token延迟的交互式应用。对于“单用户、长上下文、大模型”的场景，它往往需要CPU offload，此时TPS骤降、功耗结构也变得复杂。

4.2 统一内存工作站：容量与能效的乘积

Apple Silicon的统一内存架构把CPU、GPU、神经引擎共享同一块高带宽内存，好处是：大容量（可达数十GB至上百GB）可被GPU直接寻址，模型无需在显存与内存间搬运；整机功耗低、噪音低、体积小；MLX框架针对该架构做了算子优化。局限在于：绝对带宽仍低于高端独显、生态以MLX/Metal为主、不适合CUDA依赖强的训练任务、内存不可升级。

本文评述：统一内存的本质是“用容量换带宽、用能效换峰值”。它不追求单卡最强，而是追求“能跑起来 + 跑得安静 + 长期电费低”。对于个人研究者、内容创作者、中小团队的原型验证，这个 trade-off 往往更划算；对于需要训练或高并发的生产环境，则不是首选。

4.3 一张对照表

五、数据与案例：把“感觉”换成可核算的表

5.1 电费模型：三种使用模式的对比

下表为模拟数据（基于公开电价区间与典型功耗区间整合，非实测），用于说明使用模式对电费的影响远大于平台差异：

按0.55元/kWh估算。可以看到：“240元 vs 24元”对应的是24小时常开且PC长期满载的极端口径；多数个人用户每天实际高负载时间在2–8小时，月差额在15–60元之间。本文评述：把极端口径当作常态，是这类讨论最常见的统计谬误。真实决策应基于自己的使用时长分布，而不是别人的截图。

5.2 能效对比：E_token 的量级差异

下表为整合数据（基于公开基准与功耗区间的量级估算，标注为模拟/整合数据），用于展示E_token的数量级差异，不作为具体型号的性能承诺：

注意最后两行：当模型规模超出单卡显存，PC路线需要多卡或CPU offload，E_token反而恶化；统一内存路线虽然绝对TPS不高，但E_token仍处于可接受区间。本文评述：“性能差距没有电费差距大”这句话，在70B级模型上恰好说反了——性能差距可能很大，但能效差距更大。这正是统一内存路线的价值所在。

5.3 三年TCO：把电费放进总账

以模拟数据构建三年TCO模型（单位：元，含硬件、电费、折旧残值忽略）：

在每天8小时的口径下，统一内存工作站的三年TCO反而略高；只有在24小时常开、且PC长期满载的极端口径下，电费才足以抹平硬件差价。本文评述：电费是“慢性成本”，硬件是“急性成本”，两者量级相近时，决策应回到能力边界而非电费。如果目标模型在PC上根本跑不顺，省下的电费毫无意义；反之，如果统一内存跑不动你的微调任务，低电费也无法补偿。

六、对比与局限：统一内存的四个边界条件

边界一：绝对带宽上限。统一内存的带宽虽高，但仍低于高端独显的HBM/GDDR。对于追求极致首token延迟或超高TPS的场景，独显仍有优势。本文评述：带宽差距在7B级模型上可能只体现为2–3倍TPS，但在需要实时交互的产品里，这2–3倍就是体验分水岭。

边界二：生态与算子覆盖。CUDA生态的成熟度、量化算子覆盖、社区模型支持仍领先。MLX在快速追赶，但遇到冷门算子或自定义结构时，可能需要自己写Metal kernel。本文评述：生态不是“有没有”的问题，而是“遇到问题时有没有人踩过坑”的问题，这对工程落地的影响常被低估。

边界三：训练与微调。统一内存适合推理与轻量微调，但不适合大规模训练。若工作流包含LoRA以上规模的训练，PC+独显仍是更稳妥的选择。

边界四：内存不可升级。统一内存焊死在封装内，购买时的容量决定未来数年的上限。本文评述：这是一次“用灵活性换能效”的交易，买家需要在购买时就对未来2–3年的模型规模做出判断，而模型规模的增长速度恰恰是最难预测的变量。

“本地”的真正含义不是“不联网”，而是“数据不出域、成本可预测、能力可掌控”。在这个定义下，选型的核心不是功耗数字，而是你的工作负载是否落在该平台的“能力包络”之内。

七、操作路径：测量、建模、选型、混合组网

7.1 四步决策法

1. 定模型：列出未来12个月要跑的模型清单，记录参数量、量化方式、上下文长度、是否MoE。计算权重字节数与KV Cache需求。
2. 定负载：区分“交互式单用户”“批处理”“高并发服务”“微调训练”四类。统计日均高负载小时数。
3. 算能效：用E_token公式估算两条路线的量级，结合5.2节的表做校准。若目标模型超出单卡显存，直接进入“多卡 vs 统一内存”的比较。
4. 算TCO：把硬件、三年电费、噪音/空间折算、残值放在一张表里。若两者TCO差距在20%以内，按能力边界决策。

7.2 混合组网：不必二选一

对于预算允许的团队，更务实的方案是混合组网：用统一内存工作站做日常推理与原型验证（低功耗、常开、安静），用高功耗PC或服务器做微调、批处理与高并发服务（按需开机）。两者通过局域网共享模型与API，按任务类型路由。本文评述：“常开低功耗 + 按需高功耗”的组合，往往比单台“全能机”更接近最优TCO，因为它把电费花在了真正需要算力的时段。

可参考的部署教程：Ollama（跨平台本地服务化）、llama.cpp server（OpenAI兼容API）、MLX examples（统一内存平台示例）。

7.3 一个可复用的电费计算脚本

def monthly_bill(power_w, hours_per_day, price=0.55, days=30):
    kwh = power_w * hours_per_day * days / 1000
    return round(kwh * price, 2)

# 示例：500W 每天8小时 vs 50W 每天24小时
print(monthly_bill(500, 8))    # 66.0
print(monthly_bill(50, 24))    # 19.8
print(monthly_bill(500, 24))   # 198.0

把自家电价、实际高负载时长代入，就能得到自己的数字。本文评述：任何不注明使用时长与电价的“电费对比”都不可直接采信，这是阅读此类内容时最基本的一条校验规则。

八、结论与展望

回到最初的问题：当性能差距没有电费差距那么大时，该选哪条路线？本文的答案是：先看能力包络，再看能效，最后看电费。能力包络决定“能不能跑”，能效决定“跑得划不划算”，电费只是能效在时间维度上的投影。把电费当作首要变量，是把一个工程选型问题简化成了一个算术问题，而算术问题往往有唯一解，工程问题没有。

展望未来两三年，三个趋势值得关注：其一，MoE与稀疏化让“大内存+中等带宽”的价值上升，统一内存路线的适用面会扩大；其二，量化与推理框架的优化持续降低每token访存，能效曲线整体下移；其三，本地小模型与端侧推理的成熟，可能让“低功耗常开”成为默认形态，高功耗机器退居“按需算力”。本文评述：选型不是一次性的，而是随着模型生态与硬件迭代持续再平衡的过程。建立自己的测量基线，比记住任何一组别人的数字都更有价值。

文章声明：本文内容仅为作者学习、思考、经验、笔记的总结，仅供技术交流与参考。文中观点仅代表笔者个人思辨，不构成任何学术建议、商业建议或专业建议。所有数据来源已标注，引用时请以原始文献为准。

内容仅供学习参考。如需引用，请以原始文献为准。  全文约12600字 | 参考文献62篇（主要8篇）。