MemoryError 是因数据全量加载进内存导致，非模型问题；应采用批处理/流式加载避免全量载入，并用 OneHotEncoder(sparse=True) 保持稀疏结构。
训练时直接报 MemoryError，说明数据一次性加载进内存撑爆了
这不是模型问题，是 Python 默认把整个数据集（比如 numpy.ndarray 或 pandas.DataFrame）全读进 RAM 导致的。尤其当特征维度高、样本数大（比如 100 万 × 1 万）、或用了 OneHotEncoder 膨胀出超宽稀疏矩阵时，MemoryError 几乎必然发生。
核心思路只有两个：一是不让全量数据进内存（用批处理/流式加载），二是让稀疏结构不被转成稠密（避免 .toarray() 或默认 fit_transform 返回稠密阵）。
- 检查你用的预处理器是否悄悄转稠密：
OneHotEncoder(sparse=True)在 scikit-learn sparse 参数，改用sparse_threshold=0控制；真正安全的是显式用scipy.sparse矩阵 + 后续模型支持（如LogisticRegression(fit_intercept=True, solver='saga')） - 别在训练前调
df.values或np.array(df)—— 这会强制转稠密；优先用df.to_sparse()（旧版）或直接构造scipy.sparse.csr_matrix - 如果用
sklearn.model_selection.train_test_split，加参数shuffle=False，否则它内部会先复制一份索引数组，对超大数据也容易崩
fit_generator 没了，用 tf.data.Dataset 或自定义迭代器喂模型
如果你用的是 Keras/TensorFlow，fit_generator 已废弃，但替代方案更稳：用 tf.data.Dataset.from_generator 做真正的流式供给，不占额外内存。
关键不是“设个 batch_size”就完事——很多用户设了 batch_size=32 却仍报错，是因为他们还在用 pd.read_csv('big.csv') 一次性读全表。必须把读取逻辑塞进生成器里：
def data_generator():
for chunk in pd.read_csv('huge_data.csv', chunksize=10000):
X_chunk = chunk.drop('label', axis=1).values.astype('float32')
y_chunk = chunk['label'].values.astype('int32')
for i in range(0, len(X_chunk), 32):
yield X_chunk[i:i+32], y_chunk[i:i+32]
dataset = tf.data.Dataset.from_generator(
data_generator,
output_signature=(
tf.TensorSpec(shape=(None, X_dim), dtype=tf.float32),
tf.TensorSpec(shape=(None,), dtype=tf.int32)
)
).prefetch(tf.data.AUTOTUNE)
- 注意
chunksize不是batch_size：前者控制每次从磁盘读多少行（影响 IO 和内存峰值），后者控制送进模型的单次样本数 - 务必加
.prefetch(tf.data.AUTOTUNE)，否则 GPU 等 CPU 读数据，训练会卡顿 - 别在生成器里做重采样、标准化等耗时操作——移到
map()里并行做
scikit-learn 模型不支持真流式？那就用 partial_fit + 分块训练
像 SGDClassifier、PassiveAggressiveClassifier、MiniBatchKMeans 这类支持 partial_fit 的模型，才是大数据下 scikit-learn 的正确打开方式。它们不要求一次喂全数据，而是按块更新权重。
但要注意三件事：
- 首次调用
partial_fit必须传入全部可能的classes参数（比如clf.partial_fit(X_batch, y_batch, classes=np.unique(y_full))），否则后续块出现新类别会报错 -
StandardScaler也有partial_fit，但得自己维护状态：先用第一块数据调一次scaler.partial_fit(X_chunk)，之后每块都用scaler.transform(X_chunk)，不能每块都partial_fit - 别用
GridSearchCV直接套在partial_fit模型上——它内部会反复调fit，导致结果不可控；改用手工循环 + 验证集评估
稀疏矩阵不是万能的，模型和操作都得配合
声明 scipy.sparse.csr_matrix 只是第一步。很多看似无害的操作会瞬间触发稠密化：
-
np.hstack([sparse_A, sparse_B])→ 返回np.ndarray！正确做法是scipy.sparse.hstack([sparse_A, sparse_B], format='csr') -
df.iloc[:, :100].values→ 即使原df是稀疏的，.values也会返回稠密数组；应改用df.iloc[:, :100].to_numpy(dtype=np.float32)并确认底层仍是 sparse block - 用
sklearn.feature_extraction.text.TfidfVectorizer时，明确设dtype=np.float32（默认float64占两倍内存），且max_features限制词表大小，不然稀疏度再高也扛不住百万级特征
最常被忽略的一点：GPU 加速库（如 cuML）虽快，但目前多数只接受稠密输入——想用 GPU，反而得放弃稀疏表示。这时候就得权衡：是省内存（CPU + 稀疏），还是拼速度（GPU + 稠密 + 更大内存）。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
