本地跑 DeepSeek 再挂个知识库，最先卡住的往往不是装不装得上，而是「我这台机器到底该选哪条路」。显存不够、文档一多就慢、检索召回一堆不相关片段，都是常见场景。这篇不给标准答案，只给一套按自己条件对照的判断顺序：先量硬件，再定模型规格，然后挑知识库方案，最后留好降级出口。每一步都告诉你去站内哪一页核对当时的数字。
本地跑 DeepSeek 再挂个个人知识库，最先卡住的通常不是装不装得上，而是「我这台机器到底该走哪条路」。显存不够、文档一多就慢、检索召回一堆不相关片段，都是很常见的场景。
这篇不给标准答案，只给一套按自己条件对照的判断顺序：先量硬件，再定模型规格，然后挑知识库方案，最后留好降级出口。每一步都告诉你去站内哪一页核对当时的数字。
先算硬件账，再谈模型规格
很多人先挑模型再回头看机器，结果只能一路降级。正确顺序是先把显存、内存、磁盘三样分开量。显存决定能塞多大的模型和上下文长度，内存决定加载权重与切片时的余量，磁盘决定文档和向量索引能堆多少。三样里哪一样先见底，方案就往哪边收。
- 显存：决定模型规格与上下文上限，长文档问答比闲聊更吃这一块，别按闲聊的体感估
- 内存：加载权重、做文档切片、跑重排都要占，机器一边跑推理一边开浏览器就容易顶到上限
- 磁盘：原始文档和向量索引都会持续长，留空间的习惯比一开始买多大更重要
- 先明确用途：是单人偶尔问几段，还是每天丢几十份文档进去问，这两种对并发的要求完全不同
量化档位和上下文长度是互相挤显存的：上下文拉长，能上的模型规格就得往下压。判断标准是拿你真实的一批文档去做端到端问答，而不是拿一句问候语试。具体硬件型号的吞吐和租赁行情，到 /compute/gpus 与 /compute/gpu-rental 对当时的数字。
卡不够时有四条路，按代价从低到高排：降到更小的量化版本；把 Embedding 和重排放到 CPU；把推理放到一台固定机器、知识库留在本机；干脆改走 API，只把知识库留在本地。前两条省钱但体验打折，后两条是明确的能力取舍。家庭机器只有一个普通显卡、又只是偶尔查资料，就不建议硬上本地大模型，走 API 更省事。
方案怎么选：一把梭还是拆开装
一体化平台自带文档解析、切片、检索和问答界面，部署完就能用，适合先把流程跑通；拆开装是推理服务、向量库、编排层各自独立，可控性强，适合要改检索策略、要接进已有程序的人。两条路都不算错，错的是用一体化去接一个需要深度定制的场景。
| 判断项 | 倾向一体化 | 倾向拆开装 |
|---|---|---|
| 文档格式 | 以文本、Markdown、规整 PDF 为主 | 扫描件、表格、多栏排版占多数 |
| 要不要接程序 | 只用自带网页界面 | 要接进已有脚本或内部工具 |
| 换模型频率 | 基本不换，能用就行 | 经常换模型或换嵌入模型 |
| 检索调优 | 默认策略够用 | 要改切片、召回数量、重排规则 |
三项里有两项落在右边，就别选一体化，否则后面一定会推倒重来。还有个容易忽略的点：模型服务和知识库服务分开部署，换模型版本时不用把索引一起重建。装机前到 /models/deploy 和 /stacks/vector-dbs 对照当时的规格与可选产品。
文档进库这条链路最容易白干
知识库答不准，绝大多数不是模型的问题，而是链路里某一步偷了懒。完整顺序是：清洗、切片、向量化、入库、检索、重排、拼进提示词。任何一步糊弄，都会在最终回答里被放大成「答非所问」。
- 清洗去掉页眉页脚、空白页、重复段落；扫描件先过 OCR，OCR 质量差就先修 OCR，别指望后面的模型兜底
- 切片条款类要保完整段落，别从句子中间切开；手册类可以按标题层级切。切片长度和重叠比例要拿几篇真实文档试，看召回结果再定
- 向量化与入库确认嵌入模型在你的语种上够用；换嵌入模型就要整库重算，所以选之前先想清楚以后会不会换
- 验证准备一批你知道标准答案的问题，逐条看命中的原文片段对不对，这一步比调任何参数都有用
向量库的横向对比看 /stacks/vector-dbs，嵌入模型的口径看 /embeddings。判断标准很朴素：拿同一批问题在不同切片参数下各跑一遍，看命中片段是否包含答案原文，而不是只看最终回答读起来顺不顺。
跑起来之后：超时、并发和降级
本地推理的并发能力很有限，同一张卡上多路请求会互相拖慢。客户端要设排队和重试上限，而不是无脑并发，否则用户体感就是「越用越慢」。判断标准是压几个并发上去，看单次响应时间涨了多少，涨得离谱就必须加队列。
检索和生成要分别设超时，这点很关键。检索慢通常是索引结构或磁盘的问题，生成慢才是算力不够。混在一起看就会误判成「机器太差该换卡」，其实调索引就能解决。
- 检索超时：超过阈值就先返回「没找到相关材料」，别让整条请求卡死
- 生成超时：按你自己能接受的等待上限设，宁短勿长
- 降级路径一：显存被打满时切到更小的量化模型
- 降级路径二：本地服务不可用时切到 API，前端不用改
- 监控项：单次检索耗时、单次生成耗时、排队长度，三个分开看
延迟基线可以先到 /tools/speed-test 量一遍，把「正常时该多快」记下来，之后出现变慢才知道是哪里变了。另外提醒一句：如果你把文档留在本地、只把问题发去 API，隐私边界和纯本地是两回事，这点要在动手前就想清楚，而不是部署完才发现。
本地部署的收益是可控，代价也是可控——两头都建立在你能说清链路每一步在干什么。下一步先量清自己的显存和文档量，再去对照可选方案和当时的硬件数字，能省掉一次推倒重来。→
常见问题
只有一张消费级显卡，能不能同时跑 DeepSeek 和知识库？
能跑通，但要把预期放低。模型用较小量化版本、Embedding 放 CPU、文档量控制在一个可控规模内，问答体验是够用的；一旦文档量上去或者要多人同时用，瓶颈会先出现在显存和并发上。先按单人单路来设计，需要多人时再考虑拆服务或换 API。
知识库答得不准，是模型不行还是检索不行？
先查检索，再怀疑模型。把召回的片段单独打出来看，如果片段里根本没有答案，那是切片或向量化的问题，换再大的模型也没用；如果片段对但回答仍跑偏，才轮到调提示词或换模型。这个顺序能省掉大部分无效折腾。具体指标口径可参考 /embeddings 的说明。
本地部署和直接用 API 相比，什么时候值得折腾？
看两点：数据能不能出本地，以及调用量是否长期稳定。资料敏感、不方便外发，本地是硬需求；调用量大且持续，本地在长期成本上可能更划算。反过来，偶尔用、文档多变、对延迟敏感的场景，接 API 更省事。判断前可以到 /official-api 和 /compute/tco 把当时的数字摆在一起比。
