退役手机做计算平台：难的从来不是算力，是协调
Google 支持 UC San Diego 用 2000 部退役 Pixel 搭低碳算力集群。容易被讲成废物利用的暖故事，但真正的看点是它替代的是本该被丢弃的蕴含碳，且只对可中断的批处理负载现实。
概述
这件事最容易被讲成一个暖故事：旧手机别扔，攒起来当服务器，既环保又省钱。但暖故事会盖住真正的看点。Google 支持 UC San Diego 做的「手机集群计算」，价值不在「废物利用」四个字，而在它把计算碳足迹里那块最难啃的部分挑了出来下手，同时暴露了这条路真正的瓶颈在哪。
计算的碳足迹有两个来源。运营碳是设备用电产生的排放，靠提升能效、用清洁电就能压；蕴含碳是制造硬件时已经产生的排放，一旦造出来就固定在那台机器上，没法靠后续优化抹掉。手机的算力其实是一块被高度优化过的低功耗硅片，它的蕴含碳早在出厂那天就付清了。所以这个项目真正动的，是蕴含碳这本难账：与其让一块还能用的主板进回收炉、再造一批新服务器，不如让它继续算。
给 builder 和 researcher 的判断就一句：这类算力对延迟不敏感、可中断的批处理负载才现实，它替代的不是 GPU 集群，是本该被丢弃的那部分蕴含碳。
发生了什么
Google 支持下，UC San Diego 计划部署一个由 2000 部退役 Pixel 手机搭成的数据中心，给数百名研究者和学生提供低成本、低碳的云计算，少造一批新硬件，也就少一批制造排放。完整系统预计 2026 年秋季上线。
做法是把退役手机拆到只剩主板。手机里那些在服务器场景用不上的东西，屏幕、电池、机壳、摄像头这类外设，要么白占空间，要么像电池这种含有数据中心环境不允许的材料，全都得去掉。留下的主板才是核心算力所在，而原文给了一个关键数字：按 Google 内部碳足迹核算，主板大约占整机蕴含碳的一半。换句话说，这套拆解直接咬住了蕴含碳里最大的一块。
软件上，Android 本身基于 Linux，但要把面向移动端的用户空间换成通用 Linux 发行版。换系统不只是为了能跑通用程序，还顺手关掉一批手机上必要、服务器上多余的保护机制。原文举的例子是手机有个「低内存杀手」守护进程，会掐掉吃内存的应用，这在云计算里反而碍事。
调度是另一道关。一部手机算力有限，SPEC 跑分显示 25 到 50 部手机才抵得上一台现代服务器，所以得把活儿摊到大量设备上跑。项目用 Kubernetes 管理容器化应用，把手机按 25 到 50 部一组，组成自管理的集群来应对这件事。
效果上有具体数据可看。大学里本来就有一堆跑在云上的应用：从托管 Jupyter notebook 的小机器，到上并行计算课要用的 GPU 服务器。这里头绝大多数，单部手机就能扛，标准的评分后端跑在 AWS t3.micro 这种小实例上也就 2 个 vCPU、1GB 内存的量级。早期实验里，一个只有 20 部手机的集群就顶住了 75 人以上班级的提交峰值，评分延迟还低于 AWS 默认后端。2000 部的部署，按估计能同时撑起上百门这样的课。
需要点明：这是 Google 研究博客里的项目介绍，不是同行评审论文。2000 部的集群尚未上线，可靠性正是项目要去验证的开放问题之一，原文也明说要拿这套部署当测试床，看消费级硬件长期连续运行扛不扛得住。所以现在能确认的是 20 部规模的早期实验，2000 部的表现还是计划。
为何重要
重要，是因为它把「计算减碳」里一个常被忽略的事实摆到了台面上：运营碳有很多招可以压，蕴含碳几乎无解。你可以给数据中心换清洁电、提升 PUE，但一台服务器从沙子到成品那一路的排放，造出来就钉死了，开机不开机都还在。行业谈减碳谈得最多的是用电，恰恰是因为用电好动；蕴含碳难动，就容易被绕开。这个项目的价值在于它不绕，直接去算那块固定成本怎么摊薄。
主板占整机蕴含碳约一半这个数，决定了拆解策略的合理性。如果费半天劲只是去回收一些边角料，这事不值得做；但既然最大一块蕴含碳就锁在主板上，那么让主板多服役几年，本身就是回报率最高的减碳动作。这是个会算账的环保，不是为环保而环保。
但同样要把价值的边界划清楚。这套东西替代的是「本该被造出来的新硬件」，不是「正在烧电的 GPU 集群」。它能省的是制造端的排放，靠的是少造，不是少烧。一旦把它读成「用旧手机扛起 AI 的算力需求」，方向就错了：大模型训练和低延迟推理要的是大显存、高带宽互联、稳定在线，这些恰恰是一堆 8 到 12GB 内存、彼此异构、可靠性还没验证过的手机给不了的。它解决的是教学和科研里那些小而碎的负载，不是 AI 能耗危机。
更深一层，这个项目把瓶颈究竟在哪说清楚了。直觉会以为旧手机算力太弱所以难用，但原文的 SPEC 数据反过来：手机性能核的单线程跑分已经追平甚至超过数据中心服务器，弱的不是单核，是规模，一部手机内存就那么点、核心就那么几个。于是真正的工程难题从「能不能算」变成了「怎么把几百上千部不可靠、异构、要批量回收来的设备，攒成一个能调度、能信赖的整体」。Kubernetes、自管理集群、关掉低内存杀手，这些动作全是在解协调和运维，不是在解算力。
对建设者的影响
如果你在为延迟不敏感、可切块、可中断的负载找便宜算力，这条路值得认真看。作业评分、notebook 托管、教学集群、能容忍单节点随时挂掉的批处理任务，这些都对它的胃口。判断标准很直接：你的任务能不能塞进一部手机 8 到 12GB 内存的盒子里，挂了能不能重跑而不出大事。能，它就划算；不能，别勉强。
反过来，凡是要低延迟在线响应、要大显存常驻、要节点之间高带宽紧耦合的活儿，趁早别往这上面想。它不是 GPU 集群的廉价替身，硬塞只会把协调成本撞到天花板。把它定位成「一类专门吃可中断批处理的便宜算力」，而不是「通用算力的省钱版」，才不会踩坑。
还有一件事 builder 该收进决策里：选硬件时把蕴含碳和运营碳分开算。很多团队默认减碳等于省电，于是只盯着能效和电价。但如果你的算力需求里有相当一块是可以跑在二手或退役硬件上的，那么「少造一台机器」省下的蕴含碳，往往比「这台机器省点电」更可观，尤其在制造端排放占比高的硬件上。这个项目给出的不是一套现成方案，是一种算账方式：先问这块负载到底要不要全新硬件，再问要不要省电。
对要复刻这套思路的人，最该提前想的是回收和运维这条长尾。拆解、清洗、刷系统、组集群，再到长期跑下来设备陆续坏、怎么热替换、怎么不让一两部死机拖垮整组，这些运营成本原文没细讲，但它恰恰是决定这事能不能规模化的地方。2000 部能不能稳定跑、消费级硬件长期连续运行扛不扛得住，连项目方都还在当开放问题验证，复刻者更要把这笔账提前算进去。
该忽略什么
该忽略的是把它包装成「应对 AI 能耗危机」的宏大叙事。规模对不上，负载类型也对不上，这是一个教学和科研算力的低碳方案，不是数据中心扩张的解药，更不是大模型训练的出路。看到有人拿它当 AI 可持续性的标志性答案，可以直接打个折。
也该忽略「旧手机算力太弱、只能干杂活」这种轻视。原文的跑分数据明摆着，手机性能核单线程并不弱，弱的是单机的规模上限。把它的局限误读成算力不行，就会错判它的真实适用边界，也错过它真正解决的那个问题。
至于 2000 部、上百门课这些数字，记住它们还是计划而非战绩。值得跟进的是 2026 年秋季上线后的可靠性数据：消费级硬件批量长期运行的真实故障率，才是这套路子能不能从一个学校的实验走向更广用途的分水岭。
常见问题
退役手机集群适合跑什么负载，不适合什么？
适合延迟不敏感、可中断、能切成小块的批处理：作业评分后端、Jupyter notebook 托管、教学用的并行计算实验。原文里 20 部手机就扛住了 75 人以上班级的评分峰值。不适合低延迟在线推理、需要大显存的大模型服务、或单机内存超过 8 到 12GB 的任务。把它当 GPU 集群的替代是误读。
旧手机做计算平台真正的瓶颈是算力吗？
不是。现代手机性能核的单线程跑分在 SPEC 上已经追平甚至超过数据中心服务器，蕴含碳也早付清了。真正的难点是把海量异构、不可靠、地理分散或批量回收的设备，变成可调度、可信赖的集群：编排、可靠性、运维成本才是决定它有没有用的东西。原文用 Kubernetes 管理容器化应用，按 25 到 50 部一组组成自管理集群来应对这件事。
这是真减碳还是营销？
有真东西。手机主板占整机蕴含碳约一半，把本该报废的主板二次利用，直接省掉的是新硬件制造的排放，这是实打实的蕴含碳账。但它解决的不是 AI 的能耗危机，规模和负载类型都对不上。把它包装成应对 AI 能耗的宏大叙事是夸大。