AI 应用机器学习模型优化【免费下载链接】coremltoolsCore ML tools contain supporting tools for Core ML model conversion, editing, and validation.项目地址https://gitcode.com/gh_mirrors/co/coremltools点击查看免费下载本指南系统梳理 coremltools 中模型剪枝pruning的性能特性从稀疏表示的存储原理、Neural Engine 与 CPU 上的延迟收益机制到官方在 iPhone 14 ProA16上发布的剪枝模型延迟基准数据与复现方法。读完本文你将掌握剪枝稀疏度、稀疏模式无结构 / 块结构 /n:m与部署端收益之间的对应关系并学会用coremltools.optimize.torch与coremltools.optimize.coreml的 API 配置剪枝参数、验证压缩比与延迟。剪枝性能的基石稀疏表示节省多少存储剪枝的本质是把权重矩阵中的一部分值置为0而0值可以用**稀疏表示sparse representation**更高效地存储从而替代默认的稠密dense表示。关于稀疏表示的详细原理可参考 剪枝总览稀疏表示只保存非零数值并配以一个位掩码bit mask位掩码在非零值位置取1例如权重{0, 7, 0, 0, 0, 0, 0, 56.3}对应的掩码是01000001b伴随的非零数据是长度为 2 的向量{7, 56.3}。图创建稀疏表示出自 opt-pruning-overview.md这也是剪枝存储收益与延迟收益的底层机制。从性能角度官方文档给出了一个简洁而关键的数量关系相比以 float16 精度存储的稠密权重稀疏表示对每个0值大约节省 2 字节的存储空间float16 占 2 字节0值无需再存数值只需位掩码中的 1 个比特模型体积随引入的稀疏度线性下降。也就是说50% 稀疏大约带来接近 2 倍的压缩比75% 稀疏则接近 4 倍这在下文的基准数据中会得到印证例如 ResNet50 在 75% 无结构稀疏下压缩比达到 3.17。需要说明的是稀疏权重表示仅在iOS16 / macOS13 / watchOS9 / tvOS16 及更新的部署目标下可用针对 Core MLmlprogram模型选择部署目标时需要留意这一前提。延迟收益之一以 Neural Engine 为主的模型如何受益对于主要在Neural Engine神经网络引擎上运行的模型稀疏性通常有助于降低延迟其收益来自两个层面减少推理时加载的权重数据量对“权重内存受限”weight memory bound的网络权重的搬运是推理瓶颈稀疏表示压缩了需要搬运的数据量从而直接加速推理。跳过计算当推理过程中遇到一串连续的0时Neural Engine 可能跳过对应的计算从而减少实际计算量。要让这种跳过更有效通常需要选择较高的无结构稀疏度如 75% 或更高或者采用块结构稀疏block-structured sparsity——让0以大小为 2 或其倍数的块出现。同时官方也给出了精度层面的注意事项在更大的块大小和更高的稀疏度下为了保持精度通常需要更长时间、更多数据的微调fine-tuning。这与 剪枝算法文档 中 MagnitudePruner 的训练时剪枝设计是一致的通过PolynomialDecayScheduler在训练过程中逐步引入稀疏度让权重有时间适应0的出现。延迟收益之二n:m 结构化稀疏加速 CPU 上的线性层与 Neural Engine 不同CPU 侧更新一代的硬件的加速路径是n:m结构化稀疏其适用场景是包含大量线性运算linear ops的模型。这里在每m个元素的块中有n个为0m应为 16 的因数如3:4、7:8、14:16等n/m 0.5即块内至少一半元素为0。n:m稀疏与块稀疏同属结构化稀疏。从仓库源码看n:m掩码的生成实现在 pruning/_utils.py 的n_m_mask函数中权重张量被按m切成不重叠的块每块内按绝对值排序后把最小的n个置0当输出通道数不能被m整除时会先做零填充再裁剪回原尺寸。而dim参数控制块沿输入通道默认1还是输出通道0方向选取该参数仅对Linear/Conv类层有效。联合压缩剪枝与量化、调色板化的叠加收益剪枝可以与量化quantization和调色板化palettization联合使用在单独使用这些技术所获得的延迟与存储收益之外进一步叠加收益。完整示例可参考 组合压缩类型其核心做法是先剪枝再对稀疏权重张量的非零值做量化INT8/UINT8或调色板化LUT 查表分别对应“剪枝 量化”与“剪枝 调色板化”两种组合在coremltools.optimize.coremlAPI 中这一步通过prune_weights(...)后再调用linear_quantize_weights(...)或palettize_weights(...)并传入joint_compressionTrue实现在 Torch 侧则可用MagnitudePruner与LinearQuantizer/PostTrainingPalettizer配合实现训练时联合压缩。注意联合压缩时pruner.prepare(inplaceTrue)必须原地进行且finalize时须先 finalize 量化器/调色板化器再 finalize 剪枝器以确保导出所需的压缩元数据正确注册见 pruning/_base_pruner.py 中的相关校验逻辑。此外自iOS18 / macOS15起稀疏表示中的非零 float 值还可以进一步用调色板化或线性量化压缩带来更多存储节省与运行时性能提升。性能基准测试方法如何复现官方延迟数据官方延迟数据使用 Xcode 的Performance标签页采集统计量为median中位数计算单元Compute Unit选择为all除非另行注明。延迟数字对设备状态敏感可能因设备状态与构建版本不同而波动。测试环境如下项目值设备iPhone 14 ProA16除非另行注明iOS 构建iOS 17XcodeXcode 15关于基准模型与压缩方法论的更多细节如预训练权重来源、微调数据集、精度指标官方文档指引参考 调色板化性能文档剪枝模型的精度基准ImageNet Top-1 精度三次独立训练取均值 ± 标准差则记录在 剪枝算法文档。这些基准模型均为图像分类任务由预训练 PyTorch 模型经训练时压缩training time compression得到。官方延迟基准结果稀疏度、压缩比与延迟的关系下表汇总了官方发布的剪枝延迟基准每个值代表每 batch 的延迟单位 ms模型配置优化算法压缩比延迟ms / batchMobileNetv2-1.0Float16n/a1.00.48MobileNetv2-1.0无结构稀疏 50%MagnitudePruner1.370.46MobileNetv2-1.0无结构稀疏 75%MagnitudePruner1.730.46MobileNetv3-smallFloat16n/a1.00.13MobileNetv3-small无结构稀疏 50%MagnitudePruner1.730.12MobileNetv3-small无结构稀疏 75%MagnitudePruner3.060.12ResNet50Float16n/a1.01.52ResNet50无结构稀疏 50%MagnitudePruner1.771.46ResNet50无结构稀疏 75%MagnitudePruner3.171.28从数据中可以读出三个规律压缩比随稀疏度线性增长75% 稀疏度的压缩比约为 50% 稀疏度的一倍如 MobileNetv3-small 从 1.73 到 3.06ResNet50 从 1.77 到 3.17与“每 1% 稀疏 ≈ 1% 体积下降”的线性关系一致延迟收益相对温和但确定在所有三个模型上剪枝模型的延迟均不高于 Float16 基线且 ResNet50 在 75% 稀疏度下获得了最明显的下降1.52ms → 1.28ms约 16%。对于本身很小、计算已高度优化的模型如 MobileNetv3-small延迟空间有限收益更多体现在存储上延迟收益与模型性质强相关ResNet50 这类卷积权重占比高的模型更接近“权重内存受限”因此剪枝带来的权重加载量下降更容易转化为延迟收益。作为补充同一批剪枝模型在 剪枝算法文档 中的精度基准显示50% 无结构稀疏几乎不损失精度如 MobileNetv2-1.0 从 71.86 到 71.83±0.01ResNet50 从 76.14 到 73.64±0.04而 75% 稀疏开始出现可见的精度回落MobileNetv3-small 降至 60.52±0.06。这印证了“更高稀疏度需要更长微调来保精度”的论断也说明选择稀疏度时需要结合精度与延迟/存储综合权衡。从源码看剪枝配置稀疏模式与关键参数Torch 侧MagnitudePruner的四种稀疏模式训练时剪枝使用MagnitudePruner实现见 pruning/magnitude_pruner.py其原理基于论文《To prune, or not to prune》按权重绝对值排序后把低于阈值的元素置0并维护全量权重与0/1掩码相乘参与前向传播使梯度仍能正常回传。ModuleMagnitudePrunerConfig支持四种稀疏模式模式触发条件机制无结构稀疏默认block_size 1、n_m_ratio None、granularity per_scalar将权重张量中绝对值最小的floor(size * target_sparsity)个元素置0块结构稀疏block_size 1、n_m_ratio None沿输出通道维按block_size分组按块 L2 范数从低到高整块置0输出通道数不能被块大小整除时会先零填充n:m结构化稀疏n_m_ratio ! None沿dim默认 1即输入通道把每m个元素中绝对值最小的n个置0target_sparsity由n/m决定一般结构化稀疏granularity per_channel / per_kernel仅适用于 rank ≥ 3 的权重按通道或卷积核的 L2 范数整组置0关键参数默认值与文档中提到的 CPUn:m加速建议一致target_sparsity默认0.5范围[0, 1]initial_sparsity默认0.0granularityper_scalar/per_kernel/per_channel默认per_scalarblock_size默认1大于 1 才启用块稀疏且至多为输出通道数的一半n_m_ratio默认None当不为None时block_size必须为1、granularity必须为per_scalar二者互斥源码中有显式校验dim默认1仅用于n:m稀疏scheduler默认ConstantSparsityScheduler(begin_step0)。其中掩码的具体计算逻辑L1/L2 范数选择、块填充、阈值选取实现在 pruning/_utils.py 的magnitude_ranked_mask与n_m_mask中per_scalar用 L1 范数绝对值其余粒度用 L2 范数。调度器则在 pruning/pruning_scheduler.py 中实现ConstantSparsityScheduler从begin_step起直接把稀疏度设为target_sparsity适合数据无关的一次性剪枝PolynomialDecayScheduler按update_steps列表与幂指数power默认 3逐步逼近target_sparsity适合训练时渐进剪枝。一个训练时渐进剪枝的典型用法对全部Conv2d层逐步施加 75% 稀疏度from coremltools.optimize.torch import MagnitudePruner, MagnitudePrunerConfig config MagnitudePrunerConfig.from_dict({ module_type_configs: { Conv2d: { scheduler: {update_steps: range(0, 100, 5)}, target_sparsity: 0.75, granularity: per_scalar, }, } }) pruner MagnitudePruner(model, config) model pruner.prepare() for epoch in range(num_epochs): for inp, label in train_dataloader: train_step(inp, label) pruner.step() # 按调度逐步提高稀疏度 pruner.finalize(inplaceTrue) # 把剪枝掩码固化到权重生命周期为prepare()插入剪枝层与钩子→ 训练循环中step()按调度递增稀疏度→finalize()将掩码与参数相乘固化0值report()可输出每个模块及全局的structured / unstructured / block2稀疏度统计。数据无关的n:m剪枝则更简洁例如6:8稀疏config MagnitudePrunerConfig.from_dict({global_config: {n_m_ratio: [6, 8]}}) pruner MagnitudePruner(model, config) pruner.prepare() model pruner.finalize() # 默认 ConstantSparsityScheduler数据无关Core ML 侧prune_weights与数据无关剪枝对于已经转换好的mlprogram模型post_training_quantization.py 中的prune_weights会把存储权重的const节点替换为constexpr_sparse_to_dense稀疏表示节点。其配置类定义在 _config.pyOpThresholdPrunerConfig绝对值低于threshold默认1e-12的权重全部置0适用于权重中已有大量0的模型minimum_sparsity_percentile默认0.5控制稀疏度不足时回退到稠密存储weight_threshold默认2048规定元素总数大于该值的张量才会被剪枝避免破坏小张量OpMagnitudePrunerConfig按target_sparsity或n_m_ratio剪掉最低幅值的一批元素block_size与dim块稀疏默认0n:m默认1启用结构化稀疏且结构剪枝仅支持linear/conv层源码中有 op 类型校验target_sparsity与n_m_ratio必须且只能设置其一。一个数据无关zero-shot剪枝的完整示例from coremltools.optimize.coreml import ( OpMagnitudePrunerConfig, OptimizationConfig, prune_weights, ) config OptimizationConfig( global_configOpMagnitudePrunerConfig( target_sparsity0.5, weight_threshold1024, ), op_type_configs{linear: OpMagnitudePrunerConfig(target_sparsity0.75)}, op_name_configs{fc: None}, # 跳过名为 fc 的层 ) model_compressed prune_weights(model, configconfig)注意数据无关剪枝通常只用于快速试验不同的稀疏模式n:m、块结构等与稀疏度观察体积与延迟的影响找到合适配置后再用 SparseGPT校准数据或 MagnitudePruner微调产出精度更高的模型——这是 剪枝算法文档 给出的推荐工作流。另外若 Torch 模型已用ct.optimize.torchAPI 剪枝直接调用ct.convert即可导出稀疏表示的 Core ML 模型若只是权重被置零但仍为稠密表示则需要先用prune_weights转换。总结选择稀疏模式与稀疏度的决策要点综合官方性能文档与仓库实现可归纳出以下实操决策要点存储收益是确定的稀疏度每提高 1%模型体积大约线性下降 1%每个0值节省约 2 字节这是剪枝最稳定、最可预期的收益延迟收益取决于硬件与模型Neural Engine 侧重权重内存受限网络与连续0的计算跳过建议 75% 无结构稀疏或块大小为 2 的倍数的块稀疏CPU 侧重线性层多的模型使用m为 16 的因数且n/m 0.5的n:m稀疏3:4、7:8、14:16高稀疏度伴随精度成本更大的块、更高的稀疏度需要更长微调来保持精度建议用数据无关剪枝快速验证体积/延迟后再用校准数据或训练时剪枝落实精度联合压缩收益可叠加剪枝与量化、调色板化可以组合joint_compressionTrue或 Torch 侧按“先量化/调色板化 prepare再剪枝 prepare先 finalize 量化/调色板化再 finalize 剪枝”的顺序且 iOS18/macOS15 起稀疏非零值可再被量化/调色板化压缩验证口径要一致复现延迟基准时使用 Xcode Performance 标签页的median统计量、Compute Unit 为all并留意设备状态与构建版本对结果的影响。赞分享AI 应用机器学习模型优化【免费下载链接】coremltoolsCore ML tools contain supporting tools for Core ML model conversion, editing, and validation.项目地址https://gitcode.com/gh_mirrors/co/coremltools点击查看免费下载相关推荐Jukebox模型剪枝通道剪枝与权重稀疏化优化实践Jukebox模型剪枝通道剪枝与权重稀疏化优化实践 你是否在部署Jukebox音乐生成模型时遇到显存不足、推理速度慢的问题本文将通过通道剪枝与权重稀疏化两种人工智能大模型音乐生成音频预训练一张随手拍凭什么挂上墙试试这个会做减法的照片转抽象艺术工具一张随手拍凭什么挂上墙试试这个会做减法的照片转抽象艺术工具 你有没有这种时刻手机相册里躺着几百张拍得还行、又不够惊艳的照片。发朋友圈差点意思删AI 技能媒体生成AI 应用5分钟上手OpenRCT2插件开发用JavaScript为游乐园写第一个自定义窗口5分钟上手OpenRCT2插件开发用JavaScript为游乐园写第一个自定义窗口 OpenRCT2 是《过山车大亨2》的开源重制版它内置了一套完整的游戏开发图形学上一篇LinVst 终极问题解决指南轻松应对 Linux VST 插件常见故障下一篇构建龙与地下城5E数据库开发者如何快速集成DD数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AI 应用机器学习模型优化【免费下载链接】coremltoolsCore ML tools contain supporting tools for Core ML model conversion, editing, and validation.项目地址https://gitcode.com/gh_mirrors/co/coremltools点击查看免费下载本指南系统梳理 coremltools 中模型剪枝pruning的性能特性从稀疏表示的存储原理、Neural Engine 与 CPU 上的延迟收益机制到官方在 iPhone 14 ProA16上发布的剪枝模型延迟基准数据与复现方法。读完本文你将掌握剪枝稀疏度、稀疏模式无结构 / 块结构 /n:m与部署端收益之间的对应关系并学会用coremltools.optimize.torch与coremltools.optimize.coreml的 API 配置剪枝参数、验证压缩比与延迟。剪枝性能的基石稀疏表示节省多少存储剪枝的本质是把权重矩阵中的一部分值置为0而0值可以用**稀疏表示sparse representation**更高效地存储从而替代默认的稠密dense表示。关于稀疏表示的详细原理可参考 剪枝总览稀疏表示只保存非零数值并配以一个位掩码bit mask位掩码在非零值位置取1例如权重{0, 7, 0, 0, 0, 0, 0, 56.3}对应的掩码是01000001b伴随的非零数据是长度为 2 的向量{7, 56.3}。图创建稀疏表示出自 opt-pruning-overview.md这也是剪枝存储收益与延迟收益的底层机制。从性能角度官方文档给出了一个简洁而关键的数量关系相比以 float16 精度存储的稠密权重稀疏表示对每个0值大约节省 2 字节的存储空间float16 占 2 字节0值无需再存数值只需位掩码中的 1 个比特模型体积随引入的稀疏度线性下降。也就是说50% 稀疏大约带来接近 2 倍的压缩比75% 稀疏则接近 4 倍这在下文的基准数据中会得到印证例如 ResNet50 在 75% 无结构稀疏下压缩比达到 3.17。需要说明的是稀疏权重表示仅在iOS16 / macOS13 / watchOS9 / tvOS16 及更新的部署目标下可用针对 Core MLmlprogram模型选择部署目标时需要留意这一前提。延迟收益之一以 Neural Engine 为主的模型如何受益对于主要在Neural Engine神经网络引擎上运行的模型稀疏性通常有助于降低延迟其收益来自两个层面减少推理时加载的权重数据量对“权重内存受限”weight memory bound的网络权重的搬运是推理瓶颈稀疏表示压缩了需要搬运的数据量从而直接加速推理。跳过计算当推理过程中遇到一串连续的0时Neural Engine 可能跳过对应的计算从而减少实际计算量。要让这种跳过更有效通常需要选择较高的无结构稀疏度如 75% 或更高或者采用块结构稀疏block-structured sparsity——让0以大小为 2 或其倍数的块出现。同时官方也给出了精度层面的注意事项在更大的块大小和更高的稀疏度下为了保持精度通常需要更长时间、更多数据的微调fine-tuning。这与 剪枝算法文档 中 MagnitudePruner 的训练时剪枝设计是一致的通过PolynomialDecayScheduler在训练过程中逐步引入稀疏度让权重有时间适应0的出现。延迟收益之二n:m 结构化稀疏加速 CPU 上的线性层与 Neural Engine 不同CPU 侧更新一代的硬件的加速路径是n:m结构化稀疏其适用场景是包含大量线性运算linear ops的模型。这里在每m个元素的块中有n个为0m应为 16 的因数如3:4、7:8、14:16等n/m 0.5即块内至少一半元素为0。n:m稀疏与块稀疏同属结构化稀疏。从仓库源码看n:m掩码的生成实现在 pruning/_utils.py 的n_m_mask函数中权重张量被按m切成不重叠的块每块内按绝对值排序后把最小的n个置0当输出通道数不能被m整除时会先做零填充再裁剪回原尺寸。而dim参数控制块沿输入通道默认1还是输出通道0方向选取该参数仅对Linear/Conv类层有效。联合压缩剪枝与量化、调色板化的叠加收益剪枝可以与量化quantization和调色板化palettization联合使用在单独使用这些技术所获得的延迟与存储收益之外进一步叠加收益。完整示例可参考 组合压缩类型其核心做法是先剪枝再对稀疏权重张量的非零值做量化INT8/UINT8或调色板化LUT 查表分别对应“剪枝 量化”与“剪枝 调色板化”两种组合在coremltools.optimize.coremlAPI 中这一步通过prune_weights(...)后再调用linear_quantize_weights(...)或palettize_weights(...)并传入joint_compressionTrue实现在 Torch 侧则可用MagnitudePruner与LinearQuantizer/PostTrainingPalettizer配合实现训练时联合压缩。注意联合压缩时pruner.prepare(inplaceTrue)必须原地进行且finalize时须先 finalize 量化器/调色板化器再 finalize 剪枝器以确保导出所需的压缩元数据正确注册见 pruning/_base_pruner.py 中的相关校验逻辑。此外自iOS18 / macOS15起稀疏表示中的非零 float 值还可以进一步用调色板化或线性量化压缩带来更多存储节省与运行时性能提升。性能基准测试方法如何复现官方延迟数据官方延迟数据使用 Xcode 的Performance标签页采集统计量为median中位数计算单元Compute Unit选择为all除非另行注明。延迟数字对设备状态敏感可能因设备状态与构建版本不同而波动。测试环境如下项目值设备iPhone 14 ProA16除非另行注明iOS 构建iOS 17XcodeXcode 15关于基准模型与压缩方法论的更多细节如预训练权重来源、微调数据集、精度指标官方文档指引参考 调色板化性能文档剪枝模型的精度基准ImageNet Top-1 精度三次独立训练取均值 ± 标准差则记录在 剪枝算法文档。这些基准模型均为图像分类任务由预训练 PyTorch 模型经训练时压缩training time compression得到。官方延迟基准结果稀疏度、压缩比与延迟的关系下表汇总了官方发布的剪枝延迟基准每个值代表每 batch 的延迟单位 ms模型配置优化算法压缩比延迟ms / batchMobileNetv2-1.0Float16n/a1.00.48MobileNetv2-1.0无结构稀疏 50%MagnitudePruner1.370.46MobileNetv2-1.0无结构稀疏 75%MagnitudePruner1.730.46MobileNetv3-smallFloat16n/a1.00.13MobileNetv3-small无结构稀疏 50%MagnitudePruner1.730.12MobileNetv3-small无结构稀疏 75%MagnitudePruner3.060.12ResNet50Float16n/a1.01.52ResNet50无结构稀疏 50%MagnitudePruner1.771.46ResNet50无结构稀疏 75%MagnitudePruner3.171.28从数据中可以读出三个规律压缩比随稀疏度线性增长75% 稀疏度的压缩比约为 50% 稀疏度的一倍如 MobileNetv3-small 从 1.73 到 3.06ResNet50 从 1.77 到 3.17与“每 1% 稀疏 ≈ 1% 体积下降”的线性关系一致延迟收益相对温和但确定在所有三个模型上剪枝模型的延迟均不高于 Float16 基线且 ResNet50 在 75% 稀疏度下获得了最明显的下降1.52ms → 1.28ms约 16%。对于本身很小、计算已高度优化的模型如 MobileNetv3-small延迟空间有限收益更多体现在存储上延迟收益与模型性质强相关ResNet50 这类卷积权重占比高的模型更接近“权重内存受限”因此剪枝带来的权重加载量下降更容易转化为延迟收益。作为补充同一批剪枝模型在 剪枝算法文档 中的精度基准显示50% 无结构稀疏几乎不损失精度如 MobileNetv2-1.0 从 71.86 到 71.83±0.01ResNet50 从 76.14 到 73.64±0.04而 75% 稀疏开始出现可见的精度回落MobileNetv3-small 降至 60.52±0.06。这印证了“更高稀疏度需要更长微调来保精度”的论断也说明选择稀疏度时需要结合精度与延迟/存储综合权衡。从源码看剪枝配置稀疏模式与关键参数Torch 侧MagnitudePruner的四种稀疏模式训练时剪枝使用MagnitudePruner实现见 pruning/magnitude_pruner.py其原理基于论文《To prune, or not to prune》按权重绝对值排序后把低于阈值的元素置0并维护全量权重与0/1掩码相乘参与前向传播使梯度仍能正常回传。ModuleMagnitudePrunerConfig支持四种稀疏模式模式触发条件机制无结构稀疏默认block_size 1、n_m_ratio None、granularity per_scalar将权重张量中绝对值最小的floor(size * target_sparsity)个元素置0块结构稀疏block_size 1、n_m_ratio None沿输出通道维按block_size分组按块 L2 范数从低到高整块置0输出通道数不能被块大小整除时会先零填充n:m结构化稀疏n_m_ratio ! None沿dim默认 1即输入通道把每m个元素中绝对值最小的n个置0target_sparsity由n/m决定一般结构化稀疏granularity per_channel / per_kernel仅适用于 rank ≥ 3 的权重按通道或卷积核的 L2 范数整组置0关键参数默认值与文档中提到的 CPUn:m加速建议一致target_sparsity默认0.5范围[0, 1]initial_sparsity默认0.0granularityper_scalar/per_kernel/per_channel默认per_scalarblock_size默认1大于 1 才启用块稀疏且至多为输出通道数的一半n_m_ratio默认None当不为None时block_size必须为1、granularity必须为per_scalar二者互斥源码中有显式校验dim默认1仅用于n:m稀疏scheduler默认ConstantSparsityScheduler(begin_step0)。其中掩码的具体计算逻辑L1/L2 范数选择、块填充、阈值选取实现在 pruning/_utils.py 的magnitude_ranked_mask与n_m_mask中per_scalar用 L1 范数绝对值其余粒度用 L2 范数。调度器则在 pruning/pruning_scheduler.py 中实现ConstantSparsityScheduler从begin_step起直接把稀疏度设为target_sparsity适合数据无关的一次性剪枝PolynomialDecayScheduler按update_steps列表与幂指数power默认 3逐步逼近target_sparsity适合训练时渐进剪枝。一个训练时渐进剪枝的典型用法对全部Conv2d层逐步施加 75% 稀疏度from coremltools.optimize.torch import MagnitudePruner, MagnitudePrunerConfig config MagnitudePrunerConfig.from_dict({ module_type_configs: { Conv2d: { scheduler: {update_steps: range(0, 100, 5)}, target_sparsity: 0.75, granularity: per_scalar, }, } }) pruner MagnitudePruner(model, config) model pruner.prepare() for epoch in range(num_epochs): for inp, label in train_dataloader: train_step(inp, label) pruner.step() # 按调度逐步提高稀疏度 pruner.finalize(inplaceTrue) # 把剪枝掩码固化到权重生命周期为prepare()插入剪枝层与钩子→ 训练循环中step()按调度递增稀疏度→finalize()将掩码与参数相乘固化0值report()可输出每个模块及全局的structured / unstructured / block2稀疏度统计。数据无关的n:m剪枝则更简洁例如6:8稀疏config MagnitudePrunerConfig.from_dict({global_config: {n_m_ratio: [6, 8]}}) pruner MagnitudePruner(model, config) pruner.prepare() model pruner.finalize() # 默认 ConstantSparsityScheduler数据无关Core ML 侧prune_weights与数据无关剪枝对于已经转换好的mlprogram模型post_training_quantization.py 中的prune_weights会把存储权重的const节点替换为constexpr_sparse_to_dense稀疏表示节点。其配置类定义在 _config.pyOpThresholdPrunerConfig绝对值低于threshold默认1e-12的权重全部置0适用于权重中已有大量0的模型minimum_sparsity_percentile默认0.5控制稀疏度不足时回退到稠密存储weight_threshold默认2048规定元素总数大于该值的张量才会被剪枝避免破坏小张量OpMagnitudePrunerConfig按target_sparsity或n_m_ratio剪掉最低幅值的一批元素block_size与dim块稀疏默认0n:m默认1启用结构化稀疏且结构剪枝仅支持linear/conv层源码中有 op 类型校验target_sparsity与n_m_ratio必须且只能设置其一。一个数据无关zero-shot剪枝的完整示例from coremltools.optimize.coreml import ( OpMagnitudePrunerConfig, OptimizationConfig, prune_weights, ) config OptimizationConfig( global_configOpMagnitudePrunerConfig( target_sparsity0.5, weight_threshold1024, ), op_type_configs{linear: OpMagnitudePrunerConfig(target_sparsity0.75)}, op_name_configs{fc: None}, # 跳过名为 fc 的层 ) model_compressed prune_weights(model, configconfig)注意数据无关剪枝通常只用于快速试验不同的稀疏模式n:m、块结构等与稀疏度观察体积与延迟的影响找到合适配置后再用 SparseGPT校准数据或 MagnitudePruner微调产出精度更高的模型——这是 剪枝算法文档 给出的推荐工作流。另外若 Torch 模型已用ct.optimize.torchAPI 剪枝直接调用ct.convert即可导出稀疏表示的 Core ML 模型若只是权重被置零但仍为稠密表示则需要先用prune_weights转换。总结选择稀疏模式与稀疏度的决策要点综合官方性能文档与仓库实现可归纳出以下实操决策要点存储收益是确定的稀疏度每提高 1%模型体积大约线性下降 1%每个0值节省约 2 字节这是剪枝最稳定、最可预期的收益延迟收益取决于硬件与模型Neural Engine 侧重权重内存受限网络与连续0的计算跳过建议 75% 无结构稀疏或块大小为 2 的倍数的块稀疏CPU 侧重线性层多的模型使用m为 16 的因数且n/m 0.5的n:m稀疏3:4、7:8、14:16高稀疏度伴随精度成本更大的块、更高的稀疏度需要更长微调来保持精度建议用数据无关剪枝快速验证体积/延迟后再用校准数据或训练时剪枝落实精度联合压缩收益可叠加剪枝与量化、调色板化可以组合joint_compressionTrue或 Torch 侧按“先量化/调色板化 prepare再剪枝 prepare先 finalize 量化/调色板化再 finalize 剪枝”的顺序且 iOS18/macOS15 起稀疏非零值可再被量化/调色板化压缩验证口径要一致复现延迟基准时使用 Xcode Performance 标签页的median统计量、Compute Unit 为all并留意设备状态与构建版本对结果的影响。赞分享AI 应用机器学习模型优化【免费下载链接】coremltoolsCore ML tools contain supporting tools for Core ML model conversion, editing, and validation.项目地址https://gitcode.com/gh_mirrors/co/coremltools点击查看免费下载相关推荐Jukebox模型剪枝通道剪枝与权重稀疏化优化实践Jukebox模型剪枝通道剪枝与权重稀疏化优化实践 你是否在部署Jukebox音乐生成模型时遇到显存不足、推理速度慢的问题本文将通过通道剪枝与权重稀疏化两种人工智能大模型音乐生成音频预训练一张随手拍凭什么挂上墙试试这个会做减法的照片转抽象艺术工具一张随手拍凭什么挂上墙试试这个会做减法的照片转抽象艺术工具 你有没有这种时刻手机相册里躺着几百张拍得还行、又不够惊艳的照片。发朋友圈差点意思删AI 技能媒体生成AI 应用5分钟上手OpenRCT2插件开发用JavaScript为游乐园写第一个自定义窗口5分钟上手OpenRCT2插件开发用JavaScript为游乐园写第一个自定义窗口 OpenRCT2 是《过山车大亨2》的开源重制版它内置了一套完整的游戏开发图形学上一篇LinVst 终极问题解决指南轻松应对 Linux VST 插件常见故障下一篇构建龙与地下城5E数据库开发者如何快速集成DD数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
