前面几楼把 SDK 超时重试、分段上传、CDN 回源这些都讲到了，我补几个「配置看着没问题、但一定会踩」的点，都是权限与元数据层面的。一、桶策略和对象 ACL 同时存在时，以哪个为准。OBS 的访问判定不是简单的「谁宽松用谁」：桶策略是资源级授权，对象 ACL 是对象级授权，最终是合并判定——但 IAM 里的显式 Deny 优先级最高，会覆盖两者。所以会出现「桶策略写了允许匿名读、对象 ACL 也是公共读，访问还是 403」的情况。排查顺序应该是：先看 IAM 有没有显式拒绝，再看桶策略，最后才看对象 ACL。二、预签名 URL 的坑集中在三处。① 生成时用的 AK/SK 必须和桶归属同一账号，用委托或临时密钥生成时要保证签名里的 token 一起带上；② 有效期不要设太长，公开分发的链接建议控制在几分钟到几小时；③ 一旦 URL 里带了自定义 header 的签名（比如强制 Content-Type），客户端请求必须原样带上那个 header，否则签名不匹配，返回 403 而不是更明确的提示。三、对象名不是目录，但列举会「像目录」。用 prefix 加 delimiter 列举时，返回的 CommonPrefixes 是虚拟目录，不会出现在 Contents 里。新手常按「返回条数 = 对象数」来核对，结果永远对不上。正确做法是分别累加 Contents 与 CommonPrefixes，并且记得处理分页：单次列举有上限，要按 NextMarker 循环，否则对象多了会静默截断。四、上传不带 Content-Type 会引起两类问题。一是浏览器直接访问时被当成下载而不是预览；二是接了 CDN 后缓存键与压缩策略可能失效。建议上传时显式指定 Content-Type，并在覆盖同名对象后做一次 CDN 缓存刷新，否则用户拿到的还是旧文件。五、跨域（CORS）配置漏了 ExposeHeaders。前端直传时如果需要读取 ETag 做校验，桶的 CORS 规则里必须把 ETag 放进 ExposeHeaders，否则浏览器里读到的永远是 null——很多人据此以为上传失败，其实文件早就在桶里了。六、快速自查顺序。遇到 403 先分辨是「身份不对」还是「权限不够」：用同一组凭证调一次列举桶，能列出来说明身份没问题，那就去查桶策略与对象 ACL；列不出来就直接查凭证与 IAM。遇到 404 先确认 region 与 endpoint 是否匹配，跨 region 访问常常返回的不是明确错误。遇到上传慢或中断，回到分段与超时参数，而不是先换网络。一句话总结：OBS 的坑一半在「怎么把文件传上去」，另一半在「传上去之后谁能看、怎么被缓存、怎么被列举」。权限判定按 IAM → 桶策略 → 对象 ACL 的顺序看，元数据把 Content-Type、CORS、缓存刷新三样配齐，能省掉大部分「明明传成功了却用不了」的排查时间。

结论：OBS 的坑集中在四件事——权限、区域与 endpoint、对象键、计费规则。把这几项先对齐，大部分“用不了”都会消失。一、403 优先查签名与权限先确认三件事：endpoint 是否与桶所在区域一致、AK/SK 对应的 IAM 用户是否有该桶权限、本机时间偏差是否超过 15 分钟。第三条最容易被忽略，签名带时间戳，时钟漂了签名直接失效，但报错同样是 403，看起来像权限问题。桶默认私有，匿名访问 403 是正常现象。要分享单个对象，用带过期时间的临时签名 URL，不要为了省事把整个桶改成公共读。公网可读的桶一旦被采集站引用，流量费会以倍数增长，这类账单事故比配置错误更贵。二、404 分清是桶还是键NoSuchBucket 多半是桶名或区域写错——桶名全局唯一，创建后区域不可改，选错只能新建桶迁移。NoSuchKey 先检查对象键的大小写和 URL 编码，中文、空格、加号没编码是最常见的原因。OBS 没有真目录，控制台里的“文件夹”只是对象键前缀，删掉前缀不等于删掉里面的对象。三、覆盖与版本控制同名上传默认直接覆盖，未开版本控制无法找回。生产桶建议开版本控制。开了之后还要记住：控制台点“删除”只是打一个删除标记，旧版本仍在桶里继续计费，要真正释放空间，得在生命周期里再配一条“删除过期版本”。四、分段上传的残片大文件传一半中断，已上传的分片不会出现在对象列表里，但照样占空间、照样计费。给桶配一条生命周期规则，把“未完成的分段上传”设成 7 天过期清理，这一步不花钱但能省下不少隐性成本。五、计费不止存储一项请求次数、外网流出流量、归档取回费用都可能单独计费。低频存储最小存储时长 30 天、归档 90 天，文件存三天就删仍按最短时长收费；归档对象下载前还要先发起恢复，恢复有时延也有费用。建议上线前先去费用中心看一遍账单构成，而不是只看容量数字。排查用的两条命令：obsutil ls obs://桶名/前缀 列对象，obsutil stat obs://桶名/对象键 看大小、存储类型和元数据。比起在控制台逐层点，这两条能快速定性是权限、区域还是键的问题。最后一个建议：新项目先用一个测试桶，把建桶、上传、授权、生命周期、版本清理、删除完整走一遍，账单核对无误再上生产桶。

先说结论：现成的通用 PDF 语料是有的，但几乎没有能直接拿去训练大模型的——真正能用的语料通常需要自己筛 + 自己洗，公开数据集只解决“起步量”，不解决“质量”。一、可用的公开来源（按合规优先级）1. 学术与开放语料：arXiv 的批量下载（有官方 S3 全量镜像，注意遵守其使用条款与频率限制）、PubMed Central 的 Open Access 子集、Common Crawl 里已经抽出的 PDF 子集。这几类来源许可相对清晰，适合做继续预训练的基础语料。2. 政府与公共机构文档：各国政府开放数据平台、标准文档、年报、法院判例公开库。数量大、排版规整，但领域分布非常偏（法律、政务多，工程少）。3. 企业内部文档：最贴合业务，但必须先解决合规与脱敏，不能混进对外开放的模型。二、公开数据集为什么常常用不上1. 版式噪声：PDF 里双栏、表格、页眉页脚、脚注、水印都会污染抽取结果，直接 pdfminer 出来的文本可读性很差。2. 重复与低质：网页转 PDF 的语料重复率极高，同一份白皮书可能在几十个站点各存一份，不去重会让模型记住重复片段。3. 许可不明：很多聚合站抓来的 PDF 并没有再分发许可，用于训练存在法律风险，这条比技术问题更要紧。三、我实际用的处理链1. 抽取：先用 PyMuPDF（fitz）拿到带坐标的文本块，比纯文本抽取更容易判断栏位；扫描件走 OCR（PaddleOCR 或 tesseract），先小样本评估准确率再全量跑。2. 清洗：按行合并断行、去掉页眉页脚与页码（用重复率判定：同一行文本在超过 60% 的页面出现即视为页眉页脚）、合并连字符断词、保留段落结构。3. 去重：先用 shingle + MinHash 做近重复检测，阈值取 Jaccard 0.8 左右；再做精确去重（hash 完全一致）。这一步通常能砍掉 20%–40% 的体积。4. 质量过滤：按语言比例、平均句长、符号占比、重复 n-gram 比例打分，去掉乱码页和目录页。5. 切分与配比：按文档边界切块而不是固定字符数，保留标题层级；通用语料与领域语料按 7:3 左右配比，避免领域过拟合。四、几个容易踩的坑1. 别只看 token 总量：10 亿 token 的垃圾语料不如 1 亿 token 的干净语料，评估要用下游任务而不是看体积。2. 表格和公式要单独处理：直接拍平成文本会丢掉语义，公式建议转 LaTeX 或直接丢弃，不要留半成品。3. 保留来源元数据：每条样本带上来源、许可、抓取时间，后期要按许可过滤或下架时才有办法。4. 抽样人工检查：每批随机抽 100 条读一遍，比任何自动指标都能早发现问题。五、小结现成语料能解决“从 0 到 1”，但从 1 到可用必须自己走一遍抽取、清洗、去重、过滤、配比。这五步里最容易被低估的是去重与许可——前者直接影响训练效果，后者直接影响能不能用。

前面几楼把「定型 → 定量 → 计费方式 → 每月复核」这条主线讲得很完整了。我补一个反向角度：怎么用三步验证把「已经选对」这件事证明出来，而不是上线后靠感觉判断。因为选型真正的成本不在第一次买错，而在买错之后没人发现、一直按错规格付钱。一、先算清一个数：单位有效请求成本多数人比较规格时比的是「每月多少钱」，但这个数不可比——大规格可能更贵却扛了十倍流量。更可比的指标是「月账单 ÷ 月成功请求数」。同一个业务，2 核 4G 的账单可能是 300 元、月请求 3000 万，单位成本约 1 分/千次；4 核 8G 的账单 600 元、月请求 3500 万，单位成本反而更高。这个数字一算出来，「是不是买大了」立刻有答案，而且不需要压测。二、用一周的 P95 延迟做拐点判断，不要看平均值平均值会把长尾抹平：平均响应 120ms 看起来很好，P95 可能是 1.8 秒，用户感受完全两样。真正决定要不要升规格的，是「P95 延迟随并发上升的第一个拐点」。做法很简单：压测时从 50 并发起，每轮加 50，记录每轮的 P95，画一条曲线。曲线开始明显上扬的那个并发数，就是当前规格的实际承载上限；按业务峰值 QPS × 1.5 反推所需实例数，比凭经验拍一档准确得多。三、把「降配」也纳入常规动作，而不只是升配实务里升配很容易批，降配却总被担心「万一不够」。建议给自己定一条可执行的规则：连续四周高峰期 CPU 均值低于 25%、P95 延迟没有恶化，就降一档观察两周；两周内没有告警和超时，就固定下来。这条规则的价值是把「降配」变成一个不需要开会讨论的常规操作，长期省下来的钱比一次优化多得多。四、几个容易算错的细节带宽和磁盘要单独建账。很多账单超支不是实例规格，而是出方向带宽打满后按流量计费的部分；把带宽用量单独看一条曲线，问题会立刻暴露。突发性能型实例的 CPU 积分要盯。它在低负载时攒积分、高负载时消耗，一旦积分耗尽就会被限制到基准性能，表现是「明明 CPU 利用率不高，接口却变慢」。这类实例只适合流量有明确波峰波谷的场景，不适合长期跑在 50% 以上。数据库不要和应用抢同一台机器。同机部署时，一次慢查询会同时拖垮应用和数据库，排查时又互相掩盖；规格省下来的钱，通常会以一次故障的形式还回去。一句话：比价要比起单位有效请求成本，判断拐点要看 P95 而不是平均值，降配要有可执行的常规规则。这三件事做完，选型就不再是一次性的赌博，而是一个可以持续优化的循环。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。