企业官网建设流程全解析

1. 为什么我在生产环境最终选了这模型

先说结论：我所在的团队最近把内部一个“文档理解 + 截图问答 + 图表数字提取”的杂活任务统一收拢到一个模型上，试了一圈开源多模态方案之后，留下来跑在线服务的，就是 Qwen3-VL-32B-Instruct。这篇文章是我从模型选型评估、部署架构到线上调优的完整记录，不是官方文档复读，是把一个32B视觉语言模型真正压到生产线上之后，踩过的坑和验证过有效的做法都写出来。

先说这模型适合谁。如果你手里有这类需求：从扫描 PDF 里抽表格数字、把产品截图转成结构化描述、对着一张UI图问“这个按钮点了之后会发生什么”、给视频关键帧做内容摘要，那么 Qwen3-VL-32B 是当前开源阵营里性价比很突出的选择。相比之下，更大参数的模型效果可能更好，但显存和延迟在小规模集群上根本不现实；更小参数的模型速度快，但复杂版面理解和多图推理又不够稳。32B 是个很微妙的甜点区间：能力明显强于 7B/8B 一代，算力成本又远低于 72B/70B 一代。

另一个关键背景是做多模态视觉语言模型选型时，不能只看跑分。比如某些模型在单张图问答上刷得很高，但一到“多张截图 + 历史对话 + 要求定位到图中某个区域”的真实场景就崩。Qwen3-VL-32B 在三个我实际在意的维度上表现比较均衡：多图联合推理能力、中文场景的OCR和版面分析、“看图文混合内容”时指令跟随的稳定性。翻页、放大、裁剪这种视觉语言任务里很零碎但很要命的需求，它处理得也比前代干脆。

坦白讲，也不是没有替代选项。Qwen2.5-VL-32B 和 Qwen2.5-VL 系列是在同类任务上经常被比较的对象，更大的 Qwen3-VL-32B 在视觉编码器上做了迭代，细节理解能力有提升。真要对比时，建议别只看公开榜单，建议拿自己业务里最难的 20~30 条样本做盲测，我把这条建议也放在后面章节详说。但这篇文章的重心不是评模型，而是“既然选定了，怎么把它伺候好”。

做部署和调优这类模型，本质上做的是一件事：把模型在显存里的生命周期、KV Cache 的大小、量化方案的取舍、并发请求的调度全部理顺，让每一次推理都稳定、够快、不OOM。后面所有章节，都是围绕这几个点展开的，适合已经跑通最小推理 Demo、准备上生产或者正在扩容的同路人参考。

2. 部署不是拉起一个接口那么简单

很多时候我看有人把 32B 模型用 Transformers 库直接model.generate()跑通一次推理，就说“部署完了”。这其实是把编程题做成了“能跑就行”，离生产级部署还差很远。真实生产环境要先回答这些基础问题：模型权重放在哪台机器、驱动能不能支撑、用不用 H20/A100/H800（不需要具体型号，但算力代际差异很大）、QPS 预期多少、单请求最大输入多长、图片分辨率最大会到多少、并发尖峰怎么扛。这些不先定下来，后面全是在打补丁。

2.1 先算清显存这笔账

Qwen3-VL-32B-Instruct 的参数规模是 32B（实际 30.5B A/B 激活参数左右），如果用 BF16 精度原生加载，光权重就占约 64GB 显存。一张 80GB 的卡勉强塞下权重，但基本没剩下多少空间给 KV Cache 和激活值，一推理就撑爆。这也是为什么很多人说 32B 没两张卡玩不动。实际上我们在做显存规划时是这样拆解和计算的。

部署占用主要由四块组成：模型权重（绝大部分显存）、运行时中间激活值（前向计算时的 tensor，批量越大占越多）、KV Cache（存储历史 token 的 Key/Value，供生成阶段重复读取）、CUDA context 和碎片（框架自身开销，往往有 1~2GB 但容易被忽略）。量化就是压第一块；控制 KV Cache 就要调并发度和上下文长度；控制激活值就要限制 batch size 和最大输入 token。

实际规划时我会先把上限列出来，再用 vLLM 的--gpu-memory-utilization参数把显存利用率设为 0.9 左右，让框架自动分配 KV Cache 大小。比如一张 80GB 卡跑 FP8 量化后的 32B（权重约 32GB），能腾给 KV Cache 的空间约 38GB。对于 2K 上下文的短问答场景，KV Cache 可能只占 2~3GB，足够开挺高的并发；但如果跑超长文档，动辄几万 token，KV Cache 会飙到 30GB 以上，这时必须降低并发或继续压缩上下文。

注意：显存不是你算多少就能分多少。vLLM 在启动时会预分配一定比例的显存，如果模型权重加载后剩余空间不足，容易直接启动失败。稳妥的做法是先以单条长上下文请求测出最大 KV Cache 占用，再反推并发上限。

2.2 推理框架选型的心路历程

最初我们试过用 Transformers + Flash Attention 手写一个推理脚本，能跑，但完全扛不住并发。瓶颈有几个：动态 batch 要自己写、KV Cache 不会自动复用管理、连续多轮对话时显存会被未释放的缓存碎片拖垮。生产级别还得处理流式输出的队列、超时、重试，这套自己实现下来，相当于重新发明一个推理服务器，工程量大且容易出 bug。

后来转向 vLLM，效果立竿见影。它在调度上会把不同请求的相同前缀 KV Cache 共享，而且支持 continuous batching。这意味着来了一个短请求，不需要等长请求生成完，立刻插进 batch 执行，排队时间和 GPU 空转率都明显下降。目前 vLLM 已经原生支持 Qwen3-VL 系列，模型加载、视觉 token 处理都不用自己改代码，这对工程化很重要。

如果你只是想快速验证模型效果，用 Transformers 或者官方 quickstart 脚本就够了；但要提供 HTTP 接口、多用户并发、长时间稳定运行，直接上 vLLM（或同类基于 PagedAttention 的框架）是更靠谱的选择。文章后面实际启动、压测、调优的部分，都是以 vLLM 为主展开的。

2.3 “模型放哪”优化了频繁重启的痛点

一个小教训：别把模型文件放在普通的机械硬盘或网络盘上。32B 的权重即使量化后也有 18~30GB，冷启动加载时频繁读盘，慢到怀疑人生。我们最初把模型放在远程共享存储上，每次重启服务要等 8 分钟以上，排障非常痛苦。后来把权重放到本地 NVMe SSD，并开启模型复用（即权重路径不变时不重新加载），重启时间压缩到 40 秒以内。如果是多机部署，建议用共享只读存储 + 各节点本地缓存的方式，避免每台机器重复下权重。

还有一个很多人没注意的点：如果图省事从 HuggingFace 在线拉取权重，可能因网络波动导致加载到一半断了，形成半文件状态。我们遇到过两次，表现是服务起得来但推理结果全错。后来所有生产环境权重都先完整下载、校验文件大小再做本地映射，路径配置到~/.cache/huggingface/hub或一个受管模型目录，绝不直接在启动时临时拉取。

3. 核心实操：vLLM 部署 Qwen3-VL-32B 的完整步骤

这一节给出可以直接抄的部署操作。基于常见实践，环境假设是单机多卡（至少 1 张 80GB 卡，推荐 2 卡），操作系统为 Linux，已装好 NVIDIA 驱动和 CUDA 运行时。以下命令均在 Python 3.10+ 环境下验证过，vLLM 版本建议取当前最新的稳定版（因为多模态支持迭代很快，老版本容易出现视觉编码器兼容问题）。

3.1 环境准备和依赖安装

先用 conda 建一个干净的虚拟环境，避免把系统 Python 搞乱。我习惯把 vLLM、模型依赖、测试脚本都放在同一个环境里，但单独建 env 便于后面升级。量化库按需装，比如 AWQ 就需要对应推理内核支持。

conda create -n vllm-qwen python=3.10 -y conda activate vllm-qwen # 安装 vLLM，务必注意版本兼容性 pip install vllm --upgrade # 验证安装 python -c "import vllm; print(vllm.__version__)"

如果要用量化模型，推荐直接让 vLLM 在启动时传参指定 AWQ 或 FP8 的权重路径，不需要额外安装别的推理库。vLLM 自带的 AWQ 内核优化得不错，至少比通用 CUDA 实现更快；FP8 则要求显卡支持，也就是数据精度格式要硬件兼容，不支持的话强行跑就要 fallback 到低性能路径。

3.2 启动指令与参数逐项解释

一个可用的启动命令长这样（基于常见实践）：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen3-VL-32B-Instruct-AWQ \ --task generate \ --quantization awq \ --dtype float16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 2 \ --served-model-name qwen3vl-32b \ --host 0.0.0.0 \ --port 8000 \ --trust-remote-code \ --limit-mm-per-prompt image=10

逐项说下关键参数的选择逻辑。

--model：直接指向本地量化后的模型路径，不要写 HF 仓库名。生产环境强烈建议下载到本地，理由前面说了，在线拉取不稳定。

--quantization awq：因为用的是 AWQ 量化版本（Int4），显存占用大约是 BF16 的一半左右。如果直接用原版 BF16，这个参数去掉即可，但并发能力会差一截。FP8 的话传--quantization fp8。具体量化格式的选择在下一章展开。

--max-model-len 32768：这是模型能接受的最大上下文长度（输入+输出）。设太大，KV Cache 预留空间就会被拉高，并发数变小；设太小，长文档任务会直接报 context 超限。对于 32B 模型，我们线上设为 32K 是平衡值——文档 OCR 基本够用，显存规划也可控。

--gpu-memory-utilization 0.9：表示允许 vLLM 占用显卡 90% 的显存。剩下的 10% 是给 CUDA context、驱动通信、偶发碎片留缓冲。千万别设 0.99，设过就明白了，OOM 常在毫秒级出现。

--tensor-parallel-size 2：使用 2 张卡跑张量并行。权重和计算均匀 split 到两张卡。这个参数要和实际卡数一致，否则单卡显存撑不下时，启动阶段就会报GPU memory insufficient之类的错误。也可以设 1，但那样最大并发和上下文长度都会受限。

--served-model-name：这是对外暴露的模型名，客户端调用时model字段填这个名字。不设置的话，默认是权重文件夹名，容易在测试和日志里造成混淆。

--limit-mm-per-prompt image=10：限制单次请求里最多带多少张图片。多模态请求中，如果用户一次塞 20 张大图，视觉编码器要生成的 token 数量非常大，拖垮延迟。设个限制，让超限请求被后端直接拒绝，比让它跑到崩溃再重试更理智。

提示：--trust-remote-code是用来加载一些带自定义代码的模型的。Qwen3-VL 系列的配置文件有的依赖本地代码，不信任远程代码会加载失败。但这有安全风险，只应针对可信任的模型权重设置，不要盲目对陌生模型开启。

3.3 验证部署成功的信号

启动成功之后，日志里出现Uvicorn running on http://0.0.0.0:8000以及Application startup complete就说明 HTTP 服务起来了。但我见过不少服务起来了、跑一次请求却报 500 的情况，所以一定要做带图片的完整冒烟测试。

写一个 python 脚本，用 OpenAI 兼容接口对一个本地图片发送对话请求：

import base64 import json import urllib.request with open("test_chart.png", "rb") as f: b64 = base64.b64encode(f.read()).decode() payload = { "model": "qwen3vl-32b", "messages": [ { "role": "user", "content": [ {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{b64}"}}, {"type": "text", "text": "请描述这张图表的趋势，并提取最大值和对应日期。"}, ], } ], "max_tokens": 256, "temperature": 0.2, } req = urllib.request.Request( "http://localhost:8000/v1/chat/completions", data=json.dumps(payload).encode(), headers={"Content-Type": "application/json"}, ) resp = json.loads(urllib.request.urlopen(req, timeout=60).read()) print(resp["choices"][0]["message"]["content"])

第一次请求偏慢是正常的，因为视觉编码器和模型权重在做 warmup。之后请求延迟会显著下降。如果这里能稳定输出内容，说明服务基本可靠，接下来才谈得上性能调优。不少团队跳过这步直接上压测工具，结果收到一堆 502 或者超时，根因是模型加载异常或视觉编码器坏了，压测工具只会加重问题。

4. 量化选型：FP8、AWQ 与原生 BF16 的实测对比

32B 模型部署的第一道坎就是显存。原生 BF16 权重就要 64GB，实际业务中几乎没有卡能留出足够的 KV Cache，所以量化基本是必选项。我实测过三种方案：原生 BF16、FP8、AWQ（Int4），分别从显存占用、推理速度和效果损失三个角度做了对比。以下数据基于我们线上服务压测的平均值，仅供参考，不同卡和框架版本会有差异。

4.1 一张表看懂差异

数据不是全貌，关键还是看业务。比如我们有一个任务是“从表格截图里精确读取每一个单元格的数值”，AWQ 输出偶发会把“1.28”读成“1.26”。这单个错误放在纯文本聊天里可以忽略；但用户要的是财务数字提取，这种错误就是事故。而 FP8 在这类精度敏感任务上和原生几乎无差。

4.2 我为什么不推荐迷信 INT4

很多部署指南推荐一律上 AWQ 或者 GPTQ Int4，理由就是省显存。这个建议在纯文本大模型时代说得通，但在视觉语言模型上要打个大问号。多模态任务有两个特性：一是输入往往是一整页高清截图，视觉编码器要把图片切块转成几千个 token，这些 token 也要走 transformer 层，量化误差会被放大；二是数字、标点、版面坐标这些细节信息敏感，激活值稍微偏一点，提取出来的结构化字段就变了。

另一个隐性问题是视觉编码器本身。Qwen3-VL 系列的视觉部分也有几亿参数，AWQ 的量化过程如果只针对语言模块做校准，视觉特征的输出分布可能会整体偏移，导致“模型好像变笨了，尤其是看图变笨”。我建议如果要上 Int4，务必自己用业务图片集做一遍对比评测，别只看量化前后的 PPL 或公开榜单。

就我们最终的选择而言，如果显存和卡数完全不是问题，我可能会保留 BF16 作为基准；但生产环境只有 80GB 单卡起步时，FP8 是当前最均衡的选择：显存压力可控、推理速度提升、效果损失在绝大多数任务上小到可以忽略、并且 vLLM 的 FP8 支持已经比较成熟，不需要额外转换工具。

4.3 量化模型的自备与验证

如果你决定走 AWQ，自己量化也是可行的。可以用 AutoAWQ 对权重做校准量化，校准数据集建议从真实业务数据里抽取 100~200 条图文样本。自己量化的好处是能针对你的场景调整校准集，缺点是需要额外部署一台有足够显存的机器来做量化转换，并且过程中踩坑不少。对于大多数团队，我建议优先直接用社区已经验证过的量化版权重或官方权重，跑一轮效果盲测——省下的时间足够你多测二十组业务样本了。

自备量化有一个细节必须提醒：量化的group_size和zero_point参数会影响推理。vLLM 的 AWQ 推理内核支持的参数范围有限，部分自定义量化结果会 fallback 到慢速实现，反而比 FP8 更慢。出现这种情况时，日志里会提示 unsupported AWQ scheme 之类的信息。真遇到，要么换用官方量化权重，要么改用 FP8，别花时间调内核参数，性价比太低。

5. 性能调优：从能跑到跑得好

部署成功只是开始，生产环境真正关心的是：并发高了会不会把显存打爆？首字延迟能不能压到可接受范围？同一批长文档任务能不能稳定跑完？这一章把我实测有效和无效的调优手段都写出来，方便直接照做或者避开。

5.1 找对 vLLM 的并发模型

vLLM 对并发处理是动态 batch 的，它不按传统“进程数”或“线程数”来限制并发，而是由显存里的 KV Cache 总量和当前请求的上下文长度共同决定。你可以并发发 50 个请求，但如果每个请求上下文都很长，vLLM 的调度器会让部分请求排队。这不是 bug，是一种保护机制。

我们需要关注两个数值：最大并发数和每秒请求数。最大并发受 KV Cache 限制，可以这样估算：假设单条 32K 上下文请求的 KV Cache 占用约 5GB，显存能分给 KV Cache 的是 40GB，那理论上最多容纳 8 个这样的长请求并行。但如果你的请求大多是 2K 的短对话，KV Cache 占用可能只有 0.5GB，并发上限就变成 80 个。所以别给所有请求设统一的 max_tokens 和输入长度，不同任务类型应该走不同的路由或不同的部署实例。

压测时可以用 vLLM 自带的 benchmark 脚本，或者自己写一段用 asyncio 并发调用接口的脚本。我的建议是先固定请求上下文长度，逐步增加并发数，画一条“延迟-吞吐曲线”。理想状态是吞吐随并发线性上升，延迟增长平稳；如果并发加到某个数值后吞吐不再上升但延迟骤增，说明已经逼近 KV Cache 或者 GPU 算力的拐点，就该停下来了。

5.2 缩短首字延迟的几个有效手段

首字延迟（TTFT）是指从客户端发请求到收到第一个生成 token 的时间。对多模态模型来说，它由三部分组成：图像预处理+视觉编码（大概 0.3~2 秒，取决于图片大小）、prompt 的 prefill 阶段（长上下文时开销明显）、以及排队等待时间（高并发时明显）。

最有效的优化第一刀砍在图片尺寸上。如果你把一张 4000x3000 的大图直接塞给接口，视觉编码器会把它切成大量小块，生成几千个视觉 token，那这个 TTFT 会直接飙到 5 秒以上。而实际上很多业务场景的图片经缩放或裁剪到 1280x1280 以内，信息损失在可接受范围。我们线上对所有图片做了预处理：宽度超过 1600 就等比缩放，低于 320 就适当放大，让模型不会因为“图太小”看不清。这一步实测能砍掉 30%~50% 的 TTFT。

第二刀是给 vLLM 开前缀缓存。vLLM 支持 prefix caching，即相同前缀的 prompt 可以复用 KV Cache。我们的“系统提示词 + 任务指令 + 固定 few-shot 示例”这部分往往是相同的，开 prefix cache 后这部分计算可以直接命中，TTFT 能再降 20% 左右。启动时加--enable-prefix-caching即可。

第三刀是限制单请求的 max_tokens。很多调用方把 max_tokens 默认设到 4096，模型生成了 50 个 token 就停了，但显存还是按 4096 的最大输出长度预留，导致并发白白被压缩。线上尽量把 max_tokens 收敛到任务实际所需。这个操作对吞吐量的提升立竿见影。

5.3 长上下文与长文档任务怎么不崩

32B 的视觉语言模型常被用来做长文档理解，比如把 30 页 PDF 每页转成图片再按顺序发给模型。这种任务有几个坑，一个一个说。

第一个是请求超时。整篇文档可能要生成 2000 个输出 token，同时要跨数十张图片，总耗时可能超过 curl 默认的一分钟超时。如果你是 HTTP 客户端直连 vLLM，务必把 timeout 设到 300 秒以上，而生产环境更推荐用消息队列异步处理，任务提交后轮询结果，避免长时间的连接占用。

第二个是输出中断或 truncated。长输出时，vLLM 在生成到 max_tokens 上限或碰到停止符时才会结束。如果输出 token 超长中间被截断，就要分别处理。做法是给每个请求设置合理的 max_tokens，并让业务层检测 finish_reason 字段。finish_reason 为 length 就要提示用户“内容过长，结果不完整”，而不是拿着截断的半截 JSON 去解析。

第三个是“图片过度密集”导致的丢细节。Qwen3-VL 在多图输入上有上限，但不是图越多效果越好。实测当一页上有超过 10 张贴片或小图时，模型会漏掉部分视觉细节。工程上的对策是分层：先让模型对整页图做版面分析，定位出每个区块的位置，再裁剪小图，分多次请求逐块高分辨率识别，最后汇总结果。这个流程比一次性喂十几张图要稳太多。

第四个是关于图片与文字的混合输入顺序。视觉语言模型对“图在文本前还是后”有响应差异。Qwen3-VL 的习惯是图片 token 在文本描述中穿插，但如果你在 prompt 里先放了一堆文字，再放图，模型可能对图的注意力减弱。实操中我们应该把关键图片紧跟问题说明放，比如“请检查这张图：，然后回答问题”。这个顺序细节，盲测时提升还挺明显的。

6. 生产环境踩坑记录与问题排查速查

部署过程中真正耗时间的不是看文档，而是解决那些文档里没有的诡异问题。这里把我遇到并解决过的、以及同组同事遇到的典型问题整理成速查表，按症状描述、根因、解决办法三个维度展开。这些问题在各类大模型推理服务中都有共性，值得收藏备查。

这里选两个最值得展开的详细说。

6.1 显存莫名其妙被占满

有一次线上服务运行两天后，显存占用持续走高，最后 OOM。一开始怀疑是内存泄漏，查了很久发现是调用方把几张 8K 分辨率的巨大截图直接发给服务，vLLM 为了处理这些图，视觉编码器分配了大量临时激活值。请求结束后，框架因为碎片整理不及时，显存没有完全归还给可用池。这类问题最好在入口层做拦截，在网关或业务服务处直接对超大图做缩放或裁剪，不要让原始大图进入推理服务。

另外，vLLM 的日志里如果能开--enable-memory-profiling之类的调试选项，可以定期输出显存使用分布。生产环境建议配上显存监控面板（如利用 GPU metrics），当显存使用率超过 90% 持续一段时间就告警。这个做法帮我们避免了至少两次线上故障。

6.2 为什么量化后模型偶尔输出乱码

有一阵子我们试用 AWQ 量化权重，发现有约 1% 的请求会输出毫无意义的 token 串，像是模型“疯了”。排查下来发现这些请求都带了高分辨率图片，视觉编码器输出的 token 分布和量化校准数据差太远，导致量化误差在某些层被放大。更换为官方校准过的量化权重后，这个比例降到可忽略。这个案例的教训是：量化模型的异常输出不是 bug，而是量化精度在某些输入分布上失效，需要靠业务层的“重试一次”或“降级到未量化模型”来兜底。

我们现在的兜底策略是：对涉及数字提取、JSON 字段生成的高敏感任务走 FP8 模型；对图文闲聊、内容摘要这类流畅度优先的任务可以走 AWQ 模型；两者共用同一套 API 前缀，通过 nginx 根据请求路径做分流。这样既控制了显存成本，也把量化误差的影响限制在非关键路径上。

6.3 别忽略网络层和客户端的坑

模型服务通了以后，很多问题其实出在网络层或客户端，而不是推理服务本身。比如大图片 base64 编码后 payload 可能达到几 MB，如果并发高，nginx 的client_max_body_size默认 1MB 会直接挡掉请求，这是非常常见的“部署成功但生产不让用”的隐性坑。另外有的客户端库会把 keep-alive 关掉，导致每次请求都重新建 HTTP 连接，TTFT 多出几十毫秒甚至更多。这些都需要在压测前排查干净。

客户端超时设置也经常被忽视。我见过同事把请求超时设成 30 秒，遇到一个 2000 token 的长文生成请求，稳定超时，然后客户端自动重试，每次重试都再次触发长任务，服务雪崩。正确的做法是区分连接超时（短）和读取超时（长），并把超时值对齐到任务的最大预期耗时，同时配合“同一任务 ID 不做并发重试”的逻辑。

7. 多实例部署与水平扩容的一些细节

在线服务只要准备面对真实流量，就不可能永远一台实例扛着。Qwen3-VL-32B 这类模型推理服务做水平扩展时，没那么复杂，但有些细节很容易被忽略。

最有效的扩容方式是“按请求类型分池”。我们把业务拆成三个池子：轻量 OCR/截图问答池（单卡+AWQ，并发高，延迟敏感），长文档理解池（双卡+FP8，并发低，吞吐优先），高精度数字提取池（双卡+FP8，限定并发）。每个池子独立部署一组 vLLM 实例，通过一个统一入口按路由规则转发。好处是互不影响：某天 OCR 流量暴涨，不会把长文档任务的并发挤崩。

扩容时vLLM 实例的负载均衡只需要简单的轮询或最少连接数即可。但要注意，如果开了 prefix caching，同一个请求的前缀最好固定打到同一台实例，否则缓存命中率会下降。我在入口层用“用户ID或任务类型哈希取模”的方式做一致性路由，实测缓存命中率提升了 30% 左右。

多实例部署后另一个关键问题是显存碎片和服务重启。Kubernetes 环境下，vLLM 容器如果被 OOMKilled，重启后冷启动加载 30GB 权重需要 1~2 分钟，这个时间内流量全打给其他实例，可能把其他实例也压垮。应对方式是给每个实例留 20% 的冗余容量，并配置 readiness 探针检查“模型是否完成加载”，而不是默认端口一开就接流量。

8. 最后聊聊一些工程习惯

文章写到这里，该讲的技术点基本都覆盖了。最后我想分享几个贯穿始终的工程习惯，是从多次线上事故和加班里换来的，希望对正在做类似部署的人有帮助。

第一个习惯是：任何配置改动，先记录，再变更，最后验证。一份部署脚本、一个模型路径、一个量化参数，看起来都是小事，但线上事故往往就藏在这些“小事”里。我现在每个服务实例都会在启动命令里写清模型路径、量化方式、版本号和服务名，并且把每次改动都记录到变更文档里，方便出问题时回溯。

第二个习惯是：模型效果评测要持续做，不能只做一次。模型是固定的，但业务数据会漂移。新的 PDF 格式、新的截图风格、新的表格样式出现后，原来效果很好的模型可能突然变差。我们每个月会从线上抽取 100 条样本做回归评测，并保留历史样本集，防止“改了配置导致以前能答对的题现在答错”这样的隐性回退。

第三个习惯是：做多模态应用，不要只用一张“完美样例”做演示。真实用户上传的图片可能是模糊的、歪的、过曝的、带水印的、手机随手拍的。部署调优阶段就要专门用这些“脏图”测一遍，看看模型在退化输入上的表现。这往往能暴露比标准测试集更多的问题，而且这些问题修复后对整个系统的稳定性提升是巨大的。

技术选型和部署只是开始，真正拉高业务价值的是把模型接进流程、持续调优、不断用真实反馈打磨。希望这份实践记录能帮你在自己的多模态部署路上少踩几个坑。有问题或者有更好的方案，欢迎随时交流。