核心判断
AirLLM（仓库 lyogavin/airllm）解决的是一个被多数推理库放弃的问题：在 4-8GB 显存的消费级硬件上，跑起 70B 甚至 405B、671B 参数的原始权重模型。它走的是"分时换入"这条路——平时只把当前正在计算的那一层参数读进显存，其余层在 NVMe/SSD 上待机，算完即弃，下一层顶上。 AirLLM（仓库 lyogavin/airllm）解决的是一个被多数推理库放弃的问题：在 4-8GB 显存的消费级硬件上，跑起 70B 甚至 405B、671B 参数的原始权重模型。它走的是"分时换入"这条路——平时只把当前正在计算的那一层参数读进显存，其余层在 NVMe/SSD 上待机，算完即弃，下一层顶上。
核心判断
AirLLM（仓库 lyogavin/airllm）解决的是一个被多数推理库放弃的问题：在 4-8GB 显存的消费级硬件上，跑起 70B 甚至 405B、671B 参数的原始权重模型。它走的是"分时换入"这条路——平时只把当前正在计算的那一层参数读进显存，其余层在 NVMe/SSD 上待机，算完即弃，下一层顶上。
这条路换来了几件别家没同时做到的事：
4GB VRAM 跑 70B：不量化、不蒸馏、不剪枝，权重保持原始 fp16/bf16 精度
8GB VRAM 跑 405B Llama3.1：405B 的权重在 fp16 下约 810GB、fp8 下也要约 405GB——原本得在多张高端 GPU 上才能稳住推理，AirLLM 把它压到单卡 8GB
约 12GB 跑 DeepSeek-V3（671B）、约 3GB 跑 Qwen3-235B：v3.0 起，稀疏 MoE 模型不再整层加载，改为单个 token 实际路由到的专家逐个流式加载
2026-07 更进一步，官方称 Kimi K3（2.8T，当时开源的最大模型）在单张 RTX 6000 Ada 上实测约 3.72GB 显存跑通。
代价同样明确。逐层换入意味着每生成一个 token 都要把模型层从磁盘读一遍，吞吐低。AirLLM 的定位是"单卡 / 边缘设备能跑起来"，对应个人研究、论文复现、边缘 demo 这类对延迟不敏感、对显存极度敏感的场景；高 QPS 服务请直接走 vLLM / TensorRT-LLM。
下文先给项目地图和一条总览，再拆解分层加载、块级量化、预取、稀疏 MoE 四条机制的边界，用一个 70B 推理的完整任务流把机制串起来，然后解读性能数字的测量范围，最后给上手示例、常见问题和采用决策。读完后，你应当能独立判断一件事：在什么样的模型规模、显存大小和延迟要求下，AirLLM 才是对的选择，而不是顺手就用。
项目地图
维度 关键信息
仓库 lyogavin/airllm
PyPI pypi.org/project/airllm
许可证 Apache-2.0
Stars / Forks 29,485 / 3,150（GitHub API，2026-08-07 验证）
主语言 Jupyter Notebook（推理内核为 PyTorch）
定位 4GB 单卡跑 70B（仓库官方描述）
版本里程碑
时间 事件
2023-11 AirLLM 初始版本
2023-12 v2.0：块级量化压缩，官方称最高 3x 加速
2023-12 补 safetensors + ChatGLM / QWen / Baichuan / Mistral / InternLM 支持
2023-12 v2.5：预取（prefetching）重叠加载与计算
2023-12 v2.6：AutoModel 自动识别模型类型；v2.7：Mixtral
2023-12 v2.8.2：macOS 跑 70B
2024-04 Llama3 70B 在 4GB 单卡原生支持
2024-07 Llama3.1 405B 在 8GB VRAM + 8bit/4bit 量化
2024-08 v2.10：CPU 推理；v2.11：Qwen2.5
2026-06 v3.0：FP8 支持，DeepSeek-V3（671B）约 12GB、Qwen3-235B 约 3GB
2026-07 Kimi K3（2.8T）单卡约 3.72GB 跑通
机制总览：四条主线各管一段
AirLLM 的低显存能力来自三条相互独立、可单独开关的机制，加上 v3.0 对稀疏 MoE 的第四条专用路径。理解它们的边界，才能判断该不该开、开哪条、开了换什么。
机制 换什么 主要瓶颈 何时开
分层加载 用时间换显存 磁盘 IO 带宽 默认开，无法关
块级量化 用精度换 IO 带宽 反量化计算开销 磁盘是瓶颈时开
预取 用线程换延迟 后台线程调度 计算和 IO 可比时开
稀疏 MoE 逐专家加载 用路由换显存 专家调度开销 v3.0 起，MoE 模型默认走
工作原理：四条机制如何配合
分层加载：用时间换显存
大模型推理的本质是逐层矩阵乘法。第 N 层的输出是第 N+1 层的输入，任意时刻只有一层的权重真正参与计算。AirLLM 利用这一点，把整个模型按层切分成 shard 文件存放在磁盘上，推理时只把当前层读进显存，算完立即释放，再读下一层。
这样做的代价是显存占用从"全部权重"降到"单层权重 + KV cache + 激活"。70B 模型 fp16 全量约 140GB，单层 transformer block 权重约 1.7GB（Llama 3 70B 约 80 层），加上 KV cache 和中间激活，4GB 显存仍能容纳。代价是每生成一个 token，都要把全部 80 层从磁盘读一遍，IO 成为吞吐瓶颈。
为什么这条路在 70B 上可行、在 7B 上反而没必要？因为 7B 模型全量 fp16 只有 14GB，24GB 显卡能整体装下，走标准 transformers 推理比逐层换入快一个数量级。分层加载的价值随模型规模放大——模型越大，全量装载越不现实，逐层换入的相对代价越可接受。
块级量化：用精度换磁盘带宽
分层加载的瓶颈在磁盘 IO 一侧，计算端通常有余。块级量化（block-wise quantization）针对的就是这个瓶颈：把权重从 fp16 压到 4bit 或 8bit，磁盘读取量直接减半或减到四分之一，IO 时间相应缩短。
AirLLM 的块级量化有两个设计选择：
只压权重，不压激活。激活值在推理时动态产生，量化会引入误差累积；权重是静态的，可以离线量化好存盘。这种不对称让精度损失主要来自权重 round-to-nearest，可控且可预测。
按 block 量化，不是按 tensor 量化。把权重张量切成小块（block），每块独立计算 scale 和 zero point。相比全 tensor 量化，block 量化能更好适应权重数值分布的局部差异，精度损失更小。
官方称 4bit 量化带来最高约 3x 加速。这个数字主要反映 IO 时间缩短——磁盘读取量降到四分之一，加上反量化开销，净加速约 3 倍。它不反映计算加速，因为反量化后实际计算仍在 fp16/bf16 进行。官方把这套 block-wise 量化方案指向了论文 arXiv:2212.09720。
预取：用线程换延迟
分层加载的朴素实现是串行的：读层 N → 计算 → 释放 → 读层 N+1 → 计算。预取（prefetching）用一个后台线程，在层 N 计算的同时把层 N+1 的权重读进显存，计算和 IO 重叠。
官方在 v2.5 加入预取时称带来约 10% 的速度提升。它有效的前提是计算时间和 IO 时间可比——如果计算极快（小 batch、短序列），预取线程来不及读完下一层，加速有限；如果 IO 极快（NVMe RAID、内存盘），预取本身就成了多余开销。README 注明目前只有 AirLLMLlama2 支持预取。
稀疏 MoE：逐专家流式加载（v3.0）
MoE 模型（如 DeepSeek-V3、Qwen3-235B）的每一层并不全量参与计算，而是由路由网络为每个 token 挑出少数几个专家。v3.0 据此把"整层加载"改成"只加载被路由到的专家"——单个 token 实际用到的专家数远小于层内专家总数，显存占用随之骤减。这也是 671B 的 DeepSeek-V3 能压到约 12GB、235B 的 Qwen3 能压到约 3GB 的原因。
总览表里那四条，作用在流水线的不同阶段：分层加载决定显存上限，块级量化决定 IO 时间，预取决定 IO 与计算的重叠程度，稀疏 MoE 进一步压掉未参与计算的专家。它们可以独立调参，但效果上限受最弱一环制约——开了 4bit 量化后若磁盘仍是瓶颈，预取收益就有限。
一次推理如何流过系统
以 70B 模型生成 20 个 token 为例，假设 4bit 量化 + 预取开启，跟踪一次完整推理的流程：
模型加载阶段（首次启动耗时较长，取决于磁盘与网络）：AutoModel.from_pretrained 下载原始权重，按层切分成 shard 文件写入 HF cache 目录。README 提醒切分过程非常耗磁盘空间，需保证 cache 目录有足够空间。70B 4bit 量化后磁盘占用约 35GB。
prompt 编码：tokenizer 把输入文本转成 token ids，放进显存的 KV cache 槽位。这一步在 GPU 上完成，不涉及权重读取。
第一个 token 生成（prefill 阶段）：
主线程读取 layer 0 权重到显存，计算 attention + FFN，输出传给 layer 1
后台预取线程同时读取 layer 1 权重
layer 0 计算完毕，释放显存，主线程拿预取好的 layer 1 开始计算
后台预取线程转去读 layer 2
如此推进 80 层，最后一层输出经 lm_head 得到第一个 token
后续 token 生成（decode 阶段）：每个新 token 都要重走一遍 80 层，区别是 KV cache 已经存了历史 token 的 K/V，attention 计算量随序列长度增长。每个 token 都触发一次完整的 80 层磁盘读取。
20 个 token 完成：总耗时约 4-6 秒（社区报告值），其中 IO 占大头，计算占比随序列长度上升。
这个流程里有一个反直觉的细节：生成长序列时，AirLLM 的单 token 延迟会随序列变长而上升，因为 attention 计算量在增长，而 IO 时间基本恒定。这与 vLLM 等 batch 推理引擎的行为相反——后者主要受 batch 大小影响。
性能特征：数字在测什么
社区报告的"70B 4-6 秒 / 20 token"主要测的是单请求 decode 阶段的端到端延迟，包含磁盘 IO + 计算 + 反量化开销。它反映的是 AirLLM 在消费级硬件（NVMe + 4-8GB 显卡）上的典型表现。
从这些数字里能推出什么：
AirLLM 适合交互式或离线场景，单次生成几十到几百 token 可接受
4bit 量化相对 fp16 的精度损失在多数生成任务上不显著（weight-only 量化的 perplexity 上升通常在个位数百分比，具体数值因模型和量化方案而异）
从这些数字里不能推出什么：
不能推出 batch 推理性能。AirLLM 的设计不支持 batch > 1 的高效推理，因为每层都要为 batch 中每个样本读权重，IO 放大严重
不能推出与 vLLM 的直接对比。vLLM 测的是吞吐（token/s over batch），AirLLM 测的是单请求延迟，两者不在同一坐标轴
不能推出生产可用性。4-6 秒 / 20 token 折合约 3-5 token/s，远低于生产级 chat 服务的延迟要求
快速上手
对于一个创作平台而言，一款好用的Web富文本编辑器是至关重要的，对目前市面上的Web版的富文本编辑器作了一番研究，发现目前Web编辑器主要集中在两种类型: Markdown编辑器和WYSIWYG(所见即所得)编辑器, 两者之争由来已久。下面简要说说两者的优缺点：
Markdown
优点：
专注你的文字内容而不是排版样式，专心写作，这也是Markdown被设计出来的初衷，这对于从vi/vim过来的人来说有种天然的亲切感，同样是书写时手不碰鼠标。
纯文本内容，兼容所有的文本编辑器软件。
可以随时修改你的文章。
可读、直观、学习成本低。
轻松的导出 HTML、PDF 和本身的 .md 文件，有许多高质量的库可供选择。
缺点：
Markdown是扁平结构的，这也导致了Markdown的表现力不够丰富。无法实现精细的排版。
Markdown的标准不一。由于Markdown基本标准支持的格式有限，所以出现了很多不同的扩展，这些扩展没有统一的标准，这导致了兼容性成为问题。
Markdown不是所见即所得的，Markdown需要渲染后才可被真正阅读。
对于写技术文档、备忘录、笔记等就非常适合用Markdown来书写和预览，因为这些注重内容不注重排版。
我个人有写笔记的习惯，我使用VS Code内置的Markdown编辑器来书写和预览我的所有个人文档。
WYSIWYG(所见即所得)编辑器
优点：
表现力丰富，可实现复杂的排版，Web版的MS Office Word就是一个WYSIWYG(所见即所得)编辑器。
所见即所得，编辑时和阅读时可以做到一致。
缺点：
全功能的编辑器实现难度大。
后端存储的字节数比markdown大很多。
书写和排版通常分成两个步骤，通常是先书写后统一排版。
上面分析了Markdown和WYSIWYG编辑器的优缺点，下面分析一下编辑器的选型问题：
首先，选择何种编辑器需要考虑你的平台的受众人群，如果是IT技术人员为主的，采用Markdown编辑器合适。但如果是知乎这类面向普罗大众的创作平台，那么只使用Markdown编辑器就不合适了。因此，知乎的文章编辑器选择了WYSIWYG富文本编辑器，我想它是做了分析与权衡的，从它的产品定位和平台受众来说，它的选择是正确的。
有些创作平台使用了双编辑器，书写文章时可以选择Markdown编辑器或富文本编辑，但这并不完美。难道选择了富文本编辑器， 我就不能在其中使用Markdown？
知乎的文章编辑器在这方面作了一番努力，它称之为Markdown语法识别，使得书写体验尽可能的接近Markdown，不幸的是，它没有做到最佳。目前知乎的编辑器存在的问题：
不支持从Markdown中直接复制粘贴，需要导入文件的形式来兼容Markdown。这对需要从多个Markdown文档中复制部分内容到一篇文章中那简直是灾难，这也是知乎编辑器最大的问题。
支持数学公式，但不支持行内数学公式，这对于数学专业的文章来说排版是个问题。块级数学公式不能居中。
不支持文本删除线
不支持任务列表
不支持上标和下标
不支持文本对齐
表格不支持单元格合并和拆分，不支持手动调整列宽，表格单元格输入有bug，经常新行的单元格中输入时会丢失游标。
表格不支持嵌套
想要输入+ xxx，- xxx，* xxx 麻烦的要死，因为它会强行识别为列表，可有时我就想输入这些文本，不信你可以自己去试试, 其它语法识别也一样，它没有一种使你可以快速放弃转换的操作。
罗列了这么多知乎编辑器的不足之处，知乎的文章编辑器又不开源，想帮它优化也没办法。
于是我决定参考知乎的文章编辑器的功能自己研发一套Web富文本编辑器，我的目标是：采用WYSIWYG富文本模式，这样适用性更广，吸收知乎的文章编辑器的所有优点，同时要支持从Markdown内容中直接粘贴，输入时支持Mardown语法识别。目前已经开发完成，我都还没有为它取好名，广大网友也可以帮我取个名。
前段时间满屏都中国籍学者王虹和邓煜获得数学界的最高荣誉的菲尔兹奖（Fields Medal）的新闻。不过中国籍数学家好像并不一定就是中国数学家吧。
前段时间满屏都中国籍学者王虹和邓煜获得数学界的最高荣誉的菲尔兹奖（Fields Medal）的新闻。不过中国籍数学家好像并不一定就是中国数学家吧。
因为邓煜在北大只读了两年本科，随后转学至美国麻省理工学院（MIT），之后获得普林斯顿大学博士学位，目前担任美国芝加哥大学数学系教授。
王虹本科最初就读于北京大学地球与空间科学学院，大二转入数学科学学院。她曾公开提到，自己当时成绩处于中下游，一度感到比较受挫，后来保研和直博都没有成功。此后，她赴法国巴黎综合理工学院攻读硕士，又在美国麻省理工学院获得博士学位，现为法国高等科学研究所终身教授。
虽然王虹和邓煜都曾是北京大学数学科学学院2007级本科生，北大是他们学术道路的重要起点，但两人真正奠定国际数学成就的培养和科研阶段，主要是在欧美高校和科研机构完成的，跟北大的教育培养有多大的关系？
（网图）
北京大学是中国最顶尖的大学之一，也是世界知名的综合性大学。北大创办于1898年，历史悠久，拥有深厚的人文、科学和社会科学传统。“思想自由、兼容并包”的精神也一直影响着中国现代大学。多年前曾参观过燕园，印象深刻。
这些年随着中国经济的发展，不少重点大学都在朝着“世界一流大学”的目标迈进，很多人有名校情结。但一所真正的世界一流大学，靠的不只是漂亮的校园、先进的实验室和一流的硬件设施，更重要的是拥有顶尖的学者，营造鼓励创新、尊重学术自由、宽容不同观点的学术环境和大学精神。
早在民国时期，中国就有过几所享誉国际的一流大学，而大名鼎鼎的中国历史上第一所大学圣约翰大学（Saint John’s University）就是其中之一。
圣约翰大学以高度国际化的教育理念和鲜明的职业导向享有盛誉。它的影响力不仅遍及上海和全国，在欧美也颇有知名度。圣约翰大学还曾被誉为近代中国的“外交家的摇篮”“东方剑桥”和“东方哈佛”。
（网图）
这次正好离我们住的环球港不远，就去了下圣约翰大学旧址——现在的华东政法大学。原来同事的太太就是这里毕业后和别人一起开的法律事务所，做得风生水起，很成功。
相比有些大学，去华东政法大学参观，不用登记、预约，被不少媒体称为国内开放度最高的高校之一。
走在中山北路校区一带，现在仍然很容易感受到那段老上海大学的气质残影。大片草坪、红砖楼、拱形窗、略带西式哥特风格的建筑线条，让人很难把它和现代都市大学完全等同起来，它更像一段被保存下来的历史章节。这里被人们称为上海最适合拍照的大学。
高大的法国梧桐把道路遮成一条条绿色隧道，阳光从叶片缝隙洒下来，落在旧建筑的墙面上，形成一种很安静的斑驳感。
走到一些旧建筑附近，你会注意到墙面修复过，但仍尽量保留原来的风格；窗框不新，但结构依旧稳固。
圣约翰大学由圣公会所属1865年成立的培雅书院和1866年成立的度恩书院于1879年合并而成，名为圣约翰书院（St. John’s College），后改名为圣约翰大学（St. John’s University）。该校在1892年起开设大学课程，是中国历史上第一所大学。建校比老爸的天津大学（北洋大学堂）和北京大学（京师大学堂）都要早一些。创建时，还没有中国高校的代表北大与清华，可见其历史悠久。
最近正好在看何冰演的电视剧《江海潮生》，讲的是清朝状元，企业家，教育家张謇创办通州师范学校（中国第一所师范学校），复旦公学（现复旦大学前身），国立东南大学（现南京大学，东南大学等）等一系列高等学府的故事，颇为感慨。
圣约翰的校训是“Light and Truth”（光与真理），校刊称：“我们要使圣约翰大学成为中国之光和真理的火炬，没有再目标更崇高的了。” 可以说，中国的大学教育开始于教会大学，而教会大学则开始于圣约翰大学。
所谓的与国际接轨的问题，圣约翰大学在100年前就实施了。 20世纪上半叶，圣约翰大学几乎是中国最早、也是最彻底实行英语教学的大学之一。从课程设置、教材选择到教学方式，基本都是直接对标欧美大学。相比之下，当时的北京大学、清华大学虽然也积极吸收西方教育理念，但整体走的还是中西融合的路线，不像圣约翰那样高度西化。
圣约翰大学的学科逐渐完善，尤其是商科、法学、医学等应用领域实力突出，在上海这个国际化城市中占据重要位置，培养出大量通晓英语、熟悉西方制度的精英人才。1913年起圣约翰大学开始招收研究生，1936年起开始招收女生。
在抗日战争期间，虽然学校运作受到冲击，但仍尽力维持教学。
抗战结束后短暂恢复教学。1949年，圣约翰大学设有文、理、医、工、农、神6个学院及附属中学，是当时中国最全面的综合性大学。当年的社会声望非常高，不少人甚至把它称为“中国第一大学”。
1949年中国中央政府变更后，在1952年全国高校院系调整中，圣约翰大学难逃厄运地被拆分，其院系并入其他高校体系（如复旦大学、上海交大、华东政法等大学），从此不再作为独立大学存在，一个名校不复存在。
圣约翰不仅是当时中国最著名的大学之一，也是职业导向非常鲜明的高等学府。它的毕业生在社会上很受欢迎，尤其是在上海这样的国际都市。无论是外资企业、银行、航运、法律还是外交领域，都有不少圣约翰校友，许多人后来还出国深造。培养了一大批在近代中国政界、商界、学界和文化界有影响力的人物。注重培养实务型人才和职业精英，对近代中国社会产生了深远影响。
下面是一些有代表性的校友：
顾维钧： 近代中国最著名的外交家之一，参加巴黎和会、长期活跃于国际舞台，是典型的圣约翰式精英。
宋子文： 民国财政与外交核心人物之一，历任国民政府财政部长、中央银行总裁、行政院长、中国银行董事长等等。是宋氏家族的重要成员 。他在任财政部长时被授予了圣约翰大学法学博士学位。
贝聿铭： 世界级建筑大师。
林语堂： 著名作家、学者，把中国文化介绍到西方世界的重要人物之一。
邹韬奋： 新闻出版界的重要人物，对近代中国公共舆论有很大影响。
颜福庆： 中国现代医学教育的重要奠基人之一，与圣约翰医学院体系密切相关。
张伯苓： 教育家、体育活动家及政治人物。南开大学、南开中学的创始人，西南联大创始人，中华全国体育协进会理事长、中华民国考试院院长。
荣毅仁： 企业家，曾担任中华人民共和国副主席，被称为“红色资本家”。
严家淦：中华民国财经专家、曾任中华民国经济部部长、财政部部长、行政院院长，副总统，和总统。
LD有个亲戚是无锡唐氏家族成员，40年代末毕业于上海圣约翰大学，毕业后进入上海一家外资洋行工作，原本前途一片光明。但1952年圣约翰大学停办后，他便很少再提起自己的母校。到了文革时期，更是处处低调谨慎，所幸没有受到太大的冲击。只是由于时代的变迁，终究未能充分施展自己的才华，聪明才智没有在事业上得到应有的发挥，有些令人惋惜。不过，与圣约翰大学历史上第一位中国校长涂羽卿在“三反”“五反”、反右和文革中遭受的精神与肉体的双重折磨，最终被迫害致精神失常、含恨离世的命运相比，他还是幸运的。。。。。。
As more users discover products through LLM-powered search, companies like Vercel, Anthropic, Supabase, and Windsurf are seeing meaningful traffic driven by AI tools. An llms.txt file provides structured instructions that help these systems index and interact with your site, making that discovery possible
Companies breaking through AI-driven discovery have implemented an llms.txt file. Vercel reports that 10% of new signups now come from ChatGPT, and teams like Anthropic, Supabase, and Windsurf see users finding their products through LLM-powered search.
An llms.txt file gives AI systems structured guidance on how to index and interact with your site, making this kind of discovery possible. Making your documentation discoverable to AI tools like ChatGPT, Claude, and Perplexity doesn’t need to soak up hours of manual work. By pasting your documentation URL into our free llms.txt generator, you’ll get a properly formatted starter file based on your structure in seconds—no signup required.
Get started with your llms.txt now
This guide walks through what the generator creates, why llms.txt matters for AI-driven growth, and three approaches to generating and maintaining your llms.txt file.
What this llms.txt generator creates
Our free llms.txt generator analyzes your documentation structure and creates a lightweight Markdown file optimized for LLM consumption.
The tool outputs AI-optimized documentation with your site title, a blockquote summary, organized content sections, and key page links with descriptions. This structure follows the llms.txt format specification while making it easy for you to customize based on your documentation specifications.
Example llms.txt
Think of it as a starting template. The generator handles the formatting and structure, giving you a foundation you can refine to match exactly how you want AI tools to understand and present your product.
Manual vs automatic llms.txt generation
Creating an llms.txt file manually gives you full control over the content and structure, which is useful for highly customized documentation. However, that process is time-consuming and error-prone, especially for large or frequently updated docs.
Our automatic llms.txt generator simplifies this process by analyzing your existing documentation and generating a compliant file in seconds. You get a correctly structured, AI-ready llms.txt file without worrying about formatting or missing metadata, while still having the flexibility to tweak it manually if needed.
Why llms.txt matters for AI discoverability
As AI-powered search becomes a common way for developers to find tools, having documentation that LLMs can read is critical. Vercel went from less than 1% to 10% of signups coming from ChatGPT in six months. That represents thousands of developers receiving accurate answers from an AI assistant based on Vercel’s documentation and converting to paid customers.
When Anthropic asked us at Mintlify to implement llms.txt for our documentation, it reinforced what we were seeing across our customer base: AI assistants are becoming a primary discovery channel for technical products. To test our hypothesis, we’ve tracked LLM crawler behavior and observed consistent traffic from ChatGPT, Claude, and Perplexity crawlers accessing llms.txt files multiple times per week.
This matters for your documentation because AI needs structured, accurate information to provide the right answer to users. Without llms.txt, the AI might pull from outdated Stack Overflow threads, competitor documentation, or even hallucinate an answer entirely.
An llms.txt file creates a direct line between your documentation and the AI tools your users rely on. It directs LLMs to read the right complex HTML files and marketing-heavy pages.
Three ways to generate llms.txt files
You’ve got a few solid options for creating and maintaining your llms.txt file, depending on your team’s size, resources, and how much hands-on control you want. For a full comparison of platforms and plugins that support llms.txt, see our best llms.txt platforms guide.
Use an llms.txt generator
Best for: Small documentation sites, teams getting started with llms.txt, or anyone who wants immediate results without writing code.
How it works: Use our free llms.txt generator tool to create your initial file. Paste in your docs URL, download the generated template, customize the sections and descriptions, and host it at your root domain.
Benefits:
No technical setup required
Get started quickly
Full control over content and structure
Works with any hosting platform
Tradeoffs: When you add new pages or restructure your docs, you’ll need to update the llms.txt file manually. For documentation that changes frequently, this can become a maintenance burden.
Script-based automation (DIY approach)
Best for: Engineering teams comfortable with scripting, documentation sites with frequent updates, or teams wanting automated updates without committing to a platform.
How it works: If you’re already running build scripts or CI/CD pipelines for your documentation, you can integrate llms.txt generation directly into that workflow. A build script reads your documentation structure and outputs a formatted file on each deploy.
Example script-based automation
This works well with static site generators like Docusaurus, Next.js, or VitePress, where you can hook into the build process.
Benefits:
Automatically stays in sync with your docs
Full control over generation logic
No ongoing manual updates
Tradeoffs: Requires engineering effort to build and maintain. Generation logic must be updated as your docs evolve.
Platform-native automation
Best for: Teams who want zero-maintenance AI optimization, documentation platforms handling multiple products, or companies treating docs as a strategic growth channel.
How it works: By using Mintlify’s built-in llms.txt generator, every time you publish documentation changes, the platform regenerates your llms.txt file — along with llms-full.txt and markdown variants optimized for different AI use cases.
Benefits:
No scripts or configuration to maintain
Always stays in sync with live documentation
Supports multiple AI-optimized formats out of the box
Tradeoffs:
Requires using a documentation platform
Less low-level control than a fully custom script, however Mintlify customers are able to override the generated llms.txt with manual updates If you're in high-growth mode and documentation is becoming a user discovery channel, this approach removes llms.txt from your maintenance burden entirely — freeing up engineering time to build products instead of maintaining doc infrastructure.
How to implement your llms.txt file
Once you’ve generated your file using any of the methods above, you need to make it accessible to AI tools. Here’s the implementation process:
Step 1: Save your file as plain markdown Name it exactly llms.txt—no .md extension or alternate naming. The file should contain only Markdown-formatted text.
Step 2: Place it at your root domain Host the file at yourdomain.com/llms.txt, similar to how robots.txt and sitemap.xml work. AI tools expect to find it at this standard location.
Step 3: Ensure it serves as plain text The file should render as raw Markdown, not wrapped in HTML. If you’re using a static site generator, configure your public folder or routes to expose the file directly.
Step 4: Handle subdomain documentation If your docs live at docs.yourdomain.com or yourdomain.com/docs, you can also host the file at that subpath (e.g., /docs/llms.txt).
Step 5: Verify accessibility Navigate to your llms.txt URL in a browser. You should see plain Markdown text, not a 404 or HTML-wrapped version.
Choosing your llms.txt approach
The right generation method depends on your documentation maintenance pattern and how aggressively you’re pursuing AI-driven discovery.
Choose the manual llms.txt generator if you have a small documentation site that doesn’t change frequently, or if you’re just getting started with AI optimization and want the simplest path forward. You can create your llms.txt file quickly and start capturing AI search traffic almost immediately.
Choose script-based automation if you already have build pipelines in place, your documentation updates regularly, and your team has the engineering bandwidth to maintain generation scripts. This gives you control while eliminating manual updates.
Choose platform-native automation if you want AI optimization handled automatically, you’re managing documentation at scale, or you’d rather invest engineering time in your product than documentation infrastructure. This is the zero-maintenance option.
 Whether you’re using our free llms.txt generator or automating with scripts, implementing llms.txt is one of the most effective ways to improve how AI tools surface and represent your product. The question isn’t whether to do it, but how quickly you can get it live.
Already using Mintlify? Your llms.txt files are automatically generated and hosted.
Not using Mintlify yet? Learn more about maintaining documentation that stays AI-optimized by default.
Looking beyond llms.txt? Model Context Protocol (MCP) servers represent the next evolution of AI-native documentation, enabling even deeper integration with AI assistants.
最近，系统做了升级，从3年前的版本 1.9到了现在的3.13，这是最新版本，其他功能虽有所加强，但外面看来不明显，但编辑器变化比较大，就此做几点说明：
这个新版编辑器，为了给设计网站的人一些自由度，在编辑器设计时，在左边保留HTML的 raw data 输入，这也是编辑器的输入的区域，在右边给出一个HTML效果的界面，这样可让设计者知道发布之后的效果，任何修改只能在左边的编辑框进行。
把鼠标指向编辑器菜单上的任意图标，会有该图标的功能提示。
上载图片时，按顶部菜单上的图片按钮，就会提示选择本地文件上载，上载完毕后，在左边的编辑框里还是一堆字符串，但在右边的预览框里能看到图片的效果。
对于熟悉HTML 代码的用户而言，这个功能增强了发布文章的多元性，你可以随意植入一段 漂亮的HTML5 代码来完成很多HTML5的动态网页，但对于不熟悉 HTML 代码的用户，你会觉得左边的编辑框，是一团乱麻，所以，在确保文字的正确性前提下，不熟悉HTML代码的用户，不要乱修改左边的HTML 代码，只要右边显示效果正确就行了。
如果有任何关于编辑器的问题，可以在本贴下留言，我们将尽快去解决相关问题。
这个网站最开始建立是在10年前的2012年，2015年后因为种种未能预料到问题暂停运营。在10年前，我们的运营 目标是一个海外华文的门户网站，所以除了每天的各地新闻，包括当时跟国内一些媒体合作共板新闻等，主要还有博客和论坛。随着社交媒体的兴趣，写博客不再是主流，取而代之的是微信，推特等即时通讯，有时间的朋友继续在写文章，写博客。所以，新汉纳的设计较过去有所调整，虽然我们设计了几个论坛板块和互动博客，但这些不是我们主推的功能，我们主推的功能有三。
1. 新汉纳为大家提供一个自由发文的平台，现在发文受各种平台审查的限制，经常因为关键词而发不出文章，有些网络的好文章，会因为敏感词突然被河蟹。在这里，我们为大家提供一个自己发文章和保存好文章的自助平台。
2 新汉纳提供一个和社交媒体，如微信和推特链接互动的桥梁功能，用户可以在这里发文，然后在转发到社交媒体去，如推特，Facebook或者微信等，转发微信，因为各自手机的浏览器不同，目前发现最好的效果是先在手机浏览器打开这里文章，然后分享到微信，有些手机到这一步，就可以在微信群里生成豆腐块，如果没有生成豆腐块，可在从微信群里打开浏览器分享到微信里的收藏，然后从收藏再分享到微信，此时的效果就很好了。
3. 现在网络上假新闻很多，文字新闻如有疑问，可到主流媒体去查一下还可以判别，对于图片和视频，很难识别真假。我们在这里提供一个上载可疑内容栏目，用户把可疑内容上载到这个栏目，我们会有专家团队帮助识别。
我们直接粘贴发布就行。下面是效果
https://youtu.be/XcQjW3mI49E
2. 本网站由于目前空间的限制，可上载12M以内的图片或者小视频，按编辑框的图片按钮上载即可。尽量使用外网链接。
3. 我们还支持下列外网的视频链接，包括 Facebook，vimeo, Vine, Twitch Live, Dailmotion,Spotify 等等，这里不是每个平台都测试过，有问题可以在下面留言
4. 后续会支持YouTube的直播，因为我们的服务器在美国，暂时不考虑支持直播服务器在中国境内的直播。
在本站发文十分简单，在任何页面，只要看到有发表文章的按钮，如下图所示，点击进入编辑框，就可以写文章，添加图片等
编辑完后，需要发布时，选择一个栏目，再选择好标题，按“提交”键，如下图所示
如果要回复某人的帖子，每篇文章下面有一个快速回帖，写完点击回帖即可，见下图：
在本网站注册是最世界上简单的事，就是选择一个用户名，选择一个秘码，再确认一下密码，就完成了，一分钟搞定的事，如下图所示。但如果要想得到更好的户体验，还需要提供一个真实的邮件地址，可以用来跟我们系统通讯的那种。
为了跟过去的老网站兼容，我们把老网站的链接放到了上面菜单的最后一个外网链接的按钮，
,点击这个按钮，选“汉纳”就可以进入老网站，如果还记得密码，可以登录账号，也可直接 键入http://lwz.newhana.com 直接进入。
这里第二个按钮，
，是跟系统使用相关的文档，包括本文档，可以在后面跟帖提问。而其他隐私，使用条款·是不可修改的文档。