很多人卡在同一处：模型下载完了，命令行也能对话，一到「接知识库」就乱——不知道用哪套工具、文档切多大、检索不到该调谁。这篇不讲原理，只给一条从装环境到能问答的排查顺序，每步都告诉你先量什么、先看哪个数、不对时改哪个参数。跑不起来或者答得离谱，对着小节顺序退回去查，基本能定位到具体环节。
把 DeepSeek 跑在自己机器上、再接一个本地知识库，流程上不复杂，坑基本集中在两处：一是硬件和量化档位没配好，服务起得来但一上长上下文就崩；二是接知识库时切分、嵌入、检索互相甩锅，答不准却不知道改哪。这篇按四段走：量硬件、挑运行方式、搭知识库、调问答质量。每一步都告诉你先看哪个数、不对时动哪个参数。
提醒一句，下面对应硬件、参数、模型版本这类会变的数字，一律不写死，统一让你到站内页面按当时的情况核对。跑不起来或者答得离谱，就顺着小节顺序往回退，基本能定位到具体环节。
先算硬件：显存、内存和你要跑的档位
显存的第一笔账是权重本身：参数量乘上量化位宽，粗略就是权重占用，再乘以一个安全系数。第二笔账是上下文缓存，序列越长占得越多，同一张卡换成长上下文，占用量会明显上浮。两笔加起来才是底线，只看权重去下单十有八九不够。
- 显存不够时先降量化档位，再考虑 CPU 卸载；卸载能跑通，但生成速度掉一大截，长篇问答体验很难接受
- 内存留出权重体积一到两倍做加载缓冲，别卡着最低线买
- 磁盘把模型文件和后续知识库索引一起算上，索引会随着文档量持续涨
- 同一台机器上再跑嵌入模型和向量库，显存内存都要额外留量
具体参数与硬件的对照，到 部署测算（/models/deploy） 和 几张卡够用（/compute/sizing） 按你手上的卡对一遍再下手。不适用的情况也说清楚：如果只是偶尔跑两个问题、对延迟不敏感，那按最低档配也能凑合；反过来要多人同时用，就得按并发数往上加，不是单看能不能跑起来。
挑推理方式：本地服务还是命令行一把梭
两种走法要分清用途。只想自己对话、偶尔调一下，命令行式的轻量运行方式最省事，装完就能用；要接知识库、要让多个程序同时调用，就必须起一个常驻的本地接口服务，否则每次调用都要重新加载模型，慢到没法用。
| 运行方式 | 适合场景 | 要确认的点 |
|---|---|---|
| 命令行轻量运行 | 个人对话、临时测试 | 模型文件路径、显存占用、量化档位 |
| 常驻本地接口服务 | 接知识库、多程序调用 | 监听地址端口、是否兼容 OpenAI 协议、并发下显存 |
| 卸载到 CPU 方式 | 显存实在不够的兜底 | 能跑通但速度慢，只适合低频问答 |
起服务时确认三件事：监听地址和端口写对没有、是不是走 OpenAI 兼容协议、并发上来之后显存会不会爆。如果知识库工具只认 OpenAI 协议，起服务时把兼容层打开就行，不用去改工具代码。不同运行方式的差异对着 vLLM 和 Ollama 怎么选（/vllm-vs-ollama-selection） 看，别凭感觉挑。
搭知识库：切分、嵌入、检索三段怎么配
知识库这一段最容易乱，因为切分、嵌入、检索是三个独立环节，任何一个出错表现都像"答不准"。先把三段拆开，逐段确认，比整体调参快得多。
- 切分先粗后细，块太大命中却不精准，块太小答案缺上下文。先用一种切法跑通，再按实际命中情况调大小，别一开始就上复杂策略。
- 嵌入嵌入模型和对话模型是两回事，中文语料优先挑中文检索表现稳的。嵌入维度和知识库工具的要求必须对上，对不上根本入库不了。
- 检索入库后先问一句确定在文档里的话，看能不能召回。召回不了就按顺序查：文档有没有真的入库、切分后片段是否保留原句、相似度阈值是否压太高、要不要补一层重排。
嵌入模型和向量库的选型入口在 嵌入模型（/embeddings） 与 向量数据库目录（/stacks/vector-dbs）。这里有个前提：如果语料本身没有结构、全是扫描件没做 OCR，那再怎么调切分和检索都白搭，得先把文档转成可解析文本。
接上之后答不准，按这个顺序改
先分清是检索问题还是生成问题。把检索到的原文片段单独打出来看：片段不对，就是切分或嵌入的锅；片段对但答案偏，就是提示词和上下文的锅。这一步不做，后面所有调整都是盲猜。
- 多轮对话里历史太长会挤掉检索内容，限制历史条数或只保留摘要，往往比换模型见效快
- 要求引用来源时，提示词里明确让模型标注片段编号，没有依据就直说不知道，能明显压低编造
- 一次只改一个变量，改完拿同一批问题重测，否则不知道是哪个参数起的作用
- 把答对和答错的问题各存一份，方便回归对比
幻觉的系统性排查思路参考 模型底层概念（/ai-dict/category/tech） 里的相关词条，先分清概念再改参数。不适用的场景：如果问题本身超出知识库范围，那模型答不准是正常的，该做的是让它承认不知道，而不是硬调参数去逼它答对。
跑稳之后：更新、备份和边界
跑通只是开始。知识库更新要增量重建索引，别每次全量重跑，文档量一上来全量会等到怀疑人生。模型文件和索引目录分开备份，恢复时不用重新下载权重，省掉一大段等待。
给自己设一条验收线：常用问题随机抽一批，答对率稳定了再往外用。不达标就先别放开给同事，否则口碑崩了很难拉回来。这套本地单机方案不适合的场景也说清楚：语料需要严格权限隔离、或者问答量远超单机吞吐时，单机会撑不住，该考虑集群或多实例。合规和权限边界提前看 安全与合规（/safety），别等出事再补。
下一步先确认硬件能不能撑住你想要的档位，再决定运行方式，顺序反了会白折腾一轮。→常见问题
普通电脑没有独显，能跑 DeepSeek 加本地知识库吗？
能跑，但只能用很小的参数规模或低量化档位，速度很难支撑连续问答。更现实的做法是把知识库工具放本机、模型走本地接口服务跑在带显存的机器上，或者干脆先用云端接口验证知识库流程对不对，确认有效再考虑搬回本地。
本地知识库和直接把文档喂给模型有什么区别？
喂文档受上下文长度限制，超了就截断，而且每次都要重传。知识库是先切分、算向量存起来，提问时只把最相关的几段塞进上下文，长文档和大量文件都能覆盖，代价是要维护索引和检索质量，检索这一段没调好，答案反而更差。
跑起来以后速度很慢，先动哪个参数？
按影响从大到小排：先看是不是开了 CPU 卸载，能全放显存就全放；再看量化档位，低一档速度通常能上来；然后是上下文长度和单次输出上限，砍掉不必要的长度立竿见影。最后才考虑换运行框架或换卡，前面几项没调完，换硬件也是浪费。
