说实话这两年我接触了不少中小企业老板和技术负责人一开口就是“我们要不要也上一个私有化大模型”“千问、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 版本占用的显存大约是 14GBQ4 量化版大约占 4GB 到 5GB。再加上的上下文窗口KV Cache和运行开销单张 16GB 显存的卡跑 Q4 量化 7B同时支持 8K 到 16K 上下文是绰绰有余的。如果要把上下文窗口拉得很长比如让它一次性读 50 页 PDF显存需求会明显增加。我的经验是办公场景 7B 模型 单张 24GB 显存卡是最稳的起步配置。预算够就上 14B 的 Q4 量化版效果在语义理解、长文档归纳上会明显好一截但推理速度会慢大约 30% 到 50%。预算不太够的团队也可以先用 CPU 方式跑一版 3B 或 7B 的小模型验证流程只是生成速度确实会让人着急不适合作为最终方案。模型规模量化级别约需显存适合场景Qwen2.5 0.5BQ41GB 以内标题生成、简单分类Qwen2.5 3BQ4约 2.5GB轻度问答、意图识别Qwen2.5 7BQ4约 5GB文档摘要、合同初审、制度问答Qwen2.5 7BFP16约 14GB对效果要求更高、上下文较长Qwen2.5 14BQ4约 9GB高质量问答、复杂推理Qwen2.5 32BQ4约 20GB接近 API 体验的本地效果3.2 安装与模型拉取从零跑通千问先说最简单的路线用 Ollama。我个人最常用的部署机器是一台 Ubuntu 22.04 的服务器装好了 NVIDIA 驱动之后执行下面的脚本安装 Ollamacurl -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] EnvironmentOLLAMA_HOST0.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 助手。 中小公司私有化部署千问大模型：从选型到避坑的实战指南
说实话这两年我接触了不少中小企业老板和技术负责人一开口就是“我们要不要也上一个私有化大模型”“千问、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 版本占用的显存大约是 14GBQ4 量化版大约占 4GB 到 5GB。再加上的上下文窗口KV Cache和运行开销单张 16GB 显存的卡跑 Q4 量化 7B同时支持 8K 到 16K 上下文是绰绰有余的。如果要把上下文窗口拉得很长比如让它一次性读 50 页 PDF显存需求会明显增加。我的经验是办公场景 7B 模型 单张 24GB 显存卡是最稳的起步配置。预算够就上 14B 的 Q4 量化版效果在语义理解、长文档归纳上会明显好一截但推理速度会慢大约 30% 到 50%。预算不太够的团队也可以先用 CPU 方式跑一版 3B 或 7B 的小模型验证流程只是生成速度确实会让人着急不适合作为最终方案。模型规模量化级别约需显存适合场景Qwen2.5 0.5BQ41GB 以内标题生成、简单分类Qwen2.5 3BQ4约 2.5GB轻度问答、意图识别Qwen2.5 7BQ4约 5GB文档摘要、合同初审、制度问答Qwen2.5 7BFP16约 14GB对效果要求更高、上下文较长Qwen2.5 14BQ4约 9GB高质量问答、复杂推理Qwen2.5 32BQ4约 20GB接近 API 体验的本地效果3.2 安装与模型拉取从零跑通千问先说最简单的路线用 Ollama。我个人最常用的部署机器是一台 Ubuntu 22.04 的服务器装好了 NVIDIA 驱动之后执行下面的脚本安装 Ollamacurl -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] EnvironmentOLLAMA_HOST0.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 助手。