<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>ollama on </title>
    <link>/tags/ollama/</link>
    <description>Recent content in ollama on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Fri, 10 Apr 2026 09:00:00 +0800</lastBuildDate><atom:link href="/tags/ollama/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Codex CLI 对接远程 Ollama</title>
      <link>/posts/codex-cli-remote-ollama/</link>
      <pubDate>Fri, 10 Apr 2026 09:00:00 +0800</pubDate>
      
      <guid>/posts/codex-cli-remote-ollama/</guid>
      <description>最近开始尝试用 AI agent 来帮我处理一些相对明确的自动化分析和整理任务。论模型能力，GitHub Copilot 免费提供的 GPT-5 mini 可能比我本地部署的模型更强，但它有速率限制，跑多了就被限。本地模型的好处在于不受限制，而且可以自己调整参数和提示词来适应具体的需求场景。
我的 Homelab 服务器上正好跑着 Ollama，于是就想能不能让本地的 Codex CLI 直接用远程服务器的模型来干活。试了一圈后找到了可行的配置方式，这里记录一下。
整体架构 本地 MacBook (Codex CLI) │ │ Tailscale 虚拟局域网 │ http://100.x.x.x:11434/v1 ▼ 远程 Homelab (Ollama) │ ├── qwen3.5:latest (日常编码) ├── gemma4:26b (深度推理) └── gemma4:31b (复杂架构设计) Tailscale 负责打通网络，Ollama 提供 OpenAI 兼容 API，Codex CLI 通过自定义 Provider 接入远程模型。请求流量都留在 Tailnet 内，至少不需要经过公网转发。
远程服务器：Ollama 配置 1. 允许监听所有网卡 Ollama 默认只监听 127.0.0.1，如果你想让它接受来自 Tailscale 网卡的请求，通常要改为监听 0.0.0.0。
如果你用 systemd 管理 Ollama，创建 override 配置：
sudo systemctl edit ollama.</description>
    </item>
    
    <item>
      <title>MLX vs Ollama(GGUF)：M2 MBP 32GB 上的性能基准测试</title>
      <link>/posts/mlx-vs-ollama-benchmark-on-m2-mbp/</link>
      <pubDate>Sat, 14 Mar 2026 15:00:00 +0800</pubDate>
      
      <guid>/posts/mlx-vs-ollama-benchmark-on-m2-mbp/</guid>
      <description>Apple Silicon 的统一内存架构让本地运行大模型成为可能，而在 macOS 上，目前主要有两条路：通用方案 Ollama（基于 llama.cpp），以及 Apple 官方为 Apple Silicon 定制的 MLX 框架。
这篇文章记录我在 M2 MacBook Pro (32GB) 上的实测过程，重点回答一个问题：在日常使用中，MLX 到底比 Ollama 快多少？值不值得切换？
测试环境与方法 硬件: M2 MacBook Pro，32GB 统一内存 系统: macOS（后台无其他 GPU 密集型任务） 测试 Prompt: 固定同一段中文提问，限制输出 128 tokens 重复次数: 每组跑 3 次取平均，排除冷启动影响 引擎 模型 量化格式 Ollama qwen3.5:latest GGUF Q4_K_M MLX mlx-community/Qwen3.5-9B-MLX-4bit MLX 4-bit 两者均使用 Qwen3.5 9B，量化精度对齐为 4-bit，尽量排除模型本身的变量。
MLX 与 GGUF：两种格式的本质差异 理解这两种格式的区别，有助于解释为什么它们的性能表现不同。
GGUF（llama.cpp 使用的格式）是一种跨平台的模型格式，设计目标是兼容性：同一个文件可以在 CPU、NVIDIA GPU、AMD GPU、Apple Silicon 上运行。Ollama 底层就是 llama.cpp，通过 Apple 的 Metal API 调用 GPU，但这层抽象有额外的调度开销。</description>
    </item>
    
    <item>
      <title>Spring AI 2.0.0-M2 的 Ollama think 字段问题：排查过程与 Interceptor 临时方案</title>
      <link>/posts/spring-ai-ollama-think-field-bug/</link>
      <pubDate>Fri, 06 Mar 2026 01:00:00 +0800</pubDate>
      
      <guid>/posts/spring-ai-ollama-think-field-bug/</guid>
      <description>背景 在开发新加坡小学数学 AI 辅导 App 时，我使用 Ollama 本地运行 qwen3.5:2b 模型。qwen3.5 是 thinking-capable 模型，Ollama 0.12+ 默认开启 thinking 模式，会先在 thinking 字段输出推理过程，再在 content 字段输出最终答案。
我当时遇到的问题是：thinking 模式下推理耗时从 ~16s 增加到 ~52s（约 3x），而且对当时那组 PSLE 小学数学题来说，我并不需要这么长的推理链路，所以想先把 thinking 关掉。
现象 使用 Spring AI 2.0.0-M2 提供的 API 关闭 thinking：
ChatClient.prompt() .system(systemPrompt) .user(userMessage) .options(OllamaChatOptions.builder().disableThinking().build()) .call() .content(); Ollama 返回 HTTP 400：
think must be a boolean or string (&amp;#34;high&amp;#34;, &amp;#34;medium&amp;#34;, &amp;#34;low&amp;#34;, true, or false) 根因分析 抓取 Spring AI 发往 Ollama 的请求体，发现 think 字段出现在了两个位置：</description>
    </item>
    
  </channel>
</rss>
