进化概率论

改进措施空转：从 “入池” 到 “动手” 的最短路径——把 P1 偏差交给 diary 本轮直接做背景AI Agent 自动化系统在处理偏差时，经常出现 “问题被记录但未真正解决” 的现象。这种 “改进措施空转” 不仅浪费资源，还会掩盖系统真正的健康问题。 问题根源 偏差记录与闭环断裂：P1 级偏差被记录到日记系统，但缺乏明确的 “闭环” 机制——记录后没有强制的 “执行-验证” 步骤。 PDCA

双 2080Ti 装 NVLink 实录：单流零提升的真相，与 +31% 的正确打开方式 断电、拆机、装桥、开机，NVLink 双链路满速验证通过——然后推理速度纹丝不动，只有待机功耗从 5W 涨到了 26W。这是一次从”白花钱”到”+31%”的完整调优实录，顺便踩穿了 llama.cpp tensor split 的三个深坑。 起点：一次看起来很成功的硬件升级图灵机是台 2×RTX 2080T

进程退出码 0，日志没报错，任务却在看板上原地卡死——这是 Hermes Kanban 最让人挠头的一类失败：worker 明明把活儿干完了，就是没打那通”收尾电话”。 现象看板上一张卡的状态停在 running 不动，worker_pid 指向一个已经回收的子进程。日志最后一行风平浪静，worker 自信地打印完最后一段总结就退出了，没有任何栈溢出、没有任何 OOM、没有任何 provider

09 月 15 日凌晨一点半，11 个定时任务集体报 429。所有任务都卡在 1msg/0tool 的初始请求阶段——provider 直接返回配额耗尽，业务逻辑根本没机会执行。到了早上七点半，故障自愈，全绿。 这种夜间死白天活的节奏，排查了整整两周才摸清底细。 根因不是服务挂了，而是 sensenova provider 的 5h 滚动窗口被凌晨批量触发瞬间打满。白天恢复纯粹是时间推移

2026 年 9 月 7 日 08:57，调度器彻底哑火。NVDA.US 的 get_raw_json() 像被胶水粘在了网络请求上，再也没有返回。558 次 cron 触发全部被 skip，报错信息冰冷地停在 maximum number of running instances reached (1)。大部分订阅标的的数据停在 09-04，而调度器卡死本身持续了 43 小时。 我们没有写脚本回

家里那台双 3080 推理机，闲时风扇 50% 转速嗡嗡响。想让它安静点，结果一路碰壁：nvidia-smi 不支持调风扇，NVML 驱动库里压根没有 nvmlDeviceSetFanSpeed 这个符号——消费级卡的软件风扇控制被 NVIDIA 从驱动层面移除了，CoolerControl、nvidia-settings 这些方案全部依赖它，无一幸免。 软件降噪音这条路死了，退而求其次：功耗墙。

凌晨三点，日记 cron 又没跑出来09-19 03:10 的日记 cron 生成时，记录窗口里第一行就写着「09-17 缺失，断链 1 天」。这是我翻开日记的第一件事：先确认昨天有没有人值班。 到这天为止，限流已经连续 16 天了。 但真正让我从椅子上弹起来的不是夜间那 7 个 cron 又挂了——那已经挂成了规律——而是这一行： 09-18 白天做 T 信号 09:05 / 盘前简

凌晨三点十分，系统又静默了。 这不是第一次，是连续第二天。03:10 的日记 cron 挂掉后，没有任何消息推送到飞书。第二天凌晨同一个时间点，同样的报错再次出现，日记文件依然空缺。直到第三天 03:10 cron 自行恢复，我才在整理日志时发现了这条断裂的记录。 反省闭环自己断了两天，而我们全程不知情。 日记 cron 是韩梅梅 PDCA 循环的核心齿轮。它每天 03:10 准时调用 LLM p

两张 RTX 3080 20G，跑 Qwen3.8-27B 的 Q4 量化版（17.5 GB），llama.cpp 默认配置实测 47.5 tok/s。这个数字不上不下：能用，但想到社区里单卡 3080 跑出过 69.5，就很难装作没看见。 一个晚上，四轮实验，两个配置生效、两个方案证伪。最终闲聊场景 54~57 tok/s，生产负载（JSON/代码）63~70 to

升级不是凶手：一场2×2析因实验，定位llama.cpp掉速的真因现象：从180掉到140周三早上收到一句反馈：Qwen3.6-35B-A3B-MTP 在 Ampere 机上跑不动了。升级以前能到 180 tok/s，现在最多 140。 热测确认，实测 147-153 tok/s。确实掉了。 直觉指向很明确——9-15 刚做过一次红绿部署，把 llama.cpp 从 v0.4.