6.1 NAS 实现框架与工具

6.1 NAS 实现框架与工具

本节摘要：NAS 落地靠工具。本节盘点三层工具生态——通用框架库（NASLib、Auto-PyTorch、NNI、AutoKeras）、专门 NAS 平台（Google Cloud AutoML、SageMaker Autopilot、Azure Automated ML）、开源基准（NAS-Bench-101/201、NATS-Bench），拆解 NAS 框架的四大核心组件（空间定义、搜索算法、性能评估、工作流管理），最后给出按定位选型的决策表与实践流程。

学习目标

阅读完本节，你应当能够：

1. 说出 NAS 工具生态的三个层次及各自的定位差异
2. 对比 NASLib、NNI、AutoKeras、Auto-PyTorch 的适用人群
3. 解释 NAS-Bench 系列基准如何做到"免训练评估"
4. 按"研究/产品"定位与框架特点完成工具选型

一、问题与直觉：工具把 NAS 从"手搓"变成"配置"

早期的 NAS 研究是什么样？从零写搜索空间定义、从零实现搜索算法、从零搭评估流程——一个 DARTS 复现就是几千行代码。SOURCE 的原话说得很直接：这不仅耗时耗力，也限制了 NAS 技术的普及。后来框架的出现改变了局面：搜索空间、搜索算法、评估策略被抽象成模块，用户配置而非编写，NAS 门槛大幅下降。

但工具不能替你思考。框架把"写代码"变成"做选择"——选哪个搜索空间、配哪个搜索算法、评估用什么策略，这些判断仍然在用户肩上。第 2-4 章的全部知识，在这里都变成工具里的配置项。会用框架不等于懂 NAS，懂 NAS 才能用好框架——这是本章最重要的立场。

框架的价值有三层：抽象复杂性（封装掉空间、算法、评估的细节，提供高层 API）；提高效率（内置常用算法与并行化支持）；保证可复现性（文档、示例、实验配置让结果可复现）。三层价值分别对应研究、工程、学术的三个痛点。

二、核心原理：框架四组件与三层工具生态

框架的四个核心组件。搜索空间定义——Cell 空间、图空间、宏观/微观空间的定义模块，NASLib 等框架把第 2 章的空间类型都预置好了。搜索算法——进化、强化学习、梯度、贝叶斯、随机的算法模块，这是第 3 章内容的工具化。性能评估——完全训练、代理、权重共享、零成本的评估模块，这是第 4 章内容的工具化。工作流管理——实验记录、超参数优化、并行化分布式、可视化监控，让大规模搜索可管理。

层次一：通用框架库。NASLib——ETH Zurich 开发的开源研究框架，模块化设计，预置 DARTS space、NAS-Bench-101 space 等搜索空间和随机搜索、REINFORCE、DARTS 等算法，目标是促进可复现可比较。适合 NAS 研究者做算法开发。Auto-PyTorch——基于 PyTorch 的端到端 AutoML 框架，贝叶斯优化+元学习，不只搜架构还管超参数和数据预处理。适合机器学习工程师快速出模型。NNI——微软亚洲研究院的开源 AutoML 工具包，支持多种搜索算法与多种深度学习框架（PyTorch、TensorFlow、Keras），提供 Web UI 可视化，扩展性强。AutoKeras——基于 Keras，主打"几行代码出模型"，集成贝叶斯优化与进化算法，支持图像、文本、结构化数据。适合初学者与非专业人士。

层次二：专门 NAS 工具与平台。Google Cloud AutoML——图形界面，上传数据、配置参数、自动搜索训练，无需写代码，背后是 Google 的 NAS 技术。AWS SageMaker Autopilot——自动完成数据预处理、特征工程、模型选择、超参优化，模型选择阶段用 NAS 技术。Azure Automated ML——微软的自动化 ML 服务，模型选择阶段用 NAS 自动搜索网络架构。三个云平台把 NAS 封装成"上传数据即出模型"的服务——第 1 章说的"民主化"在这里落地，代价是搜索过程不透明、定制空间困难。

层次三：开源基准（Benchmarks）。NAS-Bench-101——Google Brain 构建的第一个大规模 NAS 基准，包含 423,624 个不同卷积架构在 CIFAR-10 上的评估结果（训练时间、验证精度、测试精度），搜索空间定义清晰。NAS-Bench-201——牛津与爱丁堡大学联合构建，提供 CIFAR-10、CIFAR-100、ImageNet16-120 三个数据集和更丰富的空间，架构表示更简洁。NATS-Bench——香港科技大学构建，包含 DARTS 空间、ResNet 空间等多种搜索空间与多个数据集、多种评估指标，更贴近真实应用。基准的价值：研究者查询数据库就能"免训练评估"新算法——不用真训练就能知道算法选中的架构表现如何，让算法比较变得公平、快速。

三、工程实践要点：选型与落地流程

选型决策表。做研究、要开发新算法——NASLib（模块化可扩展，能加自己的空间和算法）。要快速出可用模型、不管内部细节——AutoKeras 或云平台 AutoML。要兼顾实验管理与多框架支持——NNI。要端到端 AutoML（架构+超参+预处理一起调）——Auto-PyTorch。要评估新算法的竞争力——NAS-Bench 系列。判断的第一标准是你的角色：研究者要的是控制力，产品人要的是结果，初学者要的是门槛低。

七步落地流程。问题定义与目标设定——明确任务类型、应用场景、性能指标（精度+约束）。搜索空间设计——定宏观/微观空间、操作集合。搜索算法选择——按第 3.7 节的五步决策。评估策略选择——按第 4.6 节的评估阶梯。搜索与评估循环——初始化→搜索→评估→更新→迭代到停止条件。模型训练与验证——对最终架构用全量数据训练、调超参数、验证集评估。模型部署与优化——剪枝、量化、知识蒸馏、硬件加速。

实践注意。第一，预算先算后跑——把"评估一次的成本 × 预期评估次数"算清楚再启动，否则跑一半发现预算超支只能半途而废。第二，用基准验证算法——算法跑 NAS-Bench 的分数比跑一次完整搜索便宜得多，新算法先上基准，再上真实搜索。第三，最终架构必须完全训练——不管工具里用了什么代理评估，交付的性能必须来自独立训练，这是第 4.6 节纪律的延续。

⚠️ 常见坑：一上来就用云平台 AutoML，跑完拿到模型，但完全不知道它搜了什么架构、用了什么评估策略——搜索过程黑盒，出了问题没法诊断。先用开源框架（NASLib/NNI）跑通一个小实验理解流程，再决定要不要上云平台。

💡 关键直觉：工具的成熟度与 NAS 的成熟度是同一条曲线——框架把第 2-4 章的方法论固化成配置项，反过来,熟练使用框架又能加深对方法论的理解。工具不是方法论的替代品，是方法论的下一个载体。

四、框架的机制细节与上手路径

NAS 框架的"搜索空间"到底长什么样

用框架定义搜索空间，核心是"操作集合 + 结构模板"。操作集合就是第 2.3 节的那套东西——3x3 卷积、5x5 深度可分离卷积、池化、Identity 等；结构模板定义 Cell 的节点数、连接方式、Normal/Reduction 分工。NASLib 这类框架把 NAS-Bench-101 空间、DARTS 空间等预置成"空间对象"，一行配置就能加载。SOURCe 提到 NASLib 提供了"丰富的预定义搜索空间（如 DARTS space, NAS-Bench-101 space）"——这意味着你不需要从零搭空间，选一个预置空间即可起步，等流程跑通再自定义。自定义空间的注意点：操作集合别贪多（第 2.3 节纪律）、基线检验必须做（第 2.1 节纪律）。

NAS 框架与训练框架的分工

NAS 框架（NASLib/NNI/AutoKeras）与深度学习框架（PyTorch/TensorFlow）不是竞争关系，而是"上层建筑与地基"的关系——NAS 框架构建在 DL 框架之上，负责"搜索逻辑"（空间、算法、评估调度），DL 框架负责"单次训练"（前向、反向、优化）。SOURCe 把通用 NAS 库描述为"构建在成熟的深度学习框架之上，如 TensorFlow、PyTorch"。理解分工，排查问题时就能快速定位：训练报错查 DL 框架配置，搜索流程报错查 NAS 框架配置，别在两个层面间乱猜。

上手路径：从 AutoKeras 到 NASLib 的三级跳

初学者直接上 NASLib 容易被"选择过载"淹没——模块太多，不知道从哪下手。推荐三级路径：第一级，AutoKeras——几行代码跑通一个完整搜索，建立"NAS 整体长什么样"的体感；第二级，NNI——用它的可视化界面观察搜索过程（哪个候选被评估、分数怎么变化），建立"搜索过程的动态感"；第三级，NASLib——这时你已经知道 NAS 有哪些环节，再逐个环节做定制（换空间、换算法、换评估）。三级跳的本质是"先整体后局部、先黑盒后白盒"——SOURCe 的建议"对于初学者，可以尝试使用 AutoKeras 或 Google Cloud AutoML 等易用性较高的工具"正是这个思路。

基准评测的正确用法

NAS-Bench 系列基准的用法有讲究。SOURCe 的描述：基准"预先计算了大量网络架构在特定数据集上的性能，并将其存储在一个数据库中"，研究者"通过查询数据库，快速评估新提出的 NAS 算法"。正确用法是：新算法在基准上跑"搜索"，搜出的架构去数据库查性能，与现有算法对比。注意三个限制：基准只覆盖固定搜索空间（你的算法要能在这个空间里跑）；性能是"预计算的真值"（与真实训练一致性取决于基准质量）；基准结果不能替代真实实验（空间的先验性太强）。把基准当"快速筛选器"用——先在基准上验证算法有竞争力，再上真实搜索。

五、FAQ：框架与工具的常见疑问

框架会不会限制 NAS 的"自由"？

会，但这是刻意设计的。框架通过抽象封装了细节，代价是灵活性受限——NASLib 比 AutoKeras 自由，但都比你手写代码受限。SOURCe 把框架的价值定位为"抽象复杂性、降低开发门槛"——用灵活性换开发效率是框架的默认交易。判断标准是"你的自由度用在哪"：如果你只需要在成熟方法里做配置，框架够用；如果你要探索全新的搜索范式（新的空间表示、新的评估理论），框架可能成为阻碍，那时手写反而更快。先想清楚"你要做配置还是做发明"，再决定用不用框架。

云平台 AutoML 的搜索结果可信吗？

可信但要打折扣。平台负责搜索和训练，返回的模型性能通常是经过验证的，但"搜索过程不透明"意味着你不知道它搜了什么空间、用了什么评估策略——出了问题难以诊断。SOURCe 对云平台的描述是"用户无需编写代码，即可通过上传数据集和配置参数，自动搜索并训练"——便利背后的代价是控制权的让渡。工程建议：平台适合"快速验证可行性"（先看 NAS 在你任务上有没有戏），不适合"追求极致与可复现"（那是开源框架的领域）。

NAS 框架需要什么硬件配置？

起步很轻。小规模 Cell 搜索（AutoKeras 默认配置）在单卡甚至 CPU 上就能跑，只是慢；DARTS 类搜索单卡数天；大规模进化搜索需要多卡并行。SOURCe 在选型考虑里提到"计算资源"——不同框架的默认算法对资源要求差异很大，选框架前先看它默认搜索算法的算力需求。务实的建议：先在单卡小空间跑通流程，确认方向后再申请多卡做大规模搜索，别一上来就追求"能撑起论文实验"的配置。

框架之间能混用吗？

能，但别硬拼。常见混用是"评估用一套、搜索用另一套"（比如用 NASLib 的搜索算法配 NNI 的评估器），接口不兼容时成本很高。SOURCe 对各框架的描述各有侧重（NASLib 模块化、NNI 多框架支持、AutoKeras 易用），混用前先确认数据格式和评估接口兼容。工程上更稳妥的做法是"主导框架定一个，其他当辅助"——比如主用 NASLib 做搜索，用 NNI 的可视化看日志，而不是让两套框架抢同一个训练流程的控制权。

• 三层生态：通用库（NASLib/NNI/AutoKeras）、专门平台（云 AutoML）、开源基准（NAS-Bench）
• 四组件：空间定义、搜索算法、性能评估、工作流管理
• NASLib 适合研究者：模块化，能加自定义空间与算法
• 基准免训练评估：NAS-Bench-101 有 423,624 个预评估架构
• 选型看角色：研究者要控制力，产品人要结果，初学者要门槛
• 七步流程：问题→空间→算法→评估→循环→训练→部署
• 预算先算后跑：评估成本×评估次数是启动前必算的账
• 最终架构必须完全训练：交付性能必须独立训练

至此六章走完：空间、策略、评估、高级主题、工具。教程的最后一句话留给你——把第 2-4 章的方法论装进第 6 章的工具，跑一次你自己的 NAS 实验，才是这本教程真正的结尾。

图6-1 NAS 工具链分层透视图