在无法联网的 10 小时航班上运行本地大模型进行工程开发，听起来像是一次极端测试，实则是对离线推理能力的一次真实检验。Dmitri Lerko 在今年 4 月从伦敦飞往拉斯维加斯的航班上完成了这项实验，MacBook Pro M5 Max 搭载 Gemma 4 31B 与 Qwen 4.6 36B，通过 LM Studio 运行，配合自研的 powermonitor 与 lmstats 工具进行监控。整个过程处理了约 400 万 Token，涵盖代码重构、CLI 脚手架生成、文档编写等任务，最终产出了一个完整的账单分析工具。这篇文章不探讨模型本身的评测，而是聚焦于一个更务实的问题：在电池、散热、供电线缆等物理约束下，如何让本地推理持续运行 10 小时。
硬件平台与功耗基线
本次实验使用的设备是 MacBook Pro M5 Max，配备 128GB 统一内存与 40 核 GPU。运行 Gemma 4 31B 与 Qwen 4.6 36B 时，整机功耗呈现出一个清晰的区间：平均 81.6 瓦，波动范围在 47.5 瓦至 87.3 瓦之间。最关键的数字是电池消耗率 —— 在持续负载下约为每分钟 1%。这意味着即便全程连接电源适配器，电池仍会持续消耗，航班提供的 70 瓦供电无法满足满载运行的需求。
这里出现了一个容易被忽视的变量：线缆。实验中使用了两种线缆连接电源适配器与 MacBook，iPhone 充电线仅能传输 60 瓦，而 MacBook 原装线缆可传输 94 瓦，两者相差 34 瓦，幅度达 36%。英国航空宣传的 70 瓦供电与实测 60 瓦之间的落差，正是线缆导致的瓶颈。换上 MacBook 线缆后，供电能力提升至 94 瓦，为后续优化提供了更大的操作空间。
模型选择与量化策略
在离线场景下，模型大小直接决定了显存占用与推理功耗。Gemma 4 31B 与 Qwen 4.6 36B 是两个相对平衡的选择：参数量足够大以保证输出质量，同时在量化后能够在 M5 Max 的统一内存中完整加载。实际使用中，这两个模型在狭窄作用域的编码任务上表现与前沿云端模型相当，包括代码重构、CLI 脚手架生成、小型工具编写等。
上下文长度是一个硬性约束。当上下文窗口超过 100 个 Token 后，吞吐量与延迟开始出现可感知的下降。这对工程实践的启示是：需要将大任务拆解为多个小任务，每个任务的上下文控制在合理范围内，避免一次性喂入大量历史代码。实验中的最佳实践是单次会话只处理一个问题，将长篇计划写入 Markdown 文件后再逐步喂入，避免模型陷入上下文膨胀导致的性能泥潭。
热管理与舒适度平衡
70 至 80 瓦的持续功耗意味着设备会产生大量热量。在地面环境中这通常不构成问题，但航班场景有其特殊性：座椅空间狭窄，空气流通受限。更关键的是，实验者使用了机上毛毯与枕头支撑膝盖部位进行操作，这反而加剧了散热问题 —— 机身温度高到让人不适。
这是离线部署中容易被低估的因素。即便技术指标上电池续航足够，热管理的失败仍可能导致任务中断。实用建议包括：避免将设备放置在隔热材质上，保持出风口通畅；在高温环境下降低模型量化精度以换取更低功耗；必要时接受间歇运行而非持续满载。
监控工具与参数仪表盘
实验过程中开发的两款工具揭示了工程化部署的核心原则：先测量，再优化。powermonitor 读取 Mac 电源遥测数据，实时显示 CPU、GPU、ANE（Apple Neural Engine）、适配器与电池的功耗分布。在持续推理负载下，GPU 占据绝对大头，通常在 77 瓦左右，而 CPU 仅 4.5 瓦。这种功耗结构表明，优化重点应放在 GPU 负载管理与统一内存带宽上。
lmstats 则追踪 LM Studio 的推理指标，包括 Token 吞吐量、延迟分布与上下文窗口行为。两者结合，形成了完整的资源消耗画像。没有这些仪表盘，开发者只能凭感觉调整参数，难以定位线缆选择这种看似微小却影响巨大的瓶颈。
场景边界与工程启示
10 小时的实验验证了本地离线推理的可行边界。本地模型适合的场景包括：狭窄作用域的编码任务、探索性工具构建、不值得调用云端 API 的轻量级需求。而需要大上下文推理、需要前沿智能体的复杂工作流、高价值任务仍应留在云端。
更深层的启示在于 “推断成本的具象化”。当开发者直接在终端看到每瓦功耗、每次 Token 生成的物理代价时，会自然地形成对提示词大小、工具调用频率、上下文管理的自律。这种自律会迁移到云端使用场景 —— 毕竟无论本地还是云端，推理都是有成本的。
未来可以探索的方向包括：利用 Apple Neural Engine 运行更小更高效的模型，在功耗与智能之间寻找新的平衡点；针对航班等特定场景预置模型与工具链镜像，将冷启动时间压缩至最低。