本地托管大语言模型实录
我觉得时机成熟了——从 2026 年起,本文全新升级为记录大语言模型技术演进和普惠化的“活文章”。我的探索自 2025 年起步,彼时 Deepseek 刚刚揭开大语言模型普惠化的序幕,掀起本地部署大模型的热潮;此后新技术、新理论层出不穷,部署、推理成本指数级下降;结果是,无偿体验大模型能力的平台如雨后春笋般涌现,包括但不限于:
尽管如此,出于隐私考虑,我仍希冀于借助手头上的笔记本、台式机等计算资源来托管大模型,尤其是专精翻译的模型,于是有了这些小文章的合集。下面按时间倒序,讲讲我亲身体验的模型罢,分别为:
- 混元翻译模型 1.5 系列
HY-MT1.5,由笔记本和桌面 GPU 装载 - 通义千问 3.0 系列
Qwen3:稠密版 8B 和混合专家架构(MoE)版 30B-A3B,由笔记本装载 - 早期通用稠密模型,含 Gemma-X2、GLM-4、Qwen 2.5,由笔记本装载
推理框架以 LLaMA.cpp 为主——开销最小,性能最佳,支持深度量化,支持跨平台、多种硬件加速推理,目前仍在快速迭代。
标准测试流程
- 拉取 LLaMA.cpp 最新一个提交并编译。如果涉及到 NVIDIA GPU,改为下载已预先编译的二进制程序。
- 自“魔搭社区”拉取目标模型,格式最好是已预先制作的 GGUF。如未提供 GGUF 格式,下载后用 LLaMA.cpp 附带 Python 工具转换格式,再量化为 INT8(由于内存容量有限,此操作仅限于 7B 以下参数量)。
- 在内存和 VRAM 允许的前提下,用
llama-server加载并托管模型。一般用处理器推理;对于小参数模型,尽量引入 GPU 推理;对于混合专家架构(MoE),如有可能则下放一部分张量层到 VRAM。理论上llama-cli更节约资源,但命令行里跟 AI 互动有那么点别扭(我是未来主义者)……
混元翻译模型 1.5 系列(2026 年一月)
这才是我梦寐以求的、足以取代 Pot 和一切在线翻译接口的好模型。 去年末刚刚开源的腾讯混元翻译模型 HY-MT1.5 版本,分 7B 和 1.8B 两个权重,还提供了 GGUF 格式以便 LLaMA.cpp 直接部署——正中下怀!
经实测,笔记本在纯处理器运算的情况下,可托管 1.8B 模型,推理速度在每秒 13~27 字词之间不等;台式机的 CMP 40HX GPU 可托管经量化的 7B 模型。我一开始担心 40HX 在缺少张量单元的情况下,推理可能会出问题(指 BF16 和整数运算),但其表现十分出色,推理速度 26~32 字词每秒;排除保留空间后,剩余 VRAM 只能支持约 20,000 字词的上下文空间,有可能制约对超长段落的翻译性能。(难道引进 V100 的时机到了?)
模型号称支持 30 余种语言的互译。测试了英语、德语、俄语和日语四段语料,译文基本通顺,准确率也很高(相对于我自己的理解而言)。不妨去看看混元开发者的技术报告,有更专业的对照图。
台式机上用这行命令启动 LLaMA.cpp b7772 修订版后台进程,托管 7B 模型(全量加载到 GPU),上下文空间 16,384 字词:
./llama-server.exe -m ./HY-MT1.5-7B-Q4_K_M.gguf -ngl all -c 16384 --port 8080 --check-tensors元指令(System prompt):
你现在是翻译官。请记住以下词语的翻译(原文→译文):
detransitioned→停止转变过程的
detransitioner→停止转变过程的人
detrans/desisted→停止或放弃认同跨性别身份
另请注意,翻译时你必须始终保持中立客观,不得对任何群体带入任何感情色彩或偏袒,如同以上的勘误那样。现在我每发一段话,你需如实翻译至中文,除译文外无需给出任何解释。然后喂了四段涉及跨性别权益运动的英文进去。混元基本上遵照我的指示进行了客观、中立的翻译,且质量很高。 在此前测试中,我没有指定“detransitioned”的参考译文和“中立客观”的要求,故混元先入为主地认为这是“恢复正常”之意。
下面是推理用时记录:
prompt eval time = 3282.51 ms / 436 tokens ( 7.53 ms per token, 132.83 tokens per second)
eval time = 11093.61 ms / 362 tokens ( 30.65 ms per token, 32.63 tokens per second)
total time = 14376.13 ms / 798 tokens
prompt eval time = 10964.14 ms / 1409 tokens ( 7.78 ms per token, 128.51 tokens per second)
eval time = 36610.31 ms / 1105 tokens ( 33.13 ms per token, 30.18 tokens per second)
total time = 47574.45 ms / 2514 tokens
prompt eval time = 11592.94 ms / 1345 tokens ( 8.62 ms per token, 116.02 tokens per second)
eval time = 29251.55 ms / 839 tokens ( 34.86 ms per token, 28.68 tokens per second)
total time = 40844.49 ms / 2184 tokens
prompt eval time = 21192.54 ms / 2218 tokens ( 9.55 ms per token, 104.66 tokens per second)
eval time = 62331.64 ms / 1625 tokens ( 38.36 ms per token, 26.07 tokens per second)
total time = 83524.18 ms / 3843 tokens最近这个修订版增加了内存/VRAM 分配情况,如日志的最后几行所示:
llama_memory_breakdown_print: | memory breakdown [MiB] | total free self model context compute unaccounted |
llama_memory_breakdown_print: | - CUDA0 (CMP 40HX) | 8191 = 376 + (6757 = 4403 + 2048 + 306) + 1057 |
llama_memory_breakdown_print: | - Host | 450 = 410 + 0 + 40 |- 推理时 VRAM 总用量:6757 MiB,其中
- 模型用量:4403 MiB
- 上下文键值表:2048 MiB
- 计算用量:306 MiB
- 保留 VRAM 空间:1057 MiB
- 剩余 VRAM:376 MiB
- 系统内存用量:450 MiB
通义千问 3.0 & MoE(2025 年四月/九月)
最近大模型技术迭代大大加速了,向着小型化、高效率方向发展——我对此十分赞同和欢迎。现在,一批可精细管理推理精度的量化方法浮出水面:先有微软 BitNet(选择性 1.58-bit 量化),后有 Unsloth AI 的动态量化系统 2.0 版。原来推理效率不那么高的高权重模型,量化后可以获得 2~3 倍的推理速度提升,同时推理精度的损失被控制到最小。29 日,阿里云推出了“通义千问”最新迭代的 3.0 系列,推理能力与 DeepSeek R1 媲美,但参数量仅有其三分之一。相信二者结合会有全新气象。于是又做了一次试验:
- 拉取 llama.cpp 主线最新提交,重新编译。
- 拉取“通义千问 3.0”8B 量化权重。该权重相当于前述
qwen2.5-3B的 2.67 倍。综合 Unsloth AI 对其工具链的测评结果,我认为Q2_K_XL提升效率明显、准确性牺牲较小,故从unsloth/Qwen3-8B-128K-GGUF仓库中取用权重文件Qwen3-8B-128K-UD-Q2_K_XL.gguf。
——热门大模型都会有人专门量化,并上传到 ModelScope 等平台上,这样连自行量化的工夫也省却了,这是好事。 - 跟之前一样,加载权重并在 Web app 上试验。此次“通义千问”3.0 增加了思考链能力,为提高效率,这里于中文元指令之后加入
/no_think选项以关闭思考链。 - 输入依然是前述两条英语原文。
试验结果
- 输入解析速度:每秒 6.39、6.95 字词
- 输出速度:每秒 4.22、4.23 字词
这个速度较 3B 减慢了一半,但尚可接受;翻译结果则更准确些。 - 内存缓冲区需求:3334.06 MiB
综上所述,qwen3-8B 量化版在近现代四核处理器上也有足可接受的推理速度表现,且准确性明显改善,值得推荐。
“通义千问”3.0 提供了两组基于混合专家结构(MoE)的权重:235B 和 30B,据称后者仅需激活 3B 参数即可实现相当于传统 30B 权重的推理能力,同时资源开销大幅减少。我决定试用之,遂从 unsloth/Qwen3-30B-A3B-GGUF 仓库中拉取经量化的权重文件 Qwen3-30B-A3B-UD-Q2_K_XL.gguf。
这里暂且使用默认的元指令“You are a helpful assistant”,但于其后加入 /think 或 /no_think 来控制是否启用思考链;其余条件(量化级别、llama.cpp 提交等)和后记一相同。
数学问题测试
设a,b为正实数,满足 a*b=a+b+3;求a,b的取值范围。
翻译测试
同样关闭思考链的情况下,给予前述第二条英语片段来翻译,可以见到译文质量再上一个台阶。
推理速度也非常快,与 qwen2.5-3B 相当:
- 数学问题:输入 32.33 tokens/秒,输出 10.04 tokens/秒
- 翻译:输入 22.44 tokens/秒,输出 8.43 tokens/秒
- 内存开销:理论 11261.28 MiB,实际约 1.8 GB
综上所述, qwen3-30B-A3B 是当下适合我这本子托管的最强模型。
Thinkpad 托管性能
配置见《给笔记本换代升级第二部:猴版 Thinkpad》。
- 推理框架:LLaMA.cpp 最新提交
- 模型:通义千问 3.0 七月更新版 30B MoE 权重,无思考链,深度选择性量化(
Qwen3-30B-A3B-Instruct-2507-UD-Q2_K_XL.gguf) - 推理方式:纯处理器运行,无 GPU
连续询问其三个法律方面的问题;回答都很中肯,草拟的法律文书也有模有样。因涉及隐私,这里就不贴了。
- 第一次问答:给出案件梗概,询问了被告可能判处的刑期。其推测“三到六年有期徒刑”,和实际起诉书/量刑建议所示相吻合。输入 89 字词(tokens,每秒 12.83),输出 697 字词(15.09/s)。
- 第二次问答:询问了作为被害人,出庭时除旁听以外还有何权利。回答有 6 项权利,其中一项是“提交《被害人陈述意见书》”。输入 634 字词(32.60/s),输出 1299 字词(10.83/s)。
- 第三次问答:令其按照我提供的被害经历,草拟一份《被害人陈述意见书》。输入 1683 字词(18.95/s),输出 1415 字词(7.16/s)。
早期通用稠密模型(2025 年二月)
一、起因
近期因工作需要,着手在笔记本上部署 AI 助手来帮忙翻译。开源翻译助手 Pot 最近遇到些问题:先是 DeepL 接口的默认 token 废弛,再是在整整一周时间内(两次滚动更新之间)都打不开。现在不少大语言模型都具备多语言能力,不过公共接口都有试用限制,我便考虑本地部署大模型,作为翻译小助手;要求既表意准确,推理也要足够快。 早前曾尝试在资料服务器上托管,但未果。
开始正题前,声明一下笔记本上的计算资源:
- 处理器:Core i5-10210U
- 内存:16 GB,双通道 DDR4-2666,预期带宽约 40 GB/s
- 独立 GPU:无
二、框架选项
由于缺少独立 GPU,处理器算力也有限,这里要求推理框架尽可能地轻量化。基于 Python 的各种框架:Pytorch、Transformers 等等可能太重了,不仅因为执行效率比不上 C++ 程序,也因为要连带一大堆 NVIDIA 专有框架一起安装。基于 C++ 的 llama.cpp 貌似可以接受,不仅自身开销小,也自带一个 Web app 和 OpenAI-like API 服务用来试用、托管模型。
一开始试图从 AUR 拉取,但发现依赖链庞大,拉取各种 Python 运行库很慢……转念一想,干脆拉取源码仓库来编译好了。C++ 部分仅需 cmake 即可;Python 部分虽然免于编译,但依赖链需要 pip、Pypi 仓库和特定的 Python 版本(至高 3.12.x,早于 Arch 仓库;Pytorch 尚未适配 Python 3.13+)方可建立,所以需要构建一个 Python 虚拟环境。Conda?没听说过,我用基于 C++ 的软件 micromamba,Arch CN 仓库里也正好有。
Micromamba 本身没有携带任何环境,建立虚拟环境时依赖 ~/.local/share/mamba/.mambarc 的设置;需要规定镜像源,否则拉取速度很慢。 设置如下:
channels:
- defaults
default_channels:
- https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r
- https://mirrors.ustc.edu.cn/anaconda/pkgs/main
- https://mirrors.ustc.edu.cn/anaconda/pkgs/msys2
custom_channels:
bioconda: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
menpo: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
msys2: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
pytorch: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
pytorch-lts: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
simpleitk: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
always_yes: true
auto_activate_base: false这里决定构建 Python 3.12 环境。拉取 Python 包时依赖 pip 和位于 ~/.config/pip/pip.conf 的设置;pip 随环境准备完毕,设置则仅有一条简单的镜像源规则,然后拉取 Python 依赖:
[global]
index-url = https://mirrors.ustc.edu.cn/pypi/simple如此便可利用随 llama.cpp 分发的 Python 工具(convert_hf_to_gguf.py),将 Safetensors 格式编码的模型转换为可用于 llama.cpp 的 GGUF 格式。
三、在 ModelScope 物色模型
ModelScope 是大陆环境下规模最大的开源模型平台,基本上应有尽有,跟 Hugging Face 相比毫不逊色。有两种办法拉取模型文件:
- 官方提供的 Python 包
modelscope。广电宽带条件下,拉取较慢但稳定于 660 kB/s 左右;不过可自由指定一个权重文件下载,灵活性高。 - Git 拉取整个仓库。拉取速度极快,几乎充分利用了宽带下行能力。但是,它会将一整个仓库的所有权重都下载下来,比较费硬盘。
试用过程中,我会安排以下两条元指令(System prompt/message)之一:
- “I want you to act as a translator. I will speak to you in English and you will translate it and answer in Chinese. Keep the meaning same, but make them more literary. I want you to only reply the translations and nothing else, do not write explanations.” ——面向外国企业训练的模型,如 LLaMa、Gemma
- “你将扮演翻译员。我发给你一段英语材料,由你翻译为中文,译文需准确通顺。你只需回答译文,不给出任何解释。” ——面向大陆企业训练的原生中文模型,如“通义千问”
用这条命令启动 llama.cpp 服务:
./build/bin/llama-server -m qwen2.5-3b-it-Q8_0-LOT.gguf --port 8080下面试用三款模型,均为经 INT8 量化的权重:
Gemma-X2
小米翻译特训版 Gemma-2,权重分为 20 亿(2B)和 9B。在这台本子上,2B 权重比较适合。但是,它似乎不大能理解我给予的元指令:第一条正常翻译为中文,往后回答了一串拉丁字母组成的片段(我猜测是西班牙语)。无论元指令是中文还是英文,均未改变其尴尬结局。小米没有提供如何使用、调试这个模型的资料,模型还要自行转换格式。
GLM-4
智谱于 2024 年开源的模型,权重为 9B,也是我一年来梦寐以求的。成功执行了我给予的元指令,对医学材料的理解基本到位;但推理很慢,基本在每秒 2~3 字词(tokens)之间。
Qwen2.5
“通义千问”开源版,权重从 0.5B 到 72B 不等,这里选用的是 3B。尽管权重较小,但它也成功执行了元指令,对普通英语和医学材料的理解基本到位,推理速度在每秒 8~9 tokens 之间。
推理过程需要处理器满负荷运行;虽然跟性能无关,但让风扇转速增加到 6000~7000 rpm,噪音也是挺恼人的。

两段材料分别是:
综上所述,Qwen2.5-3B 是适合近代(2015~2021 年)四核处理器本地部署的大语言模型;除了翻译助手,大约还可以处理其它类别的指令,不过规模和智力所限,还是莫要勉为其难罢。
四、把计算分离到资料服务器上还可行吗?
这里要考虑到两点,即不影响裸机系统(TrueNAS CE),也不使用虚拟机;早前对 TrueNAS 底层动了太多手脚,而且一旦系统更新,这些改变是不会保留的。现在想来,比较靠谱的方案可能是:启用一个 Alpine Linux 容器,其中托管 llama.cpp 并映射端口到主机指定端口上;或者干脆采用现成的 Ollama 镜像,用容器本身的设置来自主加载指定模型。
算力始终是个大问题。我曾考虑升级服务器,将处理器至少升级到 CC150(八核,算力为这部本子的两倍);再往上,功耗和噪音将指数级增加,不符合我对资料服务器的基本要求(小且安静)。GPU 推理的话,基本没多少称心如意的二手产品可捡(Tesla P4 仅仅能下探到半精度浮点,即 BF16;T10 需额外供电;INT8 等混合精度的计算自 Ampere 一代起才支持,成本激增)。利用张量单元(NPU)计算也是大有前景的方向。
上面这些想想都烦人,还是过几年再来看罢。但愿到时更多 GPU、NPU 产品沦落街头,俯拾皆是,真正实现算力普惠。