【大模型开源项目】FastAPI结合vLLM，开发适配openai-api的接口，轻量级易扩展

1 速览

项目地址：LyLM 轻量级、易扩展，你的开发起点

1.1 主要用途

这是一个结合FastAPI和vLLM的开源项目，不少开发者在使用vLLM部署时，一般使用简单的命令行，但是自由度不够，如果你想要以工程项目的方式部署呢？这时候你需要考虑使用vllm包来做封装、然后再写一套FastAPI的逻辑，再对齐openai-api才能跑通。

那么这个项目的目的就是，提供一个轻量级、易扩展的模板项目作为你的起点，而你只需要确保你有最基本的开发环境就行（vllm、fastapi等基本的包）。

1.2 如何开始？

点击 LyLM 复制github链接，clone到本地

git clone git@github.com:JustinChen719/LyLM.git

确保你有conda环境，以我的为参考，我的基础环境是：
python 3.12、torch 2.6、cuda 12.4、vllm 0.8.3、fastapi 最新版本
准备配置文件

common 配置项待定
models 请按照模型名称分类，并且每一个模型下配置一个数组，表示实际的实例：
- devices：配置实例的 GPU 设备号，以及权重，权重越大使用概率越大，必须是大于零的整数或者浮点数
- engine_args：配置引擎参数，参考 https://github.com/vllm-project/vllm/blob/main/vllm/engine/arg_utils.py
如下所示，首先需要确保的是每一个模型实例的engine_args参数的model参数，这是模型权重的位置，不要填错，你可以从huggingface上下载，然后填权重文件位置。

另外，目前版本仅支持单机多卡配置。

{
  "common": {
  },
  "models": {
    "Qwen/Qwen2.5-7B-Instruct": [
      {
        "devices": {
          "gpu_ids": [0, 1],
          "weight": 1
        },
        "engine_args": {
          "model": "/root/***/Qwen2.5-7B-Instruct/",
          "max_model_len": 8192,
          "max_num_seqs": 256,
          "max_num_batched_tokens": 16384,
          "gpu_memory_utilization": 0.90,
          "tensor_parallel_size": 2
        }
      },
      {
        "devices": {
          "gpu_ids": [3, 4],
          "weight": 2
        },
        "engine_args": {
          "model": "/root/***/Qwen2.5-7B-Instruct/",
          "max_model_len": 8192,
          "max_num_seqs": 256,
          "max_num_batched_tokens": 16384,
          "gpu_memory_utilization": 0.90,
          "tensor_parallel_size": 2
        }
      }
    ],
    "Qwen/Qwen2.5-1.5B-Instruct": [
      {
        "devices": {
          "gpu_ids": [2],
          "weight": 1
        },
        "engine_args": {
          "model": "/root/***/Qwen2.5-1.5B-Instruct/",
          "max_model_len": 8192,
          "max_num_seqs": 256,
          "max_num_batched_tokens": 16384,
          "gpu_memory_utilization": 0.75
        }
      }
    ],
    "Qwen/Qwen2.5-3B-Instruct": [
      {
        "devices": {
          "gpu_ids": [5],
          "weight": 1
        },
        "engine_args": {
          "model": "/root/***/Qwen2.5-3B-Instruct/",
          "max_model_len": 8192,
          "max_num_seqs": 256,
          "max_num_batched_tokens": 16384,
          "gpu_memory_utilization": 0.80
        }
      }
    ]
  }
}

此外还需要有一个.env的配置文件
CONFIG_PATH：是必须配置的
TORCH_CUDA_ARCH_LIST：是为了使用FlashInfer，可以使用torch查询到该值（可以不填但不能错）
VLLM_CACHE_ROOT：改变vllm cache位置

CONFIG_PATH=/root/***/***/config.json

TORCH_CUDA_ARCH_LIST=8.6

VLLM_CACHE_ROOT=/root/***/.cache/

main.py 为程序入口，配置解释器启动项目即可

2 功能点

2.1 单机负载均衡

大家可能知道vllm自带调度机制，但是如果单机8卡的情况，假如你使用双卡张量并行，这个时候你可以部署四个实例，那么LyLM可以提供负载均衡。

比如在上面的配置下，Qwen/Qwen2.5-7B-Instruct模型有两个实例，并且两个实例的权重优先级（devices中的weight参数）分别为1和2，那么最终请求会按照1：2的比例分配到两个实例上。

如下图所示，可以看到两个实例的实际接受请求数是大致1：2的比例。
在这里插入图片描述

2.2 配置简单、支持指定gpu

通过配置中，实例的devices参数的gpu_ids可以指定该实例可利用的gpu，还是以上述配置为例，项目启动后，资源占用情况如下：
在这里插入图片描述
可以看到Qwen/Qwen2.5-7B-Instruct分别占用0,1和3,4卡，并且显存利用率最大限制90%，以及Qwen/Qwen2.5-1.5B-Instruct和Qwen/Qwen2.5-3B-Instruct分别占用2号和5号卡，显存占用限制75%和80%，全部应验。（这里只能说是vLLM牛，对显存的拿捏十分精准）

3 性能测试

这里测试也是测了vLLM性能，和我的框架关系不大，只能说我没有拖后腿吧QVQ。

可以看出这里是vLLM自己的KVCache Manager、Scheduler以及Flash attn发力了

3.1 Qwen2.5-3B、单卡4090、并发推理实验

并发数	总请求	成功率	平均端到端延迟（秒）	平均响应长度（tokens）	单请求生成速率（tokens/s）	系统吞吐量（tokens/s）	总耗时（秒）
256	512	100.00%	4.94	181.27	36.69	1937.13	47.91
128	512	100.00%	4.53	142.27	31.41	8805.50	8.27
128	256	100.00%	2.64	137.24	52.04	8274.23	4.25
64	256	100.00%	2.45	138.89	56.65	8314.08	4.28
64	128	100.00%	1.48	134.08	90.82	6476.60	2.65
32	128	100.00%	1.54	138.79	90.33	6024.02	2.95
32	64	100.00%	1.18	141.67	120.10	3174.14	2.86
16	64	100.00%	1.10	131.28	119.41	3981.02	2.11
16	32	100.00%	0.98	138.59	141.31	2373.31	1.87
8	32	100.00%	0.99	137.12	138.54	1884.90	2.33
8	16	100.00%	0.87	131.12	149.86	1042.88	2.01
4	16	100.00%	0.89	131.00	146.47	1290.63	1.62
4	8	100.00%	1.00	151.38	151.52	829.03	1.46
2	8	100.00%	0.84	132.25	156.52	903.15	1.17
2	4	100.00%	0.84	133.75	158.61	520.66	1.03
1	4	100.00%	0.82	133.00	161.37	422.56	1.26

3.2 Qwen2.5-7B、双卡4090张量并行、并发推理实验

并发数	总请求	成功率	平均端到端延迟（秒）	平均响应长度（tokens）	单请求生成速率（tokens/s）	系统吞吐量（tokens/s）	总耗时（秒）
128	512	100.00%	31.66	443.49	14.01	2784.71	81.54
128	256	100.00%	16.12	411.58	25.53	4515.36	23.33
64	256	100.00%	16.41	425.42	25.93	5119.46	21.27
64	128	100.00%	9.14	424.61	46.47	4409.28	12.33
32	128	100.00%	9.45	427.09	45.20	4444.16	12.30
32	64	100.00%	5.59	412.97	73.93	3180.01	8.31
16	64	100.00%	6.00	435.34	72.55	3399.13	8.20
16	32	100.00%	4.24	420.16	99.10	1979.90	6.79
8	32	100.00%	4.69	469.97	100.21	2229.32	6.75
8	16	100.00%	3.81	462.69	121.30	1406.46	5.26
4	16	100.00%	3.35	413.31	123.52	1033.58	6.40
4	8	100.00%	3.51	467.88	133.20	822.80	4.55
2	8	100.00%	2.57	355.88	138.36	770.25	3.70
2	4	100.00%	2.07	307.50	148.69	420.90	2.92
1	4	100.00%	3.38	497.50	147.02	515.03	3.86