在本站中

主线位置：第三条主线「在本站中」。本站的论文采集程序站在「HTTP 进来」之前，是发请求的一方；它是 Rust 写的，只发 OpenAI 兼容的 HTTP 请求。换成自托管后，这些请求走 01 部分讲的整条路径。

版本：vLLM v0.32.0、SGLang v0.5.22；本站框架以开源仓库 main 的一个 commit 为准，见正文链接。

前面几部分讲引擎怎么服务请求。这一部分反过来，拿本站自己的一个调用方当负载：它每天发什么请求、多少 token，换成在一张卡上自托管一个 8B 模型够不够。

• 论文资讯栏目每天跑一次，逐篇调用模型：全文 → 英文结构化解读 → 中文翻译，全程串行。
• 按线上两次采集的汇总，每篇约 1.8 万输入、1.2 万输出 token。每天的总量摊开后吞吐需求很小（估算），卡上真正紧的是单个请求的长度。
• 这种「每天一批、不等人」的负载适合批处理：把串行改成几篇并发，就能用上连续批处理。

flowchart LR
  cron["每天一次"] --> caller["论文采集程序（Rust）"]
  caller -->|"现在"| hosted["托管 API"]
  caller -.->|"自托管（估算）"| engine["vLLM / SGLang<br/>单卡 8B"]
  engine -.-> q1["吞吐够不够"]
  engine -.-> q2["长度放不放得下"]
  engine -.-> q3["串行还是并发"]

本部分一页：

1. 论文资讯作为调用方：读框架源码看它每天做哪些调用、请求长什么样；用线上采集的 token 统计算每篇、每天的输入输出；按 00 和 07 的方法估算自托管的吞吐需求和显存约束；为什么适合批处理。实际吞吐待实测（C3-2）。