1. 车间里查一条设备报警，要翻三份资料
某装备制造企业的机加车间有 40 名设备维修工，管着 300 多台机床。每台设备配三份资料：一本 400 多页的使用说明书、一套电气原理图、一张 2000 多条报警代码表，都是 PDF。
新手碰上不认识的报警，得从头翻。查一条代码平均三四分钟，找一张图更久，有时还要把说明书和图纸对着看。这些活里真正需要判断的不多，时间大半花在找资料上。老师傅凭经验能跳过这一步，但他们的依据大多没写下来，新人只能靠问。
设备部想做一个能问的助手，用平板问，比如「E07 报警是什么原因」，它要给出原因、处理步骤，还要指出涉及哪张图纸。这个需求有一条很容易被忽略：不少故障要拍照片，比如配电柜上的指示灯、电机接线盒的接线，维修工想知道照片里那个指示灯代表什么。
车间里还有两条硬约束。一条是平板连的是生产网，上不了外网，要连外网得掏自己的手机；另一条是图纸和工艺参数算公司的核心资产，不能原样发出去。一年里还有一百来次故障，手册和代码表里都查不到，要联系设备厂家才能定下来。
需求交到产品经理手上，第一道关就是选模型。设备部里有人说用能力最强的旗舰模型，也有人说车间上不了外网，得在本机跑一个小模型。两边说的都不算错，卡住的地方是：模型名字里写着的东西，哪些会决定这个场景能不能做成。
模型名字里的差别，哪些会影响这个场景能不能做成，得从它怎么读字说起：这一条直接决定调用一次的成本。
2. 模型的计费单位：按词元而非字数
模型读文本不是按字读的，先要把一句话切成一小块一小块，这个过程叫分词（Tokenization），切出来的每一小块叫词元（Token）。模型看到的、算成本的、算窗口容量的，都是词元。
中文的字和词元不是一对一。一个汉字在 UTF-8 里占 3 个字节，按字节切的分词器碰到没收录过的字，会把一个汉字拆成 2 到 3 个词元；常见字和常用词通常只占 1 个词元。同一个意思换一种写法，词元数能差出一截。下面这几句话说的是同一件事：
| 现场的说法 | 词元数 | 差在哪 |
|---|---|---|
| E07 报警是什么原因 | 14 | 型号加短句，最省 |
| E07 报警是什么原因，主轴温度过高要怎么处理 | 27 | 加了处理要求 |
| E07 报警代码 E07，设备型号 XK-3200B，主轴温度过高，需要怎么处理 | 46 | 型号和编号被拆成多个词元 |
产品和研发算成本、算窗口，用的都是词元，不是字数。 输入按词元计费，输出也按词元计费；上下文窗口装得下多少资料，同样按词元算；用户等多久主要看输出写了多少词元，生成是逐词元往外吐的，写得越长等得越久。
下面这张图把切词元和算账单放在一起。
不同模型的词表不一样，同一句话切出来的词元数也不同。有的模型换了更大的词表，同样一段中文用的词元更少，等于同样的成本能读更多内容。选型时问一句「这个模型切中文大概多少个词元」，比问「它多少参数」更能算出真实成本。
输出那一头更值得盯。用户等的时间主要花在模型往外吐词元上，答一段两百字的处理步骤，输出就有两三百个词元；把回答要求写短一点，比如「只给结论和三条操作」，省下来的时间和成本比换模型还明显。反过来，让它长篇解释，延迟和账单一起涨。
语言之间的效率也不一样。同一个意思，中文、英文、含型号和编号的混合写法，切出来的词元数各不相同，通篇都是型号和英文缩写的提问往往比纯中文更费。算预算时别拿一个通用系数去乘字数，拿几百条真实的现场提问跑一遍，得到的词元分布才是能用的数。
回答里还有两个常被忽略的细节。一个是输出格式：让它按固定字段返回结构化数据，比如分成设备编号、报警代码、处理步骤三段，比让它自由写一段话更费词元，但省掉了后面解析的麻烦，多数场景这笔成本值得付。另一个是让它少写客套话，一句「已为您查询到」没有信息，却在每一次调用里重复计费，把要求直接写进系统提示词（System Prompt）就能省下来。
这一点直接影响需求怎么写。需求里写「支持输入 2000 字」，研发没法换算成容量；改成「单次输入不超过 3000 个词元」，预算和限流都能直接算。同理，「回答不超过 200 字」最好写成「输出不超过 300 个词元」，因为它同时决定了用户等多久和每次调用花多少。
同一个问题三种写法，词元数差三倍
- 现场的说法E07 报警是什么原因
- 词元数14
型号加短句，这种写法最省。
- 现场的说法E07 报警是什么原因，主轴温度过高要怎么处理
- 词元数27
多要一段处理办法，词元数差不多翻一倍。
- 现场的说法E07 报警代码 E07，设备型号 XK-3200B，主轴温度过高，需要怎么处理
- 词元数46
- 多出来的部分型号和编号被拆成好几个词元
同一件事换一种写法，词元数能差三倍多。
- 这一次调用输入 62 个词元，输出 180 个词元
- 单价输入每百万词元 1 元，输出每百万词元 4 元
- 本次合计约 0.0008 元
- 换成本字数的两个问题词元数可能差一倍
算预算别拿字数乘系数，拿几百条真实提问跑一遍。
需求里写词元，不写字数。
3. 参数要分两个数看：总参数和激活参数
模型名字里的数字，比如 1.6T、744B，指的是参数量。B 是十亿，T 是万亿。这个数字过去就等于「模型多大」，现在要分两个数看，因为主流的大模型换了一种结构。
稠密模型（Dense）每次推理都用全部参数。混合专家模型（MoE，Mixture of Experts）把参数分成若干组，每组叫一个专家，每次推理只挑其中一两组算，其余不动。挑哪几组由一个很小的路由器（Router）决定。
举几个开源模型的真实数字。DeepSeek-V4-Pro 是 1.6 万亿总参数、490 亿激活；Kimi K3 是 2.8 万亿参数，896 个专家里每次挑 16 个，合起来 1040 亿激活；GLM-5.2 是 7440 亿总参数、400 亿激活。它们都属于混合专家这一类。总参数决定它能装下多少知识，激活参数决定每次调用要算多少。
同一家的两个同代型号放一起对照，这几个数的关系更直观。Qwen3.6-27B 是稠密结构，270 亿参数每次都算一遍；Qwen3.6-35B-A3B 是混合专家，总参数 350 亿，每次只叫醒其中 30 亿。跑在同样的机器上，快的是后者，每次要算的参数少了将近九成。但快不等于强：稠密那个把全部 270 亿参数都用在这一个词上，单步判断通常更稳；混合专家的本事摊在 350 亿参数里，每次只调 30 亿出来，碰上要一步步推的活，未必比 27B 好。同一个问题谁答得准，得拿自己的题去测。
部署这一头跟直觉反着来。显存装的是全部权重，不是当场激活的那部分：27B 的稠密模型用 4 位精度加载大约占 14 GB，一张 24G 的消费级显卡跑得动；35B-A3B 每次只算 30 亿，权重还是 350 亿，同样 4 位精度要 18 GB 以上。现场设备、单机部署、显存吃紧的场合，先看稠密的同档型号；显存不成问题的云端，混合专家更划算，因为每一次调用便宜。
这两个数能差多少，看上面那组数字就有感觉：总参数是激活参数的十几倍到三十几倍。如果按稠密结构来做，每次调用都得把那一万六千亿个参数全算一遍。混合专家流行的原因就在这儿：参数涨上去，每次调用的算力不用跟着涨。
| 对照项 | 稠密模型（Dense） | 混合专家模型（MoE） |
|---|---|---|
| 每次推理算什么 | 全部参数 | 只算被选中的那几个专家 |
| 名字里的参数 | 就是每次要用的量 | 总参数和激活参数是两个数 |
| 省在哪 | 不适用 | 同样能力下，每次调用的算力小 |
| 贵在哪 | 想更强就得整机加码 | 显存要装得下全部专家，部署门槛高 |
| 部署起来什么感觉 | 简单，多大的模型配多大的卡 | 显存紧张、卡间通信多，但对并发友好 |
用的时候还有一条要记住：混合专家省成本省在调用上，不省在部署上。一个总参数上万亿的模型，权重仍然要全部进显存才能跑起来，本机部署基本不现实，它的用处在云端承接高并发。
显存里还压着另一笔开销，它跟模型大小不是一回事。模型是逐词元往外算的，算到第 10 个词元时，前面 9 个的结果还能接着用，所以它把已经算过的中间结果存下来，这份缓存叫键值缓存（KV Cache）。权重占的是固定的一块，缓存随输入长度涨：同一张卡，输入从几千词元拉到几万词元，缓存就能把剩下的显存吃掉，能同时接待的人数跟着往下掉。有的模型用分组查询注意力（GQA，Grouped Query Attention），让多个查询头共用一组缓存；有的把缓存压缩着存，专门压这一块。部署方案里长输入能撑多少并发，就看这一块。问一句「长输入情况下能同时接待几个」，比问「多少参数」更接近工程师的真实体验。
混合专家不是只有好处。专家的权重全都要放在显存里，模型越大，显存门槛越高；路由器每次挑专家，挑得不均匀就会出现部分专家排队的浪费，所以厂商要在训练时做负载均衡。产品经理不用管怎么均衡，只需要知道一条：混合专家省的是每一次的计算量，不省显存。挑选型方案时，「跑得起来」和「算得便宜」是两个独立的判断。
面对一个具体需求，这一节可以压成三个问题。第一，这个名字里的数字是总参数还是激活参数？说不清就去看模型卡。第二，部署的显存按哪个数算？按总参数算，不是按激活参数。第三，同样的效果下，能不能选稠密的、小一点的型号？稠密模型部署简单，运维上的意外更少。这三问答完，参数那一栏就算填清楚了。
下面这张图说明两种结构算的地方不一样。
4. 模型分类的六个常用维度：通用、开源、参数、推理、多模态、小模型
参数之外，模型名字和型号介绍里还有六类常见的说法。认全这六类，一份候选清单看起来就不像天书了。
| 六类说法 | 它指的是什么 | 产品经理拿它做什么判断 |
|---|---|---|
| 通用还是行业 | 通用模型什么都见过一点；行业模型在某个领域的语料上继续训过 | 行业术语错得离谱时，先看有没有同行在做行业模型 |
| 开源还是闭源 | 开源的权重能下载到自己机器上，闭源的只能用厂商接口 | 数据不能出园区、要本机跑，只能选开源 |
| 参数规模 | 十亿级、百亿级、千亿级，能力台阶大致跟着走 | 只做分类和抽取，选小的；要长篇写作和多步判断，选大的 |
| 推理模型还是普通模型 | 推理模型（Reasoning Model）先想再答，适合多步判断；普通模型张口就答，快而便宜 | 客服话术、故障初判这类要权衡的活用推理；查条款、做抽取用普通就够 |
| 多模态还是纯文本 | 多模态（Multimodal）能读图片、图纸、拍照的现场 | 需求里有照片和图纸，这一条是硬门槛，不能省 |
| 大模型还是小语言模型 | 小语言模型（SLM，Small Language Model）参数小，能装进本机、手机、边缘设备 | 离线、低延迟、数据不出本地这三类需求，先看小模型够不够 |
推理模型这一类最容易多付成本。它答得慢、写得长，输出词元数往往是普通模式的好几倍，费用跟着上去。判断办法很简单：这个问题需要连着推几步、还要权衡取舍，就用推理模式；只是把一段话里的信息抽出来，或者按规则答一句，普通模式更快也更便宜。
现在的模型大多把两种模式塞进同一个型号。Claude 5 默认就开着思考，GPT-5.6 把快速回答和深度推理合成一套自动路由，Gemini 3.x 把思考分成低中高三档让你自己选。选型时不用纠结「有没有推理版本」，要问的是「这个模式能不能单独调用、切一次贵多少」。
判断一个模型带不带推理模式，有三个简单的办法：模型卡或接口文档里有没有单独的思考开关或推理解析字段；接口返回里有没有单独的推理过程字段；拿一道需要多步的计算题试一次，看它输出的是直接答案，还是先给一段推导。三条里中一条，就按推理模型去算它的延迟和费用。
多模态这一条还有一笔账：图片也按词元计费。一张配电柜照片喂进去，模型先把它切成小块、编码成视觉词元，再和文字一起读；分辨率越高、细节越多，视觉词元越多。同一张照片，传原图还是先压到能看清指示灯的尺寸，费用能差几倍。需求里带图时先把「要看什么」定下来：是看一个指示灯的颜色，还是读图纸上的尺寸标注，前者不需要高清。
多模态这一档现在也分大小两头。云端那一头是旗舰型号的标配，参数越大、图上的小字读得越准；本地那一头有专门做小尺寸的，MiniCPM-V 4.6 用 13 亿参数把图片理解放进了手机和边缘设备，官方说它的词元吞吐比同门 8 亿的纯文本型号还快，这个版本已经被 Ollama 收进官方模型库。现场那种拍一张照片问指示灯的需求，本机就够用，不必为了看图去上云端旗舰。
多模态还要认清它能做什么。它能看懂照片里的指示灯亮没亮、能读说明书里的整段文字、能描述图纸上的标注写在哪儿；它做不了的是精确测量和核对数字，图上标的是 320 还是 330，让它读比让人核对更容易出错。带图的需求要拆开写：哪些是「看懂就行」，哪些是「必须精确，交给人或交给结构化系统」。拆不开，就会在验收时扯皮。
行业模型也有两条做法。一条是拿开源模型在行业语料上继续训练，权重自己拿着；另一条是不动模型，把行业资料放进知识库，用提示词约束它的说法。前者贵、周期长，好处是术语和表达习惯进到了模型里；后者便宜、资料随时能改。多数企业的第一步走后者，等到术语错得离谱、样本又攒够了，再考虑前者。
行业模型也有现成的例子。百川现在把重心放在医疗方向，开放权重的型号叫 Baichuan-M3，接口版叫 M3-Plus，官方把定位写得很清楚：只能做辅助，不能替代专业判断。
拿两条真实的名字拆一遍。Qwen3.6-35B-A3B：Qwen3.6 是系列和版本，35B 指总参数 350 亿，A3B 指每次激活 30 亿。DeepSeek-V4-Pro：V4 是版本，Pro 是档位，同一代还排了个 Flash 档，官方说明里写总参数 1.6 万亿、激活 490 亿。名字读得快，是因为拆的都是固定几段；读不懂，多半是各家的命名习惯不统一。碰到不认识的后缀别猜，去模型卡上找那一行的说明。
参数规模也要看同一家族内部的排布。同一个系列会从小排到大：本地能跑的那一档是 Qwen3.6-35B-A3B，总参数 350 亿、激活 30 亿，往上是云端的旗舰，规模不再对外公开。这种排布对选型有用：先用小的在业务题上跑一遍，看出差距再往上加一档，不用一上来就选最大的。真正难判断的是跨厂商比，两家的「80 亿」不是一回事，这要靠业务题去测，不能看名字。
开源和闭源的差别也不只是「能不能下载」。开源模型的权重在你手上，能自己部署、自己改，代价是运维、显存和迭代都归你；闭源模型用接口调用，省事、更新快，代价是版本随时会变、可能下线、数据要经过对方服务器。这里有一个容易被忽略的风险：闭源模型换代之后，同一句提问的回答风格会变，之前调好的提示词和跑出来的评测及格线可能一起失效。所以选闭源也要留一条后路：换代之后先用同一套题回归一遍。
把常见的活按任务类型排一遍，模型要求就清楚了：
| 这类活 | 长什么样 | 对模型的要求 |
|---|---|---|
| 抽取 | 从一段文字里挑出型号、日期、金额 | 小模型够用，看的是格式准不准 |
| 分类与打标 | 判断工单属于哪一类、紧急到什么程度 | 小模型够用，要的是稳定和便宜 |
| 改写与生成 | 把技术描述改成人话、生成话术草稿 | 中等规模，看表达和口吻 |
| 多步判断 | 根据现象推原因、给出处理顺序 | 推理模式，慢和贵得认 |
| 看图理解 | 读图纸、看现场照片、读仪表 | 多模态，还要定清楚「看清到什么程度」 |
| 长文比对 | 两版合同差在哪、几份手册口径是否一致 | 长窗口加检索，先把成本算出来 |
需求到手，第一件事是把活归到这几类里。归错的代价很实在：给「抽取」类需求配一个推理模型，成本翻三倍，效果未必更好。
5. 上下文窗口：一次能读多长，贵在哪
上下文窗口（Context Window）是模型一次能读进来的最大词元数。现在云端旗舰普遍标到 1M：GPT-5.6 写的是 1.05M，Claude 5 和 Gemini 3.1 都是 1M，Meta 的 Llama 4 Scout 更大，标到 10M。能在本地跑的开源型号多在 128K 到 262K 这一档。按中文一个字一到两个词元换算，1M 大约能装下七八十万个汉字，一本 400 页的设备说明书仍装不下两本。标称这么长，日常提问根本用不到，真实的输入往往只有几千个词元。
窗口不够用的后果很具体：会话说长了，最早那几轮被挤出去，维修工前面说过的设备型号就「忘」了；一份长文档直接贴进去，超过窗口的部分根本进不去模型。
长上下文有一个很贵的代价。模型内部的注意力机制（Attention）让每一个词元都和上下文里其他词元建立关联，长度翻一倍，这种配对关系的数量涨到四倍，算力和显存跟着涨。同一段输入从 32K 拉到 128K，计算量大致是 16 倍这个量级，拉到 1M 更是涨到一千倍这个量级。下面这三档是同一份资料在不同长度下的相对开销：
| 一次塞进来的资料 | 相对开销 | 大体相当于多少中文 | 什么时候这么做 |
|---|---|---|---|
| 32K 词元 | 1 倍 | 两万多字，一份操作手册 | 单轮问答，成本最低 |
| 128K 词元 | 16 倍 | 八九万字，三四份手册 | 跨文档比对，偶发使用 |
| 1M 词元 | 1024 倍 | 七八十万字，一整套图纸说明 | 现在旗舰都标这个数，实际项目里很少用满 |
厂商敢标 1M，是因为它们没照这个理论值算账，改用稀疏注意力把这笔开销压下来。DeepSeek-V4 在算注意力之前先把相邻词元压缩一遍，只让一部分位置参与计算；Kimi K3 把历史信息写进固定大小的记忆里，不再让当前词元和全部历史逐个比对；GLM-5.2 让每四层共享一个索引器，官方说 1M 上下文下单次计算的量降到了原来的三分之一左右。产品经理要记住的是结论：窗口标得长不等于用起来便宜，上线前仍然要拿真实的输入词元数算一遍。
长上下文不能替代检索。 就算窗口装得下，资料塞得越满，模型越容易顾此失彼，因为上下文越长，它维持前后一致性的难度越大，这是结构决定的，换个模型也解决不了。工业场景里正确做法是：把说明书切块入库，用检索（Retrieval）只把相关的那几段找出来，再连同问题一起送给模型。窗口留够余量就行，塞满不是优点。
还要分清窗口和记忆。窗口说的是「这一次能读进多少」，不等于它记住了什么。会话关掉，这次读进去的内容就没了，下次再问同一台设备，它还是一张白纸。要跨会话记住，得靠外部的记忆机制把关键信息存下来，下次重新塞回窗口。
真实项目里很少把窗口吃满。一条提问配几段检索出来的说明书，输入通常在几千到两万词元之间，窗口这条写 32K 就够用。把窗口当容量指标去比大小，容易比出一个用不上也用不起的数；把它当成本指标看，动作才对：能检索就别整篇塞，能少给两段就别给五段。
和检索配合时，产品经理要定的是三件事：一份资料切成多大、切块之间要不要重叠、一次取几段。切得太大，一段里混着好几条规则，模型会挑错；切得太小，一句话被劈成两半，规则读不全。这几件事没有通用值，做法是拿那 200 条真实提问去调，看哪一组参数下答对率最高、平均取回来的段落最少。段落越少，词元越少，成本也越低。
6. 设备说明书问答这个场景选定的模型
回到车间那个助手。把前面讲的四件事一条条对到这个需求上，每一条都能落到一个具体的模型指标。
| 需求里的那句话 | 落到哪一层 | 结论 |
|---|---|---|
| 维修工会拍照问指示灯 | 多模态 | 选能读图的模型，纯文本模型这一条直接出局 |
| 说明书 400 多页，车间里要问答 | 上下文长度 | 单靠长窗口不划算，走切块加检索，窗口 32K 就够 |
| 「E07 是什么原因、怎么处理」 | 推理模式 | 故障判断走推理模式，简单查条款走普通模式，两档路由 |
| 车间上不了外网，图纸不能原样发出去 | 开源还是闭源、参数规模 | 本机部署只能选开源小模型，云端那一套进不来 |
四条一起看，结论就出来了：车间这一端用本机的开源小语言模型，接一个切块检索，处理查条款、查代码、简单问答；遇到要权衡、要引用图纸的复杂问题，把资料脱敏之后送到云端的多模态模型，用完把结论回传。两边的口径用同一套题对齐。
三个候选方案摆在一起是这样：
| 方案 | 离线可用 | 能读图纸照片 | 多步故障判断 | 每月成本 | 能承接的车间提问 |
|---|---|---|---|---|---|
| 本机小语言模型 | 是 | 否 | 弱 | 1200 元 | 55% |
| 云端多模态模型 | 否 | 是 | 强 | 4800 元 | 88% |
| 本机加云端混用 | 是 | 是 | 强 | 2600 元 | 92% |
单看能力，云端那一列最好；单看离线，本机那一列过关。混用这一列两头都占，多出来的成本只落在少数复杂问题上，这也是这个案例最后选的方案。
定完这四条，还有一件事没做：拿什么验。选型最后要交出去的是一套答案，配上自己的题验过的结果，光挑一个模型交不了差。做法是从维修记录里挑 200 条真实提问，按四类分开：查报警代码、查操作步骤、带照片问指示灯、需要多步判断的复杂故障。四类的验收标准不一样：查代码看答得对不对，查步骤看有没有漏掉前提条件，带图的看有没有把图上根本没有的部件说进去，复杂故障看处理顺序对不对。四类各跑一遍，把分数贴在同一张表上，再决定哪一档模型够用、哪一类问题要送到云端。
还有两个兜底动作要写进需求。一个是答不出的时候怎么办：检索没命中，或者模型自己说「资料里没有」，页面要给一条明确的出口，比如一个「转人工」按钮，而不是让模型硬编一段。另一个是留痕：每次问答存下问题、命中的段落编号、给出的答案和处理人，出了事能回查是哪一环出的问题。这两条不写清，上线之后第一次答错就会扯到责任上。
三条部署路线，拿四个条件筛一遍
本机小模型
- 离线可用是
- 能读图纸照片否
- 多步故障判断弱
- 每月成本1200 元
- 覆盖率55%
- 验收集200 条真实维修提问，分四类：查报警代码、查操作步骤、带照片问指示灯、需要多步判断的复杂故障
读图这一条把它筛掉，现场有一批问题是带照片问指示灯。
云端多模态模型
- 离线可用否
- 能读图纸照片是
- 多步故障判断强
- 每月成本4800 元
- 覆盖率88%
离线这一条把它筛掉，车间上不了外网，有 12% 的提问发不出去。
本机加云端混用
- 离线可用是
- 能读图纸照片是
- 多步故障判断强
- 每月成本2600 元
- 覆盖率92%
- 走云端的那一档只用在复杂故障上，占全部提问的 14%
三个条件都满足，贵的那一档只落在少数复杂故障上。
先把做不到的条件筛掉，再用成本定档。
7. 设备说明书问答场景的八栏选型表
车间那个助手是拿四条硬条件筛出来的。换成别的需求，四条不一定够用，把动作拆细一点：列一张表，每一栏都逼自己填上依据，讨论就不会卡在「我觉得这个更强」。刚才那三条方案，就是照这张表一栏一栏填出来的。
| 要填的栏 | 怎么填 |
|---|---|
| 这份活的输入是什么 | 纯文字、文字加照片，还是整份文档；照片要看清到什么程度 |
| 一次要读进多少 | 单轮提问多少词元，需要跨文档比对时多少词元 |
| 要不要多步判断 | 要拆几步、要不要权衡取舍；只做抽取就填「不要」 |
| 输出要多长 | 一两句话，还是三段带操作步骤；这一问直接决定延迟和费用 |
| 跑在哪 | 云端接口、单位的私有化机房、现场设备，三选一 |
| 数据能不能出去 | 出不去就只看开源模型，出得去才有云端可选 |
| 成本按哪一档算 | 按每次调用算，还是按每月固定算，两笔都要写出来 |
| 拿什么验 | 用多少条真实提问测、几条算过关 |
这张表里，砍候选最狠的是「跑在哪」和「数据能不能出去」这两栏，通常一眼就能去掉一半。车间那台平板跑不了千亿参数的大模型，图纸不能原样出厂房就只剩开源权重可选，车间那个案例就是卡在这两栏上。
坑最多的是「输出要多长」这一问。它看着像体验问题，实际是算成本的问题。同一个模型，答案从一段话改成三大段带步骤，输出词元可能翻三倍，延迟和账单一起翻。需求里写「回答要详细」，等于把成本交给模型自己决定。
这张表也不是填完就锁死。模型三个月就换一代，价格也在动，写死一版等于半年后就过时。按活的记录来管：表头写清谁填的、什么时候填的、依据的是哪一次评测；模型换代、价格调整，或者业务题上的分数掉了，就重填对应的那几栏。能力和成本那几栏由产品经理牵头，部署那一栏拉着研发一起过。
8. 模型分类与选型中的三个常见误解
参数规模被当成唯一标准，是最贵的一种错。参数大通常能力更强，代价是更贵、更慢、部署要求更高。查条款、做抽取、给工单分类这类活，小模型往往够用，省下的成本够把评测做扎实。判断办法是拿几百条真实提问在大小两档上各跑一遍，差距落在误差范围内就选小的那一档。
总参数很容易被当成每次都要跑的量。看到「1.6 万亿参数」就判定用不起，是没分清总参数和激活参数；反过来，看到激活参数只有 490 亿就以为本机能跑，是没算上权重全都要进显存这件事。前一个数影响每次调用的账单，后一件事影响能不能部署得起来。
窗口够长，也不等于能把所有资料塞进去。「我们有很长的上下文，知识库可以不要了」这句话，错在把「读得进」当成了「读得准」：窗口塞满不只贵，还会让模型抓不住重点，检索这一层依然省不掉。
这三条错法都出在同一个顺序上：先把模型挑好，再回头想场景能不能对上。
9. 拿到一个模型名，当场能说出什么
拿到一条模型名字，你该能说出四件事：它按什么切字、参数是哪两个数、属于哪几类、一次能读多长。这四件事决定了它在你的活里能不能用、大概多贵。
还有一组能直接说出口的话，方便你带着去开会：跟研发讨论时说「这个需求要读图纸，纯文本模型不行，得走多模态，成本按每张图多少个词元算」；跟财务算预算时说「我们按每次调用多少词元、每月多少并发来算，不按参数规模算」。这两句说不顺，说明那张选型表还差几个问题没回答。
车间那个案例只用到这张表的一部分。剩下几栏还要讲：候选清单从哪来，榜单和跑分能信到什么程度，开源许可里哪些限制会挡住商用，以及同时摆着几档模型时怎么分工。这几件事下一份材料接着讲。