企业官网建设流程全解析

1. 项目概述：为什么“会聊天”不等于“能干活”？

DeepSeek 实操一本通——这个标题里藏着一个被太多人忽略的真相：大模型能力的断层，不是技术不够强，而是使用方式没跟上。我从2023年第一批接触 DeepSeek-V2 开始，就发现一个现象：团队里90%的人用它写周报、润色邮件、生成PPT大纲，但真正让模型去读PDF合同、比对Excel数据差异、自动填充ERP系统字段、解析OCR扫描件并结构化入库的，不到5%。问题出在哪？不是模型不行，是大家卡在了“对话界面”这道窄门里，误把Chat UI当成了全部能力入口。DeepSeek-R1、DeepSeek-V2、DeepSeek-Coder 系列模型，本质上是一套可调度的推理引擎，而 Chat UI 只是它最表层的一个交互壳子。真正的“能干活”，意味着你得把它当成一个可编程的函数调用服务，而不是一个需要你不断喂提示词的AI客服。

这本“实操一本通”的核心，就是帮你把 DeepSeek 从“对话伙伴”升级为“数字员工”。它不讲大道理，不堆参数公式，只聚焦三件事：第一，怎么绕过网页界面，用 API 直接调用官方或本地部署的 DeepSeek 模型；第二，怎么让模型不只是“回答问题”，而是“执行任务”——比如自动拆解用户提问里的多步骤意图、调用外部工具、校验输出格式、重试失败环节；第三，怎么给模型装上“记忆”和“知识库”，让它在处理你公司的销售合同、产品手册、内部SOP时，不再胡编乱造，而是精准引用原文段落。热搜词里反复出现的 RAG、本地模型、API、deepseek hermes、llm-deepseek: no api key for provider route "deepseek-official"，其实都是这个升级过程中的具体路标。比如那个报错，根本不是密钥问题，而是你用错了调用路径——官方 API 走的是https://api.deepseek.com/v1/chat/completions，而本地部署的 Ollama 或 vLLM 服务走的是http://localhost:11434/api/chat，两者协议、参数、鉴权方式完全不同。搞不清这点，再好的提示词也白搭。这本书的读者，不需要是算法工程师，但得是愿意动手改几行 Python、能看懂 curl 命令、知道 JSON 是什么的业务骨干、产品经理、数据分析师或IT支持人员。你不需要从零训练模型，但必须学会指挥模型——这才是当前阶段最值钱的能力。

2. 核心思路拆解：从“单次问答”到“任务流编排”的范式转移

2.1 为什么传统 Prompt 工程无法支撑真实业务？

很多人以为，只要把提示词写得足够详细，“请严格按以下格式输出JSON，字段包括……”，模型就能稳定交付结构化结果。我试过，在测试集上准确率95%，一放到生产环境，面对用户随手拍的模糊发票照片、带表格线的Word合同、混着中英文的ERP日志，准确率直接掉到40%。原因很简单：Prompt 工程本质是“单次输入-单次输出”的静态映射，而真实业务是动态的、有状态的、容错要求极高的。举个例子：用户上传一份《2024年Q2供应商评估报告》，要求提取“所有被评供应商名称、最终得分、是否通过”。一个纯 Prompt 方案会怎么做？你写：“请阅读以下文本，提取所有供应商名称、得分和是否通过状态，以JSON数组格式返回。”模型可能漏掉表格最后一行，可能把“得分：85分”识别成“85”，也可能把“未通过”误判为“不通过”。这不是模型能力问题，是任务设计缺陷——它没给模型留出“校验”和“重试”的空间。

真正的“能干活”，必须引入任务流（Workflow）思维。我把整个流程拆成四个原子环节：理解 → 拆解 → 执行 → 校验。理解环节，模型先判断文档类型（PDF/Word/图片）、结构特征（是否有表格、页眉页脚）；拆解环节，不是一股脑扔全文，而是按逻辑块切分，比如合同先切“甲方信息”、“乙方信息”、“付款条款”、“违约责任”；执行环节，每个子块调用专用提示词模板，比如“付款条款”块用金融术语校验器，“违约责任”块用法律条文匹配器；校验环节，用正则表达式或简单规则检查输出JSON字段完整性，缺失则触发重试，错误率高则降级为人工审核队列。这个流程，靠单次 Prompt 绝对做不到，必须靠代码编排。我用 Python 的langgraph库实现过一个简易版本，核心逻辑只有20行代码，但稳定性比纯 Prompt 高出3倍。关键不在于用了什么框架，而在于你是否接受了“模型不是万能答案机，而是可调度的计算单元”这个前提。

2.2 RAG 不是“加个知识库”就完事，而是构建可信信息管道

RAG（检索增强生成）现在被吹得太神，好像加个向量库就能解决一切幻觉问题。我见过太多团队花两周时间搭好 ChromaDB，导入1000份PDF，结果用户问“我们上季度华东区销售额是多少”，模型还是瞎编。问题出在三个被忽视的环节：检索质量、上下文压缩、引用溯源。首先，检索质量。很多团队直接用默认的all-MiniLM-L6-v2做嵌入，但它对中文长尾专业术语（比如“非对称加密密钥协商协议”）表征能力很弱。我实测过，换成bge-zh-v1.5，在金融合同关键词召回率上提升47%。其次，上下文压缩。DeepSeek-R1 最大上下文128K，但你真把100页PDF全塞进去？模型注意力会严重稀释。我的做法是：先用 LlamaIndex 的SentenceSplitter按语义切块，每块不超过512 token，再用AutoMergingRetriever动态合并相关块，确保送入模型的永远是“最相关+最精炼”的3-5个片段。最后，引用溯源。用户凭什么信你？必须让模型在回答末尾标注[来源：XX合同第3.2条]。这需要在 RAG 流程里强制注入元数据，并在提示词里明确约束：“所有事实性陈述必须附带来源标注，格式为[来源：文件名_页码_段落号]，无来源不得输出”。

提示：RAG 瓶颈从来不在向量库本身，而在“检索-重排序-生成”三步之间的信息衰减。别迷信“端到端RAG框架”，先手动跑通这三步的最小闭环，再考虑自动化。

2.3 本地模型不是“为了本地而本地”，而是掌控力与成本的再平衡

热搜词里“本地向量模型”、“加载本地模型”、“可供本地免费使用的ai模型”高频出现，背后是企业对数据主权和长期成本的焦虑。但本地部署不是简单的“下载模型+启动服务”。我做过对比：用 DeepSeek-Coder-33B 在 A100 上跑代码补全，API 调用平均延迟1.2秒，本地 vLLM 部署后降到0.35秒，但显存占用飙升到48GB，单卡只能跑1个实例。而用量化后的deepseek-coder-33b-instruct-GGUF在消费级4090上，延迟0.8秒，显存仅16GB，能并发3个实例。所以“本地”的价值，不在于物理位置，而在于可控的性能-成本曲线。你得根据任务类型选模型：轻量级任务（如日志分类、邮件摘要）用deepseek-r1-1.5b量化版，重载任务（如代码生成、合同审查）用deepseek-coder-33b的 AWQ 量化版。工具链也得适配：Ollama 适合快速验证，vLLM 适合高并发API服务，LMStudio 适合桌面端调试。关键点在于，本地模型必须和你的业务监控体系打通——记录每次调用的输入token数、输出token数、实际耗时、GPU显存占用，否则你永远不知道省了多少钱，还是花了更多电费。

3. 核心细节解析：API 调用、RAG 构建与本地模型加载的实操要点

3.1 DeepSeek 官方 API 调用：绕过“no api key”陷阱的完整路径

那个反复出现的报错llm-deepseek: no api key for provider route "deepseek-official"，90%的情况根本不是密钥问题，而是调用路径和参数配置错误。我来还原一次标准调用的完整链路。首先，确认你已注册 DeepSeek 官方账号并获取 API Key，Key 位于控制台的 “API Keys” 页面，格式为sk-xxx。注意：这个 Key不能直接用于前端 JavaScript 调用，必须通过后端代理，否则会暴露密钥。后端调用的核心是curl命令或 Pythonrequests库，目标 URL 固定为https://api.deepseek.com/v1/chat/completions，这是唯一有效的官方端点。

关键参数有三个：model、messages、stream。model必须填deepseek-chat（对应 R1）或deepseek-coder（对应 Coder 系列），填错会直接 404。messages是列表，每个元素是{"role": "user"|"assistant"|"system", "content": "文本"}，注意system角色只在首条消息有效。stream设为true可获得流式响应，但处理逻辑更复杂。下面是一个可直接运行的 Python 示例：

import requests import json API_KEY = "sk-你的密钥" url = "https://api.deepseek.com/v1/chat/completions" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } data = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一个严谨的合同审查助手，只回答与合同条款相关的问题，不编造任何信息。"}, {"role": "user", "content": "请分析以下条款的风险点：'甲方有权在任意时间单方面终止本协议，无需承担任何违约责任。'"} ], "stream": False } response = requests.post(url, headers=headers, data=json.dumps(data)) print(response.json())

注意：如果遇到400 this model's maximum context length is 1048576 tokens错误，说明你传入的messages内容总 token 数超限。DeepSeek-R1 的最大上下文是128K token，但官方 API 限制更严，建议单次请求控制在64K以内。解决方案是预处理：用tiktoken库计算messages的 token 数，超限时自动截断或启用 RAG 检索。

3.2 RAG 知识库构建：从“能存图片”到“读懂图片”的实战方案

热搜词里“rag知识库能存储图片嘛”是个好问题，但答案要分两层：存储和理解。ChromaDB、Weaviate 这类向量数据库，底层存储的是向量（一串数字），不是原始图片。所以，你当然可以把图片的 Base64 编码存进去，但这毫无意义——模型无法从 Base64 向量里“看到”内容。真正的方案是多模态 RAG：先用视觉模型（如clip-vit-base-patch32）把图片转成向量，再用语言模型（如 DeepSeek）把图片描述文本转成向量，最后将两个向量拼接或融合存入数据库。这样，当用户问“合同里签字页的甲方签名是否清晰？”，RAG 检索器会同时匹配文本描述（“签字页”、“甲方签名”）和视觉特征（“手写体”、“墨迹均匀”），召回最相关的图片及其 OCR 文本。

实操步骤分四步：第一步，图片预处理。用Pillow裁剪无关边框，统一缩放至512x512，增强对比度。第二步，视觉编码。用 HuggingFace 的transformers加载openai/clip-vit-base-patch32，提取图片特征向量。第三步，OCR 文本提取。用easyocr（推荐easyocr.Reader(['ch_sim','en'])）识别图片文字，过滤掉页眉页脚噪声。第四步，向量融合。将图片向量和 OCR 文本向量做加权平均（图片权重0.6，文本权重0.4），存入 ChromaDB。关键技巧：不要把整张合同图塞进去，而是按逻辑切分——首页、签字页、盖章页、附件页，每页单独处理。这样检索精度更高，且能精准定位到“第5页签字栏”。

3.3 本地模型加载：Ollama、vLLM 与 LMStudio 的选型与避坑指南

本地部署不是选一个工具就完事，而是根据你的硬件、并发量、开发习惯做组合。我用三台不同配置的机器实测过：一台 Mac M2 Pro（32GB内存）、一台 Windows 4090（24GB显存）、一台 Ubuntu 服务器（A100 80GB）。结论很明确：Ollama 适合个人快速验证，vLLM 适合生产API服务，LMStudio 适合桌面端调试。

Ollama 的优势是极简：ollama run deepseek-coder:33b一行命令启动，自带 Web UI。但它有两个硬伤：不支持流式响应（stream: true无效），且无法精细控制 GPU 显存分配。如果你的4090要同时跑3个模型实例，Ollama 会直接爆显存。vLLM 则相反，专为高并发优化。安装命令pip install vllm，启动命令python -m vllm.entrypoints.api_server --model deepseek-ai/deepseek-coder-33b-instruct --tensor-parallel-size 1 --gpu-memory-utilization 0.9。关键参数--gpu-memory-utilization 0.9表示只用90%显存，预留10%给系统，避免OOM。它原生支持 OpenAI 兼容 API，你的旧代码几乎不用改。LMStudio 是图形界面，拖拽模型文件即可加载，支持 GGUF 量化格式，对新手友好。但它的致命弱点是：所有操作都在 GUI 里，无法集成到你的 Python 脚本中。所以我的工作流是：用 LMStudio 快速测试模型效果和提示词，确定最优参数后，用 vLLM 部署为 API 服务，最后用 Python 脚本调用。

实操心得：加载deepseek-coder-33b时，务必用 AWQ 量化版（如TheBloke/deepseek-coder-33b-instruct-AWQ），而不是 GGUF。AWQ 在 A100 上推理速度比 GGUF 快2.3倍，显存占用低18%。量化不是“降质”，而是“去冗余”——模型里大量权重对推理结果影响微乎其微，量化就是把这些冗余去掉。

4. 实操过程详解：从零搭建一个“合同智能审查助手”

4.1 环境准备与依赖安装：避开版本地狱的实操清单

搭建一个能干活的系统，第一步不是写代码，而是搞定环境。我踩过最大的坑，是 pip 安装的transformers版本和vLLM冲突，导致 GPU 推理直接报CUDA error: invalid device ordinal。所以，我整理了一份经过实测的最小依赖清单，适用于 Ubuntu 22.04 + CUDA 12.1 环境：

# 创建独立虚拟环境，避免污染全局 python3 -m venv deepseek-env source deepseek-env/bin/activate # 升级 pip 和 setuptools，基础保障 pip install --upgrade pip setuptools # 安装核心推理库：vLLM（必须用CUDA编译版） pip install vllm==0.4.2 # 安装 RAG 相关：LlamaIndex（0.10.40）和 ChromaDB（0.4.24） pip install llama-index==0.10.40 chromadb==0.4.24 # 安装多模态支持：CLIP（4.38.2）和 EasyOCR（1.7.1） pip install transformers==4.38.2 torch==2.2.1 torchvision==0.17.1 pip install easyocr==1.7.1 # 安装工具库：tiktoken（用于精确计算token）、PyPDF2（PDF文本提取） pip install tiktoken==0.6.0 pypdf2==3.0.1 # 验证安装：检查 CUDA 是否可用 python -c "import torch; print(torch.cuda.is_available())"

关键点在于版本锁定。vllm==0.4.2是目前与 DeepSeek-Coder-33B 兼容性最好的版本，更高版本会因 FlashAttention 更新导致兼容问题。llama-index==0.10.40则是最后一个支持SentenceSplitter语义切分的版本，新版已移除该功能。安装完成后，务必运行nvidia-smi确认 GPU 驱动正常，再运行python -c "import vllm; print(vllm.__version__)"确认 vLLM 加载成功。如果卡在import vllm，大概率是 CUDA 版本不匹配，此时不要强行升级，而是卸载重装vllm的 CUDA 12.1 版本：pip install vllm-0.4.2+cu121 -f https://download.pytorch.org/whl/cu121/torch_stable.html。

4.2 RAG 知识库构建全流程：从 PDF 到可检索向量库

假设你有一份《软件采购合同模板.pdf》，目标是让模型能准确回答“付款条件是什么？”、“违约金比例是多少？”。整个流程分五步，每步都有可复制的代码和参数。

第一步：PDF 文本与图像分离。用PyPDF2提取纯文本，用pdf2image提取所有页面图片。文本用于后续 OCR 和语义切分，图片用于多模态 RAG。

from PyPDF2 import PdfReader from pdf2image import convert_from_path # 提取文本 reader = PdfReader("合同模板.pdf") text = "" for page in reader.pages: text += page.extract_text() + "\n" # 提取图片（每页转一张PNG） images = convert_from_path("合同模板.pdf", dpi=200) for i, image in enumerate(images): image.save(f"page_{i+1}.png", "PNG")

第二步：文本语义切分。不用简单按换行切，用LlamaIndex的SentenceSplitter，它能识别段落、标题、列表，保证语义完整性。

from llama_index.core.text_splitter import SentenceSplitter splitter = SentenceSplitter( chunk_size=512, # 每块最大512 token chunk_overlap=64, # 重叠64 token，避免语义断裂 paragraph_separator="\n\n" # 段落分隔符 ) nodes = splitter.get_nodes_from_documents([Document(text=text)])

第三步：向量化与存储。用bge-zh-v1.5模型生成向量，存入 ChromaDB。

from llama_index.embeddings.huggingface import HuggingFaceEmbedding from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 初始化嵌入模型 embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-zh-v1.5") # 初始化 ChromaDB client = chromadb.PersistentClient(path="./chroma_db") collection = client.create_collection("contract_rag") # 批量插入向量 for i, node in enumerate(nodes): vector = embed_model.get_text_embedding(node.text) collection.add( ids=[f"node_{i}"], embeddings=[vector], documents=[node.text], metadatas=[{"source": "合同模板.pdf", "page": i//2 + 1}] # 粗略页码映射 )

第四步：多模态图片向量构建。对每张page_x.png，提取 CLIP 向量和 OCR 文本，融合后存入同一数据库。

from transformers import CLIPProcessor, CLIPModel import easyocr # 加载 CLIP 模型 processor = CLIPProcessor.from_pretrained("openai/clip-vit-base-patch32") model = CLIPModel.from_pretrained("openai/clip-vit-base-patch32") # OCR 识别 reader = easyocr.Reader(['ch_sim', 'en']) for i in range(len(images)): # OCR 文本 ocr_result = reader.readtext(f"page_{i+1}.png") ocr_text = " ".join([item[1] for item in ocr_result]) # CLIP 向量 inputs = processor(images=images[i], return_tensors="pt") image_features = model.get_image_features(**inputs) # 融合向量（简单平均） combined_vector = (image_features.detach().numpy()[0] + embed_model.get_text_embedding(ocr_text)) / 2 # 存入 ChromaDB（复用同一 collection） collection.add( ids=[f"img_page_{i+1}"], embeddings=[combined_vector.tolist()], documents=[ocr_text], metadatas=[{"source": "合同模板.pdf", "type": "image", "page": i+1}] )

第五步：检索器封装。写一个函数，输入问题，返回最相关的3个文本块+2个图片块。

def retrieve(query: str, top_k: int = 5): query_vector = embed_model.get_text_embedding(query) results = collection.query( query_embeddings=[query_vector], n_results=top_k ) return results['documents'][0], results['metadatas'][0]

这个流程跑通后，你的 RAG 知识库就具备了“读文本”和“看图片”的双重能力，不再是单薄的文本库。

4.3 vLLM API 服务部署与 DeepSeek 模型加载

vLLM 的强大在于它把复杂的 GPU 并行推理封装成了一个标准的 OpenAI 兼容 API。部署步骤极其简洁，但参数选择决定成败。

启动命令详解：

python -m vllm.entrypoints.api_server \ --model deepseek-ai/deepseek-coder-33b-instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 131072 \ --port 8000 \ --host 0.0.0.0

• --model：指定 HuggingFace 模型 ID。注意，deepseek-ai/deepseek-coder-33b-instruct是官方仓库，必须用这个，不能用社区魔改版。
• --tensor-parallel-size 1：单卡部署设为1。如果是双A100，设为2，vLLM 会自动切分模型权重。
• --gpu-memory-utilization 0.85：显存利用率设为85%，预留15%给系统和临时缓存，这是防止 OOM 的黄金参数。
• --max-model-len 131072：设置最大上下文为128K，匹配 DeepSeek-Coder-33B 的能力。设小了会截断长文本，设大了浪费显存。
• --port 8000：API 端口，可自定义。

启动后，访问http://localhost:8000/docs就能看到 Swagger UI 文档，和 OpenAI 完全一致。调用方式也一样：

import requests url = "http://localhost:8000/v1/chat/completions" headers = {"Content-Type": "application/json"} data = { "model": "deepseek-coder-33b-instruct", "messages": [{"role": "user", "content": "写一个Python函数，计算两个日期间的天数差"}] } response = requests.post(url, headers=headers, json=data) print(response.json()['choices'][0]['message']['content'])

注意：vLLM 默认不启用logprobs，如果你需要概率输出，启动时加--enable-logprobs参数。但会略微降低吞吐量。

4.4 “合同审查助手”主程序：任务流编排与结果校验

现在，把 RAG 和 vLLM API 串起来，写一个真正的“能干活”的程序。核心逻辑是：用户上传 PDF → 自动提取文本和图片 → RAG 检索相关条款 → vLLM 生成结构化审查报告 → 正则校验输出格式 → 失败则重试或告警。

import re import json from typing import Dict, List def contract_review(pdf_path: str, question: str) -> Dict: # 步骤1：提取文本和图片（复用4.2节代码） text, images = extract_pdf_content(pdf_path) # 步骤2：RAG 检索（复用4.2节 retrieve 函数） docs, metadatas = retrieve(question, top_k=3) # 步骤3：构造 Prompt，强制结构化输出 prompt = f"""你是一个资深法务，正在审查一份合同。请严格按以下JSON格式回答，不要任何额外文字： {{ "risk_points": ["风险点1", "风险点2"], "suggested_revisions": ["修改建议1", "修改建议2"], "source_references": ["来源：合同模板.pdf_第3页_条款2.1"] }} 问题：{question} 相关条款：{' '.join(docs)}""" # 步骤4：调用 vLLM API response = call_vllm_api(prompt) raw_output = response['choices'][0]['message']['content'] # 步骤5：正则校验 JSON 格式 json_match = re.search(r'\{.*\}', raw_output, re.DOTALL) if not json_match: # 校验失败，触发重试（最多2次） for _ in range(2): response = call_vllm_api(prompt + " 请务必输出合法JSON，不要任何解释。") raw_output = response['choices'][0]['message']['content'] json_match = re.search(r'\{.*\}', raw_output, re.DOTALL) if json_match: break # 步骤6：解析 JSON，添加元数据 try: result = json.loads(json_match.group()) result["review_time"] = datetime.now().isoformat() result["retrieved_docs_count"] = len(docs) return result except json.JSONDecodeError: # 彻底失败，返回告警 return {"error": "模型输出格式严重错误，请检查输入或联系管理员", "raw_output": raw_output} # 调用示例 result = contract_review("客户合同.pdf", "付款条件是否存在重大风险？") print(json.dumps(result, indent=2, ensure_ascii=False))

这个程序的关键在于校验与重试机制。它不信任模型的第一次输出，而是用正则强制提取 JSON，失败则降级重试。这比单纯依赖“温度=0”或“top_p=0.1”可靠得多。实测下来，在100份真实合同测试中，结构化输出成功率从72%提升到98.3%。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 API 调用类问题速查表

实操心得：永远不要在生产代码里硬编码 API Key。用环境变量os.getenv("DEEPSEEK_API_KEY")，配合.env文件管理。Key 泄露是最高危安全事件，一次泄露可能导致账户被滥用产生高额账单。

5.2 RAG 效果不佳的根因分析与优化路径

RAG 效果差，90%的情况不是模型问题，而是数据和流程问题。我总结了五个必查点：

第一，嵌入模型不匹配。用英文模型all-MiniLM-L6-v2处理中文合同，召回率必然低。解决方案：中文场景必须用BAAI/bge-zh-v1.5或maidalun1020/bce-embedding-base_v1，并在LlamaIndex中显式指定：

embed_model = HuggingFaceEmbedding( model_name="BAAI/bge-zh-v1.5", trust_remote_code=True # 中文模型常需此参数 )

第二，文本切分破坏语义。简单按\n切分，会把“付款方式：银行转账”和“开户行：XXX”切成两块，检索时无法关联。解决方案：用LlamaIndex的HierarchicalNodeParser，先按标题切大块（如“付款条款”），再在大块内按句子切小块。

第三，检索未重排序。ChromaDB 的默认相似度搜索，对长尾关键词不敏感。解决方案：在检索后加入CohereRerank重排序器，它能基于查询语义对候选结果二次打分：

from llama_index.postprocessor.cohere_rerank import CohereRerank reranker = CohereRerank(api_key="your-cohere-key", top_n=3) results = reranker.postprocess_nodes(nodes, query_str=question)

第四，上下文注入不充分。只把检索到的文本块塞进messages，模型不知道这是“合同条款”，还是“会议纪要”。解决方案：在 Prompt 中明确角色和上下文：

messages = [ {"role": "system", "content": "你是一名公司法务总监，正在审查一份软件采购合同。以下是从合同中检索到的相关条款："}, {"role": "user", "content": f"条款内容：{retrieved_text}\n\n问题：{question}"} ]

第五，未处理多跳推理。用户问“甲方违约时，乙方能索赔多少？”，这需要先找到“违约责任”条款，再找到“赔偿金额”子条款。单次检索无法完成。解决方案：实现两轮 RAG——第一轮检索“违约责任”，第二轮用第一轮结果中的关键词（如“赔偿”、“金额”）再次检索。

5.3 本地模型部署的显存与性能瓶颈突破

本地部署最头疼的，就是显存不够用。我整理了一套“显存诊断-优化-验证”三步法：

诊断：用nvidia-smi实时监控。启动 vLLM 后，观察Memory-Usage是否持续接近Max。如果Used占Max的95%以上，说明显存吃紧。

优化：

• 量化：deepseek-coder-33b原始 FP16 占用约66GB显存。用 AWQ 量化后降至32GB，速度提升2倍。量化命令：python -m awq.entry --model_path deepseek-ai/deepseek-coder-33b-instruct --w_bit 4 --q_group_size 128 --output_dir ./quantized。
• 批处理：vLLM 的--max-num-seqs 256参数控制最大并发请求数。设太高会OOM，设太低吞吐低。我的经验是：A100 80GB 设为128，4090 24GB 设为32。
• KV Cache 优化：vLLM 默认启用 PagedAttention，但若显存仍紧张，可加--block-size 16减小块大小，牺牲一点速度换显存。

验证：优化后，用ab工具压测：

ab -n 1000 -c 50 -H "Content-Type: application/json" -p test_payload.json http://localhost:8000/v1/chat/completions

关注Requests per second和Time per request。如果 QPS 提升但延迟增加超过20%，说明优化过度，需回调参数。