用 Agent 用久了，模型这一层迟早会碰到两个绕不过去的问题。
第一是账单。单个任务看着不贵，但 Agent 有个特点：一次用户请求背后可能是十几轮模型调用——思考、调工具、看结果、再思考。乘起来之后，账单曲线和「聊天机器人」完全不是一个量级。
第二是数据。要把 Agent 接进真实业务，它就得读内部文档、客户资料、业务数据。这些东西怎么往外发、发给谁，很多团队是没法轻描淡写过去的。
把开源模型跑在自己的服务器上，是同时回应这两个问题的一条路。这篇讲具体怎么搭：用 vLLM 起一套推理服务，然后接进 OpenClaw。
先划清楚和站内旧文的界线：本地模型怎么接 讲的是在桌面上用 Ollama、LM Studio 跑小模型，面向的是「一个人、一台机器、私有数据不出网」。本篇面向的是另一种场景——部署在服务器上的推理服务，要同时服务多个 Agent、多个任务，还要考虑并发、限流和稳定性。两者解决的不是同一个问题。
一、先判断：你到底该不该自建
自建不是「更专业的选择」，它是有明确代价的。先把该不该做判断清楚，比看命令行参数重要得多。
值得自建的情况：
- 数据确实不能出内网。这是最硬的理由。当数据的流向是合规或客户合同的硬约束时，自建不是选项之一，而是唯一解。
- 调用量足够大。量大到自有 GPU 的折旧和电费明显低于同等的 API 开销，经济账才算得过来。
- 需要固定版本、结果可复现。云端的模型会静默升级，昨天跑通的任务今天可能就不一样了。自建可以锁死模型版本，这对需要回放验证的场景很关键。
- 需要微调或特殊后处理。想接自己的 LoRA、想改采样逻辑、想挂自定义分词或约束解码，自建是前提。
别折腾的情况：
- 只是偶尔用、量很小——自建的固定成本摊不下来，反而更贵。
- 手头没有合适的 GPU——注意「合适的」这三个字，消费级显卡跑大参数模型基本没意义。
- 团队里没人愿意值班——推理服务是线上服务，会崩、会 OOM、会被打满。没人管，它就会在最忙的时候挂掉。
二、开工前先算显存，这是唯一的硬约束
自建失败最常见的原因只有一个：显存不够，跑不起来。所以第一件事不是装软件，是算账。
显存主要吃在三块：
- 模型权重。估算公式很简单：
参数量 × 每个参数占用的字节数。FP16／BF16 是 2 字节，FP8 和 INT8 是 1 字节，INT4 大约 0.5 到 0.6 字节。所以一个 32B 参数的模型，FP16 大约是 64GB，量化到 FP8 大约是 32GB，INT4 大约 18GB 上下。 - KV Cache。这是缓存上下文用的，随上下文长度和并发数线性增长，而且经常是显存占用的隐形大头。上下文开到 32K 和开到 128K，差的是好几倍。粗略估法：在权重之外再留 20% 到 40%，上下文长、并发高就往高的方向留。
- 运行时开销。激活值、临时缓冲区、框架本身。再留个几 GB 的余量。
算完拿结论去选卡：先定显存，再选模型，不要反过来。很多人是先看中一个模型，买卡回来才发现塞不进去，最后只能靠极端量化硬凑——而极端量化对 Agent 任务往往意味着灾难（下面会讲为什么）。
如果显存不够，你有四个抓手，按推荐顺序排：换更小的模型 > 降量化档位 > 缩短最大上下文 > 加卡做张量并行。最后一项成本最高，但效果最确定。
三、量化档位怎么选：别为了省显存牺牲工具调用
量化就是拿精度换显存。四个档位，代价不一样：
- FP16 / BF16：最稳，效果基线。显存需求最大。如果卡够，就用它。
- FP8：显存减半，在较新的卡上精度损失通常很小，是当前性价比较高的甜点档。需要硬件支持（较新的数据中心卡才有原生 FP8）。
- INT8：显存和 FP8 同量级，兼容性更广，但实际部署中调优的麻烦程度往往高于 FP8。除非硬件不支持 FP8，否则优先考虑 FP8。
- INT4（AWQ / GPTQ）：显存再减一半，普通问答和摘要任务可以接受。但对 Agent 任务要特别小心。
最后一条展开说。Agent 和普通聊天的差别在于，它要稳定地输出结构化内容——工具调用的参数是 JSON，字段名、类型、嵌套层级一个都不能错。量化到低精度之后，最先退化的恰恰是这类「格式严谨」的输出能力：偶尔少个引号、偶尔把数字变成字符串、偶尔把嵌套结构压平。这些错误在聊天里无伤大雅，在工具调用里就是直接失败。
所以一条实用建议：跑 Agent 任务的模型，量化档位不要低于 FP8。如果显存只够 INT4，宁可换个小一号的模型用 FP8 跑。「小模型高精度」在工具调用场景下，通常比「大模型低精度」更可靠——这一点和纯对话场景的结论是相反的。
四、起服务：几个必须设对的参数
vLLM 的安装很直接，官方提供 pip 包和容器镜像两条路。容器镜像更省事，尤其是驱动和 CUDA 版本需要固定的场景。启动命令大致长这样：
vllm serve <模型路径或仓库名> \
--served-model-name my-agent-model \
--max-model-len 32768 \
--gpu-memory-utilization 0.90 \
--tensor-parallel-size 2 \
--quantization fp8 \
--api-key <自己的密钥>几个参数值得单独说：
--served-model-name：客户端看到并调用的模型名字。起个自己认得清的名字，后面接 OpenClaw 要用它。--max-model-len：最容易踩坑的参数。它决定了 KV Cache 能开多大，直接吃显存。不要一上来就拉满——先按业务真实需要设，跑顺了再往上加。设得过大，服务会在启动时直接 OOM，或者勉强起来但并发一高就炸。--gpu-memory-utilization：允许占用的显存比例，常用 0.85 到 0.90。留一点余量给系统和其他进程，别设 1.0。--tensor-parallel-size：张量并行度，必须等于你实际使用的 GPU 数量。设成 2 但只有 1 张卡，或者 4 张卡只写 2，都会出问题。这一条配错报错信息往往不直观，新手容易卡很久。--quantization：量化方式，要和模型权重文件的格式对应。用 FP8 权重就得写 fp8，用 AWQ 权重就得写 awq，写错会直接加载失败。
服务起来之后，先做两个最小验证再做别的：一是查一下模型列表接口确认服务活着，二是发一条最短的对话请求确认能正常返回。这两步过了，说明兼容层是通的，再去接 Agent。
五、接进 OpenClaw：把端点指过去就行
vLLM 起的是 OpenAI 兼容接口，所以接入方式和接任何一家云厂商几乎一样——把 base_url 指向你的服务器地址加 /v1，模型名填 --served-model-name 定的那个，再把密钥填上。接国产大模型的那套配置方法 可以原样复用，只是把地址从厂商域名换成了你自己的内网地址。
接进去之后有几件事值得做：
- 先用一条真实的小任务验证，而不是只看接口通不通。最好挑一个会用到工具调用的任务——因为工具调用才是低精度量化最容易出问题的地方，只有跑过才算验证过。
- 按用途分模型，别所有任务都打同一个大模型。摘要、分类、打标签这类活交给小模型，判断和规划交给大模型，两套服务分开起。这样显存和成本都能省下来一大截。
- 把它当成一个普通的模型来源纳入多模型管理。自建服务和云 API 不是二选一的关系：可以配成主备，或者按任务类型分流。怎么设计降级台阶，站内 多模型容灾怎么配 讲得很清楚，自建服务在这个体系里只是多了一个「本地」的 provider。
六、上线前还要补的四件事
「跑起来了」和「能稳定用」之间，隔着这四件事：
- 健康检查与进程守护。vLLM 提供健康检查接口，配一个定时探测。更要紧的是守护：进程崩了要能自动拉起来，而不是等你发现业务全挂。容器部署的场景下，站内 部署到服务器的做法 里那套重启策略可以直接用。
- 并发与排队。服务能同时处理多少请求是有上限的，超了就排队，排久了就超时。要把并发上限设在一个明确的数字上，并且知道超过之后的行为是什么——是排队等待，还是直接拒绝。模糊的行为等于没有行为。
- 限流与配额。如果一套服务要给多个 Agent、多个业务线共用，必须按调用方分配额度。否则一个跑飞的批处理任务就能把整个服务的配额吃光，其他业务一起遭殃。设计思路参考 限流与配额怎么设计。
- 超时与回退。自建服务会抖动——显存吃紧、请求排队、偶发推理变慢。要给调用方设一个明确超时，超时后能自动切到备用服务或云 API。没有回退的自建，稳定性反而比纯用云 API 更差。
七、别把服务裸奔在公网上
这一条要单独拎出来讲，因为踩过的人太多了：推理服务默认是没有鉴权的。谁扫到你的端口，谁就能白嫖你的卡，顺便还能用你的上下文数据做点什么。
稳妥的做法是：服务只监听内网地址，不直接暴露公网；需要外部访问时走反向代理加鉴权，并且启动时就把 --api-key 设上。具体怎么配反向代理和访问控制，和 OpenClaw 部署到服务器 里讲的是同一套东西。另外，如果服务要用来处理内部敏感数据，那前面第一步提到的字段分级和脱敏规则同样要套上——自建解决了「数据不出内网」，但没有解决「数据该不该给模型看」。
八、成本到底怎么算才对
很多人比价的算法是：「这卡一小时多少钱」对比「API 每百万 token 多少钱」。这个算法是错的，因为忽略了两个变量。
第一是有效吞吐。一张卡在理想情况下能跑多少 token，和你在真实业务下的稳定吞吐，往往差好几倍——受并发、上下文长度、批处理效率影响。
第二是闲置率。业务有高峰有低谷，卡是 24 小时计费的。如果一天只有 4 小时打满，其余时间闲置，那闲置的成本要全部摊到那 4 小时上。
所以正确的口径是：用「每个月设备与运维总成本 ÷ 当月实际产出的 token 数」，去对比云 API 的实际单价。按这个算法，很多「看起来自建更便宜」的场景，算完发现并不便宜——站内 自部署成本为什么会反超 那篇里有个现成的例子，值得先看一遍再决定。整体成本框架可以对照 成本怎么算怎么省 一起看。
一个务实的折中方案：白天高峰走云 API 保稳定，夜间的批处理任务（文章处理、索引重建、批量分析）跑自建。这样既有稳定的对外服务能力，又用闲置时段把自建的固定成本摊薄了。
九、四个最容易踩的坑
--max-model-len一上来就拉满。结果要么启动就 OOM，要么起来了但并发一高就崩。按业务需要设，别按参数上限设。- 张量并行度和卡数不匹配。配错了报错信息不直观，能浪费很久时间。启动前数一遍卡。
- 跑起来就当能用了，不做压测。用一个并发脚本打一打，看它在压力下的表现（延迟曲线、失败率、显存水位）。这一步省掉，问题一定会在生产环境里出现，而且是在最不方便的时候。
- 不锁版本。模型权重和推理引擎的版本一变，输出就可能跟着变。上一版跑得好好的任务突然失败，你连「是什么变了」都不知道。所以模型和引擎的版本都要固定下来并记录，改动要有验证——这套做法站内 模型版本管理 讲得很完整，自建场景下甚至比云端更需要它。
优缺点和适合人群
优点：数据不出内网，这是很多场景的硬需求；调用量足够大时单 token 成本能明显下降；模型版本完全可控，结果可复现；能挂 LoRA、能改推理逻辑，定制空间比调 API 大得多。
缺点：前期要买卡、要调参、要算显存，投入不小；它是线上服务，会崩会 OOM，需要有人值班；小规模场景下固定成本摊不薄，很可能比直接调 API 更贵；模型迭代速度比云厂商慢，新模型出来要自己重新评估和部署。
适合：数据敏感且有稳定调用量的团队（金融、医疗、法务、政企方向尤其典型）；需要严格版本控制做回放验证的场景；有闲置 GPU 资源、想把它利用起来的团队。反过来，如果你的调用量一个月只有几百万 token，或者团队里没有熟悉 GPU 运维的人，先用云 API 把业务跑通，比自建更划算。
总结
- 先判断该不该自建：数据不能出门、量足够大、要固定版本，这三条里至少占一条再动手。
- 先算显存再选模型：权重加 KV Cache 加运行开销，留 20% 到 40% 余量，别反过来先看中模型。
- 量化别低于 FP8：工具调用对格式要求高，低精度最先坏的就是这个；显存不够宁可换小模型。
- 参数里最容易错的三个：
--max-model-len别拉满、--tensor-parallel-size要等于卡数、--quantization要和权重格式对上。 - 上线要补四件事：健康检查、并发上限、按调用方限流、超时回退——外加别把没鉴权的服务暴露在公网。
- 成本按实际产出算：别拿卡的小时价直接对比 token 单价，把闲置率算进去。
最后一句实话：自建推理不是一个技术炫技的选择，而是一个成本与合规的取舍。它适合的是「量已经到了」或者「数据确实不能出去」的团队。如果你现在只是想省点钱，先去做提示词缓存和任务分流，那两件事的投入产出比高得多，也快得多。
