在不断发展的大型语言模型(LLMs)领域中,用于支持这些模型的工具和技术正以与模型本身一样快的速度进步。在这篇文章中,我们将总结5种搭建开源大语言模型服务的方法,每种都附带详细的操作步骤,以及各自的优缺点。
1、Anaconda + CPU
我们首先介绍门槛最低的入门级方法,因为这个方法不需要GPU,基本上只要有一个还不错的CPU和足够RAM就可以运行。
这里我们使用llama.cpp及其python绑定llama-cpp-python
pip install llama-cpp-python[server] \
--extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu
创建一个名为models/7B的目录来存储下载的模型。然后使用命令下载GGUF格式的量化模型:
mkdir -p models/7B
wget -O models/7B/llama-2-7b-chat.Q5_K_M.gguf https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGUF/resolve/main/llama-2-7b-chat.Q5_K_M.gguf?download=true
然后就可以运行以下命令启动服务器:
python3 -m llama_cpp.server --model models/7B/llama-2-7b-chat.Q5_K_M.gguf
将环境变量MODEL设置为下载模型的路径。然后运行openai_client.py脚本就可以访问我们的查询服务器。openai_client.py使用OpenAI库调用LLM服务器并打印响应。
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{
"role": "user",
"content": "What are the names of the four main characters of South Park?",
},
]
因为这个方法是门槛最低的,所以他的速度也是最慢的,基于Intel®Core™i9-10900F CPU @ 2.80GHz的系统的处理时间大概是13秒左右,所以这个方法一般用作我们的本地测试服务(如果你GPU不够的话)。
2、Anaconda + GPU
前面的CPU方法是非常慢的,为了加快速度我们将使用vllm,这是一个专门为有效利用gpu而设计的工具。
pip install vllm
执行以下命令来启动服务器:
python -m vllm.entrypoints.openai.api_server --model TheBloke/Llama-2-7B-Chat-AWQ --api-key DEFAULT --quantization awq --enforce-eager
这将下载AWK量化模型并启动一个OpenAI兼容服务器,我们可以像使用llama.cpp一样进行查询。
“— enforce-eager”是费差个重要的,因为它允许模型在我的10G VRAM GPU中运行,没有内存不足的错误。
在Nvidia RTX 3080 GPU和Intel®Core™i9-10900F CPU的系统下处理时间只有0.79s。CPU快20倍左右,这就是为什么GPU现在都那么贵的一个原因。
这种方式可以用做我们测试服务器或者在线上的小规模部署,如果要求不高,也可以当作生产环境来使用,当然维护起来非常麻烦。
3、Docker + GPU
vllm有很多依赖,如果要批量的安装是一件非常耗时的事情。好在vllm还提供了一个预构建的docker映像,它已经包含了所需的所有库。
对于ubuntu,我们首先安装Nvidia CUDA Toolkit,如果安装了则跳过
sudo apt install nvidia-cuda-toolkit
然后添加Nvidia Docker存储库并安装Nvidia Container Toolkit:
distributinotallow=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker
配置Docker使用Nvidia runtime:
sudo tee /etc/docker/daemon.json <<EOF
{
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}
EOF
sudo pkill -SIGHUP dockerd
然后就可以运行我们的模型了
docker run --runtime nvidia --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
--ipc=host \
vllm/vllm-openai:latest \
--model TheBloke/Llama-2-7B-Chat-AWQ \
--quantization awq --enforce-eager
这里我们使用-v参数将本地的磁盘映射到容器中,这样所有的容器都可以使用huggingface的模型缓存,避免了重复下载。
docker的部署方式处理一个查询的时间在0.8s左右与使用相同硬件在Anaconda上运行vllm相似。
使用docker可以大大简化我们服务器的环境配置,配合集群管理脚本可以适用于大规模的服务部署。
上面的方式都适用于本地和有GPU主机/集群的方式,下面我们介绍2个比较简单的云GPU的方案,这两个方案都是按需付费的。
4、modal
Modal可以简化无服务器应用程序的部署,特别是那些利用GPU资源的应用程序。它的一个突出的特点是它的计费模式,它确保用户只在他们的应用程序使用GPU资源的持续时间内收费。这意味着当你的应用程序不被使用时则不会收费。
Modal还提供每月30美元的优惠,为用户提供了充分的机会来探索和试验部署gpu加速的应用程序,而无需支付前期费用,这也是我们介绍他的一个原因,因为每月目前还能白嫖30美元,哈。
首先安装:
pip install modal
然后配置modal的运行环境,这一步需要登陆了
modal setup
我们这里的vllm_modal_deploy.py改编Modal的官方教程。这个脚本最重要的一点是定义GPU。这里我选择了nvidia T4,因为量化模型非常小:
# https://modal.com/docs/examples/vllm_mixtral
import os
import time
from modal import Image, Stub, enter, exit, gpu, method
APP_NAME = "example-vllm-llama-chat"
MODEL_DIR = "/model"
BASE_MODEL = "TheBloke/Llama-2-7B-Chat-AWQ"
GPU_CONFIG = gpu.T4(count=1)
然后定义运行代码的docker镜像:
vllm_image = ( # https://modal.com/docs/examples/vllm_mixtral
Image.from_registry("nvidia/cuda:12.1.1-devel-ubuntu22.04", add_pythnotallow="3.10")
.pip_install(
"vllm==0.3.2",
"huggingface_hub==0.19.4",
"hf-transfer==0.1.4",
"torch==2.1.2",
)
.env({"HF_HUB_ENABLE_HF_TRANSFER": "1"})
.run_function(download_model_to_folder, timeout=60 * 20)
)
定义App:
stub = Stub(APP_NAME)
最后编写预测的类:
class Model:
@enter() # Lifecycle functions
def start_engine(self):
import time
from vllm.engine.arg_utils import AsyncEngineArgs
from vllm.engine.async_llm_engine import AsyncLLMEngine
print("? cold starting inference")
start = time.monotonic_ns()
engine_args = AsyncEngineArgs(
model=MODEL_DIR,
tensor_parallel_size=GPU_CONFIG.count,
gpu_memory_utilizatinotallow=0.90,
enforce_eager=False, # capture the graph for faster inference, but slower cold starts
disable_log_stats=True, # disable logging so we can stream tokens
@enter()装饰器被用来定义生命周期方法来处理代码的初始化之类的事情。所以我们在这里加载模型并设置生成管道。如果查询触发了此方法,则意味着有一个“冷启动”,也就是第一次启动的耗时会比较长。
定义生成函数:
@stub.function()
def generate(user_question: str):
model = Model()
print("Sending new request:", user_question, "\n\n")
result = ""
for text in model.completion_stream.remote_gen(user_question):
print(text, end="", flush=True)
result += text
return result
最后就是使用命令行进行部署
modal deploy vllm_modal_deploy.py
部署完成后就可以从python调用这个函数:
import timeit
import modal
APP_NAME = "example-vllm-llama-chat"
f = modal.Function.lookup(APP_NAME, "generate")
start_time = timeit.default_timer()
print(f.remote("What are the names of the four main characters of South park?"))
elapsed = timeit.default_timer() - start_time
print(f"{elapsed=}")
经过我的测试第一次启动大约需要37秒。这包括启动时间和处理时间。应用程序已经启动时的延迟是2.8秒。这些都是在Nvidia T4上运行的,所以3秒还是可以接受的。
需要注意:container_idle_timeout的值是用来回收容器的,超过了这个时间值会进行回收,这样再次启动就会调用初始化的过程,也就是我们说的冷启动。但是因为modal的计费方式,再未回收前都是计费的,所以请谨慎修改。
最后说下费用:Modal的Nvidia T4收费是0.000164 * /秒 或 0.59 * /小时。上面我们使用了几百秒的计算时间,花费了大约0.1美元。
5、AnyScale
Anyscale与Modal类似,但他更专注于提供随时可用的开源模型。我们可以使用Anyscale API的URL直接调用它们。
首先注册并获得API密钥。你可以使用他们提供给新用户的10*$免费套餐来运行本教程。
接下来,我们将使用与之前相同的openai_client.py脚本:
export API_KEY="CHANGEME"
export MODEL="meta-llama/Llama-2-7b-chat-hf"
export BASE_URL="https://api.endpoints.anyscale.com/v1"
python openai_client.py
不需要任何的设置,只要我们在发送请求时修改参数就可以访问不同的模型了,这就是Anyscale的优势
这个请求的延迟大约是3.7秒,还算不错。但是AnyScale是按照令牌来计费的(与OpenAI的API相同)LLama2 7B 的价格是0.15*$ / 1M 令牌。我们运行这个示例花费不到1/10美分。
可以看到AnyScale还是很不错的,对于开源模型我们直接可以拿来使用,并且花费也很低,如果你没有GPU,这个可以作为模型测试的首选平台,一个月几十美元基本上够我们测试当月新发布的所有模型了。
总结
当涉及到服务大型语言模型(llm)时,有各种各样的方法可以选择:
对喜欢本地服务器设置的人来说,使用带有CPU的Anaconda提供了较低的进入门槛,gpu加速的Anaconda环境可以缓解延迟问题,但它仍然面临可伸缩性和对本地资源的依赖方面的限制,特别是在处理大型llm时。
Docker可以简化Python环境配置,可以适应大批量的部署。
Modal提供了一种更灵活的按次付费计算解决方案,使其具有成本效益和易于设置的吸引力。
AnyScale提供了较低的进入门槛对于那些追求简单的人来说是一个非常好的选择。
我们介绍的这些方法是一个很好的起点,还有很多其他服务比如runpod和AWS,但这些方法需要更多的运维知识,并且在小规模部署上优势并不明显,所以要考虑对针对特定需求和要求量身定制的最佳方案还需要进行全面评估。