由于测试的模型越积越多了，表格会删除一些同厂商的旧模型，你可以在之前的评测帖子里找到它们的成绩。 项目 这是一个 Unity C# 项目，我进行测试的是一份皮肤系统需求案，我已经做了好预制体，而模型需要编写代码。 本轮与上两轮评测的项目和环境都完全一致： 第一轮 … 上一轮 模型来源 Claude 系列模型: 官方 API Mimo V2.5 系列模型: 官方 Token Plan Hy3 Preview: 官方 API Qwen3.7 系列模型: 官方 API Minimax M3: 官方 API Nex-N2-Pro: OpenRouter Free API Nemotron 3 Ultra: OpenRouter Free API 速度 排名 模型 时间（分钟） 备注 1 Grok 4.20 0309 Reasoning 3 2 Step-3.5-Flash 6 3 Mimo V2 Omni 7 4 Doubao-Seed-2.0-Lite 7 5 Doubao-Seed-2.0-Pro 9 6 Doubao-Seed-2.0-Code 9 7 Qwen3-Coder-Next 9 8 Claude Sonnet 4.6(high) 9 9 Qwen3.5-Plus 9 10 GLM-5 Turbo 10 11 Minimax M2.7 10 Highspeed 版本 12 Qwen3.5-Flash 10 13 Gemini 3 Pro 11 14 Hy3 Preview 13 15 GPT-5.5(low) 13 16 GPT-5.5(medium) 15 17 Mimo V2 Pro 15 18 DeepSeek V4 Flash 17 19 Qwen3.7-Plus 17 20 Qwen3.7-Max 18 21 GPT-5.5(high) 19 22 Claude-Opus-4.7(Max) 20 23 GLM-5 20 24 DeepSeek V4 Pro 21 25 Gemini 3 Flash 22 26 Claude-Fable-5(xhigh) 23 27 Mimo V2.5 24 28 KAT-Coder-Pro V2 24 29 Minimax M3 25 30 Claude-Opus-4.6(Max) 26 31 GPT-5.5(xhigh) 28 32 Gemini 3.1 Pro(high) 29 受 429 请求频率限制影响 33 Claude-Opus-4.8(Max) 33 34 Kimi K2.6 33 35 Qwen3.5 9B GGUF Q4_K_XL 35 MBP M4 Pro 48GB 本地部署 36 Qwen3.5 35B A3B GGUF Q4_K_XL 36 MBP M4 Pro 48GB 本地部署 37 Mimo V2.5 Pro 37 令牌数 Claude-Fable-5(xhigh): 7.1M Claude-Opus-4.8(Max): 13M Mimo V2.5 Pro: 未知 Mimo V2.5: 未知 Hy3 Preview: 1.4M Qwen3.7-Max: 4.6M Qwen3.7-Plus: 4.2M Minimax M3: 未知 Nex-N2-Pro: 退赛 Nemotron 3 Ultra: 退赛 代码行数 Claude-Fable-5(xhigh): +1520, -7 Claude-Opus-4.8(Max): +1347, -22 Mimo V2.5 Pro: +1682, -14 Mimo V2.5: +1270, -8 Hy3 Preview: +1246, -8 Qwen3.7-Max: +1529, -6 Qwen3.7-Plus: +1532, -7 Minimax M3: +2284, -137 Nex-N2-Pro: 退赛 Nemotron 3 Ultra: 退赛 完成度 Claude-Fable-5(xhigh) 审查结论: 完成度非常高，仅有一个细节问题。 详细 （点击了解更多详细信息） Claude-Opus-4.8(Max) 审查结论: 完成度很高，虽然存在常见错误，但在最后列出了该处理需要确认；另有一个细微实现不一致。 详细 （点击了解更多详细信息） Mimo V2.5 Pro 审查结论: 存在常见错误，有几处与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Mimo V2.5 审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Hy3 Preview 审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Qwen3.7-Max 审查结论: 较多功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Qwen3.7-Plus 审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。 详细 （点击了解更多详细信息） Minimax M3 审查结论: 存在部分功能错误和与需求/线上实现不一致的功能缺失；但在最后特别说明了协议枚举值调整的破坏性和服务器需要同步更新枚举值这一点，显示了对问题的理解。 详细 （点击了解更多详细信息） 最终总结 排名 模型/层级 说明 Tier 0 该等级的模型实现与线上基线高度一致。 1 Claude-Fable-5 2 GPT 5.5(xhigh) Tier 1 该等级的模型的代码正确完整且可编译，仅少量边界问题或轻微不一致。 3 Claude Opus 4.8(Max) 4 GPT 5.5(high) 5 Kimi K2.6 6 GPT 5.5(low) 7 GPT 5.5(medium) 8 Claude Opus 4.6(Max) 9 Claude Sonnet 4.5 Tier 2 该等级的模型的代码至少可编译或仅极少量的语法错误，但是存在明显功能错误、遗漏或与需求/线上不一致。 10 GLM 5.1 11 Minimax M3 12 Mimo V2.5 Pro 13 GLM 5 14 Kimi K2.5 15 Claude Sonnet 4.6(high) 16 Qwen3.7-Max 17 Qwen3.5-Plus 18 KAT-Coder-Pro V2 19 DeepSeek V4 Pro(max) Tier 3 该等级的模型的问题很多且无法编译，或者存在不少幻觉。 20 DeepSeek V4 Flash(max) 21 Claude Opus 4.7(Max) 22 Qwen3.7-Plus 23 Mimo V2.5 24 Hy3 Preview 25 GLM 5 Turbo 26 Gemini 3.1 Pro(high) 27 Mimo V2 Pro 28 Mimo V2 Omni 29 Minimax M2.7 30 Step-3.5-Flash 31 Qwen3-Coder-Next 32 Gemini 3 Pro 33 Gemini 3 Flash 34 Doubao-Seed-2.0-Code 35 Doubao-Seed-2.0-Pro 36 Doubao-Seed-2.0-Lite 37 Qwen3.5-Flash 38 Qwen3.5 35B A3B GGUF Q4_K_XL 39 Qwen3.5 9B GGUF Q4_K_XL 40 Grok 4.20 0309 Reasoning Claude-Fable-5(xhigh)： 速度超过 Claude-Opus-4.6(max) 与 GPT-5.5(xhigh) 完成度非常高与 GPT-5.5(xhigh) 相当，仅存在一个体验细节问题 终于 Claude 站起来了，不仅是 Claude 的首个 T0 模型，且接替 GPT-5.5 成为榜首。 当然我要重申，它们都能比较完整地做完这个需求，能力差不多，所以是按照模型发布日期来排名的（虽然它其实比 GPT-5.5 要快）。 我已经有点怀疑是否应该将评审员从 GPT-5.5 换为 Claude-Fable-5 了。 Claude-Fable-5 在做完需求后还有一段 “需向你确认的事项”，对某些奇怪的实现细节（比如皮肤配置枚举 值与服务器枚举值不同、时间戳单位猜测）还有自己不确定的地方进行了汇总，给人的感觉是对于这个需求它游刃有余， 一切尽在掌握；需求未说明自己决定的地方都放在最后列出以进行核对，这是比较难得的。 但是 Claude-Fable-5 的安全方面确实非常敏感，测完之后，正好我在做的 VS Code 扩展有一个大需求， 使用 AI 完成后怕遗漏会再用 AI 审查一遍，但 GPT-5.5 会经典地出现自己审查自己永远有问题的情况， 于是我想使用 Fable-5 审查一下，但是由于存在类似反代的功能，Fable-5 思考一半后直接拒绝了， 甚至我还没有要求它编写代码，而 GPT-5.5 对此是完全没有问题的。 后续我会尝试使用 Claude-Fable-5 替代 GPT-5.5 作为我的主力模型，看看它是否真的比 GPT-5.5 更好。 Claude-Opus-4.8 的速度几乎和我之前测试本地部署的模型一样了，对比 Claude-Fable-5，慢了接近 10 分钟， 需要注意的还有消耗的令牌数，Claude-Opus-4.8 消耗的令牌数是 Claude-Fable-5 的将近两倍， 一来一回 Claude-Fable-5 还真像是 Claude-Opus-5 了，消耗的令牌数低，所以实际价格差距不大。 Claude-Opus-4.8 的完成度有了明显提升，之前一直犯的系统注册和界面入口的常见问题都没有了， 它也和 Claude-Fable-5 一样在最后列出了需要确认的事项，虽然枚举值的处理是错了，但它留下了这样的内容： 皮肤类型枚举：以 skinList 表 Type 字段为准分类（1/2/3/4），未采用 skin.proto 中数值不一致的 SkinType（0/1/2/3）。 说明它知道这里需要判断如何处理，但认为采用配置表的值是合理的，而没有编写相互转换的函数。 首先这样的处理在我看来是完全不合理的，因为虽然留下了说明，但编写了错误的代码，没有对比就没有差距， 反观 Fable-5 既写了转换函数，也留下了这样的说明： 皮肤类型编号不一致：协议枚举 SkinType（0=神针 1=称号 2=头像框 3=气泡）与 skinList 表（1=神针 2=头像框 3=气泡 4=称号）顺序、偏移都不同。我已把转换收口在 SkinNetMgr.ToProtoSkinType/ToCfgSkinType，内部数据一律以配置表类型为准（按 skinId 反查表），仅 C2S_SKIN_LIST.skinType 请求参数按协议枚举发送。请与服务器确认线上实际使用哪套编号，若用表编号只需改这两个函数。 Fable-5 给到了一个完全无可挑剔的答卷。 Mimo V2.5 Pro 的速度非常慢，甚至比我之前测试本地部署的模型还慢，但是完成度相对上个版本有了明显提升， 虽然还存在那两个常见错误， Mimo V2.5 的速度比上代 V2 Pro 慢，与 Claude-Fable-5 的用时几乎一样，首先它没有犯那两个常见错误， 但是无法编译，未实现、功能错误也非常多，属于 T3 级别。 Hy3 Preview 出现编译错误，位于 T3。 Qwen3.7 系列模型与上一代的差距未拉开很大差距，位于 T2 和 T3，Qwen3.7-Plus 出现编译错误，相对上代 3.5 可能有退步。 Nex-N2-Pro 思考内容发生循环，遂中止了对话，遗憾退赛： maybe "SkinDataMgr GetSkinPreviewPath(int skinId, int type, bool worldPreview = false)". Need "SkinDataMgr GetSkinPreviewPathForType". Need "SkinDataMgr GetSkinPreviewPathForType". Need "SkinDataMgr GetSkinPreviewPathForType". Need "SkinDataMgr GetSkinPreviewPathForType". ... Nemotron 3 Ultra 发生上游错误，无法继续，遗憾退赛。 Minimax M3 下出神之一手，它应该是发现了配置枚举值与服务器枚举值不一致的问题，对此它的判断是， **一定是后端写错了！**于是它直接修改了 proto 的定义，把服务器枚举改成了一致的值！ 惊为天人，史无前例，这是首次有模型直接修改了服务器协议定义的内容。 当然这完全是不符合直觉的操作，但是 Minimax M3 在最后特别说明了这一点，代表着它与 Opus 4.8 一样， 都理解了只是处理不同： > **注意事项** > - 协议中 `SkinType` 枚举值的调整属于破坏性变更，服务器需要同步更新枚举值（1/2/3/4）。 > - `C2S_SKIN_LIST.totalAttrs` 字段在协议注释中标注为"所有已拥有皮肤的属性总和"，目前按各类型分别存储并在客户端聚合；如服务器已按"全部类型"聚合，可直接读取 `_totalAttrs`。 除此之外，M3 犯了未设置页签文案的低级错误，总体而言完成度与 Mimo V2.5 Pro 相当，位于 T2。 最后总结 Claude Fable 5 表现非常亮眼，我会替换 GPT-5.5 作为主力模型使用一段时间，但是需要注意该模型非常敏感。 Claude Opus 4.8 终于变得像 Opus 了，有明显提升，但是 Fable 5 的价格差不多（因为仅有一半令牌消耗量），速度还更快，效果也更好，感觉并非 Fable，而是 Opus 5，有了 Fable 5，Opus 4.8 存在的意义就不太大了。 Mimo V2.5 Pro 相对上代进步明显！ Minimax M3 相对上代进步明显！ 其余模型则如测了。 本次继续使用自己开发的开源 VS Code 插件 Unify Chat Provider 以实现在 Copilot 中使用以上模型。 6 个帖子 - 6 位参与者 阅读完整话题
在codex中想把一个竖向的繁体字pdf转换为横向的，中间穿插一些英文 每次识别繁体字要不就是上下结构识别成两个字，要不就是两个字直接合到一起了，识别出来的根本不能用 求一个可以识别繁体竖向的OCR工具 3 个帖子 - 2 位参与者 阅读完整话题
一定 一定 一定要在成年的时候去检查下有没有横向智齿，有的话要拔，我就是拔太晚了，把旁边牙顶空了。 今天去做了植骨术，超级痛 1 个帖子 - 1 位参与者 阅读完整话题
IT之家 6 月 4 日消息，酷比魔方今日公开了旗下全网通高刷小平板新品 —— 掌玩 mini 4 Pro 的外观。 从画面可以看到，酷比魔方掌玩 mini 4 Pro 小平板采用了横向 Deco 设计， 后置单摄 + 闪光灯 ，同时在模组的最右侧 还配有一个 RGB 灯环 。 IT之家注意到，酷比魔方也在与网友的互动中透露了一些掌玩 mini 4 Pro 小平板的信息。例如新品将支持插卡打电话， 不过性能会比掌玩 mini 4 Ultra 弱 。作为参考， 掌玩 mini 4 Ultra 搭载天玑 8300 处理器 ，匹配 12GB RAM 和 256GB 存储空间，定价 2599 元。 相关阅读： 《 酷比魔方掌玩 mini 4 Ultra 平板上架：天玑 8300 + 12G + 256G、全网通双卡双待，首发价 2199 元 》
佬友们，最近公司被CobaltStrike入侵植入木马病毒，病毒还会横向扩展，目前已将问题机器全部隔离，并且尝试了各种清杀工具，但是害怕杀不干净，有这方面的佬可以提供些建议吗，图片内的文件是检测出来的异常文件 7 个帖子 - 4 位参与者 阅读完整话题
十三个模型评测测试报告 1). 测试概述 本次测试针对以下十三个模型进行了统一条件下的对比评测： Gemma-4-31B-IT-Uncensored QwOpus3.6-27B Qwen3.6-27B-Neo-Code Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-v2 Qwen3.6-27B-MTP SuperGemma4-26B-Uncensored Qwen3.6-35B-A3B-Uncensored Qwen3.6-27B Gemma-4-31B-IT-Claude-Opus Gemma 4 - 26B A4B x Claude Opus 4.6 Qwen3.6-27B-Claude-Opus-Reasoning Qwen3-Coder-Next — Opus 4.6 Reasoning Distilled SuperGemma4-26B-Abliterated-Multimodal 我下载的都是Q4_K_M量化版 2).电脑硬件参数 硬件类型 型号/规格 显卡 NVIDIA GeForce RTX 4090 内存 64GB DDR5 CPU Intel Core i9-13900K 测试目标是从 逻辑推理能力、代码生成能力、响应速度、运行稳定性 四个维度，评估十三个模型在实际使用场景中的综合表现。 2. 测试方法与统一设置 为保证横向比较公平，本次评测使用了完全一致的测试方式和参数设置。 2.1 统一参数 temperature：0.0 top_p：1.0 每题采样次数：1 不使用 LLM 裁判 逻辑题采用 exact match 评分 代码题采用程序执行与测试通过率评分 2.2 测试集规模 GSM8K：20 题 BBH：20 题 HumanEval+：10 题 MBPP+：10 题 2.3 评分公式 逻辑分 = (GSM8K + BBH) / 2 代码分 = (HumanEval+ + MBPP+) / 2 总分 = (逻辑分 + 代码分) / 2 2.4 评测命令 本次评测使用 run_eval.py 进行： python run_eval.py --base-url http://localhost:1234/api/v1/chat --models qwen3.6-27b-mtp --gsm8k-limit 20 --bbh-limit 5 --humaneval-limit 10 --mbpp-limit 10 --request-timeout 900 3. 总体结果汇总 排名 模型 逻辑分 代码分 总分 平均时延 执行失败率 1 Gemma-4-31B-IT-Uncensored 0.9500 1.0000 0.9750 17.64s 0.00 2 QwOpus3.6-27B 0.9000 1.0000 0.9500 44.63s 0.00 3 Qwen3.6-27B-Neo-Code 0.9000 0.9500 0.9250 101.76s 0.05 3 Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-v2 0.8500 1.0000 0.9250 38.25s 0.00 3 Qwen3.6-27B-MTP 0.8500 1.0000 0.9250 84.37s 0.00 6 SuperGemma4-26B-Uncensored 0.8750 0.9500 0.9125 4.90s 0.05 6 Qwen3.6-35B-A3B-Uncensored 0.8750 0.9500 0.9125 100.35s 0.05 8 Qwen3.6-27B 0.9500 0.8500 0.9000 149.94s 0.15 9 Gemma-4-31B-IT-Claude-Opus 0.8500 0.9000 0.8750 69.27s 0.10 10 Gemma 4 - 26B A4B x Claude Opus 4.6 0.7750 0.9500 0.8625 18.49s 0.05 11 Qwen3.6-27B-Claude-Opus-Reasoning 0.6500 1.0000 0.8250 9.10s 0.00 12 Qwen3-Coder-Next — Opus 4.6 Reasoning Distilled 0.6000 1.0000 0.8000 58.25s 0.00 13 SuperGemma4-26B-Abliterated-Multimodal 0.7250 0.5000 0.6125 8.04s 0.50 4. 单模型详细测试结果 4.1 Gemma-4-31B-IT-Uncensored 4.1.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 19 / 20 0.95 21.24s - BBH 19 / 20 0.95 29.62s - HumanEval+ 10 / 10 1.00 15.36s 0.00 MBPP+ 10 / 10 1.00 4.35s 0.00 4.1.2 表现分析 以 0.9750 总分断层登顶 ，是十三个模型中综合实力最强的。 逻辑能力极强，GSM8K 和 BBH 均达到 0.95。BBH 0.95 远超第二名的 0.85。 代码能力满分 ，HumanEval+ 和 MBPP+ 全部通过。 执行失败率为 0 ，稳定性最佳之一。 速度适中（17.64s）。 4.1.3 结论 Gemma-4-31B-IT-Uncensored 是本次测试中 综合实力最强、无明显短板 的模型。是当前最值得推荐的全能型首选模型。 4.2 QwOpus3.6-27B（2026-05-26 第二次评测） 4.2.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 19 / 20 0.95 18.78s - BBH 17 / 20 0.85 36.19s - HumanEval+ 10 / 10 1.00 24.53s 0.00 MBPP+ 10 / 10 1.00 99.03s 0.00 4.2.2 表现分析 总分 0.9500，独占第二 。 BBH 0.85，较首轮 0.70 大幅提升（+0.15） ，是本轮最大亮点。 代码双满分 + 零失败。 平均时延 44.63s，速度中等。 唯一在「代码满分 + BBH ≥ 0.85」双条件同时满足的模型。 4.2.3 结论 QwOpus3.6-27B 经第二次评测后 总分 0.9500、独占第二 。是当前最接近 Gemma-4-31B 的模型（差距仅 0.025）。 4.3 Qwen3.6-27B-Neo-Code 4.3.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 19 / 20 0.95 95.95s - BBH 17 / 20 0.85 111.04s - HumanEval+ 10 / 10 1.00 102.49s 0.00 MBPP+ 9 / 10 0.90 97.57s 0.10 4.3.2 表现分析 以 0.9250 总分并列第三 。 BBH 0.85，复杂逻辑推理较强。 HumanEval+ 满分，代码能力 0.95。 执行失败率 0.05。 平均时延 101.76s，速度偏慢 。 4.3.3 结论 Qwen3.6-27B-Neo-Code 是 逻辑与代码双强 的模型，并列第三。速度偏慢（101.76s）是其主要短板。 4.4 Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-v2 4.4.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 20 / 20 1.00 45.08s - BBH 14 / 20 0.70 32.16s - HumanEval+ 10 / 10 1.00 43.15s 0.00 MBPP+ 10 / 10 1.00 32.62s 0.00 4.4.2 表现分析 GSM8K 满分，数学推理十三个模型中最强。 代码满分，稳定性优秀。 BBH 0.70，复杂逻辑推理有短板。 平均时延 38.25 秒。 4.4.3 结论 Qwen3.5-27B 是 代码满分 + 数学满分 的模型，并列第三。适合数学推理和代码场景，BBH 偏弱。 4.5 Qwen3.6-27B-MTP（2026-05-26 首测）★ 新模型 4.5.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 18 / 20 0.90 69.58s - BBH 16 / 20 0.80 80.21s - HumanEval+ 10 / 10 1.00 62.88s 0.00 MBPP+ 10 / 10 1.00 124.82s 0.00 4.5.2 评测说明 本次为首测，使用 run_eval.py 评测，命令如下： python run_eval.py --base-url http://localhost:1234/api/v1/chat --models qwen3.6-27b-mtp --gsm8k-limit 20 --bbh-limit 5 --humaneval-limit 10 --mbpp-limit 10 --request-timeout 900 附加 API 验证测试（rhyme 约束遵循）： curl http://localhost:1234/api/v1/chat \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3.6-27b-mtp", "system_prompt": "You answer only in rhymes.", "input": "What is your favorite color?" }' API 验证结果： 模型严格遵循押韵约束，输出完整 AAAA 押韵诗节 推理 token 数 689（占总输出 94%），推理过程详尽 生成速度 27.86 tokens/s 首 token 延迟 1.022s 4.5.3 表现分析 总分 0.9250，首测即并列第三 ，跻身第一梯队。 GSM8K 0.90，数学推理较强但非顶级。 BBH 0.80，复杂逻辑推理中上水平。 代码双满分 + 零失败 ，代码稳定性极佳。 平均时延 84.37s，速度偏慢但比原生版（149.94s）快 44%。 4.5.4 Qwen3.6-27B-MTP vs 原生 Qwen3.6-27B 对比 ★ 重点 指标 Qwen3.6-27B（原生） Qwen3.6-27B-MTP 变化 GSM8K 0.95 0.90 -0.05 BBH 0.95 0.80 -0.15 HumanEval+ 0.90 1.00 +0.10 MBPP+ 0.80 1.00 +0.20 逻辑分 0.950 0.850 -0.100 代码分 0.850 1.000 +0.150 总分 0.9000 0.9250 +0.025 时延 149.94s 84.37s -44% 失败率 0.15 0.00 改善 排名 8 3 跃升 5 位 解读： MTP（投机解码）版本实现了定位转换 ：从「逻辑极强 + 代码较强」转变为「代码满分 + 逻辑中上」 代码能力的提升是最显著的变化：MBPP+ 从 0.80 → 1.00（+0.20），HumanEval+ 从 0.90 → 1.00（+0.10） 速度提升 44%，MTP 投机解码的加速效果明显 代价是 BBH 从 0.95 降至 0.80（-0.15），逻辑推理能力有所削弱 总分反超原生版（0.9250 > 0.9000），排名从第八跃升至并列第三 4.5.5 结论 Qwen3.6-27B-MTP 首测即达到 总分 0.9250、并列第三 。相比原生 Qwen3.6-27B，MTP 版本通过投机解码实现了代码满分和速度的双重提升，但以牺牲部分逻辑能力为代价。适合需要「代码满分 + MTP 加速」的场景，是原生版的有力替代方案。 4.6 SuperGemma4-26B-Uncensored 4.6.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 19 / 20 0.95 3.09s - BBH 16 / 20 0.80 14.34s - HumanEval+ 10 / 10 1.00 1.44s 0.00 MBPP+ 9 / 10 0.90 0.75s 0.10 4.6.2 表现分析 总分 0.9125 并列第六。 速度 4.90s 最快 。 代码能力很强，HumanEval+ 满分，MBPP+ 丢 1 题。 执行失败率 0.05。 4.6.3 结论 SuperGemma4-26B-Uncensored 是 速度最快 的模型。极度看重响应速度时首选。 4.7 Qwen3.6-35B-A3B-Uncensored 4.7.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 19 / 20 0.95 92.47s - BBH 16 / 20 0.80 143.65s - HumanEval+ 10 / 10 1.00 93.43s 0.00 MBPP+ 9 / 10 0.90 71.86s 0.10 4.7.2 表现分析 总分 0.9125，并列第六。 质量高但速度第二慢（100.35s）。 4.7.3 结论 Qwen3.6-35B-A3B-Uncensored 是 质量高但速度较慢 的模型。 4.8 Qwen3.6-27B 4.8.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 19 / 20 0.95 - - BBH 19 / 20 0.95 - - HumanEval+ 9 / 10 0.90 - 0.10 MBPP+ 8 / 10 0.80 - 0.20 4.8.2 表现分析 总分 0.9000，综合第八。 逻辑极强（0.950），并列第一。 代码 0.85，失败率 0.15。 速度最慢（149.94s） 。 4.8.3 结论 Qwen3.6-27B 逻辑极强但速度最慢。建议考虑其 MTP 版本（qwen3.6-27b-mtp）作为替代。 4.9 Gemma-4-31B-IT-Claude-Opus 4.9.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 17 / 20 0.85 85.28s - BBH 17 / 20 0.85 78.65s - HumanEval+ 8 / 10 0.80 71.41s 0.20 MBPP+ 10 / 10 1.00 41.74s 0.00 4.9.2 表现分析 总分 0.8750，综合第九。 逻辑稳健（GSM8K 0.85、BBH 0.85）。 速度偏慢（69.27s），执行失败率 0.10。 4.9.3 结论 Gemma-4-31B-IT-Claude-Opus 逻辑稳健、代码较强但速度偏慢。 4.10 Gemma 4 - 26B A4B x Claude Opus 4.6 4.10.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 18 / 20 0.90 18.38s - BBH 13 / 20 0.65 20.64s - HumanEval+ 9 / 10 0.90 18.73s 0.10 MBPP+ 10 / 10 1.00 16.20s 0.00 4.10.2 表现分析 总分 0.8625，综合第十。 均衡型，速度 18.49s。 4.10.3 结论 Gemma 4 - 26B A4B 均衡且响应较快，适合通用助手场景。 4.11 Qwen3.6-27B-Claude-Opus-Reasoning（第四次重测） 4.11.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 19 / 20 0.95 9.25s - BBH 7 / 20 0.35 9.78s - HumanEval+ 10 / 10 1.00 10.10s 0.00 MBPP+ 10 / 10 1.00 7.28s 0.00 4.11.2 表现分析 总分 0.8250，综合第十一。 代码满分 + 速度快（9.10s），但 BBH 0.35 逻辑严重短板。 定位：代码专精 + 速度优先。 4.11.3 结论 Qwen3.6-27B-Claude-Opus-Reasoning 定位为「代码专精 + 速度优先」，不适合逻辑推理场景。 4.12 Qwen3-Coder-Next — Opus 4.6 Reasoning Distilled 4.12.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 18 / 20 0.90 26.57s - BBH 6 / 20 0.30 33.21s - HumanEval+ 10 / 10 1.00 129.31s 0.00 MBPP+ 10 / 10 1.00 43.93s 0.00 4.12.2 表现分析 总分 0.8000，综合第十二。 代码满分，BBH 仅 0.30，逻辑短板极明显。 偏代码导向，不推荐综合使用。 4.12.3 结论 Qwen3-Coder-Next 是偏代码专用模型，不适合综合场景。 4.13 SuperGemma4-26B-Abliterated-Multimodal 4.13.1 分项成绩 测试项 正确 / 通过情况 得分 平均时延 执行失败率 GSM8K 18 / 20 0.90 5.95s - BBH 11 / 20 0.55 21.35s - HumanEval+ 1 / 10 0.10 2.37s 0.90 MBPP+ 9 / 10 0.90 2.47s 0.10 4.13.2 表现分析 HumanEval+ 几乎全军覆没 ，执行失败率 90%。 代码分 0.500，断层垫底。 总执行失败率 0.50，所有模型最差。 4.13.3 结论 不推荐在任何需要代码能力的场景中使用。 5. 横向对比分析 5.1 逻辑能力对比 模型 GSM8K BBH 逻辑分 Gemma-4-31B-IT-Uncensored 0.95 0.95 0.950 Qwen3.6-27B 0.95 0.95 0.950 Qwen3.6-27B-Neo-Code 0.95 0.85 0.900 QwOpus3.6-27B 0.95 0.85 0.900 SuperGemma4-26B-Uncensored 0.95 0.80 0.875 Qwen3.6-35B-A3B-Uncensored 0.95 0.80 0.875 Qwen3.5-27B 1.00 0.70 0.850 Qwen3.6-27B-MTP 0.90 0.80 0.850 Gemma-4-31B-IT-Claude-Opus 0.85 0.85 0.850 Gemma 4 - 26B A4B 0.90 0.65 0.775 SuperGemma4-26B-Abliterated 0.90 0.55 0.725 Qwen3.6-27B-Claude-Opus-Reasoning 0.95 0.35 0.650 Qwen3-Coder-Next 0.90 0.30 0.600 分析： Gemma-4-31B 与 Qwen3.6-27B 并列逻辑第一（0.950）。 Qwen3.6-27B-MTP 逻辑 0.850（GSM8K 0.90、BBH 0.80），处于中上水平。 逻辑分 ≥ 0.85 共有 9 个模型，MTP 版位列其中。 5.2 代码能力对比 模型 HumanEval+ MBPP+ 代码分 Gemma-4-31B-IT-Uncensored 1.00 1.00 1.000 Qwen3.5-27B 1.00 1.00 1.000 Qwen3-Coder-Next 1.00 1.00 1.000 QwOpus3.6-27B 1.00 1.00 1.000 Qwen3.6-27B-Claude-Opus-Reasoning 1.00 1.00 1.000 Qwen3.6-27B-MTP 1.00 1.00 1.000 Qwen3.6-27B-Neo-Code 1.00 0.90 0.950 SuperGemma4-26B-Uncensored 1.00 0.90 0.950 Qwen3.6-35B-A3B-Uncensored 1.00 0.90 0.950 Gemma 4 - 26B A4B 0.90 1.00 0.950 Gemma-4-31B-IT-Claude-Opus 0.80 1.00 0.900 Qwen3.6-27B 0.90 0.80 0.850 SuperGemma4-26B-Abliterated 0.10 0.90 0.500 分析： 六个模型代码满分 ，Qwen3.6-27B-MTP 新晋。 代码满分 + 零失败的模型：gemma-4-31b、qwen3.5-27b、qwopus3.6-27b、qwen3.6-27b-mtp、qwen3-coder-next、qwen3.6-27b-claude-opus-reasoning。 5.3 速度对比 模型 平均时延 SuperGemma4-26B-Uncensored 4.90s SuperGemma4-26B-Abliterated 8.04s Qwen3.6-27B-Claude-Opus-Reasoning 9.10s Gemma-4-31B-IT-Uncensored 17.64s Gemma 4 - 26B A4B 18.49s Qwen3.5-27B 38.25s QwOpus3.6-27B 44.63s Qwen3-Coder-Next 58.25s Gemma-4-31B-IT-Claude-Opus 69.27s Qwen3.6-27B-MTP 84.37s Qwen3.6-35B-A3B-Uncensored 100.35s Qwen3.6-27B-Neo-Code 101.76s Qwen3.6-27B 149.94s 5.4 稳定性对比 模型 执行失败率 Gemma-4-31B-IT-Uncensored 0.00 Qwen3.5-27B 0.00 Qwen3-Coder-Next 0.00 QwOpus3.6-27B 0.00 Qwen3.6-27B-Claude-Opus-Reasoning 0.00 Qwen3.6-27B-MTP 0.00 Qwen3.6-27B-Neo-Code 0.05 SuperGemma4-26B-Uncensored 0.05 Qwen3.6-35B-A3B-Uncensored 0.05 Gemma 4 - 26B A4B 0.05 Gemma-4-31B-IT-Claude-Opus 0.10 Qwen3.6-27B 0.15 SuperGemma4-26B-Abliterated 0.50 5.5 「代码满分 + 逻辑强」双维度交叉筛选 模型 代码分 BBH 总分 排名 Gemma-4-31B-IT-Uncensored 1.000 0.95 0.9750 1 QwOpus3.6-27B 1.000 0.85 0.9500 2 Qwen3.6-27B-MTP 1.000 0.80 0.9250 3 Qwen3.5-27B 1.000 0.70 0.9250 3 Qwen3.6-27B-Claude-Opus-Reasoning 1.000 0.35 0.8250 11 Qwen3-Coder-Next 1.000 0.30 0.8000 12 BBH 排序：gemma-4-31b(0.95) > qwopus3.6-27b(0.85) > qwen3.6-27b-mtp(0.80) > qwen3.5-27b(0.70) > claude-opus-reasoning(0.35) > qwen3-coder-next(0.30) Qwen3.6-27B-MTP 代码满分 + BBH 0.80，在代码满分阵营中逻辑排第三 5.6 Qwen3.6-27B 版本对比 版本 总分 逻辑分 代码分 时延 失败率 排名 qwen3.6-27b（原生） 0.9000 0.950 0.850 149.94s 0.15 8 qwen3.6-27b-mtp 0.9250 0.850 1.000 84.37s 0.00 3 qwen3.6-27b-claude-opus-reasoning 0.8250 0.650 1.000 9.10s 0.00 11 qwen3.6-27b-neo-code 0.9250 0.900 0.950 101.76s 0.05 3 MTP 版本是原生版的最佳「代码 + 速度」升级：代码满分、速度提升 44%、零失败 Neo-Code 版本是原生版的最佳「逻辑保持」升级：逻辑 0.900、代码 0.950 6. 关键结论 6.1 综合排名 Gemma-4-31B-IT-Uncensored （0.9750，断层第一，逻辑碾压 + 代码满分 + 零失败） QwOpus3.6-27B （0.9500，独占第二，BBH 大幅提升 + 代码满分 + 零失败） Qwen3.6-27B-Neo-Code （0.9250，并列第三，逻辑代码双强，速度偏慢） Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-v2 （0.9250，并列第三，代码 + 数学满分） **Qwen3.6-27B-MTP **（0.9250，并列第三，首测即跻身第一梯队，代码满分 + MTP 加速） SuperGemma4-26B-Uncensored （0.9125，并列第六，速度最快 4.90s） Qwen3.6-35B-A3B-Uncensored （0.9125，并列第六，质量高但速度慢） Qwen3.6-27B （0.9000，逻辑极强但速度最慢） Gemma-4-31B-IT-Claude-Opus （0.8750） Gemma 4 - 26B A4B x Claude Opus 4.6 （0.8625） Qwen3.6-27B-Claude-Opus-Reasoning （0.8250，代码专精） Qwen3-Coder-Next — Opus 4.6 Reasoning Distilled （0.8000，偏代码专用） SuperGemma4-26B-Abliterated-Multimodal （0.6125，不推荐） 6.2 场景化推荐 综合最强、全面无短板 Gemma-4-31B-IT-Uncensored （0.9750，断层第一） 综合强 + 代码满分 + 逻辑强 QwOpus3.6-27B （0.9500，BBH 0.85 + 代码满分） 代码满分 + MTP 投机加速 **Qwen3.6-27B-MTP ** 总分 0.9250，并列第三，首测即跻身第一梯队 代码双满分 + 零失败 BBH 0.80，逻辑中上 速度 84.37s，比原生版快 44% 原生 Qwen3.6-27B 用户的理想升级方案 综合强 + HumanEval+ 满分 + BBH 强 Qwen3.6-27B-Neo-Code （0.9250，BBH 0.85，速度偏慢 101.76s） 极致速度 SuperGemma4-26B-Uncensored （4.90s 最快） 逻辑极强 + 不在意速度 Qwen3.6-27B （逻辑 0.950 并列第一，但速度 149.94s 最慢；建议考虑 MTP 版本替代） 不推荐 SuperGemma4-26B-Abliterated-Multimodal （HumanEval+ 失败率 90%） 7. 最终总结 本次测试显示，十三个模型在"逻辑、代码、速度、稳定性"四个维度上表现差异显著。 Gemma-4-31B-IT-Uncensored ：综合实力断层第一（0.9750），逻辑碾压 + 代码满分 + 零失败，全能型首选。 QwOpus3.6-27B ：独占第二（0.9500），BBH 跃升至 0.85，唯一同时实现「代码双满分 + BBH ≥ 0.85」的模型。距第一仅差 0.025。 Qwen3.6-27B-Neo-Code ：并列第三（0.9250），逻辑与代码双强，BBH 0.85，速度偏慢。 Qwen3.5-27B ：并列第三（0.9250），代码满分 + 数学满分，BBH 0.70。 Qwen3.6-27B-MTP ★ ：并列第三（0.9250），首测即跻身第一梯队。相比原生版实现「代码满分 + 速度提升 44%」，是原生用户的理想升级方案。 SuperGemma4-26B-Uncensored ：并列第六（0.9125），速度极快（4.90s）。 Qwen3.6-35B-A3B-Uncensored ：并列第六（0.9125），质量高但速度第二慢。 Qwen3.6-27B ：综合第八（0.9000），逻辑极强并列第一，速度最慢（149.94s）。 Gemma-4-31B-IT-Claude-Opus ：综合第九（0.8750），逻辑稳健。 Gemma 4 - 26B A4B ：综合第十（0.8625），均衡型，速度较快。 Qwen3.6-27B-Claude-Opus-Reasoning ：综合第十一（0.8250），代码专精 + 速度优先，逻辑短板。 Qwen3-Coder-Next ：综合第十二（0.8000），偏代码专用。 SuperGemma4-26B-Abliterated-Multimodal ：综合第十三（0.6125），不推荐。 最终推荐（按优先级）： Gemma-4-31B-IT-Uncensored — 综合最强，全能首选 QwOpus3.6-27B — 代码满分 + BBH 0.85，性价比最高的综合强者 **Qwen3.6-27B-MTP ** — 代码满分 + MTP 加速，原生版最佳替代 SuperGemma4-26B-Uncensored — 速度 4.90s 最快，交互效率优先 14 个帖子 - 12 位参与者 阅读完整话题
IT之家 5 月 25 日消息，华为终端今日开启了 nova 16 系列手机的预热。 预热视频画面展示了夏日氛围感场景， 并通过道具布设暗示新机将采用横向双圆镜头结构设计 。 IT之家注意到，华为官方也同步公布， 将在 6 月 1 日 14:30 举行 nova 16 系列及全场景新品发布会 。 值得一提的是，一款采用类似“天空之镜”渐变色设计的手机已现身互联网平台。而据多位博主分享，该机或归属华为 nova 16 系列手机。画面显示，该机延续 nova 15 系列外观，镜组采用双筒设计。 此前有爆料称：“ 华为 nova 16 系列 6 月初发布 ，今年唯二逆势升配的线下拍照走量机，影像 / 性能 / 电池都加料了”。另外，华为新品全家桶还包括 nova 16 系列新手机、MatePad Pro Max 新平板、超新星手表等。
测试时间：2026-05-23 ，Asia/Singapore 晚高峰。 测试环境：Windows 本机开启 Claxx Verge TUN ，远端 IXP 机器通过 114.111.xxx.xxx:3500 SSH 登录。 重点对比三件事：每段 RTT 、BGP/上游形态、UDP 是否存在类似 Mkcloud 那种反向 size-window 黑洞。 1. 架构 + 各段实测延迟 家宽 PC / Claxx Verge TUN │ │ ⓐ 44 ms RTT │ ping 211.136.xxx.xxx, 8 包 0% loss ▼ NB 上海前置 - IP: 211.136.xxx.xxx - SS 端口: 3599 - RIPEstat origin: AS24400 / CMNET-V4SHANGHAI │ │ 通过 NB 链路进入 IXP ▼ NB IXP - 外部连接 IP: 114.111.xxx.xxx - SSH: 3500 - 内网 IP: 172.16.xxx.xxx - eth0 MTU: 1378 │ │ ⓑ 30.4-30.6 ms RTT │ IXP -> 172.16.xxx.xxx / 日本网关 ▼ 日本侧出口 / 网关 - mtr hop1: 172.16.xxx.xxx - hop2: 80.249.xxx.xxx, AS216211 CYBERVERSE-BACKBONE │ │ ⓒ 0.1-0.6 ms ▼ NB 日本 Hy2 落地 - 87.76.xxx.xxx - 87.76.xxx.xxx - RIPEstat: 87.76.xxx.xxx/24, AS206069 CORNSEED │ │ ⓓ 1-3 ms 到 Google Tokyo peer ▼ Google Tokyo / gstatic / 8.8.8.8 汇总表： 段 RTT 测法 ⓐ 本机 TUN -> 上海前置 211.136.xxx.xxx 44 ms ping -n 8 , 0% loss 本机 TUN -> JP4 87.76.xxx.xxx 91 ms ping -n 8 , 0% loss 本机 TUN -> JP9 87.76.xxx.xxx 81 ms ping -n 8 , 0% loss IXP 172.16.xxx.xxx -> 网关 172.16.xxx.xxx 30.5 ms mtr -c 20 , 0% loss IXP -> JP4 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> JP9 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> Google DNS 8.8.8.8 31.7 ms ping -c 8 , 0% loss IXP -> gstatic 142.250.xxx.xxx 32.4 ms mtr , 0% loss 到目标 最关键的是 IXP 机器的第一跳： HOST: nbnet-35 1. 172.16.xxx.xxx avg 30.5 ms 2. 87.76.xxx.xxx avg 30.6 ms 172.16.xxx.xxx 到默认网关 172.16.xxx.xxx 不是普通同机房 LAN 延迟，而是直接跳了约 30 ms 。结合后面一跳立刻到日本 AS206069 落地，可以判断 NB 的“上海 IXP -> 日本出口”主要固定开销约为 30 ms 。 和 Mkcloud 的 25.6 ms 沪日私线相比，NB 这段慢约 3-4 ms ，但仍然属于上海到东京/日本方向比较低的水平。 2. IXP 到日本出口 mtr 到 NB JP4 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS206069 87.76.xxx.xxx 0.0% 10 30.5 30.6 30.3 30.7 0.2 到 NB JP9 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.5 30.6 30.3 31.1 0.2 2. AS206069 87.76.xxx.xxx 0.0% 10 30.8 31.0 30.3 34.0 1.1 两个日本落地的路径非常短：IXP 出去第一跳已经是 30 ms 的跨境/跨区域固定延迟，第二跳就是落地 IP 。JP4 抖动更小，JP9 偶发到 34 ms ，但整体仍稳。 到 Google Tokyo HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS216211 80.249.xxx.xxx 0.0% 10 31.1 31.3 30.9 31.7 0.2 3. AS??? 210.173.xxx.xxx 0.0% 10 31.7 31.6 31.4 31.8 0.1 4. AS15169 72.14.xxx.xxx 0.0% 10 32.4 31.9 31.6 32.4 0.2 5. AS15169 Google internal 0.0% 10 32-35 ms 6. AS15169 Google internal 0.0% 10 32-33 ms 14. AS15169 gstatic 0.0% 10 32.4 ms avg IXP 到 Google Tokyo 基本就是 30 ms 私线/隧道开销加 1-3 ms 日本侧 peering 。路径里出现 AS216211 ，后续进 Google AS15169 。 3. BGP / 地址归属观察 RIPEstat 查到的结果： 资源 前缀 / ASN 说明 211.136.xxx.xxx 211.136.xxx.xxx/19 , AS24400 Shanghai Mobile / CMNET-V4SHANGHAI 114.111.xxx.xxx 114.111.xxx.xxx/20 , SHIXP National Shanghai New-Type Internet Exchange Point 114.111.xxx.xxx/24 IRR origin AS146762 Shanghai New-type Internet Exchange Point 80.249.xxx.xxx 80.249.xxx.xxx/24 , AS216211 CYBERVERSE-BACKBONE / CYBERVERSE LLC 87.76.xxx.xxx 87.76.xxx.xxx/24 , AS206069 CORNSEED, country JP AS206069 的 RIPEstat neighbours 显示上游里有： AS174 Cogent AS216211 CYBERVERSE-BACKBONE AS210352 这和 mtr 看到的路径吻合：NB IXP 出日本侧后，先走 AS216211 ，再进入 AS206069 的落地网段。 87.76.xxx.xxx/24 的 whois 里 country 标为 JP ，geofeed 来自 IPXO ；这类地址看起来是租用/托管型地址，不等同于物理绕路。实际 RTT 才是判断位置的关键，这里 IXP 到落地只有 30 ms ，说明物理出口在日本侧。 4. UDP size-window 测试 Mkcloud 的核心问题是：反向 UDP payload 320-530B 几乎 99.9% 丢包，而 300B 和 550B+ 又恢复正常。 这次对 NB 做了同样方向的 size 扫描：本机 TUN 发 UDP 到 IXP 外部口，IXP echo 回本机。 测试方法： server: 114.111.xxx.xxx:3588 UDP echo client: Windows 本机，走 Claxx Verge TUN rate: 1 Mbps time: 每个 payload 3 秒 固定速率结果： UDP payload 接收 / 发送 丢包率 100 B 3733 / 3750 0.45% 300 B 1250 / 1250 0% 310 B 1208 / 1209 0.08% 320 B 1168 / 1171 0.26% 400 B 937 / 937 0% 500 B 746 / 750 0.53% 530 B 705 / 707 0.28% 550 B 680 / 681 0.15% 600 B 624 / 625 0.16% 800 B 467 / 468 0.21% 1200 B 310 / 312 0.64% 结论很直接：没有发现 320-530B 的 size-window 黑洞。 310 -> 320B 没有断崖， 530 -> 550B 也没有恢复边界，所有测试点都在 0-0.64% 丢包范围内。 另外跑过一轮 burst 扫描，服务端对 100-530B 基本全收，说明正向没有按 size 丢包。burst 下大包 echo 回本机时丢包升高，但固定速率测试消失，因此更像本机/TUN 接收缓冲或瞬时 burst 压力，不是线路上的固定 size filter 。 5. 对比 Mkcloud 的关键差异 项 Mkcloud 沪日 NB 本次 上海 -> 日本固定开销 25.6 ms 30.4-30.6 ms IXP -> Google Tokyo 约 31-33 ms 31-33 ms 日本落地路径 Mkcloud TK -> IIJ/DDPS AS216211 -> AS206069 UDP 320-530B 反向黑洞 有，99.9% 未复现，0-0.64% IXP 网卡 MTU 未记录 1378 本机 URL/HTTP 体感 约 88 ms URL test curl 显式代理 total 281 ms ，TUN fake-ip total 506 ms NB 的跨境段比 Mkcloud 慢几毫秒，但 UDP 行为明显更正常。对 Hy2/QUIC/游戏 UDP 这类场景，不会具有 MK 那种会直接把某个包长窗口打穿的异常。 6. 总结 NB 这套链路的主要特点： 上海 IXP 到日本出口的固定 RTT 约 30.5 ms ，比 Mkcloud 的 25.6 ms 慢一点，但仍然低。 日本侧出口到 Google Tokyo / NB JP 落地只加 0-3 ms ，说明出口和落地都在日本侧，路径不绕远。 两个 87.76.xxx.xxx 落地都在 87.76.xxx.xxx/24 AS206069 ，IXP 到两者都是约 30.4 ms 。 没有发现 UDP 320-530B size-window 黑洞；固定 1 Mbps 下 100-1200B 全部基本可用。 需要注意 eth0 MTU=1378 ，这类封装链路对大包/PMTU 仍然应该保守配置，Hy2/QUIC 建议继续避免过大的 UDP payload 。 如果只看这次数据，NB 的问题不在 UDP size filter ，而在跨境固定延迟比 Mkcloud 多约 3-4 ms 。对日常 Google/YouTube 这类场景，链路行为是正常的。 不过，NB 还在测试阶段，线路尚未完全割接，期待未来的表现吧。 数据来源：本机 ping/curl 、远端 mtr/ping/curl 、自建 UDP echo 探针、RIPEstat network-info / whois / asn-neighbours API 。
测试时间：2026-05-23 ，Asia/Singapore 晚高峰。 测试环境：Windows 本机开启 Claxx Verge TUN ，远端 IXP 机器通过 114.111.xxx.xxx:3500 SSH 登录。 重点对比三件事：每段 RTT 、BGP/上游形态、UDP 是否存在类似 Mkcloud 那种反向 size-window 黑洞。 1. 架构 + 各段实测延迟 家宽 PC / Claxx Verge TUN │ │ ⓐ 44 ms RTT │ ping 211.136.xxx.xxx, 8 包 0% loss ▼ NB 上海前置 - IP: 211.136.xxx.xxx - SS 端口: 3599 - RIPEstat origin: AS24400 / CMNET-V4SHANGHAI │ │ 通过 NB 链路进入 IXP ▼ NB IXP - 外部连接 IP: 114.111.xxx.xxx - SSH: 3500 - 内网 IP: 172.16.xxx.xxx - eth0 MTU: 1378 │ │ ⓑ 30.4-30.6 ms RTT │ IXP -> 172.16.xxx.xxx / 日本网关 ▼ 日本侧出口 / 网关 - mtr hop1: 172.16.xxx.xxx - hop2: 80.249.xxx.xxx, AS216211 CYBERVERSE-BACKBONE │ │ ⓒ 0.1-0.6 ms ▼ NB 日本 Hy2 落地 - 87.76.xxx.xxx - 87.76.xxx.xxx - RIPEstat: 87.76.xxx.xxx/24, AS206069 CORNSEED │ │ ⓓ 1-3 ms 到 Google Tokyo peer ▼ Google Tokyo / gstatic / 8.8.8.8 汇总表： 段 RTT 测法 ⓐ 本机 TUN -> 上海前置 211.136.xxx.xxx 44 ms ping -n 8 , 0% loss 本机 TUN -> JP4 87.76.xxx.xxx 91 ms ping -n 8 , 0% loss 本机 TUN -> JP9 87.76.xxx.xxx 81 ms ping -n 8 , 0% loss IXP 172.16.xxx.xxx -> 网关 172.16.xxx.xxx 30.5 ms mtr -c 20 , 0% loss IXP -> JP4 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> JP9 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> Google DNS 8.8.8.8 31.7 ms ping -c 8 , 0% loss IXP -> gstatic 142.250.xxx.xxx 32.4 ms mtr , 0% loss 到目标 最关键的是 IXP 机器的第一跳： HOST: nbnet-35 1. 172.16.xxx.xxx avg 30.5 ms 2. 87.76.xxx.xxx avg 30.6 ms 172.16.xxx.xxx 到默认网关 172.16.xxx.xxx 不是普通同机房 LAN 延迟，而是直接跳了约 30 ms 。结合后面一跳立刻到日本 AS206069 落地，可以判断 NB 的“上海 IXP -> 日本出口”主要固定开销约为 30 ms 。 和 Mkcloud 的 25.6 ms 沪日私线相比，NB 这段慢约 3-4 ms ，但仍然属于上海到东京/日本方向比较低的水平。 2. IXP 到日本出口 mtr 到 NB JP4 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS206069 87.76.xxx.xxx 0.0% 10 30.5 30.6 30.3 30.7 0.2 到 NB JP9 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.5 30.6 30.3 31.1 0.2 2. AS206069 87.76.xxx.xxx 0.0% 10 30.8 31.0 30.3 34.0 1.1 两个日本落地的路径非常短：IXP 出去第一跳已经是 30 ms 的跨境/跨区域固定延迟，第二跳就是落地 IP 。JP4 抖动更小，JP9 偶发到 34 ms ，但整体仍稳。 到 Google Tokyo HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS216211 80.249.xxx.xxx 0.0% 10 31.1 31.3 30.9 31.7 0.2 3. AS??? 210.173.xxx.xxx 0.0% 10 31.7 31.6 31.4 31.8 0.1 4. AS15169 72.14.xxx.xxx 0.0% 10 32.4 31.9 31.6 32.4 0.2 5. AS15169 Google internal 0.0% 10 32-35 ms 6. AS15169 Google internal 0.0% 10 32-33 ms 14. AS15169 gstatic 0.0% 10 32.4 ms avg IXP 到 Google Tokyo 基本就是 30 ms 私线/隧道开销加 1-3 ms 日本侧 peering 。路径里出现 AS216211 ，后续进 Google AS15169 。 3. BGP / 地址归属观察 RIPEstat 查到的结果： 资源 前缀 / ASN 说明 211.136.xxx.xxx 211.136.xxx.xxx/19 , AS24400 Shanghai Mobile / CMNET-V4SHANGHAI 114.111.xxx.xxx 114.111.xxx.xxx/20 , SHIXP National Shanghai New-Type Internet Exchange Point 114.111.xxx.xxx/24 IRR origin AS146762 Shanghai New-type Internet Exchange Point 80.249.xxx.xxx 80.249.xxx.xxx/24 , AS216211 CYBERVERSE-BACKBONE / CYBERVERSE LLC 87.76.xxx.xxx 87.76.xxx.xxx/24 , AS206069 CORNSEED, country JP AS206069 的 RIPEstat neighbours 显示上游里有： AS174 Cogent AS216211 CYBERVERSE-BACKBONE AS210352 这和 mtr 看到的路径吻合：NB IXP 出日本侧后，先走 AS216211 ，再进入 AS206069 的落地网段。 87.76.xxx.xxx/24 的 whois 里 country 标为 JP ，geofeed 来自 IPXO ；这类地址看起来是租用/托管型地址，不等同于物理绕路。实际 RTT 才是判断位置的关键，这里 IXP 到落地只有 30 ms ，说明物理出口在日本侧。 4. UDP size-window 测试 Mkcloud 的核心问题是：反向 UDP payload 320-530B 几乎 99.9% 丢包，而 300B 和 550B+ 又恢复正常。 这次对 NB 做了同样方向的 size 扫描：本机 TUN 发 UDP 到 IXP 外部口，IXP echo 回本机。 测试方法： server: 114.111.xxx.xxx:3588 UDP echo client: Windows 本机，走 Claxx Verge TUN rate: 1 Mbps time: 每个 payload 3 秒 固定速率结果： UDP payload 接收 / 发送 丢包率 100 B 3733 / 3750 0.45% 300 B 1250 / 1250 0% 310 B 1208 / 1209 0.08% 320 B 1168 / 1171 0.26% 400 B 937 / 937 0% 500 B 746 / 750 0.53% 530 B 705 / 707 0.28% 550 B 680 / 681 0.15% 600 B 624 / 625 0.16% 800 B 467 / 468 0.21% 1200 B 310 / 312 0.64% 结论很直接：没有发现 320-530B 的 size-window 黑洞。 310 -> 320B 没有断崖， 530 -> 550B 也没有恢复边界，所有测试点都在 0-0.64% 丢包范围内。 另外跑过一轮 burst 扫描，服务端对 100-530B 基本全收，说明正向没有按 size 丢包。burst 下大包 echo 回本机时丢包升高，但固定速率测试消失，因此更像本机/TUN 接收缓冲或瞬时 burst 压力，不是线路上的固定 size filter 。 5. 对比 Mkcloud 的关键差异 项 Mkcloud 沪日 NB 本次 上海 -> 日本固定开销 25.6 ms 30.4-30.6 ms IXP -> Google Tokyo 约 31-33 ms 31-33 ms 日本落地路径 Mkcloud TK -> IIJ/DDPS AS216211 -> AS206069 UDP 320-530B 反向黑洞 有，99.9% 未复现，0-0.64% IXP 网卡 MTU 未记录 1378 本机 URL/HTTP 体感 约 88 ms URL test curl 显式代理 total 281 ms ，TUN fake-ip total 506 ms NB 的跨境段比 Mkcloud 慢几毫秒，但 UDP 行为明显更正常。对 Hy2/QUIC/游戏 UDP 这类场景，不会具有 MK 那种会直接把某个包长窗口打穿的异常。 6. 总结 NB 这套链路的主要特点： 上海 IXP 到日本出口的固定 RTT 约 30.5 ms ，比 Mkcloud 的 25.6 ms 慢一点，但仍然低。 日本侧出口到 Google Tokyo / NB JP 落地只加 0-3 ms ，说明出口和落地都在日本侧，路径不绕远。 两个 87.76.xxx.xxx 落地都在 87.76.xxx.xxx/24 AS206069 ，IXP 到两者都是约 30.4 ms 。 没有发现 UDP 320-530B size-window 黑洞；固定 1 Mbps 下 100-1200B 全部基本可用。 需要注意 eth0 MTU=1378 ，这类封装链路对大包/PMTU 仍然应该保守配置，Hy2/QUIC 建议继续避免过大的 UDP payload 。 如果只看这次数据，NB 的问题不在 UDP size filter ，而在跨境固定延迟比 Mkcloud 多约 3-4 ms 。对日常 Google/YouTube 这类场景，链路行为是正常的。 不过，NB 还在测试阶段，线路尚未完全割接，期待未来的表现吧。 数据来源：本机 ping/curl 、远端 mtr/ping/curl 、自建 UDP echo 探针、RIPEstat network-info / whois / asn-neighbours API 。
测试时间：2026-05-23 ，Asia/Singapore 晚高峰。 测试环境：Windows 本机开启 Claxx Verge TUN ，远端 IXP 机器通过 114.111.xxx.xxx:3500 SSH 登录。 重点对比三件事：每段 RTT 、BGP/上游形态、UDP 是否存在类似 Mkcloud 那种反向 size-window 黑洞。 1. 架构 + 各段实测延迟 家宽 PC / Claxx Verge TUN │ │ ⓐ 44 ms RTT │ ping 211.136.xxx.xxx, 8 包 0% loss ▼ NB 上海前置 - IP: 211.136.xxx.xxx - SS 端口: 3599 - RIPEstat origin: AS24400 / CMNET-V4SHANGHAI │ │ 通过 NB 链路进入 IXP ▼ NB IXP - 外部连接 IP: 114.111.xxx.xxx - SSH: 3500 - 内网 IP: 172.16.xxx.xxx - eth0 MTU: 1378 │ │ ⓑ 30.4-30.6 ms RTT │ IXP -> 172.16.xxx.xxx / 日本网关 ▼ 日本侧出口 / 网关 - mtr hop1: 172.16.xxx.xxx - hop2: 80.249.xxx.xxx, AS216211 CYBERVERSE-BACKBONE │ │ ⓒ 0.1-0.6 ms ▼ NB 日本 Hy2 落地 - 87.76.xxx.xxx - 87.76.xxx.xxx - RIPEstat: 87.76.xxx.xxx/24, AS206069 CORNSEED │ │ ⓓ 1-3 ms 到 Google Tokyo peer ▼ Google Tokyo / gstatic / 8.8.8.8 汇总表： 段 RTT 测法 ⓐ 本机 TUN -> 上海前置 211.136.xxx.xxx 44 ms ping -n 8 , 0% loss 本机 TUN -> JP4 87.76.xxx.xxx 91 ms ping -n 8 , 0% loss 本机 TUN -> JP9 87.76.xxx.xxx 81 ms ping -n 8 , 0% loss IXP 172.16.xxx.xxx -> 网关 172.16.xxx.xxx 30.5 ms mtr -c 20 , 0% loss IXP -> JP4 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> JP9 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> Google DNS 8.8.8.8 31.7 ms ping -c 8 , 0% loss IXP -> gstatic 142.250.xxx.xxx 32.4 ms mtr , 0% loss 到目标 最关键的是 IXP 机器的第一跳： HOST: nbnet-35 1. 172.16.xxx.xxx avg 30.5 ms 2. 87.76.xxx.xxx avg 30.6 ms 172.16.xxx.xxx 到默认网关 172.16.xxx.xxx 不是普通同机房 LAN 延迟，而是直接跳了约 30 ms 。结合后面一跳立刻到日本 AS206069 落地，可以判断 NB 的“上海 IXP -> 日本出口”主要固定开销约为 30 ms 。 和 Mkcloud 的 25.6 ms 沪日私线相比，NB 这段慢约 3-4 ms ，但仍然属于上海到东京/日本方向比较低的水平。 2. IXP 到日本出口 mtr 到 NB JP4 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS206069 87.76.xxx.xxx 0.0% 10 30.5 30.6 30.3 30.7 0.2 到 NB JP9 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.5 30.6 30.3 31.1 0.2 2. AS206069 87.76.xxx.xxx 0.0% 10 30.8 31.0 30.3 34.0 1.1 两个日本落地的路径非常短：IXP 出去第一跳已经是 30 ms 的跨境/跨区域固定延迟，第二跳就是落地 IP 。JP4 抖动更小，JP9 偶发到 34 ms ，但整体仍稳。 到 Google Tokyo HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS216211 80.249.xxx.xxx 0.0% 10 31.1 31.3 30.9 31.7 0.2 3. AS??? 210.173.xxx.xxx 0.0% 10 31.7 31.6 31.4 31.8 0.1 4. AS15169 72.14.xxx.xxx 0.0% 10 32.4 31.9 31.6 32.4 0.2 5. AS15169 Google internal 0.0% 10 32-35 ms 6. AS15169 Google internal 0.0% 10 32-33 ms 14. AS15169 gstatic 0.0% 10 32.4 ms avg IXP 到 Google Tokyo 基本就是 30 ms 私线/隧道开销加 1-3 ms 日本侧 peering 。路径里出现 AS216211 ，后续进 Google AS15169 。 3. BGP / 地址归属观察 RIPEstat 查到的结果： 资源 前缀 / ASN 说明 211.136.xxx.xxx 211.136.xxx.xxx/19 , AS24400 Shanghai Mobile / CMNET-V4SHANGHAI 114.111.xxx.xxx 114.111.xxx.xxx/20 , SHIXP National Shanghai New-Type Internet Exchange Point 114.111.xxx.xxx/24 IRR origin AS146762 Shanghai New-type Internet Exchange Point 80.249.xxx.xxx 80.249.xxx.xxx/24 , AS216211 CYBERVERSE-BACKBONE / CYBERVERSE LLC 87.76.xxx.xxx 87.76.xxx.xxx/24 , AS206069 CORNSEED, country JP AS206069 的 RIPEstat neighbours 显示上游里有： AS174 Cogent AS216211 CYBERVERSE-BACKBONE AS210352 这和 mtr 看到的路径吻合：NB IXP 出日本侧后，先走 AS216211 ，再进入 AS206069 的落地网段。 87.76.xxx.xxx/24 的 whois 里 country 标为 JP ，geofeed 来自 IPXO ；这类地址看起来是租用/托管型地址，不等同于物理绕路。实际 RTT 才是判断位置的关键，这里 IXP 到落地只有 30 ms ，说明物理出口在日本侧。 4. UDP size-window 测试 Mkcloud 的核心问题是：反向 UDP payload 320-530B 几乎 99.9% 丢包，而 300B 和 550B+ 又恢复正常。 这次对 NB 做了同样方向的 size 扫描：本机 TUN 发 UDP 到 IXP 外部口，IXP echo 回本机。 测试方法： server: 114.111.xxx.xxx:3588 UDP echo client: Windows 本机，走 Claxx Verge TUN rate: 1 Mbps time: 每个 payload 3 秒 固定速率结果： UDP payload 接收 / 发送 丢包率 100 B 3733 / 3750 0.45% 300 B 1250 / 1250 0% 310 B 1208 / 1209 0.08% 320 B 1168 / 1171 0.26% 400 B 937 / 937 0% 500 B 746 / 750 0.53% 530 B 705 / 707 0.28% 550 B 680 / 681 0.15% 600 B 624 / 625 0.16% 800 B 467 / 468 0.21% 1200 B 310 / 312 0.64% 结论很直接：没有发现 320-530B 的 size-window 黑洞。 310 -> 320B 没有断崖， 530 -> 550B 也没有恢复边界，所有测试点都在 0-0.64% 丢包范围内。 另外跑过一轮 burst 扫描，服务端对 100-530B 基本全收，说明正向没有按 size 丢包。burst 下大包 echo 回本机时丢包升高，但固定速率测试消失，因此更像本机/TUN 接收缓冲或瞬时 burst 压力，不是线路上的固定 size filter 。 5. 对比 Mkcloud 的关键差异 项 Mkcloud 沪日 NB 本次 上海 -> 日本固定开销 25.6 ms 30.4-30.6 ms IXP -> Google Tokyo 约 31-33 ms 31-33 ms 日本落地路径 Mkcloud TK -> IIJ/DDPS AS216211 -> AS206069 UDP 320-530B 反向黑洞 有，99.9% 未复现，0-0.64% IXP 网卡 MTU 未记录 1378 本机 URL/HTTP 体感 约 88 ms URL test curl 显式代理 total 281 ms ，TUN fake-ip total 506 ms NB 的跨境段比 Mkcloud 慢几毫秒，但 UDP 行为明显更正常。对 Hy2/QUIC/游戏 UDP 这类场景，不会具有 MK 那种会直接把某个包长窗口打穿的异常。 6. 总结 NB 这套链路的主要特点： 上海 IXP 到日本出口的固定 RTT 约 30.5 ms ，比 Mkcloud 的 25.6 ms 慢一点，但仍然低。 日本侧出口到 Google Tokyo / NB JP 落地只加 0-3 ms ，说明出口和落地都在日本侧，路径不绕远。 两个 87.76.xxx.xxx 落地都在 87.76.xxx.xxx/24 AS206069 ，IXP 到两者都是约 30.4 ms 。 没有发现 UDP 320-530B size-window 黑洞；固定 1 Mbps 下 100-1200B 全部基本可用。 需要注意 eth0 MTU=1378 ，这类封装链路对大包/PMTU 仍然应该保守配置，Hy2/QUIC 建议继续避免过大的 UDP payload 。 如果只看这次数据，NB 的问题不在 UDP size filter ，而在跨境固定延迟比 Mkcloud 多约 3-4 ms 。对日常 Google/YouTube 这类场景，链路行为是正常的。 不过，NB 还在测试阶段，线路尚未完全割接，期待未来的表现吧。 数据来源：本机 ping/curl 、远端 mtr/ping/curl 、自建 UDP echo 探针、RIPEstat network-info / whois / asn-neighbours API 。
测试时间：2026-05-23 ，Asia/Singapore 晚高峰。 测试环境：Windows 本机开启 Claxx Verge TUN ，远端 IXP 机器通过 114.111.xxx.xxx:3500 SSH 登录。 重点对比三件事：每段 RTT 、BGP/上游形态、UDP 是否存在类似 Mkcloud 那种反向 size-window 黑洞。 1. 架构 + 各段实测延迟 家宽 PC / Claxx Verge TUN │ │ ⓐ 44 ms RTT │ ping 211.136.xxx.xxx, 8 包 0% loss ▼ NB 上海前置 - IP: 211.136.xxx.xxx - SS 端口: 3599 - RIPEstat origin: AS24400 / CMNET-V4SHANGHAI │ │ 通过 NB 链路进入 IXP ▼ NB IXP - 外部连接 IP: 114.111.xxx.xxx - SSH: 3500 - 内网 IP: 172.16.xxx.xxx - eth0 MTU: 1378 │ │ ⓑ 30.4-30.6 ms RTT │ IXP -> 172.16.xxx.xxx / 日本网关 ▼ 日本侧出口 / 网关 - mtr hop1: 172.16.xxx.xxx - hop2: 80.249.xxx.xxx, AS216211 CYBERVERSE-BACKBONE │ │ ⓒ 0.1-0.6 ms ▼ NB 日本 Hy2 落地 - 87.76.xxx.xxx - 87.76.xxx.xxx - RIPEstat: 87.76.xxx.xxx/24, AS206069 CORNSEED │ │ ⓓ 1-3 ms 到 Google Tokyo peer ▼ Google Tokyo / gstatic / 8.8.8.8 汇总表： 段 RTT 测法 ⓐ 本机 TUN -> 上海前置 211.136.xxx.xxx 44 ms ping -n 8 , 0% loss 本机 TUN -> JP4 87.76.xxx.xxx 91 ms ping -n 8 , 0% loss 本机 TUN -> JP9 87.76.xxx.xxx 81 ms ping -n 8 , 0% loss IXP 172.16.xxx.xxx -> 网关 172.16.xxx.xxx 30.5 ms mtr -c 20 , 0% loss IXP -> JP4 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> JP9 87.76.xxx.xxx 30.4 ms ping -c 8 , 0% loss IXP -> Google DNS 8.8.8.8 31.7 ms ping -c 8 , 0% loss IXP -> gstatic 142.250.xxx.xxx 32.4 ms mtr , 0% loss 到目标 最关键的是 IXP 机器的第一跳： HOST: nbnet-35 1. 172.16.xxx.xxx avg 30.5 ms 2. 87.76.xxx.xxx avg 30.6 ms 172.16.xxx.xxx 到默认网关 172.16.xxx.xxx 不是普通同机房 LAN 延迟，而是直接跳了约 30 ms 。结合后面一跳立刻到日本 AS206069 落地，可以判断 NB 的“上海 IXP -> 日本出口”主要固定开销约为 30 ms 。 和 Mkcloud 的 25.6 ms 沪日私线相比，NB 这段慢约 3-4 ms ，但仍然属于上海到东京/日本方向比较低的水平。 2. IXP 到日本出口 mtr 到 NB JP4 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS206069 87.76.xxx.xxx 0.0% 10 30.5 30.6 30.3 30.7 0.2 到 NB JP9 HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.5 30.6 30.3 31.1 0.2 2. AS206069 87.76.xxx.xxx 0.0% 10 30.8 31.0 30.3 34.0 1.1 两个日本落地的路径非常短：IXP 出去第一跳已经是 30 ms 的跨境/跨区域固定延迟，第二跳就是落地 IP 。JP4 抖动更小，JP9 偶发到 34 ms ，但整体仍稳。 到 Google Tokyo HOST: nbnet-35 Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway 0.0% 10 30.4 30.4 30.3 30.8 0.1 2. AS216211 80.249.xxx.xxx 0.0% 10 31.1 31.3 30.9 31.7 0.2 3. AS??? 210.173.xxx.xxx 0.0% 10 31.7 31.6 31.4 31.8 0.1 4. AS15169 72.14.xxx.xxx 0.0% 10 32.4 31.9 31.6 32.4 0.2 5. AS15169 Google internal 0.0% 10 32-35 ms 6. AS15169 Google internal 0.0% 10 32-33 ms 14. AS15169 gstatic 0.0% 10 32.4 ms avg IXP 到 Google Tokyo 基本就是 30 ms 私线/隧道开销加 1-3 ms 日本侧 peering 。路径里出现 AS216211 ，后续进 Google AS15169 。 3. BGP / 地址归属观察 RIPEstat 查到的结果： 资源 前缀 / ASN 说明 211.136.xxx.xxx 211.136.xxx.xxx/19 , AS24400 Shanghai Mobile / CMNET-V4SHANGHAI 114.111.xxx.xxx 114.111.xxx.xxx/20 , SHIXP National Shanghai New-Type Internet Exchange Point 114.111.xxx.xxx/24 IRR origin AS146762 Shanghai New-type Internet Exchange Point 80.249.xxx.xxx 80.249.xxx.xxx/24 , AS216211 CYBERVERSE-BACKBONE / CYBERVERSE LLC 87.76.xxx.xxx 87.76.xxx.xxx/24 , AS206069 CORNSEED, country JP AS206069 的 RIPEstat neighbours 显示上游里有： AS174 Cogent AS216211 CYBERVERSE-BACKBONE AS210352 这和 mtr 看到的路径吻合：NB IXP 出日本侧后，先走 AS216211 ，再进入 AS206069 的落地网段。 87.76.xxx.xxx/24 的 whois 里 country 标为 JP ，geofeed 来自 IPXO ；这类地址看起来是租用/托管型地址，不等同于物理绕路。实际 RTT 才是判断位置的关键，这里 IXP 到落地只有 30 ms ，说明物理出口在日本侧。 4. UDP size-window 测试 Mkcloud 的核心问题是：反向 UDP payload 320-530B 几乎 99.9% 丢包，而 300B 和 550B+ 又恢复正常。 这次对 NB 做了同样方向的 size 扫描：本机 TUN 发 UDP 到 IXP 外部口，IXP echo 回本机。 测试方法： server: 114.111.xxx.xxx:3588 UDP echo client: Windows 本机，走 Claxx Verge TUN rate: 1 Mbps time: 每个 payload 3 秒 固定速率结果： UDP payload 接收 / 发送 丢包率 100 B 3733 / 3750 0.45% 300 B 1250 / 1250 0% 310 B 1208 / 1209 0.08% 320 B 1168 / 1171 0.26% 400 B 937 / 937 0% 500 B 746 / 750 0.53% 530 B 705 / 707 0.28% 550 B 680 / 681 0.15% 600 B 624 / 625 0.16% 800 B 467 / 468 0.21% 1200 B 310 / 312 0.64% 结论很直接：没有发现 320-530B 的 size-window 黑洞。 310 -> 320B 没有断崖， 530 -> 550B 也没有恢复边界，所有测试点都在 0-0.64% 丢包范围内。 另外跑过一轮 burst 扫描，服务端对 100-530B 基本全收，说明正向没有按 size 丢包。burst 下大包 echo 回本机时丢包升高，但固定速率测试消失，因此更像本机/TUN 接收缓冲或瞬时 burst 压力，不是线路上的固定 size filter 。 5. 对比 Mkcloud 的关键差异 项 Mkcloud 沪日 NB 本次 上海 -> 日本固定开销 25.6 ms 30.4-30.6 ms IXP -> Google Tokyo 约 31-33 ms 31-33 ms 日本落地路径 Mkcloud TK -> IIJ/DDPS AS216211 -> AS206069 UDP 320-530B 反向黑洞 有，99.9% 未复现，0-0.64% IXP 网卡 MTU 未记录 1378 本机 URL/HTTP 体感 约 88 ms URL test curl 显式代理 total 281 ms ，TUN fake-ip total 506 ms NB 的跨境段比 Mkcloud 慢几毫秒，但 UDP 行为明显更正常。对 Hy2/QUIC/游戏 UDP 这类场景，不会具有 MK 那种会直接把某个包长窗口打穿的异常。 6. 总结 NB 这套链路的主要特点： 上海 IXP 到日本出口的固定 RTT 约 30.5 ms ，比 Mkcloud 的 25.6 ms 慢一点，但仍然低。 日本侧出口到 Google Tokyo / NB JP 落地只加 0-3 ms ，说明出口和落地都在日本侧，路径不绕远。 两个 87.76.xxx.xxx 落地都在 87.76.xxx.xxx/24 AS206069 ，IXP 到两者都是约 30.4 ms 。 没有发现 UDP 320-530B size-window 黑洞；固定 1 Mbps 下 100-1200B 全部基本可用。 需要注意 eth0 MTU=1378 ，这类封装链路对大包/PMTU 仍然应该保守配置，Hy2/QUIC 建议继续避免过大的 UDP payload 。 如果只看这次数据，NB 的问题不在 UDP size filter ，而在跨境固定延迟比 Mkcloud 多约 3-4 ms 。对日常 Google/YouTube 这类场景，链路行为是正常的。 不过，NB 还在测试阶段，线路尚未完全割接，期待未来的表现吧。 数据来源：本机 ping/curl 、远端 mtr/ping/curl 、自建 UDP echo 探针、RIPEstat network-info / whois / asn-neighbours API 。
从帖子 deepseek v4 pro 天气卡片横向对比sonnetv4.5、sonnetv4.5-thinking 继续 模型来源： https://gemini.google.com/ 提示词 你是 Apple Inc 的顶级 UI 设计师，以 iOS 18 的设计风格（毛玻璃效果、高斯模糊、动态渐变、细腻阴影）创建一个单个HTML文件（包含完整CSS和JavaScript）。实现横板天气页面，包含4个并排的动画天气卡片： 晴天（太阳光线、动态光晕） 大风（飘动云朵、摇曳树木、风线） 暴雨（下落雨滴、形成水洼、闪电） 暴雪（下落雪花、堆积效果） 卡片需深色背景，支持按钮切换天气状态，实现流畅交互和微动效。代码必须可直接运行，美观度优先。 Gemini 3.5-flash 晴天 大风 暴雨 暴雪 Gemini 3.5-thinking 晴天 大风 暴雨 暴雪 简评 绘制的图案样式看起来没有提升，但动态效果非常丝滑，交互体验、反馈很舒适。gemini仍然是写网页前端的首选。二者的共同优点是-速度很快，非常快，秒出 叠甲 本次测试结果不代表模型完整能力，仅为快速测试gemini 3.5在特定提示词-天气卡片设计下的实际表现，同时此贴的截图也并非最真实结果，更多次的尝试可能回得到更好、更差的表现。 原代码（查看动态效果） 3.5flash.zip (4.8 KB) 3.5thinking.zip (5.1 KB) 3 个帖子 - 2 位参与者 阅读完整话题
IT之家 5 月 20 日消息， 荣耀 WIN 官方今日宣布，荣耀 WIN Turbo 定档 5 月 29 日 15:00 发布，新机将主打性能及续航。 IT之家注意到，博主 @数码闲聊站 今日发文透露，荣耀 WIN Turbo 手机将配备 1.5K LTPS 直屏 + 金属中框 + 50Mp OIS 横向大矩阵镜组，并提供 16GB+512GB 规格。 博主还提到，荣耀 WIN Turbo 手机的型号同 Power2。不过需要注意的是， 该机无内置风扇 。 相关阅读： 《 荣耀 WIN Turbo 手机官宣本月见，号称“耐玩战神” 》
185 135斤，穿XL尺寸正合适，长度适中不漏腰不邋遢，横向的版型不错，不像别的T恤大尺码就很肥。因为加了聚酯纤维和氨纶，穿起来不皱，而且有一丝凉感。薄厚也属于适中的水平，摸起来厚实不廉价，但也没有太厚让人闷汗。搭配69的价格真的很划算，我老婆看了摸了以后直呼比我之前买的那些花里胡哨的T恤强多了 11 个帖子 - 8 位参与者 阅读完整话题
经常需要帮老师写横向或科技项目的可行性研究报告，很费时间。求问各位佬友们有没有用过和这方面相关skill，旨在提升打杂的效率 12 个帖子 - 7 位参与者 阅读完整话题
导师看上了一个项目，几十万，让我去写标书竞标，然后中标了， 我以为这就结束了，结果让我自己一个人搞，写一个软件，这本来codex啥的勉强搞定，一开始还行，后来甲方要求每周汇报进度加答辩，我哪知道啊。 最近接近中期，一堆材料要写，甲方那边又挑出了很多毛病，还要改，还要进行中期答辩。整个项目就我一个人，其他同门过的很轻松， 唉真不知道咋办了，压力很大，每天睡不着觉。 6 个帖子 - 6 位参与者 阅读完整话题
对比了kimi cli 下使用k2.6 vs claude code下使用k2.6 vs codex 3 个帖子 - 1 位参与者 阅读完整话题
最近各种 AI 套餐真的越来越难比了。 看起来都是「几十块 / 一两百块一个月」，但实际差别很大： 有的是按月订阅 有的是 Token 计费 有的是 Coding Plan 有的是 5 小时窗口额度 有的是高峰期倍率消耗 有的是包年优惠 有的是国内人民币套餐 有的是海外美元套餐 每次想知道「到底哪个更划算」，都得打开一堆官网慢慢翻。 所以我做了一个专门比较 AI 套餐的网站： PlanTrack https://plantrack.uvlio.com/ 目前主要功能就是：把不同 AI 服务的套餐放在一起横向比较。 现在已经整理了 ChatGPT 、Claude 、Cursor 、Kimi 、MiniMax 、智谱 GLM 、阿里云百炼、火山方舟、讯飞星火、SenseNova 等平台的订阅 / Token / Coding 相关套餐，可以直接看： 每个平台有哪些套餐 月付 / 年付大概多少钱 折合人民币 / 美元是多少 套餐包含什么额度 适合聊天、写代码、API 调用还是重度使用 哪些套餐有活动价 / 包年价 同类套餐之间价格差多少 网站地址： https://plantrack.uvlio.com/ 开源地址： https://github.com/limitcool/plantrack 我做这个主要是因为现在 AI 套餐信息太分散了，尤其是订阅额度、模型限制、倍率消耗、Token 单价这些规则，经常不是写在同一个页面里。单看一个官网还行，要横向比较就很麻烦。 目前站点还比较早期，数据是爬取 + 手动整理，不保证完全实时，最终还是以官网为准。
最近各种 AI 套餐真的越来越难比了。 看起来都是「几十块 / 一两百块一个月」，但实际差别很大： 有的是按月订阅 有的是 Token 计费 有的是 Coding Plan 有的是 5 小时窗口额度 有的是高峰期倍率消耗 有的是包年优惠 有的是国内人民币套餐 有的是海外美元套餐 每次想知道「到底哪个更划算」，都得打开一堆官网慢慢翻。 所以我做了一个专门比较 AI 套餐的网站： PlanTrack https://plantrack.uvlio.com/ 目前主要功能就是：把不同 AI 服务的套餐放在一起横向比较。 现在已经整理了 ChatGPT 、Claude 、Cursor 、Kimi 、MiniMax 、智谱 GLM 、阿里云百炼、火山方舟、讯飞星火、SenseNova 等平台的订阅 / Token / Coding 相关套餐，可以直接看： 每个平台有哪些套餐 月付 / 年付大概多少钱 折合人民币 / 美元是多少 套餐包含什么额度 适合聊天、写代码、API 调用还是重度使用 哪些套餐有活动价 / 包年价 同类套餐之间价格差多少 网站地址： https://plantrack.uvlio.com/ 开源地址： https://github.com/limitcool/plantrack 我做这个主要是因为现在 AI 套餐信息太分散了，尤其是订阅额度、模型限制、倍率消耗、Token 单价这些规则，经常不是写在同一个页面里。单看一个官网还行，要横向比较就很麻烦。 目前站点还比较早期，数据是爬取 + 手动整理，不保证完全实时，最终还是以官网为准。
最近各种 AI 套餐真的越来越难比了。 看起来都是「几十块 / 一两百块一个月」，但实际差别很大： 有的是按月订阅 有的是 Token 计费 有的是 Coding Plan 有的是 5 小时窗口额度 有的是高峰期倍率消耗 有的是包年优惠 有的是国内人民币套餐 有的是海外美元套餐 每次想知道「到底哪个更划算」，都得打开一堆官网慢慢翻。 所以我做了一个专门比较 AI 套餐的网站： PlanTrack https://plantrack.uvlio.com/ 目前主要功能就是：把不同 AI 服务的套餐放在一起横向比较。 现在已经整理了 ChatGPT 、Claude 、Cursor 、Kimi 、MiniMax 、智谱 GLM 、阿里云百炼、火山方舟、讯飞星火、SenseNova 等平台的订阅 / Token / Coding 相关套餐，可以直接看： 每个平台有哪些套餐 月付 / 年付大概多少钱 折合人民币 / 美元是多少 套餐包含什么额度 适合聊天、写代码、API 调用还是重度使用 哪些套餐有活动价 / 包年价 同类套餐之间价格差多少 网站地址： https://plantrack.uvlio.com/ 开源地址： https://github.com/limitcool/plantrack 我做这个主要是因为现在 AI 套餐信息太分散了，尤其是订阅额度、模型限制、倍率消耗、Token 单价这些规则，经常不是写在同一个页面里。单看一个官网还行，要横向比较就很麻烦。 目前站点还比较早期，数据是爬取 + 手动整理，不保证完全实时，最终还是以官网为准。