一次常规的数据加载步骤让常驻内存膨胀近19倍；ijson 等流式解析器逐条处理记录，无论文件多大都能保持内存占用平稳。
808 MB。这是一个 Python 进程在读取一个磁盘上仅 43 MB 的 JSON 文件后达到的内存占用——接近19倍的膨胀，也是 KDNuggets 近期一篇工程实操文章的核心问题。
这种跳升并不是 bug，而是整文件解析的默认行为。当 Python 以常规方式加载 JSON 文档时，它会在任何分析开始之前，就把整个层级结构——每个对象、数组与字符串——一次性物化为原生 Python 结构。由于 Python 对象带有可观的逐项开销，一段文本上紧凑的文档在常驻内存中的占用可能高出一个数量级。对任何把文件大小当作内存需求可靠指标的团队来说，43 MB 与 808 MB 之间的差距是一次令人不快的纠偏。
这篇实操文章给出的答案是 ijson，一个流式解析器。ijson 不把整个文档读入内存，而是增量地遍历它，每次产出一条记录，让代码在下一条到来之前处理并丢弃当前条目。内存占用随之跟随单条记录的大小而非文件的大小——作者所说的流式处理“改变了一切”，正是这个意思。
这一教训不止适用于一种文件格式。触及内存上限的数据管道之所以失败，往往不是数据真的太大，而是加载策略坚持一次性物化全部数据。
对 AI 基础设施规划者来说，这个案例是一个低调但实用的数据点。训练与预处理节点的内存余量代价高昂，一个把 43 MB 输入膨胀成 808 MB 常驻内存的步骤，会迫使团队采购比底层工作负载实际需求更大的实例。流式摄取之所以位列最便宜的可选优化之一，正是因为它不需要任何新硬件——只需换一条解析路径。
萬安算交所 AIXX · 萬安算交所 AIXX · 算力硬件实名会员制交易平台 · 进入货源大厅