最近刚好想基于Kimi来搭建本地私有知识库，调研了几家服务商，比如deepseek，阿里云等。虽然deepseek v3的发布让外界对其大加赞叹，着实让中国人扬眉吐气了一番，但是deepseek的文档实在是太简陋了，一看就是那种基本功能还不完善的样子：研读了几遍，没有找到我想要的知识库接口，虽然有第三方工具，但是短时间内搬迁过来不容易，先找找有没有现成可用的吧。第二家服务商是Kimi，国内大模型创业公司较早杀出来的一批黑马，阿里云曾投资过。而且有我想要的接口，比如这个上传文档的接口，兼容OpenAI：from pathlib import Pathfrom openai import OpenAIclient = OpenAI( api_key = "$MOONSHOT_API_KEY", base_url = "https://api.moonshot.cn/v1",)# xlnet.pdf 是一个示例文件, 我们支持 pdf, doc 以及图片等格式, 对于图片和 pdf 文件，提供 ocr 相关能力file_object = client.files.create(file=Path("xlnet.pdf"), purpose="file-extract")# 获取结果# file_content = client.files.retrieve_content(file_id=file_object.id)# 注意，之前 retrieve_content api 在最新版本标记了 warning, 可以用下面这行代替# 如果是旧版本，可以用 retrieve_contentfile_content = client.files.content(file_id=file_object.id).text# 把它放进请求中messages = [ { "role": "system", "content": "你是 Kimi，由 Moonshot AI 提供的人工智能助手，你更擅长中文和英文的对话。你会为用户提供安全，有帮助，准确的回答。同时，你会拒绝一切涉及恐怖主义，种族歧视，黄色暴力等问题的回答。Moonshot AI 为专有名词，不可翻译成其他语言。", }, { "role": "system", "content": file_content, }, {"role": "user", "content": "请简单介绍 xlnet.pdf 讲了啥"},]# 然后调用 chat-completion, 获取 Kimi 的回答completion = client.chat.completions.create( model="moonshot-v1-32k", messages=messages, temperature=0.3,)print(completion.choices[0].message)它支持的文档格式非常多，不仅支持文本文档，还支持图片格式。估计是最全的一家吧，连阿里云都没有这么多，后续再讲阿里云。
上面示例中是提取文本内容，要知道提取文件后的内容可能非常大，比如一本书，都几十万字到几百万字，这样来回跟大模型交互，这个成本估计真的是要命。
为了解决这个问题，Kimi也算是很贴心了，她跟我们提供了context cache，上下文缓存技术服务：
Context Caching （上下文缓存）是一种高效的数据管理技术，它允许系统预先存储那些可能会被频繁请求的大量数据或信息。这样，当您再次请求相同信息时，系统可以直接从缓存中快速提供，而无需重新计算或从原始数据源中检索，从而节省时间和资源。使用 Context Caching 时，首先需要通过 API 创建缓存，指定要存储的数据类型和内容，然后设置一个合适的过期时间以保持数据的有效性。一旦缓存创建完成，任何对该数据的请求都会首先检查缓存，如果缓存有效，则直接使用缓存（此时已缓存的内容将不再收取 Tokens 费用），否则需要重新生成并更新缓存。这种方法特别适用于需要处理大量重复请求的应用程序，可以显著提高响应速度和系统性能。
Context Caching 特别适合于用频繁请求，重复引用大量初始上下文的情况，通过重用已缓存的内容，可以显著提高效率并降低费用。因为这个功能具有强烈的业务属性，我们下面简单列举一些合适的业务场景：
- 在系统提示词 system prompt 中提供大量预设内容的问答机器人，例如 Kimi API 小助手；
- 针对固定的文档集合的频繁查询，例如对合同进行多维度的审查工作；
- 瞬时流量巨大的爆款 AI 应用，例如哄哄模拟器，LLM Riddles；
这个功能好是好，在我窃喜之余，翻看了她的计费方式，看完让我大吃一惊：
文档中举了一个计费的案例：比如10K文档内容，存储了2小时的缓存，总花费6元人民币，这个例子她还没有算上大模型输入输出的token开销。下面是cache计费规则：
这个计价包含了时间维度，这个有点儿让人受不了了，通常一个数字人直播挂上12小时，这期间cache 一直在用，如果某商户上传了几百万的文档，估计一晚上的开销足以让人家破产了，这谁还敢用啊？
除了这个计费问题，她还有很多限制，比如：
1. 单个用户最多只能上传 1000 个文件，单文件不超过 100MB，同时所有已上传的文件总和不超过 10G 容量。超过了，你得自己删除。
2 每个cache 大小限制128k。
3 并发访问限制，包含了访问限速，token限速等，跟累积充值金额有关，虽然充值额度不大，但是限制很恶心。
4 其他等等。。
阿里云也有一个类似的cache context功能，思路差不多，只是计费不同，它没有包括时间维度：
好了，这篇文章主要关心本地知识库的计费问题，看了几家服务商，我们大概心里有数了，知识库创建起来容易，使用起像割肉?。尤其是大量文档交互的场景，所以对价格敏感的人们，可以不用考虑大厂API了，至少长期来看，不应该这样依赖。
粤ICP备14082021号
免费POC，
零成本试错
