你想把一堆内部文档喂给模型，又不想传到别人服务器上，于是决定在本机搭一套：本地模型 + 本地知识库 + 聊天界面。真动手才发现问题一堆——装完跑不动、文档切得太碎答不准、换个系统就报错。这篇按顺序给你一条能走通的路，每一步都告诉你怎么判断有没有做对，以及哪一步不对时该回头查什么。
你想把一堆内部文档喂给模型，又不想传到别人服务器上，于是决定在本机搭一套：本地模型 + 本地知识库 + 聊天界面。真动手才发现问题一堆——装完跑不动、文档切得太碎答不准、换个系统就报错。这篇按顺序给你一条能走通的路，每一步都告诉你怎么判断有没有做对，以及哪一步不对时该回头查什么。
整套链路其实就四段：定硬件和模型、装运行环境并验证、把文档接成知识库、接聊天界面做验收。新手最容易犯的错是跳步——环境还没跑通就去调切片参数，或者模型都答不对就去改提示词。按下面的顺序走，出问题就停在那一步排查，比来回乱改省事得多。
第一步：先把硬件和模型这件事定下来
顺序别搞反：先按显存确能量化档位和能跑的参数规模，再挑具体模型。反过来做，往往是模型选好了才发现塞不进显卡，只能推倒重来。到 /models/deploy 与 /compute/sizing 按自己的卡算一遍，结果不满意就降参数量或降量化档位，而不是硬上。
- 量化档位
- 把权重压小以塞进显存，档位越低越省显存、质量掉得越多
- 参数规模
- 模型本身的体量，越大越吃显存、通常也越慢
- 上下文长度
- 一次能塞进多少字，知识库拼进去的内容也算在里面
- 量化档位只看三件事：能不能装进显存、回答质量掉不掉到影响你的任务、生成速度能不能忍；对照表在 /quantization-gguf-awq-explained，具体数字以站内当时页面为准
- 模型来源优先用官方权重仓库，或在 /official-api/providers/siliconflow、/official-api/providers/modelscope 核对名字与量化版本，避免下到改过的二手权重
- 显存实在不够时，先降量化档位，再考虑换更小的参数规模，最后才想「要不要上云」这件事
- 集显或只有一两份短文档的场景，本地部署的收益很低，先看清 /self-host 的分界线再决定要不要折腾
第二步：装运行环境，并且真的验证它能跑
用 Ollama 这类一条命令起服务的工具最省事。装完第一件事是拉一个小模型跑通「你好」，再换目标模型；别一上来就拉大模型，然后对着满屏报错发愁。安装、拉取、显卡指定分别照着 /ollama-getting-started、/ollama-huggingface-model-pull、/ollama-gpu-selection 走，先跑通再谈优化。
- 服务在不在确认进程或端口活着；连不上就先看服务有没有起来，再谈别的
- 模型拉没拉下来列出本地已有的模型清单，确认目标模型真的在本地，而不是只写了名字
- 命令行能不能出字用命令行直接对话一次，出一个完整回复；这一步不过，界面层一定也不会好
- 指定显卡有没有生效看运行日志里有没有识别到独显；没识别到就回到显卡指定的那一步查配置
这四步哪一步断掉就停在那一层排查，不要跳着改配置。常见误区是命令行都没出字就去装聊天界面，结果问题被藏在两层日志里，更难定位。如果你要的是多人并发、稳定高吞吐，Ollama 不是终点，去 /vllm-vs-ollama-selection 看该不该换推理框架。
第三步：把文档变成能查的知识库
流程固定四段：文档解析 → 切片 → 向量化 → 检索后拼进提示词。任何一段偷懒，最后都会表现为「答得很像但不对」。这个现象很有欺骗性——它看上去像模型在胡说，其实是检索没捞到正确片段。
切片是新手最容易做砸的一步。按固定字数硬切会把一段完整说明劈成两半，检索时只能捞到半句。尽量按标题层级或自然段切，并给每片保留来源信息，方便回答里带出处。嵌入模型负责把文字变成向量，中文场景、维度、要不要加重排这几项在 /embeddings 和 /chinese-embedding-model-choice 里挑，向量库本身可以在 /stacks/vector-dbs 里选一个你运维得动的。
| 环节 | 做对了的表现 | 做错了的典型症状 |
|---|---|---|
| 文档解析 | 正文、标题、表格都能提出来 | 扫描件或复杂表格整段丢失 |
| 切片 | 一片讲清一件事，边界在自然段 | 答一半、上下文明显断裂 |
| 向量化 | 专有名词能召回对应片段 | 同义改写能召回、专名却召不回 |
| 检索拼接 | 答案能指出来自哪份文件 | 答得像但来源对不上 |
验收动作很简单：拿一个只有你文档里才有的专有名词去问，模型答得出且能指出出自哪份文件，说明链路是通的；答不出就先去查切片和检索，不要先去怪模型笨。
第四步：接一个聊天界面，然后做四组验收
界面层随便挑，只要能配置「模型地址 + 知识库接口」就行。重点不是界面好看，而是它能不能把检索到的原文一并展示出来——这决定了你排查时能不能一眼看出答案是不是真的来自文档。
- 文档内问题答得对：拿文档里的原句改写一下去问，答案要点对得上
- 文档外的问题它敢说不知道：故意问一个文档里没有的事，看它会不会硬编
- 改了文档后重新入库，答案跟着变：改一处事实再问同一问题，看新答案有没有生效
- 连续追问三四轮，上下文不串味：多轮对话里指代清楚，不把上一轮结论套到新问题上
日常排查顺序建议固定为：先看服务日志有没有报错 → 再看检索返回了哪些片段 → 最后才调提示词。反过来做，会浪费大量时间在改措辞上，而问题其实在检索层。要求答案带严格出处、或者要对接内部权限体系时，本地拼装方案的上限会很快到顶，这时该评估成熟的知识库产品而不是继续加补丁。
本地部署的难点从来不是让模型说话，而是让它说的话有据可查。下一步按上面的顺序走一遍之后，如果你的卡算不动、或者不确定该选哪个量化档位，去站内的部署与算力页面按自己的显卡重新算一次，比继续试错快得多。→
常见问题
一定要用 Ollama 吗，其他工具行不行？
不是必须。Ollama 的优势是装完就能跑、拉模型一条命令，适合第一次搭。但它的并发和吞吐不是强项，如果你的场景是多人在线用，换成 vLLM 这类推理服务更合适。工具之间的差别可以在站内看 ollama 和 vllm 的对比，按你的人数规模和延迟要求来选，而不是看哪个人气高。
为什么要加知识库，直接问模型不行吗？
通用模型没见过你的内部文档，问它只能靠猜，还会猜得很自信。知识库的作用是每次提问先在你的文档里捞出相关片段，再交给模型组织语言回答，这样答案的依据来自你的资料。如果你的问题本来就不依赖私有资料，比如写代码、改文案，那加知识库只是徒增复杂度，不必上。
回答不准，是模型不行还是知识库的问题？
多数情况先查知识库。判断办法很简单：把检索到的原文片段单独拿出来看，如果片段本身就答不上这个问题，那就是切片或检索的锅，换模型没用；如果片段是对的但模型组织成错答案，那才轮到考虑模型能力和提示词。这个顺序能省掉大量换模型的无效折腾。
