8G显存跑AI：Llama3.1完胜Qwen3.5？Ubuntu下四大模型横评，速度竟差一倍！

我们之前使用ollama做了一系列的性能测试，最简单的是在Windows系统中，安装好GPU驱动，然后执行测试（）；或者是在macOS进行测试（）。

经过测试，我们还对模型的量化方式有了相对深入的了解（），为后面的使用打下了良好基础。

但是，在我们上次使用手机测试的时候（），发现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笔记本重装了一遍Ubuntu 24.04系统（）。第一步，就是安装显卡驱动，最简单也是最稳妥的方法，就是通过系统工具自动安装推荐的NVIDIA驱动。安装完成之后，重启笔记本。

apt update && apt upgrade -yubuntu-drivers autoinstallreboot

为了方便演示，我这次用的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-reloadsystemctl --user restart gnome-remote-desktop.service

在混合显卡笔记本上，X11会强行在NVIDIA显卡里划走一块显存备用。我们要把它切换到更现代、原生由核显渲染的Wayland会话，斩断X11的显存占用。

在GDM配置文件中，配置WaylandEnable=true，解除Wayland封印：

nano /etc/gdm3/custom.confWaylandEnable=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"EndSectionEOF

因为显卡驱动在系统刚通电时就会加载，所以必须把上面的修改写进initramfs（底层引导镜像启动内存盘）里。

update-initramfs -u

跑完之后，直接重启笔记本：

最后，验证成果：

nvidia-smi

现在就剩下一个占用2 MB显存的SHELL了。

接下来，我们一键部署ollama服务。

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"EOF0

模型方面，基于我们之前的经验，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秒钟以内。

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"EOF1

简单测试一下输出速度。测试提示词如下：

你是一个资深网络工程师。我现在的网络拓扑如下：R1和R2运行OSPF，都在Area 0。R2和R3运行BGP（eBGP）。R2将OSPF路由重分发进了BGP。

现在出现了一个故障：R3能够学习到R1的Loopback接口路由，但是R3无法ping通R1的Loopback接口。请列出排查此故障的3个最可能原因，并给出具体的排查命令（假设设备为华为VRP操作系统）。要求逻辑严密，不要有废话。

先测试qwen3.5:9b。

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"EOF2

中间卡了大概十秒。好像触发了极其经典的复读机幻觉，最终回答失败了，用了将近8分钟，一共输出12225 token，平均速度26.26 TPS。

运行过程中，显存占用6154 MB，功率67瓦，还有空间，就是不太实用。

接下来测试上一代的qwen3-vl:8b，我们把问题换成图片，提示词为【看一下/root/ScreenShot_2026-03-27_220856_249.png的问题】。

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"EOF3

几乎没有延迟，马上就识别到了问题，但是思考过程中，前半段是中文，后半段是英文。但好歹比3.5好使，用时两分半，一共输出6914 token，平均速度44.93 TPS，比3.5快了71 %。

运行过程中，显存占用6858 MB，功率105瓦，比9B模型资源消耗还多。

然后试试经典的deepseek-r1:8b。

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"EOF4

不愧是一代经典，仅用时34秒，一共输出1575 token，平均速度46.05 TPS，比qwen3-vl:8b稍微快一点点，大概2 %。

运行过程中，显存占用5504 MB，功率100瓦。

最后试试经典的llama3.1:8b。

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"EOF5

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优化版本，我们也试一下。

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"EOF6