生产站(中)— 跑起来、扛得住、守得住
这一章讲三件事: 五个本地工具的本质差异(量化格式与 GPU 卸载); 推理提速的三招各修哪个瓶颈;上了线之后,运维与安全为什么必须前移。 对应原书生产部第 4–8 章。读完你能回答:为什么 demo 好好的系统, 上线第一周就出事——以及出的是哪两类事。
1. 这一章讲什么
上一章结束时,客服机器人已经能「答得有据」。但它还活在一台开发机里。 本章管剩下的路:把它跑起来(本地或云端)、跑得快(优化——让同样的机器答得更多)、 跑得稳(LLMOps)、跑得安全(攻防)。
跑起来 → 跑得快 → 跑得稳 → 跑得安全
(本地/部署) (优化) (LLMOps) (攻防)
图说:原书这五章的次序,正好是「一条请求离开发布按钮之后」
会依次遇到的问题。
本章的主走查用一条请求的一生贯穿——用户在周五晚上发来「退货政策是什么?」, 看它经过的每个环节、每个环节的数,以及它没能平安到达的两种死法。
2. 本地运行:动机是隐私,技术是量化加卸载
原书给的动机很直接: 用在线服务「简单,但有隐私风险——比如 OpenAI 会存储你的交互与元数据来改进模型」;本地跑,数据不出机器1。
五个工具摆开看,真正的差异只有两个变量(机制承接第 04 章的量化):
| 工具 | 一句话定位 | 关键差异(原书给的事实) |
|---|---|---|
| GPT4All | 开箱即用的桌面应用 | 有 NVIDIA GPU 时自动加速,约每秒 30 个词块;可授权读项目文件夹做检索增强2 |
| LM Studio | 界面最好、闭源(代码不公开) | GPU 卸载等选项更全,但因此不能读项目文件夹3 |
| Ollama | 开发者向、命令行 | 内置模型库(Llama 2、Mistral、Gemma、LLaVA),用现代 CPU 指令集(AVX/AVX2)加速4 |
| llama.cpp | 一切的地基 | C/C++ 实现的推理引擎,390 多位贡献者、4.3 万星;参数表里能看到温度与 top-p 这些调用入口长什么样5 |
| Chat with RTX | 厂商 demo | 绑定 NVIDIA,仅支持 30 系及更新的显卡6 |
「卸载」是这五者共享的核心机制: 模型按层切开(7B 模型 35 层,第 04 章的数), 放得进显存的部分上 GPU,放不下的留 CPU——慢,但跑得动。 为什么这算「生产站」的内容: 它是边缘部署(下一节)的另一半; 也是 「数据不能出门」场景(医院、律所、涉密内网)的唯一选项。
3. 部署:四种形态是一张决策表
原书把部署分成四种,并给每种配了学习资源7。这不是难度阶梯,是四道不同的决策题:
| 形态 | 谁在用 | 决策变量 | 原书给的工具 |
|---|---|---|---|
| 本地 | 自己或内网 | 数据能不能出门 | 上一节五件套 |
| demo | 演示给非技术的人 | 快速做出来给人点 | Streamlit、Gradio 几行代码起界面;FastAPI 把模型包成 API8 |
| 服务器 | 真实用户 | 弹性、成本、合规 | 云托管(Bedrock、SageMaker)与推理容器9 |
| 边缘 | 设备端 | 无网、等得短、隐私 | MLC、TinyChat、车载/手机场景;小模型(如 Phi-2/Phi-3)上手机10 |
原书给边缘部署的理由值得留下:嵌入车载、 办公助手这类真实系统后, 用户「不依赖稳定网络也能即时拿到回答」,且敏感数据留在本地11。
4. 推理优化:三招,修三个瓶颈 — 主走查
一条请求的一生(演示数字,下文注明)
周五 20:00,用户发出:「退货政策是什么?」
输入:800 个词块(检索塞进来的资料 + 问题);要生成 200 个词块的回答。
(词块数与下面的延迟、显存数都是为演示编的,量级参考真实硬件。)
── 瓶颈一:自回归是串行的 ──────────────────
模型一次只吐一个词块,吐完把结果接回输入,再算下一个。
200 个词块 = 200 次串行计算;每次 30 ms → 一条请求 6 秒起。
这是生成式模型「慢」的结构性根源,不优化就永远在。
── 瓶颈二:不用缓存的话,每个新词块都在重算旧账 ──
算第 N 个词块时,注意力要回看前面全部词块。
不缓存:每吐一词都要把前 1000 个词块的中间结果全部重算一遍。
KV 缓存:把每个词块的「钥匙/值」算一次就存起来,后面直接查表。
800 词块的输入,省下的是约 20 万次重复计算量级(演示口径)。
── 瓶颈三:GPU 在等人 ──────────────────
静态凑批:攒够一批一起算,先到的等最慢的 → GPU 空转。
连续批处理:谁算完谁出队,新请求随时插队 → GPU 几乎不闲着。
图说:三招各修一个瓶颈——KV 缓存修「重复计算」,
连续批处理修「硬件空转」,投机解码修「串行」。
第三招原书只点名没展开,这里补上: 投机解码(sometimes 译「推测解码」) ——拿一个小模型先草拟几个词块,大模型一次计算同时验证这串草稿, 对的收下、错的从错处重算。验证一次的成本约等于自算一次, 但收下的是好几个词块——串行的墙被凿开一个口12。
顺着主走查看: FlashAttention 修的是第四个瓶颈
原书列的另两件工具与上面三招不平行:FlashAttention-2(更省内存的注意力实现) 与 BetterTransformer(框架层的快路径)13。
FlashAttention 修的是「搬运」。 注意力有一套最直白的算完方式: 每个词块对其他所有词块各打一个相关度分(第 02 章那一步),分数摊成一张大表格, 再拿这张表往下算。像这样「一套固定步骤、照着一步步走就一定得出答案」的东西, 行话叫算法;这一套就是注意力的朴素算法。它的问题全在表格的大小上: 本节走查里 800 个词块的输入,表格就是 800 × 800 ≈ 64 万格; 等回答再吐出 200 个词块,表格长到 100 万格(沿用本节的演示数字)。
这么大一张表放不进显存里又小又快的那块地方,只能搁在又大又慢的地方, 算一步搬一趟。FlashAttention 改成小块进快区、算完再出来, 省的是搬运而不是计算14。生产站的清单把它排在三招旁边, 说明作者的「优化」口径覆盖了计算与搬运两层。
5. LLMOps:把「能跑」变成「能维护」
原书对 LLMOps 的定位:它是 MLOps(给机器学习——从数据里训模型的技术——配的一套运维方法)的一个专门子集, 核心关切是把微调后的模型「打磨并接进产品」15。和 MLOps 的真正差别 在原书这句话里:「搭一个 LLM 应用容易,把它做成生产级非常难」16—— 难在输出不可预测,于是三件事被推到核心位置:
| 常规软件 | LLM 应用要额外做的 |
|---|---|
| 改代码要过测试 | 改提示、换模型、换版本都要过评测(输出会漂移) |
| 出错看运行记录 | 还要看安全分——监控毒性、幻觉(模型一本正经编造)的比例这类模型行为信号17 |
| 版本管代码 | 连数据和微调产物都要版本化,否则实验对不上号18 |
原书把「持续集成里跑评测」讲了两遍(评测章一遍、LLMOps 章一遍), 列举的检查项包括幻觉、数据漂移、有害输出19——评测不是一次性验收, 是上线后仍在跑的流水线。 这是第 04 章「改模型必回测」在生产侧的延伸。