预设环境是有公网 IPv6、没有公网 IPv4 的普通家宽，保留 IPv4 出站能力。若干家庭各自运行小型 Kubernetes 集群，经 IPv6 互联；少量双栈云节点承担兼容接入和需要稳定在线的基础服务。公网 IPv4 家宽节点可以参与，但不构成必要条件。
由这些小集群组成区域性乃至全国性的资源池，目标是统一安排任务、算力和数据。组网与多集群管理工具暂不选定。这是一份持续修订的设计草案，目前只讨论架构上的取舍，尚无部署和实测结果。
家宽的可用容量一直在变
单户家宽不宜被预设为高可用节点。关机、重拨、前缀变化、家庭用网争抢和上行拥塞都可能随时发生；机器也可能始终在线，但跨网路径已经不适合传输任务数据。这类资源的供给具有间歇性，带宽和时延还会在一次任务的执行期间显著变化。
资源目录如果只汇总核数、显存和在线状态，容易长期高估可交付的容量。一次探测成功，只能说明当时那条路径可达。调度还需要观察可用吞吐、时延尾部、丢包、连续在线时段，以及站点承诺共享的时间窗口。测量应有方向和对象：站点到入口正常，不代表站点之间的路径正常。
这些观测也只能形成估计。比较合理的做法，是把站点分为可接单、劣化、失联和恢复观察几种状态，并给不同工作设置不同的准入条件。链路开始拥塞时先停止新增传输，允许不依赖外部数据的已有计算继续；恢复后经过一段观察再增加配额。进入与退出劣化状态采用不同阈值，避免短时抖动触发反复搬迁。突然断电当然可能跳过劣化阶段。
迁移同样消耗家宽上行。若轻微丢包就搬走任务，传输检查点和重拉输入可能进一步加重拥塞。是否接替，需要比较剩余运行时间、恢复等待、搬运成本与截止时间；对短任务重算，对长任务恢复检查点，对严格时延服务预先放置副本，不能共用一种故障策略。
高冗余因此需要付出可见的容量成本。可承诺的容量应按约定故障情景下仍能交付的份额计算，并留出接替余量。不同家庭之间也未必独立：同一运营商汇聚、区域停电、共同入口或存储，都可能造成同时失效。不能把单站可用率相乘，就推导出全国资源池的可用率。
本地集群与区域资源池
每户站点保留自己的控制平面、Pod 网络和本地存储。上层负责跨集群放置，本地 Kubernetes 负责节点调度。全国范围共用一组跨家宽的 etcd，会把普通链路波动引入控制状态的提交过程；独立小集群则允许一个站点失联时，其他站点继续工作。
“区域”可以先作为逻辑资源池存在，不必立即对应一套独立控制服务。地理位置决定数据约束和部分故障相关性，运营商与实际路径决定互访成本，两者需要分别记录。一个区域适合承担紧邻数据的计算，另一个区域可以提供异地恢复容量；行政边界未必就是合适的调度边界。
全局资源目录、任务账本和跨站控制需要落在在线条件相对可预测的位置，具有独立故障域的副本和恢复安排。家庭站点的自治范围是已接纳的本地服务和已有任务。失去上层联系后，新的全局任务停止派发；若以后允许区域离线接单，应提前划定互不重叠的任务归属与配额。
具体放置时，数据可去往的范围、站点信任、架构与设备要求先构成硬约束。通过这些条件后，才比较数据搬运、排队、计算和失败恢复的成本；没有合格位置时，任务可以等待，而非为了用上闲置机器而放宽约束。
Pod 的划分随之落到几种不同约束上：
| 负载 | 放置范围 | 站点失联后的处理 |
|---|---|---|
| 本地基础服务 | 本站，固定保留资源 | 尽可能保持本地可用 |
| 可重算、可分段任务 | 数据附近的合格站点 | 重试、检查点接续，限制重复副作用 |
| 无状态在线服务 | 多个独立站点或区域 | 副本接替，入口退出失效后端 |
| 强状态或紧耦合任务 | 网络与数据条件可控的小集群 | 按应用的数据恢复和一致性要求处理 |
家宽更适合承接独立作业、分片计算和可中断批处理。需要频繁同步的工作尽量留在低时延的小集群内，跨区域安排不同作业。持久数据应先确定副本位置、RPO 和 RTO，再谈迁移 Pod；本地盘上的唯一副本无法靠重新调度恢复。
资源共享也保留所有权边界。本地用量优先，外来负载使用明确配额。不同所有者的节点不能自动视作同一信任域，命名空间也不能对宿主机管理员隐藏任务秘密；这会直接限制某些数据和任务能够去往的站点。
IPv6 为主，IPv4 保留接入
站点间优先利用可达的 IPv6 路径，IPv4 兼容集中在少量双栈入口。直接路径不可用或质量不足时，可以选择区域中继；是否中继应由路径条件决定，不能预设全部流量绕云，也不能只因分配到了公网 IPv6 就认定直连可用。
外层地址、内部地址和服务身份分开管理。家宽前缀变化只更新站点端点及相关路由、发现信息，内部地址规划不随每次重拨重建。需要跨站路由的网段避免重叠，Pod 与 Service 地址先限定在各自集群内。默认跨站交换的是任务、结果和选定的服务接口；确有需求时，再开放特定 Pod 网段。
IPv4-only 成员可以经兼容入口进入授权的内部服务；普通浏览器则经公开应用网关访问。对同时提供 A、AAAA 的应用，两条路径应有一致的认证和服务语义，IPv4 到 IPv6 的衔接由网关完成。客户端可能选择任一地址族，因而兼容入口仍需按实际流量留足带宽，并具备独立备用路径。
公网 IPv4 家宽节点可以补充入口容量，但其退出不应阻断 IPv4 接入。云端保留长期入口责任，更适合在费用与可用性之间形成明确预算。公开应用入口与集群管理接口分离，中继终止连接时的信任边界也要单独确认。
DNS 与基础服务需要先于业务恢复
自建 DNS 应当进入这套网络的基础设计。站点端点会变，服务落点会变，家庭网络还需要在上层不可达时维持本地解析。完全依靠临时 IP 清单，或让全部名字都依赖远端业务集群，都会把恢复过程变得脆弱。
可以分开管理公网应用名称、内部站点与服务名称、各集群自己的服务域。内部权威区由稳定管理层维护，副本分散到独立故障域；站点保留受限的本地递归解析和必要的本地区数据。跨集群导出的服务使用明确的站点或区域命名范围，各集群内部的同名服务不直接混成一个全国名称空间。权威更新、服务注册和节点身份应关联，失效或退出站点的记录能够撤回。
更关键的是引导依赖。承担启动所需解析的服务，应能独立于待恢复的业务集群运行。站点还需保存少量可维护的引导端点与信任材料，使管理连接能够在集群 DNS 未就绪时建立。把解析服务、认证入口和连接恢复程序都放进尚未启动的同一集群，会留下一个冷启动环。
断网时，本地区与仍有效的缓存可以继续服务。对变化较慢的记录，也可评估有时限的过期缓存策略；动态家宽端点应更谨慎，旧地址可能已不可达或被重新分配，连接仍须验证目标身份。缓存不能成为继续接单或延长执行权的依据。DNS 返回一个地址，也不能代替业务健康检查。
自建范围应围绕这些内部需要展开：递归服务仅面向授权客户端，内部区数据限制分发，公网只发布明确需要公开的应用记录。权威副本、缓存与任务状态各自保留边界。地理与拓扑上的副本分散可参考 RFC 2182，过期缓存的适用条件见 RFC 8767。
同样需要预先安排的还有地址分配、时间同步、节点身份与证书更新，以及基础镜像和配置的本地留存。它们不必全部集中，也不必全部进入 Kubernetes；至少要使一个重启后的站点能够恢复必要的时钟、验证管理端身份，并取得启动材料。证书过期、镜像拉取失败或解析失效，都会使一台网络已恢复的机器继续处于不可用状态。
失联之后，旧任务可能还在运行
停止向某站点派发任务，与撤销其已有任务的写入权，是两件事。远端看不到心跳时，本地进程仍可能继续计算，甚至通过另一条路径访问数据。立即重派会形成并行执行，单靠超时无法消除旧执行者。
可重算任务可以接受受控的重复计算，但任务归属需要持久账本和单一的权威决策。接替时产生新的执行代次，所有相关写入目标原子校验代次并拒绝旧写入；已经发生的外部副作用另由幂等或去重机制处理。无法约束旧写入的任务，不适合在失联后直接自动接替。
站点重连时先核对执行权、结果和数据版本，再恢复新任务准入。不能因为节点重新显示在线，就立即恢复它失联前的全部职责。DNS、路由和服务发现的更新也有传播过程，旧连接不会随记录变更自动迁移。
数据决定接替是否值得。缓存和中间结果可以丢弃，重要输入与成果需要异地副本和独立备份。复制流量同样受家宽上行限制，恢复策略应承认尚未同步的进度，而非把所有副本写成即时一致。资源池的高冗余，最终要落实到每类任务允许中断多久、允许丢多少进度，以及为此预留多少网络和计算容量。
尚待验证的取舍
初期可以只接入几个独立站点，但试验应包含不同路径和正常家庭用网时段。比扩大节点数量更早需要验证的是：链路劣化时能否及时停止新增任务，突然失联后能否接续，旧站点恢复后能否阻止过期写入，以及基础服务能否支撑一次完整冷启动。
观察对象应是任务完成时间的分布、无效搬运量、故障后的重复计算和丢失进度。还应记录持续离线、前缀变更、入口失效与解析不可用各自占用了多少恢复时间。若接替与数据搬运长期抵消了闲置资源的收益，就需要收缩可接纳的任务范围，或提高站点准入条件。
全国覆盖可以是资源目录的规模，高冗余却需要逐项建立。目前尚待回答的，是哪些任务值得承受家宽的这种波动，以及为了按时交付，需要从名义容量中扣掉多少。
修订记录
- 2026-10-23：首次公开设计草案。讨论间歇可用资源、多集群放置、双栈接入、自建基础服务与失联接管，配五张示意图；性能与恢复时间尚待实测。