ollama+langchain搭建本地大模型

本地模型能跑起来了，想拿它做个小应用，结果卡在「Ollama 起好了，LangChain 那边怎么接」这一步：包版本对不上、连不上端口、输出乱码、换模型就崩。这篇按动手顺序讲一遍——装什么、写哪几行、怎么先验证通路再叠功能，以及跑不动时先查哪儿。

本地模型能跑起来，想拿它做个小应用，很多人卡在同一处：Ollama 那边对话窗口好好的，LangChain 这边接不上去——装了包导入报错、连不上本地端口、返回内容结构对不上、换个模型整个流程就崩。这些大多不是模型问题，是通路没先验证就去叠功能了。

这篇按动手顺序捋一遍：先分清这套组合里谁管什么，再定模型和量化档，然后从接口通到应用通分步接，出问题给一个固定的排查顺序。全程只讲判断标准和动作，具体版本、性能数字和模型规格，一律到站内对应页面看当时的记录。

先说清楚这套组合各自管什么

Ollama 负责把模型跑起来并开出一个本地接口，权重加载、显存分配这些它替你处理掉，你只需要知道它在哪个地址监听。LangChain 负责把提示词、模型调用、输出处理、记忆和检索串成流水线，省掉你自己写胶水代码。两者结合的价值不在「本地」两个字，而在于你能用一套统一的写法换不同后端。

• 只是想有个本地对话窗口：直接用现成客户端，别上框架，框架带来的抽象成本你收不回来
• 要做带流程的应用：多轮上下文、接本地文件、接数据库、按条件走不同分支，这种才值得上 LangChain
• 要验证一个想法：原型阶段用这套最快，改提示词和换模型都不用动架构
• 不适用的情况：要对外提供高并发服务、对延迟有硬性保证、需要多卡多实例调度，本地这一套的定位就不是干这个的
• 不适用的情况之二：需要精细控制批处理大小和显存峰值，得换到专门的推理部署方案
• 模糊地带：团队规模很小、只给自己用，那这套够用，但别把它当成上线方案规划

选模型和量化档：先定显存，再定尺寸

选型顺序错了，后面全白搭。正确顺序是先看手上有多少可用显存，再决定参数量和量化档位，最后才在符合条件的模型里挑。反过来先看中某个模型再去凑硬件，大概率跑不起来或者跑起来就爆。

显存要留余量：权重本身占一块，上下文长度占一块，运行时和批处理再占一块。长上下文任务吃掉的显存比多数人预估的多，尤其是你后面要接检索、塞长文档的时候。拿不准就到 /models/deploy 按自己的卡和量化档算一遍，别凭感觉猜。

• 量化档位越低，占用越小，但输出质量的下滑在某些任务上会很明显，别只看能不能跑起来
• 选型唯一标准是：你这个原型要干的活它能不能完成。榜单排名和参数规模不是这里的决策依据
• 同一档位下不同模型的规格、许可和适用范围，到 /models 里对应的模型条目看，别抄别人的配置
• 嵌入模型和生成模型是两件事，配检索的时候显存要分别算，很多人漏算这一块

动手接：从能跑通到能调用

1. 验服务确认 Ollama 在运行、本地接口能通。用最简单的请求打一次，看到正常返回再往下走。这步不过，后面写多少代码都是白写。
2. 装依赖装 LangChain 相关包。套件拆得比较细，按你要用的功能装对应的包，别图省事一把全装。版本匹配是这一环最容易出问题的地方。
3. 跑单轮用最少的代码跑一次单轮问答：指定模型名、给一句提示、把返回打印出来。跑通之前不要加任何额外逻辑。
4. 叠功能确认通路后再一层一层加：先加提示模板，再加多轮记忆，最后才接检索和外部调用。每加一层回头验一次。
5. 固化配置模型名、接口地址、参数这些从代码里抽出来放进配置文件。后面换模型时你只需要改一行，不用翻代码。

# 第一步先验接口能不能通，别急着写应用代码
# 把下面的地址换成你 Ollama 实际监听的地址
curl -s http://127.0.0.1:11434/api/tags

写应用代码时，最省事的做法是先写一个最小脚本：加载模型、发一句固定的话、打印结果。这个脚本要一直留着，后面任何改动出问题，先跑它，能快速区分是环境坏了还是新代码写错了。

先验证通路，再谈功能

把验证拆成三层，哪层挂了只查那层，不要三层一起猜。接口层看请求能不能到达服务并拿到响应；模型层看返回内容本身是否合理、有没有变成乱码或者空串；应用层看解析和格式化之后的输出结构对不对。三层混在一起查，效率会低很多。

• 用固定输入做基准，每次都跑同一句。换问题会让你分不清是代码改了还是模型本身有波动
• 记录延迟基线，到 /tools/speed-test 量一次。后面觉得慢的时候有对照，不然只能凭感觉说「好像变慢了」
• 输出格式不稳定时，先在提示里把格式约束写死，再考虑在解析层加兜底，顺序反了会把问题藏起来
• 把每次改动前后的输出存下来，出问题时能直接对比，比回忆「之前是什么样的」靠谱

原型阶段常用的几种串法

从简单到复杂，原型阶段基本就这几种。不要一上来就奔着最复杂的那种去，先把第一种跑顺，后面加东西才有参照。

单轮问答

最小闭环，只用来确认通路。不要在这一步做设计，越简单越好

模板化问答

把变量抽出来，方便换输入跑批量，也方便后面接界面。原型的多数场景够用

多轮对话

需要维护历史。历史越长占用越多，必须在轮数和长度上设上限，不然跑一会儿就卡

检索增强

接向量库和嵌入模型，先把文档切分和召回质量调好，再谈回答效果。嵌入模型怎么挑去 /embeddings

这几种串法可以叠加，但叠的时候要清楚每一层在干什么。比如模板化加多轮，历史里塞的是什么、模板变量从哪里来，这些要想清楚，否则调起来会没有头绪。检索增强这块和知识库类方案的重叠比较多，先想清楚你要的是快速验证还是长期可用，目标不同做法差别很大。

跑不通时的排查顺序

按固定顺序查，别跳。下面这个顺序是从底层往上层走的，前面一层没问题再查下一层，能省掉大量来回试的时间。

• 服务层最常见的是没启动或被占用端口，错误信息通常很直白，看一眼就能定位
• 模型层的三类错误——名字错、没拉取、资源不足——提示信息差别明显，看第一行就能分
• 依赖层多为版本不匹配或套件拆分后的导入路径变化，升到或降到匹配版本通常就能解决
• 输出层的问题最隐蔽，表现为看起来没报错但结果不对。这时候回到固定输入做基准对比

这套方案的边界，以及什么时候该换

把这套方案用在对的地方，能省很多事；用错地方，会花很多时间在填坑上。它的定位是原型和内部工具，不是对外服务。搞清楚边界不是保守，是避免在错误方向上投入。

• 适合：个人或小团队的内部原型、验证一个想法能不能跑通、给非技术同事演示效果、做内部工具
• 不适合：对外高并发服务、需要严格延迟保证、需要多卡多实例调度、需要精细资源隔离
• 不承诺任何性能数字：同样的模型在不同机器上差别可能很大，先到 /tools/speed-test 量自己的基线再谈优化
• 原型通过后要做的三件事：把配置固化下来、把模型名和参数写进配置文件、准备一个能回退到远端接口的开关

关于成本，如果你后面要从本地切到远端接口，价格差别不小，但具体数字别抄别人的，到 /price-watch 看当时的记录。中转站这类渠道的可用性和稳定性怎么看，去 /sites 查对应条目，本地方案和远端方案的取舍，本质是可控性和成本之间的权衡。

最后一点：本地这套方案的价值在于快速和可控，不在于性能。原型验证完，该换就换，别因为「已经跑起来了」就一直将就。什么时候该换，标准很简单——当你的真实负载超过了原型定位的上限，就是换的时候。