波仔
🧠 第十章 管理和部署
📄 一句话概括

真起一个本地 HTTP 推理服务：启动 19.27 ms，200 次串行请求 P50 0.509 ms、 P95 0.944 ms、QPS 1757。尾巴是 P50 的 1.9 倍，全在调度和 HTTP 解析上，不在模型计算上。

📝 本节和前面几节的关系

上一节讲管理流程。这一节开始讲部署——四种方式怎么选。 先讲最朴素的一种：模型就跑在用户自己那台机器上。

一、本地部署到底是什么

一句话：模型文件和推理程序都装在用户自己的设备上，算的时候不经过任何远程服务器。 三种常见形态：桌面软件里内置一个模型（修图软件的抠图、输入法的联想）、 内网服务器上跑一套服务（公司内部的文档检索）、边缘设备上烧进去一个小模型（摄像头里的人形检测）。 它们共同点都是「数据不离开这台机器或这个内网」。这一点决定了它的适用场景，也决定了它的成本结构。

二、实测：延迟很低，但尾巴不是模型造成的

Demo 用 Python 标准库起了个真的 HTTP 服务，模型是 32 维输入、16 维输出的一次矩阵乘加。 启动 19.27 ms，200 次请求 P50 0.509 ms。 P95 是 0.944 ms，最大 1.322 ms。P95 是 P50 的 1.9 倍——这条尾巴在本地部署里很典型。 它不是模型算得慢。 纯计算只有零点零几毫秒，剩下的是操作系统的线程调度、GC、HTTP 头解析、JSON 编解码。 所以调优的方向要说清楚：如果 P50 已经很低而 P95 高，优化模型没用， 该优化的是请求链路（换更轻的协议、减少序列化、复用连接）。 这也解释了为什么很多本地工具用进程间管道或者共享内存，而不是 HTTP——在同一台机器上， HTTP 的协议开销比计算还大。

三、什么时候必须选本地部署

数据不能出境/出内网。 医疗影像、金融流水、涉密图纸，这一类需求不是「最好别传」，是「绝对不能传」。本地部署是唯一选择。 必须断网可用。工厂车间、野外设备、离线终端。只要依赖远程推理，断网就是全线停摆。 延迟要求极端。要在 10 毫秒内出结果，远程往返本身就做不到。 三条里占一条，基本就锁死本地了。一条都不占的话，本地部署通常是更贵的选择。

四、代价要说清楚

算力在用户手上。用户那台机器可能是五年前的笔记本，跑不动大模型就是跑不动，你没法靠加机器解决。 更新困难。模型升级要用户重新下载几百 MB 到几 GB 的文件。用户不更新，你就要长期维护多个版本。 没有集中观测。线上服务能看到所有请求的日志和指标，本地部署只能靠用户主动上报。 出问题时你手里没有数据。 反过来说，这也带来一个好处：一次部署之后没有持续的服务器账单。 调用量极大、模型又小的时候，本地的总成本可能更低——但前提是模型真的小到能塞进用户设备。

五、动手 Demo：本地服务实测：P50 0.5 毫秒，P95 快到 1 毫秒

用标准库的 ThreadingHTTPServer 在 127.0.0.1 上起一个推理服务，模型是 32 维输入、 16 维输出的一次矩阵乘加； 客户端复用一条连接发 200 次请求，记录每次的往返耗时，算平均、P50、P95、最大值和 QPS。

srv = ThreadingHTTPServer((u"127.0.0.1", 0), Handler)   # 端口 0 = 让系统分
conn = http.client.HTTPConnection(host, port, timeout=10)

for _ in range(200):
    ts.append(one_call(conn, payload))                # 一次完整往返
p95 = float(np.percentile(ts, 95))

实跑输出：

--------------------------------------------------------------------
本地部署：真起一个 HTTP 推理服务，量它的延迟
--------------------------------------------------------------------
  服务地址                 http://127.0.0.1:50092/infer
  启动耗时                 19.27 ms
  模型                     32 维输入、16 维输出，一次矩阵乘法加 sigmoid
  串行请求数               200 次，连接复用

  指标                数值
  -----------------------
  平均延迟        0.568 ms
  P50             0.509 ms
  P95             0.944 ms
  最大            1.322 ms
  墙钟总时长    113.835 ms
  QPS（串行）         1757

  P50 和 P95 差 0.436 ms，最大 1.322 ms。这条尾巴不是模型算得慢，
  是操作系统的调度、GC、HTTP 解析造成的——纯计算只有零点零几毫秒。
  所以本地部署的瓶颈通常不在模型上。真正跑大模型时，瓶颈是显存带宽和算子效率，不是 HTTP。
  本地部署的价值也不是性能，是**数据不出机器**。医疗、金融、内网场景选它，原因在这里。

服务地址里的端口是系统随机分的（这里每次跑都不一样），说明它是真起来的，不是写死的字符串。 启动 19.27 ms 这个数包含建 socket、绑端口、起服务线程。 看起来不快，但这是一次性的，用户装软件时只等一次。 P50 0.509 ms、P95 0.944 ms。 两者的差就是链路的抖动，不是模型的抖动——模型每次算的都是同样的 32 × 16，耗时几乎恒定。 QPS 1757 是串行的结果。它说明单条连接的上限在哪里，不代表多用户场景——那要看下一节。 这个 Demo 用的是小模型，所以延迟数字很小。 换成真的 7B 模型，一次推理是几十到几百毫秒，那时候 HTTP 的开销就可以忽略，瓶颈完全回到计算本身。

30 秒实验

  1. 把请求数从 200 改成 2000，看 P95 会不会更接近 P50（抖动被平均）。
  2. 把连接复用去掉（每次新建连接），看 P50 涨多少。
  3. 想一想：为什么本地部署的更新问题比服务器部署严重得多？

常见误区

  1. 「本地部署延迟最低」——只有模型大的时候成立，小模型反而是 HTTP 开销占大头。
  2. 「本地部署不用运维」——更新、兼容、崩溃上报全在用户那边，更难处理。
  3. 「P95 高就是模型慢」——P50 低而 P95 高，说明问题在链路不在计算。
自测三问（点开对答案） 1. 本地部署的三种常见形态是什么？ —— 桌面软件内置模型、内网服务器跑服务、边缘设备烧进小模型。 2. 什么时候本地部署是唯一选择？ —— 数据绝对不能出机器或内网、必须断网可用、延迟要求极端，占一条就够。 3. P50 低而 P95 高，该优化什么？ —— 请求链路——协议开销、序列化、连接复用，而不是模型计算。

本地部署把算力放在用户手上。下一节反过来：把算力集中到机房。

相关笔记