第179章 给热量记帐（1 / 2）
第十二次废土之行，第二十四年七月三日。
前哨站二號工作间。
四台伺服器沿墙排开，二十七张170hx分布在四组节点里，风扇压著最低转速，发出很有耐心的嗡鸣。
它们已经学会了骗人。
不拆开看，谁也想不到这批本该老老实实待在矿场里计算哈希值的板卡，已经被江临从固件、驱动和运行时一路撬开，凑出接近一tib的稳定可计算hb。
矿场给它们安排的工作很单纯，日復一日搬同一种砖。
到江临手里，矩阵分块、模型推理、代码索引和证明依赖图都能往里塞。
可一批板卡能计算，与一座计算集群能长期工作，中间还隔著一道很热的门槛。
江临把四天前新建的文件调到主屏。
【ps-theralfabric_v0.1】
t-7交出的本地服务包已经转入只读封存。
未来设备编號、介质参数和原始服务协议都被隔离在实验链之外，控制系统只能读取江临重新定义过的接口。
维护港原来的热管理表很简单。
每条支路后面跟著一个数字，以兆焦为单位，代表还能吞下多少热量。
这套写法適合相变缓衝单元。
那东西像一只预先腾空的水库，剩下多少库容，能接多大的洪峰，一眼就能看清。
眼前这套用水和乙二醇拼出来的液冷迴路麻烦得多，它一边吃热，一边又把热量送去末端换热器。
只记剩余容量，就像只盯著仓库里还有多少空地，却把每天进出多少货忘了个乾净。
於是江临给每条支路开了两本帐。
【持续排热能力：kw】
【响应窗口內瞬態热预算：j】
第一本帐管长久。
一条支路每秒能送走多少热量，决定任务能跑一个小时，还是能跑一年。
第二本帐管眼前。
泵组提速要时间，阀门转动要时间，冷却液从干管走到冷板同样要时间。
在这几十秒里，晶片已经產生的热峰由谁接住，决定板卡是继续计算，还是先把自己烫到降频。
算力有队列，显存有窗口，故障有帐本。
现在，热量也得入帐。
江临切断本地服务包与实验控制网的最后一条连接，开始改造四台伺服器。
原有风道保留下来，继续照顾主板、供电、存储和其他没压冷板的器件。
【写到这里我希望读者记一下我们域名选101看书网，101.超流畅】
二十七张170hx的gpu与hb区域分別覆盖铜冷板，四组节点对应四条並联液冷支路。
三只循环泵负责公共供回水，每条主路旁边再加一段常闭冗余旁路。
正常时，旁路闭著。
主路断流以后，它才有资格开口。
支路末端是一组翅片式液—气换热器，十二台工业风机负责把热空气送出工作间。
入口温度、出口温度、流量和供回水压力都有独立测点。gpu核心、hb区域和板上供电区域的测温结果取最高值，统一记作板卡热点温度。
两只废弃压力容器完成清洗和初次探伤后，被拖进工作间。
江临在內部焊入金属翅片，完成封装，再重新进行焊缝探伤、水压与气密性测试，最后灌入水—乙二醇混合液，改作显热缓衝罐。
这两只罐子显然谈不上先进。
它们又大又重，单位体积吸热能力也很普通，和t-7的相变缓衝单元摆在一起，大致相当於铁皮水桶参加未来工业品评奖。
可铁皮水桶有铁皮水桶的好处。
材料能买到，焊缝能检查，坏了能拆，拆完还能照著再做一只。
现实世界接得住这样的东西。
管路完工以后，江临仍然没让热织网接管控制权。
他先把二十七张卡留在待机状態，在四组冷板迴路上接入可调电阻加热块，一档一档地往冷却液里灌热。
六千瓦。
八千瓦。
十千瓦。
十一千瓦。
十一点八千瓦。
到最后一档，末端换热器的出液温度缓慢上移。两小时后，曲线停住，没再往上爬。
江临在测试页上记下结果。
【末端持续排热能力：11.8kw（当前进风温度、额定风量下）】
这不是一条脱离环境成立的常数。
进风温度、风机转速和液侧流量一併写入標定记录。
【四节点集群预计满载it功率：9.6kw至10.1kw】
换热器够用，泵组的总流量也够用。
这是一条好消息，甚至好得有些可疑。
硬体明明能端走整套集群的热量，四台伺服器此前却始终无法同时跑满。
热去了哪里
第二十四年七月十七日，固定阀位基准测试开始。
四条支路按额定热负荷完成静態水力平衡。
阀门开度写入记录，测试期间全部锁死。
二十七张170hx建立影子窗口，统一任务队列依次进入四组节点。
前二十分钟，曲线很漂亮。
第三十一分钟，node-d的板卡热点温度首先越过七十五摄氏度。
这组节点承担的检查点压缩和显存搬运更多，gpu核心尚有余地，hb与板上供电区域已经开始积热。
第四支路的回水温度向上抬，第二、第三支路却仍然凉快，node-b甚至空著接近一半的冷却余量。
十一点八千瓦的末端能力还在。
只是它平均分在四条管子里，谁也没问今天究竟是哪一组节点发热更多。
第四十六分钟，node-d最高板卡热点温度达到七十九点八摄氏度，第一张卡触发降频。
江临继续等待。
单独压低node-d没有用。
这批矩阵分块存在同步屏障，它慢下来，另外三组节点就得在检查点前陪它站著。
此时迁走活动显存窗口，还要重新建立映射。
ps-scheduler最终只能把整批任务的並发度一档一档往下砍。
百分之九十。
百分之八十。
百分之七十。
总负载降至百分之六十四，node-d的温度曲线终於压平。
其余三条支路仍有余量。
固定阀位模式继续运行六小时，设备完整，过温保护一次也没触发。
代价同样很清楚：按九点八千瓦的满载it功率归一化，固定阀位下，四节点只能释放百分之六十四的安全持续计算负载。
【固定阀位基准】
【测试硬体：27张170hx】
【末端排热能力：11.8kw（同標定工况）】
【四节点集群满载it功率基准：9.8kw】
【安全持续负载上限：64%】
【限制来源：局部支路热量堆积】
【閒置冷却能力：存在】
四条支路加起来明明够用，最热的那一条仍然吃不到別处剩下的冷量。
一座仓库里粮食充足，饿著的人却站在另一扇锁死的门后。
继续往仓库里堆粮毫无意义，得先把门打开。
江临在基准报告首页写下问题定义。
【冷却系统总能力充足，局部冷却能力无法隨计算任务转移。】
最省事的补救有两种。
重新调一次静態水力平衡，或者按最热节点的需求提高总流量和风机转速。
前一种方案只认一种稳定负载，任务一换，平衡就得跟著重做。
后一种方案更直截了当，只要肯长期支付电耗、泵组余量和换热冗余，总能把最坏工况压住。
工程上经常这么干，可靠，省脑子，主要缺点是费钱。
成熟算力中心早已配备变频泵、温控阀和热感知调度。
江临此刻推进的也並非给水泵加一只自动开关。
他要把任务即將產生的热峰、管路尚未送到的在途热量、支路恢復时间和检查点迁移资格，全都压进同一套可验证的运行状態。
任务计划、在途热量、阀门响应和检查点迁移，必须进入同一张状態表。
冷却能力要像计算任务一样可测量、可预留、可迁移，也要知道什么时候该拒绝。
第二十四年八月十二日，ps热织网第一次接管四条支路。
node-a与node-b进入计算状態，另外两组待机。
这一轮只验证稳定工况下的联合调流：两组节点进入稳定负载后，板卡热点温度必须维持在七十五摄氏度以下。
任务启动四分二十秒，node-a温升斜率超出预测。
第一支路阀门开大。
流量增加，支路压力上升，公共干管压差隨之变化，node-b获得的流量开始下降。
四十秒后，node-b温度抬头。
系统转而打开第二支路阀门。
node-b得救，node-a又开始升温。
两条支路围著同一组泵打起了拉锯。
电磁阀在百分之三十四与百分之七十一开度之间往返，压力曲线先动，流量曲线隨后，温度曲线拖在最后，等温度终於把消息送到控制器，上一轮命令早已把局面改得面目全非。
第十一分钟，node-b第一张170hx降频。
第十三分钟，第二张卡逼近保护边界。
江临按下终止键。
风扇还在转，阀门也还在忙。
它们严格执行了每一道命令，问题恰恰出在命令太勤快。
【第一次联合调流测试】
【结果：失败】
【故障类型：支路耦合振盪】
【设备损失：0】
t-7原有逻辑面对的是高速阀组、精密压差控制和相变缓衝。
那里的支路刚收到指令，新的冷却能力已经在路上。
现实电磁阀更讲规矩。
它从接到命令到稳定流量需要数秒，循环泵改变转速以后，整条迴路还得重新找一次平衡。
把未来系统的控制节奏原样塞给它，好比拿战斗机的动作口令去催一辆满载叉车。
叉车已经很努力了，货还是会翻。
江临给控制器加上三条约束。
【任何流量调整，必须等待当前支路完成响应。】
【禁止依据单一温度值连续反向修正。】
【压力变化优先於温度变化进入预测模型。】
第二十四年十二月，第二轮控制逻辑上线。
四条支路各自有了动態帐本。
持续排热能力、响应窗口热预算、冷却液质量、出入口温度、流量、冷板热滯后和缓衝罐状態，一项项写进去。
第二次测试的前四十分钟顺利得多。
node-a和node-b保持稳定。node-c启动后，第三支路帐面仍有百分之三十八余量。
系统据此批准下一组矩阵任务进入。
七分钟后，node-c连续三张卡越过警戒温度。
出口温度正常。
流量正常。
帐上的余量也还在。
江临盯著曲线看了几秒，关闭任务。
那百分之三十八的余量从头到尾都没存在过。
晶片刚產生的热量先进入导热层，再进入铜冷板、软管和冷却液，最后才会抵达支路出口。
传感器看到的温度属於一百多秒以前，帐本拿著旧消息批准了新任务。
简单地说，热已经出发，报表却还当它没上路。
【第二次联合调度测试】
【结果：失败】
【故障类型：在途热量未计入】
【触发降频：3张】
【设备损失：0】
江临拆下node-c的冷板，把测点沿著整条导热路径一路铺开。
晶片附近。
冷板入口。
冷板出口。
支路回水。
缓衝罐入口。
末端换热器。
同一份热量在六个位置留下了六个时间戳。
从晶片温升出现，到回水温度足以稳定反映负载，中间相差一百一十七秒。
一百一十七秒，足够交换机搬完许多批数据，也足够三张170hx把自己逼进降频区。
对於水而言，这只是一段管路的正常路程。
响应窗口热预算隨之改写。
【响应窗口热预算＝分配给本支路的可用显热容量＋窗口內预计排热量－在途热量－安全余量】
两只缓衝罐由四条支路共享，同一份容量不能同时记进四本帐。系统必须先为各条支路预留容量，再根据罐內温度、流量和恢復状態更新可用部分。
分配容量和窗口內预计排热量，可以通过標定与传感器估算；安全余量预先设定。
最难的是在途热量。
它藏在导热层、冷板、软管和流动的液体里，既无法靠一个测点直接读出，也不会因为报表暂时看不见就自行消失。
江临把每张170hx的功耗曲线、窗口映射规模、內核类型和预计持续时间送进ps-scheduler。
矩阵计算有矩阵计算的热峰。
模型推理有模型推理的热峰。
日誌索引和检查点写入的平均功耗相近，短时脉衝却完全不同。
从这一轮叠代开始，算力调度器会提前提交任务计划。
任务尚未进入gpu，它將在未来几分钟產生的热量已经先记到支路帐上。
第二十五年四月，第三轮控制逻辑进入测试。
node-a的矩阵任务启动前三十秒，第一支路开始增流。
任务真正进入计算时，冷却液已经抵达冷板。
第二组任务原本准备送往node-c。
node-c此刻的表面温度更低，帐本却显示它的缓衝恢復速度慢於node-b。
系统放弃这块看上去更凉的节点，把任务送进温度略高、热预算更充足的node-b。
二十分钟后，两条支路都没越线。
第一阶段通过。
江临隨即关闭node-b主回水阀的百分之七十，模擬主回水通路故障。
流量计首先报错。
热织网冻结node-b的新任务，正在运行的分块开始写检查点，node-a与node-c收到迁移计划。
顺序正確。
十七秒后，node-a第一张卡还是降频了。
任务跨过交换机只用了不到一秒。
node-a原有分块尚未结束，新的影子窗口已经建立，算力负载瞬间抬升。
对应支路从收到计划到建立有效流量，需要二十六秒。
第九秒，温升斜率越线。
第十七秒，降频触发。
江临终止迁移。
【第三次故障迁移测试】
【结果：失败】
【故障类型：算力迁移快於冷却响应】
【丟失检查点：0】
【触发降频：1张】
数据可以抄近路，水还得老老实实走管子。
冷却能力抵达以前，空閒算力只是帐面资產。
谁先把任务塞进去，谁就会收到一张过温帐单。
江临在任务迁移状態机前加了一道门。
【olg_ready】
五项条件全部满足，目標节点才允许接收迁移负载。
支路流量达到计划值。
入口温度进入允许范围。
供回水压差进入稳定区间。
在途热量低於安全边界。
缓衝罐已为新任务预留容量。
算力节点等著。
泵和阀门先走。
第二十五年秋，ps-theralfabric完成第七轮內部叠代。
四组节点后面都多出一套热状態。
【node-a】
【可用显存：284gib】
【可用计算窗口：7】
【响应窗口热预算：31.2j】
【预计恢復时间：18】
【故障迁入：允许】
【node-b】
【可用显存：301gib】
【可用计算窗口：8】
【响应窗口热预算：8.7j】
【预计恢復时间：43】
【故障迁入：拒绝】
node-b的显存更多，空閒计算窗口也更多，任务仍被挡在门外。
热预算第一次取得了否决算力调度的权力。
这道权力在接下来的半年里被反覆使用。
高温启动。
低温启动。
泵组降速。
风机失效。
过滤网堵塞。
流量传感器漂移。
单支路泄漏模擬。
伺服器风扇停转。
检查点写入延迟。
二號工作间的过滤棉换了一批又一批，阀门执行器拆开七次，两只缓衝罐外壁上多了新的测点和焊补痕跡。