企业官网建设流程全解析

1. 开始之前：为什么我在ArchLinux上折腾14b级本地大模型

先交代一下背景。我主力系统是ArchLinux，日常拿它写代码、跑实验、折腾各种新工具，显卡是一张12GB显存的消费级卡。前阵子DeepSeek开源了14b级别的模型权重，社区里讨论度很高，很多人想在本地跑起来。我当时第一反应是：这事在Arch上到底好不好搞？

先说结论：能搞，而且比想象中顺利。只要把驱动、推理框架、模型文件这三件事理顺，基本就是一条命令启动的事。但这三件事之间有不少坑，尤其Arch这种滚动更新发行版，内核、驱动、运行时库版本都可能比Ubuntu领先好几个身位，反而容易撞上兼容性问题。

这篇文章把我在ArchLinux上部署DeepSeek-14b的完整过程整理出来，包括为什么选这个模型、为什么用某个推理框架、每一步背后的理由、踩过的坑怎么解决。内容偏向实操，适合已经装了Arch、手头有N卡或A卡、想跑本地大模型但没跑通的人。没有Arch基础也没关系，我会把涉及的系统操作讲清楚，照着做就行。

2. 部署前的关键判断：模型选型与硬件评估

2.1 为什么选14b而不是7b或70b

大模型参数规模与硬件需求基本是线性关系，但体验差异很大。7b模型在消费级显卡上很流畅，但生成质量、推理深度、代码能力都偏弱，写点简单脚本还行，稍微复杂的逻辑就容易胡说。70b模型质量好，可那不是个人电脑跑得动的，哪怕量化后也要48GB以上显存，基本上得两张3090或4090。14b正好卡在中间：质量明显强于7b，硬件要求又没到企业级门槛，是个人本地部署的甜点区。

DeepSeek这个系列在中文场景下的表现一直不错，14b版本在代码补全、中英混合对话、逻辑推理这些维度上，跟同参数的Llama系列对比有明显的中文优势。如果你主力使用场景是中文，DeepSeek-14b是比Llama-3-8B更合适的选择。

2.2 显存、内存与量化等级怎么搭配

显存是最硬性的指标。14b模型如果完全用FP16精度加载，光是模型权重就需要约28GB显存。但实际推理不会直接用FP16裸跑，而是用量化压缩。量化就是把模型权重从16位浮点数压缩到更低的位宽，常见档位有Q4_K_M、Q5_K_M、Q8_0等，Q后面的数字越小，模型越小、精度损失越大。

以DeepSeek-14b为例，各量化档位的体积和显存需求大致如下：

我的卡是12GB显存，所以选择了Q4_K_M。实测生成速度大概在每秒20-35个token之间，取决于上下文长度和并发情况，用来日常写代码查资料完全够用。如果你的显卡是8GB显存，可以降一档选Q3量化，但质量会肉眼可见地下降，能上12GB还是尽量上12GB。

内存方面，16GB是底线。因为模型加载时除了显存里的权重，还要在内存里保留一份上下文缓存和推理中间结果。如果你是纯CPU推理，那内存就是你的主战场，32GB起步，64GB不嫌多。

2.3 ArchLinux做本地大模型部署的优与劣

先说优点。Arch的软件仓库更新极快，Ollama、llama.cpp这类推理框架几乎在上游发布后几天内就会进社区仓库，不用像Ubuntu那样加PPA或者自己编译。AUR更加方便，很多模型工具和辅助程序都能一条命令装上。Arch轻量、干净，没有那么多预装垃圾进程，留给推理的内存和CPU资源更多。

再说缺点。滚动更新的代价是版本兼容性风险。最常见的问题就是显卡驱动跟内核版本不匹配，升级内核后N卡驱动需要重新编译或安装对应版本，否则CUDA不可用。还有Python环境，Arch默认Python版本往往很新，很多依赖库来不及适配，容易遇到“版本太新导致安装失败”的怪问题。好在部署DeepSeek-14b用不到太复杂的Python环境，Ollama自带了运行时，能避开绝大部分坑。

3. 环境准备：ArchLinux上的驱动与基础依赖

3.1 N卡驱动安装与CUDA验证

如果你是N卡用户，第一件事就是装好驱动。Arch下N卡驱动有两种方式：一种是闭源驱动nvidia，性能好、CUDA支持完整；另一种是开源的nouveau，虽然近年进步很大，但跑大模型还是别指望它了。直接装闭源。

装驱动前先看一下内核版本，因为Arch滚动更新，内核可能刚升到很新的版本，而新内核往往需要新驱动，所以推荐用linux-lts内核搭配nvidia-lts驱动，这套组合稳定性明显更好。在实际操作中，我遇到过好几次内核小版本更新后，nvidia驱动和新内核的DKMS模块配对出现延迟，导致进桌面后GPU加速丢失。换成LTS内核后，这类问题基本绝迹。

安装命令：

sudo pacman -S linux-lts linux-lts-headers nvidia-lts nvidia-utils

装完后重启，然后验证：

nvidia-smi

如果能正常输出显卡信息、驱动版本、显存容量，说明驱动部分OK。重点看两个地方：Driver Version是否正常显示，CUDA Version是否显示了某个版本号（比如12.4）。这个CUDA版本号是驱动自带的、供CUDA运行时调用的API版本，Ollama会基于它来启用GPU加速。

注意：很多教程会让你装cuda这个包，那是完整CUDA开发套件，几百MB到几个GB不等。本地推理只需要驱动自带的CUDA运行时就够了，没必要装全套。除非你要自己编译Ollama或跑vLLM，那就另说。

3.2 A卡用户的备选方案

A卡用户也不用慌，AMD显卡跑大模型的方案已经成熟了。Arch下直接用开源驱动mesa和vulkan-radeon，Ollama在Linux下通过Vulkan或ROCm后端加速。实测ROCm在Arch上折腾一点，需要装rocm-hip-sdk等一堆包，但纯用Vulkan的话，Ollama也能跑起来，只是速度相比N卡的CUDA会慢一些。

我手头没有A卡实测数据，但社区里反馈是：同级别显卡性能差距大概在N卡的60%-80%之间，能用，但追求性能还是N卡更省心。如果你主力是A卡，建议装完驱动后直接跳到第四章，装好Ollama后跑一下ollama run，如果模型能正常加载并输出，就说明加速后端自动识别成功了。

3.3 基础依赖与系统配置

无论N卡还是A卡，有一样东西强烈建议先配好：swap交换分区或交换文件。大模型推理时极端情况下内存会飙高，如果内存不足又没有swap，内核会直接OOM杀进程，模型就崩了。我在18GB内存的机器上跑Q4量化版本，正常情况占用在12GB左右，但如果你同时开浏览器、IDE、聊天工具，内存很容易见底。提前建一个8GB的swap文件，成本极低，收益非常实在。

sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

这条命令建了一个8GB的swap文件，重启后需要重新swapon。要永久生效的话，在/etc/fstab里加一行：

/swapfile none swap defaults 0 0

另外，如果你的CPU比较老，不支持AVX2指令集，那跑量化模型会比较吃力。检查方法很简单：

lscpu | grep avx2

有输出说明支持，没有的话只能靠更强的显卡来弥补CPU指令集缺失的影响。

4. 推理框架选型：为什么我用Ollama而非vLLM或llama.cpp

4.1 几个主流框架的对比

部署大模型离不开推理框架。目前主流的选择有三个：Ollama、llama.cpp、vLLM，还有一个个人用户用得较少的Text Generation WebUI。简单对比一下：

我个人推荐个人桌面首选Ollama，核心原因有三个：

第一，Ollama把模型下载、加载、推理、服务化打包成了一个完整的闭环，几行命令搞定。llama.cpp需要自己去HuggingFace下载模型文件，再手动执行二进制文件，步骤繁琐还容易出错。

第二，Ollama的API接口与OpenAI的格式兼容，这意味着你装好后，可以直接被各种第三方工具调用，比如ChatGPT-Next-Web、Dify、代码编辑器的AI插件，不用自己写适配层。

第三，Ollama对GPU的自动检测和调度做得相当好，N卡A卡或纯CPU都能自动识别，对Arch这种系统环境复杂的玩家来说刚好合适。

4.2 vLLM在什么情况下值得用

如果你的目标是部署一个服务给多人使用，或者做高并发的API服务，那vLLM的优势就体现出来了。vLLM的PagedAttention内存管理机制在并发场景下能把显存利用率拉满，吞吐量比Ollama高出不少。但代价是配置复杂度大幅上升，需要Python虚拟环境、CUDA工具链、特定版本依赖，在Arch上装vLLM需要很强的耐心。

我不建议新手一上来就搞vLLM。先把Ollama跑通，模型验证没问题，再考虑要不要升级到vLLM。而且14b这种规模，个人本地用的时候Ollama的并发能力已经完全够用，没必要自找麻烦。

4.3 Ollama安装与初始化

Arch下安装Ollama非常省事，官方仓库和AUR都有：

sudo pacman -S ollama

装好后，先把服务启动。Arch的systemd管理方式是这样的：

sudo systemctl enable --now ollama

enable是设置开机自启，--now是立即启动。启动后确认一下状态：

systemctl status ollama

正常情况下应该显示active (running)。如果显示启动失败，大概率是硬件加速库缺失，把上一节说到的驱动装好再试。

提示：Ollama默认只监听本机127.0.0.1:11434，这正是安全默认值。不要为了方便直接改成--host 0.0.0.0暴露到局域网，除非你清楚自己在做什么，否则等于把一台能提供大模型能力的机器裸奔在内网里。

4.4 服务端的性能调优参数

Ollama有两个环境变量对体验影响很大，一个是上下文长度，一个是并发数。

默认上下文长度是2048，意味着模型只能记住最近2048个token的对话内容。如果对话历史长，模型就会“失忆”。把上下文调到更大的值能让模型更聪明，但代价是显存占用飙升，因为键值缓存的大小跟上下文长度成正比。

我的建议是：

sudo systemctl edit ollama

然后写入：

[Service] Environment="OLLAMA_CONTEXT_LENGTH=8192"

重启后生效：

sudo systemctl restart ollama

8192这个值在12GB显存下，跑Q4量化的14b模型还很宽裕。如果你显存更大，可以继续往上调，但不要盲目调到32000以上，收益边际递减且显存压力大。

并发数默认是0，即自动判断。在个人电脑上，其实不需要调大并发，一个用户交互时并发数1-2就够了，调大了反而会互相抢显存导致所有请求一起变慢。

5. 下载并运行DeepSeek-14b：完整实操过程

5.1 拉取模型：第一次跑通的完整命令

Ollama安装完毕，接下来就是拉取模型文件了。DeepSeek-14b在Ollama模型库里的标记是deepseek-r1:14b（不同发布版可能略有差异，可以在ollama list后确认）。直接拉取：

ollama pull deepseek-r1:14b

这个命令会从模型仓库下载预打包好的量化模型到本地，默认是Q4_K_M量化版本。下载体积大约9GB，取决于你的网速需要等一会儿。Arch下如果你配了代理，下载速度会快很多，模型仓库国内访问一般没问题。

下载完成后，跑个测试对话：

ollama run deepseek-r1:14b

出现对话提示符后，输入“你好”或任意测试语句，看模型能否正常回复。第一次运行会有几秒钟的加载时间，这是把模型权重从磁盘读入显存的过程，之后就会很流畅。

如果这一步顺利出结果，恭喜，你已经成功在ArchLinux上把DeepSeek-14b跑起来了。整个过程比我想象中顺利，核心步骤其实就是装Ollama、拉模型、运行这三件事。

5.2 验证GPU加速是否真正生效

很多新手在这一步会踩坑：模型确实跑起来了，但输出速度奇慢，每秒就几个token，自己还以为是正常现象。其实这是因为模型跑在CPU上，GPU加速根本没启用。

验证方法很简单，找一个模型正在运行的窗口，另开一个终端输入：

nvidia-smi

如果看到输出里有python或ollama进程占用了显存（比如显示8GB / 12GB used），说明GPU加速生效。如果显存几乎没占用，而CPU占用率拉满，说明模型跑在CPU上。

Ollama没启用GPU的常见原因有：驱动没装好、驱动版本太低、模型运行时被强制分配到了CPU、OLLAMA_GPU_LAYERS参数设置问题。在Arch下最常见的还是驱动问题，毕竟滚动更新造成的内核和驱动版本错位是家常便饭。

这里我自己的经验是：如果nvidia-smi正常但ollama不认GPU，试试重启一下系统。很多时候是因为驱动模块在内核更新后加载异常，重启后重新加载就好了，简单但有效。

心得：还有个小技巧，直接看生成速度。Q4量化的14b模型，在CPU上生成速度约为每秒2-6个token，在GPU上则能达到20-35个token。如果你感觉输出像打字机卡顿，那就是CPU在跑，先别怀疑模型，回去查驱动。

5.3 自定义模型参数：让模型更适合自己的使用习惯

Ollama支持通过Modelfile自定义模型行为。这类自定义很有用，比如调整温度、设置系统提示词、切换量化版本。

先在~/.ollama下新建一个Modelfile：

nano ~/.ollama/Modelfile

内容这样写：

FROM deepseek-r1:14b SYSTEM "你是一个资深Linux工程师，精通ArchLinux、Shell脚本和系统运维。请用简洁准确的语言回答问题。"

然后执行：

ollama create my-deepseek -f ~/.ollama/Modelfile

这样就创建了一个叫my-deepseek的新模型，使用同样的权重，但系统提示词变成了自定义内容。以后运行：

ollama run my-deepseek

所有对话都会带上“你是资深Linux工程师”的设定，回答风格会明显更贴合你的使用场景。

温度这个参数也值得调一下。Ollama默认温度是0.8，偏低温和偏高差别挺大。写代码、查资料时我个人习惯把温度降到0.3-0.5，输出更稳定，幻觉更少。做创意写作时调高到0.9反而更有灵感。在Modelfile里加一行：

PARAMETER temperature 0.4

重建模型后生效。

5.4 中文输入法问题怎么处理

在Arch上跑DeepSeek-14b，还顺带解决了一个日常痛点：终端里的中文输入。

我用的桌面环境是Hyprland，刚装的时候终端里没法输入中文，搜了很多教程才解决。这个问题的根源是环境变量没设置好，缺少输入法框架。我最终用fcitx5搭配rime方案解决了。

sudo pacman -S fcitx5 fcitx5-rime fcitx5-configtool

然后在/etc/environment或~/.bashrc里添加：

export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx

重启或重新登录后，在终端里按下Ctrl+Space就能切换中英文输入了。

6. 日常工作流：用API把模型接入各种工具

6.1 Ollama的OpenAI兼容API

Ollama不光自带交互式对话界面，还内置了一个HTTP服务，监听在11434端口，提供了与OpenAI格式兼容的API。这意味着很多为OpenAI写的工具和代码，不用大改就能直接用上本地模型。

先用curl测一下：

curl http://localhost:11434/v1/chat/completions \ -d '{ "model": "deepseek-r1:14b", "messages": [ {"role": "user", "content": "用一句话解释什么是大语言模型"} ] }'

返回结果会是标准的JSON格式，里面包含模型生成的回复。这个接口跟OpenAI的chat/completions接口结构基本一致，只是base_url换成了http://localhost:11434/v1。

6.2 Python调用示例

如果你习惯了用Python写脚本，那用openai库直接调本地模型就行，不需要装额外的SDK：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) response = client.chat.completions.create( model="deepseek-r1:14b", messages=[ {"role": "system", "content": "你是一个简洁的技术助手。"}, {"role": "user", "content": "在ArchLinux上如何查看系统日志？"} ], temperature=0.3, stream=True ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="", flush=True)

注意api_key那里随便填一个字符串就行，本地服务不校验。stream=True启动流式输出，效果就像ChatGPT一样一个字一个字蹦出来，交互体验更好。

把这个脚本保存为chat.py，运行：

python chat.py

就能在终端里跟DeepSeek对话了。

6.3 接入网页聊天界面与代码编辑器

CLI对话方便，但很多人还是喜欢网页聊天这种形式。Ollama官方有配套的Open WebUI，在Arch下可以直接用Docker装，或者用pip装到系统里：

sudo pacman -S open-webui

或者用Docker的方式：

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

启动后浏览器打开http://localhost:3000，注册一个本地账号，然后在设置里把Ollama的地址填成http://localhost:11434，就能看到模型列表并开始聊天了。

Open WebUI界面做得不错，支持Markdown渲染、代码高亮、文件上传，基本接近ChatGPT的使用体验。它还内置了RAG知识库功能，可以上传PDF或文档作为模型的知识来源，让模型回答与个人资料相关的问题。

代码编辑器方面，我自己用的是Neovim加Continue插件，这个插件支持自定义大模型API。在配置文件里把base_url指向本地Ollama，就能在写代码时享受自动补全和对话式辅助，所有数据都不离开本机。类似的方案还有VS Code的Continue扩展和JetBrains家的CodeGPT插件，配置思路都一样。

7. 性能调优与资源管理：让模型跑得更快更稳

7.1 提升生成速度的几个关键变量

跑大模型最影响体验的就是生成速度。决定速度的因素主要有三个：量化档位、上下文长度、GPU配置。

量化档位是速度的最主要决定因素。Q4量化比Q8快约30%，比FP16快约60%。在显存允许的情况下，如果只追求速度，那Q4_K_M就是最优选择，质量损失很小但速度收益明显。

上下文长度影响的是首token延迟。上下文越长，模型在生成第一个token前需要处理的历史内容越多，首token延迟越高。我之前试过从4096调到32768，首token延迟增加了将近1秒。如果你的对话基本都是短问题短回答，保持默认的2048或调成4096就够了，没必要为了“理论上更强”盲目拉长。

GPU配置方面，先确认Ollama确实把模型放进了显存而不是内存。方法还是nvidia-smi，看ollama进程占用的显存是否接近模型体积。如果发现占用很小，试试设置环境变量强制指定：

OLLAMA_GPU_LAYERS=99

这个变量是让尽可能多的大模型层跑在GPU上。数值设大一点没毛病，99的意思是把所有可移动的层全部塞进显存。

7.2 显存不足时的降级方案

显存不够是个人电脑跑大模型最常见的窘境。我12GB的显存跑14b Q4量化版刚刚好，但如果你同时开着游戏或IDE，显存就可能不够用。这时候Ollama不会崩，而是自动把部分层回退到CPU计算，表现就是生成速度骤降。

遇到这种情况，最直接的办法是关掉占显存的程序。如果不想关，就得降低模型量化档位，比如从Q4_K_M降级到Q3_K_S，体积减少约35%，显存占用也能降下来。

另一个思路是“剥离上下文缓存”。如果你明确知道自己每次对话很短，可以把OLLAMA_CONTEXT_LENGTH调低到2048，能节省约1-2GB显存，给模型权重腾出空间。

7.3 资源监控：掌握模型运行的实时状态

跑长时间任务或者多人共用的机器上，资源监控很重要。我常用的一个做法是写个简短的shell命令，定时刷新显存和内存占用：

watch -n 2 nvidia-smi

watch每2秒刷新一次nvidia-smi输出，可以实时看到显存占用、GPU利用率、进程列表等信息。

如果跑的是长时间批量任务，我还会用ollama ps看当前加载了哪些模型：

ollama ps

这命令会显示模型名称、大小、处理器类型（GPU/CPU）、显存占用等。默认情况下Ollama会把最近用过的模型保留在显存里，直到显存耗尽或5分钟无请求后才卸载。如果你需要频繁切换不同模型，可以在启动Ollama服务前加上环境变量：

OLLAMA_KEEP_ALIVE=30

表示模型在无请求30秒后自动卸载，释放显存给下一个模型用。示例值是30秒，也可以改成长时间，比如-1表示永久驻留。

心得：我个人的经验是，KEEP_ALIVE别设置得太短，否则频繁加载模型反而增加等待时间。日常使用保持默认值或设为10分钟比较合适。只有当你需要在多个模型间快速切换时才调短。

7.4 systemd服务配置的完整参考

最后把我的Ollama systemd配置完整贴出来，方便你直接参考。编辑服务配置：

sudo systemctl edit ollama

覆盖配置：

[Service] Environment="OLLAMA_HOST=127.0.0.1:11434" Environment="OLLAMA_CONTEXT_LENGTH=8192" Environment="OLLAMA_KEEP_ALIVE=600" Environment="OLLAMA_GPU_LAYERS=99"

保存后重启服务：

sudo systemctl daemon-reload sudo systemctl restart ollama

这套配置的含义是：只监听本机、上下文8192、模型空闲10分钟后卸载、优先全部使用GPU。你在部署时可以根据自己的显存大小调整上下文长度，1024-16384都是合理范围。

8. 实战中遇到的坑：问题排查与解决方案

8.1 模型加载失败，提示CUDA错误

这是我在Arch上遇到最多的一个问题，基本都跟驱动有关。现象是ollama run时报错，提示CUDA相关错误，有些直接告诉你找不到CUDA设备。

排查步骤很固定：

nvidia-smi

如果命令报错，说明驱动有问题。这时候先看内核版本：

uname -r

再看装的是哪个驱动包：

pacman -Q | grep nvidia

如果内核是6.x，驱动是nvidia而非nvidia-lts，极大概率是不配套。把内核换成LTS，驱动换成nvidia-lts，重启后基本解决。

如果nvidia-smi正常，但Ollama还是报CUDA错误，那就检查环境变量。有可能你之前装过CUDA开发套件，配置过CUDA_PATH或LD_LIBRARY_PATH，指向了某个不存在的路径。在/etc/environment或Shell配置文件里清理掉无关的变量，再试一次。

8.2 显存足够，但提示“insufficient memory”

Ollama在某些版本对显存判定的逻辑比较保守。如果你的显存刚够模型需要，且系统里同时有桌面环境占用了一部分显存，Ollama可能误判为显存不足而拒绝加载GPU层，直接退到CPU模式。

排查办法是先看nvidia-smi里显存占用率：

nvidia-smi --query-gpu=memory.used,memory.total --format=csv

如果总显存12GB，已用3GB，剩余9GB，但模型需要10GB，那确实不够。只能降低上下文长度或换更低量化。如果剩余显存明明够，但Ollama还是报错，那试试在服务配置里加：

Environment="OLLAMA_GPU_LAYERS=90"

不用100，给系统留一点缓冲，反而更容易成功加载。

8.3 模型下载中断，如何续传

Ollama拉取大模型时，网络不稳定会导致下载中断。官方客户端支不支持断点续传经常被问。实际上Ollama有内部的下载缓存机制，中断后重新执行：

ollama pull deepseek-r1:14b

它会从上次中断的地方继续，而不是重新下载。我在国内网络环境下，拉模型时断过两次，重新执行后都能续传，几十秒后就恢复进度了。

如果你发现每次重新执行都从0%开始，那可能是Ollama版本过旧，更新一下：

sudo pacman -Syu

把系统更新到最新再试。

8.4 常出现问题的速查表

8.5 一个小坑：Arch更新后Ollama服务起不来

Arch滚动更新的尿性，某个ollama包更新后，服务可能启动失败。有一次我更新完系统，systemctl status ollama显示failed，日志里报的是某个共享库找不到。

排查过程：

journalctl -u ollama -n 50

看到确实有一个.so文件找不到。用pacman -Qo查一下这个文件属于哪个包：

pacman -Qo /usr/lib/libxxx.so

发现是某个基础库版本变了，而Ollama还没适配。解决办法很简单：等上游更新，或者装AUR里更新的版本。如果急用，可以临时用旧版本：

sudo pacman -U /var/cache/pacman/pkg/ollama-旧版本.pkg.tar.zst

生活就是这样，聪明的是备点旧包，不然更新踩坑就只能干等。

9. 部署完成后，我的一些真实体会

整套部署下来，我在ArchLinux上跑通DeepSeek-14b大约花了半天时间，其中大部分耗在驱动适配和中文输入法问题上，真正跟大模型相关的时间其实很短。这也侧面说明，本地部署大模型的工具链已经发展得很成熟了，它不再是极客的专属玩具。

现在这台机器每天早上开机，Ollama服务自动启动，我写代码时随时调API让模型帮忙看报错、写测试、生成正则表达式，浏览器里开着Open WebUI查资料时随手问一句。所有数据都在本机，不会把业务代码泄露给第三方，这一点在很多场景里比模型智能程度更让人安心。

14b这个规模有个好处：它快，快到你不会因为等待而放弃使用它。我自己尝试过70b模型，每次回答问题都要等好几秒，那种迟滞感真的会打击使用热情。14b的秒回体验，让你会真的把它当工具用，而不是当作一个高不可攀的演示项目。

如果你也想在Arch上跑本地大模型，我的建议是：硬件就按12GB显存起步，内存32GB，框架直接选Ollama，模型先用14b的Q4量化版跑通全流程，然后再根据自己的需求往上加。不要一开始就追求完美，先用起来，比什么都重要。

最后再分享一个小技巧：模型文件默认存放在~/.ollama/models目录，占了将近10GB空间。Arch的系统盘如果紧张，可以把这个目录软链到其他分区：

mv ~/.ollama/models /mnt/data/ollama-models ln -s /mnt/data/ollama-models ~/.ollama/models

只要在模型未运行时操作，链路是安全的，别在模型加载时动它。这个操作能帮你省出好几个G的系统盘空间，别等到磁盘满了再处理，那就麻烦了。