为什么摘要接口特别适合用 Luna 开场做过后端服务的都知道摘要类接口的痛点从来不是能不能做而是能不能在用户耐心耗尽之前给出一个够用的结果。GPT-5.6 三档模型里Sol 强但贵、Terra 均衡而 Luna 的定位恰恰是高速低成本——输入 0.20 美元/百万 token、输出 1.20 美元/百万 token 的定价加上家族中最快的响应速度让它天然适合摘要这种高频、低单条价值的场景。但快和便宜的背面是开发者必须回答的问题质量底线在哪里什么情况下该换 Terra这篇文章基于实际踩坑经验聊聊怎么在 Luna 上跑摘要接口并找到适合自己业务的延迟-质量平衡点。对奇点智能大会2026的完整技术议题感兴趣可前往奇点大会官方渠道免费获取PPT详细资料。不同长度文本的摘要质量抽样评估摘要任务不能只看通不通顺得按文本长度分层测。我的做法是建立三级评估体系定期抽样回测。短新闻 1000 字Luna 在这类文本上表现相当稳定。信息密度高、结构清晰Luna 的低延迟优势能完全发挥。抽样时我关注两个指标关键信息覆盖率人工标注 5-10 个核心事实点看摘要是否遗漏和冗余度是否存在重复表述。实际经验是短新闻摘要的可用率能到 90% 以上temperature 设 0.1-0.3 即可reasoning effort 用low完全够用。长论文3000-8000 字这里开始出现明显分水岭。Luna 的上下文窗口相对紧凑处理长文本时容易出现**“头重脚轻”**——开头部分摘要详细后半部分一笔带过。我的评估方法是将论文按章节切分分别标注每章核心贡献再对比摘要的分布均衡性。发现当文本超过 5000 字时Luna 的章节覆盖完整率会从 90% 降至 70% 左右。此时需要权衡是接受这个衰减还是在预处理阶段做分段摘要再合并。多文档聚合 10000 字或跨文档这是 Luna 的短板场景。多文档涉及信息去重、冲突消解和优先级排序Luna 的轻量架构在这类任务上质量波动明显。我的做法是前置做文档筛选先用 Luna 快速提取单文档关键句再对关键句集合做二次摘要——但这其实已经接近 Terra 的直接处理效果成本反而上升。抽样评估的实操建议每周随机抽取各长度档位 50-100 条请求人工标注自动评分如 ROUGE-L、BERTScore双轨并行建立质量基线数据库。一旦发现某档位连续两周低于阈值触发模型或策略调整。延迟敏感场景的流式输出配置摘要接口的用户体验很大程度上取决于第一个字什么时候出现。Luna 本身的首 token 延迟已经很低但流式输出streaming的配置细节会显著影响感知速度。我的生产配置如下responseclient.chat.completions.create(modelgpt-5.6-luna,messages[{role:user,content:prompt}],temperature0.2,reasoning_effortlow,# 摘要任务不需要深度推理streamTrue,# 关键启用流式输出max_tokens512)几个关键调参经验temperature摘要任务宁低勿高。0.1-0.3 是 sweet spot再高容易出现发挥过度生成原文没有的主观评价。reasoning effort摘要明确用low。这是 Luna 的默认档但显式指定可避免某些 SDK 版本的回退问题。max_tokens根据文本长度动态计算避免预留过多导致延迟。短新闻 256 token 足够长论文给到 512-768。流式输出的另一个技巧是前端渲染策略。不要等完整响应收到第一个 sentence 或第一个完整语义单元就开始渲染配合打字机动效用户感知延迟能降低 30% 以上。与 Terra 的 A/B 测试设计Luna 够不够用不能拍脑袋得用数据说话。我的做法是对 Luna 和 Terra 做用户无感知分流核心关注两类指标。分流方案按用户 ID 哈希取模10% 流量走 Terra90% 走 Luna。注意不是随机而是固定用户固定模型避免同一用户前后体验不一致。importhashlibdefselect_model(user_id:str)-str:hash_valint(hashlib.md5(user_id.encode()).hexdigest(),16)returngpt-5.6-terraifhash_val%10010elsegpt-5.6-luna核心对比指标指标类型具体指标关注原因延迟P50/P95/P99 首 token 延迟、总耗时Luna 的理论优势是否兑现成本单次请求平均 token 消耗、美元成本Terra 贵 2.5 倍质量提升是否值得用户行为摘要展开率、复制率、相关功能留存质量差异是否影响用户实际使用人工抽检每周抽样 200 条盲评质量分弥补自动指标的盲区一个反直觉的发现在我们的知识库产品里Terra 组的摘要展开率只比 Luna 组高 3%但单次成本是 2.5 倍。这个差异不足以支撑全面切换但我们会把 Terra 保留给付费企业客户作为增值服务选项。自动降级触发条件与兜底策略再优化的配置也挡不住 corner case。我的系统里设了三层自动降级第一层实时质量信号摘要长度异常输出 token 输入的 1% 或 50%重复 token 比例过高 30% 视为生成崩溃包含特定兜底关键词如无法总结内容过长等模型拒答话术命中任一条件当前请求实时重试 Terra并标记 Luna 异常样本。第二层批量质量监控每日聚合前一天的摘要请求计算平均 BLEU/ROUGE 分数对比原文用户主动反馈摘要质量差的比例摘要功能 7 日留存率任一指标连续 3 天低于基线 10%自动提升 Terra 分流比例至 30%并触发告警。第三层人工介入每周质量评审会上人工抽检各模型输出决定是否需要调整模型版本、prompt 模板或降级阈值。调参经验temperature 和 reasoning effort 的取舍最后分享两个参数的调参心得这是最容易踩坑的地方。temperature场景推荐值原因严格提取式摘要0.0-0.1最大限度忠于原文减少幻觉一般新闻摘要0.2-0.3平衡流畅度与准确性创意性摘要如营销文案0.5-0.7可适当发挥但需人工审核Luna 的 temperature 敏感度比 Terra 更高。同样的 0.5Terra 可能只是更活泼Luna 可能就开始编故事。建议从低往高调找到质量拐点。reasoning effort摘要任务几乎永远用low。曾经试过对长论文用medium希望提升逻辑连贯性结果是延迟增加 40%、成本上升但质量提升肉眼难辨。对于 Luna 这种轻量模型推理深度的边际收益递减很快不如把算力留给更合适的场景。写在最后Luna 不是万能解药但在摘要这个场景里它提供了一个足够好的默认选项。关键不是追求单点最优而是建立监控-评估-降级的完整闭环用 Luna 跑量、用 Terra 保底、用数据决定什么时候该换。目前我的生产环境是 85% Luna 10% Terra 5% 实时降级这个比例会根据每周的 A/B 结果动态微调。如果你的摘要接口还在用统一模型处理所有请求不妨从分层策略开始试起。推荐阅读最后说一件事2026 奇点智能大会终于要和大家见面了。11 月 20-21 日·北京奇点智能研究院联合 CSDN把两场技术大会放在了同一个时空里奇点智能技术大会始于 2016——聊大模型、AI Native、企业级 AI 落地、多模态与世界模型C 及系统软件技术大会始于 2005——聊现代 C 演进、AI 算力与推理优化、高性能低时延系统。为什么要放在一起因为我们越来越相信——上层 AI 应用的爆发离不开底层系统软件的支撑而底层技术的演进方向也正在被 AI 重新定义。这次大会汇聚 70 位技术专家、18 个主题、1000 同行到场。如果你也在这些方向上做研究、做产品、做工程别错过。