1. 项目概述如果你和我一样在云计算和高性能计算HPC领域摸爬滚打了十几年那么最近几年一定感受到了一个明显的趋势曾经泾渭分明的“云”和“超算”两个世界正在以前所未有的速度融合。云厂商开始在他们的数据中心里塞进GPU、FPGA和InfiniBand网络而传统的HPC社区也开始认真审视Kubernetes、容器这些云原生技术。在这个交汇点上一个看似“格格不入”的范式——无服务器计算Serverless Computing——正悄然崛起并试图重新定义我们构建和运行大规模、计算密集型应用的方式。无服务器计算或者说函数即服务FaaS其核心魅力在于极致的抽象和弹性。开发者只需关心业务逻辑代码函数而无需操心服务器、虚拟机或容器的生命周期管理。平台负责按需毫秒级地拉起计算资源用完后立即释放真正实现了“用多少付多少”。这对于处理科学模拟、AI模型推理、大数据分析中常见的突发性、高度并行化工作负载来说具有天然的吸引力。想象一下一个气候模拟任务需要瞬间启动上万个计算节点处理峰值数据之后又迅速归零传统HPC的静态资源池和作业排队系统在这里显得笨重而低效。然而把为短时、事件驱动的Web请求设计的无服务器模型硬塞进需要低延迟通信、状态共享和硬件加速的HPC、AI场景无异于方枘圆凿。冷启动延迟、函数间通信瓶颈、缺乏对GPU等加速器的原生支持、状态管理困难……这些都是横在面前的现实挑战。过去几年学术界和工业界的研究者们正是在试图攻克这些难题探索一条通向“高性能无服务器计算”的道路。本文正是对这一前沿领域的系统性梳理。我花了大量时间深入研读了2018年至2025年初的122篇核心文献试图为你厘清这个快速演进领域的全貌。我们将不满足于简单的概念罗列而是深入技术肌理拆解从加速器集成、新型架构设计到调度算法优化、领域专用框架的每一个关键环节。我会结合自己多年在分布式系统架构和性能调优方面的实战经验为你解读这些研究背后的设计哲学、权衡取舍以及那些论文里不会写的“坑”与“技巧”。无论你是正在评估无服务器技术用于科学计算的架构师还是寻找下一代AI平台解决方案的工程师抑或是单纯对技术趋势充满好奇的研究者这篇文章都将为你提供一份详实的“导航图”和“避坑指南”。2. 核心研究脉络与分类框架面对上百篇文献首要任务是建立一个清晰的认知框架。通过对现有研究的归纳我将其梳理为八个核心研究方向它们共同构成了高性能无服务器计算的技术拼图。理解这个分类有助于我们快速定位特定问题的解决方案现状。2.1 八大研究方向全景解读2.1.1 加速器支持从GPU虚拟化到异构计算抽象这是目前最活跃的领域之一占比约16.4%。传统无服务器平台如AWS Lambda早期几乎只面向CPU工作负载这严重限制了其在AI训练/推理、科学计算等场景的应用。研究的焦点是如何让短生命周期的函数安全、高效地访问昂贵的加速器资源。GPU支持方案演进早期方案多采用“远程调用”模式例如通过rCUDA让函数访问远程GPU集群或利用NVIDIA-Docker现为NVIDIA Container Toolkit在容器内直通GPU。这类方案实现简单但无法实现细粒度共享GPU利用率低且在多租户环境下存在安全隐患。近期的研究转向了细粒度虚拟化与分区。例如将KNIX框架与GPU管理器结合把物理GPU划分为多个虚拟GPUvGPU供不同函数并发使用。更深入的工作则直接利用NVIDIA的硬件级多租户技术多进程服务MPS允许精确控制流式多处理器SM的分配比例多实例GPUMIG则能将一块A100/V100等GPU物理划分为多个隔离的实例。一项基于ParslGlobus Compute的并行运行时的研究成功集成了MPS和MIG显著提升了深度学习负载的GPU利用率和吞吐。动态内核切片这是更激进的思路适用于计算图已知的场景如某些推理任务。它将一个大的GPU计算内核Kernel动态切分成多个小片允许多个函数以更细的粒度共享GPU计算资源。这需要运行时系统的深度支持以协调内核执行和数据依赖但在理论上有望实现极致的资源利用率。其他加速器探索FPGA因其可重构性在特定计算模式上能效极高。研究如Mantle和BlastFunction试图为FPGA设计一种“ disaggregated”解耦的共享架构通过部分重配置技术来减少FPGA镜像的加载时间以适配无服务器函数的快速启停特性。智能网卡DPU和神经网络处理器NPU也开始进入视野。例如Fuyao项目利用DPU来卸载函数间通信的控制平面实现基于RDMA的直接数据交换绕过CPU和操作系统协议栈大幅降低了通信延迟。Molecule项目则更进一步提出了“XPU-Shim”抽象层试图统一管理CPU、GPU、FPGA、DPU等多种处理单元让函数能透明地调用不同硬件后端。实操心得加速器选型的现实考量在实际项目中选择哪种加速器支持方案往往不是单纯的技术选优。如果你的团队对NVIDIA生态绑定深且负载以CUDA生态的AI推理为主那么基于MIG/MPS的方案是阻力最小的路径社区工具链也更成熟。如果你面临的是定制化计算逻辑如信号处理、加密FPGA可能是唯一选择但必须评估团队在硬件描述语言和工具链上的投入。DPU/NPU方案目前仍处于前沿探索阶段更适合有强大底层系统研发能力的大厂或科研机构普通团队建议保持关注但谨慎跟进。一个很现实的坑是许多云厂商对GPU的细粒度分割如MIG仍收取整卡的费用经济性需要仔细核算。2.1.2 平台与框架构建高性能无服务器的基石这是文献中占比最高的方向29.5%说明大家普遍认同“另起炉灶”或深度改造现有平台的必要性。通用无服务器平台如OpenFaaS, OpenWhisk并非为微秒级延迟和紧密耦合的并行计算设计。通信范式的革新高性能计算的命脉是低延迟、高带宽的进程间通信。传统无服务器通过对象存储如S3或消息队列进行函数间数据传递延迟在百毫秒级完全不可接受。因此新型平台的核心突破点在于通信。rFaaS是一个典范它基于RDMA远程直接内存访问重构了函数调用链路实现了微秒级的函数调用延迟让MPI风格的应用在无服务器环境下看到了希望。Faasm则另辟蹊径基于WebAssemblyWasm运行时通过“Faaslets”的概念让函数实例能在同一地址空间内安全地共享内存极大减少了数据复制开销特别适合迭代式机器学习算法。面向科学的联邦计算平台Globus Compute前身为funcX代表了另一条思路不试图取代HPC调度器而是与之共生。它提供了一个统一的API让用户能将函数提交到从本地HPC集群到公有云的各类异构后端上执行。其架构清晰分离了控制平面云服务和执行平面部署在目标资源上的Endpoint完美适配了科学计算中多机构、多资源池协作的联邦模式。我们在实际部署中发现它的关键在于与Slurm、PBS等调度器以及Singularity/Apptainer容器技术的无缝集成让科学家无需改变使用习惯就能享受到无服务器的弹性。专用框架的涌现在通用平台之上针对特定领域优化的框架层同样关键。例如Wukong它专注于在AWS Lambda上高效执行有向无环图DAG表示的工作流。其创新在于“去中心化、感知数据本地性”的调度器将DAG子图分发给多个Lambda执行器由它们自主调度任务避免了中心调度器成为瓶颈。对于机器学习推理INFless是一个与OpenFaaS深度集成的原生设计它内置了模型缓存、自适应批处理Batching和针对GPU的冷启动优化策略相比在通用FaaS上套一个外部服务层如使用API GatewayLambda端到端延迟和吞吐量有数量级的提升。2.1.3 调度与资源管理在动态与效率间走钢丝占比28.6%与平台框架研究紧密耦合。无服务器的核心承诺是弹性但如何为性能敏感型负载实现这种弹性同时保证资源利用率是个巨大挑战。冷启动缓解这是无服务器的“阿喀琉斯之踵”。对于HPC任务其调用模式可能毫无规律传统基于历史预测的预热策略常常失效。DayDream框架针对科学工作流提出了“热启动”概念预先启动一个通用的运行时环境池接到具体函数请求时再快速注入用户代码将环境准备与代码加载解耦。SMIless针对机器学习推理流水线DAG利用LSTM模型预测DAG中不同函数的调用链和间隔进行精准的层级式预热。而在平台层面Ilúvatar通过极简化的控制平面、Worker-centric架构以及智能的容器/网络命名空间缓存从系统层面削减了冷启动路径上的每一步开销。这些方案启示我们缓解冷启动需要“组合拳”算法预测何时预热、系统优化如何更快、甚至架构调整是否必须每次冷启动。函数与加速器调度这超越了简单的“放哪里”问题进入了“如何高效共享”的深水区。PALDIA这类框架在调度ML推理请求时不仅要决定放在CPU还是GPU上还要动态决策是否以及如何在多个推理任务间共享一块GPU通过MPS。它需要权衡任务排队延迟和共享带来的性能干扰Interference以在满足SLO的前提下实现成本最优。ESG调度器则更进一步它采用两阶段策略首先通过A*搜索算法为工作流中的每个函数确定最优资源配置如GPU内存、并行度然后再进行实际的资源绑定和任务放置。这种将“规划”与“执行”分离的架构更适合复杂工作流。混合执行与弹性伸缩纯无服务器并非万能。对于长时间运行或需要特定硬件的任务混合模式更具实用性。Mashup工作流管理器可以分析工作流中每个阶段的特性动态决定将其部署在本地虚拟机集群还是公有云无服务器平台上。iSeSA框架则利用机器学习模型来判断一个HPC或AI应用是否适合无服务器化并自动完成向云端的迁移和配置调优。这种“混合云混合执行模式”的思想很可能成为企业级HPC负载上云的最终形态。2.1.4 架构、范式与应用其余研究方向同样关键它们解决了“如何设计”、“如何编程”和“用在何处”的问题。架构创新资源解耦Disaggregation是数据中心架构的前沿。研究如Skadi和FragVisor探索了在内存、计算、存储解耦的硬件环境下如何设计无服务器运行时让函数能透明地访问远地内存池。软件资源解耦则是一种务实的HPC集成方案它允许无服务器函数“见缝插针”地运行在HPC集群中已被分配但未充分利用的节点上与传统的批处理作业共存提高整体资源利用率。编程模型与范式如何让习惯MPI、OpenMP的科学家用上无服务器FaaS Message Interface (FMI)在AWS Lambda上实现了类MPI的点对点和集合通信原语支持通过TCP打洞建立直接通道。Process-as-a-Service (PraaS)提出了“进程即服务”的抽象允许函数保持长生命周期的状态和直接的通信socket更像传统的分布式进程但保留了无服务器的资源弹性。这些尝试都在弥合编程习惯上的鸿沟。应用探索与建模文献中出现了大量将具体应用无服务器化的案例研究从地震成像反演、蛋白质结构比对到实时心电图分析。这些“探路”工作验证了可行性也暴露了问题。同时应用建模方向开始关注如何用TOSCA等标准描述语言来定义包含加速器需求的无服务器应用以及如何通过静态分析自动推荐最优部署架构如容器 vs. 函数这标志着该领域向工程化、自动化迈进。2.2 九大应用领域分布解析研究最终要落地于应用。通过对文献的归类我发现当前高性能无服务器计算的应用主要集中在三大板块通用并行计算密集型负载55.7%这是基本盘包括传统的科学计算任务、模拟仿真、参数扫描等。这些工作通常具有“令人尴尬的并行性”是无服务器弹性伸缩优势最能发挥的领域。机器学习与大数据合计约30%ML推理是当前最热的落地场景因其请求具有突发性、无状态性与FaaS模型高度契合。大数据处理如MapReduce、流处理则受益于无服务器对海量任务瞬间伸缩的能力但需克服Shuffle等阶段的数据交换瓶颈。新兴与垂直领域包括图处理、流计算、生物信息学、量子计算等。这些领域有独特的计算模式如图计算的迭代依赖、流计算的连续状态推动着领域专用框架如FaaSGraph, Laminar的发展。一个明显的趋势是研究正从早期的“可行性验证”Proof-of-Concept快速转向“性能优化”和“生产就绪”的系统构建。这表明高性能无服务器计算正在跨越鸿沟从学术构想走向工程实践。3. 关键技术深度剖析与选型指南了解了全景我们深入到几个最关键的技术战场。这里没有银弹只有权衡与选择。3.1 通信架构存储转发 vs. 直接内存访问函数间通信是高性能无服务器面临的首要挑战。我将主流方案分为三个层级其选择直接决定了应用的性能天花板。3.1.1 基于外部存储的通信最低性能最高通用性这是最原始的方式函数A将输出写入对象存储如S3或键值数据库如Redis函数B再从其中读取。AWS Step Functions、大多数基于标准FaaS的工作流引擎默认采用此模式。优点实现简单兼容所有无服务器平台数据持久化容错性好。缺点延迟极高通常100ms带宽受限于存储服务成本随数据量增长。适用场景异步、粗粒度、数据交换不频繁的流水线例如ETL作业中每小时批次处理的数据传递。3.1.2 基于消息队列或共享内存的通信折中方案使用如Apache Kafka、RabbitMQ或内存数据库如Redis作为消息中介。Faasm的共享内存模型也可归入此类但它是在同一节点上的函数间共享。优点延迟降至毫秒到十毫秒级吞吐量较高。消息队列还能提供解耦、削峰填谷的能力。缺点仍需经过一个中间件引入了额外的网络跳点和序列化/反序列化开销。需要自行管理中间件集群的可用性和扩展性。适用场景大多数数据流处理、事件驱动型应用。例如一个实时日志处理流水线各个清洗、分析函数通过消息队列连接。3.1.3 直接点对点通信最高性能最大挑战这是HPC的“灵魂”所在。rFaaS利用RDMAFMI通过TCP打洞ProxyStore抽象了多种后端包括UCX这种高性能通信库目标都是让函数能像MPI进程一样直接交换数据。优点微秒级延迟高带宽可逼近硬件极限。缺点严重依赖底层网络设施如InfiniBand破坏了无服务器函数的“无状态”和“位置透明”假设增加了平台复杂度安全隔离更困难。适用场景紧密耦合的并行计算如迭代式机器学习算法中的梯度同步、CFD模拟中网格区域间的边界数据交换。避坑指南通信模式选型决策树问延迟要求如果任务间延迟要求 100ms选方案一对象存储。如果在1ms - 100ms之间考虑方案二消息队列。如果要求 1ms必须挑战方案三直接通信。问数据量每次交换数据量 100MB对象存储的带宽成本可能成为瓶颈优先考虑消息队列或直接通信。问耦合度任务是否频繁同步是则倾向直接通信否则异步的消息队列或存储更合适。问生态绑定是否深度绑定某云厂商AWS Lambda用户可考虑Step Functions优化集成Azure用户可看Durable Functions追求多云可移植性则需选择开源方案如基于Redis或NATS的自建通信层。务实建议在项目初期优先采用高阶抽象如ProxyStore它允许你后期无缝切换通信后端。过早优化直接通信会带来巨大的开发运维负担。3.2 执行环境与隔离容器、微虚拟机与WebAssembly的抉择函数运行在什么里面这关系到安全性、启动速度和资源开销。容器Docker/OCI当前绝对主流。优点镜像生态丰富启动速度相对较快秒级资源开销小。缺点共享内核存在安全攻击面尽管有Namespaces/Cgroups隔离镜像拉取耗时在冷启动中占比高。微虚拟机MicroVM 如FirecrackerAWS Lambda的实际选择。优点基于KVM的强隔离安全性媲美完整VM。缺点启动时间比容器略长但仍可优化到百毫秒级内存开销稍大。WebAssemblyWasm新兴势力以Faasm为代表。优点启动速度极快毫秒级内存开销极小基于能力Capability的安全模型理论上更安全。缺点生态不成熟系统调用通过WASI支持有限对硬件加速器、多线程的支持仍在发展中调试工具链薄弱。Unikernel将应用与最小化操作系统库编译成单一镜像直接在Hypervisor上运行。优点极致的轻量化和安全隔离。缺点构建复杂调试困难生态匮乏。选型实战建议 对于绝大多数高性能计算场景容器仍然是当下最务实的选择特别是与Singularity/Apptainer这类HPC友好型容器运行时结合时可以方便地访问GPU和高速网络。如果你的应用对安全隔离要求极高如多租户的公有云服务且能接受稍长的启动时间微虚拟机是更稳妥的基石。WebAssembly非常适合作为嵌入式计算单元或插件系统例如在一个大型模拟程序中将用户自定义的、需要频繁调用的计算核Kernel编译为Wasm模块进行快速加载和安全执行。Unikernel目前更多是研究原型除非你有极强的系统定制能力和特定的安全需求否则不建议在生产中贸然使用。3.3 状态管理有状态函数的实现之道传统FaaS强调无状态但许多HPC/AI应用本质是有状态的如迭代算法的中间状态、流处理中的窗口状态。强行通过外部存储维护状态会带来巨大性能损失。目前业界主要有三种思路外部状态服务使用分布式缓存Redis、数据库或对象存储。这是最通用、最易实现的方式但延迟和一致性是挑战。平台内建状态抽象如Azure Durable Functions的“实体函数”或Faasm的“共享内存”。这提供了更优的性能和编程便利性但将用户锁定在特定平台或运行时上。“进程即服务”抽象如PraaS所倡导的将函数升级为长生命周期的“进程”在其生命周期内维持状态。这打破了FaaS“短时运行”的假设但更符合传统编程模型。经验之谈在设计有状态无服务器应用时我推荐采用“分层状态”策略。将频繁访问的、对延迟敏感的热状态如迭代计算的当前参数尝试放在平台提供的内存抽象中如果可用。将需要持久化、共享的温状态放在高性能分布式缓存中。将最终的、版本化的冷状态归档到对象存储。同时积极采用事件溯源Event Sourcing和CQRS模式将状态变更记录为不可变事件流这不仅能简化故障恢复也天然契合无服务器的事件驱动本质。4. 典型应用场景构建与优化实录理论需要实践检验。我们以两个最典型的场景为例拆解其架构设计和优化要点。4.1 场景一大规模机器学习推理服务需求部署一个计算机视觉模型应对突发且不可预测的在线推理请求要求99%的请求在100ms内完成且成本可控。传统方案痛点使用虚拟机或Kubernetes部署模型服务需要根据峰值流量预置资源在流量低谷时资源大量闲置成本高昂。自动扩缩容响应速度慢难以应对秒级爆增。无服务器优化方案架构选型采用“专用推理框架 FaaS平台”的协同设计如INFless on OpenFaaS。避免在通用FaaS上自建API网关和负载均衡器的复杂架构。冷启动攻坚模型预热利用框架的模型缓存机制将加载好的模型常驻在GPU内存中。结合历史流量预测如LSTH算法或实时监控在流量上涨前预先启动并初始化好一批函数实例。层级化模型准备一个精简版低精度模型和一个完整版模型。冷启动时先用精简版快速响应同时在后台加载完整版后续请求切换至完整版。PULSE系统就采用了这种动态降级策略。镜像优化使用多阶段构建Docker镜像剔除一切不必要的依赖将镜像尺寸压缩到极致。考虑使用Distroless基础镜像。吞吐量与成本优化动态批处理这是提升GPU利用率的王牌。推理框架应能动态地将短时间内到达的多个请求合并成一个批次送入GPU计算。需要精细调节批处理超时时间在延迟和吞吐间取得平衡。GPU共享在多个模型或多个租户间共享GPU。使用NVIDIA MPS实现时间片共享或使用MIG实现空间分区。需要调度器能感知GPU利用率并处理共享带来的性能干扰Noisy Neighbor。自动缩放策略不仅根据请求队列长度缩放还要结合GPU利用率、批处理效率等指标。设置合理的缩容冷却期防止在短时流量抖动下频繁启停实例。监控与调优必须建立完善的监控追踪冷启动率、批处理大小分布、GPU利用率、端到端延迟P50 P99。基于这些数据持续调整预热策略、批处理参数和缩放规则。踩过的坑我们曾在一个项目中直接使用云厂商的通用FaaS部署推理服务忽略了模型加载时间。结果冷启动延迟高达10秒以上完全不可用。后来切换到INFless这类集成方案并模型格式从PyTorch.pt转换为TensorRT.plan引擎不仅加载速度提升推理速度也翻倍。另一个教训是批处理超时设置过于激进5ms导致在高并发下形成了大量小批次GPU利用率始终上不去。后来根据请求到达的统计分布将其调整为20ms吞吐量提升了3倍。4.2 场景二参数扫描式科学计算工作流需求运行一个计算流体力学CFD模拟程序需要在上万个不同的输入参数组合下执行每个任务独立运行时间从几分钟到几小时不等。传统方案痛点在HPC集群上提交数组作业Array Job需要预估总资源并排队等待。短任务可能等待时间远超其计算时间资源利用率低。无服务器优化方案工作流分解将每个参数组合的计算定义为一个独立的无服务器函数。主函数或工作流编排器负责生成所有参数任务并触发。平台选择优先选择支持长运行时间如15分钟以上和高并发度的无服务器平台。AWS Lambda15分钟、Google Cloud Run60分钟或开源方案如OpenFaaS/Knative可自定义。数据管理输入数据将公共的仿真模型、网格文件等预先放置在高速对象存储如S3或共享文件系统如EFS/FSx for Lustre中。每个函数启动时根据参数从存储中读取所需输入文件。输出数据每个函数将结果直接写入对象存储并生成一个包含元数据如任务ID、状态、结果存储路径的记录到数据库如DynamoDB。中间数据尽量避免函数间传递大量中间数据。如果必须使用高性能共享存储或考虑4.1节提到的直接通信方案。容错与监控重试机制平台层通常提供函数执行失败后的自动重试。需要设置合理的重试次数和退避策略。检查点对于运行时间极长的任务接近平台最大超时限制需要在函数内部实现检查点机制将中间状态定期保存到持久化存储以便任务超时后能从断点重启。进度跟踪使用一个中心化的数据库或队列来跟踪所有任务的状态待处理、运行中、成功、失败。前端可以据此展示实时进度。成本控制无服务器按调用次数和运行时间计费。需要精确估算单个任务的平均运行时间和内存消耗选择性价比最高的内存配置。利用云厂商提供的资源使用报告定期分析成本构成优化函数代码和资源配置。实战记录我们曾为一个基因序列比对项目部署了类似方案。最初每个函数都从S3拉取巨大的参考基因组索引文件约4GB导致函数初始化时间长达2分钟。后来我们改用弹性文件系统EFS作为共享存储函数启动时通过文件系统缓存快速访问将初始化时间缩短到10秒以内。另一个优化点是任务分片对于某些可以进一步并行化的计算我们在单个函数内部使用多线程或进程池充分利用函数分配到的vCPU资源而不是盲目增加函数并发数这节省了约40%的综合成本。5. 未来挑战与研究方向研判尽管进展迅速但高性能无服务器计算要真正成为HPC和AI生产环境的主流选择仍面临几座必须翻越的大山。5.1 性能可预测性与性能隔离在共享的多租户无服务器平台上你的函数性能可能会受到“邻居”的干扰。虽然虚拟机或容器提供了隔离但共享的物理资源CPU缓存、内存带宽、网络带宽、GPU显存带宽的争用无法完全避免。这对于需要稳定性能的科学计算来说是致命的。未来的研究需要更精细的性能隔离保证和性能可预测性模型或许需要结合硬件特性如Intel RDT, AMD PQoS和调度策略来实现。5.2 调试与可观测性调试一个在云端瞬间生灭、由事件触发的分布式函数集合比调试一个在固定服务器上运行的单体应用困难得多。现有的分布式追踪系统如Jaeger, OpenTelemetry需要与无服务器平台深度集成能够跨函数、跨服务、跨存储追踪一个请求的全链路。特别是对于复杂的科学工作流需要可视化展示函数依赖、数据流、执行时间和资源消耗帮助开发者定位性能瓶颈和逻辑错误。5.3 安全与合规无服务器引入了新的攻击面函数代码本身、函数依赖的第三方库、临时凭证、与其他云服务的交互等。在科学计算中处理的数据可能涉及隐私或受管制数据。如何确保函数运行环境的完整性如何实现细粒度的、基于身份的访问控制如何满足数据不出境等合规要求这需要从函数开发、部署到运行的整个生命周期嵌入安全最佳实践。5.4 标准化与生态系统目前各大云厂商的无服务器服务API各异开源平台也各有侧重。这导致了严重的供应商锁定。虽然有了CloudEvents等标准试图规范事件格式但在函数签名、上下文对象、部署配置等方面远未统一。一个繁荣的生态系统需要通用的编程接口、打包格式和部署工具。CNCF Serverless Whitepaper和Knative等项目正在朝这个方向努力但前路漫漫。5.5 可持续发展与能效“绿色计算”日益重要。无服务器按需使用的特性理论上可以减少资源闲置从而提升整体能效。但频繁的冷启动、数据移动的额外能耗也需要纳入考量。未来的调度器可能需要将能源消耗作为一个优化目标在满足性能SLA的前提下智能地将函数调度到能效更高的硬件或数据中心区域。从我个人的观察来看高性能无服务器计算不会完全取代传统的HPC集群或Kubernetes而是会成为一种互补的、战略性的计算资源。它的定位将是处理突发性、不规则、易于并行化的负载以及作为混合架构中的弹性补充层。未来的计算基础设施很可能是一个融合了稳定持久的HPC批处理队列、灵活可编排的Kubernetes容器服务、以及极致弹性的无服务器函数的混合体。作为从业者我们的任务不是选边站队而是理解每种范式的优劣为具体的问题选择最合适的工具并设计出能让他们协同工作的优雅架构。这场由云原生技术驱动的HPC演进才刚刚拉开序幕。