重要提示：如需以 Markdown 形式查看本页，请在 URL 后追加 `.md`。 完整文档索引见 llms.txt。
跳到主要内容
完整文档索引见 llms.txt。 在任意 URL 后追加 `.md` 即可查看该页面的 Markdown 版本。

选择合适的模型

在构建 AI 应用时，选择合适的 LLM 是最早需要做出的决策之一。

不同模型是为不同目的设计的。有些模型专注于文本生成，有些针对遵循指令进行了优化，还有一些强调效率或多模态任务能力。

模型浏览器
浏览热门开源 LLM，并查看它们的架构、规模、上下文长度和常见 GPU 部署方式。
DeepSeek-V4-Pro🤗
DeepSeek2026-04MoE
总参数量
1.6T
激活参数量
49B
上下文
1M
模态
Text
精度
FP4 + FP8 Mixed
许可证MIT
适用场景高级推理、编程与长周期 agent 工作流
后端
vLLM logoSGLang logo
硬件
8× H2008× B200

什么是基础模型？​

基础模型（base models），也称 foundation models，是大多数 LLM 的起点。它们通常通过无监督学习在海量文本语料上训练，而这种训练不需要标注数据。

在这个被称为预训练的初始阶段中，模型会学习通用语言模式，例如语法、句法、语义和上下文。它会获得预测下一个词（或 token）的能力，也能执行简单的 few-shot learning（只看少量示例后就处理任务）。不过，它此时还不理解如何遵循指令，也没有针对特定任务进行开箱即用的优化。

为了真正变得可用，这些模型通常还会在经过整理的数据集上继续微调，例如通过 instruction fine-tuning。基于基础模型，你可以得到：

  • Instruction-tuned models
  • Chat models
  • Fine-tuned domain models
  • RLHF aligned models

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

Instruction-tuned 模型 vs. chat 模型​

Instruction-tuned 模型构建在基础模型之上。在初始预训练阶段之后，这些模型会进入第二阶段训练，使用由指令及其对应响应组成的数据集。

这个过程会教会模型更可靠地遵循用户的 prompts， 从而更好地与人类预期对齐。它们能够理解任务意图，并更连贯地响应如下命令：

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

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

如果你在某个 LLM 名称中看到 “Instruct”，通常意味着该模型经过了 instruction-tuned。不过，“Instruct” 模型并不一定就是完整的聊天机器人。它们被优化来完成给定任务或遵循指令，而不是维持多轮对话。

相比之下，chat 模型通常还会进一步针对交互式聊天场景进行调优（通常使用对话数据以及 RLHF/DPO）。人们期望它们能跨轮次处理上下文，并与多个参与者交互。你可以阅读 Instruction and Chat Fine-Tuning 了解更多。

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

Dense 模型 vs. Mixture of Experts (MoE) 模型​

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

Mixture of Experts (MoE) 模型，例如 DeepSeek-V4 Pro， 则采用了与传统 dense 模型不同的方法。它们不会对每个输入都使用全部模型参数，而是包含多个专门化的子网络，也就是 experts，每个 expert 侧重于不同类型的数据或任务。

在推理期间，只有其中一部分 expert 会根据输入特征被激活。这种选择机制使模型能够更有选择性地路由计算，根据内容或上下文调用不同的 expert。结果是，MoE 模型能够通过在大规模网络中分配工作负载，在保持单次推理计算成本可控的同时，实现更强的可扩展性与效率。

模型类型工作方式优点缺点
Dense使用全部参数架构简单规模化成本高
MoE选择性激活 experts扩展效率高路由更复杂

将 LLM 与其他模型结合使用​

现代 AI 应用很少只使用单一 LLM。许多高级系统依赖将 LLM 与其他类型的模型组合起来，每种模型分别专注于不同模态或任务。这使它们能够超越纯文本生成，变得更强大、更多模态、更理解任务。

常见例子包括：

  • Small Language Models (SLMs)。适用于延迟和资源约束都重要的轻量任务。它们可以作为回退模型，或作为端侧助手，在不依赖完整 LLM 的情况下处理基础交互。
  • Embedding models。它们将输入（如文本、图像）转换为向量表示，因此适用于语义搜索、RAG 流水线、推荐系统和聚类。
  • Image generation models。Stable Diffusion 等模型可以根据文本提示词生成图像。与 LLM 配合后，它们可以支持更高级的文生图工作流，例如创意助手、内容生成器或多模态 agent。
  • Vision language models (VLMs)。NVLM 1.0 和 Qwen2.5-VL 等模型结合了视觉和文本理解，支持图像描述、视觉问答，或对截图和图表进行推理等任务。
  • Text-to-speech (TTS) models。它们可以将文本转换为自然语音。与 LLM 集成后，可用于语音 agent、无障碍界面或沉浸式体验。

进一步了解 multi-model inference pipelines。

去哪里获取模型​

当你知道自己需要哪一类模型后，下一个问题就很简单了：你到底去哪里找它们？

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

Hugging Face​

Hugging Face 是大多数团队的默认起点。它托管了数十万个开放模型，涵盖文本、视觉、音频和多模态任务。你可以在那里找到基础模型、instruct 模型、chat 变体、embedding 模型和 diffusion models。Hugging Face 还提供许多 fine-tuned 和 quantized model 变体，让你无需自己微调，就能轻松试验 instruction-tuned 模型或低 VRAM 模型。

人们使用它的原因：

  • 庞大的生态和社区采用度
  • 清晰的 model card，说明许可证、基准测试和适用场景
  • 大多数推理框架中的原生支持（例如 vLLM、SGLang、TensorRT-LLM）
  • 便于获取权重、配置和 tokenizer

需要注意的是，并不是 Hugging Face 上的所有模型都同样易于获取。有些模型完全开放，无需认证即可下载。另一些则是 gated 的，这意味着你必须接受特定许可条款，并使用 Hugging Face API token 才能访问权重。

通常会在以下情况下发生：

  • 模型带有限制性或自定义许可证
  • 作者希望知道是谁在使用模型
  • 模型仅面向研究用途或受控商业用途发布

在实践中，这意味着你可能需要：

  • 创建一个 Hugging Face 账户
  • 生成一个 API token
  • 将该 token 传递给你的 inference framework 或部署环境（例如通过 HF_TOKEN 这样的环境变量）

需要 gated 访问的模型通常伴随着更严格的使用条款、更少的运维打磨，或较弱的长期可用性保证。

一个简单经验法则是：如果某个模型需要 token 和人工审批，请在基于它构建之前，仔细确认它是否符合你的生产和法律约束。

其他还需要留意的事项：

  • 许可证差异（Apache-2.0、MIT、自定义）
  • 参数规模背后隐藏的 VRAM 需求
  • 有些模型是研究级的，并未准备好投入生产

在测试前务必阅读 model card。它会告诉你这个模型真正擅长什么，以及它不擅长什么。

ModelScope​

ModelScope 是由阿里巴巴运营的大型开放模型中心。它在以下方向上覆盖尤其强：

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

对于面向中文用户构建产品的团队，或在 Hugging Face 访问较慢或受限地区部署的团队，ModelScope 通常是首选。许多在这里发布的模型最终也会出现在 Hugging Face 上，但有些模型会在一段时间内优先出现在 ModelScope，甚至只在 ModelScope 提供。

OpenRouter​

OpenRouter 与其说是传统的“模型中心”，不如说它是一个模型访问层。

与其下载权重并自己运行模型，不如通过 OpenRouter：

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

这对于早期原型开发、A/B 测试，或在决定是否自托管前评估模型都很有帮助。不过，如果你需要在规模化场景下严格控制性能、数据或成本，它并不能替代你自己掌握推理栈。

模型权重格式​

下载开源 LLM 时，你通常下载的是它的权重。模型权重是训练中学习得到的参数，存储了模型获取的知识。它们通常以可由推理框架加载的文件形式分发。

在 LLM 生态中，常见的权重格式有几种。

PyTorch checkpoints​

许多模型最初以 PyTorch checkpoint 文件形式发布，常见扩展名包括：

pytorch_model.bin
model.pt

这些文件以 PyTorch 可直接加载的序列化格式存储模型参数。不过，传统 checkpoint 格式存在一些缺点：

  • 加载速度可能较慢
  • 可能需要反序列化步骤
  • 某些格式允许任意代码执行，这会带来安全风险

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

Safetensors​

Safetensors 现在已成为分发 LLM 权重最广泛使用的格式之一。它由 Hugging Face 推出，作为 PyTorch checkpoints 的安全且快速的替代方案。

关键特性：

  • 避免任意代码执行，实现安全加载
  • 支持快速 memory mapping，从而高效加载权重
  • 获得 vLLM、TensorRT-LLM 和 SGLang 等推理框架的广泛支持

示例文件：

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 的文件。这个文件充当映射索引，告诉加载器每个参数张量存储在哪个位置。对于大多数用户而言，这一过程由推理框架自动处理。不过，理解这个索引文件在以下情况下会有帮助：

  • 排查模型加载问题
  • 修改模型权重
  • 处理自定义 checkpoint

GGUF​

GGUF 是一种为高效本地推理设计的模型格式，尤其适合 llama.cpp 这样的工具。GGUF 模型通常具有以下特征：

  • 经过量化以减少内存使用
  • 针对 CPU 或小型 GPU 环境做了优化
  • 常用于本地运行模型

示例文件：

model.Q4_K_M.gguf

量化类型（例如 Q4、Q5 或 Q8）表明模型权重被压缩的激进程度。

常见问题​

基础模型和 instruct 模型有什么区别？​

基础模型在原始文本上完成预训练，学习语言模式。Instruct 模型则经过微调，能够遵循 prompts 并完成任务。

如何理解 LLM 命名约定​

有些 LLM 的名字很长、很难懂，但其中通常编码了关于模型架构、规模和能力的有用信息。一旦你学会如何阅读这些名字，比较模型并选择合适模型就会容易得多。

LLM 名称的构成：系列、规模、激活方式、量化与精度LLM 名称的构成：系列、规模、激活方式、量化与精度
  • 数字通常表示模型的参数数量。字母 B 代表十亿参数。
  • “Instruct” 表示该模型经过了 instruction-tuned。“Chat” 模型则针对多轮对话做了优化。
  • 有些模型提供“quantized” versions，意味着模型权重经过压缩，以减少内存占用。
  • 有些模型名称中包含年份、月份或日期，用来表示模型发布时间或更新时间。这有助于用户快速识别模型代际。
  • MoE 模型有时会在名称中包含两个数字，用来描述 expert 系统的工作方式，例如 Qwen3.5-35B-A3B。这些数字通常表示：
    • expert 的总数
    • 推理期间被激活的 expert 数量
编辑此页