模型部署与推理
本地大模型部署的取舍记录
围绕模型体积、推理速度、显存占用、量化方案和 API 封装，记录本地大模型部署的工程取舍。
背景
云端 API 适合快速验证，但在隐私、成本、离线使用和响应稳定性上会遇到限制。本地部署大模型可以提高可控性，也会带来新的工程问题：模型下载、硬件资源、推理服务、并发控制和监控。
我把本地部署看成一个分层问题，而不是一次命令行实验。模型能跑起来只是第一步，能稳定服务业务才是目标。
目标
一次可用的本地部署至少要回答这些问题：
- 模型大小是否匹配机器资源。
- 量化后质量下降是否可接受。
- 推理服务是否提供稳定 API。
- 请求超时、排队和失败如何处理。
- 后续模型替换是否影响上层业务。
技术方案
在验证阶段，可以优先选择成熟推理框架封装 HTTP 接口，把上层应用和模型运行环境隔离开。应用侧只依赖统一的 chat/completion 接口，不直接关心底层是云端模型、本地模型还是备用模型。
模型选择上，我会先用较小模型验证流程，再根据任务复杂度换更强模型。量化方案需要结合任务测试，不适合只看跑分。对于摘要、分类、简单问答，较小模型可能足够；对于复杂推理和长上下文，质量损失会更明显。
遇到的问题
本地推理最容易忽视的是并发。单用户测试时响应还可以，多请求同时进入后就会出现排队、超时和内存压力。解决方式不是盲目换模型，而是加请求队列、超时策略、缓存和降级路径。
另一个问题是上下文长度。长上下文会显著增加推理时间，真正上线时要在输入裁剪、摘要压缩和检索增强之间做组合。
结果
本地部署适合隐私敏感、成本可控、任务稳定的场景。对于求职作品集，它可以展示模型服务封装、资源评估和工程取舍；但如果目标是快速交付业务，云端 API 仍然是更稳的起点。
复盘
模型部署不是越本地越高级。工程判断应该从业务约束出发：数据能不能出网、响应时间要求多少、预算是多少、团队有没有维护推理服务的能力。把这些问题说清楚，比堆模型参数更有价值。
Reusable projects
关联可复用项目
本文已经进入以下工程项目；项目页提供固定版本、运行命令和结果工件。
- 问题背景已独立复现
本地推理容量规划工具
本文梳理本地部署在显存、速度、质量和维护上的取舍，本项目把其中速度与任务质量变成固定采集合同。
讨论