主流大模型 AI Coding 能力对比评测

主流大模型多维度评审对比表

数据日期：2026-02-19
排序依据：综合能力从高到低：Claude Opus 4.6 > Kimi K2.5 > 智谱 GLM-5 > Claude Sonnet 4.5 > MiniMax M2.5 > DeepSeek V2
备注：✅为实测数据，其余为公开第三方权威测评数据（MMLU/CMMLU/SuperCLUE）

专项能力排名

1. 代码能力排名

1. DeepSeek V2（98.0 ✅ 实测代码生成 100% 通过）
2. Claude Sonnet 4.5（88）
3. Claude Opus 4.6（92）
4. 智谱 GLM-5（85）
5. MiniMax M2.5（80）
6. Kimi K2.5（57.5 ✅ 受强制 temperature=1 影响）

2. 性价比排名

1. DeepSeek V2（95 成本仅为 Opus 的 1%）
2. Claude Sonnet 4.5（75）
3. 智谱 GLM-5（70）
4. MiniMax M2.5（72）
5. Kimi K2.5（65）
6. Claude Opus 4.6（50 成本最高）

3. 长上下文能力排名

1. Kimi K2.5（1M tokens）
2. Claude Opus 4.6 / Sonnet 4.5（200K tokens）
3. 智谱 GLM-5 / MiniMax M2.5 / DeepSeek V2（128K tokens）

4. 中文能力排名

1. 智谱 GLM-5（94）
2. Kimi K2.5（90）
3. MiniMax M2.5（88）
4. Claude Opus 4.6（87）
5. Claude Sonnet 4.5（85）
6. DeepSeek V2（82）

选型推荐

AI Coding 能力

因为我对 Java/Rust 语言比较熟悉，所以想着以下面的提示词开发项目，看项目的吞吐量和完善程度来决定 AI Coding 的能力。

开发一个最高吞吐量的网关项目（任何语言都可以），开发完输出 吞吐量详细测试报告 第一优先级是吞吐量最高

AI Coding 结论

Kimi K2.5 开发的确实吞吐量高，但是他就一个 TS 直接实现，没考虑扩展性和配置结构，连接池等问题，可能通过提示词或者 skills 能让其代码质量提升，但是没必要。

Claude Opus 4.6 表现就好很多，代码结构和我想的差不多，也对 Cluster 多进程和 Trie 树进行了优化

Kimi K2.5

🚀 峰值性能指标:

• 最高吞吐量：249,935 RPS (约 250K RPS)
• 最低延迟：1.23ms 平均延迟
• 最高并发：50,000 并发连接
• 带宽利用率：245.12 Mbps
• 成功率：100% (所有测试场景)

Claude Opus 4.6

Gateway-Ops 吞吐量测试报告

测试环境

注意: 网关、上游服务、压测客户端均运行在同一台机器上，实际生产环境中分离部署吞吐量会显著更高。

核心结果

峰值吞吐量

详细场景测试结果

场景 1: Small JSON (32 Bytes)

小 JSON 响应体，模拟典型 API 调用。

场景 2: Medium JSON (~5KB)

中等 JSON 响应体 (100 条记录)，模拟列表查询。

场景 3: Large Payload (64KB)

大响应体，模拟文件下载/大数据传输。

场景 4: High Concurrency (1000 并发)

超高并发场景，测试网关在极端负载下的稳定性。

吞吐量总结

Small JSON (32B) ██████████████████ 9,069 req/s (34.2% efficiency)
Medium JSON (~5KB) █████████████████████ 10,493 req/s (35.4% efficiency)
Large Payload (64KB) ████████████ 5,789 req/s (38.6% efficiency)
High Concurrency (1000) ████████████████████████ 12,090 req/s (41.8% efficiency)

架构设计与优化策略

核心架构

┌──────────────────────────────┐
│ Primary Process              │
│ (cluster.isPrimary)          │
└──────────┬───────────────────┘
           │ fork x 8
┌──────────┼────────────────────┐
▼ ▼ ▼      ▼ ▼ ▼
┌──────────┐ ┌──────────┐ ... ┌──────────┐
│ Worker 1 │ │ Worker 2 │     │ Worker 8 │
│ HTTP Srv │ │ HTTP Srv │     │ HTTP Srv │
│ Router   │ │ Router   │     │ Router   │
│ ConnPool │ │ ConnPool │     │ ConnPool │
└────┬─────┘ └────┬─────┘     └────┬─────┘
     │ proxy      │ proxy          │ proxy
     ▼            ▼                ▼
┌─────────────────────────────────────────────────────┐
│ Upstream Services (cluster x 8)                     │
└─────────────────────────────────────────────────────┘

吞吐量优化技术

与同类网关对比 (参考值)

gateway-ops 在同机压测（三方共享 CPU）条件下达到 12K+ req/s，独立部署预估可达 30,000+ req/s。

如何复现测试

# 1. 启动 Mock 上游服务
node bench/mock-upstream.js
# 2. 启动网关 (新终端)
node src/gateway.js
# 3. 运行基准测试 (新终端)
node bench/run-benchmark.js

文件结构

gateway-ops/
├── config/
│   └── gateway.json # 网关配置 (路由、连接池、监听)
├── src/
│   ├── gateway.js # 入口 (cluster primary)
│   ├── worker.js # Worker 进程
│   ├── router.js # Trie 路由树
│   ├── proxy.js # 反向代理核心
│   └── connection-pool.js # HTTP Agent 连接池
├── bench/
│   ├── mock-upstream.js # Mock 上游服务
│   └── run-benchmark.js # 多进程基准测试
├── package.json
└── BENCHMARK-REPORT.md # 本报告