文章目录
前言
在上一篇博客中，尝试构建了多种mcp_server。接下来考虑，如何将我们的多mcp_server给前端提供api接口。
一、fastapi的简单入门
参考文献：https://www.bilibili.com/video/BV18F4m1K7N3
1：安装必要的包（python=3.11）：
conda activate langchain
pip install fastapi
2：快速搭建一个fastapi：
文件目录如下图：
# 导入必要的模块
from fastapi import FastAPI # 导入 FastAPI 框架，用于构建 API
import uvicorn # 导入 Uvicorn，一个基于 asyncio 的 ASGI web 服务器，用于运行 FastAPI 应用
from fastapi import Request # 导入 Request 对象，用于获取请求的详细信息（如查询参数、请求体等）
from fastapi.staticfiles import StaticFiles # 用于挂载静态文件目录（如图片、CSS、JS 等）
from api.book import api_book # 导入图书相关的路由模块
from api.cbs import api_cbs # 导入出版社相关的路由模块
from api.zz import api_zz # 导入作者相关的路由模块
# 创建 FastAPI 应用实例
app = FastAPI()
# 挂载静态文件目录
# 将 "/upimg" 路径映射到本地 "upimg" 文件夹，允许用户通过 URL 访问该目录下的静态文件（如上传的图片）
# 例如：访问 http://127.0.0.1:8080/upimg/test.jpg 会返回 upimg/test.jpg 文件
# app.mount("/upimg", StaticFiles(directory="upimg"), name="upimg")
# 注册路由（API 子应用）
# 使用 include_router 将不同模块的 API 路由注册到主应用中，并设置统一前缀和标签（用于文档分类）
app.include_router(api_book, prefix="/book", tags=["图书接口"]) # 图书相关接口，路径前缀为 /book
app.include_router(api_cbs, prefix="/cbs", tags=["出版社接口"]) # 出版社相关接口，路径前缀为 /cbs
app.include_router(api_zz, prefix="/zz", tags=["作者接口"]) # 作者相关接口，路径前缀为 /zz
# 根路径接口，用于测试服务是否正常运行
@app.get("/")
async def root():
return {"message": "Hello World"}
# 自定义测试接口，返回固定消息
@app.get("/xixi")
async def xixi():
return {"message": "Hello xixi"}
# GET 请求测试接口
# 接收查询参数（query parameters），并打印到后端控制台
@app.get("/get_test")
async def get_test(request: Request):
get_test_message = request.query_params # 获取 URL 中的查询参数（如 ?name=abc&age=123）
print("收到 GET 请求参数：", get_test_message) # 打印参数到控制台
return {"message": "Hello xixi"}
# POST 请求测试接口
# 接收 JSON 格式的请求体（request body），并打印内容
@app.post("/post_test")
async def post_test(request: Request):
post_test_message = await request.json() # 异步读取请求体中的 JSON 数据
print("收到 POST 请求数据：", post_test_message) # 打印接收到的 JSON 数据
return {"message": "Hello xixi"}
# 主程序入口
# 当直接运行此脚本时，启动 Uvicorn 服务器
if __name__ == '__main__':
# 运行 FastAPI 应用
# 参数说明：
# "myfastapi:app" -> 模块名:应用实例名（即当前文件名为 myfastapi.py，app 是 FastAPI 实例）
# host="127.0.0.1" -> 绑定本地回环地址
# port=8080 -> 使用 8080 端口
# reload=True -> 开启热重载，代码修改后自动重启服务（适合开发环境）
uvicorn.run("myfastapi:app", host="127.0.0.1", port=8080, reload=True)
运行后可以浏览访问http://127.0.0.1:8080/docs查看接口文档
二、提升问答的响应速度
基于第一小节的fastapi，笔者搭建了一个chat接口，用于调用本地大模型。
1. fastapi部署后端接口，在局域网内访问的方法
首先把ip改为0.0.0.0，
if __name__ == '__main__':
# uvicorn.run("myfastapi2:app", host="127.0.0.1", port=8080, reload=True)
uvicorn.run("myfastapi2:app", host="0.0.0.0", port=8080, reload=True)
然后把本机的8080端口放开，具体操作，可参考博客，然后局域网内的其他主机就可以访问了：
2. 局域网内的测试：“未来科技有限公司的差旅费标准”PDF的RAG问答：
PDF原文件部分截图如下：
2.1 使用qwq32b模型（19GB）
在我的电脑上用postman测试下。结果还是比较准确的,对于这个文档，RAG的效果还是可以的。可以看到一次提问的响应时间是52.39s。模型需要的响应时间太长了，接下来考虑如何提速。这里使用的是qwq32b模型（19GB），因此考虑换一个更小的模型试一下。
2.2 使用qwen3:8b模型（5.2GB），平均30s
这里使用qwen3:8b（5.2GB），使用相同的问题调用接口，结果如下。可以看到，看模型的输出结果，也是没有问题的，但是所需要的时间大幅度缩小，变为了26.55s。
2.3 使用qwen3:8b模型（5.2GB），改进了rag_server的写法，，平均18s
通过chatgpt，进一步优化了rag_server，代码如下：
async def get_answer(question: str) -> str:
"""使用 RAG Chain 回答问题"""
try:
start = time.time()
context_text = await retriever.ainvoke(question.strip())
# LLM 调用
start_llm = time.time()
final_prompt = prompt.format(context=context_text, input=question)
response = await llm.ainvoke(final_prompt)
logger.info(f"🟢 LLM 生成完成，耗时: {time.time() - start_llm:.2f}s")
logger.info(f"✅ 总耗时: {time.time() - start:.2f}s")
return StrOutputParser().invoke(response)
except Exception as e:
logger.exception("❌ 问答过程中发生异常")
return f"问答过程中出错：{str(e)}"
3. 如何进一步提速？
3.1 模型推理优化
(1) 使用更小的模型；（暂不采纳）
(2) 减少生成的token数；
LLM推理时间 = 上下文长度 + 输出长度；如果只是回答文档中的问题，不必生成很长的上下文，在 LangChain 调用时传：llm = ChatOllama(model="qwen3:8b", temperature=0, num_predict=200) num_predict默认是256？
让我们来试一下看看效果。设num_predict=200，时间数据表明，的确提速了！但是，答案被强制截断了，输出是不完整的，只输出了< think >中的内容。
(3) 控制上下文窗口（prompt压缩）（暂不采纳）
Qwen3:8b 的上下文窗口很大，但你传进去的 context 越长，推理速度越慢
检索 k=1 是很好的，但也要确保 doc 片段不要太长
可以在构造 RAG 时裁剪：doc.page_content[:1000] # 控制单片段长度
(4) 调整GPU批处理参数
Ollama 的后端支持 kv_cache 批量生成，在启动模型时可设置：ollama run qwen3:8b --num-thread 16 --num-gpu 1
已经100%运行在GPU上了。
3.2 调用链路优化
(1) 流式输出（可行，这样从向量数据库中查询的过程所花的时间不可省略，但是最后给LLM所得到的LLM的输出可以流式输出，给人一种时间缩短的感觉）
让前端/调用方边生成边显示，不用等 8~9 秒全部生成完才显示
LangChain 里可以改成：
async for chunk in llm.astream(final_prompt):
print(chunk.content, end="", flush=True)
(2) 缓存相似查询（可以一试）
对相同 embedding 检索结果的 Prompt → LLM 输出做缓存；
Python 可以直接用 functools.lru_cache 或 Redis 做缓存
(3) 避免重复加载模型（可行）
Ollama 第一次加载模型会花几秒，之后在 GPU 内存中保持热启动；
确保你的进程是长驻的（FastAPI、MCP Server 不要频繁重启）
3.3 多模型协作（可以一试）
如果不追求每一步都是 Qwen3:8b 的高质量输出，可以用：
小模型（3B/4B） 先做快速判断 + 检索 → 再由大模型做最终生成；
这样 Qwen3:8b 的推理时间可以减少 %-%