你让 ChatGPT 处理一个 200MB 的 CSV、拟合一个模型、再画残差图。二十秒过去,响应单元变红:The code execution timed out 或者 Sandbox terminated. Retrying...。模型重试一次,撞上同样的墙,然后干脆改打印伪代码,不再实际运行。
最快的修法: 别再要一个巨型 cell。让模型把活拆成多个 cell,每个控制在 30 秒以内,并把中间结果以 parquet 形式持久化到 /mnt/data/。光这一个改动就能解决大多数超时,因为沙盒限制的是单次运行,而不是整段对话。
Code Interpreter(在工具选择器里叫 Advanced Data Analysis,是同一个功能)把你的 Python 跑在一个临时容器里 —— 截至 2026 年 6 月,每次运行大约有 120 秒的持续计算上限,外加很紧的 ~1GB 内存 上限和有限的 CPU。容器本身在整段对话期间一直在,但闲置约 20 分钟后会被回收。大多数超时不是 “ChatGPT 坏了”,而是一个 cell 想一口气干完所有事,把整个 dataframe 全部塞进内存,或者卡在沙盒根本走不出去的网络调用上。
先判断你属于哪一类
先用秒表掐一下故障发生的时间 —— 是耗满墙钟还是瞬间挂掉,基本就能告诉你答案。
| 症状 | 最可能的原因 | 跳到 |
|---|---|---|
| 约 60-120 秒后变红,没有输出 | 单个 cell 干完所有事(CPU 密集) | 第 1 步 |
| 不到 10 秒就挂,提示超时 | 内存暴涨,被 OOM-killed | 第 2 步 |
| 一直挂到超时,没有任何进度行 | 网络调用 / 被禁的 pip install | 第 6 步 |
大 frame 上慢,df.head() 上瞬间完成 | .apply(lambda) / .iterrows() | 第 3 步 |
在 plt.show() 之后卡住 | 画图点数太多 | 第 4 步 |
| 每个 cell 都从头重读上传文件 | 跨回合状态丢失 | 第 5 步 |
常见原因
按实际会话中遇到的频率排序。
1. 单个 cell 想把端到端的活全干完
模型写了一个巨型 cell:读 CSV → 清洗 → 特征工程 → 训练 → 交叉验证 → 画图。哪怕只是一个 50MB 的文件,这个组合也经常突破沙盒单次运行的计算上限。Code Interpreter 不会流式返回中间结果,cell 一挂中间状态就全没了。
怎么判断:出错的 cell 超过约 40 行 Python,里面有多个对 dataframe 的 for 循环,且至少出现一次 fit / cross_val_score 调用。
2. 沙盒里发起了网络请求
沙盒没有对外的联网能力 —— 截至 2026 年 6 月,OpenAI 自己的文档也确认了这一点。有些调用会立即失败,但 requests.get("https://api.example.com/...")、yfinance.download(...) 这种带 DNS 解析的写法往往不会快速失败 —— 它会一直挂到沙盒看门狗在大约 120 秒处把它杀掉。pip install 去访问 PyPI 也是同理,沙盒根本连不上。
怎么判断:cell 里 import 了 requests / urllib / httpx / yfinance / pandas_datareader,或者直接 pd.read_csv("http...")。超时之前没有任何进度输出。
3. 没等到时间到,内存先爆了
大表 join 或者宽表 df.pivot() 容易突破 ChatGPT 应用里约 1GB 的 RAM 上限。内核被 OOM-killed,ChatGPT 给你显示的是一个通用的超时提示 —— 哪怕实际上根本没耗多少时间。(OpenAI API 版的 Code Interpreter 工具能设 memory_limit 为 1g/4g/16g/64g,但面向用户的 ChatGPT 应用没有这个旋钮,你只能困在最低档附近。)
怎么判断:cell 不到 10 秒就挂出超时。换成小切片 (df.head(1000)) 再跑就秒回。
4. 在宽 dataframe 上用 pandas 的链式 lambda
df.apply(lambda row: ...) 跑 100 万+ 行就是单线程纯 Python。向量化版本 2 秒搞定,lambda 版本会一直跑到撞上单次运行的超时上限。模型经常写 lambda 版本,因为代码更短。
怎么判断:对超过 ~10 万行的 frame 用了 .apply(lambda ...) 或 .iterrows()。
5. 上传文件在 cell 之间丢了,代码每次都重新读
新的对话回合可能会拉起一个全新的沙盒。如果第 3 轮要用第 1 轮上传的文件,模型可能每轮都重新读、重新解析、重新生成特征 —— 把超时预算全浪费在重做准备工作上。参考 ChatGPT 附件在刷新后丢失 里关于沙盒状态的细节。
怎么判断:每个 cell 开头都是 pd.read_excel("/mnt/data/<file>.xlsx") 加新鲜的 df.head()。之前 cell 里的变量全部不见。
6. 画图时点数太多
matplotlib 散点图画 50 万+ 个点,要在沙盒 CPU 上把整个图序列化成 PNG。光这一步就能吃掉 30 秒以上。
怎么判断:超时前最后能看到的动作是 plt.show() 或者 sns.scatterplot。把点数砍到 5000 就立刻不超时了。
开始之前
- 确认你的套餐 —— Free 的沙盒限制更紧,每天可上传的文件数也很少(Free 大约每天 3 个文件),Plus / Team / Pro / Enterprise 要宽松些。
- 看清楚超时是确定性的(每次都在同一个 cell)还是偶发的(有时能跑完)。
- 重新提示之前先把出问题的 cell 代码留底,ChatGPT 经常在重试时改写代码,你就丢失证据了。
- 检查上传文件的体积。截至 2026 年 6 月,硬上限是 每个文件 512MB,但电子表格和 CSV 实际上在 ~50MB 附近就会卡(取决于每行的宽度),文本/文档类文件每个上限是 200 万 token。每条消息最多挂 10 个文件,每 3 小时大约 80 个。
需要收集的信息
- 出现的具体报错文本(“execution timed out”、“sandbox terminated”、“kernel restarted”)。
- 超时前的大约挂钟时间(用秒表 —— 这能区分 OOM 和墙钟超时)。
- Dataframe 形状(
df.shape)和按 dtype 算的内存占用(df.memory_usage(deep=True).sum() / 1e6MB)。 - cell 是否有任何网络 I/O 或
pip install。 - 当前使用的模型 —— 截至 2026 年 6 月,GPT-5.5 是 ChatGPT 的默认模型(选择器里有 Instant / Thinking / Pro)。模型选择会影响 planner 怎么把活拆进各个 cell。
一步一步修
按 ROI 从高到低排。
第 1 步:逼模型把活拆成有 checkpoint 的多个 cell
在提示里加一段:
分多个 cell 跑这次分析,每个 cell 控制在 30 秒以内:
Cell 1: 读取并检查文件,只打印 shape 和 dtypes。
Cell 2: 清洗并 downcast,把 df 保存到 /mnt/data/clean.parquet。
Cell 3: 特征工程,保存 features.parquet。
Cell 4: 训练并评估,打印指标。
Cell 5: 只画一张图。
不要合并 cell。中间状态用 parquet 文件持久化。这能把一个 120 秒的巨型 cell 拆成五个 20 秒的小 cell,中间的 parquet 文件还能熬过沙盒重启。
第 2 步:在重计算之前先 downcast 和切片
在训练或 pivot 之前,先把 dataframe 压小:
import pandas as pd
df = pd.read_csv("/mnt/data/input.csv")
for col in df.select_dtypes("float64"):
df[col] = pd.to_numeric(df[col], downcast="float")
for col in df.select_dtypes("int64"):
df[col] = pd.to_numeric(df[col], downcast="integer")
for col in df.select_dtypes("object"):
if df[col].nunique() / len(df) < 0.5:
df[col] = df[col].astype("category")
print(df.memory_usage(deep=True).sum() / 1e6, "MB")1.8GB 的 frame 经常能压到 300MB。同一个 cell 立刻就装得下了。
第 3 步:把 apply(lambda) 换成向量化操作
直接要求模型:
重写这个 cell,不要用 .apply(),也不要用 .iterrows()。只用向量化的
pandas / numpy 操作。如果某一步无法向量化,就在 df.sample(50_000)
上做,并解释 trade-off。很多时候,这一次重写就能把 90 秒超时变成 3 秒跑完。
第 4 步:给 matplotlib 限制点数
任何在大 frame 上的散点图都这么写:
sample = df.sample(min(5000, len(df)), random_state=0)
plt.scatter(sample["x"], sample["y"], s=4, alpha=0.4)
plt.show()或者改用 hexbin / 2dhist,先聚合再渲染。渲染时间从 30 秒掉到 1 秒以内。
第 5 步:把中间状态持久化到 /mnt/data/
沙盒工作目录 /mnt/data/ 在同一对话内多数沙盒重启之间能保留下来。每完成一个重计算步骤就保存:
df_clean.to_parquet("/mnt/data/clean.parquet")
features.to_parquet("/mnt/data/features.parquet")下一个 cell 用 df = pd.read_parquet(...) 起步 —— 亚秒级。哪怕第 4 个 cell 超时,前面 1-3 个 cell 的成果都还在。
第 6 步:把网络调用挪出沙盒
如果脚本需要外部数据,不要让 Code Interpreter 自己去抓。做法:
- 自己在本地下好数据(curl、浏览器都行)。
- 把文件上传到对话里。
- 让模型只从
/mnt/data/<file>读取。
对于需要付费墙或登录的来源,可以参考 ChatGPT 联网搜索被付费墙站点拦截 —— Code Interpreter 受同样的边界约束。OpenAI 自己的 Code Interpreter 工具文档 也确认了沙盒没有对外网络;联网浏览工具是另一个独立的、非 Python 的入口。
第 7 步:实在不行就把沙盒重启一遍
在新一轮对话里:
重置 Python 沙盒。在新 cell 里 print("ok") 确认,
然后重新加载 /mnt/data/clean.parquet。旧内核的残留状态(挂住的线程、上一轮泄漏的文件句柄)确实是性能下降的真实原因,换个新内核往往立马变快。但反过来也要注意:容器闲置约 20 分钟后会被回收,所以如果你分析到一半走开再回来看到 “session expired”,/mnt/data/ 里的文件也一起没了 —— 要从你存好的 parquet 重新上传、重跑,而不是指望内存里的状态还在。
验证
- 之前出错的 cell 现在能完整跑完,输出直接显示在下面。
- 整个分析的总挂钟时间在沙盒预算内还有富余(目标:每个 cell 不超过 30 秒)。
- 在新的对话里重跑同一个提示能复现成功 —— 证明不是内核偶尔抽风。
- downcast 之后内存占用低于 500MB(之前要 1.5GB+)。
长期预防
- 任何超过 50MB 的文件,对话第一步就让模型先打印
shape、dtypes,并先规划 downcast 方案,再动数据。 - 把”每个 cell 只做一件事”写进你的提示模板。读取、清洗、join、建模、绘图都各占一个 cell。
- 任何超过 10 秒的步骤之后都要持久化到 parquet;把沙盒当作可丢弃的临时资源。
- 重复性的工作流优先用本地 Jupyter / Colab,只用 ChatGPT 生成和审阅代码。
- 永远不要让模型在沙盒里写
requests.get(...),要么提前下好,要么干脆不调。 - 用 Advanced Data Analysis 处理超大文件时,先把上传切块(
split -n l/4 big.csv),分块处理。
常见坑
- 不给具体预算就说”让它更快”,换来的只是边角的微调,而不是结构性重组。
- 同一个失败提示重跑 5 次,把消息上限耗光 —— 参考 ChatGPT 消息上限触发。
- 以为
pip install <pkg>是免费的;某些套餐里它会触发沙盒刷新,耗 10-20 秒。 - 为了”精度”硬要画 100 万个原始点 —— 你的眼睛区分不出 5000 和 100 万,但沙盒能。
- 忘了
/mnt/data/在开新对话时会被清空。文件在同一线程内能存,跨线程不行。 - 看到 “completed successfully” 就当成功,实际并没有真的画出图或表 —— 一定要看输出 cell。
FAQ
Q: 超时到底是多少秒?
截至 2026 年 6 月,在 ChatGPT 应用里,单次运行大约持续计算 120 秒 后就会被沙盒杀掉。实际体验上 Free 最紧(资源更少、每天可上传文件数更低),Plus / Team / Pro / Enterprise 的余量更大,但单次运行的墙钟上限在哪个套餐都是有限的。OpenAI 不公布各档的精确数字,而且会变,所以不管哪个套餐,单个 cell 超过 30 秒都要当作有风险。
Q: 能在 ChatGPT 应用里调大超时或内存吗?
不能。面向用户的应用没有任何超时或内存的旋钮。要做的是结构调整:文件更小、downcast、向量化、拆 cell、持久化 parquet。唯一有内存旋钮的地方是 OpenAI API 版的 Code Interpreter 工具,可以把 memory_limit 设成 1g/4g/16g/64g —— 那是开发者/API 路径,不是你在 ChatGPT 里能切换的东西。
Q: 我本地 3 秒能跑完的 cell,在 ChatGPT 里就超时,为什么?
沙盒 CPU 核心数比你笔记本少,没有 GPU,只有 ~1GB 内存,磁盘也更慢。被单线程 Python(lambda、循环)主导的运算上限低得多。改成向量化以后差距通常就消失了。
Q: 我去吃了个午饭回来,文件怎么没了?
容器闲置约 20 分钟后会被回收。一旦过期,/mnt/data/ 会被清空,你下一条消息可能看到 “session expired” 或者一个全新的沙盒。重新上传源文件,从你存好的 parquet checkpoint 重跑即可。
Q: Advanced Data Analysis 和 Code Interpreter 是同一个限制吗?
是 —— 它们就是同一个功能。“Code Interpreter” 是最早的名字,“Advanced Data Analysis” 是你在工具选择器里看到的标签。沙盒、包、超时行为完全一致。
Q: 我上传的文件中途消失了,是超时引起的吗?
不是,那是另一个沙盒重启问题。参考 ChatGPT 文件从对话中消失 —— 重新上传,在任何重计算步骤之前先持久化到 parquet。