摘要

  • Microsoft 将 Dave Maltz 称为 Technical Fellow 和 Corporate Vice President，并称他是 Azure Networking 的工程负责人。该组织负责的软件和设备范围广泛，从面向客户的网络服务一直延伸至交换机和光学系统。
  • 他的研究记录持续追踪着跨代际的同一类整合问题：VL2 研究部署位置与网络结构设计，SNAP 研究诊断，SWAN 和 OneWAN 研究广域控制，CrystalNet 研究变更安全，AccelNet 则研究可编程 SmartNIC 卸载。
  • Microsoft 已公开的 Azure 研究涵盖 SONiC、DPU 和 2026 年的 DASH SmartSwitch 架构。这些研究表明，决定性问题越来越不是抽象意义上的软件或硬件之争，而是网络功能应当在哪一层运行。
  • Microsoft 的论文为相关系统和披露的部署提供了有力的一手证据，但这些材料不足以把 Maltz 视为唯一作者，也不能把有明确年份的网络规模数字转换为当前数量，或假定定制基础设施必然降低总成本。

Azure 网络首先是一个组织，其次才是一种拓扑

公有云网络通常被画成一张图：区域之间通过广域链路连接，数据中心内布满叶脊网络，客户虚拟网络叠加在物理基础设施上，边缘站点则连接互联网。这张图描述了路径，却没有说明要让这些路径保持可靠，需要怎样的组织；尤其是在成千上万项服务、不同代际的硬件和软件版本持续变化时。

Microsoft 当前对 Dave Maltz 的介绍格外明确地说明了这一组织范围。Microsoft 将 Maltz 列为 Technical Fellow 和 Corporate Vice President，并称他是 Azure Networking 的工程负责人。该组织开发、部署和运营网络安全服务、DNS、软件定义与物理网络控制、SONiC 交换机固件、数据中心网络，以及连接 Azure Public Cloud 与 Microsoft 365 的光学系统。其职责从客户 API 一直延伸至物理光纤。

这种广度改变了“运行”云网络的含义。没有哪位高管会亲自配置每一台交换机、审查每一次 DNS 发布，或选择每一个光学组件。真正重要的权力，是协调原本会分别优化不同层级的团队。虚拟网络服务可能需要新的策略原语；SmartNIC 团队必须判断它能否装入卸载处理流水线；交换机软件要暴露必要状态；网络结构必须在故障时承载流量；光学规划必须在服务需要之处提供容量；运营团队则必须能够发现这些环节何时协同失效。

传统网络采购会把许多决定分开：一家供应商提供路由器，另一家提供光学系统，第三家提供安全设备，第四家提供管理平台。运营商通过合同和标准进行集成。超大规模云服务商则能把更多技术栈纳入内部：编写控制软件、影响交换机固件、设计主机卸载，并把物理网络作为一个工程系统统一规划。

内部化同时带来杠杆与责任。拥有接口的组织可以跨层优化、响应新工作负载，并降低对供应商发布周期的依赖；但它也要承担原先由集成供应商负责的测试、供应链和事故处理负担。只有运营商能够跨越多个硬件世代持续配置人员并更新系统，定制系统才会成为资产。

Maltz 的重要性就在这一边界上。他的履历并不支持“一人设计 Azure”的英雄叙事，而是支持另一种判断：他的职业生涯大部分时间都在研究让大型网络能够作为完整系统被设计、测量、控制和测试的机制，如今则领导负责将这些机制投入运行的组织。

这一区别十分重要，因为超大规模网络从结构上就是协作产物。与 Maltz 相关的论文通常有很长的作者名单。生产系统依赖工程团队、硬件供应商、开源社区和运营人员，而这些人的工作不会完整体现在某位高管的职务中。他的角色最适合被理解为“对整合负责”：设定优先事项、建立组织接口，并对跨层结果承担责任。

动态路由研究提供了处理不完整信息的最初模型

Maltz 于 2001 年在 David B. Johnson 指导下获得 Carnegie Mellon University 计算机科学博士学位。他的博士研究涉及多跳无线网络的按需路由和 Dynamic Source Routing 协议。移动自组织网络在硬件和经济模式上与超大规模数据中心相距甚远，但它提出了一个持久的系统问题：当拓扑不断变化、没有任何参与节点掌握完全实时的全局视图时，节点应当怎样找到并维持可用路径？

这个问题反复出现在云网络中。中央控制器可能拥有广泛可见性，但其状态存在延迟；交换机知道本地队列，却不了解一条路径对服务级别的后果；端点能够观察延迟，却无法掌握所有原因；广域容量还会随故障和维护而变化。任何假定信息完整且即时的设计，最终都会撞上物理网络的现实。

因此，这些早期研究的重要性不在于提供直接蓝图，而在于训练分布式控制思维。路径发现、故障恢复和部分信息迫使设计者明确：哪些信息可在本地获知，哪些是推断所得，以及在这些假设错误时哪些行为仍必须保持安全。同样的纪律后来也出现在流量工程和网络验证中。

Maltz 后来加入 Microsoft Research。接触生产系统后，问题的规模随之改变。研究网络可以围绕实验布置监测，而商业服务产生的流量和故障模式并不是为方便分析而设计的，其中包含历史遗留选择、异构硬件，以及可能对同一症状作出不同解释的应用负责人。

这种环境推动了把测量与架构结合起来的研究。Microsoft 的研究人员不仅可以问某个协议在模型中怎样更高效，还能追问真实服务为何变慢、哪一种网络抽象限制了部署，以及当数千台机器或多条链路以实验室未曾出现的组合发生故障时，拟议变更会有何表现。

较早的个人简介提到他曾在 Massachusetts Institute of Technology 获得学位，但当前公开记录对 Carnegie Mellon 的博士学位和此后的 Microsoft 职业经历支持最充分。这个细节提醒人们遵守来源纪律：现有证据不支持的履历空白应当保持空白。系统研究记录足以支持基础设施叙事，私人信息和未经证实的简历细节则没有多少增益。

2010 年出现了一次重要职业转折：Maltz 从 Microsoft Research 转入 Bing，协助组建网络团队。这一步改变了激励结构。研究论文可以把主张限定在实验范围内，而生产团队在论文发表后仍要负责延迟、可用性、容量和成本。这次转变让受过研究训练的工程师进入了网络决策会立即产生商业后果的服务组织。

VL2 将数据中心网络重新定义为部署位置服务

2009 年的 VL2 论文是 Maltz 研究记录中的重要标志。它的核心问题并不只是怎样构建更快的网络结构，而是数据中心网络应当向上层应用提供什么服务。答案是一种部署位置自由：工作负载应能在可用服务器上运行，而不应因网络而被迫固定位置，也不应长期暴露于持续性的过度订阅瓶颈。

VL2 结合了类似 Clos 的物理拓扑、路径分散机制，以及将应用身份与物理位置分离的寻址模型。Valiant Load Balancing 把流量分散到可用路径，端系统解析机制则把服务地址映射到实际位置。该设计试图在服务器之间提供较为均衡的高容量，并让服务能够移动或重新分配，而无需围绕其位置重编整个网络地址。

论文包含一个由 75 台服务器构成的原型和范围明确的实验结果。它没有记录当前 Azure 的确切架构，也不应被追溯性地描述为完整的超大规模部署。它的意义主要在概念层面：网络被视为一个资源池，应使计算部署更加灵活，而不是由拓扑层级决定服务能放在哪里。

这种抽象会直接影响经济性。如果某些机架网络接入不佳，导致计算资源闲置，那么数据中心的实际可用性就低于服务器数量所暗示的水平。提供多条路径并分离身份与位置的网络结构可以改善利用率、简化服务扩展，并更容易绕过故障。但收益取决于流量模式、链路容量和控制质量，并不无条件保证每一种工作负载都获得“完全对分带宽”。

这种架构也把复杂性转移给端点和控制系统。扁平的服务寻址需要解析；多路径机制需要通过哈希或调度避免长期碰撞；故障必须被发现并反映到路径选择中；当数据包路线取决于分布式状态而非固定层级时，调试可能更加困难。部署位置自由是由软件创造的，而不是拓扑天然赋予的。

VL2 的长期影响在于，它把网络设计与云调度联系起来。当工作负载性能依赖集体通信或东西向流量时，计算、存储和网络无法彼此独立优化。网络由此成为部署位置契约的一部分。对 AI 集群而言，这一点更为重要，因为一条通信路径或一个端点表现异常，就可能拖慢整个作业。

Maltz 只是大型作者团队中的一位共同作者。论文的价值并不需要把每一种机制都归功于他。它表明，他当时的工作已经位于架构与运营的交界处：先利用测得的需求定义服务抽象，再构建足够完整的系统来检验这一抽象是否可信。

SNAP 将网络诊断视为跨层证据问题

设计高容量网络结构并不会让应用事故变得容易诊断。服务可能报告延迟，但底层原因可能是链路拥塞、网络接口故障、服务器过载、相隔数层的依赖项，或影响跨越组织边界的配置变更。仅靠设备计数器很少能识别服务层面的后果。

SNAP 通过在大型多层环境中关联应用与网络证据来处理这一问题。它研究了数千台服务器和数百个应用组件，尝试把观测到的性能与可能解释这些现象的路径和依赖联系起来。其方法的重要性在于否定了“某一个监测层掌握全部真相”的想法。

网络团队看到数据包、接口和路由；应用团队看到请求、队列和依赖。双方都可能正确理解本地数据，却对因果关系意见不一。跨层诊断需要一个共享模型，说明某个应用组件在某一时刻使用了哪条网络路径，以及故障或拥塞事件怎样影响服务。

这在技术上很困难，因为相关数据使用不同的时钟、标识符和保留策略。流记录可能聚合流量，应用追踪可能只对请求采样，拓扑状态会在观察与调查之间发生变化，服务器也可能迁移或被更换。相关性能够指出合理关系，却未必证明一个事件导致了另一个事件。

其运营价值在于缩小搜索范围。若系统显示多个故障服务组件共享同一条路径或同一设备，工程师就有了调查起点；如果网络并非共同因素，系统也可以帮助减少无效升级。目标不是创造全知的根因引擎，而是在团队之间建立更好的证据链。

这一诊断脉络延续到了后来 Azure 关于事故分派和运营系统的研究。在云规模下，告警数量可能超过工程师能够解释的范围。组织必须判断哪些信号指向共同故障域、哪个团队负责下一步行动，以及事后审查应保留哪些证据。

Maltz 当前的职责使这不再只是历史研究。一个横跨网络服务、物理设备和光学系统的组织需要跨层事故模型，因为自身边界就会产生交接风险。如果 DNS、虚拟网络、主机卸载和网络结构由不同团队负责，那么组织的运行体系必须在客户只看到一个症状时把这些团队的证据连接起来。

SWAN 与 OneWAN 揭示了中央优化的局限

数据中心间链路成本高、资源稀缺，而且很难迅速扩容。流量需求会随服务和时间变化，故障可能减少容量，却不会降低应用发送数据的需求。传统分布式路由可以保持连通性，但未必能按照业务优先级或全局效率分配广域容量。

2013 年发布的 SWAN 使用软件驱动控制来分配 Microsoft 广域网中的流量。它把高优先级流量与可以适应变化的流量分开，并尝试基于全局视图协调链路利用率。这套系统体现了超大规模服务商同时控制网络和大量工作负载的能力，因此可以对部分流量限速或重新调度，而普通传输服务商无法对相互独立的客户施加同样的控制。

中央控制的吸引力显而易见。控制器可以查看多条路径，把灵活流量从稀缺链路转移出去，为故障预留余量，并优先保障延迟后果最严重的服务。相比保守的静态配置，链路容量可以得到更高效的利用。

其局限同样是结构性的。控制器的视图永远不会完全实时；测量数据到达较晚，网络还可能在优化计算过程中发生变化。中央系统可能失效，也可能发布一种在模型中全局一致、却不符合物理状态的策略。安全运行因此需要备用路径、受限的变更范围，以及在控制器不可用时仍能保持连通性的分布式机制。

OneWAN 后来处理了多个广域控制系统和策略碎片化的问题。大型组织不会永远维持一个同质化 WAN，而会逐渐积累网络、控制器、流量类别和运营惯例。统一架构必须协调这些系统，不能假定它们都能一次性被替换。

从 SWAN 到 OneWAN 的演进体现了一种常见的云模式：第一代证明中央软件能够优化一个领域，下一代则必须整合多个优化器、处理遗留状态，并跨组织边界建立一致的运营方式。软件定义网络不会消除复杂性，只会改变复杂性的表达位置。

对 Azure Networking 而言，WAN 也是软件与资本最直观的交界处。光纤路线、光学容量和互联协议无法以软件速度改变。控制器可以更有效地使用现有链路，却无法在故障期间凭空创造物理多样化路径。因此，网络领导层必须把流量工程策略与长期容量和路线规划连接起来。

Maltz 的广域研究记录反复把利用率与韧性放入同一个设计问题。长期接近理论上限运行的网络看似高效，直到一条链路故障、容量下降。能够保障服务时，余量就不是浪费。正确的运行目标取决于故障概率、流量灵活性和延迟扩容的成本。

CrystalNet 把网络变更带入类似软件测试的环境

云网络持续变化。新的交换机固件、路由策略、访问控制列表、隧道和服务功能不断进入环境，而几台实验室设备无法复制其完整状态。依靠阅读配置和操作员经验的传统变更审查，无法适应超大规模网络中的交互数量。

CrystalNet 及相关网络验证研究把变更视为软件测试问题。生产网络或其中相当大的部分可以在受控环境中仿真；候选变更可以先在贴近实际的拓扑和配置上执行，再进入设备群。形式化和基于模型的方法可以检查既定属性，仿真则可以暴露抽象模型遗漏的实现行为。

模型与实现之间的区别至关重要。验证器也许能证明路由策略在模型中满足可达性，但交换机固件缺陷仍可能在实践中破坏模型。仿真器即使复现真实软件，也可能遗漏硬件时序、规模或故障组合。没有任何单一技术能够证明整个网络绝对安全。

价值来自多层控制。静态分析可以拒绝明显违反策略的变更；仿真可以运行实际软件并测试工作流程；金丝雀部署可以让有限生产流量先接触变更；遥测能够发现偏差；回滚则能限制损害。每一阶段的可信基础不同，捕获的错误类别也不同。

CrystalNet 还需要许多组织容易低估的基础设施。高保真仿真需要最新镜像、配置、拓扑、控制系统和具有代表性的流量。如果测试环境偏离生产环境，通过测试反而可能造成虚假信心。维护实验环境由此成为网络发布流程的一部分，而非一次性研究项目。

Maltz 与这项工作的联系进一步强化了组织主题。验证并不是网络团队买来后在最后一步使用的工具。产品团队需要表达意图，设备团队需要暴露状态，运营团队需要提供事故案例，领导层则要决定哪些属性会阻止部署。测试系统成为组织对可接受变更所订立的契约。

公开记录不会披露 Azure 的每一次中断，也不会说明当前验证的精确覆盖范围；安全和竞争约束使这种披露不太可能。可以站得住脚的结论是，Microsoft 的研究人员和工程师开发了旨在让网络变更通过更接近软件工程的保障流程。其成效应根据覆盖率、虚假信心和实际运营使用情况判断，而不能仅凭验证论文是否存在。

AccelNet 把虚拟网络处理从主机 CPU 转移到可编程硬件

虚拟网络会消耗计算资源。云主机必须对进出虚拟机的数据包执行封装、安全策略、负载均衡、计量和其他功能。当这些操作完全在服务器通用 CPU 上运行时，它们会与客户工作负载竞争，并可能造成性能波动。

2018 年 AccelNet 论文记录的 Azure Accelerated Networking，把虚拟网络数据路径的很大一部分转移到基于 FPGA 的可编程 SmartNIC 中。该设计试图保留软件定义网络的灵活性，同时在靠近网络接口的硬件上执行常见数据包操作。

其经济机制很直接。释放给主机的 CPU 周期可以出售或用于计算，而不是承担基础设施开销。由于数据包处理较少受到主机调度和工作负载竞争影响，卸载还可以使延迟和吞吐量更可预测。云服务商能够更新可编程流水线，而无需为每一次策略变化替换固定功能 NIC。

工程权衡则没有这么简单。硬件流水线的阶段、内存和时序都有限，需要一种可编译并安全更新的虚拟网络策略表示。其状态必须与控制平面保持一致。SmartNIC 故障可能影响主机上的所有工作负载，调试则要跨越主机、板卡固件、FPGA 逻辑和网络服务。

AccelNet 论文报告了相当规模的 Azure 部署，并称客户可用时间早于论文发表。这些数字属于当时，不能转换成 2026 年的设备群数量，也不能假定它们描述了后来的 DPU 世代。最有力的证据是：这是一份关于已部署架构以及在论文所述硬件和工作负载下测量结果的一手材料。

该系统标志着云基础设施的一项更广泛变化。网络功能的位置不再由简单的软件与硬件二分法决定，而是被拆分：一部分策略留在分布式控制器中，一部分在主机软件中，一部分在可编程 NIC 逻辑中，还有一部分在交换机中。最佳边界取决于延迟、更新频率、状态、安全要求和可用芯片。

这种划分也带来了长期兼容性问题。新的虚拟网络功能必须适配新旧卸载世代，或退回软件执行。设备群中可能存在多种板卡和主机配置，控制平面必须了解可用能力，并在不同配置之间保持一致行为。硬件加速可以降低每个数据包的处理成本，却会增加组织需要支持的变体数量。

Maltz 当前的组织职责正好覆盖这些边界。当 SmartNIC 的流水线实现面向客户的安全与网络语义时，它就不再是孤立的设备项目，而是服务契约的一部分。因此，决定卸载哪些功能时，必须与负责 API、可靠性和设备群生命周期的团队共同作出判断。

SONiC 使交换机软件成为运营商的战略层

传统物理交换机通常以集成产品形式交付，包括硬件、网络操作系统、命令行界面和供应商支持。超大规模服务商希望更直接地控制软件行为，并使用来自多家供应商的商用芯片。与 Microsoft 密切相关的开源交换机软件生态 SONiC，把软件栈从单一专有交换机平台中分离出来。

这种解耦可以扩大供应商选择。运营商能够在兼容硬件上开发统一的控制和管理环境，在上游检查缺陷与功能，并让自动化面向通用接口而非多套供应商命令行。凭借规模，超大规模服务商还可以要求芯片和平台供应商支持其软件模型。

解耦并不会让硬件完全可互换。不同交换 ASIC 提供的表项、缓冲区、遥测、队列和故障行为并不相同，平台驱动和抽象层必须映射这些差异。某项功能可能存在于 SONiC 中，却依赖供应商 SDK 或特定硬件能力。测试必须覆盖每一种受支持组合。

运营负担也会转移。集成供应商负责认证自家镜像和硬件；维护 SONiC 发行版的超大规模服务商则必须组装组件、管理版本、测试回归，并协调上游和供应商修复。结果可能更灵活，也更少受单一供应商锁定，但前提是运营商已经围绕交换机软件建立了内部产品组织。

不应把 Maltz 描述为 SONiC 的唯一创建者或所有者。它是一个由多家公司和众多工程师参与的社区项目。他的相关性在于，他领导的组织把交换机软件作为端到端网络的一层，并能通过部署规模和工程参与影响其优先事项。

开源也带来治理问题。其他供应商和运营商改进共享组件时，Microsoft 会受益；其他参与者也能受益于针对 Azure 规模问题开发的代码。但 Azure 的需求未必与小型网络相同，Microsoft 还可能保留上游不可见的下游差异。项目开放并不保证影响力平等，也不保证发行版完全一致。

其运营影响仍可能十分显著。交换机固件一旦成为运营商可控层，网络创新就不必等待供应商发布完整软件版本。这种速度有利于遥测、自动化和新型数据中心架构，但错误的软件决策也可能传播到庞大设备群。CrystalNet 用于网络变更的纪律，因此也成为交换机软件供应链不可缺少的一部分。

DASH SmartSwitch 追问哪些功能应放入机架顶部设备

2026 年的 SONiC DASH SmartSwitch 论文代表了卸载讨论的后续阶段。该架构没有把所有云服务功能都放在主机 SmartNIC 或 DPU 上，而是把部分功能移入交换机集成设计。论文描述了一条不可变、适合硬件实现的流水线，以及融合网络处理和 DPU 资源的“uni-box”方案。

它的吸引力在于整合。机架顶部设备可以服务多台主机，并可能减少重复的卸载硬件、能耗或空间。受约束的流水线能够以高吞吐量和可预测行为运行；需要生命周期管理的单主机加速器减少后，管理也可能简化。

限制则在于可编程性。不可变或严格定义的流水线比开放式可编程设备更容易验证和优化，却无法吸收每一种新功能。云服务持续演进，安全策略、封装和负载均衡行为的变化速度可能快于硬件。加速常用功能的设计必须为例外情况和未来需求保留安全路径。

论文报告了生产部署以及显著的性能或效率结果。这些是重要的一手披露，而不是独立的通用基准。公开记录没有说明完整部署地域、工作负载组合、比较基线，或系统其他部分承担的全部成本。交换机层面的收益可能需要更复杂的控制平面，或限制未来服务。

因此，该架构体现了 Maltz 职责范围内的核心工程问题：功能应在哪里执行？主机软件灵活、算力充足，但消耗 CPU 并增加抖动；SmartNIC 或 DPU 在服务器附近隔离工作且可以编程，却会增加硬件和设备群变体；交换机能够在多台主机之间共享加速并改善整合，但流水线更受限制，故障域也更大。

这个问题没有永久答案。工作负载、芯片和服务要求都会推动边界移动。组织需要一套决策方法：量化功能当前位置的成本，定义必须保留的语义，建模故障影响，测试新实现，并为不受支持的情况保留回退路径。

因此，DASH SmartSwitch 应被视为云网络持续重新划分过程中的一个世代，而不是交换与卸载的最终融合。其重要性在于表明，当设备群经济性足以支持时，Azure 愿意重新设计设备边界，而 SONiC 提供了能够整合这种重新设计的软件环境。

光学系统让软件组织无法假装带宽只是一种抽象

软件定义控制可以分配路径，卸载可以降低单个数据包成本，但云网络最终依赖物理链路。光纤路线、转发器、相干光学器件、交换机端口和电力决定容量有多少、能够部署在哪里。Microsoft 对 Azure Networking 的描述包含光学系统，正是因为软件层无法脱离这些约束单独规划。

光学容量的交付周期很长。控制平面功能可以在数周内部署，一条新路线却可能需要许可、施工、供应和测试。即使已经铺设光纤，转发器和线路系统的选择仍会影响传输距离、能耗和升级选项。冗余取决于物理路径多样性，而不是在同一管道中画出两条逻辑线路。

横跨软件与光学系统的组织可以把需求预测同网络设计联系起来：识别哪些服务正在推动流量，决定在哪里扩容，并构建能够利用真实拓扑约束的控制系统。它还可以协调维护，避免软件路由错误地假设物理网络具备并不存在的路径多样性。

公开记录没有提供 Azure 光纤、交换机或光学设施的完整地图，也不宜从“数拍比特连接能力”之类的表述中推断具体结构。这些说法能证明规模巨大，却没有披露拓扑、区域分布或备用容量。出于安全和商业敏感性而限制披露是合理的。

即使技术栈高度定制，供应链风险仍然存在。Microsoft 依赖晶圆代工、交换芯片、光学组件和制造能力。开放的交换机软件不会为专用光模块自动创造第二来源；定制 SmartSwitch 流水线还可能增加对特定芯片世代的依赖。基础设施领导层必须判断，定制在何处增强议价能力，又在何处缩小供应商范围。

电力是另一条物理边界。交换机、光学器件、NIC 和冷却系统会在客户工作负载运行之前消耗能源。把功能从主机 CPU 移到 DPU 或交换机，可能在一个设备中节电，却在另一个设备中增加能耗。真正相关的指标，是每单位系统总能耗所交付的有效服务，其中还要包括闲置容量和冗余。

Maltz 的组织职责表明，这些权衡应当被综合考虑。网络不是漂浮在可互换硬件上方的软件覆盖层，而是一个资本系统：软件决定物理资产能被多有效地使用，硬件则决定哪些软件抽象真正可信。

研究论文是证据，但大部分证据界面由 Microsoft 控制

Azure 网络研究极具价值，因为它描述了许多云服务商可能完全保密的系统。关于 VL2、SWAN、AccelNet、CrystalNet、OneWAN 和 DASH 的论文公开了架构、设计选择和范围明确的测量结果，让行业可以讨论具体机制，而不必只依赖营销说法。

但这些材料仍是发布方控制的披露。Microsoft 决定公开哪些系统、描述哪些事故，以及采用哪些基线比较。论文可以报告生产部署，却不说明设备群占比、涉及地点或后来遇到的运营问题。性能结果可以在测试范围内非常严谨，同时遗漏边界之外的成本。

这并不意味着证据不可靠。同行评审、详细方法和具名作者提供的支持远强于没有来源的产品页面。正确做法是让每项主张保持与其时间和范围相连。AccelNet 的百万主机数字描述的是 2018 年所报告的架构和设备群阶段；DASH 的生产声明描述的是 2026 年作者能够披露的部署。两者都不能转化为完整的当前普查。

同一规则也适用于 Maltz 的作者身份。论文把他列为共同作者，能够证明他参与了研究；除非论文明确说明，否则无法据此判断他实现了哪个组件或作出了哪项决定。他当前的职务证明组织责任，并不意味着他亲自创作每一项服务。归属应遵循证据形式，而不能被夸大。

独立比较十分困难，因为超大规模服务商公开的是各自网络的不同切面。Google 的 Jupiter 和 Andromeda 论文、AWS 的披露以及供应商的 DPU 基准，使用不同硬件、时期和工作负载。根据这些材料制作排行榜只会制造虚假精确性。更有价值的问题是：每家运营商控制哪些层，又选择公开哪些权衡。

运营保密造成了尚未解决的问责问题。客户依赖 Azure 网络，却无法检查其完整设计或事故记录。服务商提供服务承诺和经过选择的技术证据，客户则必须决定可以接受多少依赖，以及需要在服务商之外设置哪些多区域、多云或应用层控制。

对 Maltz 的人物分析可以说明这种结构，但不能假装把问题完全解决。他的角色表明 Microsoft 内部的工程问责位置。公开证据可以展现研究脉络和组织职责，却不能告诉外界每一项决定、预算或可靠性结果。这些限制是云模式的一部分，不是记者应靠推断填补的空白。

定制基础设施通过转移边界上的工作来改变成本

Azure 网络栈的经济理由通常通过效率机制来解释：Clos 网络结构可以改善部署位置和容量利用率；软件驱动的 WAN 控制可以更有效地使用昂贵链路；SmartNIC 可以把主机 CPU 还给客户工作负载；SONiC 可以扩大交换机供应商生态；验证能够降低错误变更的成本；SmartSwitch 可以整合卸载。

每种机制都有相应的内部成本。定制网络结构需要控制和运营软件；中央 WAN 控制器需要准确遥测和安全回退；SmartNIC 增加硬件开发和设备群管理工作；SONiC 需要集成与认证；验证环境必须持续维护；受约束的交换机流水线可能增加未来功能开发工作。

Microsoft 没有公开 Azure Networking 的完整成本模型，Maltz 的职务也不能说明预算或业务部门经济状况。声称某个系统按统一比例降低 Azure 总成本属于推测。论文可以证明在特定条件下获得了局部资源收益，但商业结果仍取决于硬件价格、工程人力、利用率、故障率，以及节省的资源有多少能转化为可出售容量。

潜在战略优势不只是单位成本，还包括学习速度。控制多个层级的服务商可以观察瓶颈、修改架构并部署结果，而无需等待供应商路线图。AccelNet 和 DASH 显示，随着硬件与工作负载变化，Azure 反复移动数据包功能的位置。能够在设备群规模上开展这种实验，会产生竞争者无法立即购买的知识。

其劣势是组织会依赖外界很少有人理解的系统。商业供应商把开发成本分摊给多个客户，并维护支持生态。超大规模服务商的定制设计可能缺少外部文档，人才范围也较窄。如果关键领导者或团队离开，公司必须在内部保存架构知识和运营纪律。

这就是为什么继任问题属于成本讨论。由定制控制平面、固件和卸载构成的网络不能依赖个人记忆。决策记录、接口、测试和所有权必须经得起组织重组。公开来源没有详细说明 Maltz 之下的授权结构，因此无法判断继任风险高低，但可以识别广泛职责所带来的结构性问题。

因此，云网络经济性不是简单选择定制或通用产品，而是决定在哪里定制。Azure 组合使用标准、商用组件、开源软件和专有系统。控制接口使其能够在选定层级替换或优化。总价值取决于组织维持这些选择的时间，能否超过当初为定制提供理由的硬件周期。

问责负责人既不是孤立的架构师，也不是象征性头衔

Technical Fellow 听起来可能像授予远离运营的研究人员的荣誉称号，但 Microsoft 当前对 Maltz 的描述并不支持这种理解。该称号与 Corporate Vice President 并列，并附有覆盖已部署服务和物理系统的明确工程职责。这一职位既是技术性的，也是组织性的。

这种组合反映了基础设施领导方式的广泛变化。过去的高级网络工程师可能主要负责路由设计、供应商选择和运营；在云服务商中，职责还包括分布式系统、安全、固件、可编程芯片、容量规划和供应链。一个领域的决定可能改变另一个领域面向客户的行为。

这一角色仍通过授权运作。网络安全、DNS、虚拟网络、SONiC、网络结构和光学系统都需要专业负责人。Maltz 的权力更可能通过架构审查、优先事项、组织设计和升级处理体现，而不是直接控制每一种实现。公开证据没有揭示确切决策权，因此不应对其作出具体推断。

他的研究背景为这一角色带来独特方法。与其职业经历相关的系统通常从测量或运营约束出发，定义新的抽象，构建可运行实现，再报告范围明确的结果。这种方法把理论与设备群证据连接起来，适合超大规模工程；但它也可能优先关注 Microsoft 能够测量和披露的问题。

因此，对其影响力最稳妥的评估应区分三种形式：论文署名说明他参与了有文献记录的系统；历史团队角色显示他从研究转入生产网络；Microsoft 当前资料则证明他对 Azure Networking 承担管理责任。三者共同支持“整合权力不断扩大”的叙事，却不支持把 Azure 的每项网络创新都归功于一人。

这种区分也保护了系统周围工程师和社区的贡献。SONiC 有社区治理；P4 和 Ethernet 标准由其他机构制定；硬件供应商制造芯片和光学器件；客户运行的应用行为塑造需求。Azure Networking 协调这些依赖，却并不拥有全部依赖。

领导力之所以有意义，正是因为这些依赖无法被压缩成一体。必须有人决定哪些接口由 Microsoft 控制、哪些采用标准、哪些外购、哪些留给上游社区。Maltz 的角色使他接近这些决定，而公开证据对其职责范围的说明，远比对内部决策过程的说明清楚。

DNS 与网络安全让客户直接看到 Azure 的职责范围

云网络最显眼的部分往往不是链路或交换机。客户看到的是名称能否解析、虚拟网络能否访问、安全策略是否得到执行，以及服务间流量是否沿预期路径运行。Microsoft 对 Maltz 所属组织的描述把网络安全和 DNS 与软件定义及物理控制并列。这一点很重要，因为面向客户的服务语义由此与底层基础设施处于同一工程链条中。

DNS 是一个接口看似简单的分布式依赖。应用请求名称并获得答案，但过程可能涉及权威数据、缓存、转发、私有区域、服务发现和策略。负责 DNS 的网络组织必须在控制平面变更期间保持可用，并区分命名故障与传输故障。路由系统可能完全正常，服务却因名称指向陈旧或错误信息而无法访问；反过来，DNS 事故也可能引发看似网络事件的流量转移。

安全策略带来类似的跨层问题。云客户可能通过网络安全和虚拟网络策略表达意图，平台则要把这些意图转换为主机、SmartNIC、交换机或服务设备上的执行措施。最安全的位置取决于延迟、状态、功能要求和故障行为。把执行放入可编程硬件可以减少 CPU 开销，但距离工作负载过远可能丢失身份上下文；在多个层级重复执行，又可能产生不一致判断。

工程挑战不仅在于某一条规则是否有效。云控制平面持续变化，资源不断出现和消失，地址会移动，租户会更新策略，区域服务也会失效。数据平面必须迅速获得正确状态，同时避免部分更新造成意外开放或中断。这需要版本管理、状态协调，以及判断某条连接由哪个策略版本处理的方法。

把 DNS、安全和物理网络置于同一个广泛组织之下，可以减少交接失误。设计虚拟网络的团队能够同实现主机卸载和运营网络结构的团队协调；事故负责人也可以跨层追踪依赖，而不必跨越多份供应商合同。这是超大规模自主控制的潜在优势。

同样的集中也会扩大组织假设的影响范围。共享身份模型、策略编译器或控制服务可能影响许多产品。集中化还会带来优先级冲突：一项改善某个服务的变更，可能给通用数据平面增加复杂性。问责负责人需要建立独立审查和服务特定例外机制，同时避免每个团队各自分叉平台。

公开证据没有揭示 Azure Networking 的内部所有权图谱或确切分工。可以支持的结论更为有限：按照 Microsoft 的描述，Maltz 的职责把面向客户的网络服务同执行这些服务的系统和设备连接起来。因此，组织整合是服务可靠性的一部分，而不只是内部汇报关系。

设备群发布让研究架构变成持续运营义务

许多与 Maltz 相关的系统最初通过研究论文介绍。VL2、SWAN、CrystalNet、AccelNet 和 2026 年的 DASH SmartSwitch 研究描述架构并报告范围明确的结果，但它们在生产中的意义取决于论文只能部分展示的流程：设备群资格验证与发布。

云服务商不能一次更新所有主机、交换机或区域。硬件世代不同，固件和驱动版本各异，客户工作负载还会使用原始评估未涵盖的功能。因此，新网络功能要依次经过实验室、仿真、金丝雀部署、选定集群和更广泛部署。每个阶段都需要继续推进的标准，以及回滚仍然可行的证据。

CrystalNet 与此相关，因为它把网络视为可以在变更前仿真和测试的系统。这类系统最有力的用途不是永久认证某项设计，而是把拟议状态与当前生产假设进行比较，生成故障案例，并发现变更负责人不知道的依赖。模型必须在事故后更新，否则就会变成让人安心、却已经过时的网络副本。

硬件卸载使发布更具挑战。AccelNet 把虚拟网络功能转移至 FPGA SmartNIC，后来的 DPU 或 SmartSwitch 设计延续了这种转移。过去可通过主机代理发布的软件修复，如今可能需要固件、设备重置或针对特定目标的验证。平台必须维持主机软件、设备程序与控制平面结构之间的兼容性。即使实现不同，混合世代也必须提供相同的客户语义。

设备群还会改变小缺陷的经济影响。内存泄漏、额外的数据包复制或控制平面重试，在单台机器上可能无关紧要，扩展到整个区域后却可能很严重。反之，如果基准性能提升增加了运营工作量或缩小供应商范围，也未必能降低总成本。因此，发布数据应涵盖返还给工作负载的 CPU、尾延迟、设备故障率、修复时间，以及维护多个世代的成本。

在这里，Maltz 作为工程负责人的角色不同于论文作者。负责开发、部署和运营网络的组织必须在论文发表后继续承担结果，决定何时证据已经充分、哪些性能回退可以接受，以及怎样遏制只在大规模环境中出现异常的设计。决定分布在不同团队中，但组织职责形成了明确的问责点。

公开记录支持生产导向研究的实例，也支持 Microsoft 对职责范围的描述，却没有提供独立设备群普查或内部事故史。因此，审慎的人物分析应把发布描述为连接这些工作的机制，而不能声称每篇论文中的架构都成为 Azure 的统一设计。

垂直整合改变供应商风险，而不是消除风险

Azure 对交换机软件、SmartNIC 逻辑和网络服务的控制，可以降低其对集成网络设备供应商的依赖。SONiC 将交换机软件与硬件分离，可编程设备则让 Microsoft 把功能放在架构需要的位置。这可以增强议价能力，并加快原本要等待供应商路线图的变更。

物理系统仍依赖供应商。交换 ASIC、NIC、DPU、光学器件、线缆和制造能力都来自外部生态。即使两个组件能够编译同一套开放软件，只要遥测、缓冲行为、故障模式或固件不同，它们就不完全可互换。云服务商编写的技术栈越多，承担的设备集成工作也越多，而这项工作过去由设备供应商负责。

因此，供应商多样性需要共同契约和持续测试。能够编译同一软件、却在拥塞时行为不同的第二来源并不是真正替代品。标称速率相同的光学器件，其传输距离、温度特性或故障表现可能不同；DPU 也可能通过不同控制模型提供相似功能。网络组织必须决定哪些差异可以接受，哪些必须对服务隐藏。

垂直整合还可能造成内部锁定。专有控制平面可能与某一硬件世代紧密结合，以至于更换供应商需要重新设计。如果内部接口缺少文档或由少数人掌握，它们也会像供应商接口一样形成约束。继任安排和工具由此也成为供应链问题。

战略优势并不是绝对独立，而是能够选择依赖放在哪里，并让更多接口变得可见。Maltz 的广泛职责把这些选择纳入同一个工程组织。真正的检验标准，是该组织在追求定制整合的性能收益时能否保留替代方案。

事故指挥必须跨越与架构相同的层级

垂直整合的网络栈会改变事故组织方式。客户报告连接中断，但直接症状可能源于 DNS、虚拟网络策略、主机卸载程序、交换机路由、光学故障，或分发状态的控制服务。只把问题交给某个设备团队可能延误诊断，因为每一层从局部看都可能合理。

端到端组织需要共享事件时间线，以及在不同层级之间转换后仍能保留的标识符。虚拟网络变更应能追溯到主机和交换机状态；SmartNIC 固件版本应与其执行的策略出现在同一次调查中；光学告警应与流量工程关联，而不是被当作独立设施记录。这并不要求建立一个万能数据库，但需要能够连接证据的接口。

指挥结构还必须保留独立质疑。当同一组织同时负责设计与运营时，其内部模型可能自我强化。构建控制平面的团队可能先把差异解释为遥测错误。独立的可靠性审查、故障注入和事故后分析可以降低这种风险。

Maltz 的广泛职责在原则上使这种整合成为可能，但公开材料没有披露 Azure 的确切事故流程。相关的领导力检验在于：组织广度是否缩短了从症状到责任层级的路径，以及经验教训是否转化为架构、测试和发布策略的变化，而不是只留在某个服务团队的事故复盘中。同样的重建原则适用于 Azure 的分层网络：一条具有代表性的客户流应当能够从 API 意图，一路追踪到控制状态、主机或设备执行、网络结构路径及光学依赖。这类演练可以在事故前暴露缺失的标识符和文档，并检验组织整合是否真正存在于证据层，而不只是体现在高管汇报线上。

下一代架构将根据它在哪些位置保留灵活性来接受检验

从主机软件到 FPGA SmartNIC，再到后来的 DPU 和交换机集成 DASH 流水线，这一序列表明 Azure 并不认为网络功能的位置是固定的。每一代设计都回应了 CPU 成本、延迟、能耗、硬件能力和服务变化之间不同的平衡。

AI 基础设施加剧了这种压力。大型加速器集群会产生高带宽、同步化流量，其性能取决于网络结构、传输和集体通信运行时，而网络同时还必须支持普通云服务。把某项功能移入硬件可能提高吞吐量，却限制新的拥塞控制或安全机制。架构必须在工作负载变化最快的地方保留足够灵活性。

证据没有指出唯一且永久的答案。约束更多的流水线可能高效且易于验证；可编程 DPU 能吸收新服务，却消耗电力和开发资源；主机软件可以迅速变化，但会与应用竞争。战略能力并不等同于选择某种设备，而在于组织能否移动边界，同时不改变客户语义或破坏运营稳定性。

这种能力依赖共同控制和证据。遥测必须显示成本和延迟出现在哪里；验证必须测试新的功能划分；SONiC 和其他软件层需要能够经受硬件变化的接口；光学和容量规划必须预判新设计将带来的流量。Maltz 职责中的各层共同构成一个决策系统，因为没有任何一层能够安全地孤立优化。

尚未解决的风险是整合可能演变为集中。控制完整技术栈的云服务商可以快速创新，但客户和供应商对由此产生的依赖了解更少。在内部，广泛的组织可以协调决策，但当多个层已经围绕某种架构构建后，质疑该架构也可能变得困难。

Maltz 的职业经历为理解这种张力提供了有用线索。VL2 追求部署位置自由，SWAN 追求容量控制，CrystalNet 追求更安全的变更，AccelNet 追求高效卸载，DASH 则追求新的整合点。每个系统都通过增加一层软件和组织来扩大控制。最终质量取决于这种控制能否继续被测试和撤销。

因此，“谁在运行 Azure 网络”并没有单一人物答案。Azure Networking 是一个横跨服务、控制系统、设备和物理容量的工程组织。Dave Maltz 是 Microsoft 公开确认的 Azure Networking 工程负责人，也是推动这一模式形成的多个系统中有文献记录的共同作者。他的重要性在于连接这些层级，也在于承担云服务商选择自主控制这些层级后产生的责任。