这次我们直接把 LLM 全栈开发链路拉通模型选型、本地部署、参数微调、推理服务、Prompt 优化每一步都给出可落地的操作方案。核心围绕三件事展开用 vLLM 做高吞吐推理服务用 Unsloth 做 LoRA 微调再配合 Qwen3 模型和一套 Prompt 工程方法。如果你正准备在本地或公司服务器上跑起自己的大模型应用这篇文章可以直接照做。开始之前先把结论放在前面这套链路并不复杂但每一步都卡环境。Qwen3 负责提供模型能力Unsloth 负责把模型改成你想要的样子vLLM 负责把模型跑成高并发接口服务Prompt 工程负责让模型输出真正可用。四者串起来就是一套完整的 LLM 应用开发流程。本文将带读者完成以下内容梳理完整技术栈搞清 vLLM、Unsloth、Qwen3、Prompt 工程各自解决什么问题检查本地部署所需环境给出可复制的命令用 Ollama 快速跑通 Qwen3先验证模型效果用 Unsloth 对 Qwen3 做 LoRA 微调让模型适配自己的数据用 vLLM 部署微调后的模型提供 OpenAI 兼容 API写 Prompt 工程测试用例把模型接入业务场景汇总高频问题覆盖显存不足、启动卡顿、双卡失效、API 报错等。如果你的目标是私有化部署、内部工具集成或者做一个专属客服机器人这篇文章建议收藏备用。1. 全栈技术栈vLLM、Unsloth、Qwen3、Prompt 工程的核心能力速览大模型应用开发不是单一工具能完成的。最稳妥的做法是用多个开源组件拼一条链路每个组件只做一件事。下面这张表把全栈里最关键的四个环节列了出来方便你判断自己卡在哪一环。环节工具 / 模型主要作用硬件门槛启动方式底座模型Qwen3 系列对话、推理、代码、Agent 能力按模型尺寸浮动8B 级适合单卡通过推理框架加载参数微调UnslothLoRA 微调定制模型行为和输出风格4bit 训练可显著降低显存需求pip 安装 / Desktop 工具推理服务vLLM高并发推理OpenAI 兼容 API取决于模型体积与并发量命令行 / Docker应用层Prompt 工程控制输出格式、角色、工具调用无需额外硬件代码编写 / 测试平台从这张表可以看出这四层是递进关系。Qwen3 是阿里巴巴开源的大语言模型系列覆盖从轻量级到大规模的多个尺寸也有面向代码生成的 Coder 系列和 MoE 架构版本。选择 Qwen3 做底座的原因很直接开源、中文能力强、生态完善可以配合 vLLM、Unsloth、Ollama、Llama-Factory 等主流工具链使用。Unsloth 是 LoRA 微调工具核心价值体现在速度和显存占用上。它通过优化反向传播和显存管理让消费级显卡也能跑微调任务。对于只有少量数据的场景LoRA 微调比全参微调现实得多这也是它在社区里流行起来的主要原因。vLLM 是高性能推理引擎核心卖点是 continuous batching连续批处理。普通推理框架一次只能处理一个请求vLLM 会把多个请求拼在一起动态调度GPU 利用率明显提升。它还提供 OpenAI 兼容的/v1接口这意味着你只要改一下 base_url就能把现有 OpenAI SDK 代码指向本地模型。Prompt 工程属于应用层不需要训练参数也不动模型权重只靠设计输入文本就能大幅改变输出质量。它和微调是两条互补路线能通过提示词解决的不要急着微调提示词解决不了的才需要准备数据去微调。一句话总结全栈链路先跑通 Qwen3再按需微调然后用 vLLM 部署上线最后用 Prompt 工程把模型“调教”成业务需要的样子。2. 适用场景与使用边界2.1 这套链路适合谁这套方案适合三类人有私有化部署需求的技术团队。数据不能出内网需要把模型跑在自己服务器上vLLM Qwen3 是目前比较成熟的组合。需要定制模型行为的研究和开发人员。通用模型输出不符合业务格式要求时用 Unsloth 做 LoRA 微调比全参微调成本低很多。正在学习大模型应用开发的个人开发者。从 Ollama 快速体验起步再到 Unsloth 微调和 vLLM 部署是一条完整的学习路径。2.2 不适合什么场景没有 GPU 且对实时性要求极高。纯 CPU 推理可以跑通但吞吐量低首字延迟高不适合高并发生产环境。硬件资源有限却要跑超大模型。如果只有 8G 显存硬上 70B 级别模型会非常吃力需要依赖量化、远端 API 或 MoE 版本体验会打折扣。对模型效果要求极高且几乎没有训练数据。微调需要足够质量的数据数据太少时效果不稳定这时优先考虑 Prompt 工程和 RAG。2.3 合规与使用边界部署开源模型和微调工具时有三个合规点必须确认模型开源协议。Qwen3 等开源模型有各自的许可协议商用前要确认是否合规。微调数据授权。用于训练的数据要确认有合法来源和授权尤其是涉及他人创作内容、个人信息时。未经授权使用受版权保护的对话数据、用户隐私数据做微调存在法律风险。接口服务访问边界。vLLM 启动的 API 服务默认监听端口部署到服务器时要用防火墙或反向代理限制访问范围避免内部模型被未授权调用。另外本文涵盖的模型部署、微调流程都应在自己拥有的测试环境和已授权数据集上进行不要拿这套链路去处理任何未授权的数据。3. 环境准备与前置条件3.1 硬件检查清单先看显卡。NVIDIA 显卡是主流选择因为 CUDA 生态最成熟。显存方面8B 级别模型 FP16 精度下权重接近 16GB所以 16GB 显存是“能跑”24GB 显存是“舒服”。如果没有大显存卡可以考虑 4bit 量化。CPU 和内存不要太差多核 CPU 和大内存能缓解数据预处理和并发加载的压力。实际负载很高时内存不足会导致进程被系统杀掉。磁盘空间要预留充足。一个 8B 模型文件通常在 4GB 到 16GB 之间加上微调输出、日志和依赖环境建议预留 50GB 以上。大模型下载会占用 Hugging Face 缓存目录注意磁盘分区。3.2 软件检查清单操作系统推荐 LinuxUbuntu 22.04 / 24.04 比较常见。vLLM 在 Linux 下支持最完善Windows 下可以用 WSL2 或 Docker Desktop 作为替代方案但会多一层配置复杂度。Python 环境建议使用 conda 或 venv 隔离避免和系统 Python 冲突。PyTorch 版本要和 CUDA 版本匹配这一点非常关键。很多微调失败都是 PyTorch 和 CUDA 不匹配导致的。在执行安装之前先确认当前环境是否满足条件。运行下面的命令检查# 检查显卡驱动和 CUDA 是否可用 nvidia-smi # 检查 Python 版本 python --version # 检查 conda 是否已安装 conda --version # 查看磁盘剩余空间 df -h ~如果nvidia-smi正常输出显卡信息说明驱动没问题。CUDA 版本看右上角的 “CUDA Version” 字段后续安装 PyTorch 时尽量选择匹配的版本。3.3 目录规划建议部署这类项目最忌讳把文件堆在桌面和根目录。建议按功能分目录~/llm-workspace ├── models # 模型权重文件 ├── data # 微调数据集 ├── scripts # 训练和启动脚本 ├── outputs # 微调输出 └── logs # 服务日志这样后续排查问题、清理磁盘和备份数据都方便得多。4. 最快跑通Ollama 本地部署 Qwen3先别急着上 vLLM第一步先用 Ollama 把 Qwen3 跑起来验证模型本身效果。Ollama 的优势是安装简单支持 CPU 和 GPU一条命令就能下载模型并启动交互式对话。它适合做原型验证但不适合高并发生产场景因为对批处理调度和细粒度参数控制不如 vLLM。4.1 Ollama 安装Ollama 官方提供 Linux、macOS、Windows 客户端。在 Linux 环境下安装命令如下curl -fsSL https://ollama.com/install.sh | sh安装完成后先确认服务状态ollama --version ollama list如果ollama list能正常显示说明守护进程已经启动。4.2 拉取并运行 Qwen3Ollama 支持通过模型标签拉取 Qwen3。以 8B 模型为例# 拉取模型并进入交互对话 ollama run qwen3:8b首次执行会先下载模型文件具体大小以实际拉取版本为准。进入交互界面后直接输入中文问题测试 用三句话介绍大语言模型微调的基本流程模型返回结果后可以继续测试代码生成、数学推理、角色扮演等场景。这一步的目的是验证模型本身有没有问题如果模型回复质量太差后面微调和部署也就没有意义。4.3 Ollama 与后续工具链的关系Ollama 跑通后你会对 Qwen3 的能力有一个直观感受。接下来的两条路是对模型效果不满意进入第五章用 Unsloth 微调需要对模型做高并发服务进入第六章用 vLLM 部署。Ollama 也可以单独作为本地服务使用它同样提供 OpenAI 兼容接口适合个人开发和小流量场景。但生产环境的并发控制、量化策略和监控能力vLLM 更成熟。5. Unsloth 微调 Qwen3LoRA 训练全流程微调是整个链路里最容易出错的一环。多数人的误区是一上来就全参微调结果显存爆炸、训练极慢。更现实的做法是用 Unsloth 做 LoRA 微调只训练一小部分参数显存占用低很多少数据也能跑。5.1 什么情况下需要微调模型输出的格式不符合业务要求比如客服系统需要固定 JSON 结构模型不了解你的专业术语和内部知识模型回答的语气、风格和产品定位不一致用 Prompt 工程反复调整仍然不满足需求。如果只是偶尔输出不稳定优先调 Prompt如果模型行为系统性偏了再考虑微调。5.2 安装 UnslothUnsloth 依赖 PyTorch 和特定版本的 CUDA 环境。建议先建一个独立 conda 环境conda create -n unsloth-env python3.10 -y conda activate unsloth-env然后安装 PyTorch。PyTorch 安装命令要根据你的 CUDA 版本从官网选择这里给出通用示例# 根据实际 CUDA 版本调整命令具体以 PyTorch 官网为准 pip install torch安装完成后再安装 Unslothpip install unsloth如果安装速度慢使用国内镜像源pip install unsloth -i https://pypi.tuna.tsinghua.edu.cn/simple5.3 准备微调数据指令微调的数据格式通常是 JSONL一行一个样本。对话模板可以这样组织{instruction: 你是售后客服请根据用户问题给出简洁回答, input: 我的订单三天了还没发货怎么回事, output: 您好请您提供订单号我帮您查询物流状态。}也可以使用更通用的对话格式{messages: [{role: user, content: 我的订单三天了还没发货怎么回事}, {role: assistant, content: 您好请您提供订单号我帮您查询物流状态。}]}数据量方面LoRA 微调不需要海量数据。几百到几千条高质量样本就可以看出效果提升。数据质量远比数量重要宁可少而精不要多而乱。5.4 编写 LoRA 微调脚本下面是一个基于 Unsloth 的标准微调脚本参数需要按实际任务调整from unsloth import FastLanguageModel from datasets import load_dataset from trl import SFTTrainer from transformers import TrainingArguments # 1. 加载模型4bit 量化降低显存需求 model, tokenizer FastLanguageModel.from_pretrained( model_nameQwen/Qwen3-8B, max_seq_length2048, load_in_4bitTrue, # 4bit 量化 ) # 2. 配置 LoRA 参数 model FastLanguageModel.get_peft_model( model, r16, # LoRA 秩越大表达能力越强但显存占用越高 target_modules[q_proj, k_proj, v_proj, o_proj], lora_alpha16, lora_dropout0, biasnone, use_gradient_checkpointingTrue, ) # 3. 加载训练数据 dataset load_dataset(json, data_files./data/train.jsonl, splittrain) # 4. 配置训练参数 trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasetdataset, argsTrainingArguments( output_dir./outputs/qwen3-lora, per_device_train_batch_size1, gradient_accumulation_steps4, learning_rate2e-4, num_train_epochs1, logging_steps10, save_steps100, save_total_limit2, ), ) # 5. 开始训练 trainer.train() # 6. 保存 LoRA 权重 model.save_pretrained(./outputs/qwen3-lora-final) tokenizer.save_pretrained(./outputs/qwen3-lora-final)跑这个脚本时重点观察两点一是显存占用nvidia-smi实时查看二是 loss 是否稳定下降。如果 loss 一直不降可能是学习率设置不合理或数据质量有问题。5.5 合并模型并导出训练完成后得到的是 LoRA 权重体积很小但还需要和基础模型合并才能部署到 vLLM。合并方式如下from unsloth import FastLanguageModel model, tokenizer FastLanguageModel.from_pretrained( model_nameQwen/Qwen3-8B, load_in_4bitTrue, ) model FastLanguageModel.from_pretrained( model_name./outputs/qwen3-lora-final, )[0] # 合并 LoRA 权重 model model.merge_and_unload() # 保存为完整模型权重 model.save_pretrained(./outputs/qwen3-sft-full) tokenizer.save_pretrained(./outputs/qwen3-sft-full)合并后的模型可以继续用 vLLM 或 Ollama 加载。如果你还想把微调后的模型转换为 GGUF 格式在 Ollama 里跑Unsloth 也提供了相关转换方法导出后放到 Ollama 模型目录即可。5.6 少数据量微调的建议很多人在问“数据很少怎么微调”。根据实际项目经验优先遵循这几条原则先用 50 到 100 条样本做小实验验证流程不要一上来就跑全量把数据清洗干净格式统一、无噪声、无重复比增加数量更重要设置更小的学习率比如 2e-4 以下防止过拟合开启 4bit 量化降低显存门槛让单卡也能跑训练后对比评估保留一份未微调的模型做 A/B 测试确认微调真的有效。6. vLLM 部署从命令行到生产环境微调完成后进入推理服务环节。vLLM 是当前流行的高性能推理框架重点解决两个问题高并发下的吞吐量以及 OpenAI API 兼容性。如果你需要把模型接入公司系统vLLM 是很稳的选择。6.1 vLLM 安装和启动方式vLLM 支持 pip 安装和 Docker 部署两种方式。pip 安装适合本地实验pip install vllm启动服务前先确认模型路径或 Hugging Face 模型名。下面以微调合并后的模型为例启动一个 OpenAI 兼容接口vllm serve ./outputs/qwen3-sft-full \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1参数说明如下--host和--port服务监听地址和端口--max-model-len最大上下文长度越长越耗显存--gpu-memory-utilization允许 vLLM 使用的显存比例0.9 表示最多占用 90%--tensor-parallel-size使用几张 GPU 做张量并行。启动后日志会显示服务地址和模型信息。默认服务地址是http://127.0.0.1:8000。6.2 Docker 部署方式很多人问“vLLM 必须用 Docker 吗”。不是。pip 安装完全够用。Docker 的价值在于隔离 CUDA 和 Python 环境方便在生产服务器上快速复现环境。使用 Docker 部署时官方镜像的启动方式类似docker run --rm --gpus all \ -p 8000:8000 \ -v ~/models:/models \ vllm/vllm-openai \ --model /models/qwen3-sft-full \ --host 0.0.0.0 \ --port 8000注意镜像标签和启动命令会随着 vLLM 版本变化需要以实际版本为准。-v参数是把宿主机模型目录挂载进容器确保容器内能读取模型文件。6.3 OpenAI 兼容 API 调用测试vLLM 启动后可以用 curl 快速验证接口curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: ./outputs/qwen3-sft-full, messages: [{role: user, content: 你好请简单介绍一下自己}] }如果返回 JSON 中包含choices字段说明接口正常。Python 调用时直接用 OpenAI SDKfrom openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( model./outputs/qwen3-sft-full, messages[ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 用三句话解释 vLLM 的 continuous batching}, ], temperature0.7, max_tokens512, ) print(resp.choices[0].message.content)当你把base_url指向本地 vLLM 服务后现有 OpenAI SDK 代码不需要大规模改动这大大降低了接入成本。6.4 批量任务和并发配置vLLM 天然支持并发请求不需要额外写队列。它内部会自动做 continuous batching把多个请求动态聚合到 GPU 上。如果你想压测服务能力可以用 Python 并发发送请求import concurrent.futures import requests url http://127.0.0.1:8000/v1/chat/completions def send_one(prompt): payload { model: ./outputs/qwen3-sft-full, messages: [{role: user, content: prompt}], max_tokens: 64, } resp requests.post(url, jsonpayload, timeout30) return resp.status_code prompts [f第 {i} 个测试请求 for i in range(50)] with concurrent.futures.ThreadPoolExecutor(max_workers10) as executor: results list(executor.map(send_one, prompts)) print(f成功请求数: {results.count(200)})批量任务的关键点是控制并发数观察延迟和显存。如果并发过高vLLM 会排队等待而不是立刻失败但响应时间会上升。更稳妥的做法是搭配消息队列和失败重试机制把请求先写入队列再由消费者分批调用 vLLM 接口。6.5 vLLM 部署的常见性能问题从实际使用反馈看vLLM 部署最容易遇到的问题是“慢”和“卡”。常见原因包括模型加载耗时从磁盘读入几十 GB 模型文件需要时间首字延迟不完全代表推理性能显存不足导致交换显存不够时部分数据被换到内存性能断崖式下降上下文长度过长max-model-len设置过大KV Cache 占用过多显存GPU 带宽瓶颈加载全量模型权重时GPU 显存带宽决定了 token 生成速度并发过高超过 GPU 处理能力后请求排队时间变长。排查思路是先降低并发观察单请求延迟再缩小max-model-len观察显存占用和首字延迟最后通过nvidia-smi确认 GPU 利用率和显存情况。7. Prompt 工程让模型输出真正可用模型部署完成后最后一层是 Prompt 工程。很多人在问“AI 客服属于 Prompt 工程、RAG、还是微调”答案是大概率是多者组合。简单场景 Prompt 工程就能解决知识密集型场景需要 RAG 检索增强行为风格系统性偏差才需要微调。7.1 Prompt、RAG、微调的选择边界需求类型推荐方案原因输出格式、语气、角色设定Prompt 工程成本最低调整最快需要引入最新或私有知识RAG 检索增强不用重新训练实时更新知识库模型在特定任务上行为系统性偏差LoRA 微调通过数据修正模型行为复杂场景三者组合各取所长效果最稳7.2 一个可落地的 Prompt 模板构建 Prompt 时固定的结构能显著提高输出稳定性。下面是一个客服场景的示例你是某电商平台的售后客服你的回答必须满足以下要求 1. 语气亲切、简洁不超过 100 字 2. 先安抚用户情绪再给出解决步骤 3. 如果用户询问物流需要引导用户提供订单号 4. 不知道的信息不要编造统一回复“请稍等我为您查询”。 用户问题 {用户输入}这个 Prompt 同时约束了角色、语气、长度、处理流程和不编造原则。实际使用时把{用户输入}替换为真实用户消息即可。7.3 Tool Calling 与 Agent 场景你可能会遇到需要让模型调用外部工具的场景比如查天气、查数据库。Qwen3 支持工具调用vLLM 也提供相应的 tool-call-parser 机制但不同工具链的配置方式有差异。如果是在推理服务层面接入外部工具需要先确认两件事一是模型本身是否训练过工具调用能力二是推理框架是否配置了对应的解析器。vLLM 新版本支持多种工具解析器但具体参数名和格式要以官方文档为准。7.4 Prompt 测试流程Prompt 优化不是一次完成的。建议按以下流程迭代准备 20 到 50 条代表性测试问题覆盖正常、极端、歧义场景写一版 Prompt跑一遍测试集记录失败案例分析失败原因修改 Prompt 中的约束条件重复测试直到通过率达到预期。要注意Prompt 对输出的影响很大但并不能解决所有问题。如果模型格式错乱、事实错误频繁可能需要结合 RAG 或微调而不是无限调 Prompt。8. 资源占用与性能观察方法8.1 如何观察显存占用显存占用是本地部署的核心监控指标。推荐两个工具# 实时查看 GPU 显存和利用率 watch -n 1 nvidia-smi # 按进程查看显存占用 nvidia-smi --query-compute-appspid,used_memory,process_name --formatcsv启动 vLLM 服务时--gpu-memory-utilization可以控制显存占用上限。建议留出 1GB 到 2GB 显存给系统和数据加载避免显存被打满导致进程崩溃。8.2 推理参数对性能的影响几个关键参数和性能的关系上下文长度max-model-len越长KV Cache 占用越多显存压力越大并发请求数并发越高GPU 利用率越高但单个请求延迟会增加量化精度FP8、AWQ、GPTQ 等量化方式可以降低模型文件体积减少显存占用但推理质量可能有轻微下降GPU 数量tensor-parallel-size大于 1 时模型会切分到多张 GPU适合单卡放不下的大模型。8.3 首字延迟与吞吐首字延迟反映模型看到问题后生成第一个 token 的速度吞吐反映单位时间生成的 token 数。这两个指标可以这样理解首字延迟受模型加载、计算图和 GPU 影响优化空间有限吞吐受 continuous batching 影响并发越高整体吞吐越高但对单个请求来说响应会变慢。如果你发现 vLLM 服务“经常慢、卡顿”先看显存是不是已经达到上限再看并发和 KV Cache 设置最后看模型文件是否放在机械硬盘上。模型文件放在 SSD 上能明显减少模型加载时间。9. 常见问题与排查方法下面这张表整理了本地部署 Qwen3 全栈链路中最常见的问题基本覆盖了部署、微调、推理三个阶段。问题现象可能原因排查方式解决方案pip 安装 unsloth / vllm 失败Python、PyTorch、CUDA 版本不匹配查看 pip 错误日志确认 CUDA 版本用 conda 创建干净环境按官方要求装 PyTorch显存不足进程被杀死模型过大、上下文过长或并发过高nvidia-smi查看显存占用降低max-model-len开启 4bit 量化减少并发数vLLM 启动后接口报 404请求路径错误或模型名错误检查访问地址和路径使用/v1/chat/completionsmodel 参数填实际模型路径微调后 loss 不降学习率过高、数据噪声大、prompt 模板不一致查看训练日志 loss调低学习率清洗数据统一指令格式双卡启动失败tensor-parallel-size 与 GPU 数量不匹配或驱动问题查看启动日志确认多卡可见检查nvidia-smi设置--tensor-parallel-size为实际卡数首字延迟高模型加载慢、GPU 带宽不足、并发过多测试单请求延迟模型放 SSD降低并发合理设置显存利用率API 返回空内容或报错上下文超限、模型未加载完整、请求参数错误检查服务日志和返回详情缩短max_tokens和max-model-len确认请求格式老显卡如 2080 Ti支持不好CUDA 版本过旧vLLM 新版本要求较高查看 GPU 计算能力和驱动升级驱动选择兼容的 vLLM 版本或用 Docker 隔离环境服务端口被占用之前的进程没有释放端口lsof -i :8000查看占用换端口或杀旧进程检查是否有残留 vLLM 进程本地模型无法联网vLLM 默认离线推理查询日志如果要联网搜索需要额外搭建 RAG 服务或调用搜索引擎 API这些排错顺序很好记先看日志再看显存最后看参数配置。不要一上来就重装环境多数问题都是参数不匹配。10. 最佳实践与工程化建议10.1 流程建议先小参数验证微调和部署时先用小模型、短上下文、小 batch 跑通流程再逐步放大避免一次浪费几个小时的训练时间保留一套最小可运行配置环境一旦跑通把requirements.txt、启动命令、环境变量记录在项目 README 里方便换机器复现版本锁定PyTorch、vLLM、Unsloth 的版本一旦确定能跑后续升级要谨慎先在测试环境验证目录分离模型文件、输入数据、输出结果、日志分别存目录方便备份和清理。10.2 接口和批量任务建议接口服务要限制访问范围不要直接暴露到公网建议放在内网或加一层鉴权批量任务要加日志和失败重试vLLM 本身不会重试需要调用方实现如果要做大批量离线推理建议把请求写入队列控制并发避免把服务打挂。10.3 合规底线微调数据集必须有合法来源涉及用户信息要脱敏并取得授权涉及人脸、声音、肖像或版权素材时务必确认授权链条完整商用前评估模型效果和输出内容建立人工复核机制防止模型输出有害或不实信息。10.4 最容易踩的坑回顾整条链路最容易出问题的有三个位置环境安装阶段PyTorch 和 CUDA 版本不匹配导致 Unsloth 或 vLLM 安装失败。解决方法是先创建独立 conda 环境按官方文档选择 PyTorch 安装命令微调数据阶段格式不一致、噪声多导致训练不稳。解决方法是把数据清洗和格式校验脚本化部署阶段并发和显存配置不合理导致服务卡顿。解决方法是先压测再根据 GPU 和模型大小调整参数。11. 总结与下一步这套全栈链路其实就四步用 Qwen3 做底座用 Ollama 快速验证用 Unsloth 按需微调用 vLLM 部署上线。每走一步你都会对模型能力、训练资源、推理性能有更具体的感知。建议拿到项目后先跑通 Ollama Qwen3再准备少量数据做一次 LoRA 微调最后用 vLLM 把微调模型发布成 API。这样每一步都有明确的验证标准不会卡在一个环节里出不来。最容易踩的坑集中在环境依赖和数据质量上。版本不匹配就重建环境数据不干净就先清洗这两点解决后整套流程会顺畅很多。下一步可以继续扩展的方向很多接入 RAG 检索增强让模型回答基于企业知识库引入更多评测集量化微调前后的效果差异或者把 vLLM 服务接入监控体系观察延迟、吞吐和显存趋势。按“先跑通、再优化、后扩展”的节奏推进这套技术栈能支撑起不少实际业务需求。建议收藏备用跑的时候直接对照检查。