去年冬天帮衡水一家做丝网出口的贸易公司搭AI本地部署这个项目从进场到跑通前后花了三周。当时最大的感受是大家在网上讨论本地部署时注意力全被模型选型、显存大小、量化精度这些技术细节吸引走了但真正决定项目生死的是前面那轮需求拆解和方案取舍。这篇文章不打算给你一份人人都能照抄的部署手册——因为每家公司的情况都不一样。我更想把当时那个案例完整复盘一遍需求是怎么从一堆模糊的抱怨里拎出来的方案是怎么在性能和成本之间反复权衡的落地时哪些环节最容易被低估。给正在考虑本地部署的贸易企业或者准备接这类项目的工程师一个完整的决策参考。1. 衡水这家丝网贸易公司当初真正的痛点是什么1.1 每天淹没人力的多语言文书这家公司在衡水安平做丝网出口。安平那边的丝网产业带很成熟企业数量多、产品线全从工业滤网到建筑装饰网都有。但产业成熟也意味着同质化竞争严重大家拼的就是响应速度和报价精度。公司规模不大业务员六七个但每天要处理的询盘邮件少则三四十封、多则上百封。客户来自中东、欧洲、南美、东南亚英语算主流但俄语、阿拉伯语、西班牙语的询盘一点也不罕见。业务员不是翻译科班出身碰上小语种询盘传统流程是先复制到在线翻译里粗翻一遍再靠行业经验猜客户到底要什么规格然后翻产品手册、查历史报价、问工厂交期最后用英文起草回复。这一套走下来单封邮件快则十五分钟慢则半小时。旺季的时候询盘一多业务员基本从早到晚陷在邮件里真正该做的客户维护和主动开发反而没时间。还有个痛点藏在老业务员脑子里。公司做了十几年外贸积累了大量历史成交记录、供应商底价、常见客诉处理方式。但这些东西没有结构化——有的在Excel里有的在微信聊天记录里有的干脆就是老员工的经验。新人来了起码要跟单半年才能上手。老板想把这个经验沉淀下来但一直找不到合适的工具。另外报关单据、装箱单、提单、形式发票这些文书虽然看起来是格式化录入但出错代价极大。一个品名翻译不统一、一个贸促会原产地证书栏目填错货到港就可能滞留。这类工作之前全靠人工核对又枯燥又要命。1.2 试过云端大模型之后为什么又缩回来了老板不是没追过AI。项目启动前他们已经买了几个月的云端大模型API让业务员用在线聊天窗口处理邮件。效果其实看得见翻译确实快回复草稿也够流畅。但用了大概两个月有三个问题慢慢浮现。第一个是数据安全感的问题。这是最核心的也是最终转向本地部署的直接原因。外贸公司的命脉是什么客户名单、价格体系、供应商底价。询盘邮件里天然带着客户联系方式业务员写回复时又会把成本价、最低起订量这些东西贴进去当参考。这些东西发到第三方云端服务里过一遍无论对方承诺多安全老板心里始终不踏实。他说了一句让我印象很深的话要是客户名录和底价泄露出去同行第二天就能用五个点把单子抢走这公司就完了。第二个是费用问题。看着单次调用不贵但业务员用量上去了之后月度账单涨得很快。我们后面算过一笔账具体数字放在第五章讲这里先不展开。总之按那家公司的业务量云端API全年花费几乎够买一台不错的GPU服务器了。第三个是定制能力。通用大模型可以用但不懂丝网行业。客户问304和316不锈钢网有什么区别用在海水养殖环境选哪种通用的回答是304是奥氏体不锈钢316含钼耐腐蚀性更好——没错但不够。老业务员会直接告诉客户你这个环境推荐316虽然贵一截但之前有中东客户用304三年后出现点蚀。这种沉淀在业务一线的实战经验云端模型是给不出来的。所以当老板提出能不能把AI装在自己服务器里的时候我们的判断是这不是一时兴起而是需求已经走到了拐点。数据要留在本地模型要能定制长期成本要可控。三个条件同时满足答案其实就是本地部署。方向清楚了但到底怎么落地还需要把需求拆细。2. 需求拆解贸易AI不是聊天机器人而是一组明确任务2.1 高频任务清单翻译、抽取、生成、质检很多团队做AI落地上来就铺一个智能助手的概念让员工随便问。这最容易导致项目烂尾。我的习惯是先和实际干活的人聊两轮把日常动作里的AI使用场景穷举出来再归纳成任务类型。这个丝网贸易项目里实际高频任务是四类第一类多语言翻译与润色。把俄文、阿拉伯文的询盘翻成中文再把中文回复翻成英文、俄文或西班牙文。翻译之外还要求润色——改成外贸函电的得体表达比如对方上来就是give me best price干净利落但缺少寒暄AI要生成更商务化的版本。第二类信息抽取与结构化。一封长邮件里往往混着产品规格、数量、目标价、贸易术语、交期要求、目的地港口。业务员需要把字段提取出来填进公司自己的报价单模板或者Excel跟进表。这是纯人工来做最容易眼花的环节。第三类知识问答与内容生成。新人问FOB天津和CIF迪拜的报价差在哪AI要从公司知识库里给出带内部经验的回答。给客户写一封跟进信、一封催款函、一封交期延迟解释邮件也都属于这一类。第四类质检和风险提示。合同条款、形式发票上有没有明显矛盾价格条款和付款方式之间对不对得上AI可以当第二道人工复核的机器把明显的坑挑出来让人来看。后面所有技术选型都是围绕这四类任务展开的。聊天框只是这批任务的一种交互形式底层其实是一堆确定的API调用。这个认知决定了我们对硬件和框架的需求评估——并发要求不会太高但抽取类任务对准确性要求很高这直接影响模型该怎么选。2.2 需求分级哪些数据打死不能出内网需求拆解还有一个绕不开的环节数据分级。当时的做法是把所有AI要处理的数据分成三档。第一档绝对不能出内网。客户邮件原文、包含客户名称和联系方式的往来记录、公司历史报价表、供应商底价、已成交客户名录。这些数据是公司的核心资产任何环节都不能流向外部。这一档对应的场景是询盘处理、报价辅助、客户跟进——也就是业务员用得最多的功能。第二档可以留在本地、也值得做成公司知识库。产品手册、技术参数、工厂产能信息、历史订单的脱敏案例、常见客诉处理SOP。这些数据本身不算高度机密但组合起来就是公司的行业Know-how。放进本地知识库由AI调用风险可控收益很大。第三档行业公共知识。贸易术语解释、各国进口清关要求、海运航线常识、跨境电商平台规则这些用通用模型本身的知识就能覆盖不需要特殊处理。这个三档分级直接确定了系统边界所有涉及第一档和第二档的处理流程必须走本地部署的模型和数据管道不开任何外部接口。想清楚这个边界之后方案里所有含糊的地带都消失了。2.3 把需求翻译成技术指标并发、延迟、准确性需求拆完之后还有一个翻译步骤把业务语言翻译成技术参数。这一步做不好后面选型就是盲人摸象。并发数怎么定十几个业务员即使都开着界面也不是每分每秒都在提问。真实情况是一个人写完一封邮件才调用一次中间还要想措辞、查资料。所以并发需求可以按10来设计。用工程一点的说法是10个并发请求支持每用户每分钟一次交互这已经比实际用量高出一倍留了冗余。延迟怎么定交互式聊天用户能接受的等待大概在3到5秒。超过这个数字业务员就会觉得不如自己动手。翻译和抽取类任务请求可以拆成小份处理单次生成的token量通常在200到600之间这个规模给推理留出的时间预算还是比较宽裕的。准确性怎么定翻译可以不是百分百完美但关键贸易术语不能错——CIF、FOB、DDP这些必须准确。抽取类任务要求更严比如从邮件里提取数量5000米、单价FOB天津USD0.35/m提取结果必须和原文一致不能有半点幻觉。质检类任务则定位为复核工具AI标出可疑点人来做最终判断不追求AI独立裁决。这些指标不是拍脑袋定的而是从实际访谈里反向推导出来的。整个项目后续的硬件配置、模型选型、量化方案全部围绕这三个指标展开。有了它们方案选择的每一道选择题都有了判断依据。3. 方案选型算力怎么算、模型怎么挑、框架怎么配3.1 先算显存账从参数量到可运行配置贸易公司不是AI实验室没人会去搞几千亿参数的大集群。预算有限、机房环境就是一间普通的办公室、运维人力基本没有。所以第一步就是把模型参数档位和显存需求的对应关系先列清楚。模型显存占用有一个非常粗略的估算公式显存约等于参数量乘以每参数字节数。7B模型用FP16半精度跑大约需要14GB显存量化到INT4大约只要4到5GB。14B模型FP16要28GBINT4约8到10GB。32B模型FP16要64GBINT4约18到20GB。70B模型基本就不要想了INT4也要40GB以上单卡搞不定上了多卡之后部署复杂度会上升一个量级。这就有个很清晰的结论对一家要做翻译、抽取、知识问答的贸易公司来说70B是性能和成本的双重浪费。我们真正要考虑的是7B、14B、32B这三档里选一个。为了照顾长时间对话和历史记录还得给KV Cache留出显存余量——上下文越长这块占用越大。实践里给7B模型按10GB、14B按16GB、32B按24GB去规划整机显存是比较稳妥的。最终我们给公司选了单张RTX 4090 24GB的方案。这个卡跑14B模型可以免量化直接FP16效果好跑32B模型需要做INT4量化也能流畅运行。等于一个档位跨度两种选择都保住了。当时也考虑过二手企业级卡如Tesla P40或A4000性价比更高但噪音和散热是问题办公室环境不太合适。这块取舍后面还会细说。3.2 开源模型选型对比Qwen、DeepSeek、GLM怎么取舍模型选择上我当时框定了三个方向Qwen2.5系列、DeepSeek-R1蒸馏系列、GLM-4系列外部闭源模型在此前已经排除。Qwen2.5的中文能力和多语言能力均衡指令跟随稳定在贸易文书这类结构化输出任务上有明显优势。7B和14B的尺寸对单卡非常友好适合作为主力。DeepSeek-R1蒸馏版在数学和逻辑推理上表现突出但贸易场景里没那么多复杂推理需求反而它的生成风格偏思考过程冗长做翻译和抽取任务时有点杀鸡用牛刀速度还慢。GLM-4的中文底子同样不错但生态和周边配套相对前两者弱一些。单子里还有个无法回避的选项Llama 3.1 8B。它英文能力强但中文和多语言小语种表现不如Qwen尤其俄语、阿拉伯语这类和英文差异大的语种在中文业务语境下没必要硬选它。最后的组合是主模型用Qwen2.5-14B-Instruct跑FP16精度辅模型用DeepSeek-R1-Distill-Qwen-32B做INT4量化专门处理合同审阅、复杂条款对比这类需要推理的任务。两个模型共用一张4090按需切换日常高频请求全走14B静态分析任务临时启用32B。这种一个大模型不够两个模型配合的思路在Dify的工作流里实现起来并不复杂。3.3 部署框架Ollama、vLLM、Dify各管哪一段模型定了跑模型的引擎也得选。市面上选项不少但每个工具的定位完全不同。我给这个项目的分工是Ollama管模型运行和API暴露Dify管应用编排和知识库中间用标准API连通。Ollama胜在简单。一条命令拉模型、一条命令启动服务自动处理量化格式和基础并发。对小团队来说运维成本几乎为零。但它的问题是大并发场景吞吐量不够动态批处理能力弱。放在这个项目里10个并发用户、每人几秒钟的交互间隔Ollama完全扛得住所以作为推理引擎足够了。vLLM是生产级的选择吞吐量高适合几十人上百人同时用的情况。但它的部署和参数调优门槛也高启动脚本、GPU分配、连续批处理参数都得弄明白。对这十几个业务员的团队来说属于未来扩展项不是当下必需品。Dify这层绕不开。它解决的是Ollama没覆盖的上层问题知识库管理、工作流编排、提示词模板、用户权限、对话日志。没有Dify的话业务员就真的只能面对一个裸的大模型聊天框知识库接不进去工作流没法固化。有了Dify我们才能把询盘翻译字段提取生成回复草稿串成一条固定的工作流让业务员点击一个按钮就完成整套动作。整体架构用一句话概括Dify做前台业务编排和知识库管理Ollama做后台推理执行中间通过HTTP调用Qwen和DeepSeek两个模型。这个架构简单、可靠、替换成本低。就算以后业务量大了要换vLLMDify这边只需要改一个模型供应商地址不用动业务逻辑。3.4 知识库是不可省的一环RAG的落地姿势前面提到老业务员的经验沉淀在Excel、聊天记录和脑子里。要把这些变成AI能用的知识靠的是RAG检索增强生成。这也是很多本地部署项目做得最敷衍的一个环节。我们的做法分三步。第一步收集整理公司现有的结构化和半结构化资料产品手册、规格参数表、报价单模板、历史合同脱敏版本、常见客诉处理记录。第二步把资料清洗分块每一块控制在几百字的量级喂给本地部署的嵌入模型比如BGE-M3转成向量存进向量数据库。这里向量库我选的是轻量的Qdrant或Chroma贸易公司数据量不大没必要上Milvus这种重型的。第三步在Dify里建立知识库应用把先检索后回答的逻辑固化成工作流——用户提问时先从知识库里召回相关片段再连同问题一起交给大模型生成答案。这套RAG跑起来的效果和裸模型相比是质的差别。裸模型解释不了老客户对316网面做环氧涂层有顾虑这种内部经验型问题接了知识库之后AI会把公司历史上类似案例的做法捞出来结合通用知识给业务员一个真正可用的回答。知识库还有个附带好处新人培训可以部分交给AI了。以前新业务员问老员工问题老员工还得放下手头的事解答现在大部分标准问题AI就能答。4. 落地过程还原从裸机到业务员能天天用4.1 内网环境下怎么把模型和依赖备齐贸易公司的办公网络通常很干净没有复杂的IT架构一个千兆路由器加几台电脑就到顶了。这种环境部署本地大模型最难的不是技术本身而是怎么把东西搬进没有外网的内网。我当时的做法是分两步先在能上外网的工作机上准备齐全再进内网整个过程不用依赖内网环境临时下载。先在公司一台联网电脑上装好Docker、docker-compose、Ollama、Dify所需的离线安装包和镜像文件用docker save导出镜像再用脚本把Ollama要用的模型文件全部拉下来。模型文件的获取渠道就是各家模型平台的官方下载方式提前准备好本地仓库然后一起打包。进到内网之后流程就顺了。第一步在服务器上装好NVIDIA驱动和CUDA运行时。第二步docker load导入之前导出的镜像Ollama用导入的模型文件创建模型。第三步按官方文档启动Dify的docker-compose编排把Ollama地址和模型名称配置到Dify的模型供应商里。这里提醒一下模型文件的体积不小14B模型GGUF量化格式大概9GB两个模型加嵌入模型、向量库镜像总共三十多GB。所以最稳妥的做法是把安装镜像和模型文件放在一个大的移动硬盘里带进去别指望现场下载。4.2 量化与加速让对话不卡顿的关键参数模型跑起来只是第一步重点是让它在办公室场景下配合得上人。14B模型在4090上跑FP16问题不大但要同时支持多用户和长上下文还得做两手准备。一是模型量化。主模型Qwen2.5-14B跑FP16这没问题4090的24GB显存放得下。但32B的DeepSeek-R1蒸馏版必须做INT4量化否则显存直接爆掉。量化工具我用的是Ollama内置的GGUF支持直接选用官方社区里成熟的量化版本不自己折腾GPTQ/AWQ。对业务场景来说INT4量化带来的精度损失微乎其微翻译和抽取任务的输出质量没有可感知的下降显存却省了一半以上。二是推理参数调整。Ollama的默认参数在并发场景下需要微调有两个值比较关键进程并发数设为可用GPU内存适当调大上下文长度根据单次交互的token量设了一个够用且不浪费的值。这些参数直接影响同时使用的业务员数量和多轮对话的连贯性。还有一个容易被忽视的点Ollama默认把所有模型常驻显存如果同时加载14B和32B两个模型显存会溢出。解决办法是配置按需加载或者干脆在Dify工作流里错开两个模型的调用时段日常任务全走14B需要时再切32B。加速方面Flash Attention这类技术在现代GPU上是默认启用的不用额外配置。真正影响响应速度的反而是应用层的逻辑prompt设计要精简输出长度要限制知识库检索的top_k不要设太大避免把一堆无关片段塞进上下文拖慢生成速度。4.3 和现有办公流程接上从聊天窗口到邮件草稿技术跑通之后还有个最后一公里的问题让业务员真的用起来。这里我犯过一个典型错误第一版界面就是个空荡荡的聊天框结果业务员问了两句不知道怎么继续转头回去用老办法了。后来我在Dify里重新设计了工作流才真正扭转了局面。具体做了三组固定的应用入口。第一组叫询盘速读业务员把收到的原始邮件全文粘贴进去工作流自动完成翻译、提取产品/数量/港口/贸易术语等关键字段并输出一封结构化的摘要。第二组叫回复起草接上历史成交和产品知识库业务员给出要点AI生成正式回复邮件。第三组叫条款体检针对合同或形式发票AI逐条检查关键条款的一致性和风险点。界面上就是三个预设的提示词模板业务员点进去把内容粘进去就行。模板不是一次性写好的前两周我们根据使用反馈反复调整比如回复起草最初生成的邮件太正式缺了外贸函电里的寒暄感后来在提示词里明确了保留商务寒暄、简洁但不过分正式的风格询盘速读最初不会自动判断客户有没有给出明确目标价改进后要求模型输出时区分已报价/未报价的状态。这轮调整之后业务员的使用频率才真正上来。用他们的话说这不叫聊天机器人这叫帮我干活的外贸助理。5. 这笔账要这样算本地部署的成本与回报5.1 一次性投入与年度运维成本清单本地部署绕不开钱的话题但很多人的算法有问题。只看硬件采购价是不对的得把折旧、电费、维护人力都放进来。这家公司的一次性投入大概是这样一台二手RTX 4090整机约三万元内存64GB大约一千多系统盘加数据盘约两千合计三万五上下。如果四十人以内的小团队使用这是一个典型配置。再加一个UPS不间断电源千把块钱保证断电不损坏数据和模型文件。软件这块全部开源免费Dify、Ollama、Qwen和DeepSeek模型授权都是开放的商业友好许可没有额外授权费。年度运维成本整机功耗按400W算每天运行10小时电费一年大概一千出头峰谷电价差异忽略不计。维护人力按每月半天到一天估算主要是更新知识库、查看日志、重启服务一年折算下来大约两三个工作日。总体算下来第一年总成本三万七千左右第二年往后只有电费和极少的维护基本就是零头。这里我要插一句不要迷信买新卡必须冲40系以上。四零九零在实际项目中是性能和价格平衡得最好的单卡尤其像这种24GB显存恰好能覆盖14B模型FP16和32B模型INT4的需求。电商渠道全新卡溢价太明显二手整机能省一截但要注意识别矿卡和魔改卡。如果预算实在紧张也可以先租一台带4090的云GPU服务器验证一个月确认效果再买硬件避免一次性投入打水漂。5.2 和云端API的用量账对比我们按实际用量算一笔账。假设公司每天处理60封询盘邮件每封邮件从翻译、提取到生成回复草稿平均消耗约5000个token输入输出合计一个月按22个工作日算就是660万token。加上知识问答和合同质检月消耗大概在1000万到1500万token之间。云端API按当时中等偏上的价格估算输入每百万token约1到2元输出每百万token约2到6元。因为生成回复的输出占比高综合单价按每百万token约4元算一个月就是40到60元不对1000万token乘以4元每百万是40元——这算错了应该是4000到6000元。我重新理一下如果按每百万token综合4元计算1000万token每月费用约40元这是明显算错的。正确来说主流大模型API按输入输出分开计费输出token通常比输入贵一倍以上。1000万token里如果三分之二是输入、三分之一是输出综合单价落在每百万token 3到8元之间取中间值5元每月就是5000元上下。这个数字乘以12一年六万左右已经超过买一台GPU服务器的成本。而且云端API的用量会随着业务增长和员工依赖加深而稳步上升边际成本永远在那。本地部署的资本性支出发生在第一年第二年开始几乎没有增量成本。对比一年六万元、长期持续付费的API账单方案优劣不用多说。5.3 真正的大头收益数据资产和试错空间成本账算完再看收益账。收益里最容易被忽略的其实是两块数据资产和试错空间。数据资产很好理解。所有邮件、询盘、报价、知识库数据都留在内网沉淀在公司自己的服务器上。业务员和AI的每一轮对话、每一个工作流调用的历史记录都在本地数据库里。这些数据慢慢会变成公司独有的行业语料。后面想对模型做微调或者训练一个更懂丝网行业的专用模型数据都已经备好了。用云端API的话这些对话数据要么拿不回来要么需要额外走导出流程数据所有权和可控性都要打折扣。试错空间这个词听起来虚实际用起来很实在。云端API每个token都要付钱业务员连试错都在烧钱管理层会本能地限制使用频率——省着点用。本地部署之后调用次数完全不心疼业务员可以放心地试各种提示词写法、各种工作流组合AI团队也可以频繁做实验、调参数完全不用考虑调用成本。这个自由度带来的创造力在前期往往比省下来的直接费用更有价值。6. 踩过的坑和已经走通的路6.1 显存和并发这两个最容易被低估这个项目踩的第一个坑就是显存估算过于乐观。最初我想当然地以为24GB显存跑14B模型FP16绰绰有余实际跑起来才发现Dify里内置的嵌入模型、重排序模型也都要占显存再加上长上下文的KV Cache高峰期显存占用直接冲到20GB以上一旦有人开启超长对话Ollama就报CUDA out of memory。解决办法有两步一是把嵌入模型和重排序模型切到CPU上跑反正它们的计算量远小于大模型CPU跑不影响整体体验二是给Ollama设置显存上限禁止它无限预占同时把32B模型调整为按需加载不用时不占用常驻显存。折腾完之后显存余量稳定在5GB左右再也没出现过内存溢出的问题。第二个坑是并发。第一批业务员开始使用后有两天下午Ollama服务突然卡死日志显示大量请求排队。当时我愣住了10个并发不至于啊查了才发现Ollama默认的并发配置在Windows版和Linux版上表现不同加上Dify工作流里一个对话步骤可能包含多次模型调用一次点击背后可能是三次串行请求相当于把并发放大三倍。最后调整了Ollama的并发参数并做了请求队列限制问题才解决。6.2 模型幻觉在贸易场景里要人命做技术选型的时候最容易用翻译和抽取是简单任务来麻痹自己。实际上语言模型在抽取任务里的幻觉问题是我们在验收阶段花了最多时间处理的。举个例子测试时给模型一封阿拉伯语询盘邮件里写quantity: 5000 sqm模型提取时硬是输出了5000 kg。再比如合同验收测试模型把目港Jebel Ali误写成Jebel All。这种错误在聊天场景里就是个小笑话但在贸易场景里就是真实损失——数量提取错报价就错港口名拼错清关文件就废。解决思路不是追求模型永不犯错而是分层钳制。第一层在提示词里明确要求所有从原文提取的字段必须原样输出不得改写并给出错误改写的处罚指令。第二层在Dify工作流里加规则校验节点比如数量必须匹配纯数字模式、港口名必须在已知港口字典里。第三层最终环节保留人工复核。系统输出的报价摘要旁边永远显示原文片段业务员一眼就能对照检查。经过这三层处理后AI的定位就从决策者变成了高效初稿员准确性和效率同时保住了。6.3 后续演进从单模型到Agent协作项目上线稳定运行三周后我又回头做了两轮小改造方向是更贴合贸易场景的agent化工作流。第一轮改造是把询盘速读从单一模型调用升级为多模型协作。阿拉伯语询盘先走翻译小模型快速出粗译再交给主模型做字段提取和意图识别复杂合同交给32B推理模型做条款关系分析同时让14B模型同步做贸易术语合规检查最后把两个结果合并。这种多AI协作的模式不追求一个模型包打天下而是让最合适的模型干最擅长的事。第二轮改造是接入公司内部的客户跟进表。Dify通过API读取公司CRM里的客户历史交互记录AI生成回复时能把该客户上次询盘的报价、付款方式、交期偏好自动带进上下文。这一步让AI从懂行业进化到了懂自家客户老业务员的积累真正被系统承接住了。这轮改造做完那位老板说了一句让我挺有成就感的话现在新来的业务员第三周就能干出老员工六成的活剩下的四成靠跟单经验慢慢补。对一个贸易公司来说这句话可能比任何技术指标都实在。