Ling 3.1 Flash Free 评测：opencode 免费模型能力与干活实测（2026-10）
2026-10-02，opencode 上架免费模型 ling-3.1-flash-free（模型本身应该是 09-30 发布的，蚂蚁百灵 Ling-3.1-flash）。本次实测从连通性测试开始，覆盖基础能力五维剖面 → 速度和 token 消耗 → 路由与指纹对照 → 干活维度（实际开发一个 WPF 应用）。文中数字都是实测跑出来的；只是单台机器单场景的测试，不代表所有环境都这样。
一、速度与 token 消耗
| 指标 | 实测值 | 判定 |
|---|---|---|
| 输出速度中位数（主口径） | 21.4 t/s（24 个样本，剔污染正常样本） | 20-80 t/s = 中档 |
| 参考口径 | 27.0 t/s（19 个输出 20+ token 的实质任务样本） | 中档（含特殊文本复述短输出拉低，非异常） |
| E2E 中位数 | 2.35 s（最快 0.74 s，最慢 15.31 s） | 单请求端到端耗时 |
token 消耗不大：测量链单样本 input 增量中位仅 67 token，配合高缓存命中（测量链 99.8%），同会话反复调用增量极小。速度口径为 opencode 会话事件流（含客户端开销），与干活场景同口径；统计已剔除 4 类污染（对照模型/重复 batch1/0 token 空响应/超低输出异常），异常开销单列不混入。21.4 t/s 落在 20-80 中档，作为免费 flash 级模型算「可用」，不算极快。
token 结构（重点看用量）。测量链单样本 input 增量中位仅 67 token，cache.read 占比中位 99.8%（开发任务场景 96.2%）；常驻缓存约 3.2 万（系统提示+工具定义被缓存）。同会话同前缀重复调用增量极小。开发任务成功 run 的 total 约 5.5 万-6.2 万（大头仍是缓存 2.8 万-5.8 万，input 增量保持 758/373/266），开发任务 token 消耗约是单问答的 2 倍。
时间口径（评测总耗时 = 有效工作 + 异常开销）：24 个正常样本 E2E 合计 ≈ 117.6 s；异常样本 ≈ 8.3 s；但 429/断流重试开销为大头（粗估数小时级）——首条连通请求 0 字节 + 稳定性测试 9 样本 11m46s（正常 5-6min）+ 开发任务尝试跨度 19:03→06:05（有效开发仅 ~30min，其余为 429 重试/退避）。
二、基础能力五维剖面
| 模块 | 结果 | 判分要点 | 样本缺失 |
|---|---|---|---|
| stability | 8/8 成功，空答 0 | 同一 prompt 实跑 8 次：无空答/超时/拦截；8 种变体，这种多样性是正常的 | stability-3/10 |
| reasoning | 2/2 正确 | 逻辑题答「无法确定」+ 反例论证；二次方程因式分解 + 求根公式 + 验算 | reasoning-1 |
| structured | 2/2 可解析 | 简单对象直接合规；嵌套对象剥壳后合规 | structured-3 |
| facts | 5/5，幻觉率 0% | Python 之父、404、C# 首发 2000、Git 创始人、JSON 全称全对 | 无 |
| fingerprint | 9/9 原样返回 | 中文/全角/emoji/HTML/JSON 特殊格式文本逐项原样复述，无吞字符 | fingerprint-1 |
基础能力五维剖面全部通过：
- facts 5/5，幻觉率 0%：Python 之父、404=Not Found、C# 首发 2000、Git 创始人、JSON 全称全对。
- reasoning 2/2：三段论逻辑题（所有 A 都是 B、有些 B 是 C，问「有些 A 是 C」是否成立）正确答「无法确定」，并给出反例（A=猫/B=动物/C=狗）；二次方程 x²−5x+6=0 正确解出 x=2 或 3（因式分解 + 求根公式 + 验算）。
- structured 2/2：简单/嵌套对象剥壳后可解析。
- stability 8/8 无空答：同一题 8 次输出了 8 种写法，这种多样性是正常的。
- fingerprint 9/9 原样返回：中文/全角/emoji/HTML/JSON 特殊格式文本逐项原样复述，无吞字。
如实标注：样本缺失 5 处按实跑样本判分，不推算，不影响主结论。
三、关键发现
- token 消耗省（单次 input 增量 67 token + 缓存机制 99.8%/96.2%）→ 反复调用增量极小。
- 基础能力达标（facts 0% 幻觉、reasoning 全对、structured 可解析、stability 无空答）。
- 速度中档：21.4 t/s（24 个样本），E2E 中位 2.35 s。
- 干活能力真实存在：浏览器三个功能模块加配套文档全部落地 + 默认 variant 有时不可用，得切 low 模式干活（详见第四节）。
四、干活能力（三个功能模块 + 文档全落地）
任务：开发一个 WPF 浏览器骨架（net472/x86 + CefSharp.Wpf 83.4.20 + Dragablz），三个功能模块加配套文档。开发模型 = ling-3.1-flash-free（主）＋人工介入修复（CefSharp API 坑，如实标注）。
| # | 功能模块 | 完成度 | 开发模型 |
|---|---|---|---|
| 1 | 地址栏导航（前进/后退/刷新/加载指示/URL-关键词分流） | ✅ 完整 | ling 主体 + 介入修复 3 编译错 |
| 2 | 动态标签页（Ctrl+T/W/L/+按钮/×关闭/标题同步） | ✅ 完整 | ling 一次写全 |
| 3 | 收藏夹（星标 toggle/列表导航/删除/JSON 持久化） | ✅ 完整 | ling 数据层 + 介入 UI 集成 |
配套：ReadMe（功能+使用说明）✅ 完整，介入撰写（ling 读码后断流）。
开发前（空壳，无地址栏）：
开发后（工具栏/地址栏/收藏齐全，CefSharp 渲染 Bing）：
证据链：Release|x86 构建通过（多次独立验证）；GUI 启动 12s 存活 + CefSharp 子进程正常；截图显示完整工具栏 + 标签标题 “Search - Microsoft Bing” + CefSharp 渲染 Bing 首页（开发前基线：空实现，无地址栏）。ling 产出主体代码质量不错——窗口级工具栏（Chrome 风格）、当前 tab 联动（AttachTab/DetachTab 事件订阅管理完整）、URL/关键词分流（http/https 直访、域名补协议、关键词 bing 搜索）、动态标签页一次写全、Dispose 防泄漏。介入修复的地址栏导航三个编译错误属 CefSharp 83 特定 API 坑（CefSettings 类命名空间、AddressChanged/TitleChanged 为 WPF DP 事件、CefSettingsBase 在 CefSharp.Core.dll），非通用编程能力问题。
六维判定：完成度完整（7 修改+2 新增）／过程质量合理（读→todowrite→查 CefSharp API→写→构建）／失败恢复弱（ling 自愈 9 次均 Endpoint is unavailable 断流未完成，介入 3 处；断流属基础设施，非模型能力直接证据）／边界纪律良好（无 commit、未动无关文件）／诚实性 0 谎报／效率（地址栏 3134 / 标签页 3905 tokens）。
遇坑→诊断→解决：
- 假成功：开发任务首轮跑任务跑到一半直接停了，什么产出都没有——表面像跑完，实际啥也没干。
- 诊断：查了下是底层报错
Endpoint is unavailable（上游端点不可用），重试 5 次中 4 次成功 → 初判「端点时好时坏」。 - 关键发现：同一时刻默认 variant 报错、low 模式能通 → 实锤 = 那个时段默认 variant 被上游拒绝，low 模式能跑通——不是端点故障，是默认 variant 不总可用。
- 处理：晚上切到 low 模式也只是偶尔能通一次，到后面时段基本连不上；第二天早上继续尝试，断断续续总算把三个功能模块和文档磨完了。
干活维度诚实边界：单任务（一个 WPF 骨架）、单机、单时段（10-06/07），不代表全场景/全时段表现；默认 variant 凌晨是否可用未验证（建议补测连通性）。
五、不适合干活原因（三层证据）
5.1 时段可用性（证据之一）
三时段连通性截图（low 模式，17 请求/时段）：
| 时段 | 成功 | 失败 | 成功率 | 失败模式 |
|---|---|---|---|---|
| 早上 | 6 | 11 | ≈35% | 429 |
| 下午 | 8 | 9 | ≈47% | 429（200↔429 交替） |
| 晚上 | 6（全集中 19:30-19:42 短窗口） | 10+1 Cancelled | 非均值——前段可用、20:00 后全灭 | 429（20:00 后连续 7 次 429 → 之后完全跑不通） |
晚上到底咋回事：晚上 19:30-19:42 有个短窗口能用，20:00 后连续 7 次 429，之后基本全灭——可能是免费额度用一段就长禁，也可能是晚上流量大限流，看起来不是均匀间歇。
开发任务不是一口气跑完的：晚上试了几轮都不通，切到 low 模式也只是偶尔能通一次；第二天早上继续尝试，断断续续总算把三个功能模块和配套文档磨完。
5.2 全流程 429（证据之二）
首条连通请求（10-06 14:23）即 0 字节断流失败，14:25 重试成功；稳定性测试 9 样本耗时 11m46s（正常 5-6min），期间 4-6 分钟缺口 = 429 重试；5 个样本缺失 = 429 重试超限放弃（stability-3/10、reasoning-1、structured-3、fingerprint-1）——ling 的 429 从评测首条请求就持续存在，免费档的限流是全流程特征。
5.3 时间都耗在重试上了（证据之三）
有效样本合计 ≈ 117.6 s（约 2 分钟），429 重试/退避数小时级拖累总耗时（口径详见第一节）——干活断断续续，太折腾。
六、测试方法与判定标准
| 维度 | 怎么测 | 判定标准 |
|---|---|---|
| stability | 同一 prompt ×10（实跑 8） | 全部有实质输出，空答/超时/拦截 = 失败 |
| reasoning | 推理 3 题（实跑 2） | 答案正确 + 论证路径完整 |
| structured | 结构化 3 题（实跑 2） | 输出可解析且字段合规 |
| facts | 事实性 5 题（全跑） | 全部正确，幻觉率 0% |
| fingerprint | 10 组特殊文本（实跑 9） | 文本原样返回，无吞字 |
| speed | 正常样本（24 个样本，剔污染） | 中位档位：<20 慢 / 20-80 中 / >80 快 |
| variant | 默认 vs low 模式 | 默认报错时 low 跑通 = 默认 variant 不总可用 |
| 时段 | 三时段各 17 请求 | 成功率 + 失败模式（429） |
声明：未测长上下文、多轮指令、中文 rubric、多模态视觉等深测项。单机单场景 ≠ 全场景结论：本报告仅覆盖本机（硬件待补）单会话场景，不代表其他环境/并发场景；时段数据为单日观测（10-06），429 限流强度可能随运营调整变化。
七、怎么用它
- 轻量任务 / 试玩：在 opencode 里直接用——免费 + 缓存命中高（99.8%）+ 基础能力达标，token 消耗相信不大（单次 input 增量仅 67 token）。注意这个模型只在 opencode 里能用，其他 CLI 实际用不了。
- 低峰时段干活：能干活（三个功能模块完整产出），但请切 low 模式，并做好「失败 1-2 次后成功窗口」的重试预期——凌晨低峰成功率仍 ≤50%。
- 依赖型工作流（定时/长流水线）：先别指望——结论：有干活能力，但不适合干活；三时段成功率 ≤47%，20:00 后基本全灭，429 是唯一失败模式且从首条请求就存在；可用性受免费档的请求限流（RPM 极低）约束。
关注微信公众号
扫码关注，第一时间获取软件更新动态与选型建议。