tensorflow的tf.summary日志越积越大，根本原因是默认不丢弃旧数据且无采样频率限制；其事件文件为未压缩的protocol buffer二进制流，混杂高频标量、直方图等原始数据，尤其每步记录时单个文件可达数gb。
为什么TensorFlow的tf.summary日志会越积越大
默认用tf.summary.FileWriter（TF 1.x）或tf.summary.create_file_writer（TF 2.x）写入的日志，本质是Protocol Buffer序列化后的二进制文件（events.out.tfevents.*），里面混着大量高频标量、直方图、图像等原始数据。尤其当每步都记录loss、accuracy，又开了tf.summary.histogram，单个日志文件几GB很常见。
根本原因不是“没压缩”，而是“没节制”——TensorFlow默认不丢弃旧数据，也不对采样频率做限制。
控制日志体积的三个实操手段
不用改框架，靠调整写入策略就能压掉80%以上体积：
-
降低记录频率：别每
step都记。用step % 100 == 0控制标量记录，直方图降到step % 1000 == 0；TF 2.x中可直接传step=step参数，配合条件判断 -
关闭非必要摘要类型：图像（
tf.summary.image）、音频（tf.summary.audio）、计算图（tf.summary.trace）体积极大，调试期关掉；直方图比标量贵一个数量级，确认分布异常时再开 -
精简summary name和tag：避免在name里拼接
layer_123/weights这种长路径；重复记录同一指标时，用family="loss"归组，减少元数据冗余
TF 2.x中用tf.summary.record_if动态开关
比写if判断更干净，且能避免tensor构建开销：
with tf.summary.record_if(step % 100 == 0):
tf.summary.scalar('train_loss', loss, step=step)
tf.summary.scalar('lr', lr, step=step)
<h1>直方图只在验证阶段记录</h1><p>with tf.summary.record_if(is_validation and step % 500 == 0):
tf.summary.histogram('gradients', grads, step=step)
</p>
注意：record_if的条件必须是Python bool或可静态判断的tensor，不能是依赖运行时值的tf.cond，否则可能失效。
日志目录清理与迁移建议
TensorBoard本身不删旧文件，得自己动手：
- 训练脚本末尾加
!rm -rf ./logs/train_old（慎用）或用shutil.rmtree安全删除 - 用
tensorboard --logdir_spec把多个小目录映射到同一视图，避免单目录膨胀；例如train_v1:./logs/v1,train_v2:./logs/v2 - 长期项目建议用
gs://bucket/logs/替代本地路径，GCS自动支持生命周期规则（如7天后转冷存储）
真正难处理的是已经生成的大日志——tensorboard dev upload会上传全部内容，上传前务必先用tensorboard --inspect确认事件数，超100万step的目录建议先用grep -a "loss" events.* | head -n 1000抽样检查，再决定是否重训。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
