Linux 6.18 进入长期维护，llama.cpp 开始向统一 llama 工具链收敛，Ollama 和 Gemini CLI 则把本地模型与 Agent 直接搬进终端。AI 基础设施正在从“装一堆依赖”变成“跑几条命令”。
/ / /
开篇
最近看 Linux 和 AI 的新闻，有一个感觉越来越明显。
大家讨论的重点，已经不只是某个模型又大了多少、某张卡又快了多少，而是这些东西能不能真的进入一台普通 Linux 机器，能不能被脚本调用，能不能在内网里跑，能不能让运维同学接得住。
这事儿挺关键。
因为 AI 真正进入生产环境，最后总要经过几个很朴素的考验，二进制能不能装，服务能不能起，日志能不能看，模型能不能换，出问题之后有没有地方查。
从 2025 年底到 2026 年这段时间，Linux 与 AI 的变化，恰好都在往这几个问题上靠近。
/ / /
Linux 6.18，AI 服务器更需要一个稳定的底座
Linux 6.18 在 2025 年 11 月 30 日进入长期维护序列，官方计划维护到 2028 年 12 月。
这个消息看起来没那么热闹。没有新模型，没有榜单，也没有一句“性能提升 300%”。但对真正跑服务的人来说，长期维护内核往往比发布会上的数字更重要。
一台 AI 服务器，通常不是只跑一个推理进程。它可能同时挂着容器、监控、网络存储、GPU 驱动、模型缓存和一堆内部工具。内核每周换一次，驱动和容器运行时跟着抖一下，最后排查的人就会发现，问题不是出在模型，而是出在“昨天还好好的那台机器”。
Linux 6.18 的价值，更多是给这条底层链路提供一个相对稳定的时间窗口。官方 v6.x 目录显示，6.18 系列在 2026 年持续进行稳定更新，7 月仍有 6.18.40 这样的版本发布。
这不是让所有机器今天就升级到 6.18。
我的建议很简单，生产环境先确认发行版自己的内核支持周期，再把 6.18 当成新的观察对象。测试环境可以提前验证 GPU 驱动、容器、eBPF 监控和本地推理服务，别等到业务迁移前一天才发现某个模块没编进去。
uname -r
cat /etc/os-release
lsmod | grep -E 'nvidia|amdgpu|vfio'
这几条命令没有什么 AI 味，但它们决定了后面的 AI 能不能跑起来。
/ / /
llama.cpp 的变化，推理工具开始像 Linux 命令
过去折腾本地大模型，常见画面是这样，下载一个仓库，装一套依赖，编译，再找一个启动参数，最后服务起了，但你不太确定自己到底起的是哪一层东西。
llama.cpp 这两年的方向，越来越像是在收拾这件事。
官方仓库现在把 llama-cli、llama-server、GGUF 模型、OpenAI 兼容接口这些能力放在一条清晰的路径上。你可以直接用本地模型，也可以通过 -hf 从 Hugging Face 拉取模型，还可以启动一个兼容 OpenAI API 的服务。
llama-cli -hf ggml-org/gemma-3-1b-it-GGUF
llama-server -hf ggml-org/gemma-3-1b-it-GGUF
更值得注意的是，官方在 2026 年 5 月公布了 llama.app 和统一的 llama 二进制。目标说得很直白，让新用户更容易安装和运行 llama.cpp，把原来分散的用户工具装进一个入口里。
这其实非常 Linux。
不是把所有复杂度消灭，而是先给你一个可用的命令，再允许你继续往下钻。懂的人可以编译、调参数、看后端；只想启动服务的人，也不用先读完半个构建系统。
推理工具的下一步，不是更复杂，而是更像 Unix 工具
这会直接影响内网部署。
一个统一入口意味着镜像更容易做，健康检查更容易写，systemd 服务更容易维护，甚至可以把模型服务纳入现有的日志、限流和回滚体系。
[Service]
ExecStart=/usr/local/bin/llama-server -hf ggml-org/gemma-3-1b-it-GGUF --host 0.0.0.0 --port 8080
Restart=always
当然，这段配置只是示意。生产环境还要补上用户权限、模型目录、资源限制和网络策略。模型能启动，不等于服务能上线，这个坑每年都会换一个名字出现。
/ / /
Ollama 还在降低本地模型的启动成本
Ollama 的更新节奏也很快。官方仓库显示，v0.32.0 在 2026 年 7 月 11 日发布，README 里已经把 Kimi-K2.6、GLM-5.1、MiniMax、DeepSeek、gpt-oss、Qwen、Gemma 等模型放进了同一个入口。
它解决的不是所有问题，但解决了一个非常现实的问题，很多人不是不想试本地模型，而是不想先处理一堆构建、量化和后端选择。
ollama run qwen3
ollama list
ollama ps
本地运行的意义也在变。
以前本地模型更像实验室里的玩具，今天它越来越像一个开发依赖。写一个离线文档搜索，搭一个内网问答，给日志做初筛，或者在没有公网的环境里给代码库做索引，这些事情不一定需要一个巨大的云端模型。
但这里要泼一点冷水。
本地不等于安全。模型目录里的文件、HTTP 接口的监听地址、日志里的 prompt、运行进程的权限，这些都需要按普通服务的标准来管。把 0.0.0.0 写进启动参数之前，先想清楚谁能访问。
ss -lntp | grep -E '11434|8080'
ps aux | grep -E 'ollama|llama-server'
这一步很无聊，但 AI 系统最常见的事故，往往就是一个本来只想本机访问的服务，被顺手暴露到了整个网段。
/ / /
Gemini CLI，终端开始变成 Agent 的工作台
Google 在 2025 年 6 月发布了开源的 Gemini CLI。它把 Gemini 放进终端，支持代码理解、文件操作、命令执行、搜索、MCP 扩展，也支持非交互模式，能够被脚本调用。
这条新闻和 Linux 的关系，比“某个模型能不能在 Linux 上跑”更有意思。
因为终端本来就是 Linux 最稳定的工作界面。过去我们把命令写进 shell，把部署写进 Ansible，把排障写进 runbook。现在开始有人尝试把这些东西交给一个 Agent，让它读仓库、查日志、执行命令，再把结果串起来。
gemini
gemini --prompt "检查当前目录的 systemd 服务配置，只读分析，不执行修改"
这个方向真正需要警惕的，不是 Agent 会不会写错一行代码，而是它有没有权限把错误扩散出去。
给 Agent 一个只读账号，和给它 root，完全是两种产品。让它能看日志，不代表让它能删日志；让它能生成命令，不代表让它自动执行命令；让它能改测试分支，不代表让它能碰生产主机。
在 Linux 环境里，权限、沙箱、网络出口、命令审计这些老问题，会重新变成 AI 产品的核心问题。
这也是我觉得这波变化最有价值的地方。
AI 没有把 Linux 的工程经验抹平，反而把这些经验重新推到了台前。谁熟悉进程、文件权限、服务管理、网络隔离，谁就更容易把 Agent 用得稳一点。
/ / /
这几条动态放在一起，说明了什么
Linux 6.18 在提供更长的底座周期。
llama.cpp 和 llama.app 在把本地推理工具做得更像系统命令。
Ollama 在把模型启动成本压低，让本地推理更像开发环境的一部分。
Gemini CLI 则把终端本身变成 Agent 可以工作的地方。
它们不是同一个项目，也没有一份统一路线图，但方向很一致，AI 正在从一个需要专门平台承载的“模型服务”，变成 Linux 机器里可以被安装、调用、编排、限制和审计的一类普通能力。
这对运维同学和开发者都提出了一个新要求。
以后搭 AI 环境，不能只问模型效果，也要问它的启动方式、进程权限、网络边界、缓存位置、升级策略和回滚路径。
模型会换，工具会换，甚至硬件也会换。能留下来的，还是那些朴素的工程能力。
Linux 之所以一直在，不是因为它每次都最漂亮，而是因为它允许你把系统拆开，看清楚，再接回去。
AI 现在正在学这件事。
如果你准备在 Linux 上试本地模型，可以先从一台普通机器开始，记录内核版本，选一个明确的推理入口，给服务加上最小权限，再把模型当成服务而不是魔法。等你能稳定地启动、监控和停止它，再谈更大的模型和更复杂的 Agent。
这样比较踏实。
如果这篇文章对你有帮助，欢迎点个赞、在看、转发，来一组三连。也欢迎关注并支持 Linux云技术栈，后面继续聊 Linux、云原生和 AI 工程实践。
资料来源
- -Linux kernel active releases
-
- -Linux kernel v6.x stable releases
-
- -ggml-org/llama.cpp
-
- -llama.app announcement
-
- -ollama/ollama
-
- -Google Gemini CLI announcement
