neteroster

没看懂这是要比啥，语言模型和逻辑编程语言是两个完全不同的物种吧。那我还能说计算器能几 ns 算一个乘法，大模型慢得多呢，何意味...

不要折磨自己了，你这个又不是什么强隐私相关需求。长上下文、rag 这种都是重 prefill ，高计算的负载，M 芯片最不擅长的领域就是这，首字慢到你怀疑人生，16G 内存能跑的模型长上下文注意力可想而知...

@maolon Gemini 的 coding agent 就是不行，SWE 刷那么高，实际上一到实际工况里打不了 Opus 和 GPT 5.2 一点，毕竟 coding agent 起手就是 20+K ，再加上对指令遵循的强要求，都是 Gemini 的弱势区域

Gemini 3 Pro 的有效上下文在 32K 左右，日常使用（特别是多轮对话） 20K 就可注意到显著的注意力和指令遵循下降，40K-50K 左右注意力崩溃。有趣的是，这甚至是相比 Gemini 2.5 Pro 的倒退。甚至 Gemini 3 Flash 也比 Gemini 3 Pro 有效上下文高。

这个问题关注到的人并不多，无脑吹反而更多。RP （角色扮演）社区是最先注意到这个问题的，他们在 Gemini 3 Pro 还未发布在竞技场匿名测试时就系统测试了其上下文能力，并通过体感立即注意到异常。

GPT 5.2 (xhigh)，长程 Agent 任务执行的新高度

Agent 编码的话，拉完了！ Gemini 3 Pro 多轮对话 + (>20K 上下文) 的情况*几乎*是没法用的

当前推荐：

1. Claude Code / Cursor + Claude Opus 4.5
2. Codex + GPT-5.1 / GPT-5 / GPT-5-Codex-Max 或 Cursor + GPT-5 / GPT-5.1

其实 function call 或者 structure output 区别没那么大，推理后端没做约束解码的话，function call 的参数也不能保证准确... 做了约束解码的话，structure output 和 function call 都是保证准确的。

当然，唯一的例外的是，部分提供商只做了 function call ，或者只有 function call 用了约束解码

直接支付不支持大陆和香港卡，别想了

openrouter 不行，他那个 responses 是假的，无状态的。国内有一些中转是考虑了这个东西的，具体方法不明，据我粗略测试大多数应该是只开一个号，状态就不会有问题，还有少数*可能*做了状态管理