开源模型不是「省钱版 Claude」，是另一套有自己工程纪律的运行时。
2026 年的开源权重已经不是玩具：DeepSeek-V3 / R1、Qwen3、Llama、Mistral 在很多任务上逼近闭源 SOTA。但「能在 leaderboard 上接近」和「能在你的生产线上替代 Claude」之间隔着一整层工程。多数人栽在三个错觉上：以为开源 = 省钱（其实是换来控制权、隐私、可微调，同时背上运维与质量风险）；以为下载下来就能跑（其实卡在显存数学和量化损失）；以为 Claude 的 prompt 直接搬过去就行（其实 chat template、tool use、结构化输出全要重做）。这一期不讲「Llama 是什么」——那是 ai-ml-daily 的活。我们讲四件工程事：什么任务开源真够用、License 是隐藏约束、量化与显存的真实账、prompt/tool 移植的脆弱性、以及 MoE 与 reasoning 模型的自建现实。
先把「该不该上开源」拆成两个独立问题。能力问题：开源在「短、闭、可验证」的任务上已经够用——分类、抽取、固定 domain 的 RAG 问答、翻译、改写、中等难度代码补全。它在「长、开、需要连续决策」的任务上仍有明显 cliff——多步 agentic loop、复杂 tool orchestration、前沿 reasoning。原因不是单点能力差，是误差累积：闭源模型每步 95% 对、开源每步 88% 对，跑 20 步后差距从 7pp 放大成灾难。
License 问题比多数人以为的关键。Llama 用的是 Meta 自家的 community license，不是 OSI 开源协议：它有一条 700M 月活上限（超过就得单独找 Meta 授权），还禁止用 Llama 的输出去训练 / 蒸馏任何非-Llama 模型——这条直接掐死「拿 Llama 生成合成数据训自己模型」的路。相比之下 Qwen、Mistral 多为 Apache 2.0，DeepSeek 系多为 MIT，干净得多。如果你的计划包含蒸馏、合成数据、或可能做大，License 选型要排在能力评测前面。
# 30 秒选型决策（贴在项目里）
# 用开源当且仅当 ≥1 条成立：
- 数据不能出本地/合规要求严 # 隐私是开源最硬的理由
- 任务固定且高频，值得微调一个专用小模型
- 调用量大到闭源 API 成本结构不可接受
- 需要确定性/可复现/锁版本（闭源会悄悄换模型）
# 任务能力 cliff（经验，非绝对）：
够用: 分类 / 抽取 / 翻译 / 改写 / 固定RAG / 单步代码
谨慎: 3-8 步 workflow（用 workflow 而非 agent 兜）
别碰: 长 agentic loop / 复杂多工具编排 / 前沿数学推理
# License 先于能力：
要蒸馏/合成数据/可能做大 → 避开 Llama，选 Qwen(Apache) / DeepSeek(MIT)显存预算分三块：权重（params × bytes/param）+ KV cache（随 context 长度和并发线性涨）+ activation/框架开销。一个 32B 模型 FP16 光权重就 64GB，单卡放不下；量化到 4-bit 后权重压到约 16GB，才进消费级双卡甚至单张 24G 卡的范围。所以量化不是「可选优化」，是开源能不能落地的前提。
量化格式分两条线。weight-only 低 bit：GGUF（llama.cpp 生态，CPU/Mac/混合推理首选）、AWQ / GPTQ（4-bit，GPU 推理，AWQ 的思路是只保护约 1% 的 salient 权重就能大幅降误差）。FP8：精度损失最小，但要较新 GPU。经验甜点是 4-bit（如 GGUF 的 Q4_K_M）：质量损失通常可忽略；低于 4-bit（Q3/Q2）后退化陡峭，尤其打击 reasoning 和长输出。Runtime 也分场景：llama.cpp / Ollama 灵活、装得快、适合本地与单用户；vLLM 靠 PagedAttention 做高吞吐 continuous batching，是生产并发的默认选择——两者不要混用场景。
# 显存粗估：能不能在我的卡上跑
def vram_gb(params_b, bits=4, ctx_k=8, batch=1):
weights = params_b * bits / 8 # 权重
kv = 0.5 * ctx_k * batch # KV cache 粗估(GB)，随模型变
return round((weights + kv) * 1.2, 1) # ×1.2 框架开销
vram_gb(32, bits=4, ctx_k=8) # → ~20.6G：单张 24G 卡勉强够
vram_gb(70, bits=4, ctx_k=32) # → ~62G：要双卡或 A100
# 生产部署用 vLLM 而非 Ollama 扛并发
# vllm serve Qwen/Qwen3-32B-AWQ --quantization awq --max-model-len 16384三个最常被低估的坑。① chat template：每个开源模型有自己的对话特殊 token（system/user/assistant 边界、tool 段格式）。用错 template——比如套了别的模型的格式、或自己手拼字符串——模型不会报错，只会悄悄变笨。务必用官方 tokenizer 的 apply_chat_template，别手写。② tool use / function calling：开源模型的工具调用比 Claude 脆得多，JSON 经常少括号、字段名漂移、夹杂解释文字。靠 prompt「请只输出 JSON」远不够。③ few-shot 权重：闭源模型 zero-shot 能扛的指令，开源往往要 2-3 个 example 才稳——Examples > Rules 在开源上更极端（Day 9 讲过）。
对②的工程解法是受约束解码（constrained decoding）：在 sampling 时把不合法的 token 概率直接置零，从机制上保证输出合法 JSON / 符合给定 grammar。vLLM 内置 guided decoding，底层常用 XGrammar 这类引擎，能做到近零开销。这把「祈祷模型守格式」变成「物理上不可能违格式」——和 Day 3 讲的 permission gate 同一种思路：能力别交给模型自觉，交给运行时强制。
from openai import OpenAI # vLLM 暴露 OpenAI 兼容端点
client = OpenAI(base_url="http://localhost:8000/v1", api_key="x")
# ① 永远用官方 chat template（transformers）
# prompt = tokenizer.apply_chat_template(msgs, tokenize=False,
# add_generation_prompt=True) # 别手拼 <|im_start|> 这类 token
# ② 受约束解码：从机制上保证合法 JSON，而不是靠提示
schema = {"type":"object",
"properties":{"sentiment":{"enum":["pos","neg","neutral"]},
"score":{"type":"number"}},
"required":["sentiment","score"]}
r = client.chat.completions.create(
model="Qwen/Qwen3-32B-AWQ",
messages=[{"role":"user","content":"这家店服务太慢了"}],
extra_body={"guided_json": schema}, # ← vLLM 受约束解码
) # 输出保证可 json.loads，无需正则兜底MoE 的两笔账要分开。DeepSeek-V3 是 671B 总参数、每 token 只激活 37B（采用 MLA + auxiliary-loss-free 负载均衡，见技术报告）。这意味着：算力/吞吐按激活的 37B 算，便宜；但显存得装下全部 671B 专家——哪个专家被路由到无法预知。所以 MoE 是「数据中心友好、单机不友好」：它优化的是规模化吞吐，不是让你在一张卡上跑大模型。本地想跑大 MoE 基本是误区。
Reasoning 模型的 token 账。DeepSeek-R1（arXiv:2501.12948）证明纯 RL 能逼出 self-reflection、verification 等推理行为，质量很高——但代价是思维链 token 爆炸：一个简单问题可能先吐几千 reasoning token。自托管 R1 级模型，你为每次调用的长思考付全额算力。工程现实是：与其自托管满血 reasoning 模型，不如用官方放出的蒸馏版（R1 蒸馏到 Qwen / Llama 的小模型），把推理能力压进能在你卡上跑的尺寸；或者在 prompt 层控制 reasoning budget，简单任务直接关掉思考模式（Qwen3 的 hybrid thinking/non-thinking 就是为此设计）。
# MoE：分开算两笔账
total_params = 671 # → 决定显存（要装下全部专家）
active_params = 37 # → 决定每 token 算力/吞吐
# 结论：MoE 适合数据中心规模化，不适合单机自托管大尺寸
# Reasoning：先问「这任务值得思考吗」，再决定开不开 CoT
# 简单分类/抽取 → 关思考，省 90% token
# 复杂数学/调试 → 开思考，但设上限防失控
# 自建路线优先级：
# 蒸馏版小模型(能跑) > 满血自托管(贵) > 按需调云端 reasoning API挑一个你已经在用 Claude 跑的「短闭可验证」任务（如评论情感分类、发票字段抽取），完整搬一遍，亲手摸这一期四个坑：
vram_gb() 估算尺寸；本地验证用 Ollama 拉 Q4_K_M，确认能跑后再上 vLLM + AWQ 做并发基准。apply_chat_template，把 Claude 的 system prompt 砍短、补 2-3 个 few-shot example，输出用 guided_json 受约束解码锁死格式。跑完这一套，你对「开源能不能替代闭源」的判断会从直觉变成数据：不是信仰之争，是每个具体任务上的 task-cliff + 成本 + 合规三维权衡。
"uncertain" 枚举或 confidence 字段给模型逃生，别用格式合法性冒充正确性。