我们之前使用ollama做了一系列的性能测试，最简单的是在Windows系统中，安装好GPU驱动，然后执行测试（帮你省20块！仅需2条命令即可通过Ollama本地部署DeepSeek-R1模型）；或者是在macOS进行测试（29瓦功耗运行140亿参数模型！Mac mini M4的AI能效革命）。
经过测试，我们还对模型的量化方式有了相对深入的了解（目前来看，ollama量化过的DeepSeek模型应该就是最具性价比的选择），为后面的使用打下了良好基础。
但是，在我们上次使用手机测试的时候（手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台），发现ollama其实只是对核心组件lamma.cpp做了封装，用起来方便一些，其实性能并不是最高的。以手机测试为例，ollama运行1.5B参数模型的输出速度约为20.9 TPS，运行2B参数模型的输出速度约为11.79 TPS，运行4B参数模型的输出速度约为5.14 TPS。如果使用lamma.cpp，运行3B参数模型的输出速度为25.6 TPS，差距明显。
现在，我们还差Linux系统没有测试，虽然我们之前使用vLLM运行过（桌面显卡RTX4070部署AnythingLLM调用vLLM搭建本地大模型知识库），但缺少引擎工具之间的对比，今天我们来补测一下。
我把我的RTX4070笔记本重装了一遍Ubuntu 24.04系统（一劳永逸：实战Ubuntu服务器PXE自动化部署，从此装机so easy）。第一步，就是安装显卡驱动，最简单也是最稳妥的方法，就是通过系统工具自动安装推荐的NVIDIA驱动。安装完成之后，重启笔记本。
apt update && apt upgrade -y
ubuntu-drivers autoinstall
reboot
为了方便演示，我这次用的Desktop版本，这样就会遇到一个问题，那就是桌面进程会占用一部分显存，影响我们后续的测试。
因为电脑还有一个集成显卡UHD 770，接下来，我们要通过Systemd的覆盖机制，强行把Intel的硬件加速驱动指定给gnome-remote-desktop，把本地显示都迁移到集显中。
mkdir -p ~/.config/systemd/user/gnome-remote-desktop.service.d/
cat <
~/.config/systemd/user/gnome-remote-desktop.service.d/override.conf
[Service]
Environment=”LIBVA_DRIVER_NAME=iHD”
Environment=”VDPAU_DRIVER=va_gl”
EOF
重新加载配置并重启桌面服务：
systemctl –user daemon-reload
systemctl –user restart gnome-remote-desktop.service
在混合显卡笔记本上，X11会强行在NVIDIA显卡里划走一块显存备用。我们要把它切换到更现代、原生由核显渲染的Wayland会话，斩断X11的显存占用。
在GDM配置文件中，配置WaylandEnable=true，解除Wayland封印：
nano /etc/gdm3/custom.conf
WaylandEnable=true
创建一个指向/dev/null的软链接，彻底屏蔽61-gdm.rules。
sudo ln -s /dev/null /etc/udev/rules.d/61-gdm.rules
然后，重启显示管理器，让Wayland真正生效：
systemctl restart gdm3
在内核模块层，禁用NVIDIA的图形输出，告诉Linux内核：这张RTX4070是一张纯算力卡，不要让它负责任何屏幕显示或画面渲染。
echo “options nvidia-drm modeset=0” | tee /etc/modprobe.d/99-nvidia-compute-only.conf
Xorg有个坏习惯，喜欢把主板上插着的所有显卡都摸一遍，我们直接在Xorg服务层，禁止自动添加副显卡，砍掉它的手：
mkdir -p /etc/X11/xorg.conf.d/
cat <
Section “ServerFlags”
Option “AutoAddGPU” “off”
EndSection
EOF
因为显卡驱动在系统刚通电时就会加载，所以必须把上面的修改写进initramfs（底层引导镜像启动内存盘）里。
update-initramfs -u
跑完之后，直接重启笔记本：
最后，验证成果：
nvidia-smi
现在就剩下一个占用2 MB显存的SHELL了。
接下来，我们一键部署ollama服务。
curl -fsSL https://ollama.com/install.sh | sh
模型方面，基于我们之前的经验，8 GB显存一般也就能运行到INT4量化的9B参数就差不多了，要是再高一点，留给上下文的空间就不多了。所以，我们主要选择参数量在8B、9B附近的模型，毕竟底大一级压死人。
我爬取了ollama官网，一共抓取到7000+个模型，参数量为10B的只有一个，falcon3:falcon3:10b，但是这个模型的最大参数量就是10B，名不见经传，能力有限。
此外，最新的模型就是qwen3.5:9b，也是一款高参数密度的常规指令模型，得益于9B的参数量和3.5代的架构，它对Python的语法掌握极其精准，智商下限最高。支持通过OpenClaw调用API，对于输出绝对严格的JSON格式，它几乎不会出错。当然，以为模型比较到，导致它的上下文极短，如果一次性发送内容过多，它会瞬间爆显存导致系统卡死。
还有最为经典的deepseek-r1:8b，RL强化学习驱动的CoT思维链模型。8B的参数量能留下比较多的显存，吞吐量和上下文空间非常充裕，适合处理复杂问题。缺点就是思考过程会产生大量内部Token，导致我们拿到最终答案的首字延迟（TTFT）较长。
如果需要视觉处理，可以选择qwen3-vl:8b，能看图说话，但是比较吃显存，千万不要给它传4K图，一定要压缩到1080P以下，否则必爆显存。而且它处理纯文本任务的逻辑能力不如同级别的纯文本Qwen模型，不过我们还有qwen3.5:9b来处理文本。
在8B参数下，还有一个llama3.1:8b，是Meta出品的全球开源生态标准基座，有绝对的生态兼容性，主打高并发，且体积最小巧，显存压力最小，理论上速度最快。无论我们在Github上拉取任何最新的AI运维工具、Agent框架等，默认的测试模型100 %都是它。它的英文技术文档（如IETF RFC等）理解能力世界一流，但中文语言习惯稍显生硬。
现在看来，这4个模型堪称四大金刚：遇到上传请求，召唤qwen3-vl:8b；遇到复杂问题，召唤deepseek-r1:8b进行深度思考；对于结构化API返回，召唤qwen3.5:9b；如果追求响应速度，召唤llama3.1:8b。因为模型都比较小，加载到显卡的时间基本上都在2秒钟以内。
ollama pull qwen3.5:9b
ollama pull qwen3-vl:8b
ollama pull deepseek-r1:8b
ollama pull llama3.1:8b
简单测试一下输出速度。测试提示词如下：
你是一个资深网络工程师。我现在的网络拓扑如下：R1和R2运行OSPF，都在Area 0。R2和R3运行BGP（eBGP）。R2将OSPF路由重分发进了BGP。
现在出现了一个故障：R3能够学习到R1的Loopback接口路由，但是R3无法ping通R1的Loopback接口。请列出排查此故障的3个最可能原因，并给出具体的排查命令（假设设备为华为VRP操作系统）。要求逻辑严密，不要有废话。
先测试qwen3.5:9b。
ollama run qwen3.5:9b –verbose
中间卡了大概十秒。好像触发了极其经典的复读机幻觉，最终回答失败了，用了将近8分钟，一共输出12225 token，平均速度26.26 TPS。
运行过程中，显存占用6154 MB，功率67瓦，还有空间，就是不太实用。
接下来测试上一代的qwen3-vl:8b，我们把问题换成，提示词为【看一下/root/ScreenShot_2026-03-27_220856_249.png的问题】。
ollama run qwen3-vl:8b –verbose
几乎没有延迟，马上就识别到了问题，但是思考过程中，前半段是中文，后半段是英文。但好歹比3.5好使，用时两分半，一共输出6914 token，平均速度44.93 TPS，比3.5快了71 %。
运行过程中，显存占用6858 MB，功率105瓦，比9B模型资源消耗还多。
然后试试经典的deepseek-r1:8b。
ollama run deepseek-r1:8b –verbose
不愧是一代经典，仅用时34秒，一共输出1575 token，平均速度46.05 TPS，比qwen3-vl:8b稍微快一点点，大概2 %。
运行过程中，显存占用5504 MB，功率100瓦。
最后试试经典的llama3.1:8b。
ollama run llama3.1:8b –verbose
8.6秒，这也太快了！一共输出414 token，平均速度50.4 TPS，比deepseek-r1:8b又快了9 %。
运行过程中，显存占用5352 MB，功率100瓦。
当然，还有一个叫lucasmg/deepseek-r1-8b-0528-qwen3-q4_K_M-tool-true的模型，据说是deepseek-r1的qwen3优化版本，我们也试一下。
ollama run lucasmg/deepseek-r1-8b-0528-qwen3-q4_K_M-tool-true –verbose
杂交之后，回答用时56秒，一共输出2503 token，平均速度45.43 TPS，输出速度跟deepseek-r1:8b差不多，但是输出更长了。
运行过程中，显存占用5504 MB，功率99瓦。这不是一样的？
汇总一下：
这么看来，好像qwen3.5也没什么优势啊，还不如deepseek-r1和qwen3-vl更均衡。当然，追求速度，还是得看llama3.1。
这次横评不仅仅是为了跑分，而是为了给后端的自动化运维框架（例如ollama直接支持的OpenClaw应用）选拔大脑：
对于高频短促的日常脚本执行或英文文档查询，llama3.1:8b的50+ TPS是首选；但对于需要深入排查疑难杂症，deepseek-r1:8b的逻辑深度与输出速度是无可替代的；对于识别，qwen3-vl:8b也是一个不错的选择。
各位看官，如果你手头只有一张8G显存的显卡，你会选择哪个模型陪你打江山？是追求速度的Llama，还是追求深度的DeepSeek？
声明：来自铁军哥，仅代表创作者观点。链接：https://eyangzhen.com/7038.html
