DeepSeek V4 开源以后，我想把内部知识问答搬回内网

4 月 25 日 DeepSeek 开源了 V4 预览版，百万上下文；两天后又把输入缓存的价格降到原来的十分之一。热闹的是价格，我在意的是开源权重这四个字。

知识问答走的是外部接口

内部知识问答那个 Dify 应用，从去年做起就走外部接口，用的是国内一家云厂商的模型服务。PRD、模板配置、参数文档都在里面。

没有人提过这有什么问题。文档是大家写的，问的是自己人，接口是云厂商的，每一环看着都正常，所以没人觉得要提。它是产品和研发在用，一天被问十几次，问的是内部文档，接口是正规云厂商的。

在那边的时候，我自己一直在想这件事。

为什么是我自己在想

做 Smart Photo 的时候，商品图不走外部服务，理由之一是数据合规：未上市的 SKU 不能经过第三方的服务器。这条线当时是明确定下的。

图片守住了，文档却一直在外面。PRD 里写的是还没做的功能，参数文档里是我们调了很久的东西。论敏感，它们不比商品图低。

一天十几次的问答，每一次都带着内部文档的片段出去。单看一次不算什么，积少成多，等于一整套文档都在外面转过。

以前想过数据出去的顾虑，却没有把部署和后续维护这笔账认真算完。

算力是现成的

这次开源让我又想起这个选择，只是轮不到我去做了。V4 本身太大，公司机房里那几张 4090 装不下；但权重开源，就会有人做出更小的版本，里面总有一个装得下、又够答内部文档的。一天十几次的问答，不需要最强的模型。

算力也是现成的。Smart Photo 的推理服务器放在公司机房，白天跑生成任务，夜里基本空着。机房在公司里，数据不出公司，这一条比什么都直接。知识问答调用量不大，放上去不会挤占生成；需要提前处理的文档，也可以挪到夜里跑。

我没部署过语言模型

说是维护的人是我自己，我得先承认：开源语言模型，我没有部署过。

部署过的是 SD 1.5 这类图像模型，那是团队一起弄的，有算法同事在。语言模型的部署，量化怎么选，推理框架用哪个，显存怎么分，我都只是看过，没动手做过。

看过和做过之间的距离，我在 SD 上走过一次。第一次在自己电脑上装 WebUI，出来的图能用的很少，也是从那里一点点摸出来的。

所以搬回来这件事，对我不只是多一个服务要管，是先要学会怎么把它搭起来。学是能学的，只是这部分时间要算进去。

小模型答内部文档，够不够

内部文档的问题，大多是查一个参数、找一段说明、问一个功能当初怎么定的。这类问题要的不是推理多强，是找得准、答得老实。

一个小一些的模型，只要检索做好，大概够用。真正难的，还是前面那些老问题：文档的版本，段落怎么切，旧参数和新参数怎么分。这些问题搬到哪都跟着，换到内网也不会自己消失。

搬回来要有人管

搬回来有代价。

外部接口不用管更新，内网的要自己维护版本。外部的模型会一直变好，内网的停在部署那一天。服务出了问题，没有人值班。公司机房的机器，硬件有人管；硬件之上跑的服务，是谁搭的谁管。

真搬的话，维护的人是我自己。正因为清楚这一点，我才没有马上动手。多一个要自己管的服务，就多一件可能在夜里出问题的事。

这和当年买服务器跑 SD 是同一笔账：省的是每次调用的钱，和数据出去的风险；付的是有人要一直管它。那次是团队在管，这次是我一个人。

最担心的，是领导不批

如果真要搬，我最担心的一步，不是技术，是领导不批。

这件事站在我的角度，理由很清楚：数据不出去，算力是现成的。站在领导的角度，看到的可能是另一面：一个没人提过问题的服务，要花人力搬；搬完以后，维护压在一个没部署过语言模型的产品经理身上；出了问题，影响的是大家查文档。

没人提过顾虑，就意味着没人觉得现在有问题。要让一件大家都觉得没问题的事，变成要花力气去改的事，光有我自己想过这一条，不够。

真要去提，大概得先把账算清楚：外部接口一个月花多少，搬回来要占多少机器、多少人，数据出去的风险具体落在哪几份文档上。算不清，就不去提。

问题变了

我还没决定搬。

搬回来值不值得、有没有人接着管，这笔账我当时没算完，现在也不用我算了。可下一次再碰到同样的问题，我会先算这笔账。