Mac本地LLM最终选了oMLX，顺带优化Codex和Claude Code卡死表现

原文链接：https://mp.weixin.qq.com/s/ynWj2dP_71QHMOeI-LEe6w

MacBook Pro 到手后，我一直在研究各种本地模型LLM和部署平台。我对效率的要求比较高。

MacBook Pro 到手后，我一直在研究各种本地模型LLM和部署平台。我对效率的要求比较高。模型都能跑，但推理速度能差出一个量级。网上的测评文章也不是没有，但大多数只对比了两三个平台就下结论了。实际能用来本地部署模型的引擎，比那些文章列的要多得多。后来我就自己一个个试，试了绝大部分。要把每个平台的效果都截出来或者做成口播视频，那篇幅就太长了，所以这里先把结论摆出来，今天重点讲 oMLX。这篇文章很长，因为涉及到本地模型部署平台的选择、模型功能及参数设置、Codex和Claude Code卡死优化方案，都挺有用的，建议慢慢看。着急也可以按需看。

市面上的 Mac 本地模型平台，先过一遍

下面这张表是我整理的主流平台对比，平台、定位和适用场景放在一起看，比单独讲哪个更快更有意义。

主流 GUI / 一站式平台

Ollama：轻量级命令行加 REST API 的本地 LLM 运行工具。一键安装和模型拉取（ollama run），模型管理极简，社区生态最庞大，原生支持 Apple Silicon（Metal + MLX 后端），后台服务稳定。适合开发者日常使用、快速搭建本地模型、脚本调用、构建 AI 应用、团队共享模型。API 支持 OpenAI 兼容（最广泛）。

LM Studio：桌面端可视化本地 LLM 管理与聊天工具。界面最友好，模型发现和一键下载体验优秀，同时支持 GGUF 和 MLX 格式，内置本地服务器，适合非技术用户。适合新手入门、本地模型探索、可视化聊天、日常办公和学习使用。API 支持 OpenAI 兼容（本地服务器模式）。

Jan.ai：开源的本地优先桌面 AI 聊天应用。类似 ChatGPT 的完整桌面体验，隐私优先，全本地运行，支持多种后端。适合追求 ChatGPT 式体验的用户、需要离线完整聊天界面的场景。API 支持 OpenAI 兼容。

GPT4All：开源本地 LLM 运行与聊天工具。安装简单，支持多种模型格式，跨平台，轻量。适合入门级用户、追求极简本地 AI 的场景。API 支持有限（主要通过界面）。

Open WebUI：浏览器端的美观聊天界面，通常搭配 Ollama 等后端使用。UI 现代美观，支持 RAG 文档聊天，多用户支持，功能丰富（知识库、工具等）。适合需要 Web 风格聊天界面、文档问答、团队或多设备使用。API 支持通过后端提供 OpenAI 兼容。

Apple 官方及 MLX 生态

MLX / mlx-lm：苹果官方专为 Apple Silicon 优化的数组计算框架加 LLM 推理包。原生统一内存架构优化，性能基准领先（尤其是预填充），支持原生 LoRA 微调，Python/Swift/C++多语言支持。适合开发者进行自定义推理、模型微调、研究实验、追求极致原生性能。mlx_lm.server 可提供 OpenAI 兼容。

oMLX：基于 MLX 的本地 LLM 推理服务器，带原生 macOS 菜单栏 App 加 Web 面板。Paged SSD KV 缓存（热 RAM + 冷 SSD，可跨重启持久化），连续批处理，专为 Agent 设计（重复前缀 TTFT 可降至1-5秒），多模型同时 serving。适合重度 Coding Agent（Claude Code、Cursor、OpenClaw 等）、长上下文多轮编辑、需要稳定高性能本地后端的专业用户。API 支持 OpenAI 兼容加 Anthropic Messages 兼容。

Rapid-MLX：高速 MLX 原生 OpenAI 兼容服务器。比 Ollama 快2-4倍，优秀 tool calling 支持，prompt cache，推理分离，安装简单。适合需要极致响应速度的 Agent 工作流、Cline/Cursor 等工具的用户。API 支持 OpenAI 兼容。

vLLM-MLX / vLLM-Metal：vLLM 风格的高吞吐推理服务器（MLX 后端）。连续批处理能力强，高并发吞吐优秀，PagedAttention 风格优化。适合多用户并发 serving、高负载生产环境、需要 vLLM 生态的用户。API 支持 OpenAI 兼容。

mlx-vlm：MLX 框架下的视觉语言模型支持包。原生支持图像、视频等多模态输入，与 MLX 生态无缝集成。适合多模态应用（图像理解、VLM Agent 等）。通过对应 server 提供 API。

底层推理引擎

llama.cpp：高性能 C++本地推理引擎。GGUF 生态最丰富，Metal 加速成熟，层卸载灵活，控制粒度极细。适合极致性能调优、嵌入式部署、需要 GGUF 模型的用户、各种硬件适配。通过 server 模式提供 API。

MLC-LLM：跨平台机器学习编译 LLM 框架。编译优化效果好，多硬件支持（包括 Apple Silicon）。适合移动端/嵌入式场景、需要编译优化的部署。API 支持相对有限。

其他值得一提的

Continue.dev：VS Code / JetBrains 的开源 AI Coding 扩展。IDE 深度集成，支持 Chat、Edit、Agent 多种模式，本地模型支持优秀。适合代码补全、文件编辑、Coding Agent 工作流。通过本地后端（Ollama、LM Studio、oMLX 等）提供 API。

Aider：命令行 Coding Agent 工具。直接在终端操作代码库，Git 自动集成，支持多文件编辑和重构。适合喜欢在终端完成 coding 任务的用户、强工程化 workflow。通过本地 LLM（Ollama 等）提供 API。

LM Studio llmster：LM Studio 的无 GUI 核心服务端模式。保留 LM Studio 的模型能力和服务器功能，轻量部署。适合需要无界面服务器部署、结合其他工具使用。API 支持 OpenAI 兼容。

mlxcel：Rust 原生 MLX 推理引擎。轻量、高性能潜力，Rust 生态优势。适合追求极致轻量和性能的开发者。通过扩展提供 API。

以上这些里面，我最看重的两个是 oMLX 和 LM Studio。LM Studio 上一篇文章已经详细写过了，它适合小白，图形化界面设计得非常清晰明了，简单易懂，而且支持 MLX，速度也很快。vLLM-MLX 值得企业用户部署，团队使用更合适。今天重点讲 oMLX。

oMLX 到底强在哪

oMLX 是一个基于 Apple 原生 MLX 框架的开源 LLM 推理服务器，专为 Mac 优化。它提供原生 macOS 菜单栏 App、Web 管理面板、OpenAI/Anthropic 兼容 API，支持连续批处理（continuous batching）和分页 SSD KV 缓存（两级缓存：热 RAM + 冷 SSD）。

先看一眼服务统计面板，能直观看到运行状态和缓存效率：

核心优势在于：普通 MLX 或其他工具在上下文变化时（coding agent 很常见）会频繁失效 KV 缓存，导致重新计算前缀，TTFT 可能飙到30-90秒。oMLX 把 KV 块持久化到 SSD，下次相同前缀直接从磁盘恢复，TTFT 能降到1-5秒，甚至跨重启有效。

再看性能对比（基于公开基准和用户测试）：

基础 MLX 和 oMLX 的纯生成速度（tokens/s）接近，但 oMLX 在预填充（prefill/TTFT）和 agent 场景下大幅领先，可达4-5.7倍预填充加速。对比 Ollama 和 LM Studio：oMLX 预填充速度可达4倍快，生成速度1.3-1.5倍快，整体 TTFT 有2.5倍以上的提升，尤其在 M5/M4等高配 Mac 上更明显。连续批处理还能带来2-4倍吞吐提升。

（M3/M4/M5 Mac 上）：大模型（如30B+ MoE/4bit）agent 工作流中，oMLX 让“不可用”变成“生产可用”。连续批处理下4-8个并发请求时，生成吞吐可提升2-4倍。SSD 缓存让长上下文 coding 不再卡顿。在 NVIDIA GPU 上，vLLM/TensorRT-LLM 等可能更快，但在 Mac 上，oMLX 加 MLX 是当前最优解之一。

接下来是 oMLX 的 Integrations 集成页面，这里可以直接把 Claude Code、Codex、OpenCode 等工具接到本地模型上：

逐个页面看看都有什么功能

篇幅比较大，不想看细节的可以直接往下滑到“重点设置”那部分。

首先是主界面仪表盘——网络与默认参数：

Listen Address（监听地址）：oMLX 默认只监听127.0.0.1（本地回环地址），只能在本机访问。这能最大程度保证隐私安全，不会让局域网其他设备轻易连接。如果需要其他设备也能访问，可以在这里修改为0.0.0.0。

Port（端口）：默认8000。这是 oMLX 提供 OpenAI 兼容 API 的端口。启动后可以用 http://127.0.0.1:8000/v1 来接入 Continue.dev、Cursor、Claude Code 等工具。端口支持自定义，避免和其他服务冲突。

OpenAI-compatible（OpenAI 兼容端点）：最常用的 API 地址 http://127.0.0.1:8000/v1。几乎所有支持 OpenAI 格式的工具（LM Studio、Continue.dev、Aider、PyCharm AI 等）都可以直接使用这个地址，让本地模型以 OpenAI 格式对外服务。

Anthropic / Claude Code（Anthropic 兼容端点）：http://127.0.0.1:8000。专门为 Claude Code、Cursor、Cline 等偏好 Anthropic Messages API 的工具准备。oMLX 原生支持 Claude 风格的对话格式，在 Mac 上获得接近官方 Claude 的 Agent 体验。

Health probe（健康检查端点）：http://127.0.0.1:8000/health。用于检查服务器是否正常运行，很多自动化脚本或 Agent 框架会定期调用这个地址确认服务状态。

Metrics (Prometheus)（指标监控端点）：http://127.0.0.1:8000/metrics。输出 Prometheus 格式的监控数据，包括请求数、Token 吞吐量、延迟等。适合进阶用户搭建监控面板，实时观察模型运行情况。

Context Window（上下文窗口）：默认32768 tokens。这是服务器全局的最大上下文长度（提示词加生成内容总和），支持32K 的模型可以充分利用这个窗口，适合长文档分析和复杂 Coding Agent 任务。

Max Tokens（最大生成 Token 数）：默认也是32768 tokens。限制单次回复最多生成多少内容，防止模型输出过长导致卡顿或消耗过多资源。

Temperature（温度）：默认1.0。控制生成内容的随机性。数值越低输出越确定（适合写代码），数值越高创意越强（适合脑暴、写作）。

Top P（核采样）：默认0.95。与 Temperature 配合使用的采样参数，只从累计概率达到95%的 Token 集合中采样，平衡多样性和质量。

Top K（Top K 采样）：默认0（关闭）。如果设置为大于0的值，则只从概率最高的 K 个 Token 中选择。0表示不限制。

Repetition Penalty（重复惩罚）：默认1.0（不惩罚）。大于1时会惩罚模型重复生成相同内容，有效减少“循环输出”的问题，尤其在 Coding 场景很有用。

Automatically start server on launch（启动时自动开启服务器）：开关选项。开启后，每次打开 oMLX 菜单栏 App 就会自动启动推理服务器，省去手动点击 Start Server 的步骤，适合重度用户。

这张图主要介绍了网络设置、API 端点和默认参数配置部分。

然后是性能设置页——调度器、内存管理与 KV 缓存：

Max Concurrent Requests（最大并发请求数）：设置服务器同时能处理的请求数量，默认8。数值越高，服务器能同时响应越多工具（如 Continue.dev 加 Cursor 加浏览器同时调用）的请求。但数值太高会消耗更多内存，建议根据 Mac 内存大小合理调整，64GB 以上推荐8-16。

Embedding Batch Size（嵌入批处理大小）：用于 Embedding（向量生成）任务时一次最多处理的文本数量，默认32。主要影响 RAG（文档检索）和知识库相关功能的速度，数值越大处理批量文档越快，但会占用更多统一内存。

Chunked Prefill（分块预填充）：开启后会把超长的 Prompt 拆分成小块处理，让其他请求可以“插队”执行。这对 Coding Agent 非常友好，能显著降低长上下文场景下的首 Token 等待时间（TTFT），推荐保持开启。

Prefill Memory Guard（预填充内存保护）：在预填充阶段提前检查内存使用情况，避免内存爆满导致崩溃。开启后系统会更保守地调度生成任务，适合内存较紧张的 Mac（如32GB/48GB）用户。

Memory Guard Tier（内存保护等级）：默认 Balanced（均衡）。用于平衡吞吐量和内存安全，有不同档位可选。内存充足时可以调高以获得更好性能，内存紧张时调低更安全。

Idle Timeout（空闲超时）：服务器在空闲多少秒后自动卸载模型释放内存。设置为 off 表示不自动卸载（推荐重度用户）。最小值为60秒，适合不想每次切换模型都重新加载的用户。

Model Fallback（模型回退）：当请求的模型没有加载时，是否自动切换到当前已加载的任意模型，而不是返回404错误。适合同时使用多个工具、经常切换模型的场景，开启后使用体验更流畅。

Cache Enabled（缓存总开关）：整个 KV Cache 子系统的总开关。这是 oMLX 最核心的功能之一，必须保持开启。它决定了后面所有 SSD 分页缓存是否生效。

Hot Cache Only（仅热缓存）：开启后只使用内存缓存（Hot Cache），不把数据溢出到 SSD。适合内存极大（128GB 以上）的 Mac Studio/Ultra 用户，能获得最快速度。但普通用户建议关闭，充分利用 SSD 缓存。

Hot Cache Size（热缓存大小）：限制内存中 KV 缓存的最大容量（单位 GB）。设置为0表示不限制（推荐）。你可以填入8GB、16GB 等具体数值来精细控制。

SSD Cache Directory（SSD 缓存目录）：冷缓存（溢出到 SSD 的部分）存放的位置。默认是程序基础路径下的/cache 文件夹，可自定义到更大容量的外部 SSD。

SSD Cache Size（SSD 缓存大小）：设置 SSD 冷缓存的最大容量，默认 auto（自动）等于 SSD 容量的10%。这是 oMLX 区别于其他平台的最大亮点，能把长上下文的 KV 缓存持久化到硬盘，下次相同前缀直接从 SSD 读取，极大提升 Coding Agent 的体验。

Initial Cache Blocks（初始缓存块）：服务器启动时预先分配的缓存块数量，默认 auto（自动）。提前分配好缓存能减少启动后的首次延迟，建议保持自动即可。

这张图重点介绍了 oMLX 的调度器、内存管理和核心 KV 缓存系统，也是 oMLX 在 Mac 上性能领先的关键所在。

模型 Basic 设置——单个模型的个性化参数：

Model Alias（模型别名）：给当前模型起一个自定义的简称或昵称。默认会使用模型 ID。你可以改成更短好记的名字（如 qwen35b），后续在 Continue.dev、Cursor、Claude Code 等工具中调用时会更方便。

Model Type（模型类型）：自动检测模型架构，默认 Auto-detect。oMLX 会自动识别模型类型（Qwen、Llama、DeepSeek 等），一般不需要手动修改，只有极少数特殊模型才需要手动指定。

Context Window（上下文窗口）：设置该模型单次请求允许的最大 Token 数量（提示词加生成内容总和）。数值越高，能处理的上下文越长，适合长文档分析、复杂 Coding Agent 项目。建议根据模型实际支持的上下文长度设置（例如32K、128K 等）。

Max Tokens（最大生成 Token 数）：限制单次回复最多生成多少 Token。留空表示使用服务器默认值。可以在这里单独为这个模型设置上限，避免生成过长的内容。

Temperature（温度）：默认0.7。控制输出内容的随机性和创造性。写代码、逻辑任务建议调低到0.3-0.6；创意写作、脑暴可以调高到0.8-1.0。0表示完全确定性输出。

Top P（核采样）：核采样参数（Nucleus Sampling），默认留空（使用全局设置）。数值越接近1多样性越高，建议保持0.9-0.95，与 Temperature 配合使用效果更好。

Top K（Top K 采样）：只从概率最高的 K 个 Token 中采样。留空表示关闭（推荐）。如果想让输出更聚焦，可以设置为40或50。

Min P（最小概率阈值）：设置 Token 被采样的最低概率下限。用于进一步过滤低概率 Token，帮助提升输出质量，尤其在小模型上效果明显。

Repetition Penalty（重复惩罚）：惩罚模型重复生成相同内容的力度。数值大于1时会减少“车轱辘话”，Coding 场景非常有用，建议1.1-1.2。

Presence Penalty（存在惩罚）：惩罚那些已经在当前对话中出现过的 Token。数值越大，模型越倾向于引入新内容，适合创意写作和长对话。

TTL（空闲卸载时间）：设置这个模型在空闲多少秒后自动从内存卸载，释放内存。留空表示不自动卸载（No TTL），适合经常使用的主力模型；如果内存紧张，可以设置300-600秒。

这个页面就是 oMLX 为每个模型单独创建 Profile（配置档案）的地方。你可以为不同用途的模型设置完全不同的参数，比如一个专门写代码、一个专门聊天，非常灵活。

模型 Advanced 设置——高级与实验性功能：

Enable Thinking（启用思考模式）：开启后允许模型使用 Chain-of-Thought（思维链）推理模式。模型会在正式回答前先进行一步步的内部思考（thinking tokens），显著提升复杂推理、数学、编程等任务的准确率。Coding Agent 场景强烈建议开启。

Thinking Budget（思考预算）：限制思考模式下最多允许使用的 Token 数量。开启后可以防止思考过程过长占用过多上下文。适合需要控制资源消耗的高级用户。

Limit Tool Result Tokens（限制工具返回 Token 数）：当模型调用工具（如读取文件、执行命令）后，返回的结果过长时自动截断。防止工具输出过大的内容（如超长日志或整个代码库）把上下文挤爆，非常实用。

Force Sampling（强制采样参数）：开启后会强制使用当前页面设置的 Temperature、Top P 等采样参数，忽略请求中携带的参数。适合你想为某个模型固定风格（比如固定低温度写代码）时使用。

Reasoning Parser（推理解析器）：选择或覆盖模型的思维链解析方式。默认 auto（自动）。不同模型的思考输出格式不同，这里可以手动指定解析器，确保 oMLX 能正确识别<think>或其他思考标签。

Pin in memory（固定在内存中）：开启后这个模型会一直常驻内存，不会被 Idle Timeout 自动卸载。适合你最常用的主力模型（比如主力 Coding 模型），可以大幅减少加载等待时间。

Trust Remote Code（信任远程代码）：允许模型执行 Hugging Face 上某些模型自带的自定义代码。只有你完全信任的模型才应该开启，存在一定安全风险（Per-model only，不会继承到其他模型）。

TurboQuant KV Cache（TurboQuant KV 缓存量化）：实验性功能。在预填充阶段对 KV Cache 进行量化，能显著节省内存，但会略微牺牲一点输出质量。内存紧张时值得尝试。

SpecPrefill（Speculative Prefill）：基于注意力机制的稀疏预填充技术，特别适合 MoE（混合专家）模型和混合架构模型，能加速长上下文的预填充阶段。

DFlash（Block-diffusion Speculative Decoding）：实验性的推测解码功能，通过块扩散方式提前预测 Token。只支持单请求流（一次只能处理一个请求），适合追求极致生成速度的用户。

Native MTP（原生 Multi-Token Prediction）：启用模型原生的多 Token 预测能力（如果模型支持）。可以显著提升生成速度，但需要模型权重中包含对应的 MTP 张量。

VLM MTP（视觉语言模型 Multi-Token Prediction）：专为视觉语言模型（VLM，如支持图像的模型）提供的多 Token 预测功能，通过助手草稿机制实现。开启后图像相关任务生成速度更快。

Advanced 页面主要是给进阶用户和特定场景准备的。大多数普通用户保持默认设置即可；如果主要做 Coding Agent，重点关注 Enable Thinking、Pin in memory 和 Limit Tool Result Tokens 这三个功能即可。

Security 安全设置——API Key 与权限管理：

API Key（API 密钥）：这是访问 oMLX API 的主密钥，用于验证所有/v1接口请求和管理员操作。默认会自动生成一串随机密钥。你可以点击眼睛图标查看、刷新或复制密钥。强烈建议在生产环境或需要其他设备访问时设置并使用这个密钥，以防止未授权访问。

Disable API Key Verification（禁用 API Key 验证）：开启后，所有请求都不需要提供 API Key 即可访问（包括管理员操作）。仅推荐在本地开发、单机安全环境下使用。如果你的 Mac 会连接局域网或其他设备，务必保持关闭，否则存在安全风险。

Sub Keys（子密钥）：用于给不同应用或用户颁发范围受限的子密钥。子密钥无法获得管理员权限，只能访问指定的模型或功能。点击加号可以新建子密钥，适合你在 Continue.dev、Cursor、Claude Code、PyCharm 等多个工具中使用不同密钥进行精细权限控制，安全性更高。

安全使用小贴士：oMLX 默认只监听127.0.0.1，安全性已经比较高。但如果你修改了 Listen Address 为0.0.0.0（允许局域网访问），那么一定要设置强 API Key 并保持“Disable API Key Verification”为关闭状态。Sub Keys 功能则特别适合多工具、多人协作场景，能有效避免权限滥用。

重点设置项目

以下功能不管什么配置都建议打开：

Context Window（上下文窗口）、Max Tokens（最大生成 Token 数）、Automatically start server on launch（启动时自动开启服务器）、Chunked Prefill（分块预填充）、Cache Enabled（缓存总开关）——oMLX 最核心的功能，必须保持开启。

其他不太重要的可以忽略的配置项：

量化功能：是把本地的模型量化成更小的版本，但 oMLX 这方面做得很基础，用来微调不行。单纯的量化可以做，但其实没必要，网上基本都有已经量化好的版本。

下载器：分为 Hugging Face 和 ModelScope。Hugging Face 是全球最大最全的模型仓库，英文模型和国际社区模型更多。ModelScope（魔搭社区）是阿里巴巴达摩院和阿里云推出的中国主流开源模型社区，中文模型更全。两个都可以看一看，但到目前，国际开源模型 T0还是中国的，反正都是中国公司的模型，基本这俩仓库没多大区别。

服务统计页面可以看到消耗的 token 量，本地部署也有参考价值。当然太难的任务就别让本地模型干了，可以云端顶级模型做大脑加本地一起配合。如果你是轻度 Coding，Codex 和 Claude 20美金的基础套餐就够用了。

本地模型做 Agent，为什么经常卡

Codex 和 Claude Code 表现不佳、经常卡死的问题，可以通过调整部分参数来缓解。上面给的重点设置项目，任何配置的电脑都可以这样设置。但以下这些，得看你电脑具体的硬件配置、模型格式版本、使用场景还有 coding 工具，这些因素都影响。所以每个人设置都不一样。如果你不会设置，就别动，只把上面重点设置项目该打开的功能打开即可，保持官方默认参数最稳定。

Codex 和 Claude Code 使用本地模型卡住这件事。本地开源小模型相对于顶级闭源模型差距本来就大，Agent 调用与执行能力一般。Codex 是为 GPT 量身定做的，底层架构驱动逻辑对于其他模型是未知的，如果 OpenAI 开源设计参数，那用其他模型也能较为不错地适配。Claude Code 也是一样的道理。你们觉得能力强、很聪明、反应还快，是因为本身人家是用全世界最先进的 AI 算力卡部署的，推理效率本来就高，你就只等一个网络延迟的时间，那能不快吗？模型也确实比国产的要强，但差距说大也大，说不大也不大。主要是我们国产阵营只忙着开发更强的模型，但没有开发更强的 Agent 工具。最近已经在开发了，GLM 的工具都快和 Codex 成双胞胎了，其他公司也在跟进开发。只要我们自己开发的编程工具好用了，再本地部署对应工具同公司的开源模型，哪怕是量化版本，也会非常好用。

本地模型接入体感差，就是因为上面提到的那一堆设置，当然还有更多没提到的。工具调用和模型还有服务器端需要深度优化。比如让它把这堆数据做成表格，本地模型处理过程中有可能卡住，处理完了调度工具也有可能卡住，已经调度写入的时候也有可能卡住，做完了就差回复你“完成了”，也会卡住。随便举个例子：处理过程中模型觉得难，开启了 thinking 模式进行处理，处理不明白卡住了；处理完了 thinking 模式退不出去了，一直思考，直到思考到上下文满了为止，这是目前最常见的情况。你们自己看日志就知道了。所以有人说，我不开 thinking 模式不得了？那也行，能力下降了，没准调用的时候就出错了。模型使用命令去打开文件写入，忘了给自己写入权限了，也不吱声跟你说，就一直写，直到 token 把上下文写满。这两个例子是最简单的，应该都能看明白，实际上会因为各种问题导致非常难用。

针对本地模型卡死的优化方案

以下设置仅供参考。

针对 Codex / Claude Code 接入 oMLX 经常“卡死”（长时间无响应、TTFT 爆炸、假死）的优化建议：

这些 Agent 工具的特点是：多轮对话加频繁工具调用加动态前缀（文件树、时间戳、系统提示等），这会严重破坏普通 KV Cache，导致每次都要全量重新预填充，30到90秒很常见。oMLX 的核心优势就是它的分页 SSD KV 缓存，只要设置正确就能大幅缓解。

以下是优先级排序的调整建议，按影响大小排序：

1. CACHE（最重要，核心解决方案）

Cache Enabled：必须开启。Hot Cache Only：关闭（让数据能溢出到 SSD）。SSD Cache Size：设为 auto（推荐）或手动设置较大值，例如50-100GB 以上，取决于你的 SSD 空间。SSD Cache Directory：确保路径有足够磁盘空间，建议放在大容量 SSD 上。Initial Cache Blocks：保持 auto。

为什么有效：oMLX 会把 KV Cache 块持久化到 SSD，当 Agent 回到之前的前缀时直接从 SSD 恢复，而不是重新计算。这是解决“每次都卡30-90秒”的关键。

2. SCHEDULER（调度器）

Chunked Prefill：开启。Max Concurrent Requests：从默认8调低到4-6（如果内存紧张或经常卡死）。

为什么：Chunked Prefill 能让长 Prompt 分块处理，其他请求可以插队，显著降低 Agent 多轮时的等待时间。

3. MEMORY & LIFECYCLE（内存与生命周期）

Prefill Memory Guard：开启。Memory Guard Tier：保持 Balanced（或根据内存情况调整）。Idle Timeout：建议设为300-600秒或先设 off 测试，太短会导致模型频繁加载卸载。Model Fallback：开启（请求的模型没加载时自动用已加载的模型，避免404卡死）。

4. 模型 Advanced 设置（针对具体模型）

针对你主力 Coding 模型（如 Qwen3.6-35B 等）：Enable Thinking：开启（让模型用思维链推理，质量大幅提升）。Limit Tool Result Tokens：开启，建议值4000-8000（防止工具返回超大文件或日志把上下文撑爆）。Pin in memory：开启（主力模型常驻内存，减少加载延迟）。Reasoning Parser：保持 auto 或选对应模型的解析器。Thinking Budget：如果有，设一个合理上限，避免思考过程无限长。

5. 模型 Basic 设置（采样参数）

Context Window：不要设太高，建议32768或根据模型实际支持和你的内存调整，过高容易内存压力大。Temperature：0.3-0.7，Coding 场景偏低更稳定。Repetition Penalty：1.1-1.2，减少重复输出导致的卡循环。Max Tokens：根据需要设置合理上限，避免单次生成过长。

额外实用建议：API 端点选择上，Claude Code 优先用 Anthropic/Claude Code 端点（http://127.0.0.1:8000），比纯 OpenAI 兼容端点更匹配。模型量化方面，尽量用4-bit MLX 版本，内存占用更低，速度更快。硬件上30B 以上模型推荐64GB 以上统一内存，内存紧张时优先降低 Max Concurrent Requests 加开启 Memory Guard。监控排查方面，oMLX 后台看日志（Log Level 调高一点），开启 Metrics (Prometheus）端点观察请求情况，如果还是卡，尝试重启 oMLX 服务或清缓存目录。Claude Code 本身设置（如果有~/.claude/settings.json）：有些用户需要调整 header 相关配置，避免动态前缀频繁失效缓存。

最推荐的“救急组合”（按优先级）:Cache Enabled 加 Hot Cache Only 关闭加 SSD Cache auto、Chunked Prefill 开启、Limit Tool Result Tokens 开启加合理数值、Pin in memory 开启（主力模型）、Max Concurrent Requests 调到4-6。调整后建议重启 oMLX 服务并测试一个完整的 Agent 任务。

再次强调，默认参数最稳定，如果看不懂，打开重点设置里那些功能即可。这些参数调整后，需要你大量时间来测试。但无论怎么调，也不可能把模型调整出质的飞跃——调出更适合 Coding 还是文字内容创作或者知识库问答，这些简单的需求是可以通过调整优化表现的。如果想要大幅度提升某个场景的表现，只能进行模型微调和预训练，那就复杂了，一时半会也讲不明白，还不如直接去搜官方或者社区微调后适合的版本部署就行了。

这也是一部分优化方案：在本地模型配置里注入提示词，不是使用的时候手打，而是在模型配置平台或者通过命令设置写入提示词，告诉它在 Codex 或者你用的哪个软件中使用，注意 Agent 调用与协作。其次通过降低 Thinking Budget，Temperature 也调更小，来控制模型思考链路长度与创造思维程度。完善 Codex 的插件与技能 skill，并且在配置文件中写入必须加载完后再回答，能提高一些能力，但是首 token 输出速度会严重变慢。

这篇文章主要写参数功能上的优化，因为涉及到的内容太多，这篇能看明白就不错了。还有改善的办法就是别用Codex和Claude Code，换其他Coding工具，等下一篇写。

本文转载自微信公众号，如有侵权请联系删除。