跳到主要内容

选择合适的模型

选择合适的 LLM 是构建 AI 应用时最先要做的决策之一。

不同的模型为不同的目的而设计。有些模型被训练来生成文本,其他模型被优化用于遵循指令,还有一些专注于效率或多模态任务。

提示: 若无法显示,请直接打开 独立工具页面

什么是基础模型?

基础模型(base models,也称作 foundation models)是大多数 LLM 的起点。它们通常通过无监督学习在大量的文本语料上进行训练,这不需要标注数据。

在这个被称为预训练(pretraining)的初始阶段,模型学习通用的语言模式,如语法、句法、语义和上下文。它能够预测下一个词(或 token),并能执行简单的少样本学习(few-shot learning,在看到几个示例后处理一个任务)。然而,它还不理解如何遵循指令,也没有针对特定任务进行开箱即用的优化。

为了使它们有用,它们通常需要在精选的数据集上进行微调,使用指令微调等技术。从一个基础模型,你可以创建:

  • 指令微调模型
  • 对话模型
  • 微调的领域模型
  • RLHF 对齐模型

基础模型示例:Qwen3.5-0.8B-Base、DeepSeek-V3-Base、GPT 风格的预训练模型

指令微调模型与对话模型

指令微调模型构建于基础模型之上。在初始预训练阶段之后,这些模型会使用由指令及其对应响应组成的数据集,经历第二个训练阶段。

这个过程教会模型如何更可靠地遵循用户的提示词,使其更好地与人类期望对齐。它们理解任务意图,并对以下命令做出更连贯的响应:

  • "总结这篇文章。"
  • "解释 LLM 推理是如何工作的。"
  • "列出远程工作的优缺点。"

这使它们在实际应用中更有用,比如聊天机器人、虚拟助手,以及直接与用户交互的 AI 工具。

如果你在 LLM 的名称中看到 "Instruct",通常意味着该模型经过了指令微调。然而,"Instruct" 模型不一定是完整的聊天机器人。它们被优化用于完成给定任务或遵循指令,而不是维持多轮对话。

相比之下,对话模型通常经过进一步调优(通常使用对话数据和 RLHF/DPO),以便在交互式聊天机器人场景中表现出色。它们需要处理跨轮次的上下文,并与多个参与者互动。参见指令与对话微调了解更多。

指令模型示例:Meta-Llama-3-8B-Instruct、Qwen3-4B-Instruct-2507、Kimi-K2-Instruct-0905

稠密模型与混合专家(MoE)模型

大多数传统 LLM 是稠密模型(dense model)。这意味着网络中的每个参数在推理期间都会被用于每个 token。

混合专家(MoE)模型,如 DeepSeek-V4 Pro,采取了与传统稠密模型不同的方法。它们不是对每个输入都使用所有模型参数,而是包含多个被称为专家的专门子网络,每个专家专注于不同类型的数据或任务。

在推理期间,根据输入的特征只激活这些专家中的一部分。这种选择机制使模型能够更有选择性地路由计算,根据内容或上下文启用不同的专家。因此,MoE 模型通过在大型网络上分配工作负载,同时将每次推理的计算成本保持在可控范围内,实现了更高的可扩展性和效率。

模型类型工作原理优点缺点
稠密(Dense)使用所有参数架构简单大规模时成本高
MoE选择性地激活专家高效扩展路由更复杂

将 LLM 与其他模型结合

现代 AI 应用很少只使用单一的 LLM。许多高级系统依赖于将 LLM 与其他类型的模型组合,每种模型专门处理不同的模态或任务。这使它们能够超越纯文本生成,变得更加全能、多模态和任务感知。

以下是一些常见示例:

  • 小语言模型(SLM)。用于对延迟和资源限制敏感的轻量级任务。它们可以作为回退模型或设备端助手,处理基本交互而无需依赖完整的 LLM。
  • 嵌入模型。它们将输入(如文本、图像)转换为向量表示,使其适用于语义搜索、RAG 流水线、推荐系统和聚类。
  • 图像生成模型。Stable Diffusion 等模型从文本提示词生成图像。当与 LLM 配对时,它们可以支持更高级的文生图工作流,如创意助手、内容生成器或多模态代理。
  • 视觉语言模型(VLM)。NVLM 1.0 和 Qwen2.5-VL 等模型结合了视觉和文本理解,支持图像描述、视觉问答或对截图和图表进行推理等任务。
  • 文本转语音(TTS)模型。它们可以将文本转换为自然流畅的语音。当与 LLM 集成时,它们可以用于基于语音的代理、无障碍界面或沉浸式体验。

了解更多关于多模型推理流水线的信息。

在哪里获取模型

一旦你知道自己需要什么类型的模型,下一个问题很简单:你实际上在哪里找到它们?

如今,大多数团队不会从头训练模型。他们会从开放模型中心获取模型,进行适配,然后部署。

Hugging Face

Hugging Face 是大多数团队默认的起点。它在文本、视觉、音频和多模态任务中托管了数十万个开放模型。你可以在那里找到基础模型、指令模型、对话变体、嵌入和扩散模型。Hugging Face 还提供许多微调量化的模型变体,使你无需自己进行微调就能轻松试验指令微调或低 VRAM 模型。

人们使用它的原因:

  • 庞大的生态系统和社区采用率
  • 清晰的模型卡片,包含许可证、基准测试和预期用途
  • 在大多数推理框架中得到原生支持(如 vLLM、SGLang、MAX、TensorRT-LLM)
  • 轻松获取权重、配置和分词器

请注意,并非所有模型在 Hugging Face 上都同样容易获取。有些模型完全开放,无需身份验证即可下载。其他模型则受门控,意味着你必须接受特定的许可条款,并使用 Hugging Face API token 才能访问权重。

这通常发生在以下情况:

  • 模型具有限制性或自定义许可证
  • 作者希望了解谁在使用该模型
  • 模型面向研究或受控商业用途发布

实际上,这意味着你可能需要:

  • 创建一个 Hugging Face 账户
  • 生成一个 API token
  • 将该 token 传递给推理框架或部署环境(例如,通过 HF_TOKEN 这样的环境变量)

需要门控访问的模型通常带有更严格的使用条款、更少的生产环境成熟度,或更少的长期可用性保证。

一个简单的经验法则:如果模型需要 token 和手动审批,在基于它构建之前,请仔细检查它是否满足你的生产环境和法律约束。

其他需要注意的事项:

  • 许可证差异(Apache-2.0、MIT、自定义)
  • 隐藏在参数数量背后的 VRAM 需求
  • 有些模型是研究级的,尚未为生产就绪

在测试之前,请务必阅读模型卡片。它会告诉你模型真正擅长什么、不擅长什么。

ModelScope

ModelScope 是阿里巴巴运营的主要开放模型中心。它提供了很强的覆盖:

  • 中文和多语言 LLM
  • 视觉语言模型
  • 语音和多模态模型
  • 为本地和区域用例优化的模型

对于为中文用户构建产品,或在 Hugging Face 访问可能较慢或受限的区域部署的团队,ModelScope 通常是首选之地。这里发布的许多模型最终会出现在 Hugging Face 上,但有些模型在一段时间内仍是 ModelScope 首发或 ModelScope 独占。

OpenRouter

OpenRouter 与其说是传统的"模型中心",不如说是一个模型访问层。

OpenRouter 不是让你自己下载权重和运行模型,而是让你:

  • 通过一个 API 访问许多开放和专有模型
  • 比较不同模型之间的行为、延迟和成本
  • 在模型之间动态路由流量

这对于早期原型开发、A/B 测试或在对自托管做出承诺之前评估模型很有用。然而,如果你需要对性能、数据或成本进行严格把控,它并不能替代拥有自己的推理栈。

模型权重格式

当你下载一个开源 LLM 时,你通常下载的是它的权重。模型权重是在训练期间获得并存储知识的学习参数。它们通常以推理框架可以加载的文件形式分发。

在 LLM 生态系统中,有几种常用的权重格式。

PyTorch 检查点

许多模型最初以 PyTorch 检查点文件的形式发布,通常带有以下扩展名:

pytorch_model.bin
model.pt

这些文件以 PyTorch 可以直接加载的序列化格式存储模型参数。然而,传统的检查点格式有几个缺点:

  • 它们加载起来可能很慢
  • 它们可能需要反序列化步骤
  • 某些格式允许任意代码执行,这引发了安全问题

由于这些限制,许多现代模型发布使用更安全的替代方案。

Safetensors

Safetensors 现在是分发 LLM 权重最广泛使用的格式之一。它由 Hugging Face 引入,作为 PyTorch 检查点的安全、快速替代方案。

主要特点:

  • 避免任意代码执行,实现安全加载
  • 快速的显存映射,权重可以高效加载
  • 被 vLLM、TensorRT-LLM、SGLang 和 MAX 等推理框架广泛支持

示例文件:

model-00001-of-00004.safetensors
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors

大型模型通常被分片成多个文件,以便更容易下载和管理。

当模型以多个 safetensors 分片分发时,你经常会看到一个名为 model.safetensors.index.json 的文件。这个文件充当映射索引,告诉加载器每个参数张量存储在哪里。对于大多数用户来说,这个过程由推理框架自动处理。然而,理解索引文件在以下情况下会有所帮助:

  • 调试模型加载问题
  • 修改模型权重
  • 使用自定义检查点

GGUF

GGUF 是一种为高效本地推理而设计的模型格式,尤其适用于 llama.cpp 等工具。GGUF 模型通常:

  • 经过量化以减少显存占用
  • 针对 CPU 或小型 GPU 环境进行优化
  • 非常适合在本地运行模型

示例文件:

model.Q4_K_M.gguf

量化类型(如 Q4、Q5 或 Q8)表示模型权重被压缩的程度。

常见问题

基础模型和指令模型有什么区别?

基础模型在原始文本上进行预训练并学习语言模式。指令模型则经过微调以遵循提示词并完成任务。

如何理解 LLM 的命名约定

一些 LLM 有冗长、令人困惑的名称,但它们通常编码了有关模型架构、规模和能力的实用信息。一旦你知道如何解读它们,就比较和选择正确的模型会变得容易得多。

LLM 名称解析:系列、规模、激活、量化与精度
  • 数字通常表示模型中的参数数量。字母 B 代表十亿参数。
  • "Instruct" 表示该模型经过了指令微调。"Chat" 模型则针对多轮对话进行了优化。
  • 有些模型有"量化"版本,意味着模型权重被压缩以减少显存占用。
  • 有些模型名称包含年份、月份或日期,以表示模型发布或更新的时间。这有助于用户快速识别模型的代际。
  • MoE 模型有时在名称中包含两个数字,以描述专家系统的运作方式,例如 Qwen3.5-35B-A3B。这些数字通常表示:
    • 专家的总数
    • 推理期间激活的专家数量