很多人想试本地模型，卡在第一步：工具装了两三个，模型名和参数对不上，命令行敲完没反应，或者跑起来慢到没法用。这篇只讲 1.5B 这一档小模型的跑通流程，假定你没跑过任何本地模型，从环境检查到第一次对话一步步来，最后给一张「跑不动」时的排查顺序表。
很多人试本地模型卡在第一步：工具装了两三个，模型名和参数对不上，命令行敲完光标一停没反应，或者勉强跑起来了慢到没法用。这篇只讲 1.5B 这一档小模型怎么从零跑通，假定你没跑过任何本地模型。整条路线是：先确认机器和用途，再挑一个运行时，然后把模型拉下来问第一句话，最后接上聊天界面。
先把预期放正。1.5B 这一档属于「小模型」，它的价值在窄任务：文本分类、打标签、格式转换、轻量摘要、把一段话转成结构化字段。指望它写长代码、做多轮推理、当通用助手，大概率失望。这不代表不能跑，而是跑通之后要清楚它能干什么不能干什么。
先确认三件事，再动手装
别急着装运行时。装之前把这三件事确认完，能省掉后面大半的折腾。三件事里任何一件不满足，都不是「再装个工具」能解决的。
- 看显存和内存够不够：1.5B 量化后占用很低，核显和纯 CPU 也能跑，只是慢；每档量化对显存的要求会变，到 /models/deploy 按你手上的卡算一遍
- 确认磁盘别写满：模型文件默认落在用户目录，Linux 和 macOS 的常见路径坑可以到 /ai-dict/category/hardware 对照；磁盘满了的表现是下载中断或启动直接报错
- 想清楚用途：把「我要用它做 XX 窄任务」写下来，跑通后拿这个任务去验，比随便问一句「你好」有用得多
选一个运行时，别三套一起装
本地跑模型最常见的自坑方式是：Ollama 装一半，又去装另一套，结果环境互相干扰，报错也不知道是哪套的。第一次跑通，只选一个，全程用它。
| 你的情况 | 建议路线 | 什么时候不适用 |
|---|---|---|
| 只想最快跑通、看到出字 | 用 Ollama 这类一体化的运行时，装完就能拉模型 | 需要精细控制显存、并发参数时不够用 |
| 要接进自己的 Python 项目 | 同样用 Ollama 的 HTTP 接口，先跑通再加代码 | 项目里有高吞吐、多用户需求 |
| 想对比不同方案的资源开销 | 到 /tools 里的换算工具估一遍再决定 | 对延迟极其敏感、要求毫秒级响应 |
判断标准很简单：你现在的目标是「看到模型在本机出字」，那选命令最少、依赖最少的那个。等跑通了、知道瓶颈在哪，再换更专业的推理框架也不迟。
拉模型、跑第一句话、接上界面
这一步的目标不是调优，是拿到一次成功的输出。顺序别乱：先命令行问出一句话，再去接图形界面。界面连不上，八成是接口地址或端口的问题，不是模型的问题。
- 拉取模型用运行时自带的命令行按模型名拉取。注意区分「带思考链的版本」和普通版本，前者回话更啰嗦、更慢，1.5B 这一档上感觉尤其明显。拉完先确认本地已经有这个模型，再往下走。
- 命令行问第一句直接在命令行里问一个最简单的问题。要确认三件事：能出字、能中断、显存没爆。出字但特别慢，先记下时间，等下再排查；中途卡死或报错，把报错原文留下来。
- 接图形界面想要聊天窗口，就用 WebUI 类前端指向本地接口地址。接口地址写法和端口怎么填，到 /ai-dict/category/tech 看对照。先确认命令行能出字，再接界面，否则排查会多一个变量。
- 记下启动命令把模型名、启动命令、端口抄进自己的备忘录。换机器或重启后不用重新猜。
全过程的后半段不联网也能跑，但首次拉模型需要网络。如果目标机器在内网，先想好怎么把模型文件搬进去，别等到装到一半才发现下不动。
跑不起来时，按这个顺序排查
报错长相不同，原因完全不同。别一上来就重装，按下面的顺序一步步排除，每一步都能缩小范围。
| 排查顺序 | 看什么 / 做什么 | 说明什么 |
|---|---|---|
| 第一步 | 看日志第一行 | 模型没下完、路径不对、显存不足，这三种报错长相完全不同，先分清是哪一类 |
| 第二步 | 换更低的量化档位 | 能不能出字比出字质量优先；量化档位怎么取舍到 /ai-dict/category/tech 看 |
| 第三步 | 关掉其他占显存的程序 | 浏览器多开标签、另一个模型服务没退干净，都是常见干扰项 |
| 第四步 | 换一个同量级小模型对比 | 能排除是环境问题还是模型本身能力问题 |
如果四步走完还是不行，把每一步的结果写下来，再去提问或对照站内资料。带着排查记录去问，比只说「跑不起来」有用得多。
跑通之后，先做两件小事
跑通不等于能用。接下来别急着换大模型，先花一点时间把「怎么判断它够不够用」这件事做成能重复的动作。
- 固定一个自己的测试问题集：每次换量化档位或换运行时都跑一遍同一组问题，用输出差异判断改动值不值；测延迟的方法见 /tools/speed-test
- 把模型文件位置、启动命令、端口写成一份自己的备忘录，别每次重新查
- 明确边界：小模型跑得动不等于够用，任务一变复杂就该考虑换更大的模型或直接调接口，量级对照到 /models 看
- 如果打算长期用，定期回来看一次运行时的更新说明和站内的模型资料，别停在第一次跑通的版本上
常见问题
没有独显，纯 CPU 能跑 1.5B 吗？
能跑，小模型量化后在 CPU 上也能出字，代价是速度慢、首字延迟明显。适合偶尔跑一次、不赶时间的场景，比如批量打标签、文本清洗。要交互式聊天会觉得卡顿难忍，这种需求建议换更小的模型或直接调接口。
1.5B 和更大的本地模型比，差在哪？
差在知识量和长指令的稳定性，不在「能不能跑」。小模型适合规则明确、输出短的窄任务，一旦涉及多步推理、长文改写或代码生成，错误率会明显上升。判断标准很简单：同一句话问三遍，答案自相矛盾就说明这个任务超出它的能力了。
部署完还需要联网吗？会不会偷偷调用线上接口？
本地运行时时模型推理完全在本机完成，不依赖外网，也可以断网使用。只有首次下载模型权重需要网络，之后可以搬到内网机器上跑。要注意的是，如果你接的图形界面或插件自带联网搜索功能，那是额外组件在联网，跟模型本身无关，用前看清楚。
