大模型不是AI,是硬盘上的一个文件夹

先接受一个反直觉的事实：那个会思考的东西，现在是死的

从 Hugging Face 拖一个 Qwen2.5-72B 下来，解压，你会看到一个文件夹。里面躺着 config.json（说明书）、tokenizer.json（文字和数字之间怎么换算的规则），还有 model-00001-of-00030 一直排到 model-00030-of-00030 的那一串 .safetensors 文件——模型的本体就在这些文件里，一堆二进制数字。

72B 的意思是 720 亿个参数，720 亿个数字。按 FP16、每个数字两字节粗算，光权重就得一百多 GB，一个文件装不下，于是被切成三十片。整体几十 GB 到几百 GB 的量级，下载一次，差不多等于搬几十部蓝光电影回家。

关键的一点是：这堆东西不通电。

躺在硬盘上的它不会动、不会思考，用原文的说法，像一张大脑切片的扫描图——记录了大脑长什么样，但这个大脑还没通电。

这个还原动作改变的是问题的性质。如果本体是一堆静态数字，那「智能」就不是一种实体，而是一种运行状态；以后你听到任何关于模型能力的判断，都该顺手补上三个限定：以什么精度、跑在哪台机器上、被哪个程序加载。

再往下一层：正因为它是可拷贝、可分片、可压缩、能塞进移动硬盘带走的文件，它才是资产而不是服务。这一个区别，几乎预先决定了后面所有的成本和议价问题。

通电那一步由一个最不起眼的角色完成：推理框架

推理框架是个程序，干的活儿就三件：把权重读进内存和显卡，让那个大脑通电；管性能——显存管理、请求排队、批量处理、KV Cache 缓存加速，让几十个人同时提问它还答得飞快；对外开一个 HTTP 接口，让别的程序能调它。

具体到动作，其实就一行：vllm serve Qwen2.5-72B，或者 ollama run qwen2.5:72b。敲下去，http://localhost:8000 上就冒出一个服务，那堆死文件从此开始回答问题。

所以本地部署大模型的第一步，从来不是「装模型」，是装 Ollama 或者 vLLM。原文打了个比方：推理框架是放映机，模型文件是影片拷贝，它把拷贝装上机器放起来，再开一个售票窗口。

主流框架的分工也挺清楚。vLLM 是服务端主流、数据中心标配；Ollama 是个人电脑上最省事的那条路；llama.cpp 纯 CPU 也能跑；SGLang 和 TensorRT-LLM 走极致性能。名字记不住没关系，记住一件事就行——同一份权重，换一个框架跑，吞吐、并发上限、显存占用都不一样。

这意味着什么？每百万 token 的实际成本，不是模型厂商定的，是部署方选框架选出来的。推理优化从技术细节变成了一门生意，而选框架本质上是在选成本结构。

只是这一层目前多是定性判断。公开的框架间量化对比不好找，谁快多少、贵多少，多数团队得自己压测才知道，我给不出一个能直接抄的数字。

所有人都说同一种「普通话」，于是模型变成了可替换零件

行业里几乎所有推理框架都提供「OpenAI 兼容接口」，也就是 /v1/chat/completions 那一套格式。原文叫它 HTTP 调用格式的普通话，谁家模型都听得懂。

结果就是，Agent 程序每转一圈，通过 HTTP 调一次大脑。你在配置文件里填的那个「模型地址（API Base URL）」，填的就是推理框架开的售票窗口，写错一个字符，整条链路当场断掉。

改一个 URL 就能换脑。今天 GPT、Claude 的文件在厂家服务器上，你只能远程调；Qwen、DeepSeek、Llama 的权重随便下载，用你自己的框架跑在自己机器上——而这两种情况下，Agent 循环的写法一模一样，都是 HTTP。

于是模型这一侧被推进商品化的压力里。选型从架构决策降级成配置项，「我用了什么模型」不再构成壁垒，做 Agent 的人只能把护城河建在循环、工具、数据和场景上。

硬币的另一面同样成立：你换它便宜，它换你也便宜。低切换成本是双向的。

但这套图景有边界：结构同构，不等于能力同构

得先把前提说清楚：循环里那个大脑必须是大模型。每一圈它都要读懂模糊需求、自己判断下一步、应付从没见过的情况，这是通用理解和通用推理。小模型只会做被训练过的那一件事——「你让它判断垃圾邮件它可以，你让它规划怎么修这个 bug 它就彻底傻了」。原文的断言是，这种通用能力要规模大到一定程度才会涌现。阈值在哪、原始研究出自哪篇，它没给，我也不替它补。

所以这张解剖图只解释形态，不解释能力。真正该分清的是两类问题：

可被工程抹平的：部署、并发、接口、缓存。

抹不平的：涌现出来的通用推理能力、量化带来的能力折损、闭源权重你根本拿不到。

把权重从 FP16 压到 INT4，体积和所需显存大幅缩小，代价是「能力略降」——这个「略」到什么程度，在 Agent 这种多轮任务里能不能接受，公开的实测数字我没找到，只能说这仍是笔糊涂账，自建之前最好拿自己的任务集测一遍。

多模态也是同一回事。能看图听声了，大脑确实升级，但文件、推理框架、HTTP 调用这套结构一点没变。结构稳不稳定，和能力差多少，是两件互不干扰的事。

这条分界线才是自建还是采购的真正依据。瓶颈在部署，花钱买框架；瓶颈在能力，换什么框架都一样。

所以，三类人该拿这张图去改什么决策

做 Agent 的，把精力放在循环、工具和数据上，把模型当可换零件，别在选型上做过度承诺。

做部署的，得意识到框架选型就是成本结构选型。账单来自显存和并发，不来自「模型有多聪明」；同一个模型，vLLM 和 llama.cpp 跑出来是两个价钱。

做决策的，顺序最好反一下：先问权重能不能拿到、跑在哪台机器上、谁来维护那个端口，再谈能力有多强。因为一旦模型可以被下载，智能体就从一项研究成果变成了一个运维问题——而运维问题通常有确定的答案，也有确定的成本。

最后补一块图里没画到的中间地带：开源权重不等于随便用，各家许可证差异不小，能下载和能商用是两码事。真到了选型那一步，这一条得单独过一遍。