AI推理（Inferencing）详解：原理与运行位置
训练一次，推理天天付钱。同样一个模型，有人每百万 token 花几块钱，有人花几十块，差别不在模型本身，在于推理怎么跑：批处理、量化、缓存、跑在谁的显卡上。这篇把推理的机制、指标和选型算清楚。
💡 你将学到
训练一次，推理天天付钱。同样一个模型，有人每百万 token 花几块钱，有人花几十块，差别不在模型本身，在于推理怎么跑：批处理、量化、缓存、跑在谁的显卡上。这篇把推理的机制、指标和选型算清楚。
📜 目录
AI 推理详解：一次请求里发生了什么，钱花在哪，该跑在哪
训练是一次性的资本开支，推理是每天都要付的运营成本。同一个模型，有人每百万 token 花几块钱，有人花几十块，差别几乎全在推理这一层：批处理怎么开、精度压到多少、缓存命中率多高、跑在谁的显卡上。
这篇从机制讲到选型，看完能自己算出该用云还是本地。
一、一次推理里到底发生了什么
大模型生成回答分两个阶段，这两个阶段的性能特征完全不同，很多"为什么这么慢"的困惑都源于把它们混为一谈。
第一阶段：预填充（prefill）。把你送进去的整段上下文一次性过一遍模型，算出缓存。这一步是并行的，GPU 利用率高，属于"算力密集"。
第二阶段：解码（decode）。一个 token 一个 token 往外吐。每吐一个都要把上一步的结果再算一遍，属于"显存带宽密集"——卡不是算不动，是数据搬不过来。
关键机制是 KV 缓存：预填充阶段算出的键值对会被存下来，解码时直接复用，不必重算历史。这也是为什么第二轮对话比第一轮"感觉快"——但那部分缓存要占显存，上下文越长占得越多。
一句话记住：上下文长度吃显存，输出长度吃时间。
二、四个指标，各管一件事
| 指标 | 全称 | 管什么 | 经验参考 |
|---|---|---|---|
| TTFT | 首 token 延迟 | 用户"感觉快不快" | 聊天场景 1 秒内算流畅，500ms 内算即时 |
| TPOT | 每 token 输出时间 | 阅读速度跟不跟得上 | 每秒 20-60 个汉字对聊天足够 |
| 吞吐 | 每秒总 token 数 | 单位成本摊薄 | 批处理场景越高越省钱 |
| 单 token 成本 | 每百万 token 价格 | 账单 | 以各家官网定价页为准 |
容易踩的坑：只看吞吐不看 TTFT。离线批处理任务把并发拉满，吞吐很好看，但如果这是交互产品，用户会等十秒才看到第一个字。交互看 TTFT，离线看吞吐，这两个指标要分开优化。
三、模型跑在哪：四条路线
| 路线 | 代表工具 | 适合谁 | 主要代价 |
|---|---|---|---|
| 云端 GPU 集群 | vLLM、SGLang、TensorRT-LLM | 有并发、要稳定 SLA 的产品 | 按量付费，长上下文贵 |
| 本地电脑/工作站 | llama.cpp、Ollama、LM Studio | 隐私敏感、量大且任务简单 | 一次性硬件投入，速度受显存带宽限制 |
| 手机/边缘设备 | llama.cpp 移动端、MLC-LLM | 离线可用、随身场景 | 只能跑小模型或强量化版 |
| 浏览器 | WebLLM 等基于 WebGPU 的方案 | 演示、零安装试用 | 首次要下载模型权重，性能有限 |
自建的三个主流服务端框架分工也不同：vLLM 生态最成熟，PagedAttention 做显存分页，连续批处理开箱可用；SGLang 在结构化输出和前缀复用上更强，多轮对话、固定系统提示词这类场景命中率高；TensorRT-LLM 需要针对显卡编译引擎，前期麻烦，跑起来最快，适合流量稳定的生产环境。
四、量化：拿精度换显存，是本地推理的前提
模型权重默认用 16 位浮点存，一个 70B 模型光权重就要一百多 GB，单张消费级显卡根本放不下。量化就是把权重压到更低位宽。
| 精度 | 相对显存 | 质量变化 | 适用场景 |
|---|---|---|---|
| FP16 / BF16 | 100% | 基准 | 云端生产、评测基线 |
| INT8 | 约 50% | 多数任务几乎无感 | 服务端降本首选 |
| 4-bit（如 Q4_K_M） | 约 25-30% | 通用任务可接受，数学与代码略降 | 本地部署的默认选择 |
| 2-3 bit | 约 15% | 明显退化，长链推理容易崩 | 只在小模型、极限显存下考虑 |
实践建议：本地先从 4-bit 起步，跑不通再降；服务端优先试 INT8 或 FP8，别一上来就用最低位宽，质量掉下去很难定位是哪一环的问题。
五、批量与推测解码：吞吐和延迟的取舍
连续批处理：不等一个请求答完再处理下一个，而是把新请求塞进正在跑的批次里。这是云端把单 token 成本压下来的核心手段，也是自建服务必须开的开关。
前缀缓存：系统提示词、工具定义、长文档这些每次都一样的部分，缓存下来只算一次。多轮 Agent 场景命中率往往很高，命中部分的价格通常只有正常输入的一小部分。
推测解码：用一个小模型先"猜"几个 token，大模型一次性验证。猜对的越多加速越明显，猜错就退回重算。适合输出可预测的场景（代码补全、格式化输出），创意写作收益有限。
六、云还是本地：算一遍就知道
别凭感觉。按这个顺序算：
- 统计每天输入 token 和输出 token 的量（日志里就有）。
- 乘上你候选模型的官方单价，得到云端月成本。
- 估算本地能承受的并发：显存装得下多大模型、多少上下文、几个并发。
- 本地成本 = 硬件折旧（按 24-36 个月摊）+ 电费 + 运维人力。
- 再算一遍隐性成本：模型升级要不要换卡、出故障谁修、数据合规能不能过。
判断经验：任务简单、量大、对延迟不敏感，本地往往更划算；任务复杂、流量波动大、要随时换最新模型，云端的弹性值这个钱。
还有一个常用折中：本地小模型做分流和粗加工（分类、抽取、清洗），云端旗舰模型只处理真正困难的请求。这条路由加在中间，成本结构通常比全云或全本地都健康。
常见问题
Q：推理和微调是一回事吗？ A：不是。微调改的是权重，推理是用已有的权重做预测。微调是一次性任务，推理是持续发生的成本。
Q：没有显卡能做推理吗？ A：能。llama.cpp 在纯 CPU 上可以跑小模型的量化版，速度按每秒几个 token 计，适合批处理、离线总结这类不要求实时性的任务。
Q：为什么我的本地模型比云端慢很多？ A：先看显存带宽，这是解码阶段的硬瓶颈；再看模型有没有完整放进显存，一旦溢出到内存，速度会掉一个数量级；最后看是不是用了最低位宽量化拖累了质量。
Q：上下文越长越贵，有没有办法省？ A：三条：开前缀缓存；检索后先压缩再拼接，别把整篇文档塞进去；把固定不变的内容放在前面，变动的内容放最后，提高缓存命中率。
Q：70B 模型单卡能跑吗？ A：4-bit 量化后权重约三十多 GB，理论上能装进 48GB 显存的卡。实际还要留出 KV 缓存的空间，上下文长的时候会吃紧，具体能开多长上下文要以实测为准。
注：各框架参数、量化方案与 API 定价随版本调整，具体以官方文档和定价页为准。
相关文章
❓ 常见问题
Is inferencing the same as fine-tuning?
No. Fine-tuning changes the weights; inferencing uses the weights to predict.
Can I do inferencing without a GPU?
Yes - CPU-only works with small quantized models via llama.cpp or Ollama.
本站文章由编辑人工撰写，收录的工具均经过实测或公开资料核验。文中链接指向工具官网或 GitHub 仓库，仅作信息参考，不构成付费推广。