1. 一批工艺图纸，卡在出不出园区
一家做非标装备的制造企业，工艺科有六名工艺工程师。他们手上最费时间的一件活是给外协加工厂做工艺交底。外协厂问一批零件怎么做，工程师得翻三样东西：图纸上的尺寸公差和材料牌号；工艺卡上的热处理参数；这张图纸以前改过哪几版。三样凑齐，写成一份交底说明发出去，平均四十分钟。一个人一周要做十几次。
工艺科想把这件事做成一个能问答的智能体。方案报到 IT 那边，第一个问题就卡住了：这套东西放哪儿跑。
厂长给了一条硬规定，图纸和工艺参数不出园区。这句话把所有「把资料打包传给公网模型」的方案直接划掉了。剩下的路看起来只有两条：在厂里的机器上装一个模型，或者买一套能装进园区、由厂商远程代管的方案。工艺科手上现有两台带 24G 显卡的工作站，编制里没有专职运维。
放哪儿跑只是第一道关。第二道关是成本：一次交底大概要多少费用，一天几十次下来账单是多少。这两件事不先弄清楚，方案连立项会都上不去。
2. 部署方案的两个维度：数据边界与运维责任
问「放哪儿跑」的时候，很多人把两件不相干的事混成一件：数据要不要送出单位，和这套东西归谁管。这两件事各有各的选项，交叉起来才是完整的方案。
2.1 第一个维度：数据边界
按数据边界分，有四种做法。
数据全留在用户设备上，对应本地运行（Local）。模型装在工程师自己的电脑里，请求不出这台机器，断网也能用。
数据全留在单位内网，对应私有化部署（On-premises）。模型和应用装在单位自己的机房或专有环境里，请求和数据都不出内网。
数据有一部分会送到厂商那边，对应混合部署（Hybrid）。敏感的那部分留在内网，不敏感的或者要求高的那部分走厂商的模型。
数据直接送到厂商机房，对应云端运行（Cloud）。单位不装机器，通过接口调用厂商的模型。
还有一类要单独提：端侧运行（On-device）。模型直接跑在手机、平板、工控机这类设备本身，比本地运行的机器更小、限制更紧。车间里用平板查设备手册，走的就是这一类。
2.2 第二个维度：运维责任
按运维责任分，也是三种做法。
自己管，对应自托管（Self-hosted）。机器是单位的，模型版本、升级节奏、扩容、备份都由单位自己排人。
厂商管，对应厂商托管（Vendor-managed）。单位买的是服务，机器在谁那儿、模型怎么升级，单位都不用操心。
一部分自己管、一部分厂商管，就是混合部署在运维这一面的样子。
2.3 数据边界与运维责任交叉的完整方案
把两个维度摊成一张表，常见的组合有五种。
| 组合 | 数据边界 | 谁管 | 典型场合 |
|---|---|---|---|
| 每人电脑上装一个模型 | 全在用户设备上 | 用户自己 | 单人在离线环境里查资料，不联网也能干活 |
| 单位内网装一套，自己管 | 全在单位内网 | 单位自己的运维 | 图纸、病历这类资料不能出内网，多人共用 |
| 单位内网装一套，厂商远程代管 | 全在单位内网 | 厂商代管 | 内网有硬要求，单位又没有运维人手 |
| 内网小模型加云端大模型 | 敏感的留在内网，一般的送出去 | 两边各管一部分 | 大部分活本地够用，少数难题要好模型 |
| 直接调厂商接口 | 数据送到厂商机房 | 厂商 | 没有出域限制的场景 |
数据出不出单位，是这四个选项里最硬的一条。 别的条件都可以商量，这一条谈不拢，方案就得整个换方向。
| 数据边界 | 谁管 |
|---|---|
| 全在用户设备上（Local） | 用户自己 |
| 全在单位内网（On-premises） | 单位自己的运维 |
| 一部分在单位内网（Hybrid） | 两边各管一部分 |
| 送到厂商机房（Cloud） | 厂商（Vendor） |
四种形态的名字：本地运行、私有化部署、混合部署、云端运行。
图注：左边一列管「能不能用」，右边一列管「谁来干」；两列各挑一条，就是一个完整的部署方案。
3. 本地、端侧、云端三种运行形态的适用场合
两个维度分开之后，再回头看三种跑法的脾气。
3.1 本地运行：数据不出设备，能力有上限
本地运行最大的好处是数据不出这台设备。工程师电脑里的图纸、客户名单、内部口径，一个字都不用离开机器；断网也能干活，反复调试也不产生费用。
代价有四条。能装的模型小，受显卡显存和内存限制，通常只能上小模型或者压过精度的版本，碰上要一步步推的难题会明显弱一些。并发低，一台机器一般服务一两个人，第三个人同时在用就开始排队。更新要自己动手，模型文件几个 GB 到几十 GB，怎么发到每台机器上、怎么保证版本一致，是新的运维麻烦。还有一条最容易被忽略：模型一加载，显卡显存就被占住，这台机器上别的重活就跑不动了。
3.2 端侧运行：装在设备上，便于随时使用
端侧运行把模型直接放进手机、平板、工控机里。模型规模通常在几十亿参数以内，管的是拍照识别、语音输入、离线查手册这类事。
好处是随时随地能用、完全不依赖网络、响应快。代价是能力上限低，还吃电量和存储空间。它适合的场景很集中：工人在车间里举着平板拍一张配电柜照片，问这个指示灯是什么意思，这种活云端也能做，但现场网络未必靠得住。
3.3 云端运行：能力上限最高，费用随用量变化
云端运行把机器的事全交给厂商。能力上限最高，随时能换更新的型号，按用量计费，不用买卡也不用管运维。
代价有两处。一是数据要出单位，除非买的是部署在你自己机房里的托管实例。二是单价随用量走，用量一涨账单跟着涨，厂商调价你也得跟着调预算。
4. 开源模型的硬约束：显存、并发与吞吐
厂里那两台工作站能不能扛住工艺科六个人的日常使用，要算三笔账：显存装得下吗、能同时几个人用、答得够快吗。这三笔账都由开源模型的物理条件决定，跟模型聪不聪明是两回事。
4.1 模型显存占用的三个组成部分
模型加载进显卡，显存里占着三块。
第一块是权重，也就是参数本身。它的大小等于参数量乘以每个参数占几个字节。同样一个模型，精度降一档，字节数就少一档：16 位精度每个参数占 2 个字节，8 位占 1 个，4 位大约 0.5 个。270 亿参数的模型，16 位要 54 GB，8 位要 27 GB，4 位只要 14.2 GB。这一块是固定的，模型装进去就不再变。
第二块是键值缓存（KV Cache）。它随对话变长、随同时在用的人变多而涨，是活的。这块后面单独说。
第三块是推理框架自己占的一两个 GB，还有系统留的余量。
4.2 并发一上来，显存就不够用了
一个人用和六个人同时用，是两套账。
权重只装一份，六个人共用。键值缓存不是，每一路正在进行的对话都要占一份自己的。同时用的人越多、每路对话越长，这一块涨得越快。量级上可以这么估：200 多亿参数的模型、缓存压到 8 位，每一路并发、每一万词元上下文大约占 1 GB。八路并发、每路八千词元上下文，光缓存就要六到八个 GB。
算到这里，那台 24G 的工作站就有答案了。4 位权重的 270 亿模型占 14.2 GB，加上八路并发的缓存 6 到 8 GB，再算上框架自己的一两个 GB，总共 22 到 24 GB，卡在边界上。把并发收到四路，缓存降到三四个 GB，总占用落回 20 GB 上下，这台机器才稳。
所以私有化部署时，「能同时支撑多少人」卡住的地方多半在显存，不在模型算力。
并发开到几路，显存就撑不住了
- 权重4 位精度的 270 亿模型占 14.2 GB
- 键值缓存3 到 4 GB
- 框架自己1 到 2 GB
- 合计20 GB 上下
并发收到四路，这台 24G 的机器站得住。
- 键值缓存涨到 6 到 8 GB
- 合计22 到 24 GB，卡在边界上
- 量级的口径200 多亿参数的模型、缓存压到 8 位，每一路并发、每一万词元上下文大约占 1 GB
人数一上去，吃紧的是缓存，不是算力。
- 键值缓存12 到 16 GB
- 合计超过 24 GB，装不下
- 两条出路把每路对话压到八千词元以内，或者换一张 80G 的卡
每路对话越长，这一路占得越多。
- 权重仍是 14.2 GB
- 留给缓存的空间放宽到二十路以上的并发
并发上限跟着显存走，不跟着参数量走。
私有化部署报并发，要报的是显存账。
4.3 吞吐量决定模型的响应速度
显存决定装不装得下，吞吐决定好不好用。吞吐看两个数：第一个词元要等多久，后面每秒能吐出多少个词元。
单张消费级显卡跑 200 多亿参数的模型，输出速度大约在每秒几十个词元的量级，读起来像有人在打字。多人排队的时候，第二个人要等第一个人说完才轮得到，等待时间跟着并发数往上走。真要在厂里给六个人用，就得把「一次交底几个人在同时问、最多等多久」写进需求，让研发按这个去配并发和队列。
5. 自建与托管的分界线
显存和吞吐算的是「能不能跑」，接下来要算的是「该不该自己跑」。
5.1 自建与托管的判断顺序
判断有先后顺序，前一条过不了，后面的不用比。
先看数据能不能出单位。不能出，方案里就只剩本地运行、私有化部署、混合部署这三条，云端运行直接划掉。这是硬约束，不用比价。
再看有没有人管。自托管要自己管的事有一串：模型文件、推理框架、显卡驱动、版本升级、备份恢复，每一项都要排人。编制里没有运维，就别选纯自托管，宁可买厂商代管的私有化方案，数据还是不出内网，运维的活外包出去。
然后看用量。使用密度低的时候，自己买机器是拿一笔固定投入去摊很少的用量；用量大而稳定，这笔固定投入才摊得平。判断口径可以这么定：一次任务如果一天只跑几十次，托管更合适；如果一天要跑几千次，才值得把机器买回来。
最后看能力要求。能装进单位机房的模型，能力一般不如厂商机房里最新的旗舰模型。要求高的活（长文档推理、复杂多步判断），如果数据允许出域，走云端更划算。
5.2 不同行业，差别落在数据边界上
这条线上的行业差别落在这批数据能不能出门上，跟选哪个模型关系不大。
金融和医疗最紧。客户资料、交易记录、病历都受严格约束，多数情况下只能走私有化部署或者本地运行。政务次之，政务数据一般不出内网，但口径统一比数据边界更容易出问题。制造和能源的约束来自资产本身，图纸、工艺参数、生产数据是核心资产，厂里通常一刀切不让出园区。零售电商松得多，公开的商品信息、售后话术、活动政策，走云端没有障碍。
6. 一次任务的成本构成
放哪儿跑定下来之后，账要算到「一次任务多少费用」这一层，因为预算和验收都盯这个数。
6.1 计费单价的两个口径：输入与输出
云端按词元计费，输入和输出的价格不一样，输出通常更贵。同一家的不同型号差价也很大。
| 型号 | 输入单价（元／百万词元） | 输出单价（元／百万词元） | 缓存命中输入（元／百万词元） |
|---|---|---|---|
| deepseek-flash | 1 | 4 | 0.02 |
| deepseek-v4-pro | 4.5 | 13.5 | 按厂商当页口径 |
| qwen3.8-max | 12 | 36 | 按厂商当页口径 |
同一件事，换一个型号，费用能差到十倍以上。这就是为什么选型和成本要一起看，不能等效果都调好了再去问价钱。
6.2 一次任务的总成本：逐轮输入累加
一问一答只算一次输入。智能体不是，它转了好几轮，每一轮都要把前面的对话连同新查到的资料重新发一遍。第一轮发过的内容，第二轮要再发一次，第三轮还要再发一次。
所以一次任务的总账是这么算的：
一次任务的总成本 = 每一轮的输入词元 × 输入单价，逐轮累加 ＋ 每一轮的输出词元 × 输出单价，逐轮累加 ＋ 工具调用和检索那一部分的费用。
拿工艺交底那件事算一遍。一次交底智能体转了四轮，出资料、比对公差、核对热处理参数、组织答复，四轮输入分别是 2.4 万、2.8 万、3.2 万、3.6 万词元，加起来 12 万；输出加起来 1200 词元。用 deepseek-flash：
输入 12 万词元，按每百万 1 元算，0.12 元；输出 1200 词元，按每百万 4 元算，不到 0.005 元。一次约 0.13 元，一天按 300 次算，一天约 37.5 元。
自建那条路的账不一样。机器是固定资产，成本摊在折旧上，一次任务不再产生词元费用，但机器闲着也在折旧，电费照交。所以自建划不划算，看的是一天跑多少次，不是一次多少钱。
一次工艺交底，四轮的账挨轮累加
- 第一轮 出资料输入 2.4 万词元，输出 200
- 第二轮 比对公差输入 2.8 万词元，输出 300
- 第三轮 核对热处理参数输入 3.2 万词元，输出 300
- 第四轮 组织答复输入 3.6 万词元，输出 400
最后一轮输入 3.6 万，比第一轮的 2.4 万还多，前面的资料被反复带上。
- 单价输入每百万 1 元、输出每百万 4 元
- 输入累计 12 万词元折 0.12 元输出累计 1200 词元不到 0.005 元 · 合计约 0.13 元
- 一天按 300 次算约 37.5 元
输入那一头是大头，每轮都要重新付。
- 命中缓存的 10 万词元输入那一段从 0.12 元掉到 0.022 元
- 合计约 0.03 元一天约 8.1 元
稳定前缀命中缓存，一天从 37.5 元掉到 8.1 元。
- 换 deepseek-v4-pro输入每百万 4.5 元、输出每百万 13.5 元，合计约 0.56 元，一天约 169 元
- 换 qwen3.8-max输入每百万 12 元、输出每百万 36 元，合计约 1.48 元，一天约 445 元
- 自建那条路机器是固定资产，一次任务不再产生词元费用，机器闲着也在折旧，电费照交
自建划不划算要看一天跑多少次，不看一次多少钱。
自建划不划算要看一天跑多少次，不看一次多少钱。
6.3 一次任务中容易被忽略的其他费用
词元费不是账单的全部。工具调用、知识库检索、向量库存储、文件解析，这些各有各的费用或者资源占用；私有化那一边则是机架、电费、运维人力。做预算的时候，这些要一起报，只报词元单价，后面容易在评审会上被问住。
另外一条：词元的量是估出来的，估错的代价不小。转几轮、每轮带多少资料，都会成倍地影响账单。写在需求里的成本预估，最好写成一个区间，再写清按什么假设算的。
7. 降低成本的五条手段
账单算出来之后，才知道该从哪里下手。这五条是行业里用得最多的。
7.1 提示词缓存
每一轮都会重复发送的那部分内容，比如系统提示词、固定的资料片段，第一次发过去之后在厂商那边缓存住，后面再发就按缓存价计费。deepseek-flash 上，缓存命中的输入单价是每百万词元 0.02 元，普通输入是 1 元，差五十倍。凡是系统提示词长、资料固定、对话轮数多的场景，这一条省得最多。
7.2 语义缓存
问题意思差不多，就直接把上一次的答案取出来，根本不发给模型。办事指南、售后政策这类口径固定的问答，命中率能很高。
用之前要定一条规则：政策改了，对应的缓存必须同时失效。没有这条规则，客户问的是今年 3 月的退换政策，答出来的是去年 12 月的。
7.3 模型路由
简单的问题交给便宜的小模型，难的问题才送去贵的旗舰模型。同一家的两档型号，单价差十倍是常事。什么算简单、什么算难，要靠自己攒的评测集去定，不能凭感觉分。
7.4 批处理
把一批请求攒起来一次性提交，这种接口按行业通行的做法是半价计费，代价是结果不保证马上出来。适合不着急的活：批量生成工艺卡、批量归档历史交底、批量给文档打标签。实时问答用不了这一条。
7.5 上下文裁剪
轮数一多，历史里堆着大量用不上的中间过程。把这些裁掉，只留下结论和还需要的资料，后面每一轮的输入都会跟着变小。这是这五条里唯一不依赖厂商支持、也不需要额外组件的一条，成本最低，效果也最容易被低估。
8. 工艺交底这个场景选定的部署方式
把那两条路都摆出来比一遍。
云端调用第一个出局，图纸和工艺参数不出园区，这条硬约束不需要再算别的。
混合部署也出局。看着是「一般问题走云端」，可工艺问答的输入里全是图纸尺寸和材料牌号，一般的问题里也夹着工艺参数，哪一部分能出门很难逐条判干净。
每人电脑上装一个本地运行的小模型也出局。工艺科没有运维人手，六台机器六个版本，发模型和更新模型本身就成了新负担；而且单机只能服务本人，别的活一来就把显存占了。
最后定的是：园区内网装一套私有化部署，跑 4 位精度的 270 亿参数模型，权重 14.2 GB；并发定在四路，缓存按每路每万词元约 1 GB 估，三四个 GB；再算上框架和系统余量，总占用落在 20 GB 上下，那台 24G 的工作站装得下，还留了四个 GB 左右的余量，另一台做备用。模型由厂商远程代管升级，数据不出内网。
落到效果上，一次工艺交底从四十分钟压到八分钟左右，工程师只做最后一遍核对。这个案例的部署与成本口径，收在辅文档《运行与成本方案表》里，可以直接拿去填自己单位的场景。
9. 交出去之前，部署方案先过这六条
9.1 部署方案定稿的六个待答
- 这批数据能不能出单位？不能出，云端那条路直接划掉。
- 一天大概跑多少次、同时几个人用？这两个数决定选托管还是买机器。
- 单位里有没有人管模型和显卡？没有，就别选纯自托管。
- 一次任务能接受等多久？答案决定并发配多少、要不要排队。
- 一次任务大概转几轮、每轮的输入多少词元？估不出这两个数，成本预估就是空话。
- 这套东西的账单谁来盯、按什么口径盯？没人盯，用法一放开费用就失控。
六个问题里有一个答不上来，这件事就还没到能报价的程度。
9.2 部署与成本中的三个常见误解
一个是把数据边界和运维责任混成一件事，问「本地还是私有化」，其实这两个词回答的是两个不同的选项。分开看之后，才能凑出「数据不出内网、厂商远程代管」这种本来很常见的方案。
一个是只看单价，不算一次任务的总账。每百万词元 1 元听着便宜，可四轮下来输入被算了四次，真实费用是单轮的四倍。
还有一个是凭感觉判断私有化贵还是便宜。私有化是一笔固定投入，用得越密越划算；一天跑几十次就买机器，摊到每次任务上的成本比云端高得多。这个判断要看使用密度，不能看直觉。
10. 部署方案和账单，看完能自己算
一件事是分清两个维度。拿到一个需求，能说出数据边界定在哪、运维责任归谁，而不是笼统地问一句「本地还是云上」。
二件事是算得出显存和账单。给定模型规模、精度、并发人数，能估出显存装不装得下；给定轮数和输入量，能估出一次任务的费用和一天的账单。
这一份要交出的是选得出部署方案。数据不能出单位、没有运维人手、一天几十次，这三个条件凑在一起，方案该长什么样，能当场说出来。
下一份材料开始讲外壳工程，也就是围着大模型的那些部件：八件各管什么，装上以后大模型能干什么，市面上的平台长什么样。这一份先把外壳工程整体认下来，后面的材料再一件一件展开。