星火X2.6 断网后能跑多少任务，通常不由模型名字决定，而由两个条件决定：这条任务是否需要实时信息（天气、库存、价格、新闻、内部系统的最新状态），以及输入加输出是否超出端侧可用的上下文与显存、内存预算。可行的顺序是：先把任务拆成可逐条打勾的条目，在飞行模式下跑一遍，拿到成功、部分成功、失败的原始记录；再把失败按「能力不支持、输入超长、调用参数写错」分开归因；最后把能拆的任务做成端侧初稿加云侧补全。具体能覆盖到哪一步，需要结合你本机的模型包大小、可用内存和接入方式确认。

建议把判断顺序固定为：先断网实测，再归因，最后分工。断网后失败的任务不要急着判定「端侧不行」，按能力不支持、输入超长、调用参数错误三类各查一遍，通常能排除一部分误判。实测记录里必须留下失败提示原文和耗时量级，这是后面做分工清单的唯一依据。凡是依赖实时信息或明显超长上下文的条目，直接归到云侧，不放进断网可用范围。

列出准备实测的任务清单，标注每项是否需要实时信息

这一步的目的是把「端侧能不能干」这种模糊提问，变成一张可以逐条打勾的表。每条至少写清四件事：任务条目、输入样例、期望输出形态、是否需要实时信息。上下文长度可以另起一列，只写量级（几百字、几千字、上万字），不要写精确值。

把这张表存成可脚本读取的文件，后面批量跑和记日志都省事。下面是一个通用骨架，字段名可以按你自己的跑测脚本替换：

[
  {"id": 1, "task": "润色改写", "need_realtime": false, "input_file": "cases/1.txt", "expect_form": "text"},
  {"id": 2, "task": "结构抽取", "need_realtime": false, "input_file": "cases/2.txt", "expect_form": "json"},
  {"id": 7, "task": "实时查询", "need_realtime": true, "input_file": "cases/7.txt", "expect_form": "text"}
]

标注为「需要实时信息」的条目，建议直接不进断网实测，或只测它的断网降级形态，例如是否肯明确回答「无法获取实时数据」，而不是编一个数值。

在飞行模式或断网环境下逐条跑，记录成功、部分成功、失败

断网方式用飞行模式或直接关掉网络接口即可，关键是确认进程真的出不了网，而不是以为它断网了。建议每跑一条前重置会话，避免上一条的缓存或上下文影响判断。每条任务记录四项：输入、输出摘要、耗时量级、失败提示原文。失败提示要抄原文，不要自己转述成「失败了」。

序号=2 | 任务=结构抽取 | 输入=cases/2.txt | 结果=部分成功 | 耗时约=十几秒 | 输出摘要=字段齐全但两个字段为空 | 提示原文=（无）
序号=5 | 任务=长文档摘要 | 输入=cases/5.txt | 结果=失败 | 耗时约=数十秒 | 提示原文=（此处填你实际看到的报错文本）

「部分成功」要单独算一类：输出结构对了但内容不全、格式对了但有占位段落、或者答案正确却缺了引用片段。这类任务往往才是端侧真正能用起来的地方，后面第四节会用到。同时留意耗时量级，端侧长输入时往往明显变慢，如果耗时已经影响使用，即使任务成功，也建议改走云侧或拆分输入。

区分失败原因：能力不支持、输入超长、还是调用参数写错

断网后失败，最容易发生的误判是把调用错误当成端侧能力不足。三类原因各有识别特征，建议按下面的顺序排查。

• 能力不支持：同一任务联网跑也失败，或输出明显是编造、答非所问、直接拒答；把输入换成同类型的简单样例，仍然失败；换一种提问方式也失败。这类才是真的端侧覆盖不到。
• 输入超长：失败提示里出现长度、token、上下文窗口相关的字样；把同一段输入截短到一半后能跑通；失败只在输入变长后出现，短输入一直正常。
• 调用参数写错：提示里出现字段名、类型、必填项、枚举值、路径不存在这类字样；联网时也报同样的错；换成接入方式自带的示例请求能跑通，只改你自己的调用就失败。

判定为参数错误时，回到你所接入的 SDK 或接口文档逐个核对下面这些字段类别，字段名以你本地的接入方式为准：

• 模型标识与版本名是否与实际加载的模型一致，是否误写成了云侧模型名
• 接口地址指向本地服务还是远程服务，协议与端口是否对应
• 最大输出长度、采样参数（温度、top_p 之类）是否被设成了不合法值或过小值
• 输入格式：是纯文本还是 messages 数组，是否要求必须有 system 角色，角色名是否拼写正确
• 文件、图片、附件的路径、编码与大小是否在允许范围内
• 超时与重试设置是否过短，长输入下被本地进程直接掐断
• 是否误开了需要联网的检索、插件或工具调用开关，断网时这类开关会直接导致失败
• SDK 版本与本地服务端版本是否匹配

排查顺序建议是先看提示原文属于哪一类，再改一个变量重跑一次，不要一次改多处，否则下次仍然无法定位。

把部分成功的任务拆成端侧初稿加云侧补全

「部分成功」的任务不必直接放弃，比较实用的组合是把任务切成两段：端侧负责结构化、抽取、起草这类不依赖外部数据的工作，云侧负责校验、补实时数据、长文合并、最终润色。这样断网时至少有初稿可用，联网时再把缺的部分补上。

• 放端侧：字段抽取、要点罗列、初稿撰写、格式转换、本地片段归纳
• 放云侧：实时数值填充、跨文档合并、事实核验、最终成稿的语言统一

拼接时最容易出问题的是格式不一致。建议先约定一个中间格式，端侧输出必须严格遵守，缺失内容用固定占位符标出，不要把缺失内容写成一句自然语言描述。

{
  "title": "（端侧填写）",
  "points": ["（端侧填写）", "（端侧填写）"],
  "price": "{{PENDING:realtime}}",
  "updated_at": "{{PENDING:realtime}}",
  "draft_from": "on-device"
}

云侧补全后按同一套字段回填，再做一次字段校验：必填字段是否存在、占位符是否已全部替换、数组长度是否与端侧一致。占位符没被替换掉就说明云侧补全没跑完，宁可直接报缺失，也不要把「待补」字样带进最终文本。

整理成分工清单，写清哪些任务没网时直接不做

把前面的实测记录收敛成一张表，作为日常使用边界。表里只写可执行的动作，不写「效果不错」「能力较强」这类评价。

没网时建议直接不做的，通常是三类：需要实时数值的查询、明显超过端侧上下文的长输入、以及依赖外部检索或工具调用的任务。这三类在断网下即使勉强出结果，也需要人工核验，使用成本反而更高。