FaaSMoE vs 相关论文：跨篇综合 #

相关论文 #

本篇选取 7 篇相关论文/系统，覆盖 MoE 推理执行优化、MoE 负载均衡、disaggregated serving、跨 DC prefill、多租户推理和多 LLM 编排，与 FaaSMoE 在"MoE 多租户资源共享"这一核心问题上形成多维对比。

ZeRO-Prefill (2605.02960) — FaaSMoE 的最直接技术对照。两者都观察到 MoE expert 存在"驻留但不活跃"的内存浪费，但解法方向截然相反。ZeRO-Prefill 用 AsyncEP（weight streaming）让每个 GPU 在每层都持有完整 expert 集合，消除 EP AllToAll 通信 [2605.02960]。FaaSMoE 走相反路线——将 experts 拆为 stateless FaaS 函数，scale-to-zero 消除不活跃 expert 的内存占用 [2604.26881]。ZeRO-Prefill 追求"所有 expert 本地可用"（以消除通信为目标），FaaSMoE 追求"仅活跃 expert 存在"（以消除冗余驻留为目标）。ZeRO-Prefill 用 NVLink AllGather 在 GPU 间流式传输 weights，依赖大 batch prefill 的 compute window 隐藏传输；FaaSMoE 用 HTTP invocation 在 CPU 上按需调用 expert 函数，依赖 FaaS 平台的弹性容器管理。两者的硬件层级完全不同——GPU-native vs CPU-serverless——代表 MoE serving 优化的两个极端。Kind: related。

MoE Load Balancing (moe-lb-interai25) — 与 FaaSMoE 共享 MoE routing imbalance 的问题认知，但解法层级不同。MoE-LB 用 ILP + heuristic 在 EP 框架内做 expert replication 和 reallocation，联合优化 load imbalance 和 data movement，实现 12.5% latency reduction [moe-lb-interai25]。FaaSMoE 通过 FaaS 的弹性 scale-out 天然处理 imbalance——热门 expert 自动被 FaaS 平台扩容、冷门 expert scale-to-zero。MoE-LB 在同步 EP 框架内做优化（每次 rebalance 需要搬运 expert weights），FaaSMoE 将 experts 部署为无状态函数直接消除了 rebalance 需求。但 MoE-LB 运行在 GPU 上、面向生产规模 MoE 推理，FaaSMoE 是 CPU-only 原型——两者的适用规模和性能层级差距巨大。Kind: related。

DynaServe (2504.09285) — 共享"multi-tenant serving 资源效率"主题，但面向不同层级。DynaServe 用微请求（micro-request）在任意 token 边界分割请求，自适应统一 colocation/disaggregation，实现 1.15–3.07× serving capacity 提升 [2504.09285]。FaaSMoE 的 multi-tenancy 是"跨租户共享同一组 expert 函数"——一种更粗粒度的资源共享。DynaServe 的 SLO-aware batching 在 GPU 上精细管理 prefill-decode 干扰；FaaSMoE 没有任何延迟优化（延迟未测量）。DynaServe 代表 GPU-centric 的精细化 serving 优化，FaaSMoE 代表 compute-agnostic 的架构解耦。Kind: related。

PrfaaS (2604.15039) — FaaSMoE 与 PrfaaS 共享"将计算从主推理路径 offload 到外部集群"的架构思想。PrfaaS 把长 context prefill offload 到跨 DC 的 compute-dense 集群，通过 hybrid attention 降 KV 吞吐使跨 DC 传输可行 [2604.15039]。FaaSMoE 把 expert computation offload 到 FaaS 平台——概念上也是将 stateless 计算分离到独立资源池。但 PrfaaS 面向生产规模（32 H200 + 64 H20，+54% 吞吐）[2604.15039]，有精确的 throughput model（Eq.1–8）和双时间尺度调度器。FaaSMoE 是纯原型验证（6 tenants、CPU-only、30 requests），缺乏任何形式化模型。两者的架构理念相近（分离 stateless compute），但成熟度差距约 2–3 个数量级。Kind: related。

Scepsy (2604.15186) — 与 FaaSMoE 共享 multi-tenant 多模型部署的关注点。Scepsy 用 Aggregate LLM Pipeline 为多 LLM agentic workflow 自动分配 GPU 资源，实现分数 GPU + 拓扑感知放置，相对 K8s autoscaler 拿到 2.4× 吞吐 [2604.15186]。Scepsy 的 fractional GPU 思想与 FaaSMoE 的 expert-level 共享在目标上一致——都想避免为每个租户/workflow 分配完整模型副本。但 Scepsy 在 GPU 上做 fine-grained MPS 隔离，FaaSMoE 依赖 FaaS 平台的容器级隔离。Scepsy 处理的是多 LLM 协同（generator + verifier），FaaSMoE 处理的是同一 MoE 模型内部的 expert 共享。Kind: related。

SPECTRE (2605.08151) — 共享"多租户推理中复用空闲资源"的设计哲学。SPECTRE 将空闲的 tail-model GPU 复用为 speculative drafter，用 hybrid ordinary-parallel decode + 闭式阈值 $r^$ 实现 2.28× AR 加速 [2605.08151]。FaaSMoE 将 MoE experts 部署为共享函数，多租户复用同一 expert pool。两者的共同洞察是：多租户场景中总存在空闲资源（SPECTRE 的 tail-model GPU、FaaSMoE 的不活跃 expert），系统应该将其转化为共享收益。但 SPECTRE 有精确的吞吐模型和在线 mode switching（$r^$ 闭式解），FaaSMoE 缺乏任何性能模型。SPECTRE 在 SGLang 上产线级实现，FaaSMoE 在 tinyFaaS 上原型验证。Kind: related。

DeepSeek-V3 (2412.19437) — FaaSMoE 评估模型 Qwen1.5-MoE-2.7B 继承了 MoE 的稀疏激活范式，而 DeepSeek-V3 代表了这一范式的生产巅峰（256 routed experts、64-way EP、auxiliary-loss-free load balancing + DualPipe all-to-all 完全隐藏）[2412.19437]。FaaSMoE 的核心观察——"expert activation 结构上同构于 serverless function invocation"——在 DeepSeek-V3 的 256-expert 规模下更有说服力（256 experts × 6 tenants = 1536 expert slots 但只有 top-8 × 6 = 48 活跃），但也面临更大挑战（HTTP invocation overhead × 130+ MoE layers）。FaaSMoE 未在任何 GPU MoE 或大规模模型上验证，其"MoE ≅ FaaS"的结构映射仍停留在概念层面。Kind: baseline。

本篇 vs 相关论文的 delta #

FaaSMoE 的核心 delta 是 将 MoE expert 的 stateless 特性与 FaaS 的 event-driven scale-to-zero 特性做结构映射，提出 orchestrator-expert 二平面解耦 + 可配置 expert-block 粒度的框架，在多租户场景下消除 per-tenant expert 冗余驻留 [2604.26881]。

维度	FaaSMoE	ZeRO-Prefill	MoE-LB	DynaServe	PrfaaS	Scepsy	SPECTRE
核心问题	多租户 expert 冗余驻留	MoE EP 三重冗余	EP routing straggler	PD 干扰隔离	跨 DC prefill offload	Multi-LLM GPU 分配	空闲 GPU 复用
核心方法	Expert → FaaS 函数	AsyncEP (weight streaming)	ILP expert replication	Micro-request + APS	长度阈值路由 + 双时间尺度调度	Aggregate LLM Pipeline + 3D search	Hybrid ordinary-parallel decode
形式化模型	无	饱和阈值 T = t_EP × F_GPU × γ	ILP formulation + poly heuristic	二分搜索 + profile table	6 个解析方程 + 双时间尺度	$L_w/T_w$ 解析式 + 3D 枚举	$r^*$ 闭式阈值
硬件	CPU-only	GPU (NVLink)	GPU (scale-up)	GPU (RDMA)	GPU (跨 DC Ethernet)	GPU (NVLink pair)	GPU (ZMQ)
评估规模	6 tenants, 30 requests	8×A100/H100/H200	micro-benchmark	4–8×A100, 4 workloads	32 H200 + 64 H20	16×A6000, 2 workflows	TP1/TP8, 5 benchmarks
Multi-tenant	核心关注	无（单租户）	无	部分（混合负载）	无	多 workflow	核心关注
延迟测量	无	无（throughput-only）	有	有（P99 TBT < 100ms）	有（P90 TTFT）	有（E2E latency）	有（Tok/s）
开源	是（GitHub）	是（vLLM flag）	否	否	否	是	是（SGLang PR）

FaaSMoE vs ZeRO-Prefill — 消除冗余的两个极端方向。ZeRO-Prefill 消除冗余的方式是"让每个 GPU 在每层都有完整 expert 集合"——all experts local，zero communication [2605.02960]。FaaSMoE 消除冗余的方式是"只让被激活的 expert 存在"——minimal expert residency，on-demand invocation [2604.26881]。两者的设计假设相互矛盾：ZeRO-Prefill 假设"HBM 充足以容纳全部 expert weights + 当前层全量 weights"（这在 GPU 上可行但内存成本高），FaaSMoE 假设"expert invocation overhead 可接受"（HTTP 调用延迟 vs local dispatch）。ZeRO-Prefill 在 H100 上实测 MFU 29.8–36.2% [2605.02960]，FaaSMoE 在 CPU 上甚至未测量吞吐和延迟——两者的成熟度差距使得直接性能对比不可能，但架构思想的对比极有价值：前者优化 single-tenant execution efficiency，后者优化 multi-tenant resource sharing。

FaaSMoE vs MoE-LB — scale-to-zero vs dynamic replication 的成本模型对比。MoE-LB 面对 routing imbalance 的解法是在 EP 内"搬运 expert weights 到负载更轻的 device"，核心挑战是 data movement overhead [moe-lb-interai25]。FaaSMoE 的 FaaS 模式天然处理 imbalance——热门 expert 函数由平台自动扩容。但 FaaSMoE 的"函数调用"本身引入了 MoE-LB 不需要面对的全新开销：序列化/反序列化 hidden states × 24 MoE 层 × per-token routing。在 GPU 上 expert computation 是 μs 级（高度优化的 GEMM），FaaS invocation 包含容器调度 + HTTP 解析 + tensor 序列化，量级至少 ms 级——比 computation 本身慢 1000×+。MoE-LB 的 12.5% 延迟改善 [moe-lb-interai25] 虽然温和但来自 GPU 上的真实优化；FaaSMoE 的"<1/3 资源"来自 CPU-only 原型上的资源度量 [2604.26881]，不包含延迟影响。

FaaSMoE 的 expert-block 粒度 vs ZeRO-Prefill 的 frontend-backend T — 两种控制旋钮的对比。FaaSMoE 发现 expert block size 存在 U-shaped 内存曲线（最优 k=20）[2604.26881]，但没有解析模型解释为什么。ZeRO-Prefill 的 T = t_EP × F_GPU × γ 是一个从物理量推导的精确控制旋钮 [2605.02960]。这反映了两篇论文在方法论上的层级差异：ZeRO-Prefill 建立了可推导、可验证的性能模型，FaaSMoE 的"最优 block size"依赖纯经验 sweep。PrfaaS 同样建立了 6 个解析方程做最优 $t$ 和 $N_p/N_d$ 求解 [2604.15039]，SPECTRE 导出了 $r^*$ 闭式解 [2605.08151]——当代框架论文的 bar 是"有可推导的性能模型"，FaaSMoE 在此维度上显著落后。

可攻击面 #

以下攻击针对 FaaSMoE L2 中的具体论证步骤和声明。

Attack 1: "MoE ≅ FaaS"的结构映射忽视了 MoE 的 per-layer 同步语义

FaaSMoE 的核心 insight 是"MoE expert activation 结构上同构于 serverless function invocation"——两者都是 stateless、sparse、event-driven [2604.26881]。这个映射在单层 MoE 内成立，但忽视了 MoE 推理的关键约束：24+ 层的 MoE 层是串行依赖的——layer $i$ 的 expert 输出是 layer $i+1$ 的 attention 输入。这意味着 orchestrator 必须在每层等待所有 expert function 返回后才能进入下一层。FaaS 平台为低频 event-driven 工作负载设计（web API、ETL），其调度粒度是 10–100ms 级别；MoE 推理需要在 ms 级内完成 per-layer dispatch-compute-gather 循环。24 layers × HTTP round-trip = 至少 24 × 数十 ms = 数百 ms overhead，而 GPU 上同样的 24 层 MoE forward 仅需数十 ms。论文没有测量延迟，这不是无心遗漏——因为延迟数据几乎必然暴露 FaaS invocation overhead 是 expert compute time 的 10–100×。FaaS 的 scale-to-zero 优势需要与这个延迟代价权衡，而论文只展示了资源节省（<1/3 资源）[2604.26881] 而完全回避了延迟代价。

Attack 2: Baseline 是 straw-man——"full model per tenant"在 2026 年不是任何生产系统的做法

FaaSMoE 的 baseline 是"每租户部署完整 MoE 模型"——6 tenants × Qwen1.5-MoE-2.7B = 6 个独立模型实例 [2604.26881]。这是一个极度弱的 baseline。2026 年的生产 MoE serving 系统早已支持 共享模型实例 + multi-tenant routing——vLLM 的 continuous batching 天然服务多租户（不同租户的请求共享同一模型实例和 KV cache pool），SGLang 的 RadixAttention 更进一步共享 prefix KV。在 vLLM/SGLang 的共享实例部署下，6 tenants 只需 1 个模型实例，内存 = 单模型 + 共享 KV cache pool ≈ 36 GB（vs FaaSMoE-Shared 的 72.25 GB）[2604.26881]。论文没有与 shared-instance 部署对比，使得 "<1/3 资源" 的声明失去参考意义——相比真实 baseline，FaaSMoE 的资源使用可能反而更高。DynaServe [2504.09285] 和 SPECTRE [2605.08151] 都以 vLLM/SGLang 的共享服务为 baseline，FaaSMoE 选择 2020 年代初的"per-tenant replication"作 baseline 是 methodological regression。

Attack 3: CPU-only 评估使所有 serving 相关结论不可外推到 GPU

FaaSMoE 在"CPU-only server, 300 GB RAM, no GPU"上评估 [2604.26881]。MoE 推理的核心计算——expert FFN forward pass——在 GPU 上是 compute-bound（高度并行化的 GEMM），在 CPU 上是 bandwidth-bound（sequential matrix multiply）。CPU 上的 expert computation 耗时比 GPU 慢 100–1000×，这改变了所有 overhead 的相对权重：FaaS 的 HTTP invocation overhead（~10ms）在 CPU 上被 expert compute time（~100–1000ms）掩盖，但在 GPU 上（expert compute ~0.1–1ms）HTTP overhead 成为绝对瓶颈。论文声称"FaaS platform overhead is modest relative to expert execution time" [2604.26881]——这只在 CPU 上成立。在 GPU 上，FaaS overhead / expert compute ≈ 10ms / 0.1ms = 100×，overhead 完全淹没 computation。论文的一切定量结论（<1/3 资源、U-shaped 曲线、block size 最优 20）都绑定 CPU 执行特征，不可外推到 GPU。这是一个 fundamental validity threat——MoE serving 在 2026 年几乎没有 CPU-only 的生产用例。

Attack 4: 评估规模微小——6 tenants × 5 tasks = 30 requests 不构成统计有效性

30 个请求（6 tenants × 5 tasks from BIG-Bench）无法建立任何有统计意义的性能结论 [2604.26881]。对比：ZeRO-Prefill 评估 73.8K requests [2605.02960]，PrfaaS 使用 truncated log-normal 分布模拟连续到达 [2604.15039]，DynaServe 使用 BurstGPT/Azure Code 等真实 trace [2504.09285]，SPECTRE 跨 3 个模型对 × 5 个 benchmark × 3 个 batch size 评估 [2605.08151]。FaaSMoE 的 30 requests 不构成 workload characterization——无法观察到 cold start behavior、expert contention under load、FaaS platform scheduling noise、或 tail latency distribution。特别是 FaaS 系统最关键的性能指标——cold start latency——在论文中完全未测量。tinyFaaS 的 cold start 是 10–100ms 级别，对 per-layer expert invocation 来说可能是致命的。

Attack 5: 论证链 Step 3→5 的跳跃——从"expert 是 stateless"到"expert 可做 FaaS 函数"缺少性能可行性论证

论文的论证链（L2 §6）从"expert computation is stateless and independent"（Step 3）跳到"expert blocks as FaaS functions enable shared expert pool"（Step 5），中间的 Step 4 仅声称"FaaS platforms provide on-demand scale-to-zero" [2604.26881]。这个跳跃忽略了一个关键问题：stateless ≠ suitable for FaaS。任何纯函数理论上都是 stateless 的（包括矩阵乘法），但 FaaS 适用性还要求：(1) 调用频率足够低以分摊 cold start（MoE per-token routing 的调用频率是 kHz 级，远超 FaaS 设计假设的 Hz 级）；(2) 函数执行时间远大于调度开销（GPU expert forward 的 0.1ms vs FaaS scheduling 的 10ms）；(3) 调用模式足够 sparse 以受益于 scale-to-zero（top-k=4/60 的稀疏度在 aggregate 下不够——6 tenants 同时活跃时几乎所有 expert 都被激活）。论文没有论证这三个 FaaS 适用前提中的任何一个。

Attack 6: 缺失的冷启动概率分析——在 expert activation 分布下 scale-to-zero 的真实收益存疑

FaaSMoE 的核心价值主张是"不活跃 expert scale-to-zero 节省资源"。但 MoE 的 expert activation 分布通常呈幂律——少数 hot expert 承担大部分流量，大量 cold expert 偶尔被激活 [2605.02960]（ZeRO-Prefill 报告 max/min expert load 达 16.15×）。在多租户场景下，不同租户的 hot expert 集合可能不同但有重叠——aggregate activation rate 比单租户更高。给定 Qwen1.5-MoE-2.7B 的 60 experts / layer 和 top-4 routing，6 tenants 的 expected unique expert activation per batch ≈ $60 \times (1 - (1-4/60)^6)$ ≈ 20–30 experts（即 33–50% experts 活跃）。如果 FaaS 的 keep-alive 窗口大于 inter-batch arrival interval（通常 <1s），几乎所有 expert 函数都会保持 warm——scale-to-zero 的节省消失。论文没有分析 expert activation 分布和 keep-alive 策略的交互，这恰好是其价值主张的核心地基。

生态位 #

范式定位：FaaSMoE 代表一个概念性的极端——将 serverless 的 event-driven、pay-per-use、scale-to-zero 理念应用于 MoE 推理中的 expert computation。这个"MoE ≅ FaaS"的结构映射是有启发性的：MoE 的稀疏激活（只用 top-k experts）确实与 serverless 的按需调用在语义上同构。但当前形态的 FaaSMoE（CPU-only、HTTP invocation、tinyFaaS）距离 production viability 极远。

在 framework category 的 taxonomy 中（category survey §2），FaaSMoE 属于 Serving-MoE × Execution/Runtime 象限，但其 execution mode（CPU serverless）与该象限的现有工作（ZeRO-Prefill 的 GPU weight streaming、MoE-LB 的 GPU expert replication）完全不在同一硬件层面。

与 framework category 现有系统的关系：

生态位	方案	FaaSMoE 的独特价值	FaaSMoE 的致命短板
MoE serving execution	ZeRO-Prefill (AsyncEP)	架构解耦（control/compute 分离）	CPU-only，延迟未测量
MoE load balance	MoE-LB (ILP replication)	天然弹性（FaaS scale-out）	无 GPU 验证，invocation overhead
Multi-tenant serving	SPECTRE (hybrid decode)	Scale-to-zero for cold experts	30 requests 评估，baseline 是 straw-man
Multi-LLM orchestration	Scepsy (Aggregate Pipeline)	Expert-level 而非 model-level 共享	无性能模型，无形式化分析
Disaggregated serving	PrfaaS / DynaServe	新颖的解耦维度（expert vs model）	缺乏 throughput model，scale 1000× 不足

竞争力评估：FaaSMoE 在 framework category 中几乎所有量化维度上都落后于现有工作。category survey §4 对比表中的"核心指标"列要求实测吞吐/延迟——FaaSMoE 缺少延迟测量。§4 的"代码开源"和"可复现性"列中 FaaSMoE 有代码开源（GitHub），但 CPU-only 环境下的复现不具有 MoE serving 的参考价值。category survey §5 Strength-Weakness Matrix 中，FaaSMoE 的 strength 是"概念创新性（MoE ≅ FaaS 映射）"，weakness 是"缺乏 GPU 验证、production-irrelevant baseline、无延迟/吞吐量化"，best-for 场景极窄："MoE multi-tenant CPU-only 部署的概念验证"。

定位判断：FaaSMoE 更像是一篇 position paper / PoC 而非 systems paper——其核心贡献在于提出"将 FaaS 范式应用于 MoE expert management"的概念，而非提供可行的系统实现。与 category survey 中的生产级系统（DualPath、ZeRO-Prefill、PrfaaS、TileRT）或严谨的学术系统（DynaServe、JITServe、SPECTRE）相比，FaaSMoE 在方法论严谨性、评估规模和硬件相关性上存在显著差距。但其"MoE ≅ FaaS"的概念对未来 MoE serving 架构设计有启发价值——特别是在 expert-level disaggregation 和 multi-tenant expert pool management 方向。

未探索方向 #

方向 1: GPU-native expert-as-a-service——用 CUDA kernel 替代 HTTP function

FaaSMoE 的核心瓶颈是 HTTP invocation overhead vs expert compute time 的失配。将"expert function"从"HTTP-invoked container"改为"GPU kernel service"可彻底消除此瓶颈：expert 以 persistent CUDA kernel 形式驻留 GPU HBM，orchestrator 通过 shared memory / RDMA doorbell 触发 expert execution（μs 级），expert 完成后通过 event signal 通知 orchestrator。这保留了 FaaSMoE 的架构解耦（control plane / compute plane 分离），但将通信从 ms 级 HTTP 降到 μs 级 GPU IPC。Fleet 的 hierarchical megakernel [ref:2604.15379] 和 GPUOS 的 persistent kernel [ref:2604.17861] 提供了"长期驻留 GPU kernel"的执行模型；expert-as-a-kernel 可以看作 FaaSMoE 概念在 GPU 原生实现上的自然延伸。scale-to-zero 在 GPU 上的等价物是"expert weights evict to host memory, on-demand H2D 预取"——ZeRO-Prefill 的 hybrid offloading 已经验证了这条路径 [2605.02960]。

方向 2: FaaSMoE 的 block granularity + ZeRO-Prefill 的 popularity-aware streaming 的混合

FaaSMoE 发现 expert block size 存在 U-shaped 优化曲线（k=20 最优）[2604.26881]，ZeRO-Prefill 全量 streaming 所有 expert weights。混合策略：将 experts 按 activation frequency 分为 hot/warm/cold 三层——hot experts（top 10%）永驻 GPU（无 streaming overhead），warm experts 按 block 做 ZeRO-Prefill 式 weight streaming（利用 compute window overlap），cold experts 按 FaaSMoE 式 on-demand invocation（利用 FaaS 弹性）。FaaSMoE 的 expert-block 粒度概念（k experts/block）可用于定义 warm 层的 streaming 单元——block 比单 expert 更高效（amortize 传输 overhead），比全量 streaming 更轻量（只传 warm block 而非全部 experts）。这三层策略可以用 MoE-LB 的 ILP formulation 扩展建模 [moe-lb-interai25]——决策变量从"expert-to-device"变为"expert-to-tier (hot/warm/cold) + warm block composition"。

方向 3: 将 FaaS 的 admission control 语义引入 MoE multi-tenant serving

FaaS 平台天然提供的一个关键能力——Concur 风格的 admission control [ref:2601.22705]——在 MoE multi-tenant serving 中几乎未被探索。当多租户同时请求导致 expert contention（所有 60 experts 都被激活），系统应该拒绝或延迟部分请求以避免 KV cache thrashing 和 HBM OOM。FaaSMoE 的 FaaS 平台已有此能力（函数并发限制），但论文未利用。将 FaaS 的 concurrency limit 映射为 MoE serving 的"per-expert concurrency budget"：每个 expert 同时服务的请求数 ≤ C，超出时请求排队。C 的设定依赖 expert capacity（HBM 中驻留的该 expert weight 副本数 × 单副本 batch capacity）。这将 FaaSMoE 的概念性 FaaS mapping 扩展到可操作的 resource management 策略——结合 Scepsy 的 fractional GPU allocation [2604.15186]，可以做到"per-expert fractional GPU + concurrency admission control"的联合优化。

方向 4: MoE multi-tenant expert sharing + PrfaaS 跨 DC 架构的组合

PrfaaS 证明了跨 DC prefill offload 在 hybrid attention 模型下可行（egress 仅 13 Gbps）[2604.15039]。将 FaaSMoE 的 multi-tenant expert sharing 思想引入 PrfaaS 架构：在 PrfaaS 的 compute-dense 集群中，多租户共享同一组 MoE expert weights（而非每租户一份），用 ZeRO-Prefill 的 AsyncEP 做高效执行。multi-tenant routing 层（PrfaaS 的长度阈值路由 + expert-level batching across tenants）决定哪些租户的哪些 tokens 被发往哪些 expert blocks。这结合了 PrfaaS 的跨 DC 弹性、FaaSMoE 的 multi-tenant expert 共享概念、和 ZeRO-Prefill 的 GPU-native 执行效率——解决 MoE multi-tenant serving 在大规模异构集群中的端到端问题。挑战在于 cross-tenant batching 的 SLO 隔离——不同租户可能有不同延迟要求，SPECTRE 的 speculative priority scheduling [2605.08151] 提供了 multi-tenant workload 隔离的参考方案。

方向 5: 为 FaaSMoE 构建缺失的性能模型——从 empirical sweep 到 analytical framework

FaaSMoE 最大的方法论短板是缺乏性能模型。可以参照 PrfaaS 的 throughput model（Eq.1–8）和 SPECTRE 的 closed-form threshold 构建 FaaSMoE 的解析框架：(1) Expert invocation model: per-layer latency = dispatch_overhead × ceil(tokens / block_capacity) + expert_compute_time + serialization_time，其中 dispatch_overhead 是 FaaS scheduling + container startup；(2) Memory model: total_memory = orchestrator_memory + N_active_blocks × block_memory + FaaS_platform_overhead，其中 N_active_blocks 是 expert activation distribution 的函数（可用幂律建模）；(3) Tenant scaling model: 给定 T 个 tenants，expected_active_experts(T) = E × (1 - (1-k/E)^T)，冷启动概率 = P(expert idle > keep_alive)。这三个模型组合可以回答 FaaSMoE L2 §4 提出但未解答的六个问题——break-even tenant count、最优 block size 解析解、cold-start probability、throughput ceiling。建立此模型的实验前提是在 GPU 上实现 expert invocation（GPU-native expert-as-a-service），否则 CPU-only 的模型参数对 production 无参考价值。