微软生成式 AI 入门课第 2 课怎么给大模型分类：五个维度对到选型问题
先说清楚这篇要解决的问题。你下周要给一个功能选模型，翻开 generative-ai-for-beginners 的 02-exploring-and-comparing-different-llms/README.md，看到一串分类：foundation model 和 LLM、开放权重和闭源、embedding 和图像生成和文本生成、encoder-decoder 和 decoder-only、service 和 model。看完的直观感受通常是「知道了，然后呢」。
问题出在读法上。这几节读起来像并列的分类学，其实每一条各自回答的是一个不同的选型问题，彼此之间不在同一个平面上。下面按「这一刀切下去是为了回答什么」重排一遍，并尽量落到仓库里能翻到的具体文件和字段上——课程持续更新，文中涉及的路径与变量名请以仓库最新内容为准。
先数清结构：在 ## Understand different types of LLMs 这一级标题下面，README 挂了五个 ### 小节（foundation model 与 LLM、开放权重/开源与专有、embedding 与图像生成与文本代码生成、encoder-decoder 与 decoder-only、service 与 model）。在这五节之前还有一段不带小标题的列表，按模态列了语音识别、图像生成、文本生成、多模态四类。所以严格说是「一段按模态的引子 + 五个维度」，很多人把引子和第一个小节混在一起，才会觉得分类互相重叠。
第一刀：输入输出是什么模态
这是引子那段列表在做的事，也是唯一一条必须在动手写代码之前定死的。README 在多模态那一段的结尾写得很直白：在围绕某个模型搭工作流之前，永远要去看它的 model card 上写的输入输出模态支持。
这句话听着像废话，但它是这一课里少数带「必须」语气的操作建议。理由也不难理解：模态决定了你调用的是哪个 API 形状，模态选错，后面所有代码都要推倒。而课程正文在文本生成、图像生成那几段点名的模型只是写作当时的举例，不是一份可以照抄的选型清单——这类名单变动很快，抄下来大概率已经过期。README 自己给的判据反而更耐用：不要只按发布日期或价格挑，要比任务质量、延迟、上下文窗口、工具调用、安全行为、区域可用性和总成本。这几条里没有一条能从模型名字上看出来，全都得自己去试。
第二刀：这个模型是终点还是起点
foundation model 那一节引的是 Stanford 那篇论文给的判据，README 列了三条：用无监督或自监督方式在未标注的多模态数据上训练、模型规模很大、通常是被当作「地基」供其它模型在其之上构建，构建方式之一就是 fine-tune。
翻译成选型问题就是：你打算把它当成成品直接调，还是当成起点再训一层。这条维度决定的是后面第 18 课那类工作要不要做，跟你调 API 的写法关系不大。
但同一节末尾有一句更实用的提醒，读的时候容易滑过去：服务名和底层模型名并不总是同一个东西。这句抽象话在配置里是能直接看到形态的——00-course-setup/03-providers.md 的变量表里，Azure OpenAI 那条路线要填的是 AZURE_OPENAI_DEPLOYMENT，它是你在门户里创建的部署名，文档明确写这个名字「通常和模型名相同，除非你显式改过」。也就是说，配置里躺着的那个字符串是部署名而不是模型名，两者只是碰巧常常一样。排查「我配的模型和实际跑的对不上」这类问题时，这是第一个要确认的地方。
第三刀：权重能不能拿到手
开放权重/开源与专有那一节，README 花了不少篇幅强调许可差异：开源和开放权重不是一回事，有的是完全开源，有的是带使用限制的开放权重；即便拿到了权重，团队仍然要在投产前审许可条款、serving 成本、维护、安全更新和评估质量。专有模型那边则是另一组要审的东西——通常看不到也改不了权重，得去读 provider 关于隐私、数据留存、合规和可接受使用的条款。
所以这一刀回答的问题是：数据要落在哪、能不能自己托管、法务那关怎么过。它和模型效果基本无关，和你的部署边界完全相关。
值得一提的是，第 16 课 16-open-source-models/README.md 的 ## How to Choose 一节并没有给出结论式的答案，开头第一句就写「选开放模型没有唯一答案」，给的起步动作是用 Microsoft Foundry 模型目录的按任务筛选功能，先弄清模型是为哪类任务训练的。这一节确实也提到了 Hugging Face 维护的 LLM Leaderboard 与第三方对比站点，但它把这些放在「参照物」的位置上，落地动作写的是另外两条：针对具体用例去找同领域的微调版本，以及拿多个开放模型按你和你的用户的预期实际试一遍。想直接抄一份排行照单下单的读者会失望，不过这个态度和第 2 课是一致的。
第四刀：输出的是什么东西
「embedding 与图像生成与文本代码生成」这一节，初读最像在重复第一刀。真正的区别在于它落到代码上是两套调用，而不是同一套调用的两个参数。
课程仓里可以直接对照。08-building-search-applications/python/aoai-solution.ipynb 里构造 AzureOpenAI 客户端之后，模型名取的是 os.environ['AZURE_OPENAI_EMBEDDINGS_DEPLOYMENT']，实际调用走的是 client.embeddings.create(...)；而 06-text-generation-apps 那一课的文本生成调用走的是 client.responses.create(...)。对应到根目录 .env.copy，文本生成和向量检索各有一个独立变量：AZURE_OPENAI_DEPLOYMENT 与 AZURE_OPENAI_EMBEDDINGS_DEPLOYMENT，03-providers.md 的变量表逐条写了两者的含义。文档在 Foundry 门户那一节给出的推荐部署是 gpt-5-mini 和 text-embedding-3-small——这是仓库文档当前给出的推荐值，不是必须照抄的配置，也随课程更新变动。
所以「按输出类型分类」在工程上的形态就是：一个应用里往往要同时部署两个模型、在 .env 里配两个变量、在代码里走两个不同的 client 方法。第一刀关心的是「能不能接受图片输入」，第四刀关心的是「产出的是向量还是文本」，两者切的不是同一块。
第五刀：架构上是续写还是理解
encoder-decoder 与 decoder-only 这一节用的是出题和审题的比喻：decoder-only 像写内容的人，能看着题目和已经写出来的部分继续往下生成，但在只需要分类、检索或编码的任务上不总是最合适的选择；encoder-only 像审稿的人，能看懂内容和答案之间的关系，但不擅长生成；两者都能干的是 encoder-decoder。举例上，decoder-only 举了 GPT 和 Llama 家族，encoder-only 举了 BERT，encoder-decoder 举了 BART 和 T5。
这一节需要照实说一句边界：README 给到的是比喻和举例，至于「拿到一个陌生模型，怎么判断它属于哪一类」，我们在这一课里没有找到对应的操作说明。真要判断，还是得回到第一刀那句话——去读 model card。
第六刀：你买的是端点还是工件
service 与 model 这一节的定义值得原样记住：service 是云厂商提供的产品，通常是模型、数据和其它组件的组合；model 则是神经网络工件本身——README 列的是 parameters、weights、architecture、tokenizer 以及支撑性的配置。在私有环境里跑一个模型，需要合适的硬件、serving 基础设施、监控，以及一份兼容的开源/开放权重许可或商业许可；开放权重模型可以自托管，但仍然要有算力和运维能力。
这一刀直接决定你的 .env 长什么样。00-course-setup/03-providers.md 写明作业文件名会带 provider 标签：aoai 需要 Azure OpenAI 的 endpoint 和 key，oai 需要 OpenAI 的，hf 需要 Hugging Face token，githubmodels 这个标签则是本课程眼下最容易踩的一处。
这里必须交代清楚：githubmodels- 这个前缀现在名不副实。03-providers.md 在标签表里逐字写的是 githubmodels 需要的是「Microsoft Foundry Models 的 endpoint 和 key」，并在括号里注明 GitHub Models 将于 2026 年 7 月底退役；文档正文的 provider 列表里也写明 Microsoft Foundry Models 取代了 GitHub Models。今天是 2026-08-18，这个时间点已经过去了。对应到 .env.copy，这条路线要填的两个变量是 AZURE_INFERENCE_ENDPOINT 和 AZURE_INFERENCE_CREDENTIAL，不是任何形式的 GitHub token。看到带 githubmodels- 前缀的示例文件，请按 Microsoft Foundry Models 那条路线去配。
所以「三条路线怎么选」的现状是：OpenAI 直连、Azure OpenAI、以及 Microsoft Foundry Models（原 GitHub Models 路线）。此外 03-providers.md 还列了 Hugging Face，以及 Foundry Local 和 Ollama 这两个完全离线跑在自己设备上的选项——后者正好是「你买的是工件而不是端点」那一侧的具体落地。
一个会咬人的连锁反应
上面几刀切完，还有一层不在第 2 课里、但会立刻影响代码的东西：这一代模型接不接受你的老参数。
06-text-generation-apps/README.md 写得很明确：当前 Microsoft Foundry 上未废弃的模型是 reasoning 模型（GPT-5 家族、o 系列），它们不支持 temperature 和 top_p，也不支持 max_tokens（要改用 max_output_tokens）；文档写明，把 temperature 发给 gpt-5-mini 会拿到一个「参数不支持」的错误。想跑通那一节的 temperature 例子，文档给的做法是把请求指向仍然支持采样控制的模型。
也就是说，模态和输出类型选完之后，还得确认一遍参数集合。这条在选型时通常没人提，但它是最先把人绊倒的一处。
# 仓库 06 课示例里的调用形态
response = client.responses.create(model=deployment, input=prompt, max_output_tokens=100, store=False)
以上为按仓库代码中的接口语义组合的示例，未经实测，以仓库最新代码为准。
环境准备的一点差异
03-providers.md 给的建立配置文件的命令是 cp .env.copy .env，写的是 POSIX 形态。Windows 上，PowerShell 里 cp 是 Copy-Item 的别名所以同样可用，传统 cmd 下则要用 copy——这一句是通用做法，不是该项目官方内容，以你本机 shell 的实际行为为准。另外这份 .env 是被 gitignore 掉的，文档特意点了这一点；填进去的密钥请当成真密钥对待，示例里一律写成 <YOUR_API_KEY> 这样的占位。
落到实际怎么用
把六刀按「先定死、后可调」的顺序排一遍，大致是：模态先定（决定 API 形状）→ 输出类型定（决定要部署几个模型、.env 里配几个变量）→ 权重归属定（决定数据边界与许可审查）→ service 还是自托管定（决定运维负担与 provider 标签）→ 是否 fine-tune（决定要不要把它当起点）→ 最后核一遍参数集合。
架构那一刀（encoder-decoder 与 decoder-only）在这个顺序里更像是背景知识而不是决策点，因为课程没给判定方法，实际还是回到 model card。这不是课程的疏漏，只是它在这一课的定位是解释「为什么有些模型不擅长生成」，不是给你一个筛选器。
本文依据 github.com/microsoft/generative-ai-for-beginners 仓库于 2026-08-18 的公开内容整理，
事实来自仓库内的课程正文与代码示例。我们没有跑过文中涉及的代码，
因此不涉及运行结果、耗时与生成质量的任何描述。
该课程持续更新，文中涉及的文件路径、依赖与接口写法随版本变动，请以仓库最新内容为准。
文中涉及的云端服务调用会产生费用并可能上传数据，请自行评估密钥与数据边界。
许可条款请以仓库 LICENSE 原文与你所在组织的要求为准，本文不构成法律意见。