企业官网建设流程全解析

最近好几个朋友问我同一个问题：老板拍板要做AI数字化，是不是就得直接上复杂大模型部署？有人甚至已经开始看GPU集群方案了。我的观点很直接：中小公司千万别急着搭建复杂的大模型部署平台，先想清楚业务里有什么痛点真的需要AI，然后再用最小成本把“千问办公”这类落地思路跑起来。今天这个话题，就是围绕这个展开的。

这里说的“千问”，指阿里开源的大语言模型Qwen系列，社区习惯叫千问。它有几个很适合中小公司的特点：权重开源，可以部署在自己的服务器或者办公电脑上；从7B到72B多个尺寸都有，能匹配不同预算和场景；配套工具也很完整，用Ollama这类工具半小时内就能跑出一个可调用的服务。如果你正在评估公司内部的AI数字化项目，又不想把合同、客户信息、内部流程全交给外部平台，这篇文章应该能帮你少走不少弯路。

这篇文章适合谁看呢？中小公司的技术负责人、IT运维、数字化转型项目牵头人，以及想在公司内部做AI提效但不知道从哪入手的业务负责人。下面我会把思路、选型、实操步骤和踩过的坑一次性讲清楚。

1. 先想清楚：中小公司做AI数字化，到底要不要上复杂大模型部署

1.1 “复杂部署”和“轻量落地”的分界线在哪里

先给“复杂大模型部署”做个定义。我见过不少团队一上来就奔着这个方向：买几台GPU服务器，搭Kubernetes集群，引入模型微调平台，再搞一套多租户的API网关，甚至还要配专职算法工程师。在技术圈这叫“平台化建设”，听起来很完整，但对中小公司来说，大概率是给自己挖坑。

为什么？因为复杂部署解决的是“规模化”和“多团队协作”的问题，而大多数中小公司的现状是：业务量不够大、场景不够多、算法人才也不足。这个时候，平台本身的建设和维护成本已经超过了AI带来的收益。我遇到过一个做外贸的朋友，老板批了60万预算要“搭一套全公司的大模型平台”，最后落地时发现，真正高频的需求就是业务员写邮件、财务整理报销审核要点、行政改通知。60万买回来的平台，一年下来只有两个人在用，大部分时间在讨论平台怎么“运维”。

这就是典型的“为了部署而部署”。那轻量落地是什么呢？就是一台工作站甚至一台高性能办公电脑，装好模型推理工具，把千问模型跑起来，用一个API服务去承接办公场景。不需要复杂的调度，不需要微调平台，不需要全职算法团队。它的目标是“先让AI在真实业务里产生价值”，而不是“先把基础设施建好再等业务上门”。

我的建议是：先把目标定成“跑通三个真实场景”，再考虑平台化。如果是50人以下的小公司，一台带独立显卡的PC就能起步；100到200人的公司，最多两台机器加一个简单的负载均衡就够了。真正到了几百人、每天几千次调用的时候，再回过头来讨论Kubernetes和微调平台，那时候你已经知道自己的瓶颈在哪了，不会被厂商话术带偏。

1.2 办公场景对模型的真实需求，其实没你想的那么高

我帮很多团队做过内部调研，发现一个规律：业务部门提的需求看着五花八门，真正拆解下来，九成都是“文本归纳”“内容生成”“信息抽取”这几类。比如写通知、改公文、整理会议纪要、把聊天记录提炼成待办事项、从合同里摘出关键条款、把Excel里的杂数据整理成表格、给客服话术分类打分、让AI辅助写代码和SQL。这些任务有一个共同点：输入输出都是文本，核心考的是模型的指令跟随能力和格式控制能力，而不是多深的推理能力。

用一个简单的判断矩阵可以帮你决定该上多大模型：

很多办公场景，7B模型的回答质量已经能到“可用”水平。什么叫可用？就是给员工当助理，输出稍微改一改就能用。我见过不少人第一次接触本地AI，张嘴就问“7B会不会太笨”，但实际上在写周报、改邮件这些任务上，7B和70B的差距并没有想象中那么大，真正的差距在“是否理解你的业务背景和输出格式”。所以我的原则是：先用7B跑通流程，再根据具体场景判断要不要升14B或32B，而不是一开始就追大。

2. 千问办公落地的核心思路：选对模型，轻量先跑

2.1 数据安全与成本账，本地部署怎么算得过来

为什么在办公场景里，我特别推荐本地部署而不是全走外部API？第一是数据安全。合同、客户信息、内部流程、员工薪酬，这些数据只要发送到外部平台，就意味着你把自己的核心资料交给别人保管。哪怕供应商承诺不保存、不训练，很多老板在法务和合规层面也不放心。本地部署之后，模型权重和推理过程都在公司内部，数据不出内网，这是最朴素也最硬的理由。

第二是成本账。按调用量来算，外部API在小规模使用的时候确实便宜，但一旦形成习惯，消耗量会涨得非常快。我给你算一笔账：假设一个50人的公司，每天实际产生1000次调用，每次平均消耗800个token，那就是每天80万token，一个月2400万token，按常见API价格折算，一个月轻轻松松几千块，一年下来就是几万块。而本地部署呢，买一台带16G显存显卡的整机，价格在1万到2万之间，跑一年电费加维护也就几千块。用得多，本地更划算；用得少，本地至少也不会“越用越心虚”。

第三是稳定性和可控性。外部API可能因为技术升级、政策调整、定价变化等原因随时变动，本地部署就完全没有这个顾虑。模型跑起来之后，它就是公司的一个内部服务，几点下班它都不会把服务停掉。还有一点容易被忽略：本地部署让你随时可以换模型。今天用千问7B，明天觉得14B更合适，一条命令就能切换，完全不受厂商绑定限制。

2.2 千问系列怎么选：7B、14B还是32B

千问系列到现在已经有多个版本和尺寸，Qwen2.5是目前社区里生态最完整的开源模型之一。跟其他开源模型相比，千问的中文能力、指令跟随能力和工具调用能力都比较均衡，而且官方和社区提供了大量量化版本，方便不同硬件环境跑起来。对办公场景来说，我的建议是：主要关注7B、14B、32B三个档位。

7B的优点是门槛低。8G显存就能跑，甚至在配置高一点的CPU上也能勉强跑，适合行政文秘、日常总结、通知改写这一类任务。14B是我个人最推荐的“办公室均衡型”。它在理解复杂文档、抽取细节、生成结构化内容方面的能力明显比7B上了一个台阶，硬件要求也不算苛刻，16G显存就能跑得很舒服。32B适合那些确实需要处理复杂文本的团队，比如法务、合规、研发辅助，但需要24G以上显存，机器成本也上来了。

还有一个关键概念是量化。简单说，量化就是把模型参数从高精度压缩到低精度，以减小显存占用和文件体积。办公场景推荐用GGUF格式的Q4_K_M量化版本，这是一个兼顾质量与资源消耗的选择。显存需求有个粗略估算公式：模型文件大小约等于参数量乘以每个权重占的位数再除以8，然后加上一定的上下文缓存开销。7B Q4大约需要3.5GB模型空间，加上缓存建议整机8GB显存起步；14B Q4大约7GB模型空间，建议16GB显存；32B Q4大约16GB模型空间，建议24GB以上显存。

顺便说一句，别迷信“模型越大越好”。办公场景最重要的是稳定输出格式，而不是偶尔憋出一个惊艳的回答。7B和14B如果能把系统提示词写明白，日常任务真的够用；反过来，如果32B没有调好，反而会因为“想太多”输出一些花哨但没法直接用的内容。

2.3 部署工具选型：Ollama、vLLM还是llama.cpp

模型选好了，接下来就是用什么样的工具把它跑起来。目前社区里最常用的三个方案是Ollama、vLLM和llama.cpp，各自有明确的使用场景。

Ollama是我做首批验证时的首选。它是一个把模型下载、推理、服务化包装得非常简单的工具，安装之后一条命令就能拉模型、一条命令就能跑服务。它还会自动处理量化、上下文长度、模型切换等细节，对非运维背景的同事也特别友好。缺点是高并发能力一般，适合小团队内部先验证。vLLM则更适合正式服务化。它的吞吐量高，显存管理做得好，能把GPU资源吃得很透，适合公司里几十上百人同时高频使用同一套模型的场景。缺点是安装和配置相对复杂，对Linux环境更友好。llama.cpp的优势是能在CPU上跑，机器再老旧也能先验证效果，但速度确实有限，一般只用来做可行性验证。

具体怎么选，我给一个最简单的判断逻辑：公司里如果只有三五个人试用，直接用Ollama；如果目标是让全公司用起来，先Ollama跑通流程，再让一个人把vLLM配起来，模型文件是可以共用的，不算重复劳动。这样做的好处是先快后稳，不会因为部署工具本身太复杂而拖垮项目节奏。

3. 千问办公落地的实操路径：从一台普通机器开始

3.1 硬件评估：先算一张“够用”的配置单

很多团队卡在第一步，总觉得要先买专业服务器。实际上，办公场景的千问部署对硬件的要求完全在可控范围内。我建议的原则是：先翻一翻公司现有设备，别急着下单。哪怕只有一台16G内存的办公电脑，都可以先用CPU跑7B量化版，感受一下模型输出质量；没问题了再考虑加显卡上更快的方案。

如果要从零配一台专门跑千问的机器，我一般会按三个档位来推荐。第一档是入门验证机，显卡用8G显存级别，比如RTX 3060或者同级产品，配16G到32G内存，整体预算2500到4000元，适合跑7B模型，日常文档总结、通知改写完全够用。第二档是团队实用机，显卡上到16G显存，比如RTX 4080或RTX 4090，配32G到64G内存，整体预算7000到12000元，这是目前性价比最高的一档，可以流畅跑14B，也能跑低量化32B，绝大多数办公场景都覆盖了。第三档是全员服务机，上24G或双卡，预算1.5万到4万，适合明确要服务全公司、且对模型质量要求比较高的团队。

除了显卡，内存和硬盘也不能忽视。部署时很多人只盯着显存，结果内存不够导致模型加载失败，或者硬盘空间不足没法存放多个量化版本。我的经验是：内存尽量不低于显存的两倍，硬盘留出至少50G的余量给模型文件。如果你是Windows环境，建议关闭桌面特效和后台游戏录制，免得模型推理时被系统抢资源。跑起来之后用任务管理器或者nvidia-smi查看利用率，如果模型已经加载但显存还留了很多，说明上下文化和并发参数还有优化空间，后面在问题章节细说。

3.2 5分钟跑起一个可用服务：Ollama安装与调用

先讲最省心的路径：Ollama。安装过程不需要写代码，Windows和macOS直接下载安装包，Linux环境一条命令就能装好。装完之后打开终端，拉取千问7B指令模型：

# 拉取千问7B指令模型（默认是量化版本） ollama pull qwen2.5:7b # 启动服务，保持终端不要关 ollama serve

第一次拉模型会自动下载合适的量化文件，所以不需要手动去找模型权重。服务启动后，默认监听11434端口。可以先做个最简单的测试，确认模型能正常回答：

curl http://127.0.0.1:11434/api/chat \ -d '{"model":"qwen2.5:7b","messages":[{"role":"user","content":"帮我把下面这句话改得更正式：项目延期了，因为测试没做完。"}],"stream":false}'

如果这段命令返回了正常的文本，说明服务已经可用了。接下来就是对接业务。Ollama提供了OpenAI兼容的API，这意味着你不需要记一套新协议，很多现成工具都能直接接进来。我用Python写过一个极简的调用示例，就是往本地API发消息，再取回模型回复：

import requests url = "http://127.0.0.1:11434/api/chat" payload = { "model": "qwen2.5:7b", "messages": [ {"role": "system", "content": "你是公司的行政助理。请把用户提供的内容整理成周报，要求：1. 开头一句话总结；2. 分点列出关键事项；3. 最后标注需要领导决策的问题。"}, {"role": "user", "content": "本周完成了OA系统权限调整、新员工入职IT支持、机房巡检，另外发现服务器的备份任务有一个告警，需要下周一找厂商处理。"} ], "stream": False, "options": {"temperature": 0.3} } resp = requests.post(url, json=payload) print(resp.json()["message"]["content"])

这段代码里最关键的是system prompt。很多人部署好模型后觉得“AI回答很水”，问题往往出在提示词太泛。你让模型“帮我写个周报”，它当然不知道怎么下手；但如果你告诉它“你是行政助理”“输出要分几点”“最后要标注领导决策问题”，回答质量立刻就不一样了。这里我习惯先把输出模板定好，再让AI去填内容，而不是让AI自由发挥。

另外一个实操细节是temperature参数。办公内容生成建议设置在0.1到0.3之间，尤其是合同摘要、表格整理这类任务，数值调高容易让模型自由发挥，反而增加校对成本。聊天辅助类可以略微高一点到0.5左右，但也不建议超过0.7。

3.3 把AI接进办公流：机器人、API、知识库

服务跑起来之后，下一个问题就是“同事怎么用”。我的经验是：不要一开始就做复杂系统，先做三个轻量入口，选一个最痛的场景先上。

第一个入口是群机器人。飞书、钉钉、企业微信都支持自定义机器人，原理很简单：在群里创建一个机器人，拿到它的Webhook地址，然后写一个小服务接收群消息，转发给本地千问API，再把回复发回群里。这样同事不需要学习任何新工具，直接在群里就能用AI。注意在群里@机器人提问的方式最不容易误触发，否则一聊别的就可能把无关内容发给模型，既浪费资源又泄露信息。

第二个入口是独立的内部小工具。如果公司没有现成的IM，做一个网页版聊天界面也很简单。前端一个输入框，后端定时轮询或者长连接调用本地API，再加上一个简单的身份登录。我见过很多团队用Streamlit十几分钟就搭出了一个给内部用的AI助手，效果一样不差。核心是让大家觉得“这个工具是专门给我们的”，而不是装了个实验玩具。

第三个入口是知识库问答。等同事习惯用AI之后，需求自然会升级：不只是写东西，而是要查公司内部的制度、项目文档、产品资料。这时候就涉及RAG（检索增强生成）。完整方案是先把文档切片成500到800字的块，做向量化，用户提问时先从库里检索最相关的几段，再拼接到提示词里交给千问回答。但初期我建议先做一个“伪RAG”：把文档拆好后放目录，让用户自己把相关段落粘贴进去提问。办法虽然笨，但能让团队先验证“知识库问答这个需求到底值不值得做”，而不是一上来就搭向量数据库。

不管用哪种入口，有两件事一定要做：一是加权限控制，不要让所有员工都能访问模型服务，至少要在应用层做白名单或者登录；二是留日志，谁在什么时间问了什么，模型回复了什么，都要存下来。这不是为了监视员工，而是防止有人拿公司数据乱问，出了风险可以追溯。我处理过不止一次同事把包含客户手机号的表格贴给AI，然后问“帮我提取里面所有电话号码”，如果没有脱敏和审计，这个行为完全可以避免，也可以及时发现。

4. 常见问题与排查技巧实录

4.1 显存不够、推理太慢怎么解

显存不够和推理太慢，是本地部署最常遇到的两类问题。先说显存溢出。如果启动时直接报“CUDA out of memory”，优先检查三件事：模型是不是选太大了，上下文长度是不是设置过高，还有并发数是不是太多。办公场景的上下文长度通常不需要很长，一个合同或通知也就几千字，2048到4096基本够用。Ollama可以通过环境变量控制，启动时指定一个更保守的上下文长度：

OLLAMA_CONTEXT_LENGTH=4096 ollama serve

对应的，如果想限制并发请求数，避免多个用户同时触发导致显存打满，可以设置OLLAMA_NUM_PARALLEL=1，让模型一次只处理一个请求。虽然并发低了，但稳定性会好很多，初期让同事先体验比天天卡死更重要。

推理速度慢的排查思路是：先看GPU利用率。如果GPU利用率很高，说明模型在认真算，那就只能降模型大小或量化等级；如果GPU利用率很低但CPU很高，说明模型没有完全加载到GPU，可能是量化文件选错了平台，或者没有装支持GPU的推理后端。还有一种情况是温度墙，笔记本或者小机箱的显卡跑大模型久了会降频，表现就是刚开始快、跑几分钟后变慢。解决办法是打开机箱、加强散热，或者干脆选低一档的模型，别让硬件长期满载。

4.2 回答质量差，先别急着换模型

回答质量差，换大模型确实是一个方向，但大多数人其实还没到这一步。很多团队反馈“7B太弱了”，我一看他们的系统提示词，就五个字：你是AI助手。这种Prompt下，任何模型都不会给你输出稳定的结构。我的建议是：换模型之前，先把提示词工程做扎实。

一个好的办公场景提示词至少要包含四个要素：角色、任务、格式要求、禁止事项。拿会议纪要提炼来说，可以这样写：

你是公司项目助理。请根据用户提供的会议记录，生成一份纪要： 一、会议结论（最多三条） 二、待办事项（按负责人分组，写明截止时间） 三、风险提示 如果原文中没有提到截止时间，不要编造，写“待确认”。语气保持简洁，不要输出客套话。

这种模板化的提示词，比“帮我总结一下”效果好一个量级。另外，温度要调低，办公任务里不需要太多“灵感”，稳定的格式输出才是王道。如果提示词已经写清楚，模型还在犯明显的逻辑错误，再考虑换14B或32B也不迟。

还有一种情况是“答非所问”，因为它没有你脑子里的业务背景。比如你问“这个合同的风险点在哪”，AI不知道你公司的业务模式，自然只能给出泛泛的合规建议。这时候要做的不是换大模型，而是把背景信息塞进提示词，或者接知识库，让模型先“读到”相关上下文再回答。

4.3 多人同时用，并发与权限怎么做

Ollama跑起来之后，一开始可能只有几个人试用，压力不大。但一旦行政、财务、业务部门都开始用，并发压力立刻出现。Ollama的默认设计是串行处理，一个人用着，第二个人就得排队。如果人数超过20人，或者每分钟调用超过几次，我的建议是直接切换到vLLM。部署方式也不复杂，只要模型用Linux服务器，一条命令就能把千问服务化：

pip install vllm vllm serve Qwen/Qwen2.5-14B-Instruct \ --gpu-memory-utilization 0.9 \ --max-num-seqs 4

vLLM在处理并发时的表现要比Ollama强很多，内部有连续批处理和显存管理优化，同样的显卡能服务更多并发请求。但要注意，vLLM默认占用90%显存，如果机器上还有其他服务，或者你想留一些显存给别的模型，这个参数要相应下调。

并发之外，权限问题是很多团队忽略的重灾区。我见过有同事为了方便，直接把11434端口映射到公网，然后用IP加端口访问。这是非常危险的做法，等于把公司内部AI服务裸奔在公网上，任何人都可以调用。正确做法是：服务只监听内网地址；如果有跨地域访问需求，使用办公网络已有的访问控制机制，加一层身份验证，不要直接把服务暴露出去。同时，应用层要做好数据脱敏，手机号、身份证、银行卡号在发送给模型前先替换成占位符，避免敏感信息进入模型上下文和日志文件。

4.4 常见问题速查表

这套问题排查表，基本覆盖了中小公司做本地千问落地前三个月会遇到的80%的问题。真遇到个别疑难杂症，进社区搜关键字也比自己闷头折腾效率高。

最后分享一个我自己的体会：别把“部署”当成目标，真正的目标是“有人用、用得起、有产出”。我在给团队落地这套千问办公方案时，有个很深的感受：技术选型越简单，存活率越高。先跑通一个场景，再慢慢扩容，比一开始就上复杂大模型部署要稳妥得多。如果你公司现在也卡在“要不要大干一场”这一步，我建议先用一个月时间，拿一台机器把千问跑起来，让行政、财务、业务各试一个真实场景。一个月后再回来复盘，你会感谢当初那个没有头脑发热的自己。