AI 推理部署指南：模型、显存、量化与服务并发的权衡

先明确推理任务，而不是先买显卡

部署大模型首先要定义目标：是交互式聊天、代码补全、批量文档抽取，还是向量嵌入？它们对首 token 延迟、每秒生成速度、上下文长度、批量吞吐和可用性的要求不同。个人实验可以容忍排队，面向用户的服务则需要稳定尾延迟、并发控制和容量规划。一个模型在单用户演示中回答流畅，不代表它能在多个请求同时到达时保持体验。选择硬件之前，先准备一组代表真实输入的任务和质量基线。

推理时资源都花在哪里

推理服务主要承受模型权重、激活张量和 KV cache 的内存占用。权重体积受参数量和数值精度影响；量化可以降低权重存储与带宽需求，但不同方法会影响精度和算子支持。KV cache 随上下文长度和并发会话增长，长上下文可能让内存压力比模型权重更突出。预填充阶段处理输入 token，解码阶段逐步生成 token，两者的计算模式不同，因此显存充足并不自动意味着低延迟。CPU、内存带宽、GPU 互联、存储加载速度和驱动兼容也可能成为瓶颈。

模型、量化与硬件的选择

先以模型卡、许可证和验证集筛选候选模型，再在目标硬件上实测。不要只按参数量比较；架构、词表、上下文窗口、训练数据、指令遵循和量化格式都会影响结果。量化应该被看作精度与资源间的工程权衡：对摘要和闲聊，轻微退化可能可接受；对代码生成、结构化抽取或安全建议，应建立更严格的质量测试。记录每个候选模型的版本或哈希、提示词、解码参数和测试样例，避免把模型升级造成的变化误认为硬件差异。

从单机实验到服务化

服务部署需要考虑请求队列、并发数、超时、取消、流式响应和模型加载。提高并发可能增加吞吐，也会扩大 KV cache 消耗并拉高尾延迟；无限制接收请求会让服务被突发流量拖垮。把推理服务放在专用网络，前面加身份验证和速率限制；模型 API 不应直接暴露在公网。健康检查要区分进程已启动、模型已加载和实际推理成功。对于大模型加载较慢的场景，应避免探针频繁重启进程，明确预热与就绪状态。

测量要覆盖真实体验

至少记录首 token 延迟、生成速度、请求总时长、错误率、队列长度、显存占用和请求取消数，并按输入长度、输出长度和并发分组。用接近真实的长短输入混合测试，不要只用一个固定提示词。比较模型时固定提示词、采样参数和硬件环境，分开评估准确性与速度。压测必须设上限并观察系统温度、功耗与显存碎片；实验性负载不要与重要家庭服务争抢资源。给每次测试保存模型版本和配置，才能复现“这次为什么更快”。

安全、隐私和成本

本地推理减少把提示词发送到外部服务的需求，但不会自动让数据安全：应用日志、缓存、访问控制、备份和管理员权限仍可能暴露内容。模型权重来源与许可证也要核查，尤其是商业或再分发场景。若使用外部 API，先分类数据并确认服务数据处理条款、保留策略和区域要求。对家庭环境而言，电费、噪音、散热、设备折旧和维护时间都是成本；成本最低的方案可能是混合使用本地小模型和按需调用的托管模型。

参考架构

落地顺序

先选一个用途明确的模型，在目标设备测质量和延迟；再逐步启用量化、并发和长上下文，每次只改变一项；之后增加队列、限流、监控和重启策略；最后演练模型升级、磁盘不足和服务不可达。参考 Ollama 与 vLLM 官方文档的当前模型和并行能力说明，具体参数会随版本、后端和硬件变化，应以所部署版本文档为准。 Ollama 文档 · vLLM 并行服务说明

深入实践：容量规划和服务目标

部署时先建立实际工作负载矩阵：短提示与长提示、短输出与长输出、单用户与多用户、常见任务与困难任务。记录每种场景的质量、首 token 延迟、持续生成速度、峰值显存和错误率。模型升级、量化方式改变或运行时更换后，用同一矩阵回归。若显存接近上限，优先分析上下文和并发的组合，而不是只尝试更激进的量化。为服务设最大请求长度、并发和排队时间，过载时明确返回繁忙提示，避免客户端无限等待造成级联失败。

容量规划案例：把模型尺寸换算成服务约束

以一台单卡工作站为例，部署前先看模型文件在目标精度下的实际大小，再为运行时、加速器工作区、KV cache 和系统桌面留出内存。仅仅能把权重加载进显存不代表还有空间处理上下文。若希望同时接收多个会话，应按最长上下文估算最坏情况，并在压测时监控峰值而不是空闲时占用。将最大输入 token、生成长度和并发上限写进服务配置，遇到内存压力返回明确的限流结果，避免进程被系统 OOM killer 终止。模型升级时保留旧版权重，确认新版本能启动并通过质量测试后再释放空间。

如何读懂性能数字

首 token 延迟主要包含排队、输入预填充和调度开销；每秒生成速度反映解码阶段，但对用户而言还要看完成时间和流式输出是否稳定。批处理可以提高单位时间吞吐，却可能让单个交互请求等待更久。不同模型在同一量化等级下不一定有相同精度，量化格式也可能影响 GPU 算子是否可用。测试应固定硬件电源模式、运行时版本和提示词，至少运行多轮，并报告中位数与高分位数。不要用一个短提示和一个短答案推断长文档处理能力；应加入真实长度、中文输入、代码块和异常请求。

服务化的故障边界

在家中部署时，将推理节点放在服务器 VLAN，入口由网关做认证、限速和日志关联。模型服务本身应限制监听地址，避免管理 API 暴露在公网。模型进程崩溃后自动拉起只是第一层恢复，还要确认模型文件未损坏、存储仍可读、显卡驱动正常且服务探针不会在加载时误判失败。长期运行要观察温度、风扇、功耗和散热，防止夜间批量任务产生降频或影响其他设备。若推理不是核心服务，可以设置维护窗口、并发上限和快速停止机制，保证 NAS 备份、路由转发等基础工作优先。