AI 分析
痛点：多问题文档问答场景下模型重复编码整篇文档，CPU 上一次问答要 288~580ms，问 10 个问题要 2.6~6.2 秒，成本与延迟被浪费在重复读取文档上。
目标用户：做文档问答/RAG 的独立开发者与中小团队，尤其是只有 CPU 或低配 GPU、要在一篇文档上批量提问的场景。
证据：On CPU they report around 288 ms on a laptop and 580 ms on a 4-core server for one question. Ten questions take 2.6 s and 6.2 s. ... So if you ask ten questions about the same document, it reads the document ten times. ... Disclosure: I built jevos, which is trying to solve basically the same problem ... jevos is decoder-only. It reads the document once, keeps the KV cache, then reuses it for the next questions.
变现：1) 按 token/请求计费的文档问答 API，主打「编码一次、任意次提问」的低延迟定价；2) 开源推理引擎 open-core，企业版卖 KV cache 复用、批处理与私有化部署授权；3) 面向 RAG 框架的 SDK 插件订阅。
MVP：两周内做一个 Python 库 + 极简 API：进程内对同一文档编码一次并缓存 KV，暴露 ask(doc_id, question) 接口，附一个 CPU 基准脚本，对比「每问重编码」与「复用缓存」在 1/3/10 问下的延迟曲线，开源引流、托管版收费。
竞品：Laya、jevos（发帖人自己的项目）、vLLM / prefix caching、LlamaIndex / Haystack 等 RAG 框架
摘要：发帖人是竞品 jevos 的作者，指出爆红的 Laya 在 CPU 上单问 288ms（笔记本）/580ms（4 核服务器），10 个问题要 2.6s~6.2s，原因是每次都把问题、选项和整篇文档一起重新编码。他还指出 Laya 的 typed-decisions 0.766 来自在 benchmark 训练集上微调的 checkpoint（base 仅 0.362，多数类基线 0.461），Banking77 只有 0.425 对 0.870。机会点在于「文档只编码一次、KV cache 复用」的高效多问文档推理，但目前只有技术论证，没有任何付费意愿或收入证据。