调度器中已经存在一定程度的优先级机制,用于 LLMEngine(参见 policy.py 和 scheduler.py)。然而,目前可用的唯一策略是“先来先服务”(First come first serve),而且等待序列没有排序,因为它们是按照到达顺序添加的,这与只执行先来先服务策略相符。
我尝试过添加一个策略,通过扩展版本的 SamplingParams 提供优先级:
class SamplingPriority(Policy):
def get_priority(self, now: float, seq_group: SequenceGroup) -> tuple[float, float]: # type: ignore[override] # Policy only needs the return type to be sortable
# You should use an extended SamplingParams-class that has a property 'priority'
return (
getattr(seq_group.sampling_params, "priority", 1),
now - seq_group.metrics.arrival_time,
)
2条答案
按热度按时间egmofgnx1#
调度器中已经存在一定程度的优先级机制,用于
LLMEngine
(参见 policy.py 和 scheduler.py)。然而,目前可用的唯一策略是“先来先服务”(First come first serve),而且等待序列没有排序,因为它们是按照到达顺序添加的,这与只执行先来先服务策略相符。我尝试过添加一个策略,通过扩展版本的
SamplingParams
提供优先级:(这与
PriorityQueue
相反,即较高的优先级意味着序列处理得较早)。然而,这似乎对处理序列的顺序没有明显影响——即使我让调度器对
waiting
、running
和swapped
deques 进行排序。我还没有充分理解调度逻辑,以弄清楚发生了什么。此外,从 scheduler.py 到 scheduler.py (v0.4.0) ,调度逻辑似乎发生了重大重写,所以我现在不太愿意投入时间去了解它。j9per5c42#
好的,这里是你可以做的事情:
sampling_params
设置一个属性priority
(数值越高表示处理越早)engine.scheduler.policy = SamplingPriority()
(其中engine
是LLMEngine
,如果你使用的是AsyncLLMEngine
,则设置为engine.engine.scheduler.policy = ...
)这将执行以下操作:
高优先级请求会被移动到等待队列的前面。所以下次有空闲槽位可供处理序列时,这些请求会被优先处理。然而,这并不意味着新的高优先级请求会优先于已经在运行的低优先级请求。我猜要实现这一点需要付出更多的努力。