数据截至 (上游 commit c187ef3271d5)
让模型走出脚本 — 全书的落点,和它自己撞上的那堵墙
这一章讲三件事。第一件,是一句听起来很扫兴、但完全成立的话: 你练得再好,模型留在脚本里等于零。 它现在只是硬盘上的一个文件 —— 别人的程序调不到它、你的用户点不着它。
第二件,是把它交出去的三步: 导成一份换个框架也能跑的通用格式 → 包成一个能被网络请求叫醒的服务 → 推上公网。 这三步是这本书区别于同类书的地方 —— 别的书讲到「练出来了」就收尾。
第三件,是这本书自己撞上的那堵墙,也是全书的落点。 第 04 章埋下的那个类别名错位,被原样抄进了线上服务。 拿一张松饼图去问它,它回答「吉娃娃 0.697」—— 书一字未评。 这一章把那个 0.697 的真实含义算给你看,结论比「它答错了」更别扭: 它其实答对了,只是「哪个数对应哪个类」那张对照表反了,于是被印成了错的。
在全书链条里的位置:这是最后一环,也是闭环合上的地方。 交给框架(第 13 章)→ 装上仪表(第 14 章)→ 送出去(这一章)。 而它想教的那句话,被它自己坐实了:能上线,不等于是对的。
1. 顶层全景:一个模型文件,走到公网上的一个地址
这一章拿的是第 04 章那个分松饼和吉娃娃的模型,一路送到公网1。
第 04 章训出来的权重文件
│
├─① 导成通用格式 ────────→ 换个运行环境也能跑,不必装 PyTorch
│
├─② 包成一个服务 ────────→ 开两个地址:一个报活,一个收图片地址、返回判断
│
├─③ 本地起来、试一试 ────→ 本机 8000 端口;拿一张吉娃娃图问,答「吉娃娃 86%」
│ ← 看起来一切正常
│
├─④ 推上第一家云 ────────→ 五个文件,git push 就完事
│ (这一家叫 Heroku)
│
└─⑤ 推上第二家云 ────────→ 一条发布命令
(这一家叫 Microsoft Azure)
← 拿一张松饼图问,答「吉娃娃 0.697」
图说:这一章真正的落点在第 ③ 步和第 ⑤ 步之间的对照。 同一套代码、同一个模型,一次看起来对、一次露馅 —— 第 8 节把这两次连起来算一遍。
2. 训完之后,模型只是硬盘上的一个文件
先看现象。 第 13 章那三个检查点文件、第 14 章那个注册表里的第 2 版 —— 它们都在你的机器上躺着。
而这意味着:你的同事没法用它,你的用户更点不着它。
**书对「部署」这件事的定义,值得原样记住:把开发出来的东西 (比如一个新的深度学习模型)接进真实的业务流程,并且让别人能用2。
书还借页首那句行里的老话点了它的性质 ——「周五不上线」。 它自己的解读是:这句话说的是部署意味着责任,同事和客户在依赖你2。 (这句话的字面理由也很实在:出了事没人愿意用整个周末去查。)
3. 用户点的东西,碰不到模型
先看现象: 你打开一个网站,输入点什么,得到一个结果。 中间到底隔着几层?
书画了一条链,而且强调了链上一个不许被绕过的规矩3:
用户 ──→ 浏览器 ──→ 前端服务器 ──→ 后端服务器 ──→ 数据库
└────────→ 第三方服务
规矩:后端服务器不直接和最终用户说话,一切都要经过前端服务器这个中间人。
图说:前端管画面,后端管算。 书举的例子是一个聊天机器人: 用户输入一段文字 → 前端把它转给后端 → 后端可能再去问一个第三方的语言模型, 或者去数据库里取点东西 → 结果原路返回3。
后端上跑的那些各管一摊的服务,书给了个名字叫微服务3。 我们训出来的模型,就住在后端。
3.1 接口和端点
这两个词是这一章的入口,必须当场讲清。
一个程序要被另一个程序调用,得先伸出几个可以被叫到的地址 —— 这套「能被别的程序叫到」的东西,统称接口(第 10 章用它调过别人的语言模型, 那时候我们管它叫 API,是同一件事)。
而其中每一个具体的地址,叫一个端点。 书给的定义是: 客户端 —— 也就是发起请求的那一方,你的 浏览器、或者另一个程序 —— 为了和这个接口打交道而把请求发过去的那个具体网址,就是端点; 它同时也是使用这台服务器的接入点4。
书拿自己的网站举了一个极好的例子,一句话就说明白了5:
打开 gollnickdata.de → 走的是默认的那个端点,写作 "/"
点开网站上某一本书的介绍页 → 地址栏变了,变成了另一个端点
图说:你天天在浏览器地址栏里看到的那些路径,就是端点。
这一章的服务只开两个端点6:
| 端点 | 干什么 | 回什么 |
|---|---|---|
/ | 报活 —— 让你确认这台服务还在 | 一句「状态正常」,外加一句用法提示 |
/predict | 收一个图片地址,返回判断 | 类别名,以及两个类各自的把握 |
4. 这一层用什么协议说话:三种选法
先看现象: 上一节那条链上,每一段都要「说话」。用什么语言说?
书列了三种最常见的,而且各自的取舍很清楚7:
| 选法 | 怎么说话 | 什么时候选它 |
|---|---|---|
| REST | 拿网址加动词说话(取 / 建 / 改 / 删),数据用 JSON 那种格式 | 最常用,几乎所有服务之间的通信都基于它;和浏览器这类客户端打交道最省事 |
| gRPC | 走二进制,不是文本 | 要快、要低延迟时 —— 传的数据更少,所以更快更省 |
| GraphQL | 没有固定的端点,调用方自己声明「我要哪几个字段」 | 数据结构复杂时 —— 一次请求就能从好几处取数,换成 REST 要发好几次 |
第一种是这一章用的。 书说它是这些协议里的头一号、 是互联网最重要的支柱之一7。它建立在网页那套请求方式上, 动作由「 取 / 提交 / 更新 / 删除」这几个动词定义7。
第三种那个「没有固定端点」值得多说一句,因为它正好和上一节反着来: REST 是服务器规定好每个端点返回什么,GraphQL 是调用方自己点菜。 (这一句对照是我们补的,书分开说的两句。)
5. 上线不是手动传文件
先看现象: 上面讲的是「架构长什么样」。可代码是怎么从你手上跑到线上去的?
书把部署放进一个更大的流程里讲,这个流程叫 CI/CD8。 它是一串自动化的步骤,目标是让软件的改动又快又可靠地从开发者手上送到最终用户手上8。
拆开看是两半:
前一半那两个字母,展开叫持续集成 —— 管的是「代码进库」这件事。 书说得很具体:把多个开发者写的代码,自动地并进一个大家共用的地方; 每次有人上传代码,就自动触发一套流程8。
那个「大家共用的地方」有个名字叫版本库 —— 一个记录代码每一次改动、能回退到任意一次的仓库;这一章用的是最常见的那种(Git)8。
这套流程可以包括两类动作8:
| 动作 | 干什么 |
|---|---|
| 自动测试 | 单元测试、集成测试 |
| 自动构建 | 把代码打成一个能跑的东西 |
目的书说得极准:尽早发现问题,让流程停下来,别把有毛病的代码部署出去8。
后一半(CD)其实是两个意思,差别只有一处:放行是不是自动的9:
| 说法 | 改动怎么上线 |
|---|---|
| 持续交付 | 先准备好,等人手动点一下才放行 |
| 持续部署 | 直接上线,没有人工那一步 |
这就是「周五不上线」那句老话的落点: 全自动上线快, 但出了问题的时候,没人拦得住那一步。(这一句连接是我们做的,书两处分开说的。)
6. 换成通用格式:让别人不装 PyTorch 也能跑
它解决什么问题。 你存下来的那份权重,得用 PyTorch 才读得动。 可线上的运行环境未必装了 PyTorch —— 书说得很实在: 很多生产环境用的是经过优化的运行时,可能和训练用的框架并不兼容10。
做法:导出成一份跨框架的开放格式,名字叫 ONNX。 书给的定义是:一种开放格式,用来改善不同深度学习框架之间的互通 —— 你可以用 PyTorch 训,再把它导到别的运行环境里去跑10。
导出时有两处必须交代11:
| 要给什么 | 这一章给的 | 为什么要给 |
|---|---|---|
| 一个样例输入 | 一个形状是 (1, 1, 32, 32) 的随机张量 | 导出这一步要拿它把整张计算图走一遍,才知道图长什么样 |
| 格式的版本号 | 12 | 这个格式在演进,对方的运行时支持到哪一 版,得对得上 |
那个 (1, 1, 32, 32) 正是第 04 章那个模型的输入形状 ——
一张图、一个通道(灰度)、32 × 32 像素。
这个形状此后被写死在了模型文件里:线上送进去的图,必须先被处理成这个形状。
(这一句是我们补的,它是下一节那个陷阱的根子。)
7. 包成服务:两个端点,和一条不能差半步的规矩
它解决什么问题: 有了模型文件,还得有个东西一直开着、等别人来问。
这一章用的是三样小东西12:一个写接口的框架、一个跑它的服务器、 以及一个专门跑那份通用格式模型的运行时(注意:这里已经没有 PyTorch 了)。
这三样都有名字,而且你出门一定会撞见,所以现在就点出来12: 写接口的那个框架叫 FastAPI,跑它的那个服务器叫 uvicorn (它负责真正听端口、把请求交给你写的函数), 跑通用格式模型的那个运行时叫 onnxruntime —— 上一节导出的文件正是交给它。
第一个端点简单到只有三行:声明一下这个地址收 「取」这个动作, 写一个函数,返回一句写死的话13。 书特意说:那个函数叫什么名字无所谓13 —— 起作用的是它上面那行声明。
第二个端点是正经活,四步14:
① 把图下载回来
── 图片常常只允许浏览器下载,所以要装成浏览器的样子去要
(代码里带了一整套浏览器的自我介绍)
② 预处理 ← 这一步是全章最容易翻车的地方,见下面
③ 送进模型跑一遍
④ 把结果包成 JSON 返回:类别名 + 两个类各自的把握
7.1 预处理必须和训练时一模一样,差一步就废
这一条是这一节真正的知识点,而且它是从第 04 章一路延续下来的规矩。
线上这四步预处理,每一步都对应第 04 章训练时做过的同一步14:
| 线上这一步 | 对应训练时的哪一步 |
|---|---|
| 转成灰度 | 第 04 章那个模型吃的就是单通道灰度图 |
| 缩到 32 × 32 | 同上,模型的输入形状写死了 |
| 每个像素除以 255 | 把 0–255 的亮度压到 0–1 |
再做 (x − 0.5) ÷ 0.5 | 把 0–1 挪到 −1 到 +1(第 07 章解释过这一步为什么要做) |
| 补两次维度 | 从 (32, 32) 变成 (1, 1, 32, 32) —— 补出「一批」和「一个通道」 |
为什么差一步就废: 模型学到的规律是建立在「输入长这样」这个前提上的。 你训练时把像素挪到了 −1 到 +1,线上却只除了 255(0 到 1), 那么同一张图在模型眼里完全是另一张图。 (这一段因果是我们补的:书列了这四步代码,但没有解释为什么必须一致。)
7.2 这里书悄悄修好了第 03 章那条规矩
值得单记一笔,而且这是一条独立的线,和后面那个错误没有因果关系。
第 03 章立过一条规矩:用带 logits 的那把尺训出来的模型, 输出的是原始分数,不是概率;要卡阈值,得先压一压。 而第 04 章违反了它 —— 直接拿 0.5 去卡原始分数。
这一章的代码修好了:它先把模型吐出来的那个数过一遍 sigmoid 压成 0 到 1,再卡 0.515。
但书没有说自己前面错过。 两处摆在一起看才知道这里改了口径 —— 读者对着第 04 章敲代码,不会知道那一步是错的。
8. 主走查:同一套代码,一次看起来对、一次露馅
这条走查带一次反转,请一步一步读。
第 ① 步,导出。 第 04 章那个模型 → 通用格式,输入形状 (1, 1, 32, 32)、版本 1211。
第 ② 步,起服务。 本机 8000 端口,监听所有网络接口16。
第 ③ 步,先确认它活着。 浏览器打开本机 8000 端口的根地址, 返回「状态正常」和一句用法提示 —— 服务通了17。
第 ④ 步,拿一张吉娃娃的照片去问它。 用的是维基百科上一张吉娃娃图。返回:类别「吉娃娃」,把握 86%18。
书到这里的评语是:服务器正确地、以很高的把握预测出了吉娃娃18。 看起来一切正常。
第 ⑤ 步 —— 停下来,把那个 0.86 到底是什么算一遍。
回到第 04 章那三条事实,它们书自己都印过19:
① 类别顺序是 ['chihuahua', 'muffin']
→ 吉娃娃是第 0 号,松饼是第 1 号 (书自己用文字确认过)
② 训练用的尺是「带 logits 的二分类」那一把
→ 它教模型的是:输出越大,越像第 1 号
③ 第 1 号是松饼
→ 所以 sigmoid 压出来的那个数 = 「是松饼」的把握
把这三条串起来:那个 0.86,含义是「这张图有 86% 的把握是松饼」。
而这张图是吉娃娃。
判断(我们的,不是书里的):第 ④ 步那个「答对了」是假象 —— 模型答错了, 只是被一张反过来的对照表掩盖成了对的。 「哪个数对应哪个类」的这张对照表,行话叫映射。 代码里那张映射写的是「压出来的数大于 0.5 就叫吉娃娃」20, 而这个数 越大越是松饼 —— 反了,于是「86% 是松饼」被印成了「吉娃娃 86%」。 两次颠倒抵消,于是错误看起来像正确。 如果错,会错在: 如果加载数据时给出的类别顺序不是书打印的那样, 或者训练时用的标签不是这套编号,这条判断就不成立。 判据是可查的:书自己在第 04 章印出了那个类别列表, 并且在下一段用文字确认了「吉娃娃在最上面、排第 0 号,松饼排第 1 号」19。
第 ⑥ 步,推上第一家云。 五个文件,git 推上去(细节在第 9 节)21。
第 ⑦ 步,推上第二家云。 一条发布命令,拿到一个公网地址(细节在第 9 节)22。
第 ⑧ 步 —— 反转在这里。这一次拿一张松饼图去问它。
书在本地测第二家云那套代码时,用命令行发了一次请求, 图片地址明明白白是一张松饼;而返回是23:
{"label": "chihuahua",
"prob_chihuahua": 0.6972862305017932,
"prob_muffin": 0.30271376949820683}
书对这个结果一个字都没有评论,直接说「不管你用哪种方法,都能看到服务器成功响应了请求」23。
判断(我们的,不是书里的):这一次的真相和上一次正好相反 —— 模型其实答对了,是那层反着的映射把它印成了错的。 按第 ⑤ 步算出来的口径,0.697 的含义是「有 69.7% 的把握是松饼」 —— 而这张图正是松饼。模型判对了。 可代码里那句「大于 0.5 就叫吉娃娃」把它翻了过来,于是印出来的标签是错的。 更要命的是那两个字段名也跟着反了:
prob_chihuahua那一格里装的是「是松饼」的把握,prob_muffin那一格里装的是「是吉娃娃」的把握 —— 两个名字都贴反了。 如果错,会错在: 同上一条 —— 如果类别顺序或训练标签不是我们推断的那样,整条不成立。 另外要说清:我们没有跑过这个模型,只是按书自己印出来的类别顺序、 损失函数和那段代码推的;这三样书里都有行号。
第 ⑨ 步,把这条线收网 —— 这是全书的落点。
第 03 章:立规矩「输出是原始分数,不是概率」
│
├─ 第 04 章 A:违反了它(拿 0.5 卡原始分数)
│ └→ 第 15 章:**悄悄修好了**(先 sigmoid 再卡 0.5),但书没说自己错过
│
└─ 第 04 章 B:类别名对错了位置
└→ 第 15 章:**原样抄到了线上,而且书一字未评**
图说:这是两条互不相干的线,不许说成一条因果链。 第一条到这一章结束了(被修好了);第二条到这一章才露出全貌。
这本书想教的最后一句话,被它自己坐实了:能上线,不等于是对的。 它花了整整一章讲怎么把模型送出去 —— 服务起来了、云上跑起来了、请求也回来了, 每一步都「成功」。 而那个从第 04 章带来的错误,一路穿过导出、穿过服务、 穿过两家云,没有任何一步会拦住它。 因为没有一个环节在检查「答案对不对」,它们只检查「有没有返回」。
9. 推上公网:两家云,两种做法
书选了两家,而且明说了各自适合谁24:第一家适合小项目和创业团队, 因为它直白、极容易落地;第二家适合大公司、或者要做很复杂的流程。 这两家的名字是 Heroku 和 Microsoft Azure24。
9.1 第一家(Heroku):五个文件,git push 就完事
它的卖点是「你只管代码,基础设施它管」25 —— 服务器怎么搭、怎么扩容,不用你操心。 这一家叫 Heroku;书还提醒了一句实在的:每次跑只花几美分,但仍然要先绑一张卡25。
要准备五个文件,而且后三个的文件名是固定的、不能随便起21:
| 文件 | 文件名 | 干什么 |
|---|---|---|
| 服务代码 | 随便起 | 第 7 节写的那个 |
| 模型文件 | 随便起 | 那份通用格式的模型 |
| 一份启动说明 | Procfile | 告诉它「用哪条命令把这个应用跑起来」 |
| 一份依赖清单 | requirements.txt | 要装哪些包,最好连版本号一起钉死 |
| 一份运行时说明 | runtime.txt | 用哪个版本的 Python(可选,但能避免版本冲突) |
那份启动说明里有一个细节值得记:端口不是写死的,而是取一个环境变量 —— 那个变量由平台在运行时动态塞给你26。写死端口,上去就跑不通。
推上去是五条 git 命令27:建一个本地版本库 → 把远端指向平台给你的那个库 → 把文件加进暂存区 → 提交 → 推上去。 推上去之后平台自动做三件事:把文件复制过去、照依赖清单装好环境、照启动说明把服务拉起来27。
书还留了一条很实在的收尾提醒:不用了就把应用停掉、删掉,免得白花钱28。
9.2 第二家(Microsoft Azure):先分组,再一条命令发布
这一家的路径长一些,因为它先要你把「东西放在哪、谁付钱」这件事理清楚。 它的名字叫 Microsoft Azure24。
先说清一个它反复用的词:资源。 在这家云上,你建出来的每一样东西都叫一个资源 —— 跑你代码的那个应用是一个,它用的存储是一个,数据库也是一个。
第一件要理清的是「谁付钱」:那个既管计费、又装着你所有资源的容器,就叫订阅。
订阅之下还有一级,书把两级都讲得很清楚29:
| 这一级 | 是什么 | 为什么要有 |
|---|---|---|
| 订阅 | 一个计费单位,同时也是资源的逻辑容器 | 一个账号下可以有好几个,比如按项 目分开计费;还能设月度预算上限 |
| 资源组 | 一个项目相关资源的容器 | 好管理、好监控 |
「订阅」「资源组」这两个词照抄它界面上的原话 —— 你照着做的时候会一个个撞见, 所以这里不换成别的说法。
资源组要选一个地区,而选哪儿有三条互相打架的依据30:
- 离用户近 —— 延迟低;
- 法规要求 —— 数据能不能出境;
- 价钱 —— 同样的服务在不同地区价格不一样。
然后建一个「函数应用」(界面上写作 Function App,它就是提供函数执行环境的那个主资源) —— 这一章的配置是31: 按实际用量计费、512 MB(书说这个小模型够用了,而且费用是随规格涨的)、 Python 3.12、地区选在德国中西部。
代码这边要多写三个小文件32:一份全局配置、一份这个函数的配置 (谁能调它 —— 这里设成谁都能调、不用登录;哪些动作允许;所有路径都转给这个函数)、 以及一个把这个函数和你的服务接起来的入口文件。
本地先跑一遍(7071 端口),再一条命令发布上去 —— 它会自己打包、上传、装环境、启动,最后把公网地址打印出来33。
10. 书里的立场与证据
书里给了证据的:
- 本地那次请求的完整返回 —— 状态码和 JSON 都有截图;
- 命令行那次请求的完整返回 —— 类别名和两个概率值,连小数位都印全了(正是这一条让我们能把第 8 节那笔账算出来);
- 发布命令的完整输出 —— 上传体积、耗时、公网地址;
- 依赖清单里的七个包和各自的版本号 —— 原样印了。
作者的经验判断(书里没给证据):
- 「第一家适合小项目,第二家适合大公司」 —— 一个合理的分类,但没有给成本或性能对照;
- 「512 MB 对这个小模型够用」 —— 没有测过;
- 三种协议的取舍 —— 定性描述,没有任何一组关于快慢的实测数字。
书里没交代来历的: 那份通用格式是谁提的、什么时候出现的; 三种协议各自的规范在哪儿 —— 全书一字未提。这一章仍然是零文献。
书里出问题的地方: 那个类别映射,以及对着结果一字未评 —— 见第 8 节的两个判断块。
书里悄悄改 了口径的地方: 阈值那一处 —— 见第 7.2 节。
11. 边界与局限
这本书对的地方先说清:这一章是全书最有价值的一章,也是它区别于同类书的唯一理由。 从「模型只是硬盘上一个文件」这个处境讲起,到端点、到协议选型、到导出格式、 到两家云的完整操作,每一步都能照着做出来。
「端点」那个用自己网站地址栏举的例子,是我们见过讲这个概念最省事的一次; 预处理那四步和训练时逐一对应,也做得很规矩。
但有三处要当心:
- 类别名对错了位置,一路带到线上,而且书对错误的输出一字未评 —— 见第 8 节的两个判断块。这是全书最严重的一处。
- 阈值那条规矩被悄悄修好了,但书没说自己前面错过 —— 见第 7.2 节。 对着第 04 章敲代码的读者,不会知道那一步要改。
- 服务的接入被设成了「谁都能调、不用登录」 —— 书给的理由是「为了简单」32。 这在演示里没问题,但它是一个公网地址 —— 书没有提醒这一点。
这一章没覆盖的:
- 没有任何一步在检查「答案对不对」。 整章的测试只检查「有没有返回、状态码对不对」—— 而这正是那个错误能一路穿过去的原因;
- 模型上线之后怎么盯,没有讲。 第 14 章的英文标题里有「监控」,可那一章讲的是训练期间; 上线之后请求量、延迟、以及模型表现会不会随时间变差,两章都零命中;
- 怎么更新一个已经上线的模型,没有讲。 第 14 章刚讲完模型注册表有版本号, 可这一章的部署里,模型是一个被复制进去的文件,和注册表没有任何关系 —— 两章之间断了;
- 打包成容器只提了一个名字。 CI/CD 那一节提了一句「把代码打成一个能跑的东西」, 举例时提到了容器这个词,但全书没有展开;
- 同时来很多请求会怎样、怎么扩容、成本怎么估,都没有。 一个请求要跑多久,零命中;
- 鉴权、限流、输入校验都没有。 除了「设成谁都能调」那一句,安全侧完全空白。
12. 可带走的
主走查一行写完: 第 04 章那个模型 → 导成通用格式 ONNX(输入 (1,1,32,32)、版本 12)
→ 用 FastAPI 包成一个服务、开 / 和 /predict 两个端点 →
uvicorn 在本机 8000 端口起来 → 拿吉娃娃图问,答「吉娃娃 86%」 →
把 0.86 的真实含义算出来:那是「86% 是松饼」,模型答错了 →
推上 Heroku 和 Microsoft Azure 两家云 → 拿松饼图问,答「吉娃娃 0.697」 →
0.697 的真实含义是「69.7% 是松饼」,模型这次答对了,是标签被印反了。
- 模型留在脚本里等于零 —— 部 署就是把它接进真实流程、让别人能用;
- 后端不直接和用户说话,一切经过前端这个中间人;模型住在后端;
- 接口是「能被别的程序叫到」的那一套,端点是其中一个具体地址;
- 地址栏里那些路径就是端点 —— 这一章只开两个:报活的和干活的;
- 三种协议:REST 最常用(网址 + 动词 + JSON)、gRPC 走二进制所以快、 GraphQL 让调用方自己点菜;
- CI 管「代码进库就自动测、自动构建」,目的是尽早让流程停下来;
- CD 有两个意思,差别只在放行是不是自动的 —— 这就是「周五不上线」的落点;
- 导成通用格式,是为了让不装 PyTorch 的运行环境也能跑;
- 导出时要给一个样例输入(拿它把整张图走一遍)和一个格式版本号;
- 线上的预处理必须和训练时一模一样,差一步就废 —— 灰度、32×32、除 255、挪到 −1~+1、补两维;
- 启动说明(
Procfile)里的端口要取环境变量,不能写死 —— 平台在运行时才塞给你; - 两级容器:订阅是计费单位(可设月度预算),资源组是项目的容器;
- 选地区有三条打架的依据:离用户近 / 法规 / 价钱;
- 那个从第 04 章带来的类别映射错误,穿过导出、服务、两家云,没有一步拦得住 —— 因为没有一个环节在检查答案对不对;
- 「吉娃娃 86%」其实是「86% 是松饼」,模型答错了; 「吉娃娃 0.697」其实是「69.7% 是松饼」,模型答对了,是标签印反了;
- 能上线,不等于是对的 —— 这本书想教的那句话,被它自己坐实了。
13. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 部署是什么、周五不上线 | Chapter 13 | text/15-ch13-chapter-13.txt:7(搜「deployment means responsibility」) |
| CI/CD | Chapter 13 | text/15-ch13-chapter-13.txt:24(搜「continuous delivery (CI/CD)」) · text/15-ch13-chapter-13.txt:29(搜「shared repository」) · text/15-ch13-chapter-13.txt:34(搜「CD can have two meanings」) |
| 前端与后端 | Chapter 13 | text/15-ch13-chapter-13.txt:37(搜「data flow of an internet service」) · text/15-ch13-chapter-13.txt:52(搜「microservices」) · text/15-ch13-chapter-13.txt:54(搜「don't communicate」) |
| 三种协议 | Chapter 13 | text/15-ch13-chapter-13.txt:60(搜「REST API」) · text/15-ch13-chapter-13.txt:69(搜「gRPC」) · text/15-ch13-chapter-13.txt:74(搜「GraphQL」) |
| 端点的定义与例子 | Chapter 13 | text/15-ch13-chapter-13.txt:85(搜「listens to requests at different endpoints」) · text/15-ch13-chapter-13.txt:103(搜「it will implicitly call」) · text/15-ch13-chapter-13.txt:107(搜「two endpoints」) |
| 通用格式与导出 | Chapter 13 | text/15-ch13-chapter-13.txt:117(搜「Open Neural Network Exchange」) · text/15-ch13-chapter-13.txt:124(搜「dummy_input = torch.randn」) |
| 服务的三样零件与第一个端点 | Chapter 13 | text/15-ch13-chapter-13.txt:139(搜「fastapi package」) · text/15-ch13-chapter-13.txt:170(搜「name of the function」) |
| 第二个端点的四步与预处理 | Chapter 13 | text/15-ch13-chapter-13.txt:180(搜「implementation of the」) · text/15-ch13-chapter-13.txt:215(搜「Image preprocessing」) · text/15-ch13-chapter-13.txt:229(搜「logits = session.run」) |
| 本地起服务与测试 | Chapter 13 | text/15-ch13-chapter-13.txt:240(搜「uvicorn.run」) · text/15-ch13-chapter-13.txt:268(搜「accessibility of the server itself」) · text/15-ch13-chapter-13.txt:295(搜「200 OK」) |
| 落点 类别映射的三条事实 | Chapter 4 | text/06-ch04-chapter-4.txt:735(搜「Chihuahua」) · text/06-ch04-chapter-4.txt:741(搜「'chihuahua', 'muffin'」) |
| 落点 线上那次松饼测试 | Chapter 13 | text/15-ch13-chapter-13.txt:232(搜「label = 」) · text/15-ch13-chapter-13.txt:645(搜「Muffin_NIH.jpg」) · text/15-ch13-chapter-13.txt:647(搜「0.6972862305017932」) |
| 第一家云:五个文件与 git | Chapter 13 | text/15-ch13-chapter-13.txt:305(搜「simplifies the deployment」) · text/15-ch13-chapter-13.txt:330(搜「required files」) · text/15-ch13-chapter-13.txt:354(搜「Procfile」) · text/15-ch13-chapter-13.txt:436(搜「push the local changes」) |
| 第一家云:停掉与删掉 | Chapter 13 | text/15-ch13-chapter-13.txt:471(搜「avoid unnecessary costs」) |
| 第二家云:订阅与资源组 | Chapter 13 | text/15-ch13-chapter-13.txt:504(搜「billing unit」) · text/15-ch13-chapter-13.txt:514(搜「resource group」) · text/15-ch13-chapter-13.txt:518(搜「choice of region」) |
| 第二家云:三个文件与函数应用 | Chapter 13 | text/15-ch13-chapter-13.txt:544(搜「host.json」) · text/15-ch13-chapter-13.txt:573(搜「authLevel」) · text/15-ch13-chapter-13.txt:662(搜「Flex Consumption」) · text/15-ch13-chapter-13.txt:673(搜「Germany West Central」) |
| 第二家云:本地跑与发布 | Chapter 13 | text/15-ch13-chapter-13.txt:619(搜「func start」) · text/15-ch13-chapter-13.txt:685(搜「publish」) |