kornia 数据增强基准Augmentation Benchmarks完全指南跨库吞吐对比、可复现方法与性能基线解读【免费下载链接】kornia 空间人工智能的几何计算机视觉库项目地址: https://gitcode.com/kornia/kornia本文是 kornia 仓库中 benchmarks/augmentation/README.md 的深度解读与实战手册围绕数据增强栈的可复现吞吐基准展开。文中完整继承原文档的四个基准脚本、运行命令、实测快照与已知改进清单并深入对应的 benchmarks/augmentation/ 源码与 benchmarks/common.py 方法论实现帮助读者理解每个数字背后的测法、每个结论背后的证据并能在自己的机器上复现、对比与贡献结果。套件概览四个脚本的分工与定位kornia 的增强基准套件由四个脚本组成分别回答不同粒度的问题。下表与原文档一致明确了每个脚本的测量对象脚本测量内容flagship.py旗舰套件——增强算子通过各库的随机变换类 API 进行基准测试包含参数采样与 torchvision v2、albumentations、OpenCV/PIL在可比场景下对比共享 benchmarks/common.py 方法论支持--json导出。取代旧脚本all_libraries.py。vs_torchvision.py逐算子对比 korniaeager 与torch.compilevs torchvision v2输出best/tv比值与每个算子的胜负判定。cross_library.py聚焦的逐算子三方对比kornia vs torchvision v2 vs albumentations。pipeline.py端到端多算子管线吞吐训练循环实际运行的形态支持--compile与--halffp16/AMP。从源码可以进一步确认定位flagship.py的模块文档字符串强调按增强的方式测增强——即通过用户面向的随机变换类kornia 的forward_parameters apply、torchvision v2 变换对象、albumentations 变换来计时而不是底层确定性函数。变换对象在计时区外只构造一次计时区 参数采样 应用。pipeline.py则明确指出它测量的是 kornia 设计上要领先的范式GPU 批量、可微、端到端编译的增强管线。快速上手运行命令与 CLI 参数详解原文档给出的标准运行方式python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --device cpu --compile python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --device cuda --compile --json aug_cuda.json python benchmarks/augmentation/pipeline.py --batch 32 --size 224 --device cuda --compile每个脚本都会打印 git commit、平台信息以及在 CUDA 上设备名称遵循 benchmarks/README.md 中的方法论契约。未安装的可选库会以 skip 行报告而不是让运行失败。结合flagship.py源码benchmarks/augmentation/flagship.pyflagship.py的完整参数如下参数默认值说明--batches1,8,32逗号分隔的批次大小扫描--size256图像边长宽高同为该值--devicecpu运行设备如cpu/cuda/mps--dtypefloat32可选float32/float16/bfloat16--threads4PyTorch 线程数通过torch.set_num_threads设置--compile关额外计时torch.compile后的 kornia--skip-compile-ops空逗号分隔的算子名保持 eager-only用于绕过有故障的编译内核例如 CUDA illegal memory access--json无将机器可读结果写入该路径--contribute无把本次运行写入DIR/kornia-version/suite--machine--device.json用于提交--machine-slug无覆盖文件名中的自动检测机器名pipeline.py与vs_torchvision.py、cross_library.py的参数更轻量pipeline.py支持--batch默认 32、--size默认 224、--device、--threads、--compile、--half以 float16 运行即 AMP 训练范式vs_torchvision.py支持--batch32、--size224、--device、--threads默认 1配合其手动 warmup 循环计时策略cross_library.py支持--batch32、--size256、--device、--threads4。跨库算子映射等价的变换如何对应flagship.py的模块文档中给出了八个算子在各库中的等价映射这也是同等参数、同等插值公平对比的具体落点kornia.augmentationtorchvision.transforms.v2albumentationsopencvPILRandomHorizontalFlipRandomHorizontalFlipHorizontalFlipcv2.flipImage.transposeRandomAffineRandomAffineAffine——RandomPerspectiveRandomPerspectivePerspective——RandomResizedCropRandomResizedCropRandomResizedCrop——ColorJiggleColorJitterColorJitter——RandomGaussianBlurGaussianBlurGaussianBlur——RandomBrightnessColorJitter(brightness)RandomBrightnessContrast——RandomGrayscaleRandomGrayscaleToGraycv2.cvtColorconvert(L)OpenCV 与 PIL 只在无随机参数flip、grayscale的算子上出现对于随机参数化增强albumentations 本身就是 OpenCV 后端基线。PIL 通常最慢但作为信号处理正确性的参考实现。各库参数分布在精神上匹配但参数化并不完全相同如透视失真尺度因此各列是范式对比而非逐位精确的竞赛。RandomResizedCrop 在所有后端统一输出size//2边长吞吐量以输入图像 img/s 计。方法论契约让每个数字可复现、可引用原文档强调基准的初衷是诚实、持久的基线——让每个性能区间可测量给后续工作一个明确的改进目标。这依赖于 benchmarks/README.md 中定义、并由 benchmarks/common.py 实现的方法论契约。这些规则是评估任何基准数字前必读的前提Warmup 重复统一用common.time_us(fn)计时它包装torch.utils.benchmark.Timer.blocked_autorange——预热、多次重复、报告中位数墙钟时间time_us额外返回IQR作为离散度。绝不允许只测一次。从源码看benchmarks/common.pytime_us返回(median*1e6, iqr*1e6)函数抛异常时返回(nan, nan)调用方据此渲染 skip 单元格而不是崩溃。线程一致性time_us用当前torch.get_num_threads()计时与预热和元数据一致。该修复之前的旧结果用Timer默认的单线程计时即使元数据标称更大的线程数——因此历史文件不能解读为在声明线程数下的测量值。持续 CPU 预热设置线程数后调用一次common.warm_up_cpu()。混合 CPU性能核 能效核在轻负载时把线程放在能效核上只有持续负载才会迁移到性能核而 WSL2 无法固定它们。在 i7-14700K 上该预热让 5x5 oneDNN 卷积从 0.56 ms 降到 0.22 ms而切片类滤波几乎不变——不预热可能导致 A/B 结论反转。源码实现为warm_up_cpu(seconds3.0)循环执行 1024×1024 矩阵乘持续约 3 秒。Checkout 溯源filters 与 augmentation 旗舰脚本从自己的 checkout 导入 kornia 并打印源码路径。直接执行脚本绝不能静默地测了已安装 wheel 或其他 editable checkout却记录当前树的 commit。flagship.py中通过sys.path.insert(0, str(Path(__file__).resolve().parents[2]))优先使用当前 checkout并打印# Kornia source: ...。计时区内的设备同步blocked_autorange同步 CUDAMPS 需向time_us传入synctorch.mps.synchronize。手写time.time()包住 GPU 调用测到的是启动延迟不是工作量。固定种子固定所有 RNGtorch.manual_seed、np.random.default_rng(0)保证同一软件栈上逐位可复现。flagship.py同时固定了np.random.seed(0)albumentations 从全局 RNG 采样与random.seed(0)。记录元数据每个结果文件嵌入common.run_metadata(device)——日期、git commit、平台、Python/torch/kornia 版本、设备CUDA 含设备名与版本、线程数与基线库版本。从源码看run_metadata还会尝试记录 opencv/torchvision/numpy/albumentations/kornia_rs/PIL/skimage 的版本。版本 commit 标识一次运行而不是日期一个kornia-version目录跨越多个 commit快照可能带着当前版本和近期时间戳却测着已不存在的实现。引用数字时必须同时引用kornia与git_commit。git_commit()实现会追加-dirty标记忽略未跟踪文件避免--contribute写入的结果文件把每次贡献运行都标脏。淘汰过时快照当合并的改动改变了某个已提交快照所测算子的速度时需要重新测量该机器硬件不可得时把运行移到benchmarks/results/superseded/version/并在该目录 README 中登记。详见下文历史结果一节与 benchmarks/results/superseded/README.md。机器可读导出支持--json PATH并通过common.save_json写入——严格合法 JSONNaN→null结构为{metadata: {...}, results: [...]}键排序以满足 pre-commit 的 pretty-format-json 钩子。同等条件 诚实范式跨后端使用相同变换参数与插值明确陈述各后端的范式批量 float 张量 vs 逐图像 uint8 循环而不是假装各列可以直接对比。胜与负都要发布。只测公共 API按用户调用的方式测kornia.*——不用私有辅助函数不在脚本里重新实现。JSON 导出格式benchmarks/README.md 给出了每次运行一个文件的 JSON 结构示例{ metadata: { timestamp_utc: 2026-08-07T17:58:1200:00, git_commit: 407b6dce, platform: macOS-26.5.1-arm64-arm-64bit, machine: arm64, python: 3.11.14, torch: 2.9.1, kornia: 0.9.0rc1, device: cpu, torch_num_threads: 4, opencv: 4.11.0, torchvision: null, numpy: 2.4.0 }, results: [ { op: warp_perspective, backend: kornia (eager), batch: 8, height: 256, width: 256, dtype: float32, median_us: 1983.4, iqr_us: 12.1, throughput_per_s: 4033.5 } ] }throughput_per_s统计每秒条目数——图像算子按图像数get_perspective_transform按点集求解数null表示测量失败后端抛异常。此外run_batch_sweep会把编译预热失败记录为结果行median_us/iqr_us/throughput_per_s为nullerror字段记录异常名使失败在 JSON 中可见而不只是控制台 NOTE。实测快照Intel i7-14700K RTX 4090PR #4659 合并后原文档记录了 2026-09-18 的实测快照环境为Kornia 0.9.0rc1commit5f96e3caCPU/5f96e3ca-dirtyCUDA仅含待提交的基准结果、文档与导出测试跳过运行时与基准框架与5f96e3ca一致包含已合并的 PR #46591eb06974WSL2Python 3.11.14PyTorch 2.14.0cu130四个 PyTorch 线程float32 RGB 256×256批次 1/8/32。两次运行都使用公开随机变换类、包含参数采样与分配、校验 checkout 导入、扫描前预热 CPU 工作线程。CPU 与 CUDA 顺序执行。计时使用共享blocked_autorange辅助函数至少 1 秒 CUDA 同步。全部套件基线已安装torchvision 0.29.0cu130、albumentations 2.0.8、OpenCV 4.11.0、Pillow 12.3.0。完整行、计时 IQR 与元数据见 CPU JSON 与 CUDA JSON。这是单次运行快照不是主分支对 PR 的对比。下表是 batch 32、以输入图像 img/s 计数值越大越好JSON 中还包含所有跨库基线操作CPU eagerCPU compiledCUDA eagerCUDA compiledRandomHorizontalFlip36,89727,724469,309439,993RandomAffine6,2072,8197,75449,545RandomPerspective2,4232,42416,48451,682RandomResizedCrop14,96611,84817,39074,338ColorJiggle3141,33712,70340,025RandomGaussianBlur1,5441,43947,015224,664RandomBrightness16,14330,413149,602188,938RandomGrayscale21,29832,669177,511464,424在该 batch-32 切片中编译使 CUDA 高斯模糊提升 4.78 倍、ColorJiggle 提升 3.15 倍但也有输的CPU 高斯模糊只有 eager 的 0.93 倍、CPU 水平翻转 0.75 倍、CPU affine 仅 0.45 倍。对比 CPU uint8 循环与批量 float 张量之前务必参考 JSON 中的所有基线列与下文运行范式一节。RandomResizedCrop 修复后的表现修复后的 RandomResizedCrop输入图像 img/sBatchCPU eagerCPU compiledCUDA eagerCUDA compiled12,6935,3401,0012,261810,83115,2125,95016,3793214,96611,84817,39074,338所有 24 行编译后的 kornia 行每设备均无编译失败或重编译上限警告。旧的 Kornia 0.9.0rc1 快照CPU 在d579a572、CUDA 在43cf6b46在 batch 8/32 时约 1–2 img/s同时反复编译 crop 参数——那些快照已被替换。新的 CPU batch-32 编译 crop 仍慢于 eager修复重编译并不让编译成为所有负载的最快选择。其他运行间差异不应归因于 #4659这些是独立快照不是交错 A/B 实验。PR #4659 修复了什么PR #4659 修复了 crop 参数重编译与共享增强编译缓存缺陷跟踪于 #4658。修复前的编译 crop 行测的是编译风暴而非稳态吞吐。在 Apple M1 Pro 上编译的RandomResizedCrop行从 batch 1/8/32 时的 1/2/2 img/s 提升到 CPU 的 2459/6180/8290MPS 从 555/3/failed 提升到 645/4864/17620batch 8 的 40 次调用 trace 之前会触发六次 1.3–5.6 秒的编译现在不再编译任何新图。复现该快照的命令python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --threads 4 --device cpu --compile --json aug_cpu.json python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --threads 4 --device cuda --compile --json aug_cuda.json理解运行范式为什么数字不能横向直接比较原文档用一个关键表格说明各库解决的不是同一个问题把某一列读成赢家是有误导性的。每个库的操作对象如下库数据批量设备可微korniafloatBCHW张量✅ 批量CPU或 GPU✅ 是torchvision v2floatBCHW张量✅ 批量CPU 或 GPU❌ 否albumentationsuint8HWCnumpy❌ 逐图像循环仅 CPU❌ 否OpenCVcv2uint8HWCnumpy❌ 逐图像循环仅 CPU❌ 否PILPillowuint8HWC图像❌ 逐图像循环仅 CPU❌ 否kornia-rsuint8HWCnumpy❌ 逐图像仅 CPU原生 Rust❌ 否由此产生两场不同的竞赛CPU /uint8/ 单图像——albumentations、OpenCV、PIL 与 kornia-rs 在此区间。这是经典的数据加载器范式SIMD/原生后端获胜。kornia 的float路径不是为它而建的不应期望领先。GPU /float/ 批量 / 可微——kornia 的主场。torchvision v2 在原始速度上竞争但不可微其他库根本无法运行在此区间。这正是 kornia 设计上要领先的范式也是torch.compile融合最能发挥价值的地方。flagship.py的源码进一步印证kornia 与 torchvision 跑批量 float BCHW 张量CPU 或 GPUalbumentations/OpenCV/PIL 在 CPU 上用 Python 循环跑单张 uint8 HWC 图像它们原生的范式。pipeline.py的 docstring 也强调目的不是赢得 CPU/uint8 单图像竞赛albumentations 拥有该区间这正是计划中kornia-rs后端要针对的而是量化 kornia 领先的 GPU 批量可微编译管线。历史样本结果all_libraries.py2026-08-08 淘汰下表由已淘汰的逐算子脚本all_libraries.py测得确定性参数、albumentations 变换在计时循环内构造、含 PIL/kornia-rs 列它早于共享common.py方法论与 JSON 导出。全新旗舰数字见根级 benchmarks/README.md脚本本身保留在 git 历史中。仅作方向性数字——任何引用的数字请在自己的硬件上复现。在 NVIDIA Jetson Orinaarch64、torch 2.10、CPU、batch 8、128×128、吞吐单位img/s越高越好上测得opkornia (eager)kornia (compiled)torchvision v2albumentationsOpenCVPILkornia-rsHorizontalFlip12269302623714744981568461817465304VerticalFlip14088273194658444971459222063472195Resize (½)207939615892284045657381275643GaussianBlur978194912187515266–62848Brightness82752574626425265722872–173588Grayscale765532267315023497673271678915492这个切片CPU说明了什么kornia-rs 在多数算子上是最快的 CPU/uint8后端——在 Resize、GaussianBlur 与 Brightness 上超过 OpenCV仅在两个单次内存遍历翻转或融合色彩归约灰度算子上落后。这是计划中可选kornia-rs增强后端roadmap的证据kornia 已通过其 Rust 姊妹项目提供了最快的 CPU 内核——剩下的是 API 集成工作而不是内核速度问题。torch.compile是 kornia 逐点算子的 CPU 杠杆——Brightness 8.3k → 25.7k3.1 倍、Grayscale 7.7k → 32.3k4.2 倍缩小或追平了与 torchvision 的差距。它对 CPU 上卷积受限的算子没有帮助GaussianBlur 反而回退——编译/启动开销超过了微小的内核。GPUNVIDIA Jetson Orin、torch 2.10、--device cuda、batch 32、256×256、img/s。uint8单图像后端仅支持 CPU为参考重复列出opkornia (eager)kornia (compiled)torchvision v2OpenCVkornia-rsHorizontalFlip11458✗521202213432284VerticalFlip10599✗506012268329592Resize (½)✗ nan✗261492114540773GaussianBlur47410426904834219336Brightness6538122842978540449621Grayscale190622477742555182114698GPU 行的解读——请阅读 Jetson 注意事项不要把它当作数据中心结果compiled 列的✗是Jetson wheel 限制不是 kornia 缺陷torch.compile在 Orin 的 torch 2.10 CUDA 构建上对若干算子报错CUDA driver error: invalid argument因此 compiled 行不可用。Resize的 eagernan是同一回事——Orin wheel 的cusolver损坏get_perspective_transform的线性求解在设备上失败。在正常数据中心CUDA wheel 上两者都能工作Orin 在这里只是低估了kornia。在设备上 compile可用的地方Brightness、GaussianBlur、Grayscale它带来了预期的 eager 2–4 倍提升torchvision v2 在批量 float 吞吐上领先——与包装开销发现一致廉价算子的 GPU forward 约 78% 是基类编排而非内核见下文改进清单。该 Orin 机型是本项目 GPU 基准的标准目标——所有 GPU 数字都用--device cuda在此运行并报告上述两个注意事项而不是省略行。被淘汰快照的管理原则benchmarks/results/superseded/README.md 说明了过时快照的处理保留用于历史但不再发布docs/generate_benchmarks.py会跳过该树。关键规则是快照由其 kornia 版本与git_commit标识永远不是日期——一个版本目录跨越许多 commit。当合并改动改变了某个快照所测算子的速度且机器无法重新测量时把运行移到benchmarks/results/superseded/version/并登记是哪次改动使其过时硬件可得时应重新测量。例如增强类的RandomGaussianBlur委托给kornia.filters.gaussian_blur2d因此 #4647 的滤波器加速也移动了增强数字——若把旧文件与 #4647 后的运行并排发布会被误读为硬件差异。已知改进机会清单稍后改进列表原文档给出了具体、经过测量的杠杆大致按杠杆率排序。每一条都是这个基线可以移动的地方廉价算子的包装开销GPU。性能分析显示 GPURandomHorizontalFlipforward 约 78% 是逐次调用的基类编排变换矩阵构造、where混合、dtype/shape 簿记——不是内核。杠杆是更精简、完全可torch.compile的基类forward加上 CUDA-graph 捕获而不是更快的内核。已部分处理p 1变换矩阵快速路径CUDA-graph 捕获是下一步。kornia-rsCPU/uint8后端。上表显示 kornia-rs 已领先 CPU 竞赛。可选的backendrust选择器把不可微的 CPUuint8增强路由到kornia_rs.imgproc将让 kornia 在数据加载器范式也成为最快选项——这是 API 集成问题不是内核问题。面向少数内核受限算子的 Triton 内核。针对inductor无法融合的算子融合 warp 采样器warp_affine/grid_sample/remap所有几何增强都经过它、median_blur、equalize/直方图、双边/引导滤波、形态学。逐点算子留在inductor上在那里重写 Triton 只是重新推导编译器已产出的东西。注意kornia 的依赖策略是仅 PyTorch因此核心 Triton 内核是刻意的可选依赖决策不是即插即用。float 管线中的uint8快速路径减少让批量路径在廉价算子上输给原生uint8后端的float↔uint8转换。端到端编译管线。pipeline.py已显示编译后的 kornia 管线在 CPU 上超过 torchvision v2 并达到 albumentations 同级别剩余收益是让整个管线包括参数生成保持 fullgraph从而能捕获进 CUDA graph。原文档还给出了工作流约定改进其中任一条后重新运行相关脚本把新数字放入 PR 描述若改动持久用新硬件更新上面的样本表。pipeline.py中编译管线的具体构造是参考所有算子p1.0以保证确定性、公平地计时应用的工作量并给ColorJitter固定order[0, 1, 2, 3]使整个管线可 fullgraph 编译——这正是改进清单第 5 条参数生成也 fullgraph的现状基线。如何在新机器上贡献基准结果benchmarks/README.md 给出了任何机器都可遵循的贡献流程该 README 也是所有新增基准的方法论总纲检出你要测量的 release tag。让机器安静关闭其他应用、接市电、让其冷却。文件中只记录聚合负载数字load average、内存绝不记录进程或应用名——collect_load_metrics源码也印证了这一点隐私保护设计只有数字没有名称。用--contribute运行各套件多数套件是flagship.py非旗舰的脚本在目录图中标明如feature/laf_ops.pypython benchmarks/augmentation/flagship.py --device cuda --contribute benchmarks/results运行落盘到benchmarks/results/kornia-version/suite--machine--device.json可用--machine-slug覆盖机器名。common.py的canonical_result_name用设备类型去掉冒号后缀生成文件名。提交文件并开 PR。CI 用 benchmarks/results_schema.py 校验 schema文档页与 llms digest 在下次文档构建时自动重新生成python docs/generate_benchmarks.py --refresh-llms刷新已提交的 digest。对比工件base-vs-branch A/B 或跨版本对比不是发布快照它们记录的是一个必然不是当前树的修订因此不放进benchmarks/results/kornia-version/也不进入文档性能页。此类原始 JSON 应放在引用它的报告旁的benchmarks/area/name_results/*.json例如 benchmarks/feature/graf_results/按对比的修订或系列命名CI 用results_schema.validate_artefact校验——与发布快照相同的信封、元数据、隐私与行类型规则只是放宽文件名与版本目录规则且load可选base 修订的 harness 可能早于该字段。结语把数字当作可检验的证据kornia 增强基准套件的设计哲学贯穿始终发布胜也发布负陈述范式而非假装逐列可比用 commit 版本标识运行而非日期。无论是评估torch.compile是否值得CPU 逐点算子往往值得、卷积受限算子经常回退、判断某个算子是否是需要优化的薄弱点历史上ColorJiggle、RandomResizedCrop的编译问题均由此暴露还是验证一次重构是否真的变快#4659 对 crop 编译风暴的修复这套脚本与 benchmarks/common.py 提供的方法论都能给出可复现、可引用的答案。在你自己的硬件上运行本文列出的命令即可把这份基线延续到你的环境中。【免费下载链接】kornia 空间人工智能的几何计算机视觉库项目地址: https://gitcode.com/kornia/kornia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kornia 数据增强基准（Augmentation Benchmarks）完全指南：跨库吞吐对比、可复现方法与性能基线解读
kornia 数据增强基准Augmentation Benchmarks完全指南跨库吞吐对比、可复现方法与性能基线解读【免费下载链接】kornia 空间人工智能的几何计算机视觉库项目地址: https://gitcode.com/kornia/kornia本文是 kornia 仓库中 benchmarks/augmentation/README.md 的深度解读与实战手册围绕数据增强栈的可复现吞吐基准展开。文中完整继承原文档的四个基准脚本、运行命令、实测快照与已知改进清单并深入对应的 benchmarks/augmentation/ 源码与 benchmarks/common.py 方法论实现帮助读者理解每个数字背后的测法、每个结论背后的证据并能在自己的机器上复现、对比与贡献结果。套件概览四个脚本的分工与定位kornia 的增强基准套件由四个脚本组成分别回答不同粒度的问题。下表与原文档一致明确了每个脚本的测量对象脚本测量内容flagship.py旗舰套件——增强算子通过各库的随机变换类 API 进行基准测试包含参数采样与 torchvision v2、albumentations、OpenCV/PIL在可比场景下对比共享 benchmarks/common.py 方法论支持--json导出。取代旧脚本all_libraries.py。vs_torchvision.py逐算子对比 korniaeager 与torch.compilevs torchvision v2输出best/tv比值与每个算子的胜负判定。cross_library.py聚焦的逐算子三方对比kornia vs torchvision v2 vs albumentations。pipeline.py端到端多算子管线吞吐训练循环实际运行的形态支持--compile与--halffp16/AMP。从源码可以进一步确认定位flagship.py的模块文档字符串强调按增强的方式测增强——即通过用户面向的随机变换类kornia 的forward_parameters apply、torchvision v2 变换对象、albumentations 变换来计时而不是底层确定性函数。变换对象在计时区外只构造一次计时区 参数采样 应用。pipeline.py则明确指出它测量的是 kornia 设计上要领先的范式GPU 批量、可微、端到端编译的增强管线。快速上手运行命令与 CLI 参数详解原文档给出的标准运行方式python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --device cpu --compile python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --device cuda --compile --json aug_cuda.json python benchmarks/augmentation/pipeline.py --batch 32 --size 224 --device cuda --compile每个脚本都会打印 git commit、平台信息以及在 CUDA 上设备名称遵循 benchmarks/README.md 中的方法论契约。未安装的可选库会以 skip 行报告而不是让运行失败。结合flagship.py源码benchmarks/augmentation/flagship.pyflagship.py的完整参数如下参数默认值说明--batches1,8,32逗号分隔的批次大小扫描--size256图像边长宽高同为该值--devicecpu运行设备如cpu/cuda/mps--dtypefloat32可选float32/float16/bfloat16--threads4PyTorch 线程数通过torch.set_num_threads设置--compile关额外计时torch.compile后的 kornia--skip-compile-ops空逗号分隔的算子名保持 eager-only用于绕过有故障的编译内核例如 CUDA illegal memory access--json无将机器可读结果写入该路径--contribute无把本次运行写入DIR/kornia-version/suite--machine--device.json用于提交--machine-slug无覆盖文件名中的自动检测机器名pipeline.py与vs_torchvision.py、cross_library.py的参数更轻量pipeline.py支持--batch默认 32、--size默认 224、--device、--threads、--compile、--half以 float16 运行即 AMP 训练范式vs_torchvision.py支持--batch32、--size224、--device、--threads默认 1配合其手动 warmup 循环计时策略cross_library.py支持--batch32、--size256、--device、--threads4。跨库算子映射等价的变换如何对应flagship.py的模块文档中给出了八个算子在各库中的等价映射这也是同等参数、同等插值公平对比的具体落点kornia.augmentationtorchvision.transforms.v2albumentationsopencvPILRandomHorizontalFlipRandomHorizontalFlipHorizontalFlipcv2.flipImage.transposeRandomAffineRandomAffineAffine——RandomPerspectiveRandomPerspectivePerspective——RandomResizedCropRandomResizedCropRandomResizedCrop——ColorJiggleColorJitterColorJitter——RandomGaussianBlurGaussianBlurGaussianBlur——RandomBrightnessColorJitter(brightness)RandomBrightnessContrast——RandomGrayscaleRandomGrayscaleToGraycv2.cvtColorconvert(L)OpenCV 与 PIL 只在无随机参数flip、grayscale的算子上出现对于随机参数化增强albumentations 本身就是 OpenCV 后端基线。PIL 通常最慢但作为信号处理正确性的参考实现。各库参数分布在精神上匹配但参数化并不完全相同如透视失真尺度因此各列是范式对比而非逐位精确的竞赛。RandomResizedCrop 在所有后端统一输出size//2边长吞吐量以输入图像 img/s 计。方法论契约让每个数字可复现、可引用原文档强调基准的初衷是诚实、持久的基线——让每个性能区间可测量给后续工作一个明确的改进目标。这依赖于 benchmarks/README.md 中定义、并由 benchmarks/common.py 实现的方法论契约。这些规则是评估任何基准数字前必读的前提Warmup 重复统一用common.time_us(fn)计时它包装torch.utils.benchmark.Timer.blocked_autorange——预热、多次重复、报告中位数墙钟时间time_us额外返回IQR作为离散度。绝不允许只测一次。从源码看benchmarks/common.pytime_us返回(median*1e6, iqr*1e6)函数抛异常时返回(nan, nan)调用方据此渲染 skip 单元格而不是崩溃。线程一致性time_us用当前torch.get_num_threads()计时与预热和元数据一致。该修复之前的旧结果用Timer默认的单线程计时即使元数据标称更大的线程数——因此历史文件不能解读为在声明线程数下的测量值。持续 CPU 预热设置线程数后调用一次common.warm_up_cpu()。混合 CPU性能核 能效核在轻负载时把线程放在能效核上只有持续负载才会迁移到性能核而 WSL2 无法固定它们。在 i7-14700K 上该预热让 5x5 oneDNN 卷积从 0.56 ms 降到 0.22 ms而切片类滤波几乎不变——不预热可能导致 A/B 结论反转。源码实现为warm_up_cpu(seconds3.0)循环执行 1024×1024 矩阵乘持续约 3 秒。Checkout 溯源filters 与 augmentation 旗舰脚本从自己的 checkout 导入 kornia 并打印源码路径。直接执行脚本绝不能静默地测了已安装 wheel 或其他 editable checkout却记录当前树的 commit。flagship.py中通过sys.path.insert(0, str(Path(__file__).resolve().parents[2]))优先使用当前 checkout并打印# Kornia source: ...。计时区内的设备同步blocked_autorange同步 CUDAMPS 需向time_us传入synctorch.mps.synchronize。手写time.time()包住 GPU 调用测到的是启动延迟不是工作量。固定种子固定所有 RNGtorch.manual_seed、np.random.default_rng(0)保证同一软件栈上逐位可复现。flagship.py同时固定了np.random.seed(0)albumentations 从全局 RNG 采样与random.seed(0)。记录元数据每个结果文件嵌入common.run_metadata(device)——日期、git commit、平台、Python/torch/kornia 版本、设备CUDA 含设备名与版本、线程数与基线库版本。从源码看run_metadata还会尝试记录 opencv/torchvision/numpy/albumentations/kornia_rs/PIL/skimage 的版本。版本 commit 标识一次运行而不是日期一个kornia-version目录跨越多个 commit快照可能带着当前版本和近期时间戳却测着已不存在的实现。引用数字时必须同时引用kornia与git_commit。git_commit()实现会追加-dirty标记忽略未跟踪文件避免--contribute写入的结果文件把每次贡献运行都标脏。淘汰过时快照当合并的改动改变了某个已提交快照所测算子的速度时需要重新测量该机器硬件不可得时把运行移到benchmarks/results/superseded/version/并在该目录 README 中登记。详见下文历史结果一节与 benchmarks/results/superseded/README.md。机器可读导出支持--json PATH并通过common.save_json写入——严格合法 JSONNaN→null结构为{metadata: {...}, results: [...]}键排序以满足 pre-commit 的 pretty-format-json 钩子。同等条件 诚实范式跨后端使用相同变换参数与插值明确陈述各后端的范式批量 float 张量 vs 逐图像 uint8 循环而不是假装各列可以直接对比。胜与负都要发布。只测公共 API按用户调用的方式测kornia.*——不用私有辅助函数不在脚本里重新实现。JSON 导出格式benchmarks/README.md 给出了每次运行一个文件的 JSON 结构示例{ metadata: { timestamp_utc: 2026-08-07T17:58:1200:00, git_commit: 407b6dce, platform: macOS-26.5.1-arm64-arm-64bit, machine: arm64, python: 3.11.14, torch: 2.9.1, kornia: 0.9.0rc1, device: cpu, torch_num_threads: 4, opencv: 4.11.0, torchvision: null, numpy: 2.4.0 }, results: [ { op: warp_perspective, backend: kornia (eager), batch: 8, height: 256, width: 256, dtype: float32, median_us: 1983.4, iqr_us: 12.1, throughput_per_s: 4033.5 } ] }throughput_per_s统计每秒条目数——图像算子按图像数get_perspective_transform按点集求解数null表示测量失败后端抛异常。此外run_batch_sweep会把编译预热失败记录为结果行median_us/iqr_us/throughput_per_s为nullerror字段记录异常名使失败在 JSON 中可见而不只是控制台 NOTE。实测快照Intel i7-14700K RTX 4090PR #4659 合并后原文档记录了 2026-09-18 的实测快照环境为Kornia 0.9.0rc1commit5f96e3caCPU/5f96e3ca-dirtyCUDA仅含待提交的基准结果、文档与导出测试跳过运行时与基准框架与5f96e3ca一致包含已合并的 PR #46591eb06974WSL2Python 3.11.14PyTorch 2.14.0cu130四个 PyTorch 线程float32 RGB 256×256批次 1/8/32。两次运行都使用公开随机变换类、包含参数采样与分配、校验 checkout 导入、扫描前预热 CPU 工作线程。CPU 与 CUDA 顺序执行。计时使用共享blocked_autorange辅助函数至少 1 秒 CUDA 同步。全部套件基线已安装torchvision 0.29.0cu130、albumentations 2.0.8、OpenCV 4.11.0、Pillow 12.3.0。完整行、计时 IQR 与元数据见 CPU JSON 与 CUDA JSON。这是单次运行快照不是主分支对 PR 的对比。下表是 batch 32、以输入图像 img/s 计数值越大越好JSON 中还包含所有跨库基线操作CPU eagerCPU compiledCUDA eagerCUDA compiledRandomHorizontalFlip36,89727,724469,309439,993RandomAffine6,2072,8197,75449,545RandomPerspective2,4232,42416,48451,682RandomResizedCrop14,96611,84817,39074,338ColorJiggle3141,33712,70340,025RandomGaussianBlur1,5441,43947,015224,664RandomBrightness16,14330,413149,602188,938RandomGrayscale21,29832,669177,511464,424在该 batch-32 切片中编译使 CUDA 高斯模糊提升 4.78 倍、ColorJiggle 提升 3.15 倍但也有输的CPU 高斯模糊只有 eager 的 0.93 倍、CPU 水平翻转 0.75 倍、CPU affine 仅 0.45 倍。对比 CPU uint8 循环与批量 float 张量之前务必参考 JSON 中的所有基线列与下文运行范式一节。RandomResizedCrop 修复后的表现修复后的 RandomResizedCrop输入图像 img/sBatchCPU eagerCPU compiledCUDA eagerCUDA compiled12,6935,3401,0012,261810,83115,2125,95016,3793214,96611,84817,39074,338所有 24 行编译后的 kornia 行每设备均无编译失败或重编译上限警告。旧的 Kornia 0.9.0rc1 快照CPU 在d579a572、CUDA 在43cf6b46在 batch 8/32 时约 1–2 img/s同时反复编译 crop 参数——那些快照已被替换。新的 CPU batch-32 编译 crop 仍慢于 eager修复重编译并不让编译成为所有负载的最快选择。其他运行间差异不应归因于 #4659这些是独立快照不是交错 A/B 实验。PR #4659 修复了什么PR #4659 修复了 crop 参数重编译与共享增强编译缓存缺陷跟踪于 #4658。修复前的编译 crop 行测的是编译风暴而非稳态吞吐。在 Apple M1 Pro 上编译的RandomResizedCrop行从 batch 1/8/32 时的 1/2/2 img/s 提升到 CPU 的 2459/6180/8290MPS 从 555/3/failed 提升到 645/4864/17620batch 8 的 40 次调用 trace 之前会触发六次 1.3–5.6 秒的编译现在不再编译任何新图。复现该快照的命令python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --threads 4 --device cpu --compile --json aug_cpu.json python benchmarks/augmentation/flagship.py --batches 1,8,32 --size 256 --threads 4 --device cuda --compile --json aug_cuda.json理解运行范式为什么数字不能横向直接比较原文档用一个关键表格说明各库解决的不是同一个问题把某一列读成赢家是有误导性的。每个库的操作对象如下库数据批量设备可微korniafloatBCHW张量✅ 批量CPU或 GPU✅ 是torchvision v2floatBCHW张量✅ 批量CPU 或 GPU❌ 否albumentationsuint8HWCnumpy❌ 逐图像循环仅 CPU❌ 否OpenCVcv2uint8HWCnumpy❌ 逐图像循环仅 CPU❌ 否PILPillowuint8HWC图像❌ 逐图像循环仅 CPU❌ 否kornia-rsuint8HWCnumpy❌ 逐图像仅 CPU原生 Rust❌ 否由此产生两场不同的竞赛CPU /uint8/ 单图像——albumentations、OpenCV、PIL 与 kornia-rs 在此区间。这是经典的数据加载器范式SIMD/原生后端获胜。kornia 的float路径不是为它而建的不应期望领先。GPU /float/ 批量 / 可微——kornia 的主场。torchvision v2 在原始速度上竞争但不可微其他库根本无法运行在此区间。这正是 kornia 设计上要领先的范式也是torch.compile融合最能发挥价值的地方。flagship.py的源码进一步印证kornia 与 torchvision 跑批量 float BCHW 张量CPU 或 GPUalbumentations/OpenCV/PIL 在 CPU 上用 Python 循环跑单张 uint8 HWC 图像它们原生的范式。pipeline.py的 docstring 也强调目的不是赢得 CPU/uint8 单图像竞赛albumentations 拥有该区间这正是计划中kornia-rs后端要针对的而是量化 kornia 领先的 GPU 批量可微编译管线。历史样本结果all_libraries.py2026-08-08 淘汰下表由已淘汰的逐算子脚本all_libraries.py测得确定性参数、albumentations 变换在计时循环内构造、含 PIL/kornia-rs 列它早于共享common.py方法论与 JSON 导出。全新旗舰数字见根级 benchmarks/README.md脚本本身保留在 git 历史中。仅作方向性数字——任何引用的数字请在自己的硬件上复现。在 NVIDIA Jetson Orinaarch64、torch 2.10、CPU、batch 8、128×128、吞吐单位img/s越高越好上测得opkornia (eager)kornia (compiled)torchvision v2albumentationsOpenCVPILkornia-rsHorizontalFlip12269302623714744981568461817465304VerticalFlip14088273194658444971459222063472195Resize (½)207939615892284045657381275643GaussianBlur978194912187515266–62848Brightness82752574626425265722872–173588Grayscale765532267315023497673271678915492这个切片CPU说明了什么kornia-rs 在多数算子上是最快的 CPU/uint8后端——在 Resize、GaussianBlur 与 Brightness 上超过 OpenCV仅在两个单次内存遍历翻转或融合色彩归约灰度算子上落后。这是计划中可选kornia-rs增强后端roadmap的证据kornia 已通过其 Rust 姊妹项目提供了最快的 CPU 内核——剩下的是 API 集成工作而不是内核速度问题。torch.compile是 kornia 逐点算子的 CPU 杠杆——Brightness 8.3k → 25.7k3.1 倍、Grayscale 7.7k → 32.3k4.2 倍缩小或追平了与 torchvision 的差距。它对 CPU 上卷积受限的算子没有帮助GaussianBlur 反而回退——编译/启动开销超过了微小的内核。GPUNVIDIA Jetson Orin、torch 2.10、--device cuda、batch 32、256×256、img/s。uint8单图像后端仅支持 CPU为参考重复列出opkornia (eager)kornia (compiled)torchvision v2OpenCVkornia-rsHorizontalFlip11458✗521202213432284VerticalFlip10599✗506012268329592Resize (½)✗ nan✗261492114540773GaussianBlur47410426904834219336Brightness6538122842978540449621Grayscale190622477742555182114698GPU 行的解读——请阅读 Jetson 注意事项不要把它当作数据中心结果compiled 列的✗是Jetson wheel 限制不是 kornia 缺陷torch.compile在 Orin 的 torch 2.10 CUDA 构建上对若干算子报错CUDA driver error: invalid argument因此 compiled 行不可用。Resize的 eagernan是同一回事——Orin wheel 的cusolver损坏get_perspective_transform的线性求解在设备上失败。在正常数据中心CUDA wheel 上两者都能工作Orin 在这里只是低估了kornia。在设备上 compile可用的地方Brightness、GaussianBlur、Grayscale它带来了预期的 eager 2–4 倍提升torchvision v2 在批量 float 吞吐上领先——与包装开销发现一致廉价算子的 GPU forward 约 78% 是基类编排而非内核见下文改进清单。该 Orin 机型是本项目 GPU 基准的标准目标——所有 GPU 数字都用--device cuda在此运行并报告上述两个注意事项而不是省略行。被淘汰快照的管理原则benchmarks/results/superseded/README.md 说明了过时快照的处理保留用于历史但不再发布docs/generate_benchmarks.py会跳过该树。关键规则是快照由其 kornia 版本与git_commit标识永远不是日期——一个版本目录跨越许多 commit。当合并改动改变了某个快照所测算子的速度且机器无法重新测量时把运行移到benchmarks/results/superseded/version/并登记是哪次改动使其过时硬件可得时应重新测量。例如增强类的RandomGaussianBlur委托给kornia.filters.gaussian_blur2d因此 #4647 的滤波器加速也移动了增强数字——若把旧文件与 #4647 后的运行并排发布会被误读为硬件差异。已知改进机会清单稍后改进列表原文档给出了具体、经过测量的杠杆大致按杠杆率排序。每一条都是这个基线可以移动的地方廉价算子的包装开销GPU。性能分析显示 GPURandomHorizontalFlipforward 约 78% 是逐次调用的基类编排变换矩阵构造、where混合、dtype/shape 簿记——不是内核。杠杆是更精简、完全可torch.compile的基类forward加上 CUDA-graph 捕获而不是更快的内核。已部分处理p 1变换矩阵快速路径CUDA-graph 捕获是下一步。kornia-rsCPU/uint8后端。上表显示 kornia-rs 已领先 CPU 竞赛。可选的backendrust选择器把不可微的 CPUuint8增强路由到kornia_rs.imgproc将让 kornia 在数据加载器范式也成为最快选项——这是 API 集成问题不是内核问题。面向少数内核受限算子的 Triton 内核。针对inductor无法融合的算子融合 warp 采样器warp_affine/grid_sample/remap所有几何增强都经过它、median_blur、equalize/直方图、双边/引导滤波、形态学。逐点算子留在inductor上在那里重写 Triton 只是重新推导编译器已产出的东西。注意kornia 的依赖策略是仅 PyTorch因此核心 Triton 内核是刻意的可选依赖决策不是即插即用。float 管线中的uint8快速路径减少让批量路径在廉价算子上输给原生uint8后端的float↔uint8转换。端到端编译管线。pipeline.py已显示编译后的 kornia 管线在 CPU 上超过 torchvision v2 并达到 albumentations 同级别剩余收益是让整个管线包括参数生成保持 fullgraph从而能捕获进 CUDA graph。原文档还给出了工作流约定改进其中任一条后重新运行相关脚本把新数字放入 PR 描述若改动持久用新硬件更新上面的样本表。pipeline.py中编译管线的具体构造是参考所有算子p1.0以保证确定性、公平地计时应用的工作量并给ColorJitter固定order[0, 1, 2, 3]使整个管线可 fullgraph 编译——这正是改进清单第 5 条参数生成也 fullgraph的现状基线。如何在新机器上贡献基准结果benchmarks/README.md 给出了任何机器都可遵循的贡献流程该 README 也是所有新增基准的方法论总纲检出你要测量的 release tag。让机器安静关闭其他应用、接市电、让其冷却。文件中只记录聚合负载数字load average、内存绝不记录进程或应用名——collect_load_metrics源码也印证了这一点隐私保护设计只有数字没有名称。用--contribute运行各套件多数套件是flagship.py非旗舰的脚本在目录图中标明如feature/laf_ops.pypython benchmarks/augmentation/flagship.py --device cuda --contribute benchmarks/results运行落盘到benchmarks/results/kornia-version/suite--machine--device.json可用--machine-slug覆盖机器名。common.py的canonical_result_name用设备类型去掉冒号后缀生成文件名。提交文件并开 PR。CI 用 benchmarks/results_schema.py 校验 schema文档页与 llms digest 在下次文档构建时自动重新生成python docs/generate_benchmarks.py --refresh-llms刷新已提交的 digest。对比工件base-vs-branch A/B 或跨版本对比不是发布快照它们记录的是一个必然不是当前树的修订因此不放进benchmarks/results/kornia-version/也不进入文档性能页。此类原始 JSON 应放在引用它的报告旁的benchmarks/area/name_results/*.json例如 benchmarks/feature/graf_results/按对比的修订或系列命名CI 用results_schema.validate_artefact校验——与发布快照相同的信封、元数据、隐私与行类型规则只是放宽文件名与版本目录规则且load可选base 修订的 harness 可能早于该字段。结语把数字当作可检验的证据kornia 增强基准套件的设计哲学贯穿始终发布胜也发布负陈述范式而非假装逐列可比用 commit 版本标识运行而非日期。无论是评估torch.compile是否值得CPU 逐点算子往往值得、卷积受限算子经常回退、判断某个算子是否是需要优化的薄弱点历史上ColorJiggle、RandomResizedCrop的编译问题均由此暴露还是验证一次重构是否真的变快#4659 对 crop 编译风暴的修复这套脚本与 benchmarks/common.py 提供的方法论都能给出可复现、可引用的答案。在你自己的硬件上运行本文列出的命令即可把这份基线延续到你的环境中。【免费下载链接】kornia 空间人工智能的几何计算机视觉库项目地址: https://gitcode.com/kornia/kornia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考