LLM全栈实战：Qwen3微调与vLLM部署指南

这次我们直接把 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 是阿里巴巴开源的大语言模型系列，覆盖从轻量级到大规模的多个尺寸，也有面向代码生成的 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 软件检查清单

操作系统推荐 Linux，Ubuntu 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 拉取并运行 Qwen3

Ollama 支持通过模型标签拉取 Qwen3。以 8B 模型为例：

# 拉取模型并进入交互对话 ollama run qwen3:8b

首次执行会先下载模型文件，具体大小以实际拉取版本为准。进入交互界面后，直接输入中文问题测试：

>>> 用三句话介绍大语言模型微调的基本流程

模型返回结果后，可以继续测试代码生成、数学推理、角色扮演等场景。这一步的目的是验证模型本身有没有问题，如果模型回复质量太差，后面微调和部署也就没有意义。

4.3 Ollama 与后续工具链的关系

Ollama 跑通后，你会对 Qwen3 的能力有一个直观感受。接下来的两条路是：

• 对模型效果不满意，进入第五章，用 Unsloth 微调；
• 需要对模型做高并发服务，进入第六章，用 vLLM 部署。

Ollama 也可以单独作为本地服务使用，它同样提供 OpenAI 兼容接口，适合个人开发和小流量场景。但生产环境的并发控制、量化策略和监控能力，vLLM 更成熟。

5. Unsloth 微调 Qwen3：LoRA 训练全流程

微调是整个链路里最容易出错的一环。多数人的误区是一上来就全参微调，结果显存爆炸、训练极慢。更现实的做法是用 Unsloth 做 LoRA 微调，只训练一小部分参数，显存占用低很多，少数据也能跑。

5.1 什么情况下需要微调

• 模型输出的格式不符合业务要求，比如客服系统需要固定 JSON 结构；
• 模型不了解你的专业术语和内部知识；
• 模型回答的语气、风格和产品定位不一致；
• 用 Prompt 工程反复调整仍然不满足需求。

如果只是偶尔输出不稳定，优先调 Prompt；如果模型行为系统性偏了，再考虑微调。

5.2 安装 Unsloth

Unsloth 依赖 PyTorch 和特定版本的 CUDA 环境。建议先建一个独立 conda 环境：

conda create -n unsloth-env python=3.10 -y conda activate unsloth-env

然后安装 PyTorch。PyTorch 安装命令要根据你的 CUDA 版本从官网选择，这里给出通用示例：

# 根据实际 CUDA 版本调整命令，具体以 PyTorch 官网为准 pip install torch

安装完成后，再安装 Unsloth：

pip install unsloth

如果安装速度慢，使用国内镜像源：

pip install unsloth -i https://pypi.tuna.tsinghua.edu.cn/simple

5.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_name="Qwen/Qwen3-8B", max_seq_length=2048, load_in_4bit=True, # 4bit 量化 ) # 2. 配置 LoRA 参数 model = FastLanguageModel.get_peft_model( model, r=16, # LoRA 秩，越大表达能力越强，但显存占用越高 target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_alpha=16, lora_dropout=0, bias="none", use_gradient_checkpointing=True, ) # 3. 加载训练数据 dataset = load_dataset("json", data_files="./data/train.jsonl", split="train") # 4. 配置训练参数 trainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, args=TrainingArguments( output_dir="./outputs/qwen3-lora", per_device_train_batch_size=1, gradient_accumulation_steps=4, learning_rate=2e-4, num_train_epochs=1, logging_steps=10, save_steps=100, save_total_limit=2, ), ) # 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_name="Qwen/Qwen3-8B", load_in_4bit=True, ) 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 SDK：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY", ) resp = client.chat.completions.create( model="./outputs/qwen3-sft-full", messages=[ {"role": "system", "content": "你是一个严谨的技术助手。"}, {"role": "user", "content": "用三句话解释 vLLM 的 continuous batching"}, ], temperature=0.7, max_tokens=512, ) 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, json=payload, timeout=30) return resp.status_code prompts = [f"第 {i} 个测试请求" for i in range(50)] with concurrent.futures.ThreadPoolExecutor(max_workers=10) 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、微调的选择边界

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 优化不是一次完成的。建议按以下流程迭代：

1. 准备 20 到 50 条代表性测试问题，覆盖正常、极端、歧义场景；
2. 写一版 Prompt，跑一遍测试集，记录失败案例；
3. 分析失败原因，修改 Prompt 中的约束条件；
4. 重复测试，直到通过率达到预期。

要注意：Prompt 对输出的影响很大，但并不能解决所有问题。如果模型格式错乱、事实错误频繁，可能需要结合 RAG 或微调，而不是无限调 Prompt。

8. 资源占用与性能观察方法

8.1 如何观察显存占用

显存占用是本地部署的核心监控指标。推荐两个工具：

# 实时查看 GPU 显存和利用率 watch -n 1 nvidia-smi # 按进程查看显存占用 nvidia-smi --query-compute-apps=pid,used_memory,process_name --format=csv

启动 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 全栈链路中最常见的问题，基本覆盖了部署、微调、推理三个阶段。

这些排错顺序很好记：先看日志，再看显存，最后看参数配置。不要一上来就重装环境，多数问题都是参数不匹配。

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 服务接入监控体系，观察延迟、吞吐和显存趋势。按“先跑通、再优化、后扩展”的节奏推进，这套技术栈能支撑起不少实际业务需求。建议收藏备用，跑的时候直接对照检查。