在用户附近的LLM推理环境中，很少会有现成的“重型”服务器。通常，这里混合了各种边缘设备、网关和雾节点，它们的内存容量和计算能力各不相同。如果部署模型时假设它总能装进单一设备，那无异于无视现实：模型要么装不下，要么延迟高得无法接受，要么宝贵的资源被闲置。E2LLM框架为此提供了一条更务实的路径。
为什么经典方案行不通
传统的LLM服务方法通常假设整个模型运行在一台机器上。这在云端通常可行，但在边缘/雾计算环境中，节点更弱且异构性更强。部分设备可能有足够的内存来存放权重，但计算能力跟不上；另一些则相反，速度快但内存有限。如果试图简单地将模型“分摊”到所有可用设备上，就会出现协调、通信和利用率方面的问题。
同时，实际应用中需要同时满足三个要求：
- 可预测的低延迟，
- 资源的高效利用，
- 合理的部署成本。
这三者相互冲突，因此需要的是折中方案，而非单方面的优化。E2LLM正是围绕这种折中方案构建的。
副本与角色：E2LLM如何突破限制
E2LLM的关键思想不是将单个模型拆分到所有节点，而是将设备组织成副本。每个副本内部都保存着模型的完整拷贝，然后通过模型并行将其分配到组内成员。这听起来像是浪费内存，但实际上这种冗余提高了容错性，并允许并行处理多个请求。
接下来，需要利用对LLM推理过程的了解。推理分为两个负载特征不同的阶段：prefill（预填充）阶段，模型积极处理输入令牌并构建注意力缓存；以及 decode（解码）阶段，模型生成输出令牌。这两个阶段所需的资源不同：prefill对峰值计算能力敏感，而decode则对内存带宽和数据传输延迟敏感。
E2LLM并非让每个组都同时处理这两个阶段，而是为副本分配专门的角色。一些副本成为 prefill副本，负责更快地处理传入请求；另一些则成为 decoder副本，负责平稳地生成内容。这种划分使得资源不会被浪费在处理特定硬件不擅长的阶段上。
设备组是如何形成的
不能简单地把最先找到的设备凑在一起就称为副本。E2LLM首先会判断哪些节点值得组合。为此，它使用了遗传算法：该算法遍历各种集群组合方案，并以系统的最终性能为目标逐步优化它们。
一旦确定了集群，就需要弄清楚如何在成员之间切分模型。这里采用的是动态规划方法：它寻找一种切分策略，使得设备间数据传输的“瓶颈”最小化。换句话说，上层负责挑选副本的组成，下层则负责根据具体的硬件组合对模型进行最优切分。
这在实践中意味着什么
作者将该方法与基线方案 Splitwise 进行了对比测试，后者同样分离了prefill和decode，但在处理异构环境方面不够灵活。实验表明，E2LLM能很好地适应工作负载的变化。当输入和输出令牌长度差异很大时，这一点尤为明显：例如，请求很短，但需要很长的回复，随后负载又急剧变化。
在高负载下，与Splitwise相比，新方法将平均等待时间降低了超过50%。这意味着用户排队等待生成的情况更少，而边缘/雾设备本身也能更有意义地工作，而不是试图同等地服务于推理的两个阶段。
总结
E2LLM表明，要在边缘高效运行LLM，不仅取决于单个设备的性能，还取决于设备如何组合以及如何分配角色。在副本层面复制完整模型，并结合prefill和decode的分离，是一种深思熟虑的权衡：在某些方面可能需要牺牲内存，但作为回报，系统获得了稳定的性能和更低的延迟。
对实际应用场景的主要启示是：在异构环境中，不应试图将整个模型塞进单个节点，也不应将其均匀地分散到所有节点。正确的做法是从可用硬件中组建专门的组，然后在组内决定如何分配计算任务。只有这样，LLM推理才能在大型云集群之外真正变得实用。
