Atria Dawn接入实录：400报错、上下文截断、配额共享，这些坑我都替你踩了

Atria Dawn接入实录400报错、上下文截断、配额共享这些坑我都替你踩了【免费下载链接】Atria-Dawn-Preview项目地址: https://ai.gitcode.com/InternLM/Atria-Dawn-Preview上海人工智能实验室开源的 Atria Dawn Preview是近期智能体模型里关注度最高的一张牌744B MoE 参数、256K 上下文、MIT 协议开源权重、注册即送 1 亿 token 免费额度官方公布的 16 项基准里有 5 项登顶AutomationBench 53.8、BFCL v4 77.0、CyberGym 86.5、DeepSearchQA 96.0、BrowseComp 92.5。它天然适合接进 Codex、Claude Code、Kimi Code 这类终端 Agent 工具当长程任务引擎。但免费额度从来不是接入的门票报错才是。过去两周社区里最密集的讨论几乎都围绕三件事展开400 Atria-Dawn-Preview is not a multimodal model到底怎么消掉、finish_reasonlength时怎么分辨是输出被截断还是上下文被写满、以及 401/404/429 这些状态码背后那条账户级配额共享的暗线。这篇文章把这三个坑的成因、复现路径和官方/源码层面的解法逐一拆开配置清单可以直接照着抄。接入前先摸清这个模型的脾气Atria Dawn Preview 基于 GLM-5.2 基座训练仓库里的 config.json 写得很清楚n_routed_experts: 256256 个路由专家、num_hidden_layers: 7878 层、hidden_size: 6144模型类型是glm_moe_dsa。它的定位不是聊天模型而是把开放问题推进为可执行、可验证结果的智能体底座——检索证据、调工具、写代码、跑实验、根据反馈恢复失败这是它最强的区间。两个容易被忽略的性格特征决定了后面所有报错的走向它是纯文本模型。图片、PDF、截图一律喂不进去。虽然 tokenizer_config.json 里定义了|begin_of_image|这类多模态占位 tokenchat_template.jinja 中也存在媒体输入的处理分支但那只是在媒体消息混入时渲染一句reminderYou are unable to process this ... because you dont have multi-modal input ability/reminder的兜底提示——服务端是实打实没有多模态能力的。256K 是总预算而非单次输出上限。官方 API 明确256K 上下文窗口同时容纳输入和生成内容系统指令、历史对话、文档摘录、工具返回结果全部占用输入空间而单次请求的输出上限只有 65,536 token且这个上限由三套 API 各自的参数控制Chat Completions 的max_completion_tokens/max_tokens、Messages 的max_tokens、Responses 的max_output_tokens。模型在带着工具跑长流程的基准上一串第一但在纯编码类任务SWE-bench Pro 59.6、JobBench 50.3上与顶尖商用模型仍有明显差距。这个强弱分布决定了它适合当免费的长程 Agent 引擎而不是拿来硬刚核心代码编写。坑一400 is not a multimodal model是客户端的身份误判这是接入 Codex 时命中率最高的报错完整信息是400 Atria-Dawn-Preview is not a multimodal model。成因在仓库的 README.md 里写得非常直白Codex 默认假设每个模型都支持多模态会把你通过-i/--image或 TUI 粘贴的截图自动附加到请求里而 Atria 端点只收文本于是直接拒绝。换句话说报错发生在客户端主动塞图这一侧不是模型本身坏了。规避方法是在客户端声明模型的身份——给 Codex 建一个 model catalog 文件把input_modalities显式声明为[text]{ models: [ { slug: Atria-Dawn-Preview, display_name: Atria-Dawn-Preview, base_instructions: You are a coding agent running in the Codex CLI. ... You can only receive text input. Images, screenshots, PDFs, and other binary attachments are not available to you., supported_reasoning_levels: [ { effort: low, description: Fast responses with lighter reasoning }, { effort: medium, description: Balances speed and reasoning depth }, { effort: high, description: Greater reasoning depth for complex problems } ], shell_type: unified_exec, visibility: list, supported_in_api: true, priority: 1, support_verbosity: false, truncation_policy: { mode: tokens, limit: 10000 }, experimental_supported_tools: [], context_window: 256000, max_context_window: 256000, input_modalities: [text] } ] }然后在~/.codex/config.toml里指向它并按需关掉图像查看工具model Atria-Dawn-Preview model_provider atria model_catalog_json ~/.codex/atria-catalog.json [tools] view_image false [model_providers.atria] name Atria base_url https://api.atria-asi.ai/v1 env_key ATRIA_API_KEY wire_api responses这个配置里有三个隐性要求缺一个都会翻车catalog 字段一个都不能少。解析器要求全部字段存在少任何一个都会报missing field nameCodex 直接无法启动。model_catalog_json是替换不是合并。任何没写进这个文件的模型都会回退到默认元数据默认假设多模态并打出一条warning: Model metadata for slug not found。如果后续用-m切换模型必须把它也加进同一个文件否则纯文本限制对它不生效。Codex 版本要 ≥ 0.154.0view_image的字段位置随版本变化旧文档是[features] view_image false新版本在[tools]表下先codex --version确认再抄。Claude Code 走的是另一条路它通过 Messages API 接入官方给出的方案是一段PreToolUsehook 脚本README.md 中有完整实现在Read工具层面把图片和 PDF 的读取请求直接 deny 掉让模型永远接触不到二进制附件。注意这个 hook 只拦截Read工具的按扩展名读取粘贴/上传的图片、file引用、Bash 输出都不在覆盖范围内——最稳妥的做法仍然是在外部做 OCR 或文本抽取把文本粘进去。Kimi Code 的坑则在capabilities声明capabilities [tool_use, thinking]里不能出现image_in加了就会复现同一个 400同时thinking必须显式声明否则 effort 被强制为 off推理能力静默失效——这是比 400 更隐蔽的不报错但功能没了。坑二finish_reasonlength先分清是输出截断还是输入超窗长程 Agent 跑到一半响应戛然而止翻 usage 日志发现finish_reasonlength。这个现象在社区排障里被反复讨论但很多人第一步就走错了方向——直接去改上下文结果问题依旧。排障的正确顺序是先搞清楚是哪个长度撞了上限。Atria 的 256K 上下文是输入输出的总预算而单请求输出上限是65,536 token两者是完全独立的两道闸门输出闸门max_tokens相关参数Chat Completions 用max_completion_tokens或max_tokensMessages 用max_tokensResponses 用max_output_tokens只接受 1–65,536 的整数。finish_reasonlength表示生成在到达这个上限时被强制停止。Kimi Code 的典型案例是配置里漏写max_output_sizeKimi 会把max_context_size256000原样发到线上Atria 直接以 400 拒绝合法范围 1–65536补上max_output_size 65536才能让输出上限这个语义真正生效。输入闸门系统指令、历史对话、文档摘录、工具返回结果全都在占用 256K 的输入空间。长文档 多轮工具调用 大段工具输出几轮下来输入空间就会被写满此时模型被迫丢弃早期上下文行为表现就是模型忘了任务开头。区分这两类问题的抓手是三套 API 各自暴露的字段——这也是一个模型 ID、三套 wire API最容易埋雷的地方Chat Completions 的结束原因是choices[0].finish_reasonMessages 是stop_reasonResponses 是statustoken 用量在 Chat Completions 是usage.prompt_tokens / completion_tokens另两套则是input_tokens / output_tokens。解析错字段等于排障时瞎了一只眼。社区里验证可行的长程排障流程核心就四点用非流式请求拿完整响应。流式场景下 usage 在流结束时才对账中途看到的统计是不完整的拿它判断截断位置会失真。先读结束原因再读 usage。finish_reasonlengthcompletion_tokens接近 65536是输出超限finish_reasonstop但任务明显没完成才是输入空间被占满导致上下文丢失。按轮次记录 usage做增量定位。每轮调用结束后把input_tokens/output_tokens落日志观察上下文增长曲线比事后翻总账精准得多。对工具返回做截断与摘要。长程 Agent 里最大的上下文吞噬者是工具输出社区实践是工具返回截断 状态摘要 预算控制三件套配合重试退避把非模型侧的消耗压下来——256K 上下文再大也扛不住每轮都往对话里塞几十 KB 的原始日志。值得注意的一个底层事实模型架构本身支持 1,048,576 的位置编码见 config.json 的max_position_embeddings与 tokenizer_config.json 的model_max_length但当前线上服务以 256K 上下文对外提供。也就是说上下文不是给了你 256K而是现阶段只开放 256K把它当成硬上限来规划任务而不是当成可以试探的资源。坑三401/404/429 与配额共享报错码背后的同一条暗线长程任务烧到中段突然 401第一反应是密钥过期了未必。官方文档给出的状态码语义很明确而社区里把这些码的根因串起来之后会发现它们指向同一条管理规则限速与配额是账户级的不是 Key 级的。每个账户有一个每分钟请求总数上限RPM由该账户下所有 API Key 共享并且三套 APIChat Completions、Messages、Responses共用一个额度池。超限返回 429响应头带Retry-After、x-rpm-limit: 60、x-rpm-remaining限额在固定分钟边界重置。这意味着开了三个 Key、分别喂给 Codex 和 Claude Code它们是在抢同一个杯子里的水一个 Key 上的突发流量会连坐另一个 Key 上的正常任务。调试时如果同时开着多个终端工具先想想是不是自己打满了自己的账户。把官方语义和社区观察汇总成一张对照表状态码官方/社区给出的语义典型根因处理动作401API Key 无效或已被吊销官方Key 复制不全、被误删、环境变量没生效检查ATRIA_API_KEYKey 只在创建时显示一次丢失只能重建400请求内容不被接受两类① 纯文本模型收到图片/PDFis not a multimodal model②max_tokens超出 1–65536 合法区间客户端声明input_modalities/hook 拦截修正输出上限参数404请求的端点或模型不存在模型 ID 大小写写错base_url路径不对如漏掉/v1模型 ID 严格保留Atria-Dawn-Preview的大小写核对 base_url429限速触发或配额耗尽官方账户级 RPM 被本账户全部 Key/三套 API 共享消耗读Retry-After退避错峰调度多个工具别并行抢额度5xx服务暂时不可用官方服务端波动指数退避重试两个最容易误判的点400 不是一种病是两种病。它既可能是多模态违规也可能是输出参数越界。看错误信息文本能直接区分——前者含is not a multimodal model后者会带合法范围提示。Kimi Code 那个max_output_size缺失的案例报的就是后一种 400但很多人在第一种的解法里找答案自然无解。404 大概率是身份问题而不是网络问题。Atria-Dawn-Preview这个 ID 大小写敏感atria-dawn-preview或Atria-Dawn都查无此模型base_url忘记带/v1时请求会落在不存在的路径上。这类错在社区 401/400/404 定位实践中占了大头排查优先级应该高于怀疑服务端。最后补一条关于配额的预期管理。社区实测数据显示智能体类任务的 token 消耗是聊天界面的几十倍一次代码库深度扫描116 次调用消耗约 12.7 万 token含重试总计约 17.4 万。1 亿免费额度按聊天估会觉得用不完按Agent 干活估才刚好够跑几百次深度任务。所以长程任务里usage 监控不该是可选项而应是接入的第一优先级配置——把 README.md 接入章节完整读一遍比翻遍全网排错帖省下一整个下午。一张避坑清单接入前先确认三件事模型纯文本、256K 是输入输出总预算、单次输出上限 65,536Codex 必须用 catalog 文件声明input_modalities: [text]字段全量、版本 ≥ 0.154.0、catalog 是替换不是合并Claude Code 用 PreToolUse hook 拦掉图片/PDF 读取但别指望它拦截粘贴和 Bash 输出Kimi Code 必须写max_output_size 65536和capabilities [tool_use, thinking]看到finish_reasonlength先读结束原因字段和 usage再决定是调输出上限还是压缩上下文401/404 先查 Key 和模型 ID 大小写429 先想到账户级配额被自己别的 Key 共享消耗长程任务坚持非流式验证 分轮 usage 日志 工具返回截断把上下文和配额都当成需要治理的资源。【免费下载链接】Atria-Dawn-Preview项目地址: https://ai.gitcode.com/InternLM/Atria-Dawn-Preview创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考