基于大语言模型的毕设实战：从选题到部署的完整技术路径

最近在辅导学弟学妹做毕业设计，发现一个挺普遍的现象：大家选题时一窝蜂地想做“基于大语言模型”的项目，但真正动手后，从选题到部署，每一步都容易踩坑。要么选题太大，比如“做一个通用人工智能助手”，根本做不完；要么好不容易跑通了模型，却不知道怎么封装成服务、怎么设计前端交互，最后答辩只能干巴巴地展示一个命令行窗口。今天，我就结合自己做过的一个真实项目，跟大家聊聊如何走通从选题到部署的完整技术路径，希望能帮你把毕设做得更扎实、更有展示度。

1. 背景痛点：我们常踩的那些“坑”

在做LLM相关的毕设时，最容易在以下几个地方“翻车”：

选题空泛，缺乏边界：这是最常见的问题。比如“基于大模型的智能客服系统”，这个题目本身没问题，但如果不加限定，范围就太大了。你需要明确：客服针对哪个垂直领域（如IT故障排查、电商售后）？使用什么具体模型（ChatGLM3-6B还是Qwen-7B）？实现哪些核心功能（仅多轮对话，还是包含知识库检索）？一个可行的思路是“小而深”，例如“基于Qwen-7B和本地知识库的计算机故障问答系统”。

工程落地困难：很多同学在Jupyter Notebook里跑通模型推理后，就不知道下一步该怎么办了。如何提供一个稳定的HTTP API？如何管理对话历史？如何设计一个简单明了的前端界面？这些工程化问题往往比模型调参更让人头疼。

忽视推理成本与部署：在实验室用一张显卡跑得欢，但没考虑过如何部署到云服务器或让答辩老师现场访问。模型的显存占用、推理速度、并发支持，这些在生产环境中至关重要的问题，在毕设阶段常常被忽略。

缺乏安全与稳定性考虑：直接暴露模型接口，没有对用户输入做过滤，可能导致模型被“教坏”或输出不当内容。同时，没有基本的限流和错误处理，服务很容易被意外请求打垮。

2. 技术选型对比：找到适合你的“脚手架”

面对众多工具，怎么选？这里对比几个主流方案：

Hugging Face Transformers：生态最完善，模型加载和推理API简单易用，非常适合快速原型验证。但它的推理Pipeline通常不是为高性能并发设计的，自带的生成策略可能效率不高。

vLLM：专门为高效推理而生，采用了PagedAttention等优化技术，吞吐量非常高，尤其适合需要处理大量并发请求的场景。但它的配置相对复杂，对新手不够友好，且更侧重于纯推理服务。

Ollama：在Mac和Linux上部署和运行开源模型极其简单，一条命令就能启动一个模型服务，非常适合本地开发和体验。但它更像一个黑盒，自定义程度较低，对于想深入理解后端流程的毕设来说，可能过于“省事”了。

我们的选择：对于毕业设计，我推荐Transformers + FastAPI的组合。Transformers用来加载和运行模型，FastAPI用来构建稳健的Web后端。这个组合平衡了灵活性、易学性和可控性，能让你清晰地掌握从模型加载到API响应的每一个环节，这对于答辩时讲清技术架构非常有利。

3. 核心实现：三步搭建端到端应用

我们的目标是构建一个具备API、前端和基础安全控制的完整应用。下面分三步走：

第一步：使用FastAPI封装本地LLM

核心是为模型创建一个Web服务接口。我们使用FastAPI因为它异步性能好、自动生成API文档。

1. 环境准备：创建虚拟环境，安装transformers,torch,fastapi,uvicorn等包。
2. 模型加载与推理函数：编写一个函数，负责加载指定模型（如Qwen/Qwen-7B-Chat），并实现文本生成逻辑。这里要注意使用device_map=”auto”让Transformers自动分配GPU和CPU内存。
3. 创建FastAPI应用与路由：定义一个/chat的POST接口，接收用户消息，调用上面的推理函数，并返回模型生成的回复。

第二步：集成LangChain处理上下文

直接调用模型，每次对话都是独立的，没有记忆。为了实现多轮对话，我们需要管理上下文。LangChain的ConversationBufferMemory组件可以帮我们轻松实现。

1. 引入LangChain：安装langchain和langchain-community。
2. 创建记忆体：为每个会话（可以用用户ID区分）创建一个ConversationBufferMemory对象，用于存储历史对话。
3. 改造推理流程：在调用模型前，将记忆体中的历史对话和当前问题拼接成一个完整的提示（Prompt），再送给模型。模型回复后，将当前的一问一答再保存到记忆体中。

第三步：通过Gradio构建简易前端

一个Web界面能让你的毕设演示效果提升好几个档次。Gradio可以让你用很少的代码快速构建一个交互式Web UI。

1. 安装与集成：安装gradio库。你可以在FastAPI应用中直接挂载一个Gradio界面，也可以单独为前端启动一个服务。
2. 设计界面：通常需要一个聊天输入框、一个提交按钮和一个展示对话历史的区域。
3. 连接后端：将Gradio界面的提交动作绑定到我们之前写好的FastAPI/chat接口上。

这样，一个拥有记忆功能、带Web界面的聊天应用原型就搭建起来了。

4. 代码示例：一个清晰的实现

下面是一个高度精简但结构完整的核心代码示例，遵循了Clean Code原则，关键部分都有注释。

# app.py from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel from typing import List, Optional import uvicorn from transformers import AutoTokenizer, AutoModelForCausalLM import torch from langchain.memory import ConversationBufferMemory from langchain.schema import HumanMessage, AIMessage import hashlib app = FastAPI(title="LLM毕设演示API") # 1. 定义请求/响应数据结构 class ChatRequest(BaseModel): message: str session_id: Optional[str] = None # 用于区分不同对话会话 class ChatResponse(BaseModel): reply: str session_id: str # 2. 全局模型与工具加载 (简单起见，使用全局变量，生产环境需优化) print("正在加载模型和分词器...") model_name = "Qwen/Qwen-7B-Chat-Int4" # 使用量化版本，显存占用更小 tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, device_map="auto", trust_remote_code=True ) print("模型加载完毕！") # 用于存储不同会话的记忆体 session_memories = {} def get_memory(session_id: str) -> ConversationBufferMemory: """获取或创建某个会话的记忆体""" if session_id not in session_memories: session_memories[session_id] = ConversationBufferMemory() return session_memories[session_id] # 3. 核心聊天端点 @app.post("/chat", response_model=ChatResponse) async def chat_endpoint(request: ChatRequest): user_message = request.message.strip() if not user_message: raise HTTPException(status_code=400, detail="消息不能为空") # 生成或使用传入的session_id session_id = request.session_id or hashlib.md5(user_message.encode()).hexdigest()[:8] memory = get_memory(session_id) # 从记忆体中获取历史对话 history = memory.load_memory_variables({})['history'] # 构建LangChain消息格式 messages_for_llm = [] if history: # 这里简化处理，实际应根据历史记录构造 pass messages_for_llm.append(HumanMessage(content=user_message)) # 构建模型所需的Prompt (此处需根据具体模型调整) # 例如，Qwen-Chat模型通常需要格式：<|im_start|>user\n{用户消息}<|im_end|>\n<|im_start|>assistant\n prompt = tokenizer.apply_chat_template( [{"role": "user", "content": user_message}], tokenize=False, add_generation_prompt=True ) # 模型推理 model_inputs = tokenizer([prompt], return_tensors="pt").to(model.device) with torch.no_grad(): generated_ids = model.generate( **model_inputs, max_new_tokens=512, do_sample=True, temperature=0.8, top_p=0.9 ) reply = tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] # 清理回复，只提取助手部分 # 此处需要根据模型输出格式进行解析，以下为示例逻辑 assistant_reply = reply.split("<|im_start|>assistant\n")[-1].split("<|im_end|>")[0] # 将本轮对话保存到记忆体 memory.save_context({"input": user_message}, {"output": assistant_reply}) return ChatResponse(reply=assistant_reply, session_id=session_id) # 4. 启动Gradio前端 (可选，独立运行) # 这里展示在另一个文件中用Gradio调用上述API的方式 # frontend.py """ import gradio as gr import requests API_URL = "http://127.0.0.1:8000/chat" def predict(message, history, session_id): # history是Gradio的格式，我们主要用session_id来维持记忆 data = {"message": message, "session_id": session_id} try: response = requests.post(API_URL, json=data) if response.status_code == 200: return response.json()["reply"] else: return f"API错误: {response.text}" except Exception as e: return f"请求失败: {str(e)}" # 创建带会话状态的界面 with gr.Blocks() as demo: session = gr.State(value="default_session") # 会话状态 chatbot = gr.Chatbot() msg = gr.Textbox() clear = gr.Button("清空") def respond(message, chat_history, session_state): bot_message = predict(message, chat_history, session_state) chat_history.append((message, bot_message)) return "", chat_history, session_state msg.submit(respond, [msg, chatbot, session], [msg, chatbot, session]) clear.click(lambda: None, None, chatbot, queue=False) if __name__ == "__main__": demo.launch() """ if __name__ == "__main__": # 启动FastAPI后端 uvicorn.run(app, host="0.0.0.0", port=8000)

5. 性能与安全：让应用更健壮

一个能答辩的毕设，不能只满足于“跑通”，还要考虑以下方面：

性能方面：

• 冷启动延迟：首次加载模型可能很慢。可以在服务启动时预加载模型（就像上面代码做的），而不是在第一次请求时加载。
• 并发与竞争：上面的简单实现中，session_memories字典的并发访问可能有问题。生产环境需要使用线程锁（如threading.Lock）或更成熟的内存数据库（如Redis）来管理会话状态。
• 推理加速：可以考虑使用text-generation-inference(TGI)或vLLM作为后端推理引擎，通过FastAPI调用它们的接口，能获得更好的吞吐量。

安全方面：

• 输入过滤：必须对用户输入进行检查。过滤敏感词、检查输入长度（防止超长输入耗尽资源）、警惕提示词注入攻击（Prompt Injection）。可以写一个中间件（Middleware）或依赖项（Dependency）来实现。
• API限流：使用slowapi等库为/chat接口添加限流（如每分钟每个IP 10次请求），防止恶意刷接口。
• 输出审核：对模型的回复内容也可以进行基本的审核，避免生成有害内容。

6. 生产环境避坑指南

如果你想更进一步，把项目部署到云服务器上演示，这些坑要提前知道：

模型量化陷阱：为了降低显存占用，我们常使用量化模型（如Int4）。但要确认量化是否影响了模型的核心能力（比如代码生成、逻辑推理）。最好在测试集上对比一下量化前后的效果。

显存溢出处理：即使用了量化模型，在生成很长的文本时也可能OOM（内存溢出）。一定要在代码中设置max_new_tokens参数来限制生成长度，并在异常捕获中处理torch.cuda.OutOfMemoryError，给用户一个友好的错误提示，而不是让服务崩溃。

日志与监控缺失：这是学生项目最常忽略的。至少要实现请求日志（谁、什么时候、问了什么、回复了什么、花了多长时间），这不仅能帮你调试，也是答辩时体现工程素养的亮点。可以看看structlog或loguru库。

依赖与环境固化：务必使用requirements.txt或environment.yml文件精确记录所有依赖的版本，避免“在我电脑上能跑”的尴尬。考虑使用Docker容器化部署，这是目前最可靠的方式。

成本控制：如果使用云服务器，选择按量计费的GPU实例。演示完毕后及时关机或释放实例，避免产生高额费用。

写在最后

回顾整个流程，从具体的选题切入，到选择Transformers+FastAPI的技术栈，再到一步步实现后端、集成记忆、搭建前端，最后考虑性能、安全和部署，我们其实完成了一个微型的AI产品闭环。做毕设，尤其是基于LLM的毕设，最重要的可能不是用了多前沿的模型，而是如何将你的学术创新点（比如一种新的提示方法、一个特定的微调策略）与工程可行性完美结合，做出一个完整、健壮、可演示的系统。

我强烈建议你按照这个框架，动手复现一遍，把每个环节都吃透。然后，尝试加入你自己的创新点，比如接入一个特定的知识库，或者实现一个有趣的Agent功能。完成之后，别忘了把它放到GitHub上，一个内容丰富的README和清晰的项目结构，会是你简历上非常出彩的一笔。

技术之路，动手远比空想来得实在。希望这篇笔记能为你点亮一盏灯，祝你毕设顺利！