开源模型和闭源 API：微软生成式 AI 入门课第 16 课把差异落在哪几处

翻到 16-open-source-models/README.md 的时候，多数人是带着一个具体问题来的：手上这个项目，到底该接一个托管 API，还是自己拉一个开放权重的模型跑。这一课的 How to Choose 一节把话说得很直白——课程自述没有唯一答案，建议先按任务类型去模型目录里筛，再拿几个模型试。这个回答没错，但它不解决你今晚要不要在 .env 里多填两行的问题。

好在这套课程是有代码的。同一个仓库里，两条路线都留下了可以逐字核对的痕迹：环境变量怎么配、进程在谁的机器上跑、哪些参数你调得动。下面就沿着这三处走一遍，全部内容以仓库最新版本为准。

一、获取方式：差别写在 .env.copy 的变量数量上

先看仓库根目录的 .env.copy。它把课程支持的几条路线并排列了出来，OpenAI 那条只有一个 OPENAI_API_KEY；Azure OpenAI 那条要 AZURE_OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT，再加 AZURE_OPENAI_DEPLOYMENT 和 AZURE_OPENAI_EMBEDDINGS_DEPLOYMENT 两个 deployment 名；另外还有一个 AZURE_OPENAI_API_VERSION，文件里给了默认值（这是仓库当前文件里的默认值，随版本可能变动）。开放模型这一侧则是 HUGGING_FACE_API_KEY。

00-course-setup/03-providers.md 对这个变量还专门补了一句自述：它技术上并不是 API key，而是用于认证的 token，只是为了命名一致才沿用了这个叫法。这句话本身就说明了两条路线的取得逻辑不同——一边是服务商发给你的调用凭证，一边是模型托管平台上的身份令牌。

这份文档还讲了作业文件名前缀的规矩：aoai 需要 Azure OpenAI 的 endpoint 与 key，oai 需要 OpenAI 的，hf 需要 Hugging Face token，githubmodels 需要的是 Microsoft Foundry Models 的 endpoint 与 key。这里要停一下：githubmodels- 这个前缀现在已经名不副实。仓库文档在多处逐字写明 GitHub Models 于 2026 年 7 月底退役，直接替代者是 Microsoft Foundry Models；06-text-generation-apps/python/githubmodels-app.py 的开头注释也把这句话写在了取值说明旁边，代码里读的是 AZURE_INFERENCE_CREDENTIAL 和 AZURE_INFERENCE_ENDPOINT，不是任何 GitHub 的 token。看到这个前缀别去找 GitHub 的设置页，要配的是 Foundry 项目 Overview 页上的 endpoint 和 key。

还有一条容易被跳过：03-providers.md 的 signup 表里，Foundry Local 那一行的 API Key 一栏写的是 Not required。这就是获取方式上最硬的一道分界——开放模型这条路可以走到「不需要向任何人申请凭证」。

二、部署责任：进程跑在谁的机器上

03-providers.md 开头把托管这条路线定义得很清楚：provider 提供一个 hosted endpoint，你拿凭证去程序化访问。责任边界在这里其实不是一刀切的——OpenAI 那条你直接用模型名；Azure OpenAI 那条你得先在 Foundry 门户里把模型 deploy 出来，再把 deployment 名字填回 .env。也就是说闭源侧你已经承担了一半的「部署」动作，只是部署的是别人托管的模型实例。

开放模型这一侧，课程把动作放在了 19-slm/README.md 里。Ollama 那段只有一行：

ollama run phi3.5

Foundry Local 那段区分了平台。Windows 侧文档给的是 winget：

winget install Microsoft.FoundryLocal
foundry model run phi-3.5-mini

macOS 侧在 03-providers.md 里给的是 brew install microsoft/foundrylocal/foundrylocal。想在 Python 里直接管理，文档给的是装 foundry-local-sdk，然后：

from foundry_local import FoundryLocalManager

manager = FoundryLocalManager("phi-3.5-mini")
print(manager.endpoint, manager.api_key)

注意 FoundryLocalManager 会把 endpoint 和 api_key 打出来——文档自述它暴露的是一个 OpenAI 兼容的 endpoint，所以课程里大部分示例代码只要改客户端初始化就能指过去。这一点对做技术决策的人很重要：换路线的改动量不在业务代码，而在配置层。

再往下还有一层责任，是 ONNX Runtime for GenAI。19 课给的装法是 pip install onnxruntime-genai，用法是 og.Model 载入模型、og.Tokenizer 建分词器、再 model.generate 拿 token。走到这一层，模型格式转换、执行提供程序的选择都归你了。同一课也把代价说得很直白：课程自述这条路需要 GPU 加速，且如果不做量化、在 CPU 上跑 Vision 和 MoE 这类场景会很慢。这两句都是仓库文档里的原话，我们没有跑过任何一条，不做延伸判断，也不给出任何资源需求的量化结论。

三、可控性：一个反例比十条论述管用

06-text-generation-apps/README.md 里有一处特别值得单独拎出来。文档写明，当前 Foundry 上未废弃的模型是 reasoning 模型（GPT-5 家族、o 系列），它们不支持 temperature 和 top_p，也不支持 max_tokens（要改用 max_output_tokens）；给 gpt-5-mini 传 temperature 会拿到参数不支持的报错。那这一课的 temperature 教学怎么办？文档给的解法是：把示例指向一个仍然支持采样控制的开放模型，例如 Foundry 模型目录里的 Llama 模型，走 Foundry Models / Azure AI Inference 的 endpoint 调用。

.env.copy 里也为此留了一个变量 AZURE_INFERENCE_CHAT_MODEL，注释写明它要填一个支持 temperature/top_p 的非 reasoning 模型部署名，供 temperature 示例使用。一门讲托管 API 的课，为了演示一个基础采样参数不得不绕到开放模型上——可控性的差异到这一步就不用再论证了。

另一头看微调。18-fine-tuning/python/openai/oai-assignment.ipynb 用的是 OpenAI Python SDK 指向 Foundry 的 /openai/v1/ 端点，流程是 client.files.create(..., purpose="fine-tune") 上传训练与验证文件，然后：

job = client.fine_tuning.jobs.create(
    model="gpt-4.1-mini",              # base model to fine-tune
    training_file=training_file_id,
    validation_file=validation_file_id,
    suffix="elements-limerick",        # helps you identify the resulting model
    seed=105,                          # makes the run reproducible
    extra_body={"trainingType": "GlobalStandard"},
)

这里的模型名、suffix 和 seed 都是仓库示例里的具体取值，照抄没有意义，换到你自己的场景要重填。关键在于产物形态：你拿到的是一个 job id，之后用 client.fine_tuning.jobs.retrieve 查状态、client.fine_tuning.jobs.checkpoints.list(job_id) 列出可部署的 checkpoint，最后 notebook 的 Step 3.2 写明 Foundry 这条路必须先把模型 deploy 出来、用 deployment 名字调用，而 OpenAI 平台可以直接用返回的 fine-tuned model id。全程你手里没有权重文件，只有一串 id。

对照 16 课开头列的那份判定条件：要算传统意义上的开源，训练数据集、完整权重、评估代码、微调代码、训练指标都得公开。课程自述当前满足全部条件的模型很少，所以它后文一律改称 open models。这句限定很要紧——你从开放这一侧拿到的经常只是权重，而不是那一整套；把「开源」直接等同于「什么都能改」，会在合规审查那一关被打回来。

02-exploring-and-comparing-different-llms/README.md 把这层意思补全了：开放权重与开源模型让你可以检视、下载、定制，适合需要更多部署、数据驻留、成本和定制控制权的场景，但许可条款各不相同，团队仍要自己审许可、服务成本、维护、安全更新与评估质量；闭源模型由服务商拥有并托管，通常客户无法检视或修改权重，需要去审服务商关于隐私、留存、合规和可接受使用的条款。

四、倒着推：你的处境落在哪一格

把上面三处翻译成判断顺序，比记参数表管用：

第一问，你能不能持有凭证。 如果数据不许出网、或者拿不到任何云账号，那托管这两条路在第一步就走不通了，直接看 Foundry Local / Ollama 这一支——03-providers.md 明写这条不需要 API key、不需要订阅。这一问一票否决，先问它。

第二问，你想不想管进程。 托管这条你只管 endpoint 和 key；本地这条你要管安装、模型拉取、执行提供程序的选择，走到 ONNX 那一层还要管格式转换。托管侧还有一笔容易忘的账：微调 notebook 里写明部署好的自定义模型按时长计费、闲置的部署会被自动移除，具体计费口径与时限以官方文档为准。

第三问，你要改的是哪一层。 只是改提示词和输出格式，两条路都够用；要动 temperature、top_p 这类采样参数，就得先看目标模型是不是 reasoning 模型，这一层限制在托管侧是硬的；要拿到权重做二次分发或离线定制，那只有开放模型这一侧能满足，代价是许可与安全更新全归你审。

顺序不能颠倒。见过不少人先挑模型再发现凭证批不下来，白折腾一轮。

五、这些维度我们不比

16 课里引了 Artificial Analysis 的价格与质量图，Hugging Face 也有排行榜。这类数字变动太快，本文不引用具体数值，也不据此给模型排名。同样，两条路线的速度、延迟、显存占用、生成质量，我们没有跑过任何一条，一个字都不写。课程自述的建议是拿你自己的用例去试几个模型——这句话我们同意，但那是你要做的事，不是本文能替你给的结论。

以上代码片段均按仓库代码中的接口语义引用，未经实测，以仓库最新代码为准。

---

本文依据 github.com/microsoft/generative-ai-for-beginners 仓库于 2026-08-18 的公开内容整理， 事实来自仓库内的课程正文与代码示例。我们没有跑过文中涉及的代码， 因此不涉及运行结果、耗时与生成质量的任何描述。 该课程持续更新，文中涉及的文件路径、依赖与接口写法随版本变动，请以仓库最新内容为准。 文中涉及的云端服务调用会产生费用并可能上传数据，请自行评估密钥与数据边界。

本文对照的是同一项目内的两种用法，依据均为上述仓库内容，不对两种用法做优劣排名， 选型结论只在仓库文档写明的能力边界内成立。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。

许可条款请以仓库 LICENSE 原文与你所在组织的要求为准，本文不构成法律意见。