付费 Colab 为何没到24小时就断开？一份 L4 用户报告能说明什么

FAQ 将 Pro+ 的连续执行描述为计算单元充足时最长24小时。定价页描述浏览器关闭后的后台执行，同样以正计算单元余额和最长时限为条件。这是上限说明，并非最短运行时长承诺；也不能据此认为保持浏览器连接就能免受其他资源限制。

两份文档的表述并不相同。FAQ 说明资源不保证且并非无限、限制可能波动，并且不公布具体限制；定价页另行说明资源不保证，使用限制和硬件可用性需要保留动态调整空间。合起来看，不应把每次付费会话都能运行24小时作为计划前提。但这些说明没有识别某次终止的原因，不能证明每次终止都是有意为之，更不能推导任何可能的终止都符合服务条款。

在 issue #6101 中，AIBI0131 报告每30秒检查内存信息、cgroup 的 OOM 计数和内核日志，并记录多次会话中超过40GB的内存余量、观测到的 OOM kill 为零、没有观测到 GPU Xid 错误，以及终止前最后一拍仍在运行的心跳。这些是报告者的观察，本刊没有独立复现或检查其诊断环境；账户中仍有计算单元，也属于用户自报。

这些观察削弱了几种简单解释，却不能凭未记录到错误就排除全部内存、GPU、连接或平台故障。心跳说明某个进程运行过，不会展示服务方完整的空闲判定逻辑，也不能证明工作负载符合所有政策。虚拟机内部日志同样无法揭示宿主调度、账户级决策或服务端终止原因。单独一个 WebSocket 关闭码是症状，不是诊断结论。

报告者描述单会话在活跃工作约2小时15分后终止；三个笔记本并行时，另一些会话在虚拟机存活3小时5分至3小时49分之间终止。这里既有配置差异，也有计时起点差异，相减不能测出统一的终止阈值。这份小样本、单账户记录既不能确立通用的隐藏上限，也不能证明不存在这类上限。

线程中其他参与者报告 L4 或 A100 提前终止，其中包括 Colab Pro 用户。多个人描述相似症状，不等于已知发生率、共同根因、相同订阅权益或覆盖某类硬件的统一政策。调度行为、运行时回归和基础设施故障，仍是需要区分的假设，而不是本专题已经确认的发现。

2026年10月1日，署名 spencersgoogle 的回复者表示 L4 不会被区别修剪，并询问报告者使用最新还是旧运行时版本。这为版本对照提供了线索，却不是经独立验证的遥测、已经结束的支持调查，也不能据此排除差异化处理。公开线程仍未提供这个账户的服务端终止原因。

FAQ 将产品内反馈列为提交问题的路径，报告者表示已经提交。有效升级应保留 issue 引用、实际订阅层级、运行时版本、加速器、时间戳、计算单元观察，并区分活跃工作时长和虚拟机存活时长。相关 issue 编号只是调查线索，并不证明同一故障。公开文档没有列出全部限制，也不能解释这个具体支持问题为何尚未解决。

下一次可比运行前，先核实实际套餐和运行时版本，不能将 Pro 与 Pro+ 的个案直接当作相同权益。记录检查点时间、最后成功保存的输出、终止时间和支持回复；条件允许时，用尽量匹配的配置做对照。服务方原因码或可复现的版本差异，会实质改变判断。在这些证据缺失时，增加计算单元能否解决该问题尚未得到证明。

购买决策取决于中断后能保留多少有效工作，以及工作负载需要多大控制权。如果保存状态后重启的代价可接受，这种有条件的运行时仍可能适用；如果多次中断损失大部分进度，则应先验证恢复设计，或评估资源控制和明确承诺更合适的服务。FAQ 指向 GCP Marketplace 专用方案和 Colab Enterprise，作为不受 Colab 强制使用限制的保证资源路径，但这本身并不承诺作业永不中断、合同规定的最短运行时长或已经实现的节省。切换前仍需核对实际条款、恢复负担和工作负载总成本。