数据不出域、API 成本可控、低延迟响应——这三个需求推动了 2026 年本地大模型部署的爆发式增长。本文从硬件选型到推理服务上线，梳理一条可落地的部署路径。
硬件规划速查表
模型大小与显存需求（推理阶段，含 KV Cache 余量）：
- 7B 模型 INT4：约 6 GB 显存，单卡 RTX 3060 可跑
- 14B 模型 INT4：约 10 GB，RTX 3080 / 4070 级别
- 32B 模型 INT4：约 20 GB，RTX 4090 或 A10
- 70B 模型 INT4：约 40 GB，需 A100 40G 或双卡
纯 CPU 推理可行但速度慢——7B Q4 模型在 64GB 内存的服务器上约 5–8 token/s，仅适合低频离线任务。
量化策略选择
量化在几乎不损失质量的前提下大幅压缩模型体积：
- GGUF Q4_K_M：llama.cpp 生态首选，质量与速度平衡最好
- AWQ / GPTQ INT4：vLLM、TGI 等 GPU 推理框架常用格式
- FP8：H100 等新一代 GPU 原生支持，精度损失极小
生产环境推荐先用 Q4_K_M 验证效果，若质量不够再升到 Q5 或 Q8，而非直接用 FP16。
推理框架对比
- llama.cpp：跨平台、支持 CPU/GPU 混合推理、GGUF 格式，适合边缘和桌面
- vLLM：PagedAttention 实现高吞吐，适合 GPU 服务器批量服务
- Ollama：开箱即用，API 兼容 OpenAI 格式，适合开发和小团队
- LocalAI：多模型多模态统一管理，支持 embedding 和 STT
# 使用 Ollama 快速启动并暴露 OpenAI 兼容 API
ollama pull qwen2.5:14b-instruct-q4_K_M
ollama serve
# API 端点：http://localhost:11434/v1/chat/completions服务化部署架构
从「命令行跑模型」到「生产 API 服务」，需要补齐：
- API 网关：统一鉴权、限流、日志（可用 Nginx + Lua 或 LiteLLM Proxy）
- 模型路由：按任务复杂度分发到不同大小的模型
- 健康检查：定期发送 probe 请求，检测模型是否 OOM 或僵死
- 自动扩缩：Kubernetes 配合 GPU Operator，按队列深度增减 Pod
模型选型建议
2026 年开源模型生态已非常成熟，按场景推荐：
- 通用对话：Qwen2.5-14B-Instruct、Llama-3.1-8B
- 代码生成：DeepSeek-Coder-V2、Qwen2.5-Coder-14B
- 中文场景：Qwen 系列在中文理解和生成上表现突出
- Embedding：bge-m3（多语言）、nomic-embed-text
监控与运维
- 记录每次推理的 token 数、延迟、GPU 利用率
- 设置 max_tokens 和 timeout 防止单请求占用过久
- 定期更新模型版本，用 benchmark 数据集验证质量不回退
- 磁盘预留足够空间——一个 14B Q4 模型约 8 GB，加上多个版本很快占满
小结
本地部署大模型的公式：合适的量化级别 + 匹配的推理框架 + 规范的服务化封装。先用 Ollama 验证效果，再用 vLLM 扛生产流量，是大多数团队最务实的路径。