把大模型塞进终端这事我在两年前还觉得是“折腾给自己看”的玩法。命令行里跑个大模型没有可视化聊天界面没有漂亮的流式输出卡片甚至连个像样的进度条都要自己写终端转圈动画。但真等我把本地的 Qwen 和 Llama.cpp 全部切到终端里用起来再回头看那些 GUI 套壳应用反而觉得少了点什么。终端这个被嫌弃了十几年的老界面和大模型这种新玩意儿凑到一块意外地顺手意外地高效。这篇就聊聊 LLM CLI 这条线。核心不是让你抛弃所有图形界面而是说清楚终端场景下怎么把大模型真正用起来有哪些趁手的工具、怎么接入本地或者远端模型、怎么处理上下文和编码问题、长时间挂机该用什么姿势。如果你已经受够了每次都要打开浏览器才能问一句“帮我写个正则”或者你手上是台配置不高的小机器想本地跑个量化小模型当终端助手这篇应该能帮你省不少弯路。1. 为什么要把大模型请进终端1.1 终端这个老界面凭什么又吃香了终端命令行本质上就是个“低带宽、高精度”的交互界面。它的输入输出没有富文本、没有图片、没有花哨的排版全靠字符流转。这个特性在过去被批“门槛高”但在大模型时代反而成了优点因为大模型返回的内容本质上就是文本流。你把一段文本交给模型模型吐回来的还是一段文本。终端天生就是干这个的渲染零成本复制零障碍重定向、管道、脚本化全是原生支持。举个最直观的例子。你在图形界面里和模型聊完一段代码想把历史记录里的某一行提取出来基本靠手选、复制、粘贴。但在终端里你可以直接把模型输出通过管道丢给 grep、jq、sed甚至拿来做成一个 shell 函数。像我用终端里的 Aider 改代码每次改完自动 git diff这事情在 GUI 里就得靠插件或者手点但在终端里就是管道加别名的事。另外你会发现终端对大模型资源的消耗感知特别透明。CPU 占用、显存占用、温度、每秒 token 数全部可以用 nvidia-smi、top 这些命令并排监控。图形界面一包装很多细节被隐藏了出了问题反而不容易定位。1.2 LLM CLI 到底解决了什么真实需求先把“终端跑大模型”拆成三类需求你对照着看自己是哪一类。第一类本地推理引擎的 CLI 交互。典型的就是 llama.cpp 编译出来的 main 可执行文件、Ollama 自带的命令行交互或者 AirLLM 这类在低显存环境下跑模型的小工具。这类需求的核心是“不让数据出本机”离线也好、隐私敏感也罢图的是一个自主可控。第二类面向通用模型的命令行客户端。典型如 simonw 写的 llm 工具或者各种纯 Python、纯 Go 写的 CLI 聚合客户端。这类工具本身不加载模型而是包装远端或本地 API帮你管理多套模型、多组 API Key、多种提示词模板。第三类面向代码场景的编程助手 CLI。比如最常见的 Codex CLI或者各种国产模型的 CLI 接入版。这类工具要解决的痛点很明确我正在终端里写代码不想切到网页去问“这段函数怎么 optimize”而是希望直接在编辑器旁边的终端里让 AI 改文件、生成 diff、跑测试。这三类需求背后有一个共同逻辑模型能力越强越像一个“可以在任意地方被调用的函数”。CLI 就是那个把函数暴露给 shell 的入口。1.3 终端与 GUI 的边界别当成零和博弈现在网上很多人一说“终端跑大模型”就阴阳怪气说你有图形界面不用非要折磨自己。我觉得这是把两件事搞混了。GUI 适合浏览、沉浸式对话、多模态内容展示终端适合批量、脚本、管道、远程环境下使用大模型。这两个场景并不冲突。我自己是混合用的。日常长文总结、知识问答、需要看图的场景我会用带图形界面的工具。但凡是批量处理文件、配合 git 操作、在 SSH 远程服务器上做数据处理我就老老实实用终端里的 LLM CLI。因为远程服务器上往往没有图形桌面终端是唯一可用的交互方式。我在 WSL2 里跑本地大模型然后从 Windows 侧用 VS Code 的终端连过去整个过程顺畅得很。你要是维护过几台服务器你会很自然地把 LLM CLI 纳入工具箱就像你用 htop 和 vim 一样自然。2. 主流 LLM CLI 工具选型与思路2.1 本地推理引擎llama.cpp、Ollama、AirLLM 怎么选本地跑模型的 CLI 解决方案市面上已经卷出了好几个路线这里先讲三个最有代表性的。llama.cpp 是基础也是绕不开的底层项目。它把所有模型权重转成 GGUF 格式然后在 CPU 上高效跑推理也能通过 GPU 加速。它提供的最原始 CLI 是 main 这个命令编译完之后你直接对着它的参数去调就行。这个工具适合什么人适合想搞清楚推理细节的人。吞吐、批处理大小、上下文长度、KV cache 量化、多卡拆分这些全部暴露在参数里。你可以像调校一辆老式机械车一样一点点试出自己机器的最优配置。缺点是学习成本高交互也弱更多是“跑一次推理”而不是“陪你聊天”。Ollama 的出现本质上就是把 llama.cpp 的复杂度封装掉了。它自带模型下载管理一条命令 ollama run qwen2.5:7b 就把模型拉下来并进入交互模式。它的 CLI 体验更像是你在终端里和一个模型助手对话有历史记录、有流式输出、可以通过 Modelfile 自定义系统提示词。对大多数普通用户和非重型场景Ollama 是那个“装完就能用”的方案。我个人很喜欢它的 API 兼容接口你甚至可以用它作为后面各种 CLI 工具的后端引擎。AirLLM 则是另一种极端场景——它专门解决“显存不够”的问题。通过类似混合精度的方案能让你在 4GB 甚至更小显存的显卡上跑几十亿参数模型。它的 CLI 风格非常“数据科学化”适合研究用途。但要明确它的速度没法跟 Ollama 比属于“能不能跑起来”型工具而不是“跑得爽”型工具。选型建议很简单追求深度调优、需要脚本化推理的选 llama.cpp想省心的选 Ollama显存捉襟见肘的试 AirLLM。三者也可以并存并不冲突。2.2 通用客户端一条命令调用模型的几种姿势本地推理引擎解决的是“模型怎么跑”的问题通用客户端解决的是“怎么舒服地调模型”的问题。这类工具更像一个模型接入总线后端可以接本地 Ollama也可以接各种线上 API。比较典型的是 simonw/llm它是一个 Python 写的命令行工具设计思路很清晰。你配置好各个模型的 API 端点然后 llm -m gpt-4o 一口气列出十种用终端管理日程的方法 这种用法就出来了。它还支持模板、支持把输出存成 SQLite 方便后续查询甚至可以把你自己的本地 Ollama 模型作为后端注册进去。类似的工具还有 aichat。aichat 的特点是配置灵活你可以给不同模型设定不同的角色在同一个会话内随时切换模型。它本身还内置了一些高级功能比如把聊天记录保存成 Markdown、在 TUI 界面里交互、配合其他终端工具做脚本处理。我在实际使用里最常用的“通用客户端”其实是直接给上一层的编辑器插件用比如让 VS Code 里的 Continue 插件接入本地 Ollama但没有图形界面需求的时候终端里的 aichat 反而更快。你想想写代码写到一半直接按个快捷键呼出终端敲一行指令获得答案再按个快捷键回到编辑器这个流程度是跨窗口切换没法比的。2.3 编程助手 CLI让 AI 直接改文件现在终端里最热闹的赛道是编程助手 CLI。Codex CLI 这类的官方工具自不用说问题是很多国内模型也有 CLI 接入教程原理基本类似通过云端的推理服务把一个能够读文件、改文件、执行命令的“智能体”暴露在终端里。这类工具和普通聊天的最大区别在于它们不仅能回答问题还能动手。你让它“修一下 tests/test_login.py 里的断言错误”它会先读取文件内容再生成补丁最后执行测试验证。整个过程全都发生在终端你能看到它每一步在调用什么命令、读哪个文件。但用它也有不少坑。常见的问题是Codex CLI 在部分环境里会提示“没有终端和文件编辑工具”这通常是权限配置不全或者环境变量没设置到位需要检查运行用户对工作目录是否有完整读写权限以及是否安装了依赖的 jq、git 等命令。如果不想用官方服务也可以考虑开源自托管的 TabbyML。注意前面说的“Tabby 终端工具”是终端模拟器而 TabbyML 是编程助手两个是完全不同的东西。TabbyML 可以部署在你自己机器上然后通过各种编辑器插件调用也能用 REST API 形式在终端里做脚本化操作。这种方式的好处是代码不出内网很多团队已经在这样玩了。2.4 周边工具终端复用、文件管理、终端模拟器说完“跑模型的主力”周边工具才是让体验拉满的关键。第一个必须提的是终端复用器。长期跑大模型交互会话时最怕的就是 SSH 终端一断整个会话没了。tmux 就是解决这个问题的。在服务器上起一个 tmux 会话在里面跑 Ollama 交互或者长代码生成任务之后哪怕本机断网、SSH 超时服务器上的进程继续跑。等你重新连上tmux attach 一下原封不动回到之前的界面。这个体验直接决定了你能不能放心把大任务丢给终端。类似工具还有 Zellij风格更现代但 tmux 依然是生态最成熟的那个。第二个是终端文件管理器。你可能会问这和大模型有什么关系等你真的在终端里用编程助手改代码时突然想看一眼目录结构或者某个文件内容如果反复敲 ls、cd、cat效率会很低。Yazi 这类终端文件管理器提供了类似图形文件管理器的预览能力可以直接看文本文件、图片缩略图而且可以嵌入 tmux习惯之后可以完全代替在图形界面上翻文件。第三个是终端模拟器本身。如果你在用 WindowsWindows Terminal 是最好的起点macOS 上可以用系统自带 Terminal也可以升级到 iTerm2。终端模拟器的选择会直接影响到字体渲染、光标跟随、Unicode 字符显示对亚洲语言环境尤其重要。3. 实操从零搭一个可用的终端大模型环境3.1 环境准备先把终端基础打牢既然主题是终端那环境准备的每一步都在终端里完成。先确认你日常终端是否正常尤其是 WSL2 用户很多人卡在怎么快速进入 Ubuntu 终端。最简单的办法是 Windows 终端里直接配置默认配置文件为 Ubuntu或者用 wsl 命令从 PowerShell 启动。注意 WSL2 的启动路径如果是挂在 /mnt/c 下的 Windows 文件系统IO 性能会差不少大模型训练和推理尽量把项目放到 Linux 侧的目录比如 ~/projects。macOS 用户有一个很实用的小技巧在 Finder 的某个文件夹图标上你默认没有“在该目录打开终端”的选项。可以在“系统设置 - 键盘 - 键盘快捷键 - 服务”里勾选“新建位于文件夹位置的终端窗口”这样以后在任何目录都能直接呼出终端省得一遍遍 cd。Linux 桌面玩家最简单发行版自带终端模拟器装好就能用。唯一要注意的是不同桌面环境的默认 shell 可能不一样有些发行版默认 zsh有些默认 bash后面配置环境变量的时候注意别写错文件。3.2 部署并运行一个本地模型以 Qwen2.5 为例本地跑模型我最推荐的路线还是 Ollama步骤少、出问题概率低。先把 Ollama 装上纯终端操作以 Linux 为例官方提供了脚本安装。装好后直接拉取一个 Qwen2.5 7B 的量化版本ollama pull qwen2.5:7b ollama run qwen2.5:7b第二条命令会进入交互式命令行你直接打“你好”就能得到回复。就这么简单本地模型已经跑起来了。但这里我要多说两句。很多人第一步就卡在下载太慢上因为模型权重文件比较大。解决方法是给 Ollama 配置镜像源不同地区的镜像不太一样。另外Ollama 默认模型存放路径在用户目录下如果你的系统盘空间紧张务必提前改路径。配置 OLLAMA_MODELS 环境变量为其他磁盘上的目录即可。如果你更想了解推理引擎底层直接玩 llama.cpp 也一样。编译过程几乎是一条命令之后需要找到对应的 GGUF 权重文件。像 Qwen2.5 系列在模型托管平台上都有 GGUF 版本把权重文件下载到本地然后用类似下面的命令跑./llama-cli -m /models/qwen2.5-7b-q4_k_m.gguf -p 你好请介绍一下自己 -n 256这里的 -n 是生成的 token 上限你可以把它理解成“最多输出多少个字”。至于量化格式q4_k_m 是一个速度和内存占用比较均衡的选择如果你的内存或者显存够大可以尝试 q8_0 精度更高一点。用 Ollama 时这些细节已经被自动处理但用 llama.cpp 时你得亲手选。3.3 把终端 AI 用于日常上下文管理和提示词策略模型跑起来之后真正决定好不好用的是“你如何给它上下文”。终端里的交互模式和网页聊天不一样你的输入会被当成一次完整请求发送。如果没有设置好上下文模型记不住前面的对话每次回答都是“失忆”状态。Ollama 默认会在一个会话内保留历史但如果通过 API 调用就得自己把历史消息拼接到请求里。这里给个实用的经验把每次请求的上下文压缩到关键信息而不是把所有历史原文都塞进去。比如你让模型修改一段文件不需要把整个文件发过去只需要把报错日志和相关函数片段发过去。如果你在终端里用脚本化方式调用模型可以构建一套输入模板。我在实际项目里总结了几个常用的系统提示词模板比如“你是一名资深 SQL 优化师只回答 SQL不解释其他内容”“你是日志分析助手从以下日志中找出异常点并按时间排序输出”。把这些模板存成文件curl 调用时用 $(cat 模板文件) 塞进去终端大模型就能变成一个可以随时复用的“专家工具”。3.4 后台挂机和终端复用长会话的正确姿势大模型交互经常是长会话特别是代码生成任务一次跑几十分钟很正常。网页端你关掉标签页就没了终端里你也怕中断。正确的姿势是开一个 tmux 会话。tmux new -s llm # 在会话里运行 ollama run qwen2.5:7b # 按 Ctrlb 然后按 d 分离会话 # 下次回来 tmux attach -t llm这个操作看着简单却是最容易被忽略的。我早期在服务器上跑一个长文本推理任务直接在 SSH 里裸跑结果中途网络抖了一下进程直接被杀几十秒生成的内容全丢了。后来所有 CPU 密集、GPU 推理任务一律丢进 tmux 或者 nohup再也没出现过类似事故。另外如果你用 Windows 终端连接 WSL2 里的模型服务后台管理逻辑是一样的。WSL2 里的进程并不因为 Windows 终端窗口关闭就终止但为了可控还是统一放在 tmux 里管理更稳妥。4. 常见问题与排查技巧实录4.1 终端中文乱码剑气留痕VS Code 终端中文乱码、Windows Terminal 中文乱码这些问题几乎每个中国开发者都遇到过用 LLM CLI 时尤其明显因为模型必然输出中文。乱码的根源九成是编码不一致终端模拟器认为你在用 UTF-8但 shell 或者工具本身输出的是 GBK或者反过来。排查思路很简单。第一步在终端里执行 echo $LANG看语言环境是不是 zh_CN.UTF-8 或者 en_US.UTF-8。不是的话在 ~/.bashrc 或 ~/.zshrc 里加上export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8第二步VS Code 终端里打开设置搜索 “terminal.integrated.profiles.windows” 或者相关的编码选项确保配置文件里没有强制设置 GBK。Windows Terminal 本身默认 UTF-8问题通常出在旧版 PowerShell 上可以用 chcp 65001 临时切换或者把控制台代码页改成 UTF-8。一个隐藏坑是有些模型输出会带特殊 Unicode 字符比如 Markdown 粗体星号、表格边框字符个别终端字体显示成方框。解决办法是换一个对 Unicode 支持好的字体比如 Sarasa Term SC、JetBrains Mono不要用老式点阵字体。4.2 显存和内存不足模型加载不进去怎么办本地部署大模型最现实的瓶颈就是资源。你满怀期待地运行 ollama run llama3.3:70b然后看到 Ollama 瞬间把内存吃光系统卡死或者直接被 OOM Killer 干掉。这个问题实操中非常让人头大但解决办法其实是一个“向下兼容”的阶梯。先看模型参数量和量化等级。70B 模型你要有 48GB 以上内存才有资格用 CPU 跑如果只有 16GB 内存就别硬撑。换成 7B 模型的 Q4 量化版本内存需求大概在 6GB 左右很多老机器都能跑。如果还想继续用大模型但资源不足把上下文长度调小是一个立竿见影的手段。Ollama 里可以设置 /set parameter num_ctx 4096这会将 KV cache 的内存占用大幅压缩。如果机器有独立显卡但显存只有 6GB用 AirLLM 这类工具可能比硬上 Ollama 更合适。虽然速度慢但至少模型能跑完。另外提醒一点WSL2 下 NVIDIA 显卡需要装 Windows 侧驱动和 WSL 里的 CUDA 工具包很多人漏了最后一步导致 Ollama 一直用 CPU 推理速度慢以为机器不行。4.3 API 响应不稳定超时和连接重置很多人不在本地跑模型而是用各种免费大模型 API 或者云端 API。命令行工具调用 API 时你会碰到网页端很少遇到的问题超时。网页端前端可能自动重试但 CLI 工具默认不会等太久。加超时时间是最直接的解法比如 curl 里用 --max-timePython 的 requests 里设置 timeout(connect, read)。如果是长文本生成光设置连接超时没用因为服务端可能在生成过程中无响应客户端会被 read timeout 掐断。这时候可以把读超时设置成 300 秒以上。还有一个很日常的问题是 API 返回结构变化。大模型 API 输出长度受到 max_tokens 限制有时候你发现回答突然“截断”了以为是模型问题仔细一看是 CLI 工具默认把 max_tokens 设成了 200。这个参数在 OAuth 或者云端工具里往往隐藏得很深有时需要去配置文件里手动调。4.4 上下文长度与提示词工程的配合CLI 使用大模型和网页聊天有本质区别每次调用都是一个“无状态请求”如果你不在提示词里把来龙去脉说清楚模型就只能瞎猜。这就是为什么在终端场景下提示词工程和上下文工程比 GUI 场景更重要。我踩过的一个深坑是为了省事我写了个很长的提示词模板包含系统的全部业务规则每次调用都完整拼接。结果模型开始“忘事”频繁输出无关内容。后来才意识到上下文太长了模型注意力机制被无关信息稀释。你要做的是“最小充分上下文”也就是只给模型提供完成任务所必需的信息。举个例子在终端里让模型写一份月度工作总结系统提示词只需要包含岗位角色、工作周期、三个关键指标数据。不要把你过去三个月的日报全部塞进去。总结成一句终端调用里上下文长度不是越长越好是越精准越好。5. 进阶玩法与个人实操心得5.1 用管道组合出自动化工作流当 LLM CLI 真正接入终端后最有意思的部分就是和 Unix 哲学结合。你可以把大模型当成一个高级文本过滤器接在任何管道中间。cat error.log | grep ERROR | tail -n 50 | llm -m qwen2.5 -p 从这些报错中推断最可能的原因并给出修复命令这种用法的妙处在于模型不需要看到整个日志文件只需要你精心筛选后的关键片段。我写了个别名叫 analyze专门做日志分析每周排查线上问题的时间从半小时降到了几分钟。本质上就是把大模型变成了一个“会总结的 grep”。5.2 本地部署与脚本化调用的组合拳如果手边有台性能不错的机器完全可以把它变成团队的“终端大模型服务中心”。部署方式很简单在服务器上装好 Ollama然后暴露 API 服务你笔记本上的各种 CLI 工具、编辑器插件、Python 脚本全部通过这个 API 调用。注意安全别轻易公网裸奔可以配个简单的 Token 或者放在内网。我自己的做法是配合一个反向代理只暴露需要的路径这样手机上也能通过快捷指令调家里的模型体验很奇妙。5.3 一些愿意分享给你的真实体会几年用下来我最大的体会是终端大模型不是“替代 GUI 工具”的方案而是“补齐终端生态短板”的方案。过去你在终端里查资料、查文档、处理文本总感觉缺一个能理解语义的助手。现在 LLM CLI 把这一块补上了而且补得很完整。我个人现在最常用的组合是WSL2 tmux Ollama Yazi VS Code 终端。每天早上打开电脑一个终端窗口就成了我的“数字助理桌”。写邮件、改代码、分析数据、翻译文档全都命令行解决。有明显的提升感也有明显的学习成本。如果你想把大模型真正变成日常工具我建议别一上来就搞高深术语先用最简单的 Ollama run 和模型聊五分钟然后慢慢把管道、脚本、复用器加进来。要相信终端这扇门一旦推开能玩出的花样远超你原本的想象。