内部系统原来调的是云端接口现在数据不能出内网业务代码又不想改——这类需求这两年我碰到过太多次。答案其实不复杂把 H3 模型用 vLLM-Omni 在本地跑起来对外暴露一个 OpenAI 兼容 API业务侧只改base_url和一个 key其余一行不动。这件事听起来像部署个模型这么简单真动手才会发现坑集中在三个地方显存账算不清、启动参数拍脑袋、接口看着兼容实际处处是边界。这篇就把这几个环节拆开讲透从显存预算怎么手算、vllm serve那串参数为什么这么给、多模态输入和流式输出怎么写一直讲到上线后怎么压测、怎么排查那几类最常见的报错。适合已经能跑通单卡推理、但还没把模型变成服务的读者也适合负责把内部系统从云端迁回本地、需要一份可复现方案的同行。1. 方案选型为什么最后落到 vLLM-Omni 这条路上1.1 先搞清楚真正要解决的问题不是跑起来很多人第一步就走偏了拿到权重先写个transformers的generate()脚本能出字了就觉得搞定了。但那个东西离服务差着十万八千里。真正的需求清单其实有四条第一接口形态要是 OpenAI 兼容的/v1/chat/completions、/v1/models、/v1/embeddings这些路径和字段结构得对得上否则客户端 SDK 直接报错第二要能扛并发两个人同时提问不能排队等到天荒地老第三要有 KV 复用和批处理不然每次请求都从头算 prefilltoken 成本高得离谱第四行为要可控超时、限流、日志、鉴权这些得有地方挂。只有第一条的话随手写个 FastAPI 转发层包一层也能骗过客户端但第二、第三条基本无解。所以选型的核心不是哪个框架名气大而是哪个框架把这四件事同时解决了。1.2 三条路线的实际取舍我把常见的三条路摆在一起对比过结论很明确路线上手成本并发能力接口兼容度多模态支持适合场景原生transformers脚本极低无单请求串行需自己写需自己拼单人调试、效果验证专用推理框架多种可选中等强多数自带视版本而定生产部署vLLM-Omni中等强自带 OpenAI Server原生覆盖文本/图像等既要吞吐又要多模态第一列那条路我只在验证权重有没有损坏的时候用。第二条路里各家都有自己的取舍有的偏重极致延迟有的偏重生态兼容我选 vLLM-Omni 的直接原因是我的这份 H3 权重是带视觉编码器的版本文本和图像要进同一条推理流水线如果文本走一个框架、图像走另一个框架中间那层胶水代码的维护成本会吃掉所有收益。Omni 这条路的价值就在于它把多模态前端和文本后端放在同一个调度器下面一个进程搞定运维面收敛。提示如果你手上的权重是纯文本版本下面第 3 节里所有带图像参数的步骤都可以跳过其余内容完全通用。1.3 Omni 在这一层到底做了什么要理解参数为什么那么给得先知道框架内部在干什么。文本侧的核心是两块PagedAttention和连续批处理continuous batching。前者把 KV Cache 切成固定大小的 block 来管理像操作系统管内存页一样避免了预分配导致的显存浪费这也是为什么它能支持很高的并发后者让不同请求可以在同一个 iteration 里混着跑新请求随时插队不用等当前批次全部结束。多模态侧则是加了一层预处理前端图像、音频这类输入先过编码器打成 embedding再和文本 token 拼成一条序列送进主干。H3 这种规模的模型视觉编码器往往单独占几百 MB 到一两 GB 显存这部分开销经常被忽略导致算显存预算时对不上账。对外那层是 FastAPI uvicorn 起的一个 HTTP 服务把内部调度器包成 OpenAI 的协议格式。所以严格说OpenAI 兼容 API不是模型的能力是这层前端的翻译能力——字段映射错一个客户端就报400。2. 动手前的显存预算这笔账必须先算2.1 硬件与软件栈的最低要求先说硬性门槛。bf16 推理需要比较新的架构支持太老的卡跑起来要么降精度要么直接不认。多卡张量并行TP对卡间带宽敏感有条件走高速互联实在没有PCIe 也能跑只是通信开销会吃掉一部分吞吐。软件栈的版本对齐比想象中脆弱。驱动、CUDA runtime、PyTorch、框架本体这四个东西的版本必须互相咬合任何一个超前或落后一档症状往往是编译期报一堆看不懂的符号错误或者运行到一半 NCCL 卡死。我的习惯是先确定框架版本再反推它要求的 torch 和 CUDA最后装驱动而不是反过来——因为驱动向下兼容框架向上不兼容。磁盘方面权重的实际体积等于参数量乘精度字节数再留出 20% 余量给 tokenizer、配置文件和日志。放在 NVMe 上加载速度能差出好几倍。内存建议不低于权重体积的 1.5 倍因为加载过程中会有 mmap 和临时缓冲内存不够会直接被 OOM Killer 干掉进程而且日志里看不出是内存问题。2.2 权重、KV Cache 与框架开销的三段式算法我把显存拆成三块来算比拍脑袋准得多。第一块权重显存。公式是参数量 × 每参数字节。bf16 是 2 字节fp8 是 1 字节4bit 量化是 0.5 字节。这部分是刚性的省不掉。第二块KV Cache。这是弹性的也是最容易被低估的。单个 token 的 KV 占用算法是每 token 每层 KV 字节 2 × KV头数 × head_dim × KV精度字节数 每 token 总 KV 字节 上式 × 层数乘 2 是因为 K 和 V 各存一份。注意这里用的是KV 头数不是注意力头数——现在主流模型普遍用 GQAKV 头数远小于 Q 头数这个差别直接决定了你能开多大上下文。举个具体的算例。假设这份 H3 的配置是 64 层、hidden size 5120、32 个注意力头、8 个 KV 头、head_dim 128KV 用 bf16单 token 单层 2 × 8 × 128 × 2 4096 字节 4 KB单 token 全模型 4 KB × 64 层 256 KB8K 上下文单序列 256 KB × 8192 ≈ 2 GB32K 上下文单序列 256 KB × 32768 ≈ 8 GB看到这个数字就知道为什么 32K 上下文配 32 并发是不现实的——光 KV 就要 256 GB比权重还夸张。这也是很多人启动时报max seq len is larger than the maximum number of tokens that can be stored in KV cache的根因。第三块框架开销。包括 CUDA context、激活值峰值、CUDA Graph 的显存池、视觉编码器常驻。经验值文本模型留 1~2 GB带视觉编码器的留 2~3 GB开了 CUDA Graph 再上浮。把三块加起来再除以卡数才是每张卡的压力。这里有个反直觉的点TP 切分切的是权重和计算KV Cache 是按卡存的所以两张卡做 TP 时每张卡上的权重是一半但 KV Cache 也是各自存一份自己的那部分算并发时要按单卡可用显存算。2.3 上下文、并发与卡型的对照参考把上面的算法套进几个典型配置做个对照表方便你拿到自己的config.json之后直接对号入座上下文长度单序列 KV 占用单卡 80Ggpu-util 0.9可支撑并发备注4K≈ 1 GB30短问答、分类任务首选8K≈ 2 GB15~20常规对话的甜点区32K≈ 8 GB5~7长文档摘要需配合 chunked prefill128K≈ 32 GB1~2建议单独起实例别和短请求混跑这张表的用法是先确定业务里 P99 的输入长度再倒推并发上限最后去定--max-num-seqs。反过来拍一个很大的并发数运行时会被 KV Cache 分配器挡住请求排队表现为服务没挂但特别慢排查起来很耗时间。3. 部署实操从零到跑通一个 OpenAI 兼容端点3.1 容器化环境搭建把版本漂移挡在门外我强烈建议用容器理由不是现在流行容器而是这个技术栈的版本耦合度太高。宿主机上原有的 CUDA 和 Python 环境大概率和你需要的那套冲突裸机装出来一个能跑的版本换台机器又得重来一遍。基础镜像选和框架官方文档匹配的那个标签别自己从ubuntu:latest开始拼。启动参数里有两个必须点名的docker run --gpus all \ --ipchost \ --shm-size16g \ -p 8000:8000 \ -v /data/models:/models:ro \ -v /data/hf-cache:/root/.cache/huggingface \ --name h3-serving \ -it 你的vllm-omni镜像标签 bash--ipchost是关键。多卡通信和部分数据加载依赖共享内存默认的 64 MB/dev/shm会让 NCCL 初始化直接卡死或者报错退出而且报错信息非常隐晦往往只写个unhandled system error。加上--shm-size是双保险。权重挂载用只读:ro这是个习惯问题——容器里不小心写坏了权重重下几十 GB 的成本比加两个字符高太多。缓存目录单独挂出来避免每次重启容器都重新做一遍 tokenizer 和 processor 的初始化。如果是裸机上装对应的是pip install -U vllm # 多模态支持可能还需要额外依赖 pip install -U vllm[audio] pillow装完先跑一句python -c import vllm; print(vllm.__version__)确认版本再看一眼这个版本对应的vllm serve参数列表因为参数名在不同小版本之间改过好几次网上抄来的命令直接跑经常撞在unrecognized arguments上。3.2 启动命令与关键参数逐条拆解真正启动服务的命令长这样我把每个参数为什么这么给写在后面vllm serve /models/h3 \ --served-model-name h3 \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2 \ --dtype bfloat16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 16 \ --max-num-batched-tokens 8192 \ --enable-prefix-caching \ --enable-chunked-prefill \ --trust-remote-code \ --api-key 自定义令牌 \ --limit-mm-per-prompt {image: 4}--served-model-name是给外部调用方看的名字客户端里model填的就是它和本地路径不需要一致。我一般起个短名字好处是以后换权重目录时客户端不用改。--tensor-parallel-size 2表示两张卡切权重。这里有个硬约束TP 数必须能整除注意力头数和 KV 头数。8 个 KV 头配 3 张卡是不行的会直接报错退出。所以多卡机器不一定能全用上4 卡机器配 8 KV 头TP4 可以TP3 不行。--dtype bfloat16显式指定不要指望自动推断。自动推断在某些权重上会给你挑成 float16然后出现数值溢出导致输出重复或者直接变成乱码。--max-model-len 32768是允许的最大上下文。这个值和 KV Cache 直接挂钩设太大了启动阶段就 OOM。建议做法先用小值比如 8192把服务拉起来确认权重和模板没问题再往大调。--gpu-memory-utilization 0.90是允许框架占用的显存比例。0.9 是个稳妥值留 10% 给 CUDA context 和突发峰值。如果是共享卡上面还跑着别的进程降到 0.7 甚至 0.6否则跑到一半被别人挤爆报错会出现在别人的进程里非常难追。--max-num-seqs 16直接决定同时处理的序列数。给太大没有意义KV Cache 不够自然会挡住给太小则浪费显存。按第 2 节算出来的并发上限打个八折比较合适。--max-num-batched-tokens 8192是单次迭代处理的 token 上限。这个值影响的是首 token 延迟和吞吐的平衡调大吞吐上去但单个请求的首 token 变慢调小响应更灵敏吞吐下降。对话类业务我一般给 4096~8192批处理类给 16384 以上。--enable-prefix-caching打开前缀缓存。只要你的业务里有大量相同 system prompt这个开关的收益非常明显——公共前缀只算一次后续请求直接命中缓存。实测在固定 system prompt 的客服场景里首 token 延迟能降一半以上。--enable-chunked-prefill让长 prompt 分块处理避免一个超长请求把整个批次的 GPU 占死。长文档场景必开。--limit-mm-per-prompt限制单次请求里的图片数量。不设的话有人一次塞二十张图进来显存瞬间见底。旧版本用image4的写法新版本用 JSON跑之前先确认版本。服务起来之后屏幕上会打印一张表里面有几个数字要重点看可用 KV Cache block 数、最大并发数、KV Cache 能覆盖的最大 token 数。这三个数字比任何文档都直观地告诉你你这套配置到底能扛多少。3.3 第一次连通性验证别急着上业务代码服务起来先别写业务逻辑用最朴素的方式确认端点活着curl -s http://127.0.0.1:8000/v1/models \ -H Authorization: Bearer 自定义令牌 | python -m json.tool返回里应该能看到--served-model-name指定的那个名字。看不到说明服务没起来或者被--api-key挡了返回 401。再发一个最小请求curl -s http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 自定义令牌 \ -d { model: h3, messages: [{role: user, content: 用一句话解释什么是张量并行}], max_tokens: 128, temperature: 0.2 }这里最容易出的问题是输出成段重复或者夹杂乱符号。九成情况下不是模型坏了是chat template 没匹配上。不同模型对对话格式的要求不一样模板不对等于把裸文本硬塞给模型它只能瞎接。检查方式是看权重目录里有没有chat_template相关文件或者用--chat-template显式指定一个。Python SDK 侧更省事from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_key自定义令牌, timeout120.0, ) resp client.chat.completions.create( modelh3, messages[ {role: system, content: 你是一名严谨的技术助手回答简洁。}, {role: user, content: 把下面这段话压缩成三个要点……}, ], temperature0.3, max_tokens512, ) print(resp.choices[0].message.content) print(resp.usage)timeout一定要显式给。SDK 默认超时对本地大模型来说短得离谱长 prompt 的首 token 就可能超过它表现出来是客户端报超时但服务端日志显示请求正常完成——这种假故障最耗排查时间。usage字段里的 prompt/completion token 数也别忽略它是后面算成本和压测的基准数据。3.4 多模态输入与流式输出的正确写法图像输入走的是 OpenAI 的image_url结构本地文件转 base64 塞进 data URI不需要额外起文件服务import base64 from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_key自定义令牌) def to_data_url(path: str) - str: with open(path, rb) as f: b64 base64.b64encode(f.read()).decode() ext path.rsplit(., 1)[-1].lower() mime image/png if ext png else image/jpeg return fdata:{mime};base64,{b64} resp client.chat.completions.create( modelh3, messages[{ role: user, content: [ {type: text, text: 描述这张图里出现的表格结构并指出表头列名。}, {type: image_url, image_url: {url: to_data_url(/data/samples/table.jpg)}}, ], }], max_tokens1024, ) print(resp.choices[0].message.content)两个经验点。第一base64 会让请求体积膨胀约 33%一张 2 MB 的图变成 2.7 MB 的 JSON网关的 body 大小限制要提前放开否则直接 413。第二图片分辨率不是越高越好很多视觉编码器内部会做 resize传 4K 原图纯属浪费带宽和时间长边压到 1024~1568 之间通常足够识别表格和文字。流式输出在对话场景几乎是必须的用户等首字比等全文的心理感受差太多stream client.chat.completions.create( modelh3, messages[{role: user, content: 写一段 300 字的产品介绍}], streamTrue, temperature0.7, ) for chunk in stream: if not chunk.choices: continue delta chunk.choices[0].delta if delta.content: print(delta.content, end, flushTrue)if not chunk.choices这个判空不能省。有些实现在最后一个 chunk 里会带 usage 统计而不带 choices不判空直接索引会抛IndexError而且这个问题只在特定请求结尾出现测试时容易漏。4. 让它能上生产网关、兼容边界与可观测性4.1 套一层薄网关别把推理服务直接暴露推理服务本身不适合直接对外。它没有限流、没有密钥轮换、没有统一的超时兜底重启的时候还会把正在处理的请求全部掐断。中间加一层网关nginx 或自己写的 FastAPI 薄壳都行成本很低但收益明显。nginx 侧最关键的三条location /v1/ { proxy_pass http://127.0.0.1:8000/v1/; proxy_http_version 1.1; proxy_buffering off; proxy_read_timeout 300s; client_max_body_size 20m; }proxy_buffering off是流式输出的命门。默认开启缓冲nginx 会攒够一批才往下发前端看到的效果就是卡住半天然后一次性全出来完全失去流式的意义。proxy_read_timeout给足长 prompt 首 token 超过 60 秒是很正常的事。client_max_body_size配合上一节说的 base64 膨胀。密钥管理上对外发的是网关的 key网关再换成推理服务的 key这样轮换密钥不用改客户端也不用重启推理服务。我吃过一次亏直接把--api-key发给业务方后来要换 key只能挨个通知中间还有漏掉的系统在报 401折腾了一下午。4.2 结构化输出与工具调用的兼容边界OpenAI 兼容这四个字要打个折看。路径和基础字段是兼容的但一些高级能力要看模型侧的模板支持程度。结构化输出response_format走json_schema在 vLLM 侧一般是通过引导式解码实现的——解码时对不合法的 token 直接置零概率所以能保证输出一定是合法 JSON。这对下游解析极其友好可以省掉一大堆正则修补。但要注意约束越严格解码速度越慢schema 里如果嵌套了几十层生成会明显变卡。工具调用tool_calls能不能用取决于两件事模型的 chat template 里有没有定义工具调用的格式以及框架版本有没有把这块解析出来。判断方法很直接发一个带tools的请求看返回里finish_reason是不是tool_calls、message.tool_calls是不是有内容。如果返回的是纯文本里夹着 JSON 字符串说明模板没对齐这时候要么换模板要么自己在前端解析文本——后者虽然丑但在快速上线阶段是可行的兜底。Embedding 接口要单独确认。多模态模型的文本主干能不能直接当 embedding 用取决于权重里有没有导出对应的池化配置。如果/v1/embeddings返回 404 或者维度对不上别硬凑单独部署一个小型 embedding 模型更省事成本也低得多。4.3 监控指标与压测方法服务默认会暴露/metricsPrometheus 格式。上生产至少要盯这几个指标含义异常信号num_requests_running正在处理的请求数长期等于 max_num_seqs说明排队严重num_requests_waiting排队中的请求数持续大于 0 且增长需扩实例gpu_cache_usage_percKV Cache 占用率长期 95% 以上几乎没有调度余量time_to_first_token_seconds首 token 延迟P99 突然翻倍先看是否有超长 prompttime_per_output_token_seconds单 token 生成耗时走高通常意味着并发把显存压满了gpu_cache_usage_perc是我最看重的指标。它长期贴着 100%意味着新请求进来必须等别人释放 block表现是延迟毛刺。这时候的正确做法不是加卡而是降--max-model-len或者降--max-num-seqs把水位拉回来。压测别用自己写的 for 循环那种测法测不出并发瓶颈。框架自带压测工具直接指定模型名和请求分布vllm bench serve \ --backend openai-chat \ --base-url http://127.0.0.1:8000 \ --model h3 \ --endpoint /v1/chat/completions \ --num-prompts 200 \ --request-rate 8 \ --max-concurrency 8重点关注三个输出请求吞吐req/s、输出 token 吞吐output tok/s、TTFT 和 TPOT 的分位数。很多人只看吞吐但业务体感由 P99 的 TTFT 决定——平均 200ms、P99 三秒用户照样骂。--request-rate从低往高扫找到 TTFT 的拐点那个点就是这套配置的真实容量上限。5. 常见问题与排查实录5.1 启动阶段从报错信息倒推根因启动阶段挂掉信息量其实很足关键是别被表层文字带偏。CUDA out of memory出现在加载权重时十有八九是--max-model-len给太大KV Cache 预分配不下。解法是先把max-model-len降到 4096把服务拉起来看日志里打印的最大可支撑 token 数再按那个值往回设。另一个可能是--gpu-memory-utilization给到了 0.95 以上CUDA context 没地方放降到 0.85~0.9。The models max seq len is larger than ... KV cache这条几乎全是同一个原因上下文设得比显存能撑的大。按第 2 节的公式算一遍把数字对上就解决了。NCCL error或进程在初始化阶段卡住不动先怀疑两件事容器没加--ipchost或者多卡之间被防火墙/端口占用了通信端口。前者看我第 3.1 节的启动参数后者试着重启容器换一组端口。如果卡了超过五分钟没有任何输出基本可以判定是通信问题别等。unrecognized arguments是版本不匹配。vllm serve的参数名在不同版本之间改过--enable-prefix-caching在某个版本之后变成默认开启、不再需要显式给--limit-mm-per-prompt的取值格式也从image4变成了 JSON。跑之前vllm serve --help | grep 关键字确认一下比在网上到处找答案快。trust_remote_code相关的报错说明权重目录里有自定义的 modeling 文件而你没加这个开关。加上就行。但要注意这是执行仓库里的代码生产环境务必先把权重来源确认清楚。5.2 运行阶段能跑但不对劲的那类问题这类问题最磨人因为服务没挂日志也没红字。输出重复、复读、或者中途开始胡言乱语。按可能性排序chat template 不匹配 dtype 用了 float16 导致数值溢出 采样参数极端temperature 0 且 top_p 极小在某些模型上会退化成死循环。排查顺序就按这个来先换模板测试再显式指定--dtype bfloat16最后调采样。首 token 特别慢但吐字很快。说明卡在 prefill 阶段。三个方向prompt 太长看日志里的 prompt token 数、--max-num-batched-tokens给太小导致长 prompt 被切得太碎、prefix caching 没开导致公共前缀反复计算。实测把 system prompt 固定下来并开启前缀缓存TTFT 能降一半以上。并发一上来就报超时单请求却很快。典型的 KV Cache 打满。看gpu_cache_usage_perc如果是 100%说明请求在排队。此时降并发目标或者降上下文长度而不是加机器。图片请求返回 400。三个检查点content数组里的type字段拼写对不对image_url不是image、image_url.url是不是合法的 data URI、--limit-mm-per-prompt的上限有没有被超过。这三个错一个都会返回 400但错误信息措辞不一样仔细看 message 字段能区分。服务跑几个小时后变慢重启就好。显存碎片或者缓存块没回收干净。先确认框架版本不是有已知问题的那个短期缓解办法是给服务加个定时健康检查连续 N 次gpu_cache_usage_perc异常就自动重启。长期方案是升级版本。5.3 一份可以直接抄的排查速查表现象最可能原因第一个动作启动即 OOMmax-model-len 过大降到 4096 重试读日志里的可用 token 数启动卡住无输出共享内存不足 / 通信问题加--ipchost --shm-size16g参数不识别版本不匹配vllm serve --help对照输出复读chat template 不匹配指定--chat-template或核对模板文件客户端超时、服务端正常SDK 默认超时过短显式设置timeout120以上流式输出一次性吐出网关开了缓冲proxy_buffering off图片请求 400结构字段错误 / 超出数量限制核对image_url结构与limit-mm-per-prompt并发升高就慢KV Cache 打满看gpu_cache_usage_perc降上下文或并发多卡利用率不均TP 不能被头数整除改 TP 为 2/4/8 这类 2 的幂长时间运行后性能衰减显存碎片加健康检查自动重启或升级版本6. 几个值得单独调的性能开关6.1 前缀缓存与分块预填充的实战收益这两个开关我在多个场景下对比过收益差异很大值得单独说。前缀缓存的收益完全取决于你的 prompt 里有多少固定前缀。客服问答场景system prompt 加知识库片段可能有两三千 token命中率超过 90%TTFT 直接砍半。但如果你的场景是每段 prompt 都完全不同的长文档摘要命中率接近零开了也只是多占一点内存做索引不会变慢但也不会有收益。分块预填充的价值在长 prompt 混跑场景。不开的话一个 30K token 的请求进来会把整个 iteration 占满期间所有短请求全部堵住P99 延迟出现巨大毛刺。开了之后长请求被切成若干块短请求可以插在块之间执行牺牲一点点长请求的绝对延迟换来整体尾延迟的大幅改善。这个权衡在有长短混合流量的系统里非常划算。6.2 量化与 KV Cache 精度的取舍权重从 bf16 降到 fp8显存直接省一半这是最立竿见影的手段。代价是精度损失体现在哪里要看任务事实性问答和摘要类任务基本感觉不到差别数学推理和多步逻辑链会有可测量的下降最好在切换前用你自己的评测集跑一遍对比而不是只看通用榜单。KV Cache 单独降精度--kv-cache-dtype fp8是另一个维度能让你在同样的显存下开更大上下文或者更高并发。它的影响比权重量化小一些但要注意硬件支持情况老卡上可能跑不了或者反而更慢。我的建议顺序是先调参数上下文、并发、批大小把显存压下来还不够再上 KV Cache 量化最后才考虑权重量化。因为前者是零损失的后者是有代价的。6.3 用健康检查把假活着的服务识别出来最后这个是运维层面的经验。推理服务有一种状态叫假活着进程在、端口通、/health返回 200但实际请求全部超时或者返回空。这种情况用常规的端口探测完全发现不了。我的做法是健康检查里真发一次极短的推理请求比如让它输出一个固定的词设一个 5 秒的硬超时连续三次失败才重启。这样既能识别真挂也能识别假活同时避免因为瞬时负载导致的误杀——毕竟重启一次要重新加载权重代价不小。我在实际使用中最大的体会是把模型变成服务这件事难点从来不在把模型跑起来而在算清楚账和把参数对上号。前面那个显存三段式算法我建议你每次换模型、换卡型、换上下文长度都老老实实重算一遍花五分钟能省下好几个小时的试错。至于参数调优别信任何一篇文章里的最佳值包括这篇——你机器上的流量分布和别人不一样--max-num-batched-tokens到底是 4096 还是 16384只有你自己的压测曲线能回答。
