想象你是一位饭局主理人，要为一群口味各异、预算不同的客人张罗宴席：有三五老友的便饭，有重要客户的商务晚宴，也有老饕的私房品鉴会。你手下的候选厨师来自天南海北——米其林三星主厨、街角私房菜高手、刚出师的年轻学徒。聪明的做法，绝不是顿顿都请最贵的大厨：既烧钱，又让家常菜显得小题大做；也不是哪家便宜请哪家——万一端上来的菜难以下咽，客人照样翻脸。 这个场景，正是大模型应用开发里的“模型选择”。每个 LLM 都是一位厨师：效果是厨艺，Token 成本是菜价，时延是上菜速度。选对模型，同样预算能服务更多用户，效果不掉线，成本甚至能省一半；选错模型，要么钱包失血，要么口碑翻车。这篇文章就带你走一遍完整的“选厨师”流程：认厨师（主流模型能力）、试菜（评测方法）、算菜钱（成本构成）、画性价比四象限（成本效果矩阵）、按客人点菜（任务匹配）、定菜单并持续复考（选型流程与追踪）。

岗位关联

学模型选择，是把 AI 应用从“能跑通”推向“能赚钱”的关键一跃——同样功能，选对模型可省一半成本，这是每个 LLM 从业者的核心 ROI 技能。

目录
  1. 可视化演示
  2. 一、认得清：主流模型能力地图
  3. 二、评得准：模型评测方法论
  4. 三、算得清：Token 与成本构成
  5. 四、衡得对：成本效果权衡矩阵
  6. 五、配得巧：任务类型模型匹配
  7. 六、选得稳：科学选型决策流程
  8. 七、盯得住：效果持续追踪
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示主流LLM能力对比雷达图、成本-效果权衡矩阵散点图、模型路由混合部署策略。切换模式探索如何选对LLM省一半成本。

本节配有交互动效（进入视口后自动加载，约 3KB）。

主流LLM能力对比与评测 GPT-4o推理与通用任务强劲，Claude长文本理解优势，Llama开源可本地部署 评测维度：MMLU多任务理解、HumanEval代码生成、GSM8K数学推理 capability = reasoning + coding + math + context 选对模型需要多维度能力对比

一、认得清：主流模型能力地图

办一场饭局前，主理人心里得有本“厨师册子”：谁擅长川菜、谁是甜品大师、谁能一口气做二十道菜的流水席。你不可能只认识一个米其林大厨就搞定所有局，也不可能指望新手厨师撑起商务晚宴。先摸清候选厨师各有几把刷子，点菜时才不会手足无措。

大模型世界的“厨师册子”就是主流模型的能力地图。模型选择的第一步不是打开价格表，而是把市面上的 LLM 分为几大家族：闭源旗舰、开源阵营，以及各自的长板与短板。这张地图决定了后面所有筛选的范围。

目前能力地图上有三大坐标。第一，闭源旗舰——GPT-4o、Claude 3.5 等，综合能力最强、工具生态最完善，但价格和封闭性是代价；第二，开源阵营——Qwen、DeepSeek-R1、Llama 3.1 等，可自部署、可微调、数据不出域，效果已逼近旗舰；第三，上下文窗口从 8K 到 200K token 不等，长文本场景要格外关注。此外各家有专长：R1 擅长复杂推理，Kimi 与 GLM 主打长文本，Qwen 中文更稳。把这些维度合成一个可比较的“能力分”，选型才有的放矢。

有了这张能力地图，就像主理人手里多了一本写满拿手菜和短板的花名册。接下来要做的，就是把这些厨师请进后厨，真刀真枪地试菜——这就是评测。

Sm=∑i=1nwi⋅sm,i\displaystyle S_m = \sum_{i=1}^{n} w_i \cdot s_{m,i}
S_m 是模型 m 的加权能力综合分：每一项能力按重要性乘以权重后相加，得到一张横跨各家的“打分表”。
  1. S_m —— 综合能力分给模型 m 打的“总能力分”，用于把各家模型放到同一把尺子上比较。
    SmS_m
  2. 求和符号把 n 项能力的得分逐一累加，表示“总分由各项能力共同构成”。
    ∑i=1n\sum_{i=1}^{n}
  3. 权重 w_i第 i 项能力（推理、代码、中文等）在业务中的重要性比例，全部权重相加等于 1。
    wiw_i
  4. 单项得分 s_{m,i}模型 m 在第 i 项能力上的归一化得分，取值 0 到 1，越高代表越擅长。
    sm,is_{m,i}

二、评得准：模型评测方法论

菜谱和名气都不可全信，真正的高手敢让客人盲吃盲评。主理人请厨师试菜时，会偷偷把每道菜编号，不让客人知道是哪位厨师做的，吃完按“色香味”打分。这样评出来的分数，才不会被名气绑架。

模型评测同样讲究“盲测”和“多级可信度”。光看厂商公布的成绩单远远不够，需要一套从粗到细的评测阶梯。

评测有三层阶梯。第一层，公开基准——MMLU、HumanEval、GSM8K 等，覆盖知识、代码、数学，适合快速横向粗筛；第二层，人工评测——让标注员盲测回答质量，捕捉主观体验（语气、条理、稳定性）；第三层，业务实测——拿你自己的真实 Prompt 和业务数据跑一遍，请真实用户或专家打分，这是最可信的一层。解读指标时还要当心“测试集污染”：基准题目若混进训练数据，分数会虚高。看相对提升比看绝对分更能说明差距。

试菜有了固定流程和打分标准，主理人就能在几位候选厨师之间排出座次。但菜好不好吃是一回事，这桌席花多少钱是另一回事——下一节就来算菜钱。

R=Enew−EbaseEbase×100%\displaystyle R = \frac{E_{new} - E_{base}}{E_{base}} \times 100\%
R 是新模型相对基线的提升百分比：把“多出来的效果”除以“原来的效果”，避免不同基准难度不同导致的误读。
  1. E_new —— 新模型效果分待评估模型在某个评测集上的得分，通常是准确率或通过率。
    EnewE_{new}
  2. E_base —— 基线模型效果分选定的参照模型（如当前生产模型）在同一评测集上的得分。
    EbaseE_{base}
  3. 差值与比值先算出提升量 E_new − E_base，再除以基线得分，得到“相对提升了百分之几”。
    Enew−EbaseEbase\frac{E_{new} - E_{base}}{E_{base}}
  4. 乘以 100%把小数比值换算成直观的百分比，便于汇报与对比。
    ×100%\times 100\%

三、算得清：Token 与成本构成

点菜时最怕“只问单价不问分量”。一份松露 300 元很贵，但只点一小碟；一份麻婆豆腐 38 元很便宜，却连点三盘还配两碗米饭，结账时照样肉疼。LLM 的成本也取决于“单价 × 数量”，而那个“数量单位”就是 Token。

Token 是模型读写文字的最小计量单位，大约一个汉字对应 0.6~2 个 Token，一个英文单词约 1~2 个。每次调用都要把 Prompt 全部折算成 Token 计费，输出部分尤其昂贵。

成本构成可拆成四块。第一，Token 计费——几乎所有 API 都按“每千 Token 多少钱”结算；第二，输入输出定价——输出单价通常是输入的 3~4 倍，因为生成 Token 更耗算力；第三，折扣渠道——缓存命中、批量处理（batch API）能省 50%~75%；第四，隐形成本——若自部署开源模型，GPU 采购、电力、运维工程师的工资都要算进去，流量低时反而更贵。只盯单价不看用量，预算必超支。

把每道菜的单价和分量都算清楚后，主理人心里有了一本账。下一个问题是：用一份钱的菜钱，能换来多少“好吃”？这就是性价比四象限。

C=Tin×Pin+Tout×Pout1000\displaystyle C = \frac{T_{in} \times P_{in} + T_{out} \times P_{out}}{1000}
C 是单次调用的成本：输入 Token 数乘输入单价，加上输出 Token 数乘输出单价，再除以 1000 换算成“每千 Token”。
  1. T_in —— 输入 Token 数发送给模型的 Prompt 折算成的 Token 总量，越长越贵。
    TinT_{in}
  2. P_in —— 输入单价每 1000 个输入 Token 的价格（元）。
    PinP_{in}
  3. T_out 与 P_out模型生成的回复 Token 数及其每千 Token 单价，输出单价通常数倍于输入。
    Tout,PoutT_{out}, P_{out}
  4. 除以 1000把“每千 Token 计价”换算成一次调用的实际金额。
    ⋯1000\frac{\cdots}{1000}

四、衡得对：成本效果权衡矩阵

好主理人从不单看“好不好吃”或“贵不贵”，而是把候选厨师都摆到一张“菜价—好吃程度”的平面图上：横轴是菜价，纵轴是好吃。落在左上角的“物美价廉”是梦中情人，右上角“价高货好”留给重要客人，左下角“便宜够用”适合随便吃吃，右下角“又贵又差”的直接拉黑。

这张图正是成本效果权衡矩阵。选型不能只盯效果或只盯成本，而要在多个维度中找平衡点。除了效果和成本，时延（上菜速度）也常常是第三根坐标轴。

构建矩阵时，先用统一尺度给模型打“效果分”（如 0~100），再算“单次调用成本”（元），最后把候选模型逐个放入四象限。物美价廉区最先考虑；价高货好区只在高价值任务（医疗、金融、法律）中启用；便宜够用区适合海量低风险请求；又贵又差区永远排除。降本的另一条路是“结构优化”：把简单请求路由到小模型、缓存高频问题的答案、优化 Prompt 减少输入 Token——矩阵解决“选哪个”，结构优化解决“怎么更省”。

有了四象限，主理人心里就有了“哪桌菜配哪位厨师”的大方向。不过不同客人的口味天差地别，还得针对每桌客人精准点菜——这是任务类型匹配的活。

Scorem=αEm−βCm−γLm\displaystyle Score_m = \alpha E_m - \beta C_m - \gamma L_m
Score_m 是模型 m 的综合决策得分：用系数 α、β、γ 把效果、成本、时延折成同一个天平上的分量，得分最高者胜出。
  1. E_m —— 效果分模型 m 在业务任务上的效果评分（0~100），来自评测环节。
    EmE_m
  2. C_m 与 L_m单次调用成本（元）和响应时延（秒），两个“负担项”从总分里扣。
    Cm,LmC_m, L_m
  3. α、β、γ —— 权衡系数业务对效果、成本、时延的重视程度，系数越大越不敢得罪该维度。
    α,β,γ\alpha, \beta, \gamma
  4. 综合得分效果加分、成本与时延减分，最终得到可排序的选型分数。
    Scorem=αEm−βCm−γLmScore_m = \alpha E_m - \beta C_m - \gamma L_m

五、配得巧：任务类型模型匹配

同一批厨师，不同场合有不同点法：商务晚宴上，主理人毫不犹豫请米其林主厨上硬菜；朋友聚会上，请街角私房菜师傅做几道拿手家常菜就皆大欢喜；深夜食堂要快速填饱肚子，路边小摊就够。每桌客人的“任务类型”，决定了该请谁。

LLM 应用也分“客人”：客服问答、合同摘要、代码补全、数学推理……不同任务对效果、成本、时延的敏感度完全不同。把任务拆清，再和模型能力对齐，是选型的核心手艺。

典型任务与模型的匹配大致如下：简单问答与信息抽取——小模型（如 MiniMax、Qwen-turbo 级）足够，成本极低；复杂推理与数学逻辑——R1 等推理增强模型比通用旗舰更稳；代码生成与补全——代码专项模型或旗舰模型视工程需要而定；长文本处理——优先长上下文模型，再配合分段摘要、检索增强等策略控成本。底层逻辑是对每个任务建立一个“效果—成本”函数，选使该函数最优的模型。

点菜点得再漂亮，也离不开一套稳妥的主理流程：先问清预算和客人，再筛选厨师，试菜打分，最后小范围试营业观察反馈。这就是选型流程。

m∗=arg⁡max⁡m∈M(Em(t)−λCm(t))\displaystyle m^* = \arg\max_{m \in M} \left( E_m(t) - \lambda C_m(t) \right)
该式表示：在所有候选模型 M 里，选出让“任务 t 的效果减去 λ 倍成本”最大的那个模型 m*，λ 表示你舍不舍得为效果加钱。
  1. m* —— 最优模型最终选定的那个模型，是整体表达式的输出。
    m∗m^*
  2. argmax —— 取最大者遍历所有候选，找到让括号内数值最大的那一个。
    arg⁡max⁡m∈M\arg\max_{m \in M}
  3. E_m(t) —— 任务效果模型 m 在具体任务 t 上的效果分，强调“因任务而异”。
    Em(t)E_m(t)
  4. λ 与 C_m(t)λ 是成本敏感系数；C_m(t) 是该模型完成一次任务 t 的真实成本，λ 越大越抠成本。
    λCm(t)\lambda C_m(t)

六、选得稳：科学选型决策流程

成熟的主理人不会第二天就换菜单。他会先定好“这季预算、常客口味、翻台速度”，在花名册里圈出三五个候选人；然后各做一道招牌菜请老客人盲吃打分；最后让其中一两道菜先上试卖菜单，观察一周的点击率和退菜率，才放心写进正式菜单。

模型选型同样是一条科学流水线：需求分析 → 候选筛选 → 小样本验证 → 灰度切换。每一步都有明确产出，避免“拍脑袋选模型”。

第一步需求分析，明确任务类型、每日调用量（QPS）、时延 SLA、月预算上限；第二步候选筛选，用能力地图和公开基准粗筛出 3~5 个候选；第三步小样本验证，从真实业务数据中抽 200~500 条，设计盲测脚本让模型各跑一遍，人工或自动化打分；第四步灰度切换，先放 10% 流量对比线上指标（准确率、成本、时延），确认无回退再全量。四个步骤缺一不可，前两步省时间，后两步保质量。

菜单定下来只是开始。客人的口味会变，厨师的状态也会起伏——真正让成本持续省下来的，是每个月的那次“菜单复考”。

n=z2⋅p(1−p)d2\displaystyle n = \frac{z^2 \cdot p(1-p)}{d^2}
n 是小样本验证需要的最少测试条数：z 是置信度对应的系数，p 是预估准确率，d 是允许的误差幅度。想验证得准，样本量要够。
  1. z —— 置信系数95% 置信度对应 z ≈ 1.96，越要稳妥 z 越大。
    zz
  2. p 与 (1−p)p 是预估的模型效果（0~1），(1−p) 是对应的“犯错率”，两者相乘描述不确定性。
    p(1−p)p(1-p)
  3. d² —— 误差幅度d 是允许的误差（如 ±5%），误差要求越严，d 越小，样本量越大。
    d2d^2
  4. 整体计算把上面的量组合起来，得到所需最小样本量，避免“测了 30 条就下结论”。
    z2⋅p(1−p)d2\frac{z^2 \cdot p(1-p)}{d^2}

七、盯得住：效果持续追踪

再好的主理人也不敢把菜单锁进保险柜。上个月这位厨师发挥超常，这个月可能因为家里琐事状态全无；隔壁新开了一家馆子，性价比吊打你菜单上的招牌菜。所以主理人每月都会悄悄复查：同一道菜横向盲吃，算翻台率和毛利，随时准备调整菜单。

模型选型是一次决策，更是一套持续运营机制。厂商每个季度发布新版本，业务数据分布也在漂移，不追踪就一定会“选型过时”。

持续追踪的四个抓手：第一，基准选择——维护一套与业务相邻的公开基准（如中文问答、代码、法律），每季度跑一遍；第二，私有评测集——从线上数据采样 500~1000 条，人工标注标准答案，防止测试集污染，也比公开基准更贴近业务；第三，版本迭代监控——订阅厂商更新公告，新版本发布后先在小流量对比旧版本再决定是否切换；第四，成本效果复盘——每月核算“每千次调用的真实成本”和效果指标，算出实际节省，验证当初选型假设是否成立。

主理人的饭局越办越省钱，靠的就是这张“菜单复考”的循环：认识厨师、盲测试菜、核算菜钱、四象限定位、按客人点菜、流程化定菜单、持续复查。模型选择的全部秘密，也不过如此。

Save=(Cold−Cnew)×N−Cmigrate\displaystyle Save = (C_{old} - C_{new}) \times N - C_{migrate}
Save 是切换到新模型后一年节省的钱：旧模型单次成本减新模型单次成本，乘以年调用量 N，再减去一次性迁移成本。正数才值得换。
  1. C_old 与 C_new切换前后两个模型的单次任务成本（元），含 Token、缓存、后处理等。
    Cold,CnewC_{old}, C_{new}
  2. N —— 年调用量该任务一年的总调用次数，是放大成本差的“杠杆”。
    NN
  3. 差值乘数量每次调用省下的钱乘以总次数，得到一年的毛节省。
    (Cold−Cnew)×N(C_{old} - C_{new}) \times N
  4. C_migrate —— 迁移成本代码改造、Prompt 重写、评测验证的一次性投入，最终节省要扣掉它。
    CmigrateC_{migrate}

AI 应用场景

智能客服的模型路由分级

阶段：模型部署与推理优化

解决的问题：传统做法是所有请求都走旗舰模型，每个用户咨询都要付高额输出费，月成本居高不下。AI 方案：先用意图分类把请求分级——常见问题走缓存或小模型，复杂投诉转旗舰模型兜底，成本下降近 60% 且体验不降。

具体案例：某电商客服每天处理 50 万次会话，按“FAQ 小模型 + 投诉旗舰”路由后，年节省约 120 万元；退款纠纷等高敏感场景保留旗舰兜底，用户满意度反而回升 3 个百分点。

代码助手的大模型选型

阶段：模型选型与评测验证

解决的问题：代码补全对时延极敏感，旗舰模型虽聪明但逐字生成太慢。团队在 HumanEval 与内部代码库上做业务实测，发现代码专项模型在补全场景效果追平旗舰、成本却只有三分之一。

具体案例：某研发团队 500 名工程师的 IDE 助手，从旗舰模型切到代码专项模型后，日成本从 3000 元降到 900 元，补全接受率反而提升 12%，工程师等待时间明显缩短。

长文合同的解析与摘要

阶段：推理成本优化

解决的问题：法务合同一份 2 万字，直接塞进小模型会截断丢信息，硬上旗舰模型单份成本超 10 元。方案：选用 200K 长上下文模型 + 分段抽取 + 结构化输出，把单份成本压到可接受范围。

具体案例：律所每周处理 3000 份合同，单份成本降至 2.5 元，关键条款召回率 96%，合规风险大幅下降，法务团队从“逐条读”转为“只复核”。

Python 演示

python68 行
#!/usr/bin/env python# -*- coding: utf-8 -*-"""模型选型决策器: 根据任务类型、预算与时延约束, 从候选模型中选择综合最优解""" # 候选模型库: 名称, 效果分(0-1), 价格基准(元/千token), 时延(秒), 上下文窗口(K)CANDIDATES = [    {"name": "Mini", "effect": 0.20, "price": 0.15, "latency": 0.1, "context": 8},    {"name": "Llama3", "effect": 0.42, "price": 0.20, "latency": 0.3, "context": 128},    {"name": "Kimi", "effect": 0.48, "price": 0.35, "latency": 0.4, "context": 200},    {"name": "R1", "effect": 0.72, "price": 0.30, "latency": 1.2, "context": 64},    {"name": "GLM4", "effect": 0.58, "price": 0.45, "latency": 0.6, "context": 32},    {"name": "QwenMax", "effect": 0.66, "price": 0.50, "latency": 0.6, "context": 32},    {"name": "Claude35", "effect": 0.82, "price": 0.75, "latency": 0.8, "context": 200},    {"name": "GPT4o", "effect": 0.80, "price": 0.85, "latency": 0.5, "context": 128},] TASK_RATIOS = {    "问答": (0.30, 0.70),    "摘要": (0.60, 0.40),    "代码生成": (0.40, 0.60),    "推理": (0.50, 0.50),}  def estimate_tokens(task_type, word_count):    """按任务类型估算输入与输出 token 数"""    in_ratio, out_ratio = TASK_RATIOS[task_type]    total = word_count * 1.3  # 中文约 1.3 token/字    return total * in_ratio, total * out_ratio  def cost_per_call(model, task_type, word_count):    """把模型价格基准换算成单次调用的真实成本(元)"""    tin, tout = estimate_tokens(task_type, word_count)    price_in = model["price"] * 0.8   # 每 1000 输入 token 单价    price_out = model["price"] * 3.2  # 每 1000 输出 token 单价(约为输入 4 倍)    return (tin / 1000) * price_in + (tout / 1000) * price_out  def weighted_score(model, task_type, word_count):    """效果加分, 成本与时延减分: Score = E - 20*C - 30*L"""    cost = cost_per_call(model, task_type, word_count)    return model["effect"] * 100 - 20 * cost - 30 * model["latency"]  def select_best(task_type, word_count, budget, latency_limit):    """在预算与时延约束下选出加权得分最高的模型"""    feasible = [        m for m in CANDIDATES        if m["latency"] <= latency_limit        and cost_per_call(m, task_type, word_count) <= budget    ]    if not feasible:        raise ValueError("预算或时延约束过紧, 没有可选模型, 请放宽条件")    best = max(feasible, key=lambda m: weighted_score(m, task_type, word_count))    best["cost"] = cost_per_call(best, task_type, word_count)    return best  if __name__ == "__main__":    # 示例: 1000 字合同摘要任务, 单次预算 1 元, 时延不超过 1 秒    choice = select_best("摘要", 1000, budget=1.0, latency_limit=1.0)    print("任务: 摘要 1000 字, 预算 1 元, 时延<=1s")    print("推荐模型: %s" % choice["name"])    print("单次成本: %.3f 元" % choice["cost"])    print("效果分: %d / 时延: %.1fs" % (choice["effect"] * 100, choice["latency"]))    print("结论: 在约束内, 效果/成本/时延加权得分最高"          "({:.1f})".format(weighted_score(choice, "摘要", 1000)))
目的：输入任务类型、字数和预算约束，自动从候选模型库中筛掉不符合条件的，再用加权打分选出综合最优的模型，帮你在“效果、成本、时延”之间找到平衡点。
  1. TASK_RATIOS = { "问答": (0.30, 0.70), "摘要": (0.60, 0.40),不同任务输入输出 Token 占比不同：摘要是“读得多写得少”，问答是“读得少写得多”
  2. total = word_count * 1.3 # 中文约 1.3 token/字估算文本量对应的 Token 总数，这是算账的地基
  3. price_out = model["price"] * 3.2输出 Token 单价是输入的 4 倍，提醒你控制生成长度
  4. return (tin / 1000) * price_in + (tout / 1000) * price_out输入、输出两段费用相加，就是一次调用的真实成本
  5. feasible = [m for m in CANDIDATES if m["latency"] <= latency_limit and cost_per_call(...) <= budget]第一时间过滤掉超时延、超预算的“超预算厨师”
  6. if not feasible:约束太紧时勇敢报错，比硬选一个不达标的便宜模型更负责任
  7. best = max(feasible, key=lambda m: weighted_score(m, task_type, word_count))在及格名单里挑加权得分最高者
  8. return model["effect"] * 100 - 20 * cost - 30 * model["latency"]效果加分、成本与时延减分，一分钟算完四象限决策

常见误区

误区“选最贵最聪明的模型肯定没错，反正效果最好，多花点钱值得。”很多刚做 AI 应用的同学，不管什么任务都默认上 GPT-4o、Claude 这类旗舰。

正解旗舰模型在简单任务上并不比小模型强多少，却贵 5~10 倍、时延更高。就像请米其林三星主厨做蛋炒饭，好吃是好吃，但 300 元的蛋炒饭只有商务宴请才点得下手。按任务分级路由，把旗舰留给高价值请求，才是省钱正道。

为何常见：厂商宣传永远强调“更强”，基准榜单也是旗舰霸榜，让人忽略了“够用”才是性价比的起点。

误区“MMLU 第一、HumanEval 满分，就选它了！”拿着榜单直接上生产，上线后业务效果却惨不忍睹。

正解公开基准与你的业务数据分布不同，且存在测试集污染风险——模型可能在训练时见过这些题。好比米其林评的是摆盘和创意，你家客人只在乎麻婆豆腐够不够下饭。必须用私有评测集加业务实测验证，跑分只能当粗筛。

为何常见：跑分直观、零成本、一键对比，是人性中最省力的决策捷径。

误区“小模型单价是旗舰的十分之一，全换小的！”结果幻觉率飙升，回答质量差，用户反复追问。

正解单价低不等于总成本低——小模型答不对，用户重试、人工兜底、售后赔付都是隐性成本。性价比要看“完成一次任务的总成本”，效果不达标时，贵模型反而可能更省钱，就像便宜菜原材料不新鲜，客人退菜浪费更多。

为何常见：成本表格上单价最显眼，而效果失败的代价写在财报里，不入眼。

误区“开源模型免费，部署到自己的 GPU 上，API 费全省了。”

正解自部署的显性成本是 GPU 采购与电费，隐性成本是运维工程师的工时、模型更新的迁移、高可用机房。日调用量低于十万次时，买卡自部署往往比 API 贵得多。开源省的是“单位推理费”，花的是“固定设施费”，得像买门店还是租摊位一样算总账。

为何常见：“免费”二字自带吸引力，让人忽略工程与运维的真实人力成本。

误区“上个月选好的模型，这个月还用，没毛病！”半年后发现成本翻倍、效果变差也不知情。

正解模型厂商每月发新版本，你的业务数据也在漂移，昨天的“最佳模型”今天可能沦为“又贵又差”。要像主理人定期复考厨师一样，季度跑私有评测集、月度核算真实成本，持续迭代选型。

为何常见：选型完成有强烈的“完事感”，而持续运营的枯燥不易被感知，团队也缺少复盘机制。

面试题

Q1. 模型选型的核心目标是什么？

单选题 · easy

  • A.选择效果最强的旗舰模型
  • B.效果成本时延三者平衡← 正确答案
  • C.选择单价最便宜的模型
  • D.追随最新发布的模型

答案：B。模型选型不是“选最强”而是“选最合适”，核心是在效果、成本、时延之间找平衡点。A 只重效果、C 只重成本、D 盲目追新，都忽略了任务本身的约束；如同请客只看名气不预算，再好的菜也撑不住账。

Q2. LLM 按什么单位计费？

单选题 · easy

  • A.按字符数量计费
  • B.按对话轮次计费
  • C.按 Token 数量计费← 正确答案
  • D.按用户人数计费

答案：C。LLM 的计费单位是 Token，即模型读写文字的粒度量：中文一个字约 0.6~2 个 Token。按字符、轮次或人数计费都不符合 API 的实际结算规则，所以选 C。

Q3. 通常输出 Token 单价与输入的比值是？

单选题 · mid

  • A.两者完全相等
  • B.输入价格更高
  • C.输出约为输入 3~4 倍← 正确答案
  • D.两者都完全免费

答案：C。输出 Token 需要逐个“生成”，算力消耗远大于并行“读取”输入，因此输出单价通常是输入的 3~4 倍。这提醒我们要控制生成长度，类比请客时“上菜成本”往往高过“备菜成本”。

Q4. “测试集污染”指的是什么？

单选题 · mid

  • A.评测数据标注错误
  • B.基准题混入训练数据← 正确答案
  • C.测试服务器性能不足
  • D.评测样本数量太少

答案：B。测试集污染指基准测试里的题目在训练阶段被模型“见过”，模型靠记忆而非能力答题，分数虚高。若据此选型，就像试菜时厨师提前知道要考哪道菜，端出来的不一定是真实水平。

Q5. 成本效果矩阵中“物美价廉”象限位于？

单选题 · mid

  • A.低成本低效果区域
  • B.高成本高效果区域
  • C.低成本高效果区域← 正确答案
  • D.高成本低效果区域

答案：C。成本效果矩阵横轴是成本、纵轴是效果，左上角是低成本高效果的“物美价廉”区，也是选型首选的甜点区域，像 R1、Llama 这类模型就常落在这里。

Q6. 小样本验证阶段最合理的做法是？

单选题 · hard

  • A.用公开基准分数直接定
  • B.抽真实业务数据盲测← 正确答案
  • C.随机选一个模型上线
  • D.让开发人员主观推测

答案：B。小样本验证要从真实业务数据中抽样盲测，因为公开基准与业务分布不同。A 忽略业务差异，C、D 毫无依据。这就像请老客人盲吃候选厨师的新菜，而不是只看简历。

Q7. 相对提升率 R 的计算作用是什么？

单选题 · mid

  • A.消除基准难度差异方便对比← 正确答案
  • B.精确计算单次调用的成本
  • C.衡量模型参数量的大小
  • D.判断上下文窗口的长度

答案：A。相对提升率把提升量除以基线得分，消除不同基准的难度差异，让“从 85 到 90”和“从 50 到 55”具有可比性——前者只有 5.9%，后者有 10%。选型报告里用相对提升更科学。

Q8. 以下哪些属于模型选型的隐形成本？

多选题 · mid

  • A.幻觉引发用户重试次数← 正确答案
  • B.客服人工兜底的成本← 正确答案
  • C.代码迁移改造的时间← 正确答案
  • D.模型名称的品牌影响力

答案：ABC。隐形成本包括幻觉导致的重试流量、客服兜底人力、代码迁移改造成本，它们不显示在单价表里却真实消耗预算；D 是品牌而非成本。选型时要把这些“菜单外的额外花销”一起算进总账。

Q9. 有哪些常用的降本手段？

多选题 · mid

  • A.简单任务路由到小模型← 正确答案
  • B.缓存高频问题的回复← 正确答案
  • C.精简 Prompt 减少 Token← 正确答案
  • D.全量请求都用旗舰模型

答案：ABC。简单任务路由小模型、缓存高频回复、精简 Prompt 减少输入 Token 都是已验证的降本手段；D 用旗舰处理全量请求等于放弃降本。就像高级餐厅也会备一套简餐菜单，让不同客人各得其所。

Q10. 关于持续追踪正确的做法有哪些？

多选题 · extreme

  • A.季度跑私有评测回归← 正确答案
  • B.订阅厂商版本更新← 正确答案
  • C.月度核算真实成本← 正确答案
  • D.选型后永久不再变更

答案：ABC。持续追踪意味着季度评测回归、关注厂商版本更新、月度成本复盘，形成“选型—验证—迭代”的闭环；D 是“一次性思维”，正是持续运营要力戒的反面。模型会更新、业务会漂移，菜单要定期复考。