M1 Pro跑LLM实测：Ollama+LangChain4j零成本本地大模型开发，比云端API快在哪？

本地大模型开发，听起来挺酷，但实际体验如何？今天在M1 Pro上把Ollama跑通，用LangChain4j集成GLM4和Qwen3两个模型，做了3组对比实验。结论先放这：本地9B模型开发调试完全够用，GLM4:9B比Qwen3:8B快4倍，切换模型只改一行代码。

不是玩具，是真的能用在日常开发流程里的方案。下面把安装、部署、代码、踩坑全部写清楚，最后附5道面试题。

一、Ollama安装：Homebrew有个坑

安装本身简单，一行命令：

bash 复制代码

brew install ollama

但今天踩了个坑：Homebrew装的0.30.7版本缺少llama-server二进制文件，这是实际跑模型推理的引擎。调用API直接报错：

复制代码

error starting llama-server: llama-server binary not found

解决方案是升级到0.32.5：

bash 复制代码

# 跳过auto-update，否则会卡住
HOMEBREW_NO_AUTO_UPDATE=1 brew upgrade ollama

升级后启动服务：

bash 复制代码

# 后台启动
nohup ollama serve > /tmp/ollama.log 2>&1 &

# 验证
curl http://localhost:11434/api/version
# 返回 {"version":"0.32.5"} 就OK

拉模型也简单：

bash 复制代码

ollama pull qwen3:8b    # 5.2GB，通义千问
ollama pull glm4:9b     # 5.5GB，智谱GLM4
ollama list             # 查看已安装模型

我的M1 Pro是16GB内存版本，VRAM可用10.7GB，跑9B模型毫无压力。Ollama默认设置上下文窗口4096 tokens，对开发调试足够了。

二、三个API接口：哪个跟OpenAI兼容？

Ollama暴露了三个HTTP接口，容易搞混。直接看对比：

接口	用途	请求格式	OpenAI兼容
`/api/generate`	单轮生成	`{prompt, model}`	❌ Ollama原生
`/api/chat`	多轮对话	`{messages[], model}`	❌ Ollama原生
`/v1/chat/completions`	多轮对话	完全兼容OpenAI	✅ 可直接替换

第三个接口是杀手锏。你之前写的所有调用OpenAI的代码，只需把baseUrl改成http://localhost:11434/v1，就能切到本地模型。API Key随便填，不校验。

实测三个接口：

bash 复制代码

# /api/generate -- 单轮，直接给prompt
curl http://localhost:11434/api/generate -d '{
  "model": "glm4:9b",
  "prompt": "什么是RAG？",
  "stream": false
}'

# /api/chat -- 多轮，用messages数组
curl http://localhost:11434/api/chat -d '{
  "model": "glm4:9b",
  "messages": [
    {"role": "system", "content": "你是技术顾问"},
    {"role": "user", "content": "什么是RAG？"}
  ],
  "stream": false
}'

# /v1/chat/completions -- OpenAI兼容，直接替换
curl http://localhost:11434/v1/chat/completions -d '{
  "model": "glm4:9b",
  "messages": [{"role": "user", "content": "什么是RAG？"}],
  "stream": false
}' -H "Content-Type: application/json"

流式输出也完全兼容SSE格式，stream: true返回data: {chunk}\n\n，跟OpenAI一模一样，以data: [DONE]结束。

返回结构差异要注意：

Ollama原生接口返回total_duration、load_duration、eval_count、eval_duration（性能数据更全）
OpenAI兼容接口返回usage: {prompt_tokens, completion_tokens, total_tokens}（标准格式）

实际意义：你的Java项目里用的OpenAI SDK或LangChain4j OpenAI模块，切本地模型只需要改URL和模型名。

三、LangChain4j集成：代码差异只有一行

先加Maven依赖：

xml 复制代码

<dependency>
    <groupId>dev.langchain4j</groupId>
    <artifactId>langchain4j-ollama</artifactId>
    <version>1.15.0</version>
</dependency>

然后看本地模型 vs 云端API的代码差异：

java 复制代码

// 云端API（之前的方式）
ChatModel cloudModel = OpenAiChatModel.builder()
    .baseUrl("https://open.bigmodel.cn/api/paas/v4")
    .apiKey("your-api-key")
    .modelName("glm-5.1")
    .build();

// 本地Ollama（现在的方式）
ChatModel localModel = OllamaChatModel.builder()
    .baseUrl("http://localhost:11434")
    .modelName("glm4:9b")
    .temperature(0.7)
    .timeout(Duration.ofSeconds(120))
    .build();

// 调用方式完全一样
String answer = localModel.chat("什么是RAG？");

chat()方法调用完全一致，业务代码零改动。这就是统一接口的威力。

四、实测数据：GLM4比Qwen3快4倍

跑了3组对比实验，同一问题让两个模型回答：

测试用例	Qwen3:8B	GLM4:9B	胜者
简单-情感分类	21.5s / 139字	5.0s / 44字	GLM4快4倍
中等-代码生成	43.5s / 391字	8.3s / 429字	GLM4快5倍
复杂-数学推理	59.2s / 484字	14.7s / 551字	GLM4快4倍

平均延迟：GLM4:9B = 9.3s，Qwen3:8B = 41.4s。GLM4快了4.4倍。

有意思的发现：

Qwen3过于啰嗦------简单情感分类都要写139字解释，而GLM4用44字就说明白了
两个模型数学推理都正确------F1≈0.6857，计算过程清晰
代码生成两个模型都对------二分查找算法逻辑正确
GLM4回答风格更简洁，更适合开发调试场景

这数据什么意思？本地开发用GLM4:9B，响应快、质量够用，不花一分钱API费。

五、ModelSwitcher：自动选模型

实际项目中不同任务用不同模型，写了个ModelSwitcher自动路由：

java 复制代码

// 核心思路：策略模式选模型 + 工厂模式缓存 + 装饰器模式加统计
class ModelSwitcher {
    // 1. 分类：分析输入判断任务类型
    public TaskType classify(String input) {
        if (input.contains("分类") || input.contains("翻译"))
            return TaskType.SIMPLE;
        if (input.contains("写代码") || input.contains("实现"))
            return TaskType.CODE;
        if (input.contains("分析") || input.contains("推理"))
            return TaskType.COMPLEX;
        return TaskType.MEDIUM;
    }

    // 2. 路由：任务类型 -> 模型
    public String chat(String userInput) {
        TaskType type = classify(userInput);
        ModelConfig selected = routingRules.get(type);
        ChatModel model = getModel(selected); // 懒加载+缓存
        return model.chat(userInput);
    }
}

实测5个问题自动路由，简单任务1.8s返回，复杂任务17.9s返回。还支持手动覆盖：强制用Qwen3:8B回答简单问题，结果16.6s（比GLM4慢9倍），验证了路由策略的合理性。

六、生产环境怎么用？

本地Ollama是开发调试用的，生产环境还是得云端API。但两者不是非此即彼：

复制代码

ModelRouter（生产级路由）
├── 开发环境 -> Ollama本地（0成本）
│   ├── SIMPLE -> GLM4:9B（快）
│   ├── CODE   -> GLM4:9B
│   └── COMPLEX -> GLM4:9B
└── 生产环境 -> 云端API（高质量）
    └── GLM-5.1（数百B参数，效果更好）

实际部署建议：

开发阶段：本地Ollama跑GLM4:9B，0 API费用，秒级响应，调试效率高
测试阶段：切换到云端小模型（如GLM-4-Flash），验证API集成正确性
生产阶段：云端大模型（GLM-5.1/GPT-4），保证输出质量
降级方案：云端API挂了，自动降级到本地模型兜底

这个模式跟Claude Code的架构思路一致--本地快速迭代，云端高质量生产。

七、5道面试题

能答上来说明你真做过本地部署：

Q1: Ollama的/v1/chat/completions和/api/chat有什么区别？

答：/v1/chat/completions是OpenAI兼容接口，返回标准OpenAI格式（choices/usage），可以直接用OpenAI SDK调用；/api/chat是Ollama原生接口，返回格式不同（message对象+性能数据如total_duration/eval_count）。生产环境建议用/v1接口，方便切换云端API。

Q2: 本地模型和云端API各自适用什么场景？

答：本地模型适合开发调试（0成本、无网络延迟、数据不出本地），云端API适合生产环境（大模型质量更高、并发能力强、有SLA保障）。最佳实践是开发用本地、生产用云端，通过ModelRouter自动切换。

Q3: LangChain4j中OllamaChatModel和OpenAiChatModel有什么共同点？

答：两者都实现了ChatModel接口，chat()方法签名完全一致。切换模型只需改Builder配置（baseUrl+modelName vs baseUrl+apiKey+modelName），业务代码零改动。这是依赖倒置原则的体现--面向接口编程，不绑定具体实现。

Q4: Ollama在Apple Silicon上为什么能流畅运行9B模型？

答：Ollama底层用llama.cpp，支持Metal框架加速，直接调用Apple GPU的统一内存。M1 Pro有10.7GB可用VRAM，9B模型量化后约5.5GB，完全装得下。加上Flash Attention和KV Cache优化，推理速度能达到20-30 tok/s。

Q5: 如何设计一个支持本地+云端多模型的Router？

答：核心是策略模式+工厂模式。策略模式：根据任务复杂度（简单/中等/复杂）选择模型层级；工厂模式：懒加载+缓存ChatModel实例。路由规则可配置化，支持运行时动态调整。降级链路：云端大模型 -> 云端小模型 -> 本地模型，任一节点失败自动降级。

总结

今天把Ollama本地大模型开发的完整链路跑通了：安装部署 -> API探索 -> LangChain4j集成 -> 多模型管理。核心收获：

Ollama的OpenAI兼容接口是关键--切本地模型只改URL
GLM4:9B比Qwen3:8B快4倍--本地开发首选GLM4
LangChain4j统一接口--业务代码零改动切换模型
ModelSwitcher三模式落地--策略+工厂+装饰器
开发本地、生产云端--这是成本最优解

下一篇会写vLLM生产部署和Docker/K8s容器化方案，关注不迷路。

聊聊技术人的成长路径。有问题评论区聊。