小模型和大模型怎么选：微软生成式 AI 入门课第 19 课的判断维度

2026-08-18

要给一个功能挑模型的时候，最没用的动作是先去看参数量表和榜单。generative-ai-for-beginners 这个课程仓把选型这件事拆在了两个地方：02-exploring-and-comparing-different-llms/README.md 讲的是「按什么维度判断」，19-slm/README.md 讲的是小模型以及它能落到哪些部署形态上。这两处放在一起看，才是一条能走的路径。

先说清楚本文不引用什么。19-slm/README.md 里有一大段参数量与基准对比的内容（某个尺寸的模型在哪些 benchmark 上超过了谁），这类内容随模型迭代变动得很快，本文一个数字都不搬。本文只用两处文档里相对稳定的东西：判断维度，和部署形态的接口差异。

第一刀：课程直接写出的比较维度

第 02 课在讲文本生成模型时有一句很直接的告诫：不要只按发布时间或价格来选。它随后给出的比较项是任务质量、延迟、context window、工具调用能力、安全行为、区域可用性和总成本。这几项没有一项是「参数量」。

这一刀之所以重要，是因为它把注意力从模型本身挪到了你的约束条件上。区域可用性和总成本是业务约束，延迟和 context window 是工程约束，只有任务质量才和模型能力直接相关——而任务质量这一项，课程接着说了要在你自己的数据和工作负载上测，是一个实验与度量的迭代过程，不是查表能查出来的。

第二刀：Service 还是 Model

第 02 课有一节叫 Service versus Model，这一节其实决定了你后面所有的运维负担。课程的划分是：service 是云服务商提供的产品，通常是模型、数据和其它组件的组合，往往有图形界面，也往往要付费；model 则是神经网络工件本身——parameters、weights、architecture、tokenizer 以及配套配置。课程紧接着写明，在本地或私有环境跑一个模型，需要合适的硬件、serving 基础设施、监控，以及一份兼容的开源或开放权重许可或商业许可；开放权重模型可以自托管，但仍然需要算力和运维能力。

所以这一刀问的不是「哪个更好」，而是「这套东西谁来养」。你如果没有人来养 serving 与监控，讨论本地小模型的意义就不大。

第三刀：第 19 课列出的五个区分维度

19-slm/README.md 在 LLM 与 SLM 的差异一节里给了五个维度：Size、Comprehension、Computing、Bias、Inference。这五个维度里，有两个可以直接拿来做判断。

Comprehension：课程写明 SLM 通常是在特定领域内做优化，因此高度专门化，但跨多个知识领域提供广泛上下文理解的能力可能受限；LLM 则在多样数据上训练，覆盖面更广、适应性更强。翻译成决策语言就是：你的任务边界越窄越固定，这一维度对你的惩罚越小。

Bias：课程写明偏差是 LLM 的已知问题，主要来自训练数据；而 SLM 因为训练在更受限、更领域化的数据集上，天然不那么容易受这类偏差影响，但并非免疫。注意后半句——课程自己给了「并非免疫」这个限定，别把它读成小模型就没有偏差问题。

Inference 这一维度课程也写了，说小模型能在本地硬件上出结果、不需要大规模并行处理。这是课程正文的表述，我们没有跑过其中任何一个模型，所以不在本文里给任何性能结论。

从处境倒推：先改提示还是先换模型

第 02 课的 Improving LLM results 一节给了四条递进的路径：带上下文的提示工程、RAG、微调、从头训练。课程对这四条的定位很明确——提示工程加上下文是成本最低的起手式；RAG 适合数据在数据库或某个接口里、需要在提问时把相关片段拼进上下文的场景；从头训练是最难最复杂的一条，只有在你既有领域专属场景又有大量领域数据时才考虑。

微调这一条课程给了三个判据：一是想用更小的任务专用模型代替反复去调一个更大的前沿模型；二是延迟要紧，长提示或大量示例塞不进提示长度限制；三是你已经有大量高质量样例，希望模型稳定地遵循某种任务模式、输出格式、语气或领域风格。第三条后面跟着一句限定值得单独拎出来：如果你的主要问题是「新鲜事实」或「经常变化的私有知识」，那应该用 RAG，而不是只靠微调。

这三条判据里，第一条正好是小模型的典型入口——它把「换小模型」和「微调」绑在了一起，而不是把小模型当成大模型的廉价平替。

还有一处边界必须照实标出来：第 02 课在模型目录那一节带了一个 Note，写明目录里并非所有模型当前都支持微调和按量付费部署，具体要看 model card。也就是说上面那条微调路径不是对每个模型都成立的。

部署形态：同一条链路在几个地方分叉

19-slm/README.md 的后半部分把可选路线摊开了，每条路线在代码层面长得都不一样。

云端目录：Microsoft Foundry Models。 这里有一件容易踩的事：00-course-setup/03-providers.md 列出的作业标签清单里，githubmodels 这个标签的说明现在写的是「需要 Microsoft Foundry Models 的 endpoint 和 key」，也就是说文件名前缀和它实际接入的目标已经脱节了。仓库多处写明 GitHub Models 连同它的 GITHUB_TOKEN 变量已于 2026 年 7 月底退役，Microsoft Foundry Models 是直接替代者——按仓库文档给出的这个时点算，今天它已经过去了。所以照着带 githubmodels- 前缀的示例走的时候，.env 里要填的是 AZURE_INFERENCE_ENDPOINT 和 AZURE_INFERENCE_CREDENTIAL，不是那个已退役的 token 变量。

第三方推理服务：NVIDIA NIM。 19-slm/python/Phi-3-Vision-Nividia-NIM.ipynb 里没有用任何 SDK，就是 requests.post 打一个 invoke_url，请求头里放 Authorization，payload 是 messages 加上 max_tokens、temperature、top_p、stream。图片是先 base64 编码后直接内嵌进 message 的 content 里的——notebook 里还有一句 assert 限制编码后的长度，超了要改走 assets API。要注意这条路线上你的图片是完整上传给第三方服务的，密钥和数据边界得自己拿主意。

本地 Transformers。 19-slm/python/phi35-instruct-demo.ipynb 的写法是 AutoModelForCausalLM.from_pretrained 加 AutoTokenizer.from_pretrained，然后套一个 pipeline("text-generation", model=model, tokenizer=tokenizer)：

model = AutoModelForCausalLM.from_pretrained(
    "../phi-3-instruct",
    device_map="cuda",
    torch_dtype="auto",
    trust_remote_code=True,
)

generation_args = {
    "max_new_tokens": 1024,
    "return_full_text": False,
    "temperature": 0.3,
    "do_sample": False,
}

这几个值都是仓库示例里的取值，不是推荐配置。两处值得说：device_map="cuda" 是写死的，示例里没有给 CPU 分支，Windows 上如果手头没有 CUDA 设备，这一行就是你要自己改的地方；trust_remote_code=True 意味着会执行模型仓库里附带的自定义代码，用之前自己判断权重来源——这一句属于通用做法提醒，不是课程正文的内容。另外 temperature 和 do_sample: False 同时出现在一个 dict 里，课程正文没有解释这两者的相互关系，照抄之前建议对着你所用 transformers 版本的文档确认一下。同一目录下的 vision 示例走的是 AutoProcessor.from_pretrained(model_id, trust_remote_code=True, num_crops=4)，模型加载时还传了 _attn_implementation='flash_attention_2'，这几个也都是示例里的取值。README 自己也写明了这条路线需要 GPU 加速。

以上为按仓库代码中的接口语义组合的示例，未经实测，以仓库最新代码为准。

Ollama。 课程给的就是一行 ollama run phi3.5，没有别的。

Foundry Local。 这一条对 Windows 读者最直接，19-slm/README.md 和 00-course-setup/03-providers.md 给的安装方式是分平台的：Windows 用 winget install Microsoft.FoundryLocal，macOS 用 brew install microsoft/foundrylocal/foundrylocal；跑模型是 foundry model run phi-3.5-mini。也可以走 SDK：

from foundry_local import FoundryLocalManager

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

课程文档自述这个运行时会自动挑选可用的 execution provider（NPU、GPU 或 CPU），并暴露一个 OpenAI 兼容的 endpoint，因此原有的 openai 或 Azure AI Inference SDK 代码改动很小就能指过去。这句「改动很小」是仓库文档的说法，不是我们验证过的结论。

ONNX Runtime for GenAI。 这条路线的接口层次和上面几条不一样，它把 token 级循环交到你手里：og.Model 拿模型，og.Tokenizer 或 model.create_multimodal_processor() 处理输入，og.GeneratorParams 配参数（示例里用 params.set_search_options(max_length=3072)，这是仓库示例里的取值），然后是 generator.compute_logits() 与 generator.generate_next_token() 的显式循环。课程也提到它内置了 greedy 与 beam search、TopP 与 TopK 采样以及重复惩罚这类 logits 处理，并支持自定义打分。

这个差异什么时候会咬到你：采样参数不通用

前面那个 generation_args 里的 temperature，是本篇最值得停一下的地方。

06-text-generation-apps/README.md 里写明：当前 Microsoft Foundry 上未废弃的是 reasoning 模型（GPT-5 家族与 o 系列），它们不支持 temperature 和 top_p，也不支持 max_tokens（要改用 max_output_tokens），给 gpt-5-mini 传 temperature 会拿到一个「参数不支持」的错误。同一段又写明 temperature 和 top_p 在 Llama、Mistral、Phi 以及 GPT-4.x 家族上仍然有效，其中 GPT-4.x 正在弃用。

把这两处放在一起，结论就出来了：你在本地小模型路线上写熟的那套采样参数，在你把同一段调用指向云端 reasoning 模型的那一刻要拆掉；反过来，你如果先学的是 reasoning 模型那套写法，回到本地示例时会发现 temperature 又回来了。这不是版本升级带来的兼容问题，而是两条部署形态本来就落在不同的参数面上。做选型的时候，把「这段代码以后会不会换一条路线跑」也算进去，能省掉一次返工。

没有依据就不比的两项

总成本这一项，第 02 课把它列进了比较维度，但仓库里没有给具体价格与计费口径，本文也不写。「本地跑就更便宜」这个结论我们在课程仓里没有找到对应说明，不比。

准确率与质量排名这一项同理。19-slm/README.md 里确实有基准对比的段落，但那正是本文一开始就说明不引用的内容，所以「哪个更准」这一维度本文不比。课程给的做法是自己在自己的数据上测，这个建议本身比任何一张对比表都耐放。

收尾：三个问题

真要落到动作上，按顺序问自己三句就够了：这套东西谁来养（对应 Service 还是 Model）；任务边界有多窄（对应 Comprehension 那一维）；这段代码将来会不会换一条部署路线跑（对应采样参数那一节）。三个问题都答完，剩下的就是在你自己的数据上做实验，而不是继续翻表。

课程仓持续更新，上面涉及的文件路径、环境变量名、命令与接口写法都可能随版本变动，以仓库最新内容为准。

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

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

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