第 09 讲 | 模型选型与抽象层

本节我们将掌握：
2026 年 LLM 生态格局：开源与闭源的差距和选型逻辑
模型抽象层：为什么不能让业务代码直接调 LLM API
模型抽象层的产品化：LiteLLM/Portkey/OpenRouter/One API 选型
研发过程视角：Claude Code 的模型路由启示
选型决策清单

2026 年的 LLM 生态格局

和 2024 年"OpenAI 一家独大"不同，2026 年的 LLM 生态已经进入了多极化时代。

闭源阵营：GPT-5 系列（OpenAI）、Claude Opus 4 系列（Anthropic）、Gemini 3 系列（Google）。仍然是通用能力的天花板，尤其在复杂指令遵循、长上下文理解上。

开源/开放权重阵营：Qwen 3 系列（阿里）、GLM-5.1（智谱）、Llama 4（Meta）、DeepSeek V4（深度求索）、Gemma 4（Google）。在编码、数学等垂直领域已经追上甚至超越闭源模型，且 Token 成本通常只有闭源的 10%-30%。

关键变化：开源和闭源的差距不再是"能不能用"，而是"在什么场景下用"。GLM-5.1 在 SWE-Bench Pro 上达到了 58.4%，超过了 GPT-5.4 和 Claude Opus 4.6；Qwen3-Max-Thinking 在多步推理上追平了 Opus 4.5。但闭源模型在安全对齐、指令遵循的细腻度上仍有优势。

架构师的第一课：不要只押注一个模型。2026 年的共识是——模型是易耗品，架构才是资产。

模型抽象层：企业级项目别让业务代码直接调 API

生产环境最常见的错误是把 LLM 调用散落在业务代码里：

代码只为想了解原理同学准备，非编程场景可不看

python

# ❌ 反模式：业务代码直接耦合 OpenAI SDK
from openai import OpenAI

def generate_report(text):
    client = OpenAI()
    response = client.chat.completions.create(
        model="gpt-5",
        messages=[{"role": "user", "content": text}]
    )
    return response.choices[0].message.content

这有什么问题？

模型换了，改 20 个文件：今天用 GPT-5，明天觉得贵想换 Qwen 3，后天 GLM-5.1 发布想试试——每个文件都改一遍
无法统一加监控：Token 消耗、延迟、错误率散落各处，没法集中采集
无法做路由和容灾：OpenAI 挂了就是全挂，没有降级路径
无法做语义缓存：同样的问题调了 100 次 API，花了 100 次的钱

正确做法：所有 LLM 调用走一个统一的抽象层

代码只为想了解原理同学准备，非编程场景可不看

python

# ✅ 正确模式：业务代码只调抽象层
def generate_report(text, user_id, tenant_id):
    return llm_gateway.complete(
        task="report_generation",   # 绑 model 映射 + 缓存策略 + fallback 链
        input=text,
        priority="normal",          # normal→Sonnet, high→Opus, low→DeepSeek
        user_id=user_id,            # 成本归因
        tenant_id=tenant_id,        # 多租隔离
        timeout=30_000,             # fallback 触发阈值
        ...
    )

网关层内部做路由、缓存、容灾、监控。业务代码只关心"我要一个结果"，不关心"用什么模型、挂了找谁"。

Russell经验⭐：咱们搭企业级生产系统时，MVP后第一周就把 LiteLLM 接好。模型可以换，路由可以调，但抽象层一旦建立，后续所有优化（缓存、容灾、成本监控）都可以在这一层集中做，不需要改业务代码。这是投入产出比最高的架构决策之一。

模型抽象层的产品化

2026 年这个抽象层已经有成熟产品了，不需要全部自研。

产品	定位	License / 语言	为什么是主力
LiteLLM	协议级统一 SDK	MIT / Python	协议级事实标准——100+ 模型统一成 OpenAI-compatible `completion()`，Router+fallback+Redis C1 缓存+C2 桥接全有，自部署随便用
Portkey	云网关 + 观测 + cost tracking	网关核心 MIT / Go + 云托管	云网关最完整——virtual key / tenant 拆解 + cost attribution + 观测 + C1 缓存 + semantic cache 开箱，LiteLLM 之上不想自己包观测的首选。
OpenRouter	全球最大 LLM 聚合 SaaS 网关	闭源 SaaS	全球最大的LLM统一网关——model 横向比价 + fallback + C1 exact-match 缓存 + 最小运维
One API	国内自部署聚合网关	MIT / Go	国内自部署主力——多租 / 额度 / 审计，国内团队数据不出域的默认选，出海/国内二分里"国内"那档就它。

其他还有 Cloudflare AI Gateway、Kong AI Gateway 等。

选型信号：

自部署协议统一 → LiteLLM
云网关一站式（观测+cost+多租）→ Portkey
最小运维接入聚合 → OpenRouter
国内自部署多租 → One API

模型公开测评：不能不看跑分，也不能只看跑分

测评就像高考，已经是“综合筛选”的”最优解“，但同时考试属于“抽样”，不可能完全等同于真实水平，甚至在某方面可能有较大偏差。所以”不能不看跑分，也不能只看跑分“。

大模型的能力是综合的，但在不同方向上各有侧重。测评不是为了排名，而是为了回答一个核心问题：这个模型在我们的场景里好不好用。

大模型测评的维度

能力方向：综合知识、代码、数学推理、科学推理、Agent能力、多模态、精确指令遵循、长上下文理解、知识广度和事实准确性、安全与对齐（可选项->否决项）、幻觉控制等。

生产需要：耗时、价格、上下文窗口大小、输出格式可靠性、并发与吞吐、部署成本、合规。

部署形态（硬约束）与交互形态：云端API、本地自部署、边缘/手机端（模型大小、延迟）；纯对话、工具调用（Agent）、多模态输入、流式实时；

维度是根据需求定的，随着场景的变化，维度以及维度的内涵都会变化。比如
随着具身智能的发展，以”世界模型“（物理常识/空间推理/因果预测/时序一致性）为目标，以”机器人、无人机、自动驾驶“为载体的大模型，独立形成一种新的维度。
随着国内以及欧盟等对于合规的要求，“安全合规”的维度内涵必然变化。

测评方式

模型测评的方法论大致分为三类，各有优劣，适用于不同的评估目的。

方式	优势	劣势	代表平台	适用场景
客观题库	可复现、成本低、速度快、适合横向对比	数据污染风险、无法测开放任务、维度有限；大模型"备考"严重，影响正确性	HF Open LLM Leaderboard、C-Eval、OpenCompass	日常迭代、能力摸底、开源选型；不应用于开放域创作、安全验收、Agent 多步任务
众包二选一	反映人类偏好、覆盖开放域、贴近真实体验	成本高、受用户偏差影响、无法精细诊断；用户偏见（长=专业、讨好用户->得分高）	LMSYS Chatbot Arena、SuperCLUE对战平台	产品发布前验收、综合能力排名；不应用于精细诊断、低资源语言
领域专家评审	精度最高、可深入诊断、适合高价值场景	周期长、样本少、成本昂贵、专家一致性难保证；"专家"资质各家差异大（执业者/学者/垂类），需看标定流程	Scale AI SEAL（付费执业者+私有数据）、FlagEval（学界+国标）、AGI-Eval（垂类执业者）	医疗/法律/金融等垂直场景验收

测评平台

国际模型测评平台：

平台	机构	方法论	核心维度	适用场景
LMSYS Chatbot Arena（现arena.ai）	UC Berkeley LMSYS	匿名双盲对战 + Elo，600 万+ 投票	文本/代码/多模态/长文本，分榜细	全球综合强弱、厂商宣发对标
Hugging Face Open LLM Leaderboard	Hugging Face	学术基准统一复现（MMLU/HellaSwag/ARC 等）	开源模型主战场，可复现	开源选型、研究对比
Scale AI SEAL	Scale AI	私有数据集 + 领域专家人工评审	70+ 语言、200+ 专业领域，偏鲁棒性	企业上线级稳定性
LiveBench	杨立昆联合 Abacus.AI/NYU	每月换题（IMO/Kaggle/arXiv），防数据污染	数学/推理/编程	防刷分、硬核推理能力
Artificial Analysis	Artificial Analysis	性能 + 速度 + 价格综合比	延迟/吞吐/$$$/token	选型算账（性价比）

国内模型测评平台：

平台	机构	方法论	核心维度	适用场景
SuperCLUE	CLUE 团队（中立第三方）	原创题 + 人工/裁判模型评	数学/科学/代码/指令遵循/幻觉/Agent 六维	中文选型首选
FlagEval（天秤）	北京智源研究院	"能力-任务-指标"三维，客观+主观	115+ 数据集，LLM/多模态/文生图视频；牵头 IEEE P3419、参与国标	全栈评测、标准话语权最强
OpenCompass（司南）	上海 AI 实验室	开源可复现，"六位一体"	通用/推理/代码/数学/指令/智能体，扩到科学智能	技术团队/研究者
中国电信·天罡	中国电信	按国标 GB/T 45288.2-2025	长文本/推理/代码/多模态	国企/政企选型
AGI-Eval	上海交大+同济+华师大+DataWhale	真实认知任务泛化	推理/知识/数学 + 垂类（法律/教育/医疗）	垂类落地参考

选型建议：跑分只是参考，真正选型时要结合自己的业务场景实测。建议先在目标场景下用 2-3 个候选模型各跑一周，对比实际效果、延迟、成本，再决定主力模型。

测评趋势

维度持续膨胀：从单一MMLU到几十个细分Benchmark，评估变成雷达图，不再看总分。
Agent能力取代代码成为最热赛道：SWE-bench、WebArena这类“模拟真实工作流”的Benchmark影响力远超HumanEval。
安全从加分项变为否决项：监管压力下，安全测评低分的模型直接出局。
成本+速度进入公开竞技：厂商主动公布价格/TTFT/TPOT，选型时这些指标的权重逼近能力分数。
长上下文成为标配门槛：128K已不够，200K+且位置偏差小的模型才有竞争力。

模型选型步骤方式

选型步骤

Step1: 根据硬约束，砍掉不合适的。

部署条件：本地部署 Vs 远程调用；开源 Vs 闭源；终端要求（显存；手机/服务器/机器人）
合规：国内 Vs 国外模型（如Claude Code不支持国内使用，国内企业原则上就不能用；央国企为数据安全也不要用国外模型），是否符合政策要求（如国内的算法备案证明），模型的数据留存政策（如很多code plan明确标注“对话会拿去训练”）
成本：成本承载粗估；资源包等综合费用计算.
性能要求：速度、吞度、并发、延迟。
其他要求：上下文窗口（是否匹配场景）

Step2：根据上文的平台，结合自己的场景，做初筛。

参考多平台测评结论，（注意：要综合考量国内外测评平台、以及”测试方式“）

比如：
有对应指标的，选对应指标，如“代码综合能力”。
没有对应指标的，选相关指标，如“客服FAQ” 跟“知识广度、指令遵循、安全”有关。
如果得分差距大，取top 5；如果得分差距小，取top 10。
多平台取综合top3-5。

公开测试：很多测评有线上平台，测几个案例找找感觉。

Step3: 内部测评：在内部测试集跑POC

准确性、格式符合/稳定性、延迟感受、安全表现。

Step4: 生产监控/定期复测。

生产监测
用户/客服反馈；有必要可以双模型A/B测试
定期复测：因为模型有时候也会小版本变化，并不会对外体现。

选型注意事项

不要迷信单一分数，一定要贴合场景：MMLU高分不代表Agent能力强，SWE-bench高分不代表客服场景好用。
公开Benchmark只反映平均水平：我们的场景可能是长尾分布，内部微测评才是最终裁判。
定期复测：模型版本更新频繁，上次合格的模型下个月可能因更新而行为变化。
混合方案是常态：没有一个模型在所有维度上都最优，根据场景路由不同模型往往比追求全能更划算。

选型陷阱

陷阱一：只用一个模型。

生产环境最常见的错误是把所有调用绑死在单一模型上。模型会宕机、会涨价、会更新后行为改变。从一开始就建立主备模型列表，明确每个场景的默认模型和备选模型。主备最好来自不同厂商，避免厂商级故障导致全站降级。

陷阱二：没事别乱升级，追新未必正确。

新模型发布就想试试，生产环境频繁切换模型，持续打破业务稳定性。正确做法

模型和代码分离，换模型不需发新版/影响生产稳定性；
如果用户已经满意，换模型不必频繁；优先保持业务稳定性。
如果要换，优先在低风险场景切换；
如果高风险场景要换，要重走选型流程。

陷阱三：开源闭源二选一。

很多公司因为各种原因，优先选择了开源模型自部署，完全舍弃了闭源商用的大模型API。其实很多场景要做细的划分，没必要”一刀切“。开源自部署和闭源商用不是对立关系，而是互补。

在"不违反公司规定/要求"的前提下，2026年的最佳实践是“开源做主力、闭源做备选和攻坚”。

开源模型（Qwen3、Llama 4、DeepSeek-V3）负责日常请求（客服FAQ、简单代码生成、内容分类），成本低、可控、可自部署、无数据出境风险；
闭源模型（GPT-4o、Claude Sonnet 4.6）负责复杂场景（高难度推理、Agent多步规划、顶级质量输出），质量上限高，但贵、有宕机风险、数据出境需评估。

日常流量中比如可以让开源承担70-80%，闭源承担20-30%业务，并作为部分合规自部署场景的灾备。

一方面，开元商用模型能力更强，可以完全兜住复杂业务，保证了“业务优先”。

另一方面，开源商用模型稳定性更好，并发更高，当闭源不可用时，能平滑接管大部分场景，不至于全站降级。

研发过程视角

详见第 05 讲（编排与工作流）中 Workflow 的嵌套关系。从模型架构的视角看，我们每天用的 Claude Code 本身就是一台精心设计的模型路由器：

写代码、改 Bug → Claude Opus（强推理）
搜索文件、读代码 → 轻量级工具调用（不需要完整 LLM）
跑测试、看结果 → 本地执行（零 LLM 成本）

我们不需要自己做模型路由——Claude Code 已经在帮我们做了。但当我们为生产环境设计系统时，这套"什么任务用什么模型"的决策逻辑，必须显式地写进架构里。

选型决策

架构师决策清单：
模型抽象层（非常推荐）：企业级项目，业务代码禁止直接调 LLM SDK，所有调用走统一网关，低投入高产出
网关选型：自部署协议统一选 LiteLLM，云网关一站式选 Portkey，最小运维选 OpenRouter，国内自部署多租选 One API
模型选择原则：不要只押注一个模型，建立主备模型列表，明确各场景的默认模型和备选模型
测评参考：跑分不代表实战，LMSYS 看综合实力、Artificial Analysis 看性价比、SuperCLUE/FlagEval 看中文能力。每种测评方式都有盲区，不能只信一种。最终选型要结合自身场景实测。
选型步骤：硬约束初筛 → 测评平台参考 → 内部场景实测 → 生产监控复测。不能跳过内部实测直接看跑分。

面试回答要点

Q：生产环境的 LLM 系统怎么做模型选型？

答（抓架构 + 讲分层）：

核心原则——模型是易耗品，架构才是资产。不能让业务代码直接耦合某个模型的 SDK。必须建统一的模型抽象层（LiteLLM / API Gateway），所有调用走这一层。

为什么需要抽象层：

解耦：模型切换不影响业务代码
统一监控：Token 消耗、延迟、错误率集中采集
为后续优化铺路：路由、缓存、容灾都在这一层集中做

测评参考：跑分不代表实战。LMSYS 看综合实力、Artificial Analysis 看性价比、SuperCLUE/FlagEval 看中文能力。每种测评方式都有盲区，不能只信一种。最终选型要结合自身场景实测。

深度追问：

"抽象层和直接调 API 有什么区别？" → 直接调 API 会把模型 SDK 耦合到业务代码里，模型换了要改几十个文件；抽象层把路由、监控、缓存都收拢到一个地方，业务代码只关心业务逻辑。
"跑分很高的模型，实际使用效果不好怎么办？" → 跑分只代表特定基准的能力，不代表我们的业务场景。一定要在目标场景下实测 2-3 个候选模型，对比实际效果、延迟、成本，再决定主力模型。

小结

模型抽象层是基础设施：所有 LLM 调用走统一网关，后续的路由、缓存、容灾、监控都在这一层集中做
网关产品已经成熟：LiteLLM/Portkey/OpenRouter/One API 覆盖主流场景，不需要全部自研
模型是易耗品，架构才是资产：不要只押注一个模型，建立主备模型列表
跑分不代表实战：测评方式各有盲区，选型必须结合自身场景实测
Claude Code 本身就是模型路由器：什么任务用什么模型，这套逻辑要显式写进生产架构

思考题

我们的团队正在开发一个企业内部的知识问答系统，日均 5000 次查询。目前开发阶段直接在业务代码里调 OpenAI SDK，准备上线前再做"工程化改造"。从模型架构的视角，这种做法有什么风险？如果让我们说服技术负责人第一周就接抽象层，我们会怎么论证投入产出比？
假设我们要为公司选型 LLM 网关：团队规模 50 人，主要用国内云厂商的模型（通义千问、文心一言），也有少量 OpenAI 调用用于对比。数据合规要求不能出境。从 LiteLLM/Portkey/OpenRouter/One API 中，我们会选哪个？理由是什么？

第 09 讲 | 模型选型与抽象层 ​

2026 年的 LLM 生态格局 ​

模型抽象层：企业级项目别让业务代码直接调 API ​

模型抽象层的产品化 ​

模型公开测评：不能不看跑分，也不能只看跑分 ​

大模型测评的维度 ​

测评方式 ​

测评平台 ​

测评趋势 ​

模型选型步骤方式 ​

选型步骤 ​

选型注意事项 ​

选型陷阱 ​

研发过程视角 ​

选型决策 ​

面试回答要点 ​

小结 ​

思考题 ​

参考资料 ​