企业智能问答系统本地部署实战：从模型选型到vLLM调优

1. 为什么企业级问答系统的第一步，是先把模型拉回内网

先说一个我最近常被问到的问题：很多团队做智能问答，第一反应是“直接调大模型API不就行了？”确实，如果场景宽松、数据不敏感，调用云上API是最快拿到结果的方式。但一旦进入企业环境——尤其是金融、政务、制造、医疗这类行业，事情就没那么简单了。

我建过不少企业内部的问答系统，几乎无一例外都会撞上三堵墙：

第一堵墙是数据边界。企业内网里的制度文档、技术资料、客户记录、运维日志，这些内容一旦送出去做大模型推理，就脱离了可控范围。哪怕只是发给API做一次“临时”问答，内部合规审计时也是绕不过去的问题。你可以跟业务方解释一百遍“网络传输是加密的”，但对方一句“数据离没离开我们的网？”，就足以让整个方案回到原点。

第二堵墙是成本曲线。调用外部API，在小流量、小范围试点时成本看着很低，但随着用户数涨上去，问答量从每天几百次涨到几万次，费用会变得极其难看。而且资料越多、Prompt越长，token消耗越大，账单涨得比业务指标还快。本地部署是一次性投入，GPU虽然贵，但在连续跑满的情况下，单位成本反而可控得多。

第三堵墙是定制化需求。企业问答不是单纯“把问题丢给模型让它回答”，往往需要挂上内部知识库做检索增强，还需要对输出格式、语气、安全策略做很多干预。直接调API，等于把模型当成黑盒，中间想要加一层权限校验、内容过滤、知识库召回，全部受制于外部服务的接口能力。本地部署之后，模型权重在自己手里，推理服务自己起，中间任何一层都能插入定制逻辑。

所以，如果你接下来要读或写的是《从零到一搭建企业级智能问答系统》这个系列，我的建议非常直接：第一章必须先解决“模型在哪里跑”的问题。这不是因为炫技，而是因为后续所有的检索、对话、权限、审计、评测，全部建立在一个前提之上——推理能力在本地是可控的。

这篇文章就是这套系统的第一块地基。我会把从硬件评估、模型选型到部署框架、接口对接的完整路径走一遍，并且把我实测中踩过的坑一并交代清楚。读完之后，你应该能基于自己的预算和业务场景，判断出选什么模型、用多少显存、走哪条部署路线，以及怎么把模型服务正确地嵌进你的问答系统架构里。

2. 先搞清楚要吃多少显存，再谈选不选GPU

2.1 不同参数量级和精度下，显存到底怎么算

很多第一次做本地部署的人，最容易犯的错误是：先定模型，再买显卡，最后发现卡跑不动，只能重新折返。正确顺序应该是倒过来——先看预算和手头硬件，再反推能跑什么量级的模型。

这里有一个基础的计算公式，虽然简化过，但足够做前期决策：模型权重所需显存 ≈ 参数量（B）× 每个参数占用字节数。不同精度的每个参数占用是这样的：

但这只是“权重”的显存，实际跑起来还要额外留出三块开销：

• KV Cache：每生成一个token，模型就要把之前算过的Key和Value缓存下来。上下文越长、并发越高，这块内存涨得越快。通常2K到4K上下文长度下，7B模型要预留2到4GB。
• 激活值（Activation）：推理过程中间层的临时张量，batch越大占得越多。
• CUDA上下文和其他开销：CUDA runtime、模型加载时的碎片化，一般再预留1到2GB比较稳。

所以实际一台24GB显存的卡（比如RTX 3090 / 4090），跑7B模型的INT8量化版，负载状态大约是7GB权重 + 3GB KV Cache + 1GB激活 + 1GB其他，还剩下12GB左右的可余量。这个余量要给谁？给并发和上下文。

2.2 企业问答场景里的并发，对显存是隐形杀手

如果你只是自己玩，跑一个7B模型，24GB卡绰绰有余。但企业问答系统的特点是并发不可控——上班时间可能同时有几十个用户提问。每个用户的对话都有独立的KV Cache，并发数一上去，显存就会迅速吃紧。

我实测过一个经验值：7B模型INT4量化，4K上下文长度下，单并发大概占6GB多一点；并发拉到10，轻松突破16GB。所以如果你的场景是几十人同时用，一张24GB卡跑7B模型已经偏紧张，需要考虑双卡或者直接上48GB的专业卡。

这里有个选型建议，直接给结论：

• 预算在1万以内：消费级24GB显卡（3090/4090）是甜点位，配7B-14B模型的INT4/INT8量化版本。
• 预算在3到5万：可以考虑两张24GB卡做张量并行，或者一张48GB的A6000，推理速度和并发能力会舒服很多。
• 预算再往上：A100/H100/A800这类数据中心卡，14B模型基本无压力，32B模型也能比较从容。

另外，如果你连GPU都没有，纯CPU部署也不是不能跑，7B模型量化到INT4后，用一套性能好的服务器CPU加上大内存（建议64GB以上），推理速度大概每秒2到4个token，作为调试和开发环境凑合能用，但生产环境我不建议这么做——用户等一个回答要一两分钟，体验基本归零。

3. 开源模型怎么选：问答场景下的现实格局

3.1 主流开源模型的实际能力对比

模型选型是本地部署里最容易被“参数大小”带偏的一个环节。很多团队一看32B就兴奋，结果部署上去发现速度慢、成本高，而实际使用效果并不比7B好多少——因为问答系统的表现瓶颈，往往不在模型本身，而在知识库召回和Prompt编排。

我从问答场景的实际需求出发，把目前主流可本地部署的开源模型梳理一下：

对于绝大多数企业级智能问答，我最常推荐的是Qwen2.5-14B-Instruct的INT8版本或Qwen2.5-7B-Instruct的INT4版本。原因很实际：

• 中文理解和生成能力是开源模型里第一梯队，公司制度问答、技术文档问答都能胜任。
• 指令遵循能力强，配合RAG检索和系统Prompt，输出可控性好。
• 生态完善，无论是Ollama、vLLM还是SGLang，都对Qwen系支持得很到位，几乎不存在兼容性问题。

DeepSeek-R1-Distill系列是另一个值得关注的选手。它继承了DeepSeek-R1的推理能力，在需要多步推理、逻辑计算的问答上表现突出。但要注意，它的输出风格倾向于“先思考再回答”，生成的token数会偏多，也就是说每次回答更慢、更贵。做企业问答时，如果只是查知识库、问制度流程，没必要上它；但如果你的场景里有大量“分析型问题”，那它值得考虑。

3.2 不要迷信“最大”，要匹配真实业务

聊到这里，我想多说一句：模型选型的本质是成本和体验的平衡。7B模型在RAG架构下，配合好的检索，能力完全够用；32B模型在同样架构下，虽然理解更细腻，但推理速度可能只有7B的三分之一到四分之一。对企业问答来说，响应延迟超过10秒，业务方的耐心就会快速耗尽。我见过不少团队在模型上追高，结果部署完发现并发跟不上、响应超时，最后又把参数降回去。与其来回折腾，不如一开始就按“最小可用 + 可替换”的策略来。模型文件下载和管理用统一的方案（比如Ollama或HuggingFace的模型仓库），后续要升级参数规模，切换成本并不高。

4. 部署框架落地：从Ollama快速验证到vLLM生产部署

4.1 开发阶段用Ollama，快速把链路跑通

模型定了之后，下一步是选推理服务框架。这里我不建议直接上重方案。第一步先跑通模型，我的选择是Ollama——它简单到几乎不需要学习成本。

Ollama的优势在两点：一是模型管理非常方便，一条命令就能拉取和运行本地模型；二是它自带对OpenAI兼容API的支持，后续哪怕换成vLLM，代码层的改动可以被压到最小。

安装完成后，整个流程是这样的：

# 1. 拉取模型，这里以Qwen2.5为例 ollama pull qwen2.5:7b-instruct # 2. 运行模型 ollama run qwen2.5:7b-instruct # 3. 默认监听11434端口，可以用OpenAI兼容接口测试 curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b-instruct", "messages": [{"role": "user", "content": "公司年假制度是什么？"}] }'

看到这里你可能会问：这就算部署完了？对，开发阶段的部署就是这么简单。Ollama会自动做好显存管理、并发排队，你写业务逻辑时完全不用操心底层推理细节。

如果要定制模型参数，Ollama提供了Modelfile，相当于模型的“运行配置模板”：

FROM qwen2.5:7b-instruct # 设置系统提示词，统一回答口径 SYSTEM "你是一名企业内部知识助手，请严格依据给定资料回答，不要编造答案。" # 调整推理参数 PARAMETER temperature 0.3 PARAMETER top_p 0.9 PARAMETER num_ctx 8192

构建自定义模型后再运行：

ollama create my-qa-bot -f Modelfile ollama run my-qa-bot

在这个阶段，你只需要关心一件事：业务逻辑和模型服务之间的接口契约。我建议把模型服务层封装成一个独立的模块，对外只暴露“输入问题、返回答案”的接口，内部用OpenAI SDK风格的调用方式对接。这样不管底层是Ollama还是之后的vLLM，上层都不用改。

4.2 生产环境换vLLM，吞吐量不是一个量级

Ollama做原型验证非常顺手，但生产环境我基本会换到vLLM。原因不是Ollama不能生产，而是vLLM有两个企业级刚需能力：

• Continuous Batching（连续批处理）：vLLM会把并发请求动态拼成一个batch送进GPU计算，大幅提升吞吐。
• PagedAttention（分页注意力）：KV Cache按需分页分配，显存利用率比传统预分配高得多。

部署vLLM服务，推荐直接用Docker，省去一堆CUDA环境依赖的问题：

docker run --runtime nvidia --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/qwen2.5-7b-instruct \ --served-model-name qwen2.5-7b \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 --port 8000

几个参数值得解释：

• --gpu-memory-utilization 0.9：允许vLLM使用90%的显存，剩余留给CUDA context和其他进程。
• --max-model-len 32768：最大上下文长度。它不是越大越好，因为上下文越长，KV Cache内存越大，并发能力越小。建议按实际需要设置，不是所有场景都需要32K。
• --served-model-name：对外暴露的模型名，可以自定义。这样你实际用70B模型替换7B模型时，API层的model参数可以保持不变。

起来之后，健康检查一下：

curl http://localhost:8000/v1/models

返回的JSON里能看到模型信息，说明推理服务已经就绪。到这一步，你已经有了一个生产级的模型推理服务，下一步的问题就是：怎么把它接到企业问答系统的架构里。

5. 接入问答系统时的四个关键设计点

5.1 架构分层：模型推理和业务逻辑必须解耦

企业级智能问答系统和“对着模型问问题”的最大区别，是它需要一条完整的处理链：用户进来后，先做权限校验，再判断问题类型，然后去知识库检索相关内容，最后把检索结果和问题一起交给模型生成答案。这一串逻辑如果直接写在调用模型的地方，后面改任何一环都会牵动全局。

所以我建议把系统拆成四层：

• 接入层：负责用户认证、权限控制、问题预处理（敏感信息过滤、敏感词校验）。
• 知识检索层：把用户问题转成向量或关键词，从向量数据库/全文检索引擎里召回相关文档片段。
• 编排层（Orchestration）：决定要不要检索、怎么拼Prompt、要不要查多轮对话历史，是把所有信息组装成最终请求中转站。
• 模型服务层：也就是第4章里部署的vLLM或Ollama，只做一件事——给定Prompt，生成回答。

这种分层最大的好处是：模型升级（比如从7B换到14B）不会影响上面的业务逻辑；同样的架构也能挂不同的模型跑A/B测试。

5.2 RAG检索增强：别让模型“裸答”企业问题

企业问答和通用聊天的本质区别在于，模型的预训练知识里没有你的企业资料。你不告诉它年假是几天、报销流程是什么，它就只能胡编。RAG（检索增强生成）就是解决这个问题的标准方案：先从知识库里召回最相关的段落，再把这些段落连同问题一起交给模型生成答案。

整个RAG流水线有三个关键决策点：

• Embedding模型选型：需要中文场景表现好的。我个人推荐BAAI/bge-m3，它对中文的支持扎实，而且多语言能力好，后续如果知识库里有英文技术文档也能覆盖。Embedding服务建议单独部署，不需要GPU，纯CPU也能跑，或者用服务商的向量化能力。
• 知识切块策略：这是RAG里最影响效果的一环。切块太大，检索回来的内容噪音多、占上下文空间；切块太小，语义不完整。我通常用“固定长度 + 重叠窗口”的方式，块大小500到800个字符，重叠50到100个字符，再结合标题和段落结构做对半切分。具体切多大，需要根据你的文档类型调，没有一个万能值。
• 向量库选型：如果知识库在百万级向量以下，Chroma和Qdrant都够用，部署简单；如果到了千万级，再考虑Milvus这种重方案。起步阶段不用在这块过度设计。

召回之后，Prompt的拼接方式也很关键。我会在系统Prompt里明确告诉模型：只根据给定资料回答；资料里没有的信息直接说不知道；不要自己编造补充。下面是一个可用的Prompt模板：

你是一名企业内部知识助手。请严格根据以下资料内容回答用户问题。 如果资料中没有相关内容，请直接回答“未找到相关信息”。 资料内容： {context} 用户问题： {question} 请注意：不要编造任何资料中不存在的答案。

这一段模板看着简单，但真的能极大减少“幻觉”——模型一本正经胡说八道的问题。我在多个项目里验证过，加了这段约束之后，回答的可靠性提升非常明显。

5.3 多轮对话：上下文传递的正确姿势

问答系统大概率需要支持多轮对话。多轮对话的坑在于：如果每次把全部历史都丢给模型，上下文会迅速塞满，token消耗暴涨，回答质量也会因为信息过载而下降。

我的做法是两层策略：

• 会话摘要压缩：对话超过N轮之后，把之前的对话做一次摘要，压缩成一段背景信息，再拼进当前Prompt。
• 有效历史截断：只保留最近几轮完整对话，更早的内容按关键词提取用户名和核心实体，而不是全部原样带上。

具体来说，每轮对话都要维护一个“上下文对象”，包含：用户ID、会话ID、检索到的文档片段、当前问题、最近3到5轮的历史问答。发送给模型的messages里，历史问答放在system后面、当前问题之前，顺序不能乱——模型是严格感知上下文顺序的。

5.4 权限接入：哪些人能看到哪些知识

企业系统的另一个刚需是权限控制。同一个问答系统，普通员工不应该问到薪资明细，财务部门不应该问到产品路线图。这个能力不能指望靠模型“自觉”——必须在检索阶段就做好过滤。

标准的解法是知识库内容打标 + 用户权限匹配。在每一条知识文档入库时，给它打上可见范围标签；用户发起问答时，根据用户所属角色和部门，只让检索器搜他有权看的文档集合。模型拿到的context本身就是过滤过的，自然就不会“越权回答”。这个方案的优点是很直观，缺点是知识库文档打标本身需要做一轮治理，但这是企业级系统绕不开的工作。

6. 本地部署深水区：我的实测调优和踩坑记录

6.1 量化精度选择：INT8优先，INT4要有保留

很多教程会直接让你上INT4量化，说显存占用小、速度快。以我实测的经验来看，INT4会带来可感知的效果下降，尤其在中文长文本、专业术语多的场景里，会出现答非所问或表述不精确的情况。

我的建议是：24GB显存起步，优先跑INT8。7B模型INT8权重只占7GB左右，留出的显存余量足够支撑不错的并发和上下文。只有当你的硬件实在紧张，或者模型参数上升到14B以上实在塞不下，才考虑INT4。启动阶段先在INT8上验证效果，再根据性能瓶颈决定是否压缩，这是最稳妥的路径。

6.2 上下文长度：不是越大越好，要算并发账

在vLLM部署时，--max-model-len这个参数特别容易踩坑。很多人看模型支持128K，就直接设128K，然后发现并发一上来就OOM。

这里有个简单的账可以算：上下文长度翻倍，KV Cache占用的显存也近似翻倍。假设单请求上下文4K时KV Cache占2GB，上下文拉到32K就要占了16GB，那并发请求还能处理几个？所以生产环境务必根据实际业务定长度。企业问答多数问题的上下文需求在4K到8K之间就够了，16K已经是很宽裕的配置。不是模型支持多少，你就一定要用多少。

6.3 vLLM并发参数：先理解再调

vLLM有俩参数经常让新手困惑：--max-num-seqs和--max-num-batched-tokens。前者限制最多同时处理的请求数，后者限制一次batch里能塞多少token。

我遇到过一种情况：并发明明不高，但GPU利用率很低，响应却很慢。排查下来发现是max-num-seqs设得太低（默认值偏保守），导致请求排队等待。反之，如果你把max-num-seqs调得过高，又有可能导致显存炸掉。比较稳妥的做法是从默认值开始，压测工具（比如使用locust或者简单的并发脚本）逐步加压，观察显存占用和平均响应时间，找到当前配置下的最优值。

另外提醒一个Linux运维层面的坑：vLLM默认把日志打印到标准输出，跑在systemd或Docker里时，日志会以很快的速度膨胀。建议增加启动参数：

--disable-log-requests # 关闭每个请求的日志，减少I/O压力

6.4 常见故障速查：我碰到的问题和最终解法

还有一个特别容易被忽略的问题：服务启动后端口看起来正常，但请求超时。这种情况多半是--max-model-len设置得比模型实际支持长度大很多，模型内部做了不必要的前置填充，导致首token延迟拉高。把上下文长度调到实际业务需要的范围内，首token延迟会明显降下来。

7. 本章落地后的下一步动作建议

大模型接入和本地部署这一层跑通之后，你手里的基础设施是：一个稳定的模型推理服务（Ollama或vLLM），一个与OpenAI兼容的接口层，以及一套已经能跑通的基础问答调用逻辑。这时候你可以做几件事来验证这套基座的可靠性：

第一，做一轮压测。用脚本模拟20个并发用户同时提问，观察平均响应时间、TPOT（每输出一个token的时间）和TTFT（首token时间）。这三个指标直接决定了上线后业务方的使用体验。我的经验值是：7B模型INT8，单卡24GB，4K上下文，20并发下TTFT控制在1秒内、TPOT控制在40毫秒左右，属于合格水平。

第二，搭一个最小可用的评测集。整理50到100条真实业务问题和标准答案，每次换模型、调Prompt后都跑一遍，用“完整率”“准确率”“拒绝回答率”三个维度做对比。这个评测集不用多复杂，但必须要做，否则模型升级或参数调整后效果是变好还是变坏，你完全无感。

第三，把模型服务管理化。无论是Ollama还是vLLM，都要配置好进程守护（如systemd或supervisor），写清启动脚本、日志路径、健康检查接口和告警规则。部署后看一两天，确认无内存泄漏现象。vLLM长时间运行偶发的显存碎片化问题，可以通过定时重启或升级版本缓解。

我个人在数个本地部署项目里的体会是，第三章之前的这一层，看起来“只是把模型跑起来”，但它的成败直接决定后面所有环节的体验。硬件估错、模型选错、并发配错，这些在第一章不暴露，到了上线压测时都会加倍还回来。所以这一章值得多花时间和耐心，把地基夯实了再往上走。