集群工作负载分配：基于自然语言处理的语义软亲和性调度 Cluster Workload Allocation: Semantic Soft Affinity Using Natural Language Processing

系统的工作流程可以分为以下步骤：第一步，用户在 Kubernetes Deployment 的 Pod 模板中添加 allocation_hint 注解，写入自然语言调度偏好（如「这是一个关键的 ML 训练作业，必须在有 GPU 的节点上运行」）。第二步，当 kube-scheduler 为该 Pod 进行调度时，内置的过滤插件（如 NodeResourcesFit）先排除资源不足的节点，然后将候选节点列表发送给评分扩展器的 /prioritize 端点。第三步，扩展器从 Pod 注解中提取 allocation_hint 文本，先经过消毒函数去除潜在的恶意字符（防止提示注入攻击），然后发送给意图分析器。第四步，意图分析器将消毒后的文本嵌入到一个精心设计的提示模板（Prompt Template）中，该模板包含角色定义（「你是一个专家 AI 助手」）、关键指令（8 条详细规则）、意图列表（25 种预定义意图及其描述和元数据要求）、以及 JSON 输出示例，然后调用 AWS Bedrock 上的 LLM（默认使用 Amazon Nova Pro）。第五步，LLM 返回一个 JSON 对象，包含检测到的意图、每个意图的置信度、强度和元数据（如 prefer_gpu_cores: 4.0）。第六步，扩展器解析该 JSON，为每个候选节点计算评分：对每个意图，根据其类别应用不同的评估逻辑（二值偏好返回 0/1，避让惩罚返回 -2，分散逻辑返回基于最少负载的归一化分数），然后乘以基权重 $\beta = 100/|\mathcal{I}|$、置信度 $C_i$ 和强度 $W_i$。第七步，所有意图的评分求和得到每个节点的原始分，然后归一化到 [0,100] 区间，得分最高的节点被确定性地赋值为 100 分（平局时按字母序选择），其余节点限制在 [1,99]。第八步，评分返回给 kube-scheduler，调度器选择得分最高的节点放置 Pod。同时，该放置决策被写入本地短期缓存（TTL 10 秒），以便后续突发调度请求能够感知到尚未持久化到 etcd 的待处理放置。

本文的技术新颖性体现在三个层面。第一，在概念层面，「语义软亲和性」是一个新的调度范式。已有工作要么关注硬约束（如 Kubernetes 的 requiredDuringScheduling），要么关注基于标签的软偏好（如 preferredDuringScheduling），但都没有引入「语义理解」这一维度。本文首次将 LLM 的自然语言理解能力嵌入到调度决策路径中，使得调度器能够理解「高性能」「关键任务」「最好在欧洲」这类模糊的、带有语义色彩的表达。第二，在系统设计层面，论文提出了「三维度意图评分」机制（类型 × 置信度 × 强度），这与传统的单一权重打分不同。置信度和强度的引入使得系统能够区分 LLM 的解析不确定性和用户的语义优先级，为调度决策提供了更丰富的信息维度。第三，在工程实践层面，论文实现了「有效 Pod 集合」（Effective Pod Set）的概念 $\mathcal{P}_{eff} = \mathcal{P}_{api} \cup \mathcal{P}_{local}$，通过将 API 确认状态与本地短期缓存合并，解决了突发调度场景下的竞态条件问题。这种混合状态模型在传统调度器中并不常见，是为适配 LLM 的异步特性而专门设计的。

从独立分析的角度，本文存在以下几个值得改进的弱点。第一，加权和标量化策略在处理冲突意图时过于简单：论文在场景 F 中展示了系统能够「解决」冲突——但实际上它只是将冲突的软偏好简单求和，找到一个折中的节点，而不是真正理解冲突并做出有原则的权衡。例如，当用户同时说「集中部署」和「分散到不同区域」时，系统应该提示用户澄清优先级，或者使用 Pareto 前沿方法提供多个候选方案供用户选择。改进方向是引入层次化的目标优先级机制，让高强度意图优先于低强度意图，而不是简单加权求和。第二，LLM 调用的确定性保障不足：虽然论文设置了 temperature=0.0 来提高确定性，但 LLM 的输出本质上仍是概率性的，相同输入可能产生不同输出。在调度场景中，这种不确定性可能导致同一部署的不同 Pod 被分配到不同策略。改进方向是在 LLM 输出后增加确定性校验层，对结构化输出进行严格模式验证和归一化。第三，评估场景的选择可能存在选择偏差：六个场景中有五个（A-E）都展示了正面结果，只有场景 F 展示了限制。论文没有评估更多边界情况，如用户输入含错别字、使用方言或俚语、或给出极度模糊的提示（如「随便放」）。改进方向是构建更全面的压力测试数据集，覆盖真实用户可能产生的各种边缘输入。第四，单线程 Flask 架构严重限制了系统的实际可用性：在生产环境中，调度器需要处理大量并发请求，单线程串行处理会导致严重的性能瓶颈。这一问题在评估中被规避了，但在实际部署中会立即暴露。

论文提出了几个明确的未来研究方向。首先是异步意图分析：将 LLM 调用从同步的 /prioritize 路径移到 MutatingAdmissionWebhook，在 Pod 创建时就完成意图分析并将结果存储在注解中，让调度器扩展器在打分时直接读取本地结果，消除同步延迟。其次是扩展评估数据集：已创建了 v2 版本数据集（包含多目标优化和矛盾提示两个新类别），未来应进一步扩大规模和覆盖范围。第三是 Pareto 前沿优化：用 Pareto 基础的评分替代简单加权和，在保留高强度意图优先级的同时，为低强度意图提供更有原则的冲突解决机制。第四是并行执行环境评估：将 Flask 替换为多线程/异步框架（如 FastAPI），在并发负载下评估系统的正确性和性能。第五是通用调度语法：将核心逻辑与 Kubernetes 解耦，设计一个抽象的中间格式，让 LLM 翻译自然语言到该格式，再由平台特定适配器转换为 Kubernetes、Mesos 或 SLURM 的指令，实现跨平台的语义调度。从论文成果可延伸的方向来看，结合强化学习和 NLP 模型进行意图驱动的软亲和性调度是一个有前景的混合方法，可以利用 RL 从历史调度结果中学习最优的权重分配策略，而不是依赖 LLM 提供的静态置信度和强度。

在复现性方面，本文做得相对较好。评估数据集已公开发布在 HuggingFace Model Hub（lsliwko/poc-schedule-intent-evaluation），包含 v1（英文 314 条）、v1es（西班牙语 47 条）、v1ge（德语 62 条）和 v2（新增多目标和矛盾类别）四个版本。测试环境基于 Minikube + Docker 驱动，不需要真实的多节点集群，可以在单台机器上复现。然而，有几个复现门槛需要注意：首先，意图分析器依赖 AWS Bedrock 服务，需要 AWS 账户和相应的 API 访问权限（特别是 Amazon Nova Pro 模型），这对没有 AWS 资源的研究者是一个障碍；不过理论上可以替换为任何支持 JSON 输出的 LLM。其次，论文未提供完整的源代码仓库（只提供了数据集），评分扩展器服务和集群状态缓存的实现细节分散在论文正文中，复现者需要自行编写代码。第三，实验使用 Kubernetes 1.31.4 版本，不同版本的 Scheduler Extender API 可能存在差异。总体而言，有 Kubernetes 开发经验的工程师可以在 1-2 天内搭建测试环境并复现核心场景，但从零开始搭建可能需要更长时间。