Keras模型子类化中call函数的运行时机、机制及多次触发原因

关于层初始化与连接逻辑的认知验证 #

你的核心认知基本完全准确，仅需补充一处细节修正：

• 在构造方法__init__的执行阶段，确实仅完成所有网络层实例的创建，固定层自身的超参数（比如Dense层的神经元数量、激活函数类型）；此时层的权重还未正式生成（若未预先指定输入维度），也不存在任何跨层的连接关系。
• 你提出的“层间连接不存在独立逻辑实体，本质是按特定顺序将某一层的输出传递给下一层的执行过程”的判断完全准确。和函数式API会在层实例创建时，就把输入、输出张量的映射关系存储为固定的计算图结构不同，子类化模型的层间连接逻辑完全内嵌在call方法的逐行代码中，不存在单独的连接对象实体。
• 补充细节：构造方法执行完成后，层的权重张量并非直接完成初始化，而是要等call方法第一次接收到实际输入张量时，才会根据输入的维度尺寸，为每一层创建匹配形状的权重矩阵，完成权重的随机初始化。

训练早期三次call触发的原因拆解 #

你观察到的三次触发，完全匹配Keras（基于TensorFlow后端的tf.function编译机制）的固定运行流程，三次触发分别对应：

1. 第一次触发：fit()方法启动后，首先抽取第一个训练小批量的数据，以Eager模式逐行执行一次call方法。这个阶段的核心目的是遍历所有层，根据输入张量的实际形状完成所有层的权重正式初始化，同时提前校验call逻辑的维度兼容性，避免训练启动后才暴露形状不匹配的报错。
2. 第二次触发：紧跟第一次Eager执行完成后，TensorFlow会启动静态图编译流程。为了提升训练速度，Keras会自动将Eager模式下执行的call方法逐操作解析，转换成可被硬件调度优化的静态计算图。这个编译过程会完整执行一次call方法的逻辑，追踪所有计算节点的依赖关系，把计算逻辑从Python层面迁移到优化过的C++运行时层。
3. 第三次触发：第一个epoch临近结束时，因为你传入了validation_data参数，Keras会自动在每个epoch训练完成后运行验证集的前向传播、计算验证指标。为了减少等待时间，Keras会在训练进度接近尾声时提前加载验证集数据，第一次传入验证集张量时，会再次触发一次静态图的追踪编译，对应你观察到的第三次打印输出。

后续训练不再触发call的原因 #

经过前面三次执行后，训练集前向、验证集前向对应的静态计算图已经全部编译完成。后续所有的批量训练、验证指标计算，都会直接调用已经优化好的静态图执行，不会再回退到Python层面逐行运行你编写的call方法代码。
这个过程不代表call的计算逻辑失效了，而是整个前向传播的逻辑已经被提前固化到了高效的静态执行图中——仅存在于Python层面的print这类副作用代码自然不会被触发，但核心的层间数据传递、张量计算逻辑和你在call中编写的内容完全一致。

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