《AI大模型应用开发实战从入门到精通共60篇》028、OpenAI API兼容接口：用FastChat搭建自己的API服务

028、OpenAI API兼容接口：用FastChat搭建自己的API服务

昨晚调试到凌晨三点，客户那边反馈说GPT-4调用量超限了，业务直接卡死。我盯着终端里那行“Rate limit exceeded”看了半天，突然意识到一个问题——为什么非要死磕OpenAI的官方API？本地部署一个兼容接口，既能跑开源模型，又能无缝切换回GPT-4，这不香吗？

FastChat就是干这个的。它能把LLaMA、Vicuna、ChatGLM这些模型包装成和OpenAI API一模一样的接口，你代码里那些openai.ChatCompletion.create()调用，改个base_url就能直接怼到本地服务上。今天就把这套搭建流程掰开揉碎讲清楚。

环境准备：别在Python版本上翻车

先说我踩过的坑。FastChat对Python版本有隐性要求，3.8以下直接报typing模块缺失，3.11以上某些依赖包还没适配。我建议锁死在3.10，省心。

# 这里踩过坑，别用conda默认的3.7conda create-nfastchatpython=3.10conda activate fastchat

安装FastChat时有个坑——如果你在墙内，pip install fschat会卡在flash-attn这个依赖上。这玩意儿是加速库，但编译巨慢。解决方案是加个--no-deps先装主体，再单独装其他依赖：

# 别这样写：pip install fschat # 会卡死pipinstallfschat --no-deps pipinstalltransformers accelerate sentencepiece protobuf# flash-attn可选，没有也能跑，就是慢点

模型下载：选对模型省一半功夫

模型选择上，我建议新手别碰LLaMA原版，那玩意儿需要申请权重，流程繁琐。直接上ChatGLM3-6B或者Qwen-7B，HuggingFace上直接下，中文效果还更好。

# 这里踩过坑：用git lfs clone会下半天，还容易断# 推荐用huggingface_hub的snapshot_download，支持断点续传fromhuggingface_hubimportsnapshot_download# 别这样写：model_path = "./models/chatglm3-6b" # 手动下载容易缺文件model_path=snapshot_download(repo_id="THUDM/chatglm3-6b",local_dir="./models/chatglm3-6b",resume_download=True,# 断点续传，网络不稳时救命ignore_patterns=["*.h5","*.ot","*.msgpack"]# 这些文件用不上，省空间)

如果你在服务器上跑，记得先检查显存。ChatGLM3-6B的FP16版本大概需要13GB显存，Qwen-7B差不多。显存不够就上4bit量化，后面会讲。

启动Controller和Worker：理解FastChat的架构

FastChat的架构分三层：Controller（调度中心）、Worker（模型工人）、API Server（对外接口）。我第一次启动时直接跳过了Controller，结果API Server一直报连接拒绝。

先启动Controller，它负责管理所有Worker的状态：

# 这个进程不能关，关了所有Worker都会掉线python-mfastchat.serve.controller--host0.0.0.0--port21001

然后启动Worker，把模型加载进去。这里有个关键参数——--num-gpus，如果你有多卡，别一股脑全用上，留一张给API Server和其他服务：

# 别这样写：--num-gpus 4 # 把所有卡都占了，其他服务没得用python-mfastchat.serve.model_worker\--model-path ./models/chatglm3-6b\--controllerhttp://localhost:21001\--workerhttp://localhost:21002\--host0.0.0.0\--port21002\--num-gpus1\--load-8bit# 显存不够时加这个，8bit量化

Worker启动时会加载模型，这个过程慢是正常的。我第一次等了两分钟没反应，以为卡死了，差点Ctrl+C。实际上它在下载tokenizer和配置文件，耐心等。

启动API Server：让接口和OpenAI一模一样

这是最爽的一步。API Server启动后，你的本地模型就拥有了和OpenAI完全兼容的接口：

python-mfastchat.serve.openai_api_server\--controllerhttp://localhost:21001\--host0.0.0.0\--port8000

启动成功后，你会看到类似这样的输出：

INFO: Uvicorn running on http://0.0.0.0:8000

现在用curl测试一下，注意看请求格式——和OpenAI的ChatCompletion API完全一致：

curlhttp://localhost:8000/v1/chat/completions\-H"Content-Type: application/json"\-d'{ "model": "chatglm3-6b", "messages": [{"role": "user", "content": "你好，请用中文回答"}], "temperature": 0.7, "max_tokens": 512 }'

返回的JSON结构和OpenAI一模一样，有id、object、choices这些字段。这意味着你现有的OpenAI SDK代码，只需要改一行就能切过来。

客户端代码改造：一行代码切换模型

假设你原来用的是OpenAI的Python SDK：

# 原来的代码importopenai openai.api_key="sk-xxxx"# 这里踩过坑：本地服务不需要key，但SDK会校验格式openai.api_base="https://api.openai.com/v1"# 改成这样importopenai openai.api_key="EMPTY"# 随便填，但不能为空字符串，否则报错openai.api_base="http://localhost:8000/v1"# 指向本地FastChat# 调用方式完全不变response=openai.ChatCompletion.create(model="chatglm3-6b",messages=[{"role":"user","content":"讲个冷笑话"}])print(response.choices[0].message.content)

注意那个api_key，我一开始填了空字符串，结果SDK直接抛异常说API key格式不对。后来发现只要填个非空字符串就行，FastChat根本不校验。

多模型切换：一个API服务挂多个模型

FastChat支持同时加载多个模型，每个模型一个Worker。比如我再加一个Qwen-7B：

# 第二个Worker，端口不能冲突python-mfastchat.serve.model_worker\--model-path ./models/Qwen-7B-Chat\--controllerhttp://localhost:21001\--workerhttp://localhost:21003\--host0.0.0.0\--port21003\--num-gpus1

然后在客户端调用时，model参数填对应的模型名就行。FastChat会自动把请求路由到对应的Worker上。这个特性在A/B测试时特别有用——同一个API服务，不同用户用不同模型，代码层面零改动。

性能调优：别让模型跑成蜗牛

如果你发现响应速度慢，先检查这几个地方：

1. Worker数量：默认每个模型只有一个Worker，并发请求会排队。可以加--worker-num 2参数启动多个Worker实例，但注意显存占用会翻倍。

2. 批处理：FastChat支持--batch-size参数，把多个请求合并成一个batch推理。我实测batch_size=4时吞吐量提升3倍，但延迟会增加。适合离线批量处理，不适合实时对话。

3. 量化：显存不够时用--load-8bit或--load-4bit。4bit量化后ChatGLM3-6B的显存占用降到4GB左右，但生成质量会下降。我一般只在开发环境用4bit，生产环境至少8bit。

4. 流式输出：客户端请求时加stream=True，服务端会逐token返回。但FastChat的流式实现有个bug——如果模型生成过程中报错，流会直接断掉，客户端收不到错误信息。建议在客户端加超时重试逻辑。

生产部署：别忘了加鉴权和负载均衡

如果你把这个服务暴露到公网，有几个坑必须填：

• 鉴权：FastChat默认没有鉴权，谁都能调。可以用Nginx加个API Key校验，或者用FastAPI的中间件自己写一个。我写了个简单的装饰器，检查请求头里的Authorization字段。

• 负载均衡：单机扛不住并发时，可以启动多个Worker实例，前面挂Nginx做负载均衡。注意每个Worker的--worker-address要不同，否则Controller会报地址冲突。

• 健康检查：Controller和Worker之间有心跳机制，但API Server没有。我写了个定时任务，每30秒调一次/v1/models接口，如果返回非200就重启服务。

个人经验：什么时候该用FastChat，什么时候不该用

FastChat最大的价值不是性能，而是接口兼容性。如果你的团队已经基于OpenAI API开发了一套完整的工具链（比如LangChain、AutoGPT），用FastChat做本地部署几乎是零迁移成本。

但别指望它替代生产级的推理服务。FastChat的Worker是单进程的，一个Worker挂了整个模型就不可用。而且它没有内置的请求排队、限流、监控这些功能。真要上生产，还是得用vLLM、TGI这些专门优化的推理引擎。

我的建议是：开发测试阶段用FastChat快速验证，上线前再迁移到vLLM。vLLM也兼容OpenAI API格式，迁移成本极低。后面我会专门写一篇vLLM的部署实战，到时候你就知道怎么无缝切换了。

最后说一句，别在模型选择上纠结太久。ChatGLM3-6B和Qwen-7B在中文场景下差距不大，先跑起来再说。模型可以换，架构不能等。