公开动态与原创分析 · 消息日期： · 消息来源
10月20日，开源推理项目 llm-d 发布 1.0。它运行在 Kubernetes 环境中，为 vLLM、SGLang 等推理引擎提供分布式调度。这次版本的一个重点，是让不同部门、不同紧急程度的请求共用模型服务时，不至于被一阵突发任务挤到队尾。
这一变化对应着企业自建模型后的一个具体问题。假设运营人员一次提交了整批商品说明改写，客服又正在等待一句回复建议：两类请求都调用同一个模型，却有完全不同的等待代价。前者晚些完成可能仍赶得上排期，后者迟迟不返回，就会拖住正在进行的对话。只看整台机器每秒生成多少文字，未必能发现后者的处境。
优先级需要企业自己定义
llm-d 的发布说明介绍了按优先级和租户公平性进行流量控制的能力。同一优先级内的多个租户轮流获得处理机会；拥堵时，请求可以先留在路由层等待，避免继续压入已经繁忙的后端队列。不过，默认行为仍接近先到先处理，企业需要主动配置相应策略。安装新版本并不会自动知道哪一项业务更着急。
因此，前面的客服请求和商品文案任务，应在进入推理服务前就带上可以识别的业务类别。任务发起方可以提供类别，但不能人人都自行宣称最高优先级；否则，队列很快又变回谁提交得多谁占得多。优先顺序需要由业务负责人和运维人员共同确定，并与入口的身份识别对应起来。
这里还有一个容易被“实时优先”掩盖的问题：批量任务也有交付时间。如果客服流量全天不断，商品文案一直没有机会执行，运营排期仍会落空。合适的策略应为在线响应留出余量，也为批量工作保留可预计的进度；当总需求超过容量时，则要让发起人知道任务正在排队，或暂时无法受理。
吞吐量之外，要看到谁在排队
检查这种安排是否有效，可以在同一段繁忙时段分别观察两类任务：客服人员实际等了多久，批量文案在约定时间前完成了多少。平均响应时间可能掩盖少数很慢的请求，记录较慢请求的等待情况，才更接近用户感受到的服务。还应区分队列等待与模型生成时间，避免把调度拥堵误判成模型能力不足。
对已经出现混合负载的团队，llm-d 提供了更明确的调度手段。对调用量尚小、托管模型已经够用的团队，这条新闻并不构成立刻自建集群的理由。先看清等待发生在什么地方，再决定是否需要增加这一层设施，通常比先追求更高的总吞吐量更有帮助。
消息来源
本页内容由 墨客云AI（南京薄幕软件科技有限公司）发布与维护。 咨询与场景诊断预约：180-1290-1065 · neo@mokyun.com
