说实话，这两年我接触了不少中小企业老板和技术负责人，一开口就是“我们要不要也上一个私有化大模型”“千问、Llama 哪个本地部署更稳”。很多人被各种“AI数字化”的行业文章搞得焦虑，总觉得不上个复杂的分布式推理框架、不搞个几十张显卡的集群，就落后于时代了。但真到了算预算、盘需求那一步，才发现这事没那么简单。
今天这篇就围绕“中小公司做 AI 数字化，要不要直接上复杂大模型部署”这个问题，结合我用千问（Qwen）在办公场景落地的实际经验，聊聊从决策到选型、从部署到避坑的完整思路。我的结论先放在这里：中小公司真正需要的不是“显眼的大模型部署”，而是“让 AI 真正进到办公流程里干活”。复杂部署是手段，不是目的，方向一旦搞反，钱花了，团队也累了，最后大概率只收获一个吃灰的 GPU 服务器。
1. 先别问“能不能部署”，先问“部署了干什么”
1.1 复杂大模型部署背后的隐性成本
很多人看到“千问本地部署”“大模型私有化”就觉得门槛不高了，毕竟开源模型满天飞，一条ollama run qwen2.5就能在笔记本上跑起来。但中小公司如果直接奔着“复杂大模型部署”去，往往忽略了三笔隐性成本。
第一笔是硬件成本。别只看一张消费级显卡能跑 7B 模型，真要支撑全公司几十号人同时用，推理吞吐根本扛不住。我见过一家 200 人规模的公司，老板拍板买了两台 8 卡机器，结果实际业务只跑了一个文档问答机器人，高峰期显存占用不到 30%，绝大部分算力在空转。按一张主流加速卡 2 到 3 万的价格算，这两台设备就是大几十万的沉没成本。
第二笔是运维成本。复杂部署通常意味着要上 vLLM、TensorRT-LLM、Kubernetes 这一整套东西，你得有人懂 CUDA 环境、懂显存调度、懂高并发推理优化。中小公司哪有专职的 AI 运维岗？最后往往是做后端的同事硬着头皮兼任，出了问题查一晚上日志，第二天还得正常写业务代码。
第三笔是业务对齐成本。模型部署得再漂亮，如果没人告诉它“我们公司的报销流程是什么样”“这份合同里的风险条款该怎么审”，它对于办公场景就是一堆随机参数。很多企业上了大模型之后发现，员工问两句觉得回答不靠谱，就再也不用了。
1.2 从“部署思维”切换到“场景思维”
我给中小公司的第一个建议是，把问题从“要不要上复杂大模型部署”改成“我们公司最耗人、最重复、最需要知识沉淀的办公场景是哪几个”。这才是 AI 数字化真正该回答的问题。
拿我自己经历过的几个案例来说。一家做外贸的公司，最痛的是每天要回复大量相似的产品询盘邮件，业务员来回复制粘贴改措辞；一家 50 人左右的设计工作室，最痛的是合同的初审、报销单据的粘贴、新员工入职制度问答；还有一家电商代运营公司，最痛的是把一堆客服聊天记录整理成日报和周报。
这些场景有个共同点：不需要 700 亿参数的大模型，也不需要多机多卡分布式推理。它们需要的是“一个靠谱的文本助手 + 能够访问本公司知识的通道”。千问 7B、14B 这个规模的模型，量化之后用一张消费级显卡甚至纯 CPU 就能跑，配合检索增强（RAG）把公司文档喂进去，效果已经足够让人“觉得这个 AI 真懂我们公司”。
所以，在纠结技术方案之前，先拿一张纸列出公司前十个最重复的办公任务。如果连三个都列不出来，那说明现在上大模型确实为时过早，倒不如先梳理流程。
2. 千问办公落地，到底选哪条技术路线
2.1 开源模型与商用 API 的取舍
聊到千问办公落地，很多人会问“到底该用阿里云的百炼 API，还是自己私有化部署”。我的建议是分阶段看。
如果公司数据敏感度不高、预算有限、想要两周内看到效果，直接用官方 API 是最划算的。通义千问的 API 价格按 token 计费，几十个人的办公场景一个月可能也就花几百块钱，还省掉了所有机器和运维。适合先跑通流程、验证场景的阶段。
但如果数据涉及客户名单、财务报表、薪酬绩效这类敏感信息，或者公司注册地、所在行业对数据出境有要求，那就必须走私有化部署。这时候千问开源模型的优势就出来了，qwen2.5 系列在 Apache 2.0 协议下可以商用，参数从 0.5B 到 72B 都有，能根据企业规模灵活裁剪。
我个人比较推荐的路径是“混合式”：先把非敏感的通用办公场景接到 API 上快速试用，同时在内网用一台 GPU 工作站部署千问 7B 或 14B 的量化版，把敏感数据类的问答、合同初审、制度查询逐渐迁到内网。两条腿走路，既不耽误业务，也不至于一开始就在基础设施上押重注。
2.2 部署工具：Ollama 起步，vLLM 跟上
当前主流的本地部署工具，我认为可以按使用人群分成三类。
第一类是面向个人和轻量办公的，代表是 Ollama。它对硬件要求低，装完就是一条命令拉模型，内置了 OpenAI 兼容接口，很多办公应用能直接接进来。我测试下来，Ollama 跑 qwen2.5 7B 的量化模型，在单张 24GB 显存的卡上非常流畅，支持五六个并发请求没什么压力，这已经覆盖了绝大多数中小公司的实际使用情况。
第二类是面向有一定研发能力的团队，代表是 vLLM。它最大的优势是推理吞吐量高，适用于需要同时服务几十甚至上百个请求的场景，比如把模型接入 OA 系统，全公司几百号人同时用。vLLM 支持连续批处理、PagedAttention 这些优化技术，同样一张卡，吞吐能比 Ollama 高出不少。缺点是安装配置更复杂，需要一定的 Python 和 CUDA 基础。
第三类是纯 CPU 或边缘设备上的方案，代表是 llama.cpp。它的意义在于“没显卡也能跑”。我试过在一台只配了 64GB 内存的服务器上用 llama.cpp 跑 qwen2.5 7B 的 Q4 量化版，生成速度确实不快，但对“合同条款检索+摘要”这类不需要实时对话的任务是够用的。
给中小公司的建议很简单：一个人就能维护、十个请求以内并发，无脑上 Ollama；有研发团队且并发高，再去碰 vLLM。一上来就 RAM 集群，属于给自己找事。
3. 实操过程：用 Ollama 把千问跑起来并接入办公场景
3.1 硬件准备：显存规模怎么算
很多人在部署前最纠结的就是硬件配置。我提供一个非常粗略但够用的估算方法。
推理时模型需要占用的显存，大约等于模型参数量的两倍再乘以量化系数的倒数。比如 qwen2.5 7B 的 FP16 版本，占用的显存大约是 14GB；Q4 量化版大约占 4GB 到 5GB。再加上的上下文窗口（KV Cache）和运行开销，单张 16GB 显存的卡跑 Q4 量化 7B，同时支持 8K 到 16K 上下文，是绰绰有余的。
如果要把上下文窗口拉得很长，比如让它一次性读 50 页 PDF，显存需求会明显增加。我的经验是：办公场景 7B 模型 + 单张 24GB 显存卡，是最稳的起步配置。预算够就上 14B 的 Q4 量化版，效果在语义理解、长文档归纳上会明显好一截，但推理速度会慢大约 30% 到 50%。
预算不太够的团队也可以先用 CPU 方式跑一版 3B 或 7B 的小模型验证流程，只是生成速度确实会让人着急，不适合作为最终方案。
| 模型规模 | 量化级别 | 约需显存 | 适合场景 |
|---|---|---|---|
| Qwen2.5 0.5B | Q4 | 1GB 以内 | 标题生成、简单分类 |
| Qwen2.5 3B | Q4 | 约 2.5GB | 轻度问答、意图识别 |
| Qwen2.5 7B | Q4 | 约 5GB | 文档摘要、合同初审、制度问答 |
| Qwen2.5 7B | FP16 | 约 14GB | 对效果要求更高、上下文较长 |
| Qwen2.5 14B | Q4 | 约 9GB | 高质量问答、复杂推理 |
| Qwen2.5 32B | Q4 | 约 20GB | 接近 API 体验的本地效果 |
3.2 安装与模型拉取：从零跑通千问
先说最简单的路线，用 Ollama。我个人最常用的部署机器是一台 Ubuntu 22.04 的服务器，装好了 NVIDIA 驱动之后，执行下面的脚本安装 Ollama：
curl -fsSL https://ollama.com/install.sh | sh安装完成后，直接把千问模型拉下来：
ollama pull qwen2.5:7b-instruct-q4_K_M这个命令会下载量化后的 7B 千问指令模型，大概 4.7GB。第一次启动需要把模型加载进显存，之后就开始监听默认的 11434 端口。我们先用一条命令验证生成效果：
ollama run qwen2.5:7b-instruct-q4_K_M "用一句话介绍什么是检索增强生成"如果能在几秒内返回一段合理的中文回答，说明基础部署已经跑通了。接下来要做的是把它暴露给局域网内的其他办公电脑。修改 Ollama 的服务配置，让它监听所有网卡：
sudo systemctl edit ollama在打开的编辑器中填入：
[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"保存并重启服务：
sudo systemctl daemon-reload sudo systemctl restart ollama到这一步，公司内网里的任何一台电脑都可以通过http://服务器IP:11434访问到千问模型了。用 curl 快速验证一下：
curl http://192.168.1.100:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b-instruct-q4_K_M", "messages": [{"role": "user", "content": "你好"}] }'这个接口是 OpenAI 兼容格式，所以很多现成的 AI 办公工具、IDE 插件都能直接接进来。
3.3 把千问接进办公流程：文档问答与知识库
模型能跑通只是第一步，真正让员工觉得“有用”，得让它能回答公司内部的问题。推荐的做法是搭一个带 RAG 的本地知识库。
我的选择是 AnythingLLM 搭配 Ollama，因为前者图形化做得好，普通同事也能自己维护知识库的文档。部署思路大概是这样：
- 把公司规章制度、产品手册、FAQ、合同模板等文档整理成 PDF 或 Word，放进一个指定目录。
- 在 AnythingLLM 里配置语言模型为 Ollama 上的千问，再配置一个嵌入模型（Embedding Model），比如千问的文本嵌入模型或
nomic-embed-text。 - 系统会把文档切片并向量化，用户提问时会先检索相关片段，再交给千问整理成带出处的回答。
接了知识库之后，效果和我之前只裸跑模型完全是两码事。员工问“年假制度是什么”，模型回答就不只是泛泛的“年假一般按工龄算”，而是会引到公司制度文档里的具体条款。这是中小公司 AI 数字化性价比最高的一个动作，没有之一。
另外一个高频场景是让千问辅助写文档和回邮件。在员工电脑上装一个支持 OpenAI 兼容接口的 AI 助手客户端，把服务地址指向内网的 Ollama，就能在写周报、回邮件、整理会议纪要时直接调用公司自己的模型。数据不出内网，老板放心，员工也免去了一批重复打字。
4. 常见问题与排查技巧实录
4.1 部署过程中的典型坑：显存与性能问题
我见过最多的问题是部署完之后，发现模型生成速度特别慢，或者直接报显存不足。
先看显存不足。最常见的原因是模型加载时没有考虑上下文窗口的大小。虽然 Q4 量化 7B 模型只要 5GB 左右显存，但如果你把上下文设置成 32K，聊几轮之后 KV Cache 会吃掉好几 GB。我在 Ollama 里一般会显式限制上下文长度，比如跑 7B 模型时设置num_ctx为 8192，保证在多人并发使用时不至于某个人把显存占满。
再看生成慢。如果生成速度只有每秒几个 token，先检查是不是跑在 CPU 上。Ollama 默认会用 GPU，但如果驱动或 CUDA 没装好，它会悄悄回退到 CPU。用ollama ps命令看一下模型加载到哪个设备上，如果显示的是 CPU，就去查驱动的安装情况。
另外，Ollama 默认加载模型之后会一直占着显存，哪怕没有请求。如果公司只有一张卡，又想让多个模型轮流用，可以把keep_alive参数调短，比如设为 5 分钟，空闲后自动释放显存，给其他任务腾地方。
4.2 落地办公时更容易踩的坑：检索、权限与合规
技术问题其实都好解决，真正容易栽跟头的是办公流程里的“软问题”。
第一个坑是知识库检索不准。很多人发现接了 RAG 之后，模型回答的还是常见百科式答案，不引用公司文档。这多半是切分策略的问题。我把文档从原来的固定 500 字切片改成按标题和段落切分，同时让切片之间有部分重叠，召回效果立刻好了很多。
第二个坑是访问权限失控。公司制度不可能所有人都能看全，薪酬文件、绩效评语这些敏感内容如果被一股脑放进知识库，就等着出事。我的建议是知识库也要分权限，或者至少先只放全员可读的制度类文档，涉及敏感数据的文件暂时不要进系统。
第三个坑是内容合规问题。有些同事故意拿模型问敏感问题，或者诱导它输出不适合办公环境的内容。这里我要多说一句，千万不要为了“功能强大”去部署来路不明的无限制版本，数据进去之后完全不可控，出了问题还得自己兜底。企业在内部用 AI 反而应该做好内容审计，在代码和提示词层面加一层过滤，同时保留操作日志，让所有员工知道公司模型产生的对话记录是有迹可循的。这不是为了限制谁，而是企业基本的风险控制。
| 问题 | 典型表现 | 排查思路 | 解决建议 |
|---|---|---|---|
| 显存溢出 | 请求报错 CUDA OOM | 检查并发的上下文占用 | 调小num_ctx或限制并发数 |
| 生成太慢 | 每秒只有 3 到 5 个 token | 确认模型是否加载在 GPU | 重装 CUDA，或改用更低量化版本 |
| 回答不引用公司文档 | 知识库形同虚设 | 检查切分策略和 Embedding 模型 | 按段落切分、加大切片重叠 |
| 多人并发卡死 | 一个请求超长生成，其他人排队 | Ollama 单进程处理能力有限 | 并发高时换 vLLM，或限制最大生成长度 |
| 敏感信息泄露 | 普通员工问出薪酬数据 | 知识库权限失控 | 分目录管理、敏感文件暂不接入 |
5. 关于“微调行业大模型”，我给中小公司的忠告
5.1 RAG 优先，微调后置
聊到最后，还得说说“微调行业大模型”这个热门话题。很多公司觉得只有微调才能让千问更懂自己，于是花大价钱准备训练数据、租 GPU 做 LoRA，结果训完发现效果提升有限，还搞出一堆灾难性遗忘的问题。
我的看法是：对于 90% 的中小公司，RAG 比微调重要得多，而且成本低得多。原因很简单，办公场景里大部分知识是动态变化的。今天改了作息时间，明天更新了产品价格，用 RAG 只需要重新上传文档，索引实时更新；如果用微调，每次变化都得重新训练一轮，根本不现实。
那什么情况下才值得微调？只有当公司业务有稳定的、格式化的输出要求，比如特定的报告模板、固定的客户沟通风格、特有的行业术语翻译，这时微调能让模型质量上一个台阶。另一个前提是你手里得有成百上千条高质量标注数据，如果只有几百条，微调的效果通常不如把提示词写好。
5.2 如果真要微调，建议走轻量路线
如果你确实决定试一下微调，我建议从 LoRA 开始。我之前用过 LLaMA-Factory 这套工具，对千问系列支持得比较好，环境配置也比自己从零写训练脚本省心很多。
大概流程是这样的：准备 500 到 1000 条问答对，格式最好是“指令 + 输入 + 期望输出”，然后把数据整理成 JSON 或 JSONL，在 LLaMA-Factory 里选择 qwen2.5-7b 作为基座模型，用 LoRA 微调，训练一两轮就能看到初步效果。硬件上单张 24GB 显存的卡可以勉强跑 7B 的 LoRA，如果开不了全量微调也没关系，LoRA 本身参数量很小，效果在垂直场景里往往比全量微调更稳。
微调完的模型导出之后，可以通过 Ollama 的 Modelfile 导入运行，也可以继续走 vLLM 部署。我个人的建议是，微调这件事至少放到整个 AI 数字化项目启动三个月之后再做，先让 RAG 和提示词工程把 80% 的办公场景覆盖掉，剩下那 20% 解决不了的，再用微调去补。
6. 写在最后
从我帮几家公司落地千问办公的实际经验来看，中小公司做 AI 数字化，最大的障碍从来不是技术，而是“什么都想要”。想要大模型部署有面子，想要私有化数据安全，想要功能强大到能替代半个员工，最后往往哪个都没做好。
我更推荐的路径是：用官方 API 验证场景，再用 Ollama 私有化部署千问 7B 或 14B，配合 RAG 把公司文档变成可检索的知识库，最后根据真实使用数据决定要不要引入 vLLM 提升并发、要不要用 LoRA 微调专业任务。整个过程完全可以分步走，每一阶段都有看得见的业务价值，而不是一次性把复杂部署的架子搭起来，然后等业务来适应它。
最后再分享一个我自己在实操中的小技巧：给员工做 AI 工具培训时，别讲技术架构，就告诉他们在写周报、读合同、查制度的时候“可以问一下公司自己的 AI”，然后手把手演示三个高频场景。一旦有人因为这省下了半小时，这个项目就活了。AI 数字化的成功标准，从来不是部署了多少个大模型，而是办公室里的真实工作流里，有没有一个大家愿意天天用的 AI 助手。
