AWS SageMaker训练sklearn回归模型时内核重启报错

你贴的tornado.websocket.WebSocketClosedError是次生报错，不是故障根因。这个错误的含义是：Jupyter内核已经崩溃触发重启逻辑，Notebook服务尝试给前端浏览器发"内核重启中"的状态通知时，发现浏览器和实例之间的WebSocket连接已经断开，所以抛了这个错。真正的问题是内核为什么会在训练启动数分钟后崩溃，结合你用ml.m5.12xlarge跑大规模sklearn回归的场景，90%以上的可能是以下原因：

• 内存耗尽触发系统OOM Killer杀进程：ml.m5.12xlarge是48vCPU、192GiB内存的通用计算规格，没有GPU。sklearn绝大多数回归算法是内存密集型，全量数据加载、特征工程、并行计算阶段都会占用大量内存：如果你的数据集做了高维独热编码、没做数值类型压缩、或者用n_jobs=-1开全核并行时触发多进程内存拷贝（比如树模型并行时每个工作进程复制全量数据集，内存占用瞬间翻数倍），很容易触达实例内存上限，系统会直接杀掉Jupyter内核进程，这个过程不会在你贴的NotebookApp日志里留OOM记录。
• WebSocket连接提前断连放大故障感知：如果跑任务时浏览器网络波动、标签页被系统休眠、本地电脑断网，会先断开和Notebook实例的WebSocket连接，此时如果内核刚好因为内存压力重启，就会抛出你看到的回调失败错误，容易让人误以为是网络问题导致的故障。

• 先查系统级日志定位根因：不要只看NotebookApp的日志，去CloudWatch对应Notebook实例的日志组/aws/sagemaker/NotebookInstances下找system.log日志流，搜索Out of memory、Killed process关键字，基本能直接找到内核进程被OOM Killer终止的记录。
• 实时监控内存占用：在Notebook实例里开一个系统终端，执行watch -n 1 free -h，启动训练任务后观察内存使用率，如果内存持续上涨到接近192GiB后突然回落，同时内核重启，即可确认是OOM问题。
• 核对代码配置：检查所有sklearn模型初始化的地方是否设置了n_jobs=-1，检查数据加载逻辑是否一次性读入全量数据且未做类型优化、是否保留了大量无用特征列。

• 优先做内存优化：
  • 数据加载时主动压缩数据类型：将数值列从默认的float64/int64转换为float32/int32，类别列转换为category类型，通常可将内存占用降低50%以上。
  • 调整并行参数：不要直接设置n_jobs=-1，先从n_jobs=8、n_jobs=16开始测试，找到内存和速度的平衡点，避免全核并行导致的内存拷贝放大。
  • 砍掉不必要的内存开销：训练前提前删除无用特征列，避免对高基数类别特征直接做全量独热编码，可改用特征哈希等低内存方案。
• 调整任务运行方式：不要在Notebook内核里直接跑大规模全量训练——Notebook实例是为交互式开发设计的，内核本身有额外内存开销。把训练逻辑打包成SageMaker训练任务提交，同规格训练实例的可用内存比Notebook实例高15%以上，还支持分批加载数据、断点续跑，也不会受浏览器WebSocket断连影响。如果一定要在Notebook里跑长任务，用nohup后台执行脚本，不要依赖单元格前台运行。
• 按需调整实例规格：如果代码优化后内存仍有缺口，换用内存配比更高的r5系列实例，比如ml.r5.12xlarge配384GiB内存，比同vCPU数的m5系列更适合内存密集型的sklearn训练任务。

内容的提问来源于stack exchange，提问作者Jorge