大语言模型（LLM）分类详解：从架构到应用场景的完整梳理

1. 为什么你需要一张 LLM 分类地图

大语言模型（LLM）这个词现在几乎天天出现在技术群和需求文档里，但真正落到选型时，很多人还是会卡住：同样是「大模型」，为什么有的适合做文本分类，有的适合写代码，有的能一口气读完 200 页 PDF？答案藏在分类维度里。LLM 不是一个单一物种，而是一个庞大的家族，按架构、训练方式、规模、应用定位、技术特性、开源与否可以切出至少六个维度。你不需要背下所有模型名字，但需要建立一套判断框架，才能在面对「用哪个模型」这个问题时，快速缩小范围。

这篇文章面向正在做 AI 应用落地的开发者，尤其是需要对接多家模型 API、做模型对比或搭建统一调用通道的人。我会先把分类体系拆成可对照的表格，再给出一套基于 TaoToken 统一 Key/API 通道的配置骨架，让你用同一套代码去验证不同 LLM 的调用差异。整个过程不需要你分别注册五六家平台，也不需要维护多套鉴权逻辑。读完你至少能拿到三样东西：一张能直接贴进选型文档的分类对照表、一份可复制的多模型调用配置、一套遇到报错时能自己排查的检查清单。

2. 六个分类维度：从架构到应用场景

2.1 按基础架构：Encoder-only、Decoder-only、Encoder-Decoder

架构决定了模型「怎么看文本」。Encoder-only 用双向注意力，同时看上下文两侧，擅长理解类任务，比如文本分类、情感分析、命名实体识别，代表是 BERT 系列。Decoder-only 是自回归生成，从左到右逐 token 预测，适合开放式生成、对话、代码，GPT、LLaMA、Claude、Qwen 都属于这一类。Encoder-Decoder 则是编码器理解输入、解码器生成输出，典型场景是翻译、摘要、问答，T5、BART、GLM 是代表。

当前主流是 Decoder-only，因为 GPT 系列验证了自回归生成在通用任务上的扩展性。你在选型时如果做的是分类或抽取，Encoder-only 的小模型往往性价比更高；如果做对话或生成，直接看 Decoder-only。

2.2 按训练范式：预训练、指令微调、对齐、多模态

训练范式决定模型「会不会听话」。基础预训练模型只有通用语言能力，不懂指令；指令微调模型（SFT）学会了遵循「翻译这段话」「总结文章」这类要求；对齐模型（RLHF/RLAIF）进一步优化了安全性和有用性，ChatGPT、Claude 3 Opus 属于这一层。多模态模型则融合文本、图像、音频、视频，GPT-4V、Gemini 1.5 Pro、Qwen-VL 是代表。

实际调用时，你会发现同一个基座模型的不同版本，指令遵循能力差异很大。选型时优先看是否经过 SFT 和 RLHF，除非你要自己做微调。

2.3 按规模：小型、中型、大型、超大规模

参数量直接影响部署成本和能力上限。小于 10B 的小型模型适合端侧、IoT、边缘计算，比如 Phi-3-mini、Gemma-2B、Qwen2-1.5B。10B 到 70B 的中型模型是性能和成本的最佳平衡点，个人服务器和中小企业私有化部署首选，LLaMA-2-13B、Mistral-7B、ChatGLM3-6B 都在这个区间。70B 到 100B+ 的大型模型能力接近顶级闭源，但需要专业硬件，LLaMA-2-70B、Qwen-72B、Mixtral 8x7B 是代表。超大规模模型（100B+ 到万亿级）只有少数头部机构能训练和部署，GPT-4、PaLM-2 属于这一档。

这里有个容易踩的坑：MoE 架构的总参数量很大，但实际推理只激活一部分。比如 Mixtral 8x7B 总参数 46.7B，激活约 12.9B，不能简单按总参数判断硬件需求。

2.4 按应用定位：通用、代码、垂直领域、中文优化、数学推理

应用定位决定模型「擅长什么」。通用基座模型面向广泛任务，GPT-4o、Claude 3.5 Sonnet、通义千问 2.5 是代表。代码专用模型针对代码理解和生成优化，GitHub Copilot、CodeLlama-70B、DeepSeek-Coder-V2 属于这一类。垂直领域模型针对法律、医疗、金融深度优化，LawGPT、Med-PaLM 2、BloombergGPT 是例子。中文优化模型针对中文语料和文化语境调优，文心一言、通义千问、ChatGLM-4、Baichuan-3 都在做这件事。数学推理模型强化计算和证明能力，DeepSeek-Math、Qwen2-Math、Minerva 是代表。

选型时先问自己：任务是通用问答，还是代码补全，还是领域知识问答？定位错了，再大的模型也白搭。

2.5 按技术特性：稠密、MoE、长上下文、RAG-native

技术特性决定模型的效率和扩展性。稠密模型每次前向传播激活全部参数，架构简单、训练稳定，GPT-3、LLaMA-2-70B、Qwen-72B 是代表。MoE 模型把大模型拆成多个专家子网络，通过门控动态激活部分专家，总参数量大但推理成本低，GPT-4（据传 8×220B MoE）、Mixtral 8x7B、DeepSeek-V2 是典型。长上下文模型支持超长输入窗口，Gemini 1.5 Pro 支持 1M tokens，Kimi 支持 200K tokens，GLM-4-9B-1M 支持 1M tokens。RAG-native 模型原生集成外部知识检索，RAGFlow、Dify、Perplexity AI 属于这一类。

如果你要处理整本书或大型代码库，长上下文是硬指标；如果知识需要实时更新，RAG-native 或自己搭 RAG 更合适。

2.6 按开源/闭源：商业闭源、开放权重、半开放

开源与闭源直接影响成本、隐私和定制化。闭源商业模型只通过 API 提供服务，性能顶尖、持续迭代、无需运维，但成本高、数据隐私有风险、无法定制，GPT-4/GPT-4o、Claude 3、Gemini 1.5、文心一言、通义千问属于这一类。开放权重模型可以本地部署、二次开发，数据隐私好、可定制、社区生态活跃，但性能通常略逊于顶级闭源，需要自行运维，LLaMA-3、Mistral-7B/8x22B、Qwen2、DeepSeek-V2、ChatGLM-4 是代表。半开放模型权重有限开放，需申请或签署协议，LLaMA-2、Gemma 属于这一类。

实际项目中，常见做法是闭源模型做效果上限验证，开放权重模型做私有化落地，两者通过统一 API 通道切换。

3. TaoToken 前置：统一 Key 与 API 通道

3.1 为什么需要统一通道

做 LLM 分类验证时，最麻烦的不是模型本身，而是每家平台的鉴权方式、请求格式、返回结构都不一样。你可能要同时维护 OpenAI、Anthropic、Google 三套 SDK，还要处理不同的错误码和限流策略。TaoToken 提供的是一个统一 Key/API 通道，让你用同一套 OpenAI 兼容接口去调用不同厂商的模型，省掉多平台注册和多套鉴权逻辑。

官网地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api 。你只需要在控制台创建一个 API Key，就可以在代码里通过 base_url 切换不同模型。

3.2 获取 API Key 与配置环境

进入控制台后，在 API Keys 页面创建一个新 Key。建议按项目或环境分开创建，方便后续排查和轮换。创建后把 Key 存到环境变量里，不要硬编码在代码中。

export TAOTOKEN_API_KEY="sk-你的实际Key" export TAOTOKEN_BASE_URL="https://taotoken.net/api"

如果你用的是 Python，可以这样读取：

import os api_key = os.environ.get("TAOTOKEN_API_KEY") base_url = os.environ.get("TAOTOKEN_BASE_URL") print("Key 前缀:", api_key[:8] if api_key else "未设置") print("Base URL:", base_url)

控制台里还能看到模型列表和用量统计，建议先确认你要验证的模型是否在支持范围内。

4. 可复制配置：多模型调用骨架

4.1 Python 调用骨架

下面这段代码用 OpenAI SDK 的兼容模式，通过 TaoToken 统一通道调用不同模型。你只需要改 model 参数，就能在同一个脚本里对比不同 LLM 的输出。

import os from openai import OpenAI client = OpenAI( api_key=os.environ.get("TAOTOKEN_API_KEY"), base_url=os.environ.get("TAOTOKEN_BASE_URL"), ) def ask(model: str, prompt: str, temperature: float = 0.7) -> str: resp = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": "你是一个简洁的技术助手。"}, {"role": "user", "content": prompt}, ], temperature=temperature, max_tokens=512, ) return resp.choices[0].message.content if __name__ == "__main__": models = [ "gpt-4o", "claude-3-5-sonnet", "qwen2-72b", ] prompt = "用一句话解释 Decoder-only 架构和 Encoder-only 架构的核心区别。" for m in models: print(f"=== {m} ===") try: print(ask(m, prompt)) except Exception as e: print(f"调用失败: {e}") print()

这段代码的关键点是 base_url 指向 TaoToken 的 API 入口，model 参数填你要验证的模型标识。不同模型的返回结构在兼容层已经被统一成 OpenAI 格式，你不需要为每个厂商写不同的解析逻辑。

4.2 分类对照表（可直接贴进选型文档）

4.3 选型判断清单

拿到一个新需求时，按这个顺序问自己：

第一，任务是理解类还是生成类？理解类优先看 Encoder-only 或经过指令微调的 Decoder-only；生成类直接看 Decoder-only。

第二，需不需要遵循复杂指令？需要的话，确认模型是否经过 SFT 和 RLHF。

第三，部署环境是什么？端侧选小型模型，私有化选中型开放权重，云端 API 选闭源或大型模型。

第四，上下文有多长？超过 32K 就要专门看长上下文模型。

第五，数据能不能出本地？不能的话，开放权重本地部署是唯一选择。

第六，预算和延迟要求？MoE 模型在总参数量大的情况下推理成本更低，适合高并发场景。

5. 验证请求与成功结果

5.1 单模型验证

先用一个模型跑通链路，确认 Key、base_url、网络都正常。

from openai import OpenAI import os client = OpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.environ["TAOTOKEN_BASE_URL"], ) resp = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "回复 OK 两个字母即可。"}], max_tokens=10, ) print(resp.choices[0].message.content) print("usage:", resp.usage)

如果返回OK并且 usage 里有 prompt_tokens 和 completion_tokens，说明通道正常。

5.2 多模型对比验证

把 4.1 的脚本跑起来，你会看到不同模型对同一个 prompt 的回答风格差异。比如问「用一句话解释 Decoder-only 和 Encoder-only 的核心区别」，GPT-4o 可能偏结构化，Claude 3.5 Sonnet 可能偏解释性，Qwen2-72B 可能偏中文语境。这个对比过程本身就是分类认知的验证。

python compare_models.py

预期输出类似：

=== gpt-4o === Decoder-only 从左到右生成，Encoder-only 双向理解。 === claude-3-5-sonnet === Decoder-only 是自回归生成，每次预测下一个 token；Encoder-only 是双向注意力，同时看上下文两侧。 === qwen2-72b === Decoder-only 擅长生成，Encoder-only 擅长理解，前者是 GPT 系，后者是 BERT 系。

5.3 用 curl 快速验证

如果你不想装 SDK，可以直接用 curl 验证通道。

curl -s https://taotoken.net/api/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o", "messages": [{"role": "user", "content": "回复 OK"}], "max_tokens": 10 }'

返回 JSON 里如果有 choices 数组和 usage 字段，说明请求成功。

6. 本篇常见错排查

6.1 401 Unauthorized

最常见的原因是 Key 没设置或设置错了。检查环境变量：

echo $TAOTOKEN_API_KEY

如果输出为空，说明没 export 成功。注意 Key 前面通常有sk-前缀，不要漏掉。另外确认你用的是 TaoToken 控制台创建的 Key，而不是其他平台的。

6.2 404 Not Found

base_url 写错了。正确写法是https://taotoken.net/api，不要在后面多加/v1或/chat。OpenAI SDK 会自动拼接/chat/completions。如果你用的是其他 SDK，确认它的 base_url 拼接规则。

6.3 model 参数不识别

不同模型在 TaoToken 里的标识可能和官方文档不完全一样。比如 Claude 系列可能写成claude-3-5-sonnet，Qwen 系列可能写成qwen2-72b。建议先在控制台的模型列表里确认准确标识，再填到代码里。

6.4 超时或连接失败

先确认网络能访问https://taotoken.net/api。如果公司网络有出口限制，联系运维放行。另外检查是否设置了 HTTP_PROXY 之类的环境变量，有时候本地代理会干扰请求。

curl -I https://taotoken.net/api

如果返回 200 或 401，说明网络通；如果超时，就是网络问题。

6.5 返回内容为空

检查 max_tokens 是否设得太小，或者 prompt 是否触发了内容过滤。有些模型对敏感词会返回空内容。把 max_tokens 调到 256 以上再试。

6.6 usage 字段缺失

部分模型在兼容层可能不返回 usage，这不影响使用，但会影响你的计费统计。如果需要精确统计，建议在应用层自己记录 token 数，或者用 tiktoken 之类的库本地估算。

7. 下一步：按场景选择入口

分类认知建立之后，下一步就是动手验证。如果你主要做模型对比和效果验证，可以直接用模型对话入口快速试不同模型的输出差异：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。

如果你要长期做编码类任务或 Agent 开发，建议看 Coding Plan，它更适合持续性的代码生成和工具调用场景：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。

如果你需要管理多个项目的 Key 和用量，控制台入口在这里：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 。创建和管理 Key 的页面是：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。

接入文档里有更详细的参数说明和错误码对照：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。如果你用 Claude Code 做开发，Anthropic 兼容通道的配置参考：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claude_code&utm_campaign=rewrite 。

我自己的习惯是先把分类表贴在项目 README 里，每次选型时对着表过一遍判断清单，再用统一通道跑三个模型的对比请求。这样既不会漏掉关键维度，也不会在多个平台之间来回切换浪费时间。