基于 SGLang 框架的 ModelServer 类。完全自建,还请提出更多优化方式。
- Server 配置:全部服务器配置,托管了不同大小的模型(如
8B
和70B
)。每个服务器通过一个Server
命名元组来表示,包含属性如ip
(IP 地址)、port
(端口)、model_size
(模型大小)、model_path
(模型路径)和gpus
(GPU 配置)。 - BENCHMAK_MESSAGE: 定义了一个基准消息(
BENCHMAK_MESSAGE
),用于测试不同服务器的性能。
get_fastest_server
: 测试各个服务器的延迟,并返回最快的服务器。延迟长于当前最低 latency 的服务器将被跳过,这在服务器 latency 非常不均衡时有显著意义。get_all_latency
: 检查并打印所有配置服务器的延迟。get_running_server_sizes
: 返回当前运行中的服务器模型大小列表。
get_eno1_inet_address
: 获取网络接口eno1
相关的 IP 地址。is_gpu_free
: 检查指定的 GPU 是否空闲(内存使用量低于某个阈值)。get_gpu_memory_info
: 获取指定 GPU 的总内存和可用内存信息。get_free_memory_ratio
: 计算 GPU 可用内存与总内存的比例。get_comond_infos
: 构建用于启动服务器的命令,取决于服务器的配置。main
: 主函数,管理 GPU 的可用性并启动模型服务器。
- 动态资源管理: 动态检查和管理 GPU 资源,确保只有在资源充足时才启动服务器。
- 服务器初始化: 自动化地启动服务器,确保使用正确的配置和资源分配。
- 并发性: 使用
ThreadPoolExecutor
并发地管理多个服务器,充分利用资源。
LATENCY_GROWING_RATE
(延迟增长率)、MAX_RETRY
(最大重试次数)和 INF
(无穷大)。
采用自动化重启和容错恢复的方式管理不同模型服务器(8B
和 70B
)的创建和交互。
ModelServer
实现了延迟监测和自动重启机制:
-
延迟监测: 每当用户请求一个模型完成任务时,
get_completion
方法会测量服务器的响应时间(elapsed_time
)。如果响应时间超过了预设的延迟边界(LATENCY_GROWING_RATE * latency_bound
),系统会认为当前模型服务器的性能下降,可能无法继续高效处理请求。 -
自动重启: 当检测到响应时间过长时,
ModelServer
会触发_manage_model_server
方法,对当前服务器进行重建。这个过程会选择一个新的、响应速度更快的服务器来替代原来的服务器,从而提高系统的整体响应速度。
为了处理偶发性的服务器故障或网络问题,ModelServer
类实现了容错机制:
-
多次尝试: 在
get_completion
方法中,模型服务器会在处理请求时进行最多MAX_RETRY
次尝试。如果在某次尝试中服务器响应失败,系统会记录这个错误并再次尝试,直到成功或者达到最大重试次数。 -
错误处理: 每次尝试从服务器获得
response
时如果发生异常,系统都进行捕获,输出错误信息,并且调用_manage_model_server
重建服务器。
ModelServer
采用了完善的服务器构建与重建逻辑:
-
服务器构建: 在初始化时,
ModelServer
会根据当前运行的服务器配置,调用_manage_model_server
方法来选择最快的模型服务器。 -
服务器重建: 如果当前服务器因为延迟或错误被判定为不再适合使用,系统会通过
_manage_model_server
方法重新选择新的服务器,替换掉原有的服务器。这个过程会持续进行,直到找到一个能够满足响应要求的服务器为止。 -
避免过多次重建: 请合理调整参数确保
ModelSever
不会过于频繁的重建服务器。重建服务器本身有一定开销,此外更换服务器会降低SGLang
框架的 cache 利用率,增大单次请求的开销。