企业官网建设流程全解析

大模型私有化部署到生产环境这件事，我最近一年多反复在做。先后帮几个内部团队把开源模型从“能跑通 demo”推到真正的生产服务，中间踩的坑比想象中多得多。很多人以为私有化部署就是把模型下载下来、起个服务、给前端调个接口这么简单，真跑到生产环境里就会发现，模型推理延迟、显存碎片、并发打满、安全防护、日志治理，每一个环节都能让人加班到半夜。这篇文章不聊云端 API 调用，专门讲把一个开源大模型完整部署到自己的服务器或内网集群里、让业务方稳定调用，是怎么一步步落地的。适合有一定深度学习基础、但还没完整做过模型服务化的工程师，也适合正在做技术选型、需要给团队指个方向的技术负责人。

先说个结论：私有化部署的难点不在“部署”本身，而在“生产化”。模型权重放到 GPU 上跑通，用 Transformers 库写个推理脚本，几个小时内就能搞定；但要让它在生产环境里扛住真实业务流量，同时保证响应速度、稳定性、安全性和可观测性，需要的是一个完整的服务化工程方案，而不是一个 Python 脚本。

1. 项目概述与核心思路

1.1 私有化部署到底在解决什么问题

大模型私有化部署，本质上是把原本运行在云端 SaaS 服务里的模型能力，搬回到自己掌控的服务器或内网集群中。这么做通常有三个直接驱动力。

第一个是数据安全。业务数据、用户对话内容、内部文档属于敏感信息，不允许出域。很多企业和机构在做 AI 应用时，第一条要求就是“数据不能离开我们的网络”。云端大模型即使承诺不用于训练，从合规审计角度依然难以让安全团队放心。把模型部署在内网，数据从进入到产出全程闭环，合规压力小很多。

第二个是成本可控。云端 API 按 token 计费，业务量上来之后，单个请求的成本虽然不高，但乘以百万级调用量就是一笔不小的支出。如果模型使用频率极高、调用量稳定，自己买 GPU 服务器做推理，摊薄之后的单次成本往往比按量付费低很多。当然，这需要一定的前期硬件投入，不是所有场景都划算，后面我会给一个简单的成本判断方法。

第三个是定制化和稳定性。云端模型版本更新不受自己控制，API 参数、模型行为发生变化时，业务侧只能被动适配。私有化部署之后，模型版本、推理参数、服务策略全部自己说了算，还可以根据业务特点做微调或定制 prompt 策略。尤其是一些需要快速迭代、频繁实验的场景，私有化部署明显更灵活。

这不是说私有化部署一定比云端 API 好。如果业务量不大、数据不敏感、团队没有 GPU 运维能力，直接用云端服务反而更合适。我的经验是：当你有明确的数据边界要求，或者单月 API 调用成本已经超过一台 GPU 服务器的持有成本时，私有化部署才有真正的价值。

1.2 一个完整私有化部署项目的构成

一个能上生产环境的私有化部署项目，至少包含四个层面：模型层、推理层、服务层、运维层。

模型层解决“用什么模型”的问题。选多大参数量的模型、用不用量化、需不需要针对业务微调，这是整个项目的起点。模型选型错误，后面所有工作都白搭。

推理层解决“模型怎么高效跑起来”的问题。生产环境里不能用朴素的 Transformers 推理脚本，需要使用支持连续批处理、显存优化、并发调度的推理引擎。这是整个链路中最吃经验的部分，也是性能差异最大的部分。

服务层解决“业务系统怎么调用模型”的问题。需要提供标准的 API 接口、鉴权机制、流式响应、超时控制、错误处理等。理想情况下，业务方不需要知道自己调用的是一套私有化的大模型服务，接口语义和云端保持一致，切换成本最低。

运维层解决“服务怎么长期稳定跑下去”的问题。包括 GPU 监控、日志收集、模型版本管理、服务扩缩容、安全加固。很多团队在私有化部署时忽略了这一层，结果上线后出了问题只能靠人工一台台查，效率极低。

这四个层面不是顺序执行的关系，而是互相交织。比如推理层的并发参数会影响服务层的超时设置，运维层的监控指标需要从推理层采集。在动手部署之前，先把这个整体结构在脑子里过一遍，后面每一步都会顺畅很多。

2. 部署前的硬件评估与模型选型

2.1 显存怎么算才准确

模型能不能在一张 GPU 上跑起来，只看显存容量是不够的，还要算上推理过程中的额外开销。很多人在这里犯了想当然的错误，拿着模型文件大小对比 GPU 显存，发现文件 16GB、GPU 有 24GB 显存，就以为能跑，结果一启动就 OOM。

一个参数规模为 N 的模型，以 FP16 精度加载，模型权重本身占用的显存大约是 2N 字节。比如一个 7B 模型（70 亿参数），FP16 权重大约占 14GB；13B 模型占 26GB；70B 模型占 140GB。这只是基础值，推理过程中还需要为 KV Cache、激活值、临时计算分配显存。KV Cache 的大小取决于并发数和上下文长度，激活值和临时计算也视框架和 batch size 而定。

我给一个保守的经验公式：

总显存需求 ≈ 模型权重显存 + 推理框架固定开销(约 1-2GB) + KV Cache 预留(按 batch 数 × 上下文长度估算)

以 7B 模型为例，FP16 权重占 14GB，预留 2GB 框架开销、2GB KV Cache，那么单张 24GB 显卡基本能跑起来，但并发能力很有限。如果业务方要求高并发，要么换显存更大的卡，要么用量化把权重压下来。

2.2 模型参数量级与业务场景的匹配

选模型不是一个“越大越好”的问题，而是一个“在效果、成本、延迟之间找平衡”的问题。

7B 级别的中小模型适合什么场景？文本分类、信息抽取、意图识别、简单的问答、代码补全。这类模型速度快、显存占用低、部署成本小，普通单卡就能跑起来。对于很多企业内部工具类场景，7B 模型经过简单微调之后的效果已经够用。

13B 级别适合需要一定推理能力和复杂指令理解、但并发量又不大的场景。比如企业内部知识库问答、报告生成辅助、多轮对话。13B 的效果相比 7B 有明显的提升，但显存和延迟压力也上来了，一般需要 2 张 24GB 或单张 48GB 的卡。

70B 及以上级别适合对生成质量要求很高、对延迟不太敏感的场景，比如复杂逻辑推理、长文本生成、高质量的代码生成。这类模型部署成本极高，通常需要多卡张并行推理，并且要做量化才能落到单机。我个人建议，除非场景明确需要，不要一上来就选 70B 级别，先把 13B 或者 7B 玩透，很多业务需求已经能解决。

还有一个很容易忽视的选择维度：模型的上下文长度。长上下文能力直接影响 KV Cache 的占用。一个 4K 上下文和一个 16K 上下文的模型，同样并发下显存占用差距可能超过一倍。选型时如果业务场景不需要超长输入，刻意追求长上下文反而会拖累整体性能。

2.3 量化方案选型与效果取舍

量化是把模型权重从高精度降到低精度，从而减少显存占用和推理延迟。FP16 转 INT8 显存减半，转 INT4 显存减到四分之一，但精度也会有损失。

INT8 量化对模型效果的影响通常很小，大部分业务场景都感受不到明显差异，可以放心用。INT4 量化则要谨慎，虽然显存占用大幅下降，但在某些任务上会出现明显的回答质量下降，尤其是数学推理、代码生成这类对精度敏感的任务。

做私有化部署时，我的建议是：单卡能装下 FP16 就不要量化，单卡装不下优先考虑 INT8，实在不行再上 INT4。如果连 INT4 都装不下，那就不是量化能解决的问题，需要考虑换模型或加硬件。

另外，尽量选择硬件厂商深度优化的量化方案。同一张卡上，用对了加速库和手工调优的量化算子，推理速度能差出 30% 甚至更多。这些细节通常写在硬件厂商的官方文档里，部署前一定要花时间看。

2.4 并发量预估与成本判断

私有化部署要不要做，除了数据安全这个因素之外，成本也是一个硬指标。判断方法是估算自己的实际调用量，算一笔账。

假设业务每天有 10 万次请求，每个请求平均输入输出加起来 2000 token，一天就是 2 亿 token。按当前市面主流云端大模型 API 价格，粗略按每百万 token 数十元到数百元计算，一天的成本大约在数百到数千元区间，一个月下来就是几万元甚至更高。

一台能跑 13B 量化模型的服务器，硬件成本大约十万元级别，按三年折旧算，每月也只有数千元。再加上电费、维护成本，如果调用量足够大，私有化部署的成本优势非常明显。反过来，如果一天只有几百次请求，私有化部署的性价比就很低了。

硬件选型上我再给一个通用参考：7B 模型做低并发推理，单张 24GB 显卡够用；13B 模型做中等并发，优先考虑双卡 24GB 或单卡 48GB；需要高并发低延迟的话，显存要留足冗余，而不是卡着上限配。

这里有一个我踩过的坑：为了省成本，GPU 显存刚好卡在模型刚能启动的量级，结果上线后并发稍有波动就 OOM。生产环境必须给显存留 20%-30% 的缓冲区，别贪。

3. 推理运行时与模型服务搭建

3.1 为什么不能直接用 Transformers 做生产推理

很多第一次做私有化部署的人，会写一个简单的 Python 脚本，用 Transformers 库加载模型，然后通过 Flask 或 FastAPI 暴露接口。这种方式跑通 demo 没问题，但放到生产环境里会遇到三个致命问题。

第一个问题是吞吐量太低。朴素推理脚本一次只处理一个请求，GPU 利用率低得可怜。大模型推理的并行特性很强，多个请求可以共享模型权重，同时进行批处理。Transformers 原生方式缺乏这种调度能力，GPU 算力大量浪费在等待上。

第二个问题是显存管理低效。推理过程中需要维护 KV Cache，朴素脚本通常一次性预分配大量显存，或者频繁动态分配释放，导致显存碎片化严重。跑一段时间后，即使显存总量够用，也可能因为碎片化问题分配不出连续的显存块。

第三个问题是缺少工程化能力。没有请求排队机制、没有超时控制、没有动态批处理策略，一旦并发上来，请求直接堆死。这不是模型问题，而是服务架构问题。

因此生产环境的推理必须使用专门的推理引擎。它们本质上是把“模型加载、显存管理、请求调度、批处理决策”这些底层工作打包处理，让上层只需要关心业务逻辑。

3.2 主流的推理框架怎么选

目前市面上主流的开源推理框架有几个典型代表，各自适用场景不同。选型前先梳理一下自己的需求：显存多大、模型多大、并发多高、需不需要流式输出、有没有多模型切换需求。

偏重高性能、高吞吐的场景，适合用 vLLM 这一类引擎。它的核心优势是引入 PagedAttention 显存管理技术，把 KV Cache 分块管理，显存利用率接近最大化；同时支持 continuous batching，新请求可以随时插入到正在执行的批次中，不用等当前批次全部跑完。实测下来，同样的模型和 GPU，vLLM 的吞吐量通常比朴素 Transformers 推理高出数倍，甚至一个数量级。

偏重轻量部署、快速上手的场景，用 Ollama 更合适。它的优势是封装程度极高，模型管理和服务启动几乎是傻瓜式的，几条命令就能完成部署。缺点是底层调度黑盒，难以做精细化调优，并发能力和大规模适配能力有限。适合个人项目或者内部小范围工具，不适合严肃的大规模业务生产环境。

还有一种情况是内部已有大模型训练或微调平台，深度绑定了一个推理框架，这时候不需要额外引入新框架，直接用平台自带的推理服务。这类方案的好处是跟训练流程衔接无缝，坏处是社区生态可能不活跃，遇到问题排查起来麻烦。

我自己在多个项目里主推 vLLM，原因是它在性能、开源活跃度、与主流生态兼容性上平衡得最好。下面以 vLLM 为例，讲一下实际部署过程。

3.3 vLLM 部署实操与关键参数

vLLM 的部署过程本身不算复杂，核心是理解那些启动参数的含义，然后根据业务场景做配置。基础启动命令大概是这样的：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/my-7b-model \ --served-model-name my-model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.90 \ --max-model-len 4096 \ --max-num-seqs 32 \ --host 0.0.0.0 \ --port 8000 \ --dtype auto

--model指定模型路径。如果模型是本地下载好的，指到本地目录；如果是从模型仓库拉取，填仓库 ID 也行。生产环境建议先把模型下载到本地，避免运行时依赖外网。

--tensor-parallel-size是张量并行度。单卡部署填 1；如果单卡显存放不下或者需要更高吞吐，填 2 就表示把模型切分到两张卡上并行推理。注意这个值不是越大越好，并行度越高，卡间通信开销越大，小模型用多卡反而可能变慢。

--gpu-memory-utilization是最关键的性能参数，表示允许 vLLM 使用 GPU 显存的比例。默认值是 0.9，如果显存比较紧张，需要适度调低。这个值调太高，留给推理引擎之外的开销太紧，容易出现启动阶段分配失败；调太低，留给 KV Cache 的空间就少，并发吞吐上不去。

--max-model-len是允许的最大序列长度，直接影响 KV Cache 上限。这个值设置得越大，显存预留就越保守，能并发的请求数就越少。要根据业务真实最大输入输出长度来设置，别盲目调大。

--max-num-seqs是最大并发序列数，通俗理解就是同时最多处理多少个请求。这个值不是拍脑袋定的，它跟显存、max-model-len、平均请求长度强相关。我一般先用默认值跑基准测试，观测 GPU 利用率和显存水位，再逐步调大，压到显存使用率 90% 左右为止。

启动之后，vLLM 会自带一个 OpenAI 兼容的 HTTP 服务，支持/v1/chat/completions和/v1/completions接口。业务方用标准的 OpenAI SDK 修改一下 base_url 就能接入，改造工作量很小。

下面用一个简单的 Python 请求示例验证服务是否正常：

import requests response = requests.post( "http://127.0.0.1:8000/v1/chat/completions", headers={"Authorization": "Bearer fake-key"}, json={ "model": "my-model", "messages": [{"role": "user", "content": "介绍一下大模型私有化部署"}], "stream": False, "max_tokens": 512, "temperature": 0.7, } ) print(response.json()["choices"][0]["message"]["content"])

返回正常就说明接口服务通了。不过这只是第一步，生产环境还需要做大量的工程封装。

4. 服务封装与对外接口设计

4.1 为什么建议走一层 API 网关

推理框架提供的原生 HTTP 接口可以直接给业务调用吗？可以，但不推荐。原因有三个：鉴权、限流、多模型路由。

原生接口默认接受的鉴权非常薄弱，如果直接暴露给业务系统，一旦调用方鉴权配置失误，整个推理服务就是裸奔状态。限流能力更是几乎没有，业务方某个接口写了个死循环，能把推理服务打到 OOM。多模型路由也不支持，只能一个模型一个端口，维护成本很高。

我习惯在推理框架前面加一层 API 网关，或者至少加一个基于 Nginx 的反向代理层。网关负责统一鉴权、按调用方做限流、把不同业务请求路由到不同的模型实例上，同时记录访问日志。这层顺手还能做一层输入输出过滤，把明显异常的请求拦在前面，一定程度上保护模型服务。

如果团队里已经有成熟的 API 网关设施，直接接入就行；如果没有，用 Nginx 做一层简单的反向代理也能解决大部分问题。关键是把“模型服务”和“业务入口”剥离开来，模型服务不直接暴露给业务方。

4.2 鉴权方案的落地细节

私有化部署的模型服务，最简单的鉴权方式是共享密钥：业务方在请求头里带一个固定的 token，网关校验 token 是否合法。实现成本最低，适合内网环境、调用方角色不多的小规模场景。

稍微正规一点的方案是给每个调用方分配独立的 API Key，网关根据 Key 识别调用方身份，可以做细粒度的配额管理。某个调用方的流量暴涨时，可以直接在网关封禁对应 Key，而不用影响其他业务。

更进一步，如果模型服务要开放给外部合作伙伴调用，建议在网关层接入统一的认证体系，用标准的 OAuth 2.0 或企业内部统一登录体系签发的令牌，而不是自建一套密钥系统。自建密钥系统在早期能跑，后续维护成本和安全隐患都不小。

鉴权配置时有一个容易忽略的问题：推理服务自身监听的端口如果直接绑定在 0.0.0.0 上，即便网关做了鉴权，攻击者也可能绕过网关直连推理端口。安全做法是让推理服务监听内网地址，网关是唯一的外部入口，通过防火墙或安全组限制推理服务端口只允许网关访问。

4.3 流式响应与超时控制

大模型生成一个字一个点往外蹦，如果业务端要等整段生成完再返回，用户体感会很差。生产环境必须支持流式响应，也就是 SSE（Server-Sent Events），边生成边推给前端。

vLLM 原生支持流式输出，接入时业务方把请求参数里的stream设置为 True，接口就会以 SSE 格式持续返回增量内容。前端用标准的 SSE 或 fetch stream 读取即可。这里要注意的是，底层网关和代理层必须正确配置对 SSE 的支持，尤其是关闭代理缓冲。缓冲开启时，中间层会把整个响应攒完再推给前端，流式效果直接没了。

超时控制同样重要。大模型单次生成十几秒甚至几十秒都很正常，但如果服务异常卡住，调用方不能无限等待。一般建议在网关层设置合理的请求超时时间，同时在业务方也设置客户端超时。两层超时配合，才能避免某个请求把整个调用链拖死。

另外还要注意应用层的重试策略。模型服务偶发超时或返回异常时，业务方可以自动重试，但重试次数和间隔要克制。无限重试或者重试间隔过短，只会放大故障，把模型服务彻底打挂。

关于流式响应，我特别提一个坑：网上很多教程让前端用 EventSource 接流，但 EventSource 不支持自定义请求头。如果鉴权 token 放在 header 里，前端就没法直接用 EventSource 调接口。要么改用 fetch + ReadableStream 读取 SSE，要么把鉴权信息放到 URL 参数或 Cookie 里。这个坑在对接 web 端时几乎一定会遇到。

4.4 多模型服务与版本管理

生产环境里通常不止一个模型在跑。不同业务场景可能需要不同规格的模型，同一个模型也可能在迭代更新。这就要解决两个问题：多个模型怎么共存、模型版本怎么切换。

如果模型数量不多，最直接的办法是一个模型起一个推理服务实例，各占一个端口，由网关做路由分发。比如 7B 模型服务占 8001 端口，13B 模型服务占 8002 端口，网关根据请求路径或参数分发到对应端口。这个方案简单直观，缺点是多实例会重复加载模型，内存和显存有浪费。

如果模型数量多且存在明显的错峰调用，可以考虑在单实例内部同时加载多个模型。vLLM 支持多模型共存，通过--serve-models或模型配置参数即可。这种方式显存利用率高，但模型之间会争抢计算资源，一个模型流量暴涨时会拖慢另一个模型。

模型版本管理的核心诉求是“灰度切换”。新模型上线前，最好先在独立的影子实例上跑一段时间，对比新旧模型的输出质量，确认没问题后再把流量切过来。如果发现新模型效果反而不如旧模型，还要能快速回滚。因此模型文件目录建议具备版本号，服务配置里指向对应版本，切换本质上就是改配置重启服务。整个流程和传统后端服务的发布流程没有本质区别，提前规划好路径，别等到上线那天才手忙脚乱。

5. 监控、告警与安全加固

5.1 GPU 监控：必配项而不是可选项

GPU 是私有化部署里最贵的资源，也是最先出问题的地方。生产环境上线后，第一件事就是配置 GPU 监控。

必做的基础监控指标包括：显存使用率、GPU 利用率、显存温度、功耗、PCIe 带宽。显存使用率直接反映还有多少余量支撑并发；GPU 利用率反映算力有没有跑满；温度过高会触发降频，算力下降导致推理变慢。

GPU 信息在 Linux 下用nvidia-smi命令就能实时查看，但生产环境不可能每次都人工登录服务器去看。建议用一种支持 Prometheus 协议的 GPU 监控 exporter，把指标暴露出来，由 Prometheus 定期采集，再接到 Grafana 面板或告警系统里。显存使用率超过 90% 就告警，GPU 温度超过 80 度就告警，这两条是最基本的。

日志方面，推理服务本身会输出大量日志，包括每个请求的延迟、吞吐、token 数、异常信息。这些日志要接入统一的日志采集平台，不能用nohup把输出重定向到单一文件就完事。日志里要包含请求唯一标识，业务方传入 request_id 时透传它，问题排查时能从日志串起整个请求链路。

5.2 安全加固：网络、输入、输出三层防线

私有化部署不等于绝对安全。模型服务一旦暴露出来，同样面临滥用、攻击、数据泄露风险。安全加固至少要做三层。

网络层：模型服务所在的机器只开放必要端口，对外访问走防火墙或安全组白名单。GPU 机器的 SSH 端口不要直接暴露到公网，能通过跳板机或堡垒机访问就尽量走堡垒机。内网环境还要考虑 VLAN 隔离，模型服务所在网段与办公网段分开。

输入层：对用户提交的内容做基础的过滤和长度校验。虽然大模型本身自带一定的内容审核能力，但业务侧仍然需要根据实际场景补充输入审核。对长度异常、格式异常、明显恶意的请求，在网关层拦截掉，不送到模型推理。

输出层：大模型的输出是不可控的，即便输入合规，也可能生成不合规的内容。如果业务场景对合规性要求严格，需要在模型服务返回内容后增加一道输出审核环节。这一步会增加响应延迟，但合规要求明确的场景里不能省。输出审核可以采用规则加模型双重判断，优先做关键敏感词过滤和内容分类，再根据业务需求决定是否引入专门的审核模型。

5.3 模型更新与备份策略

模型服务上线后还面临频繁更新的问题。新版本模型微调完成、效果验证通过，需要平滑替换线上模型，不能直接杀掉旧服务重启新服务，会造成服务中断。

我习惯的做法是：推理服务多节点部署，节点 A 继续服务旧模型，节点 B 先加载新模型并做预热，确认状态稳定后，网关把流量从节点 A 切到节点 B，节点 A 再下线。整个过程对调用方无感。如果在资源有限的单机环境，没有多节点可切换，至少要提前在低峰期预留服务重启时间窗口，并通知业务方。

备份同样不能漏。模型文件本身占用空间不小，建议做定期快照备份，同时对服务配置、启动命令、环境依赖版本做好记录。很多人部署完模型后，半年后再去更新，发现自己都忘了当时是怎么配置的。把配置文件、启动脚本、部署文档统一放到代码仓库管理，不是形式主义，是实际能救命的事。

6. 常见问题排查与实操经验

6.1 显存不够与 OOM 的排查清单

模型服务启动就报 OOM，是最常见的问题，通常有几个原因。

首先是显存估算不准确。之前按 FP16 权重算了显存，但实际启动时框架还会预留 KV Cache 空间、激活值空间，加之其他进程占用显存，超出卡的上限。排查时先用nvidia-smi看当前显存占用，确认是否有其他进程占着显存，再逐步调整gpu-memory-utilization参数。

其次是max-model-len设置过大。同样的模型，支持的上下文长度翻倍，KV Cache 占用几乎翻倍。如果业务根本不需要长上下文，把这个参数调小立竿见影。

第三是并发值设置过大。max-num-seqs设得越高，运行时需要为每个请求预留的 KV Cache 就越多，显存很快就会见底。排查时逐步降低并发值，找到当前显存条件下的最佳平衡点。

6.2 推理延迟忽高忽低的原因与应对

生产环境里延迟不稳定，通常有三种情况。

第一种情况是请求并发波动导致的排队延迟。模型服务的并发处理能力有限，并发上来后，新请求只能排队等前面请求执行完。这不是服务异常，而是容量规划问题。解决方法是限制单实例最大并发，在网关层做排队和削峰，或者横向扩展更多推理实例。

第二种情况是显存碎片化导致的分配缓慢。如果用的推理框架没有好的显存管理机制，运行一段时间后显存碎片化，新请求分配显存的耗时越来越长。这类问题的排查特征是：刚启动时延迟正常，跑几天后延迟逐渐变差。解决方法是升级推理框架版本，或者定时重启服务释放碎片。

第三种情况是 CPU 与 GPU 之间的数据传输瓶颈。如果服务端处理 prompt 解析、token 采样时 CPU 负载过高，或模型加载时 CPU 加载权重过慢，整个请求的延迟会显著上升。排查时看 GPU 利用率和 CPU 使用率的比例，找出瓶颈在哪一端。

6.3 流式输出断流与响应超时的常见坑

流式输出在实际使用中经常出现“生成到一半断了”的现象。常见原因是网关或代理层设置了太短的响应超时时间。大模型生成超过 30 秒很常见，如果中间层 20 秒就把连接断了，前端自然就看到断流。排查时需要把网关超时、反向代理超时、客户端读取超时几个环节都放开，统一调到足够大的值。

另一个意外情况是模型本身推理出错，导致流式输出中断。这种情况要在服务日志里查报错信息，大多数推理框架会记录中断原因。如果是因为输入触发了模型异常状态，还需要在输入侧做拦截，提前过滤可能触发问题的内容。

响应超时还有一个容易忽视的原因：业务方用同步等待的方式调用了流式接口。流式接口本质上是先返回响应头，然后持续推送数据，如果调用方用同步 HTTP 客户端等待整个响应体完全返回，感知到的就是“非常慢”。正确的做法是用支持流式读取的客户端，逐步消费数据。

6.4 模型输出质量变差的排查思路

上线时模型效果正常，运行一段时间后输出质量下降，也是需要认真排查的。

一种情况是 prompt 或上下文被业务方改动，导致模型行为偏移。尤其是有业务方在请求里拼接了大量不规范的额外上下文，模型对用户指令的跟随能力就会下降。排查时对比线上请求和基准测试时的输入差异。

另一种情况是量化参数导致的精度问题。有些硬件平台为了追求推理速度，动态开启了一些精度优化开关，可能导致模型输出出现可感知的质量下降。如果业务对输出质量敏感，建议把推理精度强制设置为 FP16 或更高，不要依赖硬件的动态精度调节。

还有一种情况是模型版本被意外回退或替换。这种问题靠日志很难第一时间发现，需要在部署文档里记录每个模型的版本信息和启动状态，定期对比线上模型文件的校验值，确保线上跑的就是想要的那个版本。

6.5 长上下文带来的显存暴涨困境

业务场景需要长上下文时，显存占用会剧烈膨胀。这个问题在部署初期没有充分预估，上线后才会暴露。

一个比较实用的处理方式是限制上下文长度并按需扩容。在业务允许范围内，把max-model-len设置为实际需要值而不是越大越好；确实需要长上下文的场景，用更大的 GPU 显存做支撑，同时降低并发数。还有一种做法是引入上下文压缩技术，在送入模型前对历史对话或长文档做摘要，减少实际送入的 token 数。这不是模型本身能解决的，需要业务侧配合改造。

上下文长度和并发是鱼与熊掌的关系，部署时务必根据业务真实需求做取舍，不要在两者上同时追求极致。

最后聊点个人的体会

做私有化部署这一年多，我最大的体会是：技术方案永远是相对简单的部分，真正难的是让整个系统在长期运行中保持稳定。模型推理框架再强，没有监控、没有版本管理、没有安全加固，迟早要出事。所以我在每一次部署的时候，都会先把运维和安全体系搭好，再回头优化推理性能。顺序反了，后面要返的工是非常痛苦的。

还有一个小技巧想分享给正在做这件事的人：私有化部署的验收标准不要太单一，延迟低不代表系统稳，吞吐高不代表效果好。我习惯在部署完成后做一套基准测试，包含延迟、吞吐、错误率、显存水位、输出质量五个维度，再用这套基准去指导后续每一次优化和升级。有了基准，后面团队任何一个人想改参数，都有依据可循，不会瞎调。

如果你正在计划做私有化部署，我建议先拿一个非核心业务场景做试点，把这条链路完整跑一遍，再逐步扩大范围。不要把第一个生产项目就压在一个核心业务上，那样出了问题大家压力都很大。私有化部署这条路不难走，但确实需要稳扎稳打，一步一步来。