2026/9/16 15:55:49
FEATURED · 精选文章 
SkyPilot API Server 负载测试与性能剖析完整指南从并发压测到 worker 资源调优【免费下载链接】skypilotThe AI Compute Platform for frontier teams. SkyPilot turns fragmented AI compute into one AI supercomputer, so frontier AI teams build custom intelligence faster.项目地址: https://gitcode.com/GitHub_Trending/sk/skypilot本篇指南围绕 tests/load_tests 目录下的负载测试与性能剖析工具展开介绍如何对 SkyPilot 的 API ServerAI 计算平台的控制面服务端进行并发压力测试、系统资源监控与分布式压测并最终将测量结果反馈到服务端 worker 池的内存估算中。读完本文你将掌握sys_profiling.py、test_load_on_server.py、test_distribute_load_on_server.py三套工具的使用方法理解 API Server 的长请求 / 短请求双 worker 池架构并能基于实测数据调整 worker 内存常数以稳定服务端资源占用。工具集概览一个仓库内的完整压测栈tests/load_tests/目录为 SkyPilot API Server 提供了从单机剖析到分布式压测的完整工具链核心文件如下文件作用sys_profiling.py在服务端机器上持续监控系统资源CPU、内存以及 executor worker 进程的内存占用test_load_on_server.py在客户端机器上并发发送多种sky命令与 API 调用压测 API Server 并统计延迟test_distribute_load_on_server.py将test_load_on_server.py的负载分发到多个 SkyPilot 集群客户端上消除客户端瓶颈benchmark_ctl.py配置驱动的分布式基准控制器一键拉起 worker VM、下发负载、回收结果并输出报告benchmark_worker.py在单个 worker 上运行多种负载生成器shell / qps / long_conn / ssh_benchconfig.py 与 configs/基准配置的 YAML schema 解析与示例配置mixed.yaml、ssh.yamlworkloads/basic.sh基准 shell 工作负载脚本覆盖集群生命周期与 managed jobs 两类操作需要特别注意的是官方文档的适用边界负载测试的工作负载相对简单可能无法完全反映 API Server 在生产环境中的真实使用模式若希望获得更准确的测量结果可考虑运行部分或全部 smoke tests见 tests/smoke_tests作为补充。这一点在分析压测数据时需要时刻谨记。前置理解API Server 的双 worker 池架构负载测试的意义建立在 SkyPilot API Server 的请求执行模型之上。从 sky/server/requests/executor.py 顶部的模块注释可以看出服务端将请求分为两类长请求long-running耗时长、资源占用大例如集群启动cluster launching / starting、任务提交、managed job 提交等短请求short-running完成快、对响应延迟敏感例如sky status、job 状态查询等。出于资源利用率和延迟的双重优化服务端为两类请求分别维护独立的 worker 池长请求池的 worker 数量有限每个 worker 常驻占用数百 MB 内存短请求池的 worker 数量显著更多以便并行处理大量短查询、降低响应延迟。worker 池的规模由系统资源动态决定具体计算逻辑在 sky/server/config.py 的compute_server_config()中部署模式deployTrue下资源专用于 API Server并行度固定且拒绝在低资源环境启动本地模式deployFalse则限制常驻长 worker 数量_MAX_LONG_WORKERS_LOCAL 4见 config.py并允许 burstable worker 弹性扩展。这也是为什么负载测试的输出最终要落到 worker 内存常数上准确的资源估算直接决定了服务端能并行处理多少请求、以及在高并发下是否会发生 OOM。一、系统性能剖析sys_profiling.py在压测进行的同时需要在服务端机器上运行 sys_profiling.py 来记录资源使用曲线。该脚本基于psutil实现以0.2 秒为采样间隔持续采集整机 CPU 百分比与内存用量见 sys_profiling.py通过进程命令行匹配SkyPilot:executor:short与SkyPilot:executor:long关键字分别统计短/长 executor worker 的峰值 RSS 内存与平均 RSS 内存见 sys_profiling.py。进程名由服务端通过setproctitle设置executor_initializer()将 executor 进程标题设为SkyPilot:executor:proc_group:pid见 executor.py其中proc_group即调度类型short或long见 executor.py。剖析脚本正是依赖这一命名约定精确追踪 worker 内存。运行方式在服务端机器上直接执行CtrlC结束并打印汇总python tests/load_tests/sys_profiling.py运行期间终端会持续输出类似CPU Usage: 12.3%、Memory Usage: 3.12GB/15.60GB (20.0%)的实时采样行。按CtrlC后脚本打印完整汇总此输出示例来自 tests/load_tests/README.md MONITORING SUMMARY Duration: 1481.7 seconds (0.41 hours) BASELINE USAGE: Baseline CPU: 1.2% Baseline Memory: 2.99GB (21.6%) PEAK USAGE: Peak CPU: 96.9% Peak Memory: 11.78GB (79.0%) Memory Delta: 8.8GB Peak Non-blocking Executor Memory: 0.37GB Peak Non-blocking Executor Memory Average: 0.23GB Peak Blocking Executor Memory: 0.35GB Peak Blocking Executor Memory Average: 0.30GB AVERAGE USAGE: Average CPU: 11.5% Average Memory: 63.1% 汇总字段解读结合 sys_profiling.py 的输出逻辑各字段含义如下字段含义Duration监控总时长秒与小时Baseline CPU / Memory压测开始前记录的基线占用用于对比压测增量Peak CPU / Memory整个压测期间的峰值 CPU 百分比与内存用量Memory Delta峰值内存与基线内存之差即压测带来的内存增量Peak Non-blocking Executor Memory短请求non-blockingexecutor 单个进程的峰值 RSSPeak Non-blocking Executor Memory Average短请求 executor 全体进程平均 RSS 的历史最高值Peak Blocking Executor Memory / Average长请求blockingexecutor 的对应指标Average CPU / Memory全程平均占用百分比其中Non-blocking即短请求池、Blocking即长请求池长请求在执行期间会阻塞占用的 worker故而得名。这两组 executor 内存数字是下一步调整服务端常量的直接依据。二、负载生成test_load_on_server.pytest_load_on_server.py 是压测的负载发生器通过 Python 多线程并发执行skyCLI 子进程或 SDK API 调用向 API Server 注入压力并记录每个请求的延迟。支持的请求类型脚本支持两大类请求源码见 test_load_on_server.pyCLI 请求-r/--requests参数选择类型执行的命令说明launchsky launch --cloudc --cpus2 -y [--async]并发发起集群启动请求可配合--run-async异步化statussky status并发状态查询短请求典型场景logssky logs test 1先建集群再并发拉日志结束后销毁集群jobssky jobs launch --cloudc --cpus2 echo hello sleep 120 -y并发提交 managed jobservesky serve up/status/down基于同目录 serve.yaml 部署服务并并发查询状态API 调用--apis参数选择类型调用的 SDK 接口说明statussdk.status()stream_and_get直接压测 API Server 的 /status 接口cli_statusjobs.queue_v2serve.statussdk.status模拟sky status命令在客户端内部的全部 API 调用链tail_logssdk.tail_logs(...)并发追踪日志流validate通过sky.Dag构造 Task 后调用sdk.validate(dag)压测 DAG 校验接口api_statussdk.api_status服务端存活/状态查询命令行参数参数默认值说明-n1每种请求的并发数量-r/--requests空要测试的 CLI 请求类型可选launch status logs jobs serve或all-c/--clouds[aws]参与测试的云厂商列表用于测试多云场景下的 worker 内存消耗见 test_load_on_server.py--apis空要测试的 API 调用类型可选status cli_status tail_logs validate api_status或all--run-async关闭对launch/jobs使用--async异步提交模拟长时间请求的异步路径延迟统计输出所有请求完成后脚本打印按请求类型分组key 为完整命令字符串的延迟统计表见 test_load_on_server.py包含请求数、总耗时以及平均 / 最小 / 最大 /P95 / P99延迟可直接用于评估并发下的尾部延迟表现。统计计算使用 NumPynp.percentile见 test_load_on_server.py。三、标准压测流程五步以下为官方 README 推荐的完整流程tests/load_tests/README.md第 1 步在远端机器上启动 API Serversky api stop sky api start第 2 步在服务端机器上运行剖析脚本python tests/load_tests/sys_profiling.py第 3 步在本地运行负载测试脚本向服务端发送请求python tests/load_tests/test_load_on_server.py -n 50 -r all --cloud aws该命令对launch、status、logs、jobs、serve五类 CLI 请求各并发 50 次云厂商限定为 AWS。第 4 步压测结束后终止剖析进程得到如本文第一节所示的资源使用汇总含 peak CPU / memory、blocking / non-blocking executor 内存峰值与均值。第 5 步根据阻塞长请求与非阻塞短请求worker 的峰值内存更新 worker 内存常数。官方 README 将这两个常数标注为_LONG_WORKER_MEM_GB与_SHORT_WORKER_MEM_GB位置在sky/server/requests/executor.py。从当前仓库源码来看这两个常量的实际定义位于 sky/server/config.pyLONG_WORKER_MEM_GB 0.4 # 单个长请求 worker 的内存估算GB SHORT_WORKER_MEM_GB 0.3 # 单个短请求 worker 的内存估算GB SERVER_WORKER_MEM_GB 0.4 # 单个 uvicorn server worker 的内存估算GBREADME 中的路径可能基于较早版本的目录结构实际以 config.py 为准。这些常数直接影响服务端 worker 池的容量计算_max_long_worker_parallism()依据available_mem * 0.6 / LONG_WORKER_MEM_GB计算长请求并行度上限config.py_max_short_worker_parallism()则从总内存中扣除长 worker 预留后再按SHORT_WORKER_MEM_GB计算短请求并行度config.py。文件注释同时强调这些估算与使用模式高度相关启用的云、请求类型等覆盖的是主要云与常见使用模式对偏离该模式的用户可通过环境变量覆盖估算。此外SKYPILOT_MEMORY_AWARE_WORKER_SIZING环境变量见 sky/utils/env_options.py可让服务端在划分 executor 池内存前先扣除 server worker 常驻进程与 consolidation 模式控制器的内存避免池容量估算超出机器物理内存。四、以 API 性能为焦点的 Benchmarkingtest_load_on_server.py亦可直接作为基准测试使用。需要警惕的陷阱是在高并发下客户端本机同时拉起大量skyCLI 进程会显著增加客户端侧延迟进程启动、Python 模块加载开销从而使测量结果失真。若希望基准聚焦于 API Server 本身官方推荐使用--apis参数直接调用 SDK 接口而非 CLI 子进程python tests/load_tests/test_load_on_server.py -n 100 --api status等价写法为--apis status实际参数名见 test_load_on_server.py。脚本注释中对此有专门说明test_load_on_server.pytest_cli_status_in_api用 SDK 调用链模拟sky status的行为正是因为 100 个并行 CLI 进程的模块加载会造成客户端拥塞——而在真实场景中多个用户从不同机器调用 CLI 并不会出现这一瓶颈因此这种客户端开销不属于服务端能力范畴。五、分布式客户端压测消除客户端瓶颈当并发度足够高时单台客户端会成为新的瓶颈导致基准测试测量的不再是 API Server 的性能。此时使用 test_distribute_load_on_server.py 将负载分发到多个 SkyPilot 集群客户端每个客户端运行独立的test_load_on_server.py实例# -t: 客户端实例数量 # --cpus: 每个客户端使用的 CPU 核数 # --memory: 每个客户端使用的内存GB # --url: 被测 API Server 的 URL建议把客户端部署在另一个 API Server 上以避免互相干扰 # ARGS_FOR_TEST_LOAD_ON_SERVER: test_load_on_server.py 的参数参考前文 python tests/load_tests/test_distribute_load_on_server.py -t 10 --cpus 2 --memory 8 --url API_SERVER_URL ARGS_FOR_TEST_LOAD_ON_SERVER从源码看test_distribute_load_on_server.py该脚本的可选参数还包括--workdir本地 SkyPilot 仓库路径用于挂载到客户端与--branch指定 git 分支客户端将克隆该分支作为工作目录。其实现机制是通过sky.launch在 Kubernetes 集群上为每个客户端创建名为benchmark-i的 VM挂载本地仓库作为 workdir或按分支 clone安装skypilot-nightly[kubernetes,aws,gcp]后执行sky api login -e url并运行test_load_on_server.py见 test_distribute_load_on_server.py。脚本注释特意指出使用sky launch而非sky jobs launch是为了获得可预测的客户端并行度。压测结束后所有客户端集群会被自动销毁。六、进阶配置驱动的混合模式基准除 README 中直接介绍的脚本外同一目录还提供了更完整的基准工具链。以 benchmark_ctl.py 为控制器、benchmark_worker.py 为 worker 执行端可通过一个 YAML 配置同时叠加四种负载生成器定义于 config.pyshell运行 bash 工作负载脚本如 workloads/basic.sh覆盖 launch→exec→ssh→logs→queue→status→stop→start→down 的完整集群生命周期与 managed jobs 操作属闭环closed-loop压力qps开放环open-loop的固定速率 QPS 引擎sky.status/sky.jobs.queue等目标 QPS 为全局值、按 worker 数均分long_conn维持 N 条并发长连接会话ssh_idle/logs_follow压测 WebSocket 长连接通道ssh_bench反复打开/关闭到 victim 集群的 SSH 会话记录连接延迟。示例配置见 configs/mixed.yaml 与 configs/ssh.yaml核心结构包括target被测 API Server 端点、认证方式、云、workersworker VM 数量与规格、duration_sQPS 与长连接的墙钟围栏、victim_pool供长连接/SSH 压测使用的目标集群池与generators列表。运行方式python tests/load_tests/benchmark_ctl.py \ --config tests/load_tests/configs/mixed.yaml \ --target-endpoint http://user:passyour-api-server控制器自动完成拉起 worker VM → 下发基准 → 通过 base64gzip 封装回收结果 JSON → 汇总输出含 P50/P95/P99 的报告 → 清理资源的完整闭环见 benchmark_ctl.py 与报告打印逻辑 benchmark_ctl.py。这一套件适合需要同时施加慢速生命周期操作 恒定短读 长连接 SSH 突发混合压力、且结果要求可复现的高级基准场景。七、最佳实践与注意事项综合官方 README 与源码实现实践中有以下几点值得注意剖析与压测必须同步剖析脚本提供的是时间窗口内的峰值与均值只有与压测并发执行才能捕捉到真实的资源上限压测结束后立即终止剖析可得到完整的基线-峰值对比。以 API 模式为准的基准凡是关注 API Server 自身性能的测量优先使用--apis/--api模式CLI 并发会引入客户端模块加载开销污染延迟数据。高并发必须分布式压测当并发客户端本身成为瓶颈时用test_distribute_load_on_server.py把负载分散到多个集群客户端并尽量将客户端与被测服务端部署在不同 API Server 上。worker 内存常数与使用模式强相关LONG_WORKER_MEM_GB与SHORT_WORKER_MEM_GB的取值依赖具体使用模式启用哪些云、请求类型分布等实测后按峰值内存更新并可通过SKYPILOT_MEMORY_AWARE_WORKER_SIZING环境变量启用更精确的内存感知池容量计算文件注释中的 TODO 亦指出未来计划根据系统使用统计自动在运行时调优并行度见 sky/server/config.py届时手工维护常数的负担有望消除。工作量不代表生产全貌README 明确警示简单负载可能无法覆盖真实世界的 API Server 使用模式需要更精确测量时可补充运行 smoke tests。所有性能结论都应基于你自己的环境实测切勿直接套用任何示例数字作为生产容量规划的结论。【免费下载链接】skypilotThe AI Compute Platform for frontier teams. SkyPilot turns fragmented AI compute into one AI supercomputer, so frontier AI teams build custom intelligence faster.项目地址: https://gitcode.com/GitHub_Trending/sk/skypilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
SkyPilot API Server 负载测试与性能剖析完整指南：从并发压测到 worker 资源调优
SkyPilot API Server 负载测试与性能剖析完整指南从并发压测到 worker 资源调优【免费下载链接】skypilotThe AI Compute Platform for frontier teams. SkyPilot turns fragmented AI compute into one AI supercomputer, so frontier AI teams build custom intelligence faster.项目地址: https://gitcode.com/GitHub_Trending/sk/skypilot本篇指南围绕 tests/load_tests 目录下的负载测试与性能剖析工具展开介绍如何对 SkyPilot 的 API ServerAI 计算平台的控制面服务端进行并发压力测试、系统资源监控与分布式压测并最终将测量结果反馈到服务端 worker 池的内存估算中。读完本文你将掌握sys_profiling.py、test_load_on_server.py、test_distribute_load_on_server.py三套工具的使用方法理解 API Server 的长请求 / 短请求双 worker 池架构并能基于实测数据调整 worker 内存常数以稳定服务端资源占用。工具集概览一个仓库内的完整压测栈tests/load_tests/目录为 SkyPilot API Server 提供了从单机剖析到分布式压测的完整工具链核心文件如下文件作用sys_profiling.py在服务端机器上持续监控系统资源CPU、内存以及 executor worker 进程的内存占用test_load_on_server.py在客户端机器上并发发送多种sky命令与 API 调用压测 API Server 并统计延迟test_distribute_load_on_server.py将test_load_on_server.py的负载分发到多个 SkyPilot 集群客户端上消除客户端瓶颈benchmark_ctl.py配置驱动的分布式基准控制器一键拉起 worker VM、下发负载、回收结果并输出报告benchmark_worker.py在单个 worker 上运行多种负载生成器shell / qps / long_conn / ssh_benchconfig.py 与 configs/基准配置的 YAML schema 解析与示例配置mixed.yaml、ssh.yamlworkloads/basic.sh基准 shell 工作负载脚本覆盖集群生命周期与 managed jobs 两类操作需要特别注意的是官方文档的适用边界负载测试的工作负载相对简单可能无法完全反映 API Server 在生产环境中的真实使用模式若希望获得更准确的测量结果可考虑运行部分或全部 smoke tests见 tests/smoke_tests作为补充。这一点在分析压测数据时需要时刻谨记。前置理解API Server 的双 worker 池架构负载测试的意义建立在 SkyPilot API Server 的请求执行模型之上。从 sky/server/requests/executor.py 顶部的模块注释可以看出服务端将请求分为两类长请求long-running耗时长、资源占用大例如集群启动cluster launching / starting、任务提交、managed job 提交等短请求short-running完成快、对响应延迟敏感例如sky status、job 状态查询等。出于资源利用率和延迟的双重优化服务端为两类请求分别维护独立的 worker 池长请求池的 worker 数量有限每个 worker 常驻占用数百 MB 内存短请求池的 worker 数量显著更多以便并行处理大量短查询、降低响应延迟。worker 池的规模由系统资源动态决定具体计算逻辑在 sky/server/config.py 的compute_server_config()中部署模式deployTrue下资源专用于 API Server并行度固定且拒绝在低资源环境启动本地模式deployFalse则限制常驻长 worker 数量_MAX_LONG_WORKERS_LOCAL 4见 config.py并允许 burstable worker 弹性扩展。这也是为什么负载测试的输出最终要落到 worker 内存常数上准确的资源估算直接决定了服务端能并行处理多少请求、以及在高并发下是否会发生 OOM。一、系统性能剖析sys_profiling.py在压测进行的同时需要在服务端机器上运行 sys_profiling.py 来记录资源使用曲线。该脚本基于psutil实现以0.2 秒为采样间隔持续采集整机 CPU 百分比与内存用量见 sys_profiling.py通过进程命令行匹配SkyPilot:executor:short与SkyPilot:executor:long关键字分别统计短/长 executor worker 的峰值 RSS 内存与平均 RSS 内存见 sys_profiling.py。进程名由服务端通过setproctitle设置executor_initializer()将 executor 进程标题设为SkyPilot:executor:proc_group:pid见 executor.py其中proc_group即调度类型short或long见 executor.py。剖析脚本正是依赖这一命名约定精确追踪 worker 内存。运行方式在服务端机器上直接执行CtrlC结束并打印汇总python tests/load_tests/sys_profiling.py运行期间终端会持续输出类似CPU Usage: 12.3%、Memory Usage: 3.12GB/15.60GB (20.0%)的实时采样行。按CtrlC后脚本打印完整汇总此输出示例来自 tests/load_tests/README.md MONITORING SUMMARY Duration: 1481.7 seconds (0.41 hours) BASELINE USAGE: Baseline CPU: 1.2% Baseline Memory: 2.99GB (21.6%) PEAK USAGE: Peak CPU: 96.9% Peak Memory: 11.78GB (79.0%) Memory Delta: 8.8GB Peak Non-blocking Executor Memory: 0.37GB Peak Non-blocking Executor Memory Average: 0.23GB Peak Blocking Executor Memory: 0.35GB Peak Blocking Executor Memory Average: 0.30GB AVERAGE USAGE: Average CPU: 11.5% Average Memory: 63.1% 汇总字段解读结合 sys_profiling.py 的输出逻辑各字段含义如下字段含义Duration监控总时长秒与小时Baseline CPU / Memory压测开始前记录的基线占用用于对比压测增量Peak CPU / Memory整个压测期间的峰值 CPU 百分比与内存用量Memory Delta峰值内存与基线内存之差即压测带来的内存增量Peak Non-blocking Executor Memory短请求non-blockingexecutor 单个进程的峰值 RSSPeak Non-blocking Executor Memory Average短请求 executor 全体进程平均 RSS 的历史最高值Peak Blocking Executor Memory / Average长请求blockingexecutor 的对应指标Average CPU / Memory全程平均占用百分比其中Non-blocking即短请求池、Blocking即长请求池长请求在执行期间会阻塞占用的 worker故而得名。这两组 executor 内存数字是下一步调整服务端常量的直接依据。二、负载生成test_load_on_server.pytest_load_on_server.py 是压测的负载发生器通过 Python 多线程并发执行skyCLI 子进程或 SDK API 调用向 API Server 注入压力并记录每个请求的延迟。支持的请求类型脚本支持两大类请求源码见 test_load_on_server.pyCLI 请求-r/--requests参数选择类型执行的命令说明launchsky launch --cloudc --cpus2 -y [--async]并发发起集群启动请求可配合--run-async异步化statussky status并发状态查询短请求典型场景logssky logs test 1先建集群再并发拉日志结束后销毁集群jobssky jobs launch --cloudc --cpus2 echo hello sleep 120 -y并发提交 managed jobservesky serve up/status/down基于同目录 serve.yaml 部署服务并并发查询状态API 调用--apis参数选择类型调用的 SDK 接口说明statussdk.status()stream_and_get直接压测 API Server 的 /status 接口cli_statusjobs.queue_v2serve.statussdk.status模拟sky status命令在客户端内部的全部 API 调用链tail_logssdk.tail_logs(...)并发追踪日志流validate通过sky.Dag构造 Task 后调用sdk.validate(dag)压测 DAG 校验接口api_statussdk.api_status服务端存活/状态查询命令行参数参数默认值说明-n1每种请求的并发数量-r/--requests空要测试的 CLI 请求类型可选launch status logs jobs serve或all-c/--clouds[aws]参与测试的云厂商列表用于测试多云场景下的 worker 内存消耗见 test_load_on_server.py--apis空要测试的 API 调用类型可选status cli_status tail_logs validate api_status或all--run-async关闭对launch/jobs使用--async异步提交模拟长时间请求的异步路径延迟统计输出所有请求完成后脚本打印按请求类型分组key 为完整命令字符串的延迟统计表见 test_load_on_server.py包含请求数、总耗时以及平均 / 最小 / 最大 /P95 / P99延迟可直接用于评估并发下的尾部延迟表现。统计计算使用 NumPynp.percentile见 test_load_on_server.py。三、标准压测流程五步以下为官方 README 推荐的完整流程tests/load_tests/README.md第 1 步在远端机器上启动 API Serversky api stop sky api start第 2 步在服务端机器上运行剖析脚本python tests/load_tests/sys_profiling.py第 3 步在本地运行负载测试脚本向服务端发送请求python tests/load_tests/test_load_on_server.py -n 50 -r all --cloud aws该命令对launch、status、logs、jobs、serve五类 CLI 请求各并发 50 次云厂商限定为 AWS。第 4 步压测结束后终止剖析进程得到如本文第一节所示的资源使用汇总含 peak CPU / memory、blocking / non-blocking executor 内存峰值与均值。第 5 步根据阻塞长请求与非阻塞短请求worker 的峰值内存更新 worker 内存常数。官方 README 将这两个常数标注为_LONG_WORKER_MEM_GB与_SHORT_WORKER_MEM_GB位置在sky/server/requests/executor.py。从当前仓库源码来看这两个常量的实际定义位于 sky/server/config.pyLONG_WORKER_MEM_GB 0.4 # 单个长请求 worker 的内存估算GB SHORT_WORKER_MEM_GB 0.3 # 单个短请求 worker 的内存估算GB SERVER_WORKER_MEM_GB 0.4 # 单个 uvicorn server worker 的内存估算GBREADME 中的路径可能基于较早版本的目录结构实际以 config.py 为准。这些常数直接影响服务端 worker 池的容量计算_max_long_worker_parallism()依据available_mem * 0.6 / LONG_WORKER_MEM_GB计算长请求并行度上限config.py_max_short_worker_parallism()则从总内存中扣除长 worker 预留后再按SHORT_WORKER_MEM_GB计算短请求并行度config.py。文件注释同时强调这些估算与使用模式高度相关启用的云、请求类型等覆盖的是主要云与常见使用模式对偏离该模式的用户可通过环境变量覆盖估算。此外SKYPILOT_MEMORY_AWARE_WORKER_SIZING环境变量见 sky/utils/env_options.py可让服务端在划分 executor 池内存前先扣除 server worker 常驻进程与 consolidation 模式控制器的内存避免池容量估算超出机器物理内存。四、以 API 性能为焦点的 Benchmarkingtest_load_on_server.py亦可直接作为基准测试使用。需要警惕的陷阱是在高并发下客户端本机同时拉起大量skyCLI 进程会显著增加客户端侧延迟进程启动、Python 模块加载开销从而使测量结果失真。若希望基准聚焦于 API Server 本身官方推荐使用--apis参数直接调用 SDK 接口而非 CLI 子进程python tests/load_tests/test_load_on_server.py -n 100 --api status等价写法为--apis status实际参数名见 test_load_on_server.py。脚本注释中对此有专门说明test_load_on_server.pytest_cli_status_in_api用 SDK 调用链模拟sky status的行为正是因为 100 个并行 CLI 进程的模块加载会造成客户端拥塞——而在真实场景中多个用户从不同机器调用 CLI 并不会出现这一瓶颈因此这种客户端开销不属于服务端能力范畴。五、分布式客户端压测消除客户端瓶颈当并发度足够高时单台客户端会成为新的瓶颈导致基准测试测量的不再是 API Server 的性能。此时使用 test_distribute_load_on_server.py 将负载分发到多个 SkyPilot 集群客户端每个客户端运行独立的test_load_on_server.py实例# -t: 客户端实例数量 # --cpus: 每个客户端使用的 CPU 核数 # --memory: 每个客户端使用的内存GB # --url: 被测 API Server 的 URL建议把客户端部署在另一个 API Server 上以避免互相干扰 # ARGS_FOR_TEST_LOAD_ON_SERVER: test_load_on_server.py 的参数参考前文 python tests/load_tests/test_distribute_load_on_server.py -t 10 --cpus 2 --memory 8 --url API_SERVER_URL ARGS_FOR_TEST_LOAD_ON_SERVER从源码看test_distribute_load_on_server.py该脚本的可选参数还包括--workdir本地 SkyPilot 仓库路径用于挂载到客户端与--branch指定 git 分支客户端将克隆该分支作为工作目录。其实现机制是通过sky.launch在 Kubernetes 集群上为每个客户端创建名为benchmark-i的 VM挂载本地仓库作为 workdir或按分支 clone安装skypilot-nightly[kubernetes,aws,gcp]后执行sky api login -e url并运行test_load_on_server.py见 test_distribute_load_on_server.py。脚本注释特意指出使用sky launch而非sky jobs launch是为了获得可预测的客户端并行度。压测结束后所有客户端集群会被自动销毁。六、进阶配置驱动的混合模式基准除 README 中直接介绍的脚本外同一目录还提供了更完整的基准工具链。以 benchmark_ctl.py 为控制器、benchmark_worker.py 为 worker 执行端可通过一个 YAML 配置同时叠加四种负载生成器定义于 config.pyshell运行 bash 工作负载脚本如 workloads/basic.sh覆盖 launch→exec→ssh→logs→queue→status→stop→start→down 的完整集群生命周期与 managed jobs 操作属闭环closed-loop压力qps开放环open-loop的固定速率 QPS 引擎sky.status/sky.jobs.queue等目标 QPS 为全局值、按 worker 数均分long_conn维持 N 条并发长连接会话ssh_idle/logs_follow压测 WebSocket 长连接通道ssh_bench反复打开/关闭到 victim 集群的 SSH 会话记录连接延迟。示例配置见 configs/mixed.yaml 与 configs/ssh.yaml核心结构包括target被测 API Server 端点、认证方式、云、workersworker VM 数量与规格、duration_sQPS 与长连接的墙钟围栏、victim_pool供长连接/SSH 压测使用的目标集群池与generators列表。运行方式python tests/load_tests/benchmark_ctl.py \ --config tests/load_tests/configs/mixed.yaml \ --target-endpoint http://user:passyour-api-server控制器自动完成拉起 worker VM → 下发基准 → 通过 base64gzip 封装回收结果 JSON → 汇总输出含 P50/P95/P99 的报告 → 清理资源的完整闭环见 benchmark_ctl.py 与报告打印逻辑 benchmark_ctl.py。这一套件适合需要同时施加慢速生命周期操作 恒定短读 长连接 SSH 突发混合压力、且结果要求可复现的高级基准场景。七、最佳实践与注意事项综合官方 README 与源码实现实践中有以下几点值得注意剖析与压测必须同步剖析脚本提供的是时间窗口内的峰值与均值只有与压测并发执行才能捕捉到真实的资源上限压测结束后立即终止剖析可得到完整的基线-峰值对比。以 API 模式为准的基准凡是关注 API Server 自身性能的测量优先使用--apis/--api模式CLI 并发会引入客户端模块加载开销污染延迟数据。高并发必须分布式压测当并发客户端本身成为瓶颈时用test_distribute_load_on_server.py把负载分散到多个集群客户端并尽量将客户端与被测服务端部署在不同 API Server 上。worker 内存常数与使用模式强相关LONG_WORKER_MEM_GB与SHORT_WORKER_MEM_GB的取值依赖具体使用模式启用哪些云、请求类型分布等实测后按峰值内存更新并可通过SKYPILOT_MEMORY_AWARE_WORKER_SIZING环境变量启用更精确的内存感知池容量计算文件注释中的 TODO 亦指出未来计划根据系统使用统计自动在运行时调优并行度见 sky/server/config.py届时手工维护常数的负担有望消除。工作量不代表生产全貌README 明确警示简单负载可能无法覆盖真实世界的 API Server 使用模式需要更精确测量时可补充运行 smoke tests。所有性能结论都应基于你自己的环境实测切勿直接套用任何示例数字作为生产容量规划的结论。【免费下载链接】skypilotThe AI Compute Platform for frontier teams. SkyPilot turns fragmented AI compute into one AI supercomputer, so frontier AI teams build custom intelligence faster.项目地址: https://gitcode.com/GitHub_Trending/sk/skypilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
