TensorFlow显存增长模式默认关闭，且必须在CUDA上下文初始化前启用，否则报RuntimeError；它与memory_limit互斥，且不缓解单步显存峰值问题。
显存增长模式默认关闭是CUDA上下文初始化的硬约束
TensorFlow在首次调用 tf.config.list_physical_devices('GPU') 时，会触发CUDA驱动创建上下文（context）。这个上下文一旦建立，显存分配策略就已锁定——tf.config.experimental.set_memory_growth 必须在上下文创建前执行，否则会抛出 RuntimeError: Physical devices cannot be modified after being initialized。这不是设计“懒”，而是CUDA运行时本身的限制：它不允许在context alive状态下动态切换预分配/按需分配模式。
开启时机错误是90%失败的直接原因
常见错误现象：代码里写了 set_memory_growth，但 nvidia-smi 显示显存仍瞬间打满。原因几乎总是——它被放在了模型构建、数据加载甚至 import tensorflow 之后。
- 必须放在
import tensorflow as tf之后、**任何张量操作之前**（包括tf.random.normal、tf.constant、tf.keras.Model()） - 不能放在Jupyter cell中间：如果前面cell已触发GPU初始化（哪怕只是
tf.test.is_gpu_available()），当前cell再调用set_memory_growth就无效 - 容器/Kubernetes环境要特别注意：镜像启动时可能有预加载逻辑，需确保该设置在entrypoint最前端执行
和 set_memory_limit 互斥不是bug，是内存管理语义冲突
当你同时调用 tf.config.experimental.set_memory_growth(gpu, True) 和 tf.config.experimental.set_memory_limit(gpu, 4096)，后者会静默覆盖前者。因为两者的底层机制根本不同：
-
set_memory_growth=True→ 告诉CUDA：“我不要固定大小的池，每次malloc都走runtime分配流程” -
set_memory_limit=4096→ 告诉CUDA：“给我划一块4GB的池，后续所有分配都在里面做”
二者逻辑不可共存。如果你看到显存没增长，先检查是否无意中设置了limit。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
它不解决单步显存峰值问题，这点常被误读
启用内存增长后，nvidia-smi 显示的显存使用量会缓慢爬升，但这只说明“框架没抢光所有显存”，不代表你的模型不会OOM。比如一个batch_size=64的ResNet50前向传播需要5.2GB，而卡上只剩5.0GB空闲——即使增长模式开着，这一步照样崩。此时真正要动的是：batch_size、模型宽度、或用 tf.keras.mixed_precision.Policy 切float16。
最易被忽略的一点：增长模式对已存在的Python对象无感知。如果你在开启前已经创建过GPU张量（比如调试时手敲过 tf.ones((1000,1000))），那段显存就被永久占住，clear_session也清不掉——只能重启Python进程。
