实时视频处理的性能预算非常紧。30 FPS 时，每帧只有 33.3 ms；60 FPS 时更是只有 16.6 ms。摄像头采集、神经网络分割、Shader 执行和最终合成都必须在这个窗口内完成，否则就会出现丢帧、抖动和明显的交互延迟。
传统优化通常依赖人工阅读火焰图、修改 Swift、C++ 或 Metal 代码，再反复验证视觉效果。这种方式能够解决局部热点，却很难持续探索跨帧缓存、数据搬运、线程调度和框架 API 组合带来的系统性收益。AlphaEvolve 所代表的闭环进化优化方法，改变了搜索过程：云端模型生成候选代码，目标硬件上的评估器负责编译、运行、计分和淘汰。
这类方法的关键不在于让模型“猜一段更快的代码”，而在于构造一个不会被轻易钻空子的评估系统。
把生成和评估拆成两个循环
AlphaEvolve 的基本输入可以抽象为三个部分：
- 一个能够编译和运行的种子程序。
- 一个由开发者定义的评分函数。
- 一组候选代码的迭代搜索机制。
生成侧运行在托管云环境中，由 Gemini 模型组合、提示词采样器和程序数据库负责提出代码变体。评估侧则由开发者控制，运行在真实目标机器上，例如原生 macOS、Swift、Metal 和目标 Neural Engine 环境。
这种分离很重要。模型可以在云端扩大搜索规模，但只有本地评估器知道实际硬件上的编译结果、端到端延迟、内存行为以及画面是否仍然正确。评估器不必使用 Python，Swift、C++、Metal 或其他适合目标平台的语言都可以参与其中。
一个候选版本的生命周期大致如下：
- 模型根据种子程序和工程上下文生成代码变体。
- 本地评估器检查代码格式并编译候选版本。
- 候选程序处理固定的摄像头测试片段。
- 评估器记录每帧耗时、整体延迟和视觉质量。
- 不满足质量门槛的候选直接淘汰，其余候选按性能排序。
- 得分较高的代码进入下一代搜索。
这不是一次性的代码生成，而是一个以真实测量结果驱动的反馈回路。
评分函数决定搜索方向
进化搜索只会看到评分函数返回的数字。如果评分函数只奖励低延迟，模型自然会寻找最直接的捷径：跳过模糊渲染、直接返回原始帧，甚至减少实际处理工作量。这样的候选可能在基准里得到接近 0 ms 的成绩，却完全没有完成产品需求。
视频管线至少应同时检查性能和视觉保真度。SSIM 可以作为结构相似度指标，用来比较候选输出和人工确认过的 golden 输出。实践中还应该同时设置平均 SSIM 和最差帧 SSIM：平均值能够反映整体质量，最差帧则能抓住快速转头、遮挡变化或运动场景中的局部失败。
下面是一个可直接改造的 Python 质量门示例。它读取两个目录中的同名图片，输出平均 SSIM、最差帧 SSIM，并在画质不达标时返回非零退出码。安装依赖后即可运行：
python -m pip install pillow numpy scikit-image
python evaluate_ssim.py --golden ./golden --candidate ./candidate --min-mean 0.98 --min-worst 0.95
# evaluate_ssim.py
from __future__ import annotations
import argparse
import json
import sys
from pathlib import Path
import numpy as np
from PIL import Image
from skimage.metrics import structural_similarity
def load_gray(path: Path) -> np.ndarray:
with Image.open(path) as image:
return np.asarray(image.convert("L"), dtype=np.float32) / 255.0
def main() -> int:
parser = argparse.ArgumentParser()
parser.add_argument("--golden", type=Path, required=True)
parser.add_argument("--candidate", type=Path, required=True)
parser.add_argument("--min-mean", type=float, default=0.98)
parser.add_argument("--min-worst", type=float, default=0.95)
args = parser.parse_args()
golden_files = sorted(args.golden.glob("*.png"))
scores = []
for golden_path in golden_files:
candidate_path = args.candidate / golden_path.name
if not candidate_path.exists():
print(f"missing candidate frame: {candidate_path}", file=sys.stderr)
return 2
golden = load_gray(golden_path)
candidate = load_gray(candidate_path)
if golden.shape != candidate.shape:
print(f"shape mismatch: {golden_path.name}", file=sys.stderr)
return 2
score = structural_similarity(golden, candidate, data_range=1.0)
scores.append(float(score))
if not scores:
print("no PNG frames found", file=sys.stderr)
return 2
mean_ssim = float(np.mean(scores))
worst_ssim = float(np.min(scores))
passed = mean_ssim >= args.min_mean and worst_ssim >= args.min_worst
result = {
"frames": len(scores),
"mean_ssim": mean_ssim,
"worst_frame_ssim": worst_ssim,
"passed": passed,
}
print(json.dumps(result, indent=2))
return 0 if passed else 1
if __name__ == "__main__":
raise SystemExit(main())
在真实项目中，可以把这个脚本放在 Swift 候选程序之后执行，再把候选的每帧耗时加入结果。例如，评估器可以用下面的规则组合性能与质量：
speedup = baseline_ms_per_frame / candidate_ms_per_frame
if mean_ssim < 0.98 or worst_frame_ssim < 0.95:
return {"score": -1e12, "reason": "visual-quality-gate"}
return {
"score": speedup,
"speedup": speedup,
"mean_ssim": mean_ssim,
"worst_frame_ssim": worst_frame_ssim,
}
淘汰条件应当优先于性能排序。否则，一个画面已经失真的候选可能凭借极低延迟进入下一轮，污染后续搜索。
不要只测静态画面
测试片段决定了质量门能否发挥作用。静态背景、空摄像头画面和没有遮挡变化的素材，无法覆盖真实视频处理中最容易出错的情况。
测试集应该至少包含：
- 快速转头和大幅度肢体运动。
- 前景与背景颜色接近的场景。
- 遮挡、出画和重新进入画面的对象。
- 光照快速变化和运动模糊。
- 连续几帧模型置信度下降的片段。
仅检查平均 SSIM 也不够。候选程序可能在大多数静态帧上表现很好，却在一个关键动作帧中完全没有更新 mask。设置每帧最低 SSIM、最大连续失败帧数，或者直接保存失败帧，能够让搜索结果更接近生产质量。
给模型完整的框架上下文
如果提示词里只有一个孤立的逐帧回调，模型通常只能做局部微优化，例如内联函数、调整循环或减少临时对象。要发现真正的系统级优化，候选程序必须能够看到足够的工程上下文，包括：
- Swift、C++ 和 Metal 的公共接口。
- 帧生命周期和资源复用方式。
- 分割模型的输入输出格式。
- 可用的缓存、纹理和命令队列 API。
- 哪些状态可以跨帧保留，哪些状态必须严格重置。
跨帧状态尤其值得暴露。比如，候选代码可以维护有限时长的历史 mask、缓存时间戳或上一帧的追踪结果。这样，搜索空间就不再局限于“每一帧独立处理”，而是能够探索时序优化。
但状态也会带来明显风险。过于激进的 mask 缓存会让快速移动的对象产生拖影，缓存窗口过长还可能让背景变化无法及时反映。质量门应该把这些退化反馈给搜索过程，使模型在延迟收益和视觉稳定性之间寻找可接受的窗口，而不是由开发者手工猜一个固定参数。
用硬件下限判断优化空间
性能优化最容易陷入的误区，是只看相对加速比。一个候选版本快了 2 倍，并不代表它已经接近极限；也可能说明大量时间仍然浪费在内存分配、格式转换或线程切换上。
实时媒体管线的总耗时可以拆成两类：
- 可修改的软件开销：对象分配、buffer 格式转换、数据编组、线程上下文切换和 API 调度。
- 接近不可修改的硬件下限：神经网络推理、GPU Shader 计算以及显示同步。
可以构造一个 no-op 或 lower-bound 管线来估计物理下限。它应该尽量移除 Swift 或 C++ 的业务编排、数据转换和额外拷贝，只保留预热后的模型调用与最小 GPU pass，并在固定 dummy buffer 上运行。这个结果不是产品性能目标，而是判断剩余可优化空间的参考线。
一个简单的估算方式是：
可寻址优化空间 = 当前端到端耗时 - no-op 管线耗时
优化效率 = (当前耗时 - 候选耗时) / 可寻址优化空间
如果 no-op 管线已经占用了绝大部分预算，那么继续优化 Swift 调度代码的收益会很有限，应当转向模型、Shader、硬件并发或显示同步策略。反过来，如果 no-op 管线很快，而完整管线很慢，说明评估器应该重点鼓励减少数据搬运和框架调用摩擦。
落地时的检查清单
采用闭环进化优化前，可以逐项确认：
- 基线和候选版本使用完全相同的输入片段、分辨率和预热策略。
- 评估运行在实际目标硬件，而不是开发机上的近似环境。
- 评分同时包含端到端延迟、平均画质和最差帧质量。
- 评估器能够拒绝编译失败、崩溃、超时和缺失输出。
- 测试集覆盖运动、遮挡、光照变化和困难边界情况。
- 候选代码拥有足够的框架上下文，可以探索跨帧和系统级优化。
- no-op 管线已经测出硬件下限，团队知道当前剩余空间有多大。
- 每个被接受的候选都保留编译日志、性能数据、画质数据和输入版本。
AlphaEvolve 的价值不只是自动改写代码，而是把性能优化变成可重复的实验系统：云端负责扩大代码搜索，目标机器负责提供真实反馈，质量门负责守住产品行为边界。视频处理只是一个典型案例。同样的分离结构也可以用于微服务吞吐、数据库查询、ML 张量流水线和嵌入式系统，只要你能定义可靠的基准、可观测的评分以及不会被轻易绕过的质量约束。