你八成也犯过这个错。装好 Ollama，拉下一个模型，一跑发现回答到一半就断了，或者长文档喂进去它前面说的话全忘了。查了半天代码逻辑，最后发现问题就一个：Ollama 默认上下文长度是 4096 token。不到 4K，一份长一点的技术文档还没读完就被截断了。
这不是个例，是几乎每个新用户都会踩的第一个坑。而它也只是本地部署里最浅的一层。真正决定你能不能把 Kimi-K2.6 或 GLM-5.2 用起来的，是显存和量化档位的精打细算，是环境变量的正确写法，还有一个大多数教程都没讲清楚的事实：这两个模型在 Ollama 里根本不是让你下载到本地跑的。
Ollama 的 GitHub 仓库简介写得很直白：“Get up and running with Kimi-K2.6, GLM-5.2, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models”。截至目前项目已经积累约 178K GitHub Star，最新版本是 2026 年 8 月 4 日发布的 v0.32.6。
先把这件事说清楚，免得你装到一半发现不对劲：Kimi-K2.6 在 Ollama 库里只有一个 tag，kimi-k2.6:cloud，256K 上下文；GLM-5.2 同样只有 glm-5.2:cloud 一个 tag，976K 上下文。两个都没有本地量化权重可下。原因很简单，这两个模型的参数规模（GLM-5.2 原始参数量高达 744B）远超个人设备能承受的范围，Ollama 干脆把它们做成云端代理，命令行体验和本地模型一模一样，实际推理跑在 Ollama 的服务器上。
这不是坏消息，反而是这篇文章真正的价值所在：搞清楚 Ollama 生态里哪些模型能真本地跑、哪些只能云端代理、怎么在两者之间无缝切换，比闭着眼睛跟着某个"一键部署"教程走要靠谱得多。
一、先算账：显存/内存 与 量化档 对照表
本地部署的第一步不是敲命令，是算账。你的显存或统一内存，决定了能碰哪个量化档，量化档又反过来决定输出质量的上限。经验公式很简单：模型体积（GB）应控制在可用显存/内存的 80% 以内，留出给上下文缓存和系统进程的余量。
| 可用显存/内存 | 能扛住的量化档位 | 参考模型 | 备注 |
|---|---|---|---|
| 8GB | Q4 量化，7B~9B 级 | qwen3.5:9b-q8_0 约 11GB（勉强，建议再降一档） | 消费级显卡起步线 |
| 16GB | Q4/Q8 混用，20B 级 MoE | gpt-oss:20b（MXFP4 原生格式，官方标注 16GB 内存可跑，128K 上下文） | 苹果笔记本统一内存也算这一档 |
| 24GB | Q4_K_M，27B~30B 级 | qwen3-coder:30b（MoE，3.3B 激活参数，Q4_K_M 约 19GB） | MoE 模型激活参数量比总参数量更重要 |
| 32GB | Q8_0，27B 级 dense | qwen3.6:27b（约 17GB，256K 上下文） | 苹果芯片在这一档触发 MLX 默认加速 |
| 64GB | Q8_0，35B 级 MoE 常驻 | qwen3.6:35b-a3b-q8_0（MoE，3B 激活参数） | 可以同时常驻一个写作模型 + 一个 embedding 模型 |
| 128GB | 顶配 MoE，百亿参数级 | 通用主力档模型（80GB 级 MoE，仅 Q4_K_M 量化可选） | 顶配 Apple Silicon 才够格 |
| 不装本地，走云端 | 无本地占用 | kimi-k2.6:cloud / glm-5.2:cloud | 需要 ollama signin，按 GPU 时长计费，非按 token |
有个反直觉的地方值得记住：MoE（混合专家）模型的解码速度看的是激活参数量，不是总参数量。一个 30B 总参数但只激活 3B 的模型，跑起来比同等体积的 dense 模型快得多，因为每个 token 只需要读取那一小部分权重。选型时先看"激活参数"这一栏，别只盯着模型名字里的大数字。
量化档位怎么选也有讲究。Q4_K_M 是目前公认的性价比甜点，质量、速度、显存占用三者平衡得最好；如果你的设备内存宽裕（比如 64GB 以上），直接上 Q8_0，把量化损失降到最低，反正内存基本是"免费"的；只有在显存实在紧张、Q4 都装不下的时候，才考虑更激进的量化档，同时要有心理准备，输出质量会明显打折。
二、装与配：关键环境变量逐个讲
Ollama 的默认配置是为"能跑起来"优化的，不是为"跑得好"优化的。装完之后有几个环境变量必须手动调整，不然你会一直在默认值的坑里打转。
先装：
# macOS
brew install ollama
# 或者官方脚本（Linux/macOS 通用）
curl -fsSL https://ollama.com/install.sh | sh
# 验证版本
ollama --version
上下文长度：最容易被忽略的默认值
前面提过，Ollama 默认上下文只有 4096 token。不改这个值，所有没有在请求里显式带 num_ctx 参数的调用，都会被裁到这个长度。改法有两种：
# 方式一：全局环境变量（适用于 systemd 服务或 launchd）
launchctl setenv OLLAMA_CONTEXT_LENGTH 32768
# 方式二：单次调用时指定
ollama run qwen3.6:27b --verbose
/set parameter num_ctx 32768
或者在 API 请求里带上：
curl http://localhost:11434/api/generate -d '{
"model": "qwen3.6:27b",
"prompt": "总结这份文档",
"options": { "num_ctx": 32768 }
}'
有个优先级关系容易搞混：如果模型的 Modelfile 里用
PARAMETER num_ctx写死了一个值，这个值会覆盖你设置的全局环境变量。也就是说，改了环境变量却发现没生效，先去检查这个模型是不是自带了 Modelfile 层面的硬编码上下文。
模型常驻与并发加载
# 常驻时长，避免每次调用都冷启动
export OLLAMA_KEEP_ALIVE=2h
# 同时加载几个模型（显存/内存够用再开）
export OLLAMA_MAX_LOADED_MODELS=3
OLLAMA_KEEP_ALIVE 设太短，每次对话都要重新加载模型，浪费好几秒到几十秒；设太长又占着内存不释放。24GB 以上的机器可以放心设到 1-2 小时，甚至常年常驻。
云端模型的登录方式
如果你要用 Kimi-K2.6 或 GLM-5.2 这类只有 :cloud tag 的模型，流程和本地模型完全不同，多一步登录：
# 命令行登录，走浏览器 OAuth
ollama signin
# 或者用 API key（在 ollama.com 账号设置里生成）
export OLLAMA_API_KEY=你的key
# 命令行体验和本地模型一模一样
ollama run kimi-k2.6:cloud
ollama run glm-5.2:cloud
计费方式也不一样，云端模型是按 GPU 占用时长计费，不是按 token 数，官方提供免费、Pro、Max 三档订阅，免费额度没有公开具体的速率限制。
Apple Silicon 的 MLX 加速
如果你在 M 系列芯片上跑本地模型，Ollama 从 v0.30（2026 年 5 月 13 日发布）起默认启用 MLX 引擎替代原来的 Metal 路径，但有一个硬门槛：统一内存必须达到 32GB 以上，低于这个数会自动回退到 Metal。MLX 官方基准测出的是约 2 倍解码速度提升，不需要手动开关，只要设备达标、Ollama 版本够新就自动生效。
三、三个模型实跑对比与适用场景
拿三个真实能拿到手的选项做对比，一个云端，两个本地，让你看清楚"能用"和"值得用"之间的区别。
| 模型 | 部署方式 | 上下文 | 许可协议 | 适合场景 |
|---|---|---|---|---|
| Kimi-K2.6 | 云端代理（:cloud） | 256K | Modified MIT，超过 1 亿月活或每月 2000 万美元营收需在界面显著标注"Kimi K2.6" | 长文档理解、多模态任务，不想自己扛硬件 |
| GLM-5.2 | 云端代理（:cloud） | 976K | 标准 MIT，商用无附加条款 | 超长上下文的编码/长任务，团队内部工具集成 |
| gpt-oss:20b | 本地，MXFP4 原生量化 | 128K | Apache 2.0 | 16GB 内存机器上的真本地部署，离线场景首选 |
三个模型分别代表了三种典型需求：
Kimi-K2.6，你要的是"不用自己管硬件也能用上顶级模型"。它是原生多模态、面向长周期编码和自主任务编排设计的模型，256K 上下文足够塞进一个中等规模的代码库。但因为走云端，你的 prompt 和输出都会经过 Ollama 的服务器，涉密内容不建议走这条路。
GLM-5.2，如果你的任务需要"读一份特别长的东西再给结论"，比如一整本书、几十份合同、一个巨型代码仓库的全量上下文，976K 的窗口是目前 Ollama 生态里少见的量级。同样是云端代理，同样不适合处理敏感数据。许可协议上它比 Kimi-K2.6 更干净，纯 MIT，没有月活或营收门槛的附加条款，如果你打算把它包进一个商业产品，这点值得记一笔。
gpt-oss:20b，这才是"本地跑"三个字真正对应的体验。MXFP4 是它的原生量化格式，不是事后压缩出来的，官方标注 16GB 内存的机器就能带得动，128K 上下文对日常写代码、写文档已经够用。完全离线，数据不出本机，这是它相对两个云端选项最大的优势。
# 本地跑 gpt-oss，完全离线
ollama pull gpt-oss:20b
ollama run gpt-oss:20b
# 云端跑 Kimi-K2.6，需要先登录
ollama signin
ollama run kimi-k2.6:cloud
想要更大规模的真本地模型，Qwen 系列是目前 Ollama 库里覆盖档位最全的一条线，从几亿参数的小模型一路铺到百亿参数级的 MoE，qwen3-coder:30b（MoE，3.3B 激活参数，Q4_K_M 约 19GB）和 qwen3.6:27b（约 17GB，256K 上下文）是编程和写作场景里性价比比较高的两档，具体选哪个看你的显存预算落在前面那张对照表的哪一格。
四、常见踩坑
坑一：默认上下文 4096，长任务无声截断
前面反复提到的这个坑，之所以列进这里再强调一遍，是因为它的表现不是报错，是安静地丢失信息。模型不会告诉你"我把你的输入砍掉了一半"，它只会给出一个基于不完整上下文的、看起来还算合理的回答。你以为它理解错了，其实是它压根没读到。任何涉及长文档、多轮对话、代码库分析的任务，第一件事就是确认 OLLAMA_CONTEXT_LENGTH 或 num_ctx 有没有设对。
坑二：多模型同时常驻，内存被悄悄吃光
OLLAMA_MAX_LOADED_MODELS 设得太随意，本地跑一个写作模型、一个编程模型、再加一个 embedding 模型，三个一起常驻，很容易在你没意识到的时候把内存吃满，导致系统开始交换分页，所有模型一起变慢。开多模型常驻前，先手算一遍：三个模型的体积加起来，是不是还留有给系统和上下文缓存的余量。
坑三：换 embedding 模型，忘记重建索引
如果你用本地模型搭了检索增强的知识库，换 embedding 模型这件事不能想换就换。不同 embedding 模型输出的向量维度和语义空间不一样，换了模型不重建索引，旧的向量和新的查询根本不在一个坐标系里，检索结果会变得莫名其妙地差，而且不会报错，只会"看起来能用但结果很烂"。正确顺序是先让新旧模型并存一段时间，重建索引并验证检索质量，确认没问题了再删掉旧模型。
坑四：以为装了 MLX 就自动生效
改完 launchd 配置文件或环境变量，很多人以为写了就等于生效了，实际上环境变量残留、版本没升级到位、统一内存卡在 32GB 门槛以下这几种情况都会让 MLX 静默失败，回退到老的 Metal 路径，速度慢了你也未必能第一时间察觉。改完配置之后，养成用 launchctl getenv 或对应平台的命令核实一遍生效状态的习惯，别只信规则文件里写的数字。
写在最后
本地部署这件事的门槛，已经从"能不能跑起来"变成了"参数有没有调对"。多数人卡住的地方从来不是硬件不够，是默认的 4096 上下文、随手设置的常驻模型数量、换了 embedding 却没重建索引这些细节，一步都不复杂，但每一步都得知道去哪里改。
Kimi-K2.6 和 GLM-5.2 这两个当下最受关注的模型，在 Ollama 里走的是云端代理路线，用的是本地命令行的壳，跑的是别人的显卡。这不算缺点，只是需要你提前知道，好让涉密数据别往那条路上送。真要完全离线、数据不出本机，gpt-oss、Qwen 系列这些有真实本地权重的模型，才是这篇指南真正要交给你的答案。
部署之前先算账：你的显存/内存决定量化档位，量化档位决定模型质量的上限。别等装完了才发现根本带不动。
延伸阅读可以看看 Ollama 官方仓库 和 模型库首页，两个页面的 tag 列表是判断一个模型到底能不能真本地跑的最快方式。