最近技术圈有一种说法流传得很广：“全球大模型都在用他的公式，却没人知道他的名字。”很多人把它当成励志故事来读。但换个角度，这句话其实是在描述一个真实的技术现象：你今天用的 ChatGPT、DeepSeek、Qwen、Llama、Mistral，无论闭源还是开源，底层推理时都在反复计算同一小撮“公式级组件”——缩放点积注意力、RMSNorm、RoPE、SwiGLU、AdamW。提出或推广这些组件的研究者在公众视野里存在感很低，但它们的代码出现在几乎所有主流大模型仓库里。
这篇文章不做人物考据，重点解决三个问题：这些被全球大模型反复使用的公式到底解决了什么；想在本机部署一个大模型，从驱动到推理框架需要准备什么；部署完成后如何通过 API、批量脚本和性能观察验证它真的能干活。定位是“原理拆解 + 本地部署实践”，不是单纯的论文翻译，也不是一分钟跑通 Demo 的营销稿。
全文会覆盖从 Attention 公式到本地模型启动、OpenAI 兼容接口调用、批量任务脚本、显存占用观察、常见报错排查和合规边界。建议先收藏，后面按章节接着看。
1. 核心能力速览
| 维度 | 说明 |
|---|---|
| 话题类型 | 大模型底层公式科普 + 本地部署实践 |
| 覆盖公式 | Scaled Dot-Product Attention、Softmax、LayerNorm / RMSNorm、RoPE、SwiGLU、AdamW |
| 推理框架 | Ollama、llama.cpp、vLLM、Transformers，均可作为路线参考 |
| 硬件门槛 | N 卡建议 8GB 显存起步；也可用 CPU / Apple Silicon 尝试，但速度差距明显 |
| 显存参考 | 7B 模型 FP16 权重约 14GB，4bit 量化后约 5GB；实际占用受上下文长度影响较大 |
| 接口能力 | 多数本地推理框架提供 OpenAI 兼容 API，可通过 HTTP 调用 |
| 批量任务 | 可通过 Python 脚本逐条请求，需自行控制并发与失败重试 |
| 适合场景 | 学习大模型原理、内网部署、私有数据测试、接口联调、聊天机器人原型 |
| 不适合场景 | 没有授权就商用模型权重、无 GPU 还强跑超大模型、用生成结果直接做高风险决策 |
需要先说明：文中的显存估算和命令模板是通用工程经验，不是针对某个版本的精确测试结果。你手里的实际显存占用会因框架、量化方式、上下文长度、并发数而变。凡是写“建议”或“参考”的地方，都要以你本机实测为准。
2. 那个“公式”到底是什么
如果一定要在标题里找到一个“他”，不同人会有不同答案。有人会提 RoPE 的主要作者之一苏剑林，有人会想到 Transformer 架构背后的参与者 Noam Shazeer，也有人会把 FlashAttention 的 Tri Dao 放进讨论。与其争论一个名字，不如看看共识部分：大模型时代真正通用的不是某一个算法，而是一组互相配合的数学组件。
2.1 缩放点积注意力：一切生成的开端
Attention 机制是整个生成模型里最核心的公式：
Attention(Q, K, V) = softmax(Q K^T / sqrt(d)) VQ 表示“我要找什么”，K 表示“我有什么候选”，V 表示“候选里真正的内容”。一个 Token 要先计算自己和序列里所有 Token 的相关性，然后把相关性变成权重，最后按权重把 V 加权求和。结果就是：每个位置都知道该看谁、该忽略谁。
公式里的sqrt(d)不是多余设计。点积结果会随向量维度增大而变大，如果不去缩放，softmax 会过早进入饱和区，梯度变得很小。除以维度平方根以后，训练稳定性会好很多。
这段公式的代价也很明显：序列长度为 T 时，复杂度大约是 O(T²)。今天大模型都在强调长上下文，但长上下文并不是没有代价的，它需要更强的显存来存放 KV Cache，也要等更长的首 token 延迟。
2.2 Softmax：让注意力变成可分配的概率
注意力权重本质上是一个概率分布，通常用 softmax 把一组得分变成 0 到 1 之间的权重：
softmax(z_i) = exp(z_i) / Σ_j exp(z_j)它的作用是做竞争性归一化：得分高的 Token 会拿到更大权重，得分低的也不会完全归零。很多本地部署时遇到的问题，比如“输出突然重复”“采样随机性不可控”，本质上都跟 softmax 之后的概率分布有关。你可以通过 temperature 参数调整这个分布：temperature 越低，分布越尖锐，输出越稳定；temperature 越高，分布越平坦，文字越有发散性。
2.3 LayerNorm 与 RMSNorm：让训练不崩
Transformer 里每个子层后面基本都会接一个归一化，用来把中间激活拉回稳定范围。原始 Transformer 使用 LayerNorm，而不少开源大模型后来换成了 RMSNorm。RMSNorm 的写法相对简单，它去掉了“减均值、除以方差”里的均值中心化过程，只使用均方根做缩放。这样做减少了计算量，同时在大规模训练里表现也足够稳定。正因为 RMSNorm 更简单，它在 Llama、Mistral、Qwen 等主流开源系列中成为事实标准。如果你打开这些模型的代码，会频繁看到rms_norm这个函数。
2.4 RoPE：把位置信息写进旋转矩阵
Transformer 本身没有顺序概念，一句话拆成词后如果不加位置信息，模型会把它当成词袋。传统做法是在 Embedding 上直接加一个位置向量，但这种方式对长文本外推不友好。RoPE（旋转位置编码）的做法更巧妙：把相邻 Token 的位置差转换成旋转角度，在计算 Q 和 K 时通过旋转矩阵注入相对位置信息。
之所以大量模型选择 RoPE，是因为它天然支持相对位置编码的优点，同时能通过调整旋转频率增强外推能力。你在很多模型卡片的说明里看到的“上下文长度 128K”“支持 256K 长文本”，底层往往就有 RoPE 的参与。位置编码没有参与最终模型参数更新，但它在训练和推理阶段都会实实在在增加计算量，长文本场景下尤其明显。
2.5 SwiGLU：当前开源模型的默认激活函数
早期 Transformer 的 FFN 模块习惯用 ReLU 或 GELU。后来 SwiGLU 成了开源大模型的主流选择。它把门控机制和 Swish 激活组合在一起，让网络在部分输入上有更强的非线性表达能力。从工程上看，SwiGLU 会增加一些权重体积和计算量，但换来的是更好的效果。现在很多开源模型在基础配置里直接使用 SwiGLU，很少再回到原始 FFN 结构。
2.6 AdamW 与学习率：训练的地基
公式不只在推理时出现，训练过程同样依赖。主流大模型优化器几乎都是 AdamW 配合带预热阶段的余弦学习率衰减。AdamW 会为每个参数维护一阶动量、二阶动量，训练中能自适应调整更新幅度。这一套方案兼顾稳定性和收敛速度，成了大模型训练的事实标准。理解这一点，对你后续做微调或 LoRA 有帮助：当你设置学习率、权重衰减时，本质是在调整 Adam 的更新节奏。
3. 本地部署路线怎么选
从“公式”到“能跑的本地模型”，工具链有不同选择。没有绝对最好的方案，只有阶段最合适的方案。下面是四条主流路线。
| 路线 | 适合人群 | 主要特点 | 上手成本 |
|---|---|---|---|
| Ollama | 新手、产品原型、日常测试 | 安装简单，命令拉模型即用，提供 OpenAI 兼容 API | 低 |
| llama.cpp | CPU / Apple Silicon / 需要原生 gguf 部署 | 轻量，单文件可跑，适合低显存与嵌入式环境 | 中 |
| vLLM | 服务端、高并发、需要批量推理 | PagedAttention 管理 KV Cache，吞吐高，但对显存容量要求更高 | 较高 |
| Transformers + PEFT | 研究调试、微调、实验参数 | 灵活，和 HuggingFace 生态打通，便于改代码观察过程 | 中高 |
如果你是为了验证“模型能不能跑”“接口通不通”，直接用 Ollama 最快。如果你想调试采样参数、观察每一层输出，或者做 LoRA 微调，走 Transformers 路线更合适。如果你最终要做成服务并承担持续调用压力，vLLM 是更接近生产的选择。
4. 环境准备：从驱动到模型权重
本地跑模型不能只关注显存，环境准备经常占了踩坑的一半。下面是通用检查流程。
4.1 硬件与系统检查
先确认系统里是否有可用 GPU：
nvidia-smi如果输出显卡型号和驱动版本，说明驱动基本正常。如果提示command not found，需要先安装 NVIDIA 驱动。Apple Silicon 机器不需要执行这条命令，用uname -m查看架构即可，框架会走 Metal 加速。
再确认磁盘空间：
df -h ~7B 模型的量化文件通常有 4GB 到 8GB，FP16 版本可能超过 14GB。如果下载多个模型，磁盘需要预留足够空间。
4.2 Python 环境与依赖
走 Transformers 路线时，建议把 Python 隔离到虚拟环境里，避免污染系统环境：
python3 -m venv .venv source .venv/bin/activate pip install -U pip然后按需安装依赖：
pip install transformers accelerate sentencepiece如果你的机器有 NVIDIA GPU，并且想用 PyTorch 的 CUDA 能力，需要参考 PyTorch 官网选择与驱动匹配的安装命令。这里不写死版本，因为驱动版本和 CUDA 版本经常不匹配。常见做法是先通过nvidia-smi查看最高支持的 CUDA 版本，再选择对应的 PyTorch 安装源。
4.3 目录规划
建议从一开始就把不同文件分开管理：
~/llm-labs/ ├── models/ # 模型权重或外部模型文件 ├── scripts/ # 测试与批量脚本 ├── data/ # 输入测试集 └── outputs/ # 推理结果先建立目录：
mkdir -p ~/llm-labs/{models,scripts,data,outputs}这样做的好处是：后面做批量任务时，输入、输出、错误日志都有固定位置，不会出现“模型权重和结果文件混一起”的尴尬情况。
5. 快速启动：把公式跑成本地服务
5.1 安装 Ollama 并拉取模型
Ollama 是目前最接近“一键启动”的工具。官网提供对应系统的安装包或安装脚本。如果你在 Linux 上，常见安装方式是：
curl -fsSL https://ollama.com/install.sh | sh执行脚本前建议先去官网确认当前安装方式是否仍然推荐这种写法。如果网络不通，直接从官网手动下载安装包也可以。
安装完成后，先拉取一个能在你机器上跑的模型。这里不固定模型名，把它替换成你需要的模型标签：
ollama pull <model> ollama run <model>ollama run进入交互界面后，可以直接输入一句话测试。退出交互界面用/bye。查看当前已加载到内存或显存的模型：
ollama psollama ps是判断模型是否已经驻留显存的重要命令。如果模型没有输出，说明它可能已经被卸载，下一次请求会重新加载，延迟会比较高。
5.2 用 Transformers 跑一次推理
如果你想脱离 Ollama，直接观察模型加载和 token 生成过程，可以用 Transformers 写一个最小推理脚本：
from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 这里替换为本地模型路径或 HuggingFace 模型名称 model_name = "<model_path_or_id>" tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype="auto", device_map="auto", trust_remote_code=True, ) prompt = "请用一句话解释大模型中的注意力机制" inputs = tokenizer(prompt, return_tensors="pt") outputs = model.generate(**inputs, max_new_tokens=256) print(tokenizer.decode(outputs[0], skip_special_tokens=True))这段脚本能跑通，说明模型文件、分词器、设备映射都没有问题。需要注意：某些模型需要trust_remote_code=True，但也意味着会执行仓库里的自定义代码。不要信任来源不明的模型仓库。
6. 接口 API 与批量任务
本地模型跑通以后，最重要的事情是把服务变成可以被其他程序调用的 API。
6.1 OpenAI 兼容接口调用
Ollama 默认提供 OpenAI 兼容接口，服务地址在本机启动后通常是：
http://127.0.0.1:11434/v1/chat/completions用 curl 验证：
curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "<model>", "messages": [ {"role": "user", "content": "用一句话解释什么是浮点数"} ], "temperature": 0.7, "max_tokens": 256 }'返回结构里重点关注choices[0].message.content。如果这一段能正常返回，说明服务可以接进你自己的代码了。
6.2 Python 调用示例
有的场景不适合用 curl，比如要写自动化测试。下面是一个最基础的 Python 请求示例：
import requests API_URL = "http://127.0.0.1:11434/v1/chat/completions" MODEL = "<model>" payload = { "model": MODEL, "messages": [{"role": "user", "content": "什么是梯度下降？"}], "temperature": 0.5, "max_tokens": 512, } response = requests.post(API_URL, json=payload, timeout=180) response.raise_for_status() data = response.json() print(data["choices"][0]["message"]["content"])这种调用方式不依赖任何大模型专用 SDK，只要接口兼容 OpenAI 格式，就能快速接到自己的业务脚本里。
6.3 批量任务脚本
批量任务最容易出现的问题是：单个请求耗时太长，一个请求失败导致整个脚本退出。下面脚本会读取每行一个 prompt 的文本文件，逐条调用 API，并把结果写入 JSONL 文件：
import json import time import requests API_URL = "http://127.0.0.1:11434/v1/chat/completions" MODEL = "<model>" INPUT_FILE = "./prompts.txt" OUTPUT_FILE = "./results.jsonl" def call_llm(prompt: str) -> tuple[str, str]: payload = { "model": MODEL, "messages": [{"role": "user", "content": prompt}], "temperature": 0.7, "max_tokens": 512, } try: resp = requests.post(API_URL, json=payload, timeout=180) resp.raise_for_status() content = resp.json()["choices"][0]["message"]["content"] return "ok", content except Exception as exc: return "error", f"{type(exc).__name__}: {exc}" if __name__ == "__main__": prompts = [] with open(INPUT_FILE, encoding="utf-8") as fr: prompts = [line.strip() for line in fr if line.strip()] results = [] for idx, prompt in enumerate(prompts, 1): print(f"processing {idx}/{len(prompts)}") status, content = call_llm(prompt) item = {"id": idx, "prompt": prompt, "status": status, "output": content} results.append(item) with open(OUTPUT_FILE, "a", encoding="utf-8") as fw: fw.write(json.dumps(item, ensure_ascii=False) + "\n") # 避免短时间请求过密 time.sleep(0.5) print(f"done, total={len(results)}")这个脚本已经具备基础断点续跑能力：因为每处理一条就追加写入一行，即使中途崩了，前面成功的结果也不会丢。真正生产环境还会要求更完善的并发控制、队列管理和任务重试机制，但作为本地验证已经够用。
6.4 接口安全边界
本地 API 服务尽量不要直接暴露到公网。如果只是本机调试，让服务监听127.0.0.1就够了。如果必须开放给局域网其他机器，也要在网关层增加身份校验，否则别人可以随意消耗你的显存和带宽。
7. 资源占用与性能观察
7.1 看显存：不要只盯任务管理器
推理过程中需要实时监控显存使用情况，可以开一个独立终端执行：
nvidia-smi -l 2每隔 2 秒刷新一次显卡状态。关注点不是“显卡到底占了多少”，而是“模型加载前后显存变化了多少、随着请求次数增加是否会持续上涨”。如果持续上涨，多半是 KV Cache 累积或模型被重复加载，要定位是哪个环节出了问题。
7.2 哪些因素最影响资源占用
| 参数 | 影响方向 | 说明 |
|---|---|---|
| 模型参数量 | 权重体积上升 | 7B 和 70B 的显存需求完全不是一个量级 |
| 量化精度 | 权重体积降低 | FP16 变成 4bit 后，显存需求会明显下降 |
| 上下文长度 max_tokens | KV Cache 增长 | 上下文越长，KV Cache 占显存越多 |
| 并发请求数 | 峰值显存与吞吐 | 并发越高，越容易碰到 OOM |
| temperature 等参数 | 几乎不影响 | 这是采样参数，不改变显存 |
| FlashAttention | 降低显存访问量 | 是否支持取决于框架和显卡 |
7.3 降低显存占用的常用手段
第一是量化。同样的模型，FP16 权重大约是 14GB，4bit 量化后可能降到 5GB 左右。Ollama 和 llama.cpp 使用 GGUF 量化模型，Transformers 生态里则有 GPTQ、AWQ、bitsandbytes 等方案。
第二是限制上下文长度。服务端不设 max 长度的话，模型会按最大能力分配 KV Cache 空间。比如你用 vLLM 部署，就可以显式限制--max-model-len，避免缓存占用过高。
第三是降低并发数。本地调试时并发设为 1 或 2 就足够，没必要一上来就模拟高并发。
第四是使用 vLLM 这类推理服务框架。它对 KV Cache 做了更精细的管理，吞吐在长上下文场景下会更有优势。
7.4 vLLM 启动示例
如果你的目标是更接近生产的服务，可以参考 vLLM 的启动方式：
python -m vllm.entrypoints.openai.api_server \ --model <model_path> \ --gpu-memory-utilization 0.9 \ --max-model-len 8192启动以后，服务同样提供 OpenAI 兼容接口。--gpu-memory-utilization 0.9表示允许 vLLM 最多占用 90% 显存；--max-model-len 8192是最大上下文长度，设置得越小，留给批处理的空间就越大。具体参数以你安装的 vLLM 版本为准，不同版本的命令行参数可能有差异。
8. 常见问题与排查方法
下表汇总了本地部署大模型最容易遇到的问题，按出现频率排序。
| 问题现象 | 可能原因 | 排查与解决 |
|---|---|---|
| 启动后页面或 API 打不开 | 端口被占用或服务启动失败 | 查看终端日志；换端口重启，或先杀掉残留进程 |
| 模型下载极慢 | 网络不稳定或默认源速度较慢 | 确认是否能从官网稳定下载；不要使用来路不明的加速包 |
| 显存不足 OOM | 模型太大、上下文太长、并发过高 | 换量化模型；限制 max token；降低并发；关闭无关程序 |
| 提示 CUDA 相关错误 | PyTorch 与驱动版本不匹配 | 检查nvidia-smi和 PyTorch 对应版本；重新安装匹配的 CUDA 版本 |
| API 返回 404 或路径报错 | 接口前缀与框架版本不一致 | 查看服务日志里的路由；按对应版本修改 URL |
| 输出重复、句子卡住 | 温度过低或长度参数设置不合理 | 调高 temperature；增加 top_p 范围；清理过短或过长测试用例 |
| 模型加载很慢 | 权重文件在机械硬盘或首次冷启动 | 使用 SSD；预热模型；必要时做 keep-alive 配置 |
| CPU 推理特别慢 | 未使用 GPU 或模型未支持当前设备 | 确认device_map或 CUDA 可用性；换更小模型 |
| 批量任务中途全部失败 | 并发过高导致 OOM，或单个请求超时 | 降低并发；增加 timeout；加入失败重试和结果持久化 |
还有一个容易忽视的问题：多次启动服务后进程残留，占用显存不释放。用ollama ps或nvidia-smi找到对应进程后手动清理，避免显存被“隐身进程”占满。
9. 大模型应用合规与最佳实践
9.1 授权与版权边界
本地部署使用开源模型时，先确认模型权重仓库里的 License 和开源协议。不要以为“参数下载下来就能随便商用”。不同模型对商用、二次分发、模型输出归属有不同要求。如果模型用于内容生成，且结果要对外发布，必须做人工复核。用模型生成人脸、声音、标识或模仿特定风格的内容时，要确认你拥有素材授权。数据隐私同样重要，不要把真实用户手机号、身份证号等敏感数据直接喂给来源不明的模型。
9.2 工程化建议
第一，第一次测试时先用小参数量模型和短文本，验证链路能通，再放大规模。不要一上来就在 70B 模型上尝试，否则环境问题会淹没在资源问题里。
第二，保留一套最小可运行配置。比如把“能跑通的模型标签、推理参数、启动命令”记在一个 Markdown 文件里。这样出问题后能快速回退到已知可用状态。
第三，模型文件、测试素材、输出结果分开管理。代码目录里不要堆几十 GB 的权重文件。
第四，批量任务要有进度日志、错误日志和结果文件。每处理一条就追加写入一次，可以有效对抗突发崩溃。
第五，接口服务要限制访问范围。仅本机调试就绑定 127.0.0.1；需要局域网访问时加上鉴权，不要直接暴露公网端口。
第六，上线前做效果抽检。大模型输出质量不稳定，批量任务跑了 1000 条，也不能默认全对。抽检比例至少覆盖 5% 到 10% 的结果，重点看关键字段、政治敏感内容、隐私信息和明显的逻辑硬伤。
10. 小结：公式是入口，部署是验证
回到标题：全球大模型都在用哪些公式，这个问题比“他的名字”更重要。Attention 让模型学会关注，RMSNorm 让训练稳定，RoPE 让位置信息进入注意力计算，SwiGLU 提升非线性表达能力。这些组件都不是秘密，全部写在开源代码里，任何人都能查看。
最值得先做的事情是：打开终端，挑一个小尺寸量化模型，启动 Ollama 或 Transformers 推理脚本，输出第一句话。这一步能跑通，你就有了一台属于自己的“实验大模型”。接下来可以测试 API 调用、批量任务、显存监控、量化对比，甚至尝试 LoRA 微调。
最容易踩的坑通常集中在三处：显存估算不准、上下文长度设置过大、接口协议与框架版本不匹配。遇到问题不要慌，按日志、端口、显存、依赖版本这个顺序排查，大部分问题都能在十分钟内定位。
想看模型真实效果，别只看榜单分数，直接用你自己准备的问题集跑一遍；想判断是否适合业务，也要用真实场景数据做小批量验证。公式自己能解释世界，但只有部署到你的机器上，它才能真正开始工作。
