基于个人实践，对 Claude Opus 4.6、Kimi K2.5、智谱 GLM-5、DeepSeek V2 等主流大模型进行 AI Coding 能力横向对比。测试涵盖代码生成、Debug 修复、重构理解及性价比等维度。实测显示 DeepSeek V2 在代码生成与性价比上表现突出，Claude Opus 4.6 在逻辑推理与长文本处理上优势明显。通过构建高吞吐量网关项目验证，Opus 4.6 生成的代码结构更优，Kimi K2.5 虽峰值吞吐高但扩展性不足。结论推荐不同场景下的首选模型，为开发者选型提供参考。
本文主要用途是 AI Coding，从各种渠道获取到了很多不同的大模型排序。最多的是 Opus 4.6 > K2.5 > GLM-5 > Sonnet 4.5 > M2.5。
但我希望从自身实践的角度进行测试，我把所有的平台都办了月卡，在此基础上添加了 DeepSeek V2。
确实 Claude Opus 4.6 更适合 AI Coding
智谱 GLM-5 可能是真的因为资源不够，感觉降智，速度也慢，前两天他们发通知寻求资源，目前可能不推荐
我从多个维度进行了评审：
测试目标：模型独立完成指定功能代码的能力
测试目标：模型排查和修复代码问题的能力
测试目标：模型对复杂项目的理解和工程化能力
测试目标：模型的投入产出比
为了保证测评结果客观公正，专门对可能影响结果的因素做了校验：
所有模型在完全相同的环境下测试：
综合分 = (代码生成 Pass@1 × 40%) + (Debug 通过率 × 35%) + (重构平均分 × 25%)
数据日期：2026-02-19
排序依据：综合能力从高到低：Claude Opus 4.6 > Kimi K2.5 > 智谱 GLM-5 > Claude Sonnet 4.5 > MiniMax M2.5 > DeepSeek V2
备注：✅为实测数据，其余为公开第三方权威测评数据（MMLU/CMMLU/SuperCLUE）
| 模型名称 | 综合能力 （满分 100） | 代码能力 （满分 100） | 中文能力 （满分 100） | 多模态能力 （满分 100） | 长上下文 支持长度 | 性价比 （满分 100） | 核心优势 | 适用场景 | 数据来源 |
|---|---|---|---|---|---|---|---|---|---|
| Claude Opus 4.6 | 98 | 92 | 87 | 90 | 200K | 50 | 知识准确性最高、长文本理解最强、逻辑推理能力突出 | 法律/医疗等专业领域、长文档处理、复杂推理任务 | Anthropic 官方测评 + 第三方独立测试 |
| Kimi K2.5 | 93 | 57.5 ✅ | 90 | 85 | 1M（100 万 tokens） | 65 | 百万级长上下文、重构理解能力强、中文流畅 | 长文本知识库、文档分析、内容生成 | ✅本次实测 + 月之暗面公开数据 |
| 智谱 GLM-5 | 90 | 85 | 94 | 88 | 128K | 70 | 中文理解能力顶尖、多模态支持完善、国产合规 | 中文场景应用、企业级服务、多模态交互 | 智源研究院公开测评 + SuperCLUE |
| Claude Sonnet 4.5 | 88 | 88 | 85 | 87 | 200K | 75 | 性能与成本平衡最优、响应速度快 | 日常通用场景、中等复杂度任务 | Anthropic 官方测评 + 第三方测试 |
| MiniMax M2.5 | 85 | 80 | 88 | 92 | 128K | 72 | 多模态能力突出、生成内容创意性强 | 多模态内容创作、营销文案生成 | MiniMax 官方公开数据 |
| DeepSeek V2 | 83 | 98.0 ✅ | 82 | 75 | 128K | 95 | 代码能力顶尖、性价比极高、支持开源部署 | 代码开发、技术研发、本地化部署场景 | ✅本次实测（代码能力 100% 通过） |
| 场景 | 首选模型 | 备选模型 |
|---|---|---|
| 专业领域（法律/医疗/金融） | Claude Opus 4.6 | 智谱 GLM-5 |
| 长文档/知识库处理 | Kimi K2.5 | Claude Opus 4.6 |
| 代码开发/技术研发 | DeepSeek V2 | Claude Sonnet 4.5 |
| 中文通用场景 | 智谱 GLM-5 | Kimi K2.5 / MiniMax M2.5 |
| 性价比优先通用场景 | Claude Sonnet 4.5 | 智谱 GLM-5 |
| 多模态内容创作 | MiniMax M2.5 | 智谱 GLM-5 |
| 本地化部署/数据敏感场景 | DeepSeek V2 | Qwen2 开源系列 |
因为我对 Java/Rust 语言比较熟悉，所以想着以下面的提示词开发项目，看项目的吞吐量和完善程度来决定 AI Coding 的能力。
开发一个最高吞吐量的网关项目（任何语言都可以），开发完输出 吞吐量详细测试报告 第一优先级是吞吐量最高
Kimi K2.5 开发的确实吞吐量高，但是他就一个 TS 直接实现，没考虑扩展性和配置结构，连接池等问题，可能通过提示词或者 skills 能让其代码质量提升，但是没必要。
Claude Opus 4.6 表现就好很多，代码结构和我想的差不多，也对 Cluster 多进程和 Trie 树进行了优化
🚀 峰值性能指标:
| 项目 | 值 |
|---|---|
| CPU | Intel Core i7-1195G7 @ 2.90GHz (4 核 8 线程) |
| OS | Windows 10 (win32 x64) |
| Node.js | v24.13.0 |
| 测试日期 | 2026-02-19 |
| 网关 Workers | 8 进程 (cluster 模式) |
| Mock 上游 Workers | 8 进程 (cluster 模式) |
| Benchmark Workers | 4 进程 |
| 每场景测试时长 | 15 秒 |
注意: 网关、上游服务、压测客户端均运行在同一台机器上，实际生产环境中分离部署吞吐量会显著更高。
| 指标 | 值 |
|---|---|
| 峰值网关吞吐量 | 12,090 req/s |
| 峰值直连吞吐量 | 29,674 req/s |
| 峰值网关开销 | 59.3% |
| 零错误率 | 全场景 0 errors (网关侧) |
小 JSON 响应体，模拟典型 API 调用。
| 指标 | 经网关 | 直连 | 开销 |
|---|---|---|---|
| Requests/sec | 9,069 | 26,542 | - |
| 总请求数 | 136,210 | 398,258 | - |
| 吞吐量 (MB/s) | 0.19 | 0.56 | - |
| 错误数 | 0 | 65 | - |
| 延迟 Mean | 33.08ms | 11.30ms | - |
| 延迟 p50 | 6.68ms | 9.80ms | - |
| 延迟 p90 | 34.17ms | 17.15ms | - |
| 延迟 p95 | 60.98ms | 23.38ms | - |
| 延迟 p99 | 725.02ms | 53.47ms | - |
| 延迟 Max | 1473.82ms | 239.71ms | - |
中等 JSON 响应体 (100 条记录)，模拟列表查询。
| 指标 | 经网关 | 直连 | 开销 |
|---|---|---|---|
| Requests/sec | 10,493 | 29,674 | 64.6% |
| 总请求数 | 157,443 | 445,320 | - |
| 吞吐量 (MB/s) | 54.38 | 153.80 | - |
| 错误数 | 0 | 0 | - |
| 延迟 Mean | 28.61ms | 10.11ms | - |
| 延迟 p50 | 14.02ms | 8.48ms | - |
| 延迟 p90 | 33.13ms | 14.34ms | - |
| 延迟 p95 | 49.46ms | 19.01ms | - |
| 延迟 p99 | 508.73ms | 36.23ms | - |
| 延迟 Max | 1310.01ms | 182.23ms | - |
大响应体，模拟文件下载/大数据传输。
| 指标 | 经网关 | 直连 | 开销 |
|---|---|---|---|
| Requests/sec | 5,789 | 15,003 | 61.4% |
| 总请求数 | 86,857 | 225,326 | - |
| 吞吐量 (MB/s) | 361.84 | 937.66 | - |
| 错误数 | 0 | 0 | - |
| 延迟 Mean | 26.27ms | 10.13ms | - |
| 延迟 p50 | 21.26ms | 8.26ms | - |
| 延迟 p90 | 46.36ms | 16.78ms | - |
| 延迟 p95 | 63.43ms | 22.95ms | - |
| 延迟 p99 | 138.33ms | 37.21ms | - |
| 延迟 Max | 624.54ms | 125.89ms | - |
超高并发场景，测试网关在极端负载下的稳定性。
| 指标 | 经网关 | 直连 | 开销 |
|---|---|---|---|
| Requests/sec | 12,090 | 28,934 | 58.2% |
| 总请求数 | 182,733 | 434,650 | - |
| 吞吐量 (MB/s) | 0.25 | 0.61 | - |
| 错误数 | 0 | 0 | - |
| 延迟 Mean | 82.49ms | 34.55ms | - |
| 延迟 p50 | 29.78ms | 27.41ms | - |
| 延迟 p90 | 249.88ms | 50.17ms | - |
| 延迟 p95 | 441.99ms | 71.37ms | - |
| 延迟 p99 | 833.86ms | 201.85ms | - |
| 延迟 Max | 1969.38ms | 547.90ms | - |
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) │
└─────────────────────────────────────────────────────┘
| 优化项 | 说明 |
|---|---|
| Cluster 多进程 | 8 个 worker 进程充分利用所有 CPU 核心 |
| Trie 路由树 | O(k) 前缀匹配，k=前缀长度，零分配热路径 |
| 连接池复用 | HTTP Agent keep-alive，maxSockets=1024 |
| 上游解析缓存 | URL 解析结果缓存，避免重复 new URL() |
| 流式代理 (pipe) | 不缓冲响应体，直接 stream pipe |
| Hop-by-hop 头过滤 | 仅过滤必要的 hop-by-hop headers |
| 零依赖 | 纯 Node.js 原生 API，无第三方框架开销 |
| FIFO 调度 | 连接池使用 FIFO 调度，减少延迟抖动 |
| 高 backlog | listen backlog=4096，防止连接拒绝 |
| Keep-Alive 65s | 长 keep-alive 超时，最大化连接复用 |
| 网关 | 语言 | 典型 RPS (单机) | 备注 |
|---|---|---|---|
| gateway-ops | Node.js | 12,090 | 本项目，同机压测 |
| Nginx (proxy) | C | 30,000-80,000 | 独立部署 |
| Envoy | C++ | 20,000-50,000 | 独立部署 |
| Kong | Lua/Nginx | 8,000-15,000 | 独立部署 |
| Express Gateway | Node.js | 3,000-8,000 | 独立部署 |
| Fastify Proxy | Node.js | 5,000-12,000 | 独立部署 |
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 # 本报告
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online