ollama/ollama¶
这个项目在系统里负责哪一层¶
Ollama 负责的是本地模型平台层。它解决的不是“本地跑个模型”这么简单，而是“怎样把模型拉取、模型定义、运行管理、服务接口和生态兼容做成正式平台能力”。
读它最大的收获，是把“模型平台”和“业务服务”分开。很多团队只盯业务接口，不想模型运行边界，最后一遇到模型更新、资源争抢、版本切换就开始混乱。
先抓整体结构¶
读 Ollama 时，先看它对外承诺了什么：
- CLI：怎样拉模型、列模型、运行模型。
- REST API：怎样把本地模型暴露成服务。
- 模型定义：怎样描述模型、模板和依赖。
- OpenAI 兼容层：怎样接进现有上层生态。
看完这些，再回头看模型加载、调度、常驻和回收，会更容易明白内部设计在服务什么。
一条典型执行链¶
一条典型链路通常是这样：
- 先拉取或准备模型文件。
- 服务端启动本地模型服务。
- 上游业务通过 REST API 或兼容接口发请求。
- 平台层检查模型是否存在、是否已加载、资源是否足够。
- 推理结果以同步或流式方式返回。
- 模型实例按策略常驻、回收或切换版本。
这条链说明了一件事：模型服务本身就是后端系统。它有资源管理、错误语义、接口兼容和生命周期问题，不是业务服务后面一个透明黑盒。
值得学的设计¶
Ollama 最值得学的有两点。
第一，它把业务接口和模型运行环境分开。对业务方来说，需要的是稳定 API、明确错误、兼容生态；对平台方来说，真正难的是模型是否存在、能不能拉取、资源是否足够、不同模型如何调度和复用。第二，OpenAI 兼容层被放在主能力里。它不是装饰，而是生态入口，因为上层 SDK、调试工具和 Agent 框架能不能直接接进来，很大程度取决于这层兼容是否可靠。
如果你以后做私有化模型部署、混合模型架构或本地推理，这两点会非常重要。
适合借回自己项目的点¶
- 把模型平台和业务服务分成两层边界。
- provider adapter 单独做，不要在业务层四处散落模型 HTTP 请求。
- 把健康检查、错误语义、版本切换和兼容接口当正式能力设计。
- 提前想清楚模型拉取、加载、回收和资源占用，不要等线上再补。
不要照抄的地方¶
- 不要因为模型跑在本地，就误以为权限、审计、限流、观测可以少做。
- 不要把模型运行管理逻辑混进问答业务服务。
- 不要把兼容层当成“为了看起来像生态”的包装。它通常就是平台的核心入口。