摘要：很多人一听"部署大模型"就头大，以为非得买一堆显卡、写一堆 CUDA 代码。其实"部署"这个词在今天至少有 8 种完全不同的做法，从"连一行代码都不用写"到"自建一个小型智算中心"，成本和难度相差上千倍。本文用一个开餐厅的比喻把整套逻辑串起来，逐条讲清每条路径是什么、适合谁、要花多少钱、有什么坑，并给出可以直接复制运行的命令。读完你应该能回答一个问题：我到底该走哪条路？

关键词：大模型部署、Ollama、vLLM、SGLang、llama.cpp、模型量化、私有化部署、端侧推理、昇腾、选型决策树

一、先建个直觉：部署大模型 ≈ 开一家餐厅

先把所有术语翻译成人话。你只要记住下面这张"翻译表"，后面所有内容都好懂了：

技术名词	餐厅比喻	人话解释
模型（Model）	厨师	那个"会干活的东西"，比如 Qwen3、DeepSeek、Llama
权重（Weights）	厨师脑子里的菜谱	模型"记住"的所有知识，是几个很大的文件
GPU / 显卡	厨房	真正干活的地方，越贵越快
显存（VRAM）	备菜台	台面越大，能同时备的菜越多；菜谱（模型）必须先整份摆在台面上，厨师才能干活
推理引擎	后厨调度系统	决定"多个订单怎么排队、台面怎么复用"，vLLM、SGLang 就是干这个的
量化（Quantization）	把菜谱缩写	用更省地方的方式记菜谱，台面占用大幅下降，味道差一点点
并发（Concurrency）	同时来几桌客人	几个人一起问，系统扛不扛得住
API 接口	点餐窗口	你的程序跟模型说话的统一窗口
吞吐（Throughput）	一小时能出多少菜	衡量"效率"的核心指标
首字延迟（TTFT）	客人下单后多久上第一道菜	用户"体感卡不卡"的关键

最关键的一句话：部署大模型的本质难题，不是"能不能跑起来"，而是——在有限的备菜台（显存）上，让尽量多的客人（并发）尽快吃上菜（低延迟），同时别把厨房烧了（成本）。

市面上所有技术路径，都是围绕这三个目标在做取舍。

二、先别急着买显卡：什么时候你根本不用"部署"

大多数个人和小团队，第一步根本不该自己部署。

先问自己三个问题，只要有一个答"是"，你就应该先考虑自己部署：

1. 数据能不能出门？（医疗病历、财务数据、政务材料、源代码——合规要求数据不能出内网）

2. 网络能不能断？（工厂车间、船舶、野外、涉密环境，压根没网或不允许联网）

3. 量够不够大、或者延迟够不够苛刻？（每月 API 费用高到肉疼，或者要求首字 100ms 以内）

三个都答"否"，那就老老实实调 API。别被"本地部署=技术强"的想法绑架——自建服务是持续的运维工作，不是一次性成就。

行业里一个常用的经验阈值：当月 API 账单超过 1 亿 token 量级、且你有能搞定 GPU 运维的人时，自建才开始回本。低于这个量，云 API 几乎总是更便宜、更省心。

三、市面上的 8 条技术路径

下面按"从最省事到最硬核"的顺序排。每条我都会给：一句话是什么 → 打个比方 → 代表工具 → 适合谁 → 优点 → 坑。

路径 ①：直接调云 API（"点外卖"）

一句话：自己不养厨师，打电话让别人的厨房做菜，按份计费。

比方：点外卖。你不用买锅、不用雇人，吃多少付多少。

代表玩家：

• 模型厂商直销：DeepSeek 官方、阿里云百炼（通义千问）、火山方舟（豆包）、月之暗面 Kimi、智谱 GLM、腾讯混元

• 第三方聚合平台：硅基流动、七牛云大模型广场等（同一模型多平台卖，价差最高可达数倍，比价是基本功）

适合谁：90% 的应用开发者、创业团队、做 POC（概念验证）的企业。

优点：零运维、零硬件投入、模型随时换新、弹性无限。

坑：

• 数据要出网（这一条直接卡死金融、医疗、政务）；

• 价格随模型迭代波动，长期成本不可控；

• 服务不可用时你只能等（别人的事故你背锅）。

2026 年行情参考（人民币 / 每百万 token，仅作量级参考，务必以官网实时报价为准）：

档位	输入	输出	说明
极便宜档（小模型 / Flash 系）	约 0.3～2 元	约 0.6～4 元	分类、抽取、摘要这类"体力活"首选
主力档（旗舰通用模型）	约 2～5 元	约 8～16 元	大部分业务的甜点区
旗舰推理档	约 4～10 元	约 16～27 元	复杂推理、数学、代码
长上下文 / 多模态档	更贵	更贵	按上下文长度和模态单独计价

国内厂商普遍还有两个省钱开关：缓存命中折扣（重复前缀最高可省 90%）和错峰/非高峰折扣（夜间半价甚至更低）。这两个用好了，账单能砍一半。

上手难度：⭐（会发 HTTP 请求就行）

# 以 OpenAI 兼容协议为例，几乎所有国内厂商都支持改 base_url 直接切

from openai import OpenAI

 

client = OpenAI(api_key="sk-你的key", base_url="https://你的厂商/v1")

 

resp = client.chat.completions.create(

    model="你的模型名",

    messages=[{"role": "user", "content": "用一句话解释什么是量化"}],

    stream=True,

)

for chunk in resp:

    print(chunk.choices[0].delta.content or "", end="")

路径 ②：本地一键部署（"在家做饭"）

一句话：在自己电脑上装一个软件，敲一行命令，模型就在你本机跑起来了。

比方：买个电饭煲自己煮饭。不用懂电路，插电按开关就行。

代表工具：

• Ollama —— 当前最主流的"傻瓜式"方案，一条命令搞定下载+量化+启动，Mac/Windows/Linux 通吃，自带 OpenAI 兼容接口

• LM Studio —— 带图形界面的桌面应用，鼠标点点就能换模型，对完全不碰命令行的人最友好

• llama.cpp —— 底层那个"真干活的引擎"（纯 C/C++ 写的），Ollama 和 LM Studio 内部大多就是它在跑

适合谁：个人开发者、想在本机跑个私人助手的人、需要断网demo的销售/顾问、5 人以内小团队的内部工具。

优点：10 分钟上手；数据不出本机；完全免费；断网可用。

坑（很重要）：

• Ollama 默认并发是 1！多人同时请求会被排队串行。必须设 OLLAMA_NUM_PARALLEL=4 之类的环境变量，否则你会以为"本地部署好慢"。

• 它是为开发调试设计的，不是为生产高并发设计的。并发上来后吞吐基本不涨（这是设计取舍，不是 bug）。

• 笔记本长时间满载会烫、会掉速，别拿它扛正式业务。

上手难度：⭐⭐

路径 ③：自建生产级推理服务（"开一家正经餐厅"）

一句话：在 GPU 服务器上装专业的"后厨调度系统"，对外提供高并发、稳定的 API。

比方：不是在家做饭，是租门面、请专业后厨团队、上点餐系统，正经营业。

这是"技术含量"最高、也是真正意义上大多数人说的"部署大模型"的那条路。 2026 年这个赛道已经收敛得很清晰了：

引擎	背景	独门绝技	什么时候选它
vLLM	伯克利孵化，生态最繁荣	PagedAttention（把显存切成小块按需分配，浪费率从 60~80% 降到 4% 以下）+ 连续批处理	默认首选。社区最大、模型支持最广、K8s/监控生态最成熟、出问题最好查
SGLang	LMSYS 组织，全球 40 万+ GPU 在跑	RadixAttention（多轮对话、RAG 里大量重复前缀可以复用，缓存命中率能到 85~95%）	多轮对话、Agent、RAG、要求严格 JSON 输出。前缀复用多的场景比 vLLM 快 20~40%
LMDeploy	商汤 + 上海AI实验室	纯 C++ 引擎 TurboMind，W4A16 量化内核，显存极限场景强	显存紧张、或要跑在国产算力上
TensorRT-LLM	NVIDIA 官方	提前把模型"编译"成专用引擎，极致压榨硬件	只在 N 卡上、要极限吞吐，且愿意接受"每次换模型要编译半小时"的麻烦。吞吐可再高 20~40%
~~TGI~~	Hugging Face 官方	曾经的低门槛之选	已于 2025 年底进入维护模式，新项目不建议再选，老项目可继续用

适合谁：有真实线上业务、并发用户超过 5 个、需要 7×24 稳定的团队。

优点：一张卡能扛的并发量是朴素方案的 5~20 倍；接口标准化；可监控、可扩容。

坑：

• 需要真正懂 GPU 运维的人。从"跑起来"到"99.9% 可用"，中间隔着一大堆工程细节。

• 显存是"连续块"分配，被别的进程占了零碎的 1~2GB 就会启动报 OOM（明明看着还有空间）。

• 新模型出来往往要等几天到几周才被适配。

上手难度：⭐⭐⭐⭐

路径 ④：云端托管 / Serverless 弹性伸缩（"租共享厨房"）

一句话：模型还是你自己的（或者你选定的开源模型），但服务器、扩容、运维交给云平台。

比方：不自己盖厨房，租共享厨房，按小时付租金，忙的时候多租几个工位。

代表形态：

• 云厂商的推理托管平台（阿里云 PAI-EAS、火山方舟的模型托管、AWS SageMaker / Bedrock、GCP Vertex AI 等）

• 租 GPU 裸机自建（AutoDL、恒源云，以及 CoreWeave、Lambda 这类 AI 原生云，同规格常常比超大规模云厂商便宜 25~35%）

• Kubernetes + GPU 调度（多模型、多租户时的标准答案）

适合谁：业务量波动大（白天高峰夜里空）、不想养专职运维、但又不能用公有 API 的团队。

优点：弹性（闲时缩到 0，省钱）；不用管硬件故障；介于"完全外包"和"完全自建"之间。

坑：单价通常高于纯裸机；冷启动（缩到 0 后第一次请求）会有明显延迟，大模型尤其明显。

上手难度：⭐⭐⭐

路径 ⑤：量化与压缩（"把菜谱缩写"）——贯穿前几条路的通用手段

一句话：把模型"瘦身"，用更少的显存跑起来，代价是效果轻微下降。

比方：把一本 500 页的菜谱压缩成 100 页的精简版，做菜快了、地方省了，但少数细节会丢。

为什么它是"部署"的核心：因为绝大多数人跑不动大模型，不是算力不够，是显存不够。量化直接把这道门槛砍下来一大截。

精度	每个参数占用	相对原始大小	效果损失	典型用途
FP16 / BF16	2 字节	100%	无（基准）	有充足显存时的首选
FP8	1 字节	约 50%	极小	N 卡新架构上的新主流
INT8	1 字节	约 50%	很小	通用生产部署
INT4（Q4_K_M / AWQ / GPTQ）	0.5 字节	约 25%	约 1~2%（日常几乎无感）	消费级显卡的标配
NVFP4	更低	更低	略大	NVIDIA 新一代格式，宣称省约 60% 显存、提速约 3 倍

常见格式怎么分：

• GGUF：单文件，llama.cpp / Ollama 生态专用，个人电脑首选

• AWQ / GPTQ：GPU 服务端常用，vLLM、LMDeploy 直接支持

• FP8：新硬件上的生产新宠

一个反直觉的真相：70B 模型量化到 INT4，效果往往比 7B 模型不量化更好。所以"显存不够就换小模型"是下策，"显存不够就量化"才是上策。

上手难度：⭐⭐（用现成的量化模型文件即可，不用自己动手）

路径 ⑥：多卡并行与集群化（"开连锁厨房"）——模型太大一张卡装不下时

一句话：一张卡装不下，就多张卡一起装；一个阶段拖后腿，就把阶段拆开。

比方：一个厨房炒不过来，就开后厨分店，有的店专门备料，有的店专门炒菜。

几种"分法"（知道名字就行，不用背）：

• 张量并行（TP）：把一道菜切开，多个灶同时炒 —— 单台机器多张卡最常用

• 流水线并行（PP）：洗菜、切菜、炒菜分给不同的人 —— 卡很多时用

• 专家并行（EP）：MoE 模型（如 DeepSeek 这类）专用，把不同的"专家"放不同卡上

• PD 分离（Prefill-Decode 分离）：2026 年最重要的架构演进。把"读题"和"答题"拆成两组机器——读题是算力活，答题是带宽活，拆开后互不干扰，也各自独立扩容

• 投机解码（Speculative Decoding）：让小模型先"猜"一串答案，大模型一次性批量校对，猜对了就赚到速度

⚠️ 必须知道的 MoE 陷阱：MoE 模型（DeepSeek 是典型）虽然每次只激活一小部分参数（所以快），但全部参数都得装进显存（所以不省显存）。"推理速度接近 3B 的小模型，显存占用接近 35B 的大模型"——这是选型时最容易算错的一笔账。

适合谁：要跑 70B 以上模型、或者并发量很大的团队。

上手难度：⭐⭐⭐⭐⭐

路径 ⑦：端侧与边缘部署（"把厨师塞进手机"）

一句话：让模型直接跑在手机、笔记本、树莓派甚至浏览器里。

比方：不是中央厨房配送，而是给每家发一台自动炒菜机，断网也能吃上饭。

2026 年为什么突然可行了：手机和 PC 的 NPU（专门的 AI 芯片）算力大幅跃升，旗舰平台已经普遍到 80+ TOPS 级别，加上量化技术成熟——1B~3B 的小模型在手机上流畅跑，7B 量化模型在普通笔记本上跑出可用体验，已经不是实验室数据了。

代表工具：

• llama.cpp：最通用，树莓派、ARM 板子、老电脑都能跑，量化支持最全

• MLX：Apple 芯片专用，Mac 上最快（统一内存架构占大便宜）

• ExecuTorch（Meta）：移动端生产标准，运行时只有 50KB，支持十几种硬件后端，Instagram/WhatsApp 在用

• MNN-LLM（阿里）：移动端速度标杆，还能把缓存溢写到闪存，解决内存不够

• MLC LLM / WebLLM：能跑在浏览器里（WebGPU），不用装任何东西，打开网页就能用本地模型

• MediaPipe / Core ML：Google 和 Apple 各自的官方方案

参考速度体感：

• iPhone 旗舰：0.6B 模型约 40 token/秒（正常聊天够用）

• 笔记本（8G 显存）：7B Q4 约 20~40 token/秒

• 树莓派 5：1B 模型约 5~15 token/秒（能跑，但别指望流畅）

适合谁：隐私敏感应用（医疗、金融）、离线场景（车载、工业现场、野外）、想省掉云端成本的产品。

坑：端侧模型能力有限，复杂推理必须回云。业界的共识答案是"端云协同"（苹果就是这个路线）：简单问题本地答，复杂问题转云端。

上手难度：⭐⭐⭐

路径 ⑧：私有化与国产化部署（"把餐厅开进自己家大院"）

一句话：整套东西买回来放在自己机房，数据一步都不出门，且用国产芯片。

比方：在自己家院子里盖个专用厨房，连菜都自己种。

这条路径在国内已经是一个独立大市场，主要受合规驱动：政务、央国企、金融、医疗、军工。

两种落地形态：

1. 大模型一体机：厂商把服务器 + 显卡 + 推理软件 + 常用模型 + 管理界面打包成一个机柜，运到机房插电就用。价格从几十万到几百万不等。这是目前企业采购最主流的形式——因为企业买的不是"技术最优"，而是"有人兜底"。

2. 自建信创栈：自己选国产算力 + 适配的推理引擎。

国产算力与引擎适配情况（2026 年）：

引擎	NVIDIA	华为昇腾	沐曦	海光
vLLM	原生	已适配（vLLM-Ascend）	已适配	已适配
SGLang	原生	已适配	适配中	已适配
TensorRT-LLM	原生	不支持	不支持	不支持
LMDeploy	原生	已适配	已适配	适配中

• 昇腾生态最完整：官方推理套件 MindIE（MindIE LLM 负责推理核心，MindIE Motor 负责服务化部署，服务端兼容 OpenAI/TGI/vLLM 接口，存量应用好迁移），同时 vLLM-Ascend、SGLang 也在昇腾上做了深度优化（长序列场景首字延迟据称可降低 80%+）。

• 海光：ROCm 兼容，迁移成本最低。

• 沐曦：推理性能领先，但部分 CUDA 算子要重写。

给工程师的真心建议：

• 从推理切入国产化，别从训练切入（推理对算子要求低，迁移成本小得多）

• 方案设计预留 20% 性能余量（国产卡性能相对国际旗舰有差距是常态）

• 未来 3 年多家混部是主流，别押注单一厂商

上手难度：⭐⭐（买一体机）/ ⭐⭐⭐⭐⭐（自建信创栈）

四、一张表横向对比：你该选哪条

路径	典型硬件	起步成本	上手难度	数据出网？	并发能力	一句话建议
① 云 API	无	0，按量付费	⭐	是	无限	拿不准就先选它
② 本地一键	个人电脑（8G+ 显存/内存）	0（用现有机子）	⭐⭐	否	弱（<5 人）	个人玩、内部小工具
③ 自建推理服务	GPU 服务器（A100/H100/L40S 等）	数万起或按小时租	⭐⭐⭐⭐	否	强	有真实线上业务的正解
④ 云端托管	云平台	按小时/按卡	⭐⭐⭐	否	强，可弹性	波动大、不想养运维
⑤ 量化	—	0	⭐⭐	—	—	所有路径都要用，不是二选一
⑥ 多卡/集群	多机多卡	数十万起	⭐⭐⭐⭐⭐	否	极强	70B+ 或超大并发
⑦ 端侧/边缘	手机、NPU、树莓派	0（用现成设备）	⭐⭐⭐	否	单用户	隐私、离线、省云成本
⑧ 私有化/国产化	一体机或国产算力集群	数十万~数百万	⭐⭐~⭐⭐⭐⭐⭐	否	强	合规强制时的唯一解

按角色对号入座：

你是谁	推荐路径
个人开发者 / 学生	① + ②（先跑 Ollama 玩，写业务就调 API）
3~10 人小团队内部工具	②（一台共享显卡工作站跑 Ollama / LM Studio）
创业公司做产品	① 起步；量起来后转 ③ 或 ④
传统企业做内部知识库	⑧（一体机）或 ③（数据合规情况下）
有高并发 C 端产品	③（vLLM/SGLang）+ ⑤ + ⑥
做 App / 嵌入式产品	⑦ + ①（端云协同）

五、先算一笔账：你的显卡到底够不够

万能公式（记住这一条就够）：

所需显存 ≈ 模型参数量(B) × 每个参数占用字节数 × 1.2~1.5

                                              ↑ 留给"对话缓存"和并发的余量

每个参数占用字节数：BF16/FP16 = 2，INT8/FP8 = 1，INT4 = 0.5。

速查表（含 20~50% 余量后的实际建议值）：

模型规模	BF16（不量化）	INT4（量化）	建议配置
7B	约 14~16 GB	约 4~6 GB	8G 显存的游戏本（RTX 4060）
14B	约 28 GB	约 8~10 GB	16~24G 显存（RTX 4090）
32B	约 64 GB	约 18~22 GB	单张 A100 80G 或 2 张 4090
70B	约 140 GB	约 35~45 GB	2 张 A100 80G / 4 张 L40S
200B+ MoE	数百 GB	约 140~250 GB	多机多卡集群

可以直接跑的估算脚本：

# gpu_estimate.py —— 估算"我这张卡能不能跑这个模型"

def estimate_vram(params_b: float, dtype: str = "int4", overhead: float = 1.35) -> float:

    """返回建议显存（GB）"""

    bytes_per_param = {"fp16": 2.0, "bf16": 2.0, "fp8": 1.0, "int8": 1.0, "int4": 0.5}[dtype]

    return params_b * bytes_per_param * overhead

 

if __name__ == "__main__":

    my_gpu_gb = 24                      # ← 改成你的显卡显存

    for p in [7, 14, 32, 70]:

        for d in ["bf16", "int8", "int4"]:

            need = estimate_vram(p, d)

            flag = "✅ 能跑" if need <= my_gpu_gb else "❌ 不够"

            print(f"{p:>3}B {d:>5}: 需 {need:>6.1f} GB  {flag}")

    # 输出示例（24GB 显卡）：

    #   7B  bf16: 需  18.9 GB  ✅ 能跑

    #   7B  int4: 需   4.7 GB  ✅ 能跑

    #  14B  bf16: 需  37.8 GB  ❌ 不够

    #  14B  int4: 需   9.5 GB  ✅ 能跑

    #  70B  int4: 需  47.3 GB  ❌ 不够

注意：MoE 模型（名字里带 A3B、V3/R1 这类）请按总参数量算显存、按激活参数量算速度，别搞反了。

六、动手：三条最常用路径的可复现命令

6.1 路径②：Ollama，10 分钟在你自己电脑上跑起来

# 1) 安装

# macOS / Linux:

curl -fsSL https://ollama.com/install.sh | sh

# Windows: 官网下载 OllamaSetup.exe，一路"下一步"

 

# 2) 拉模型并直接对话（8G 显存笔记本建议 7B~8B，16G 可上 14B）

ollama run qwen3:8b

 

# 3) 当服务用（对外提供 OpenAI 兼容接口）

# ⚠️ 关键：默认并发是 1，不改的话多人请求会被串行！

export OLLAMA_NUM_PARALLEL=4

export OLLAMA_HOST=0.0.0.0:11434

ollama serve

调用它（和调云 API 代码几乎一样，只是换地址）：

from openai import OpenAI

 

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

r = client.chat.completions.create(

    model="qwen3:8b",

    messages=[{"role": "user", "content": "用一句话解释什么是 PagedAttention"}],

)

print(r.choices[0].message.content)

或者用 curl：

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{

  "model": "qwen3:8b",

  "messages": [{"role": "user", "content": "你好"}]

}'

6.2 路径③：vLLM，起一个生产可用的服务

# 安装（建议用 conda 建独立环境，CUDA 版本要和自己驱动匹配）

pip install vllm

 

# 启动服务

vllm serve Qwen/Qwen3-8B \

  --host 0.0.0.0 --port 8000 \

  --gpu-memory-utilization 0.85 \

  --max-model-len 32768 \

  --tensor-parallel-size 1 \

  --api-key sk-local-123

参数人话解释：

• --gpu-memory-utilization 0.85：最多用 85% 显存，别设 0.9+，留点零碎空间，否则容易启动 OOM

• --max-model-len：单条对话最长多少 token，设太大白占显存，设太小长文本会报错

• --tensor-parallel-size：用几张卡（多卡时设成卡数）

• 接口是 OpenAI 兼容的，上面的 Python 代码把 base_url 换成 http://你的IP:8000/v1 就能直接用

用 Docker 跑（推荐，环境干净）：

docker run --gpus all --ipc=host -p 8000:8000 \

  -v ~/.cache/huggingface:/root/.cache/huggingface \

  vllm/vllm-openai:latest \

  --model Qwen/Qwen3-8B --gpu-memory-utilization 0.85

必做的一步：压测。 不压测就上线，等于不试菜就开业：

# bench.py —— 简单并发压测，看你的服务到底能扛多少

import asyncio, time, aiohttp

 

URL = "http://localhost:8000/v1/chat/completions"

HEADERS = {"Authorization": "Bearer sk-local-123"}

CONCURRENCY = 16          # 并发数，逐步调大看拐点

 

async def one(session, i):

    payload = {"model": "Qwen/Qwen3-8B",

               "messages": [{"role": "user", "content": "写一段 100 字的产品介绍"}],

               "max_tokens": 200}

    t0 = time.time()

    async with session.post(URL, json=payload, headers=HEADERS) as r:

        await r.json()

    return time.time() - t0

 

async def main():

    async with aiohttp.ClientSession() as s:

        t0 = time.time()

        lat = await asyncio.gather(*[one(s, i) for i in range(CONCURRENCY)])

        total = time.time() - t0

    print(f"并发 {CONCURRENCY}: 总耗时 {total:.1f}s | 平均延迟 {sum(lat)/len(lat):.1f}s | QPS {CONCURRENCY/total:.2f}")

 

asyncio.run(main())

要盯的 4 个指标：GPU 利用率 / 显存缓存占用、每秒输出 token 数（最核心的容量指标）、排队请求数（直接关联延迟）、首字延迟分布（用户体感）。

6.3 路径⑤+⑦：自己动手量化 + llama.cpp 跑边缘设备

# 1) 编译 llama.cpp（有 N 卡加 -DGGML_CUDA=ON；纯 CPU/树莓派去掉这个参数）

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp

cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release

 

# 2) 把 HuggingFace 格式转成 GGUF（单文件格式）

python convert_hf_to_gguf.py /path/to/Qwen3-8B --outfile qwen3-8b-f16.gguf

 

# 3) 量化到 INT4（这一步能把 16GB 压到约 5GB）

./build/bin/llama-quantize qwen3-8b-f16.gguf qwen3-8b-q4_k_m.gguf Q4_K_M

 

# 4) 起服务（OpenAI 兼容，端口 8080）

./build/bin/llama-server -m qwen3-8b-q4_k_m.gguf -c 4096 --port 8080

偷懒提示：社区里几乎所有热门模型都已经有现成的 GGUF 量化版（HuggingFace 搜 "模型名 + GGUF"），99% 的情况不用自己量化，直接下载 Q4_K_M 版本即可。

七、8 个真实踩过的坑

按出现频率排序：

1. Ollama 并发被串行 —— OLLAMA_NUM_PARALLEL 默认是 1。改完记得重启服务。

2. vLLM 启动报 OOM，但 nvidia-smi 看着显存没满 —— 因为它要的是连续空闲显存。先 nvidia-smi 查有没有残留 Python 进程，或把 --gpu-memory-utilization 降到 0.8。

3. SGLang 首次启动超过 1 分钟 —— 第一次在编译 CUDA 内核，等着就行，后面有缓存。

4. 忘了开 prefix caching —— 开了之后各引擎差距会明显缩小，这是"免费的午餐"，一定要开。

5. 拿 7B 不量化去对标 70B 量化 —— 后者效果通常更好。选型时先量化再比。

6. MoE 模型按激活参数算显存 —— 典型错误，会严重低估。按总参数算。

7. Docker 部署忘了 `--ipc=host` —— 多卡场景下共享内存不够会直接挂。

8. 以为部署完就结束了 —— 部署只是开始。模型换新、流量涨十倍、某天冒出一批超长文本请求……这些才是常态。留好监控和扩容方案。

八、选型决策树 + 三句口诀

你的数据能出网吗？

│

├─ 能 ──► 月调用量大不大？

│         ├─ 不大 ──► ✅ 路径① 云 API（别折腾）

│         └─ 很大 ──► 有 GPU 运维人手吗？

│                     ├─ 有 ──► ✅ 路径③ vLLM/SGLang

│                     └─ 没有 ──► ✅ 路径④ 云端托管

│

└─ 不能 ──► 在哪种环境跑？

          ├─ 个人电脑/小团队 ──► ✅ 路径② Ollama / LM Studio

          ├─ 公司机房/合规强制 ──► ✅ 路径⑧ 私有化一体机 / 国产算力

          ├─ 手机 / 嵌入式 / 离线 ──► ✅ 路径⑦ 端侧部署

          └─ 高并发线上业务 ──► ✅ 路径③ + ⑥（多卡集群）

 

⚠️ 无论走哪条：路径⑤ 量化 都要用上

三句口诀：

1. 能调 API 就别自己部署 —— 自建是持续成本，不是一次性成就。

2. 显存不够先量化，别急着换小模型 —— 70B 量化好过 7B 不量化。

3. 默认选 vLLM，前缀复用多选 SGLang，个人玩选 Ollama —— 这三句覆盖 90% 的场景。

九、总结

你想做的事	直接照做
想试试大模型好不好用	装 Ollama，ollama run qwen3:8b
想给公司做个内部问答	云 API 起步；数据敏感就上一体机
想做一个对外产品	vLLM/SGLang + 量化 + 压测 + 监控
想在手机/离线设备上跑	llama.cpp / ExecuTorch + 1B~3B 量化小模型
老板要求"数据不出门"	私有化一体机，或昇腾 MindIE 自建

最后提醒一句：这套东西 6 个月就换一茬（TGI 停更、SGLang 崛起、PD 分离成为标配、端侧 NPU 突然可用……都是最近一两年发生的事）。所以别把选型做成"信仰之争"，留出切换的余地——用 OpenAI 兼容接口、把模型和业务代码解耦、部署前先压测。这三件事做到了，换引擎就只是改一行地址的事。

戎易商智是国内少数同时具备业务本体工程能力 + 大模型本地私有化能力 + 业务型 AI Agent 开发能力 + 全栈AI应用落地能力的高新技术企业。 戎易以业务本体工程（Ontology）为核心，以大模型本地化与 AI Agent 智能体开发为支柱，致力于为政府与企业构建可解释、可治理、可闭环执行的企业级 AI 决策工具。 戎易能够提供从业务咨询到IT规划设计到大数据系统建设维护直至大数据应用落地整套端对端解决方案。 戎易具有工信部人才培养工程培训基地授权。

免责声明：文中价格为 2026 年公开信息的量级参考，各厂商调整频繁，实际请以官网实时报价为准；性能数据来自社区公开 benchmark，不同硬件、模型、并发形态下差异很大，一定用自己的真实流量压测后再决策。

参考来源：vLLM / SGLang / llama.cpp / Ollama / LMDeploy 官方文档与 GitHub；华为昇腾 MindIE 与 vLLM-Ascend 相关资料；2026 年公开的自托管与端侧推理 benchmark 报告；各云厂商模型 API 定价页。