大模型 ai coding 比较
序
我主要用途是 ai coding，从各种渠道获取到了很多 不同的大模型排序
最多的是 opus 4.6 > k2.5 > glm5 > sonnet4.5 > m2.5
但是我 希望从自身实践的角度 进行测试，我把所有的平台都办了月卡
我在这个基础上 添加了deepseek v3
结论
确实opus 4.6 更适合 ai coding
glm5 可能是真的因为 资源不够，感觉降智，速度也慢，前两天 他们 发通知，寻求资源，目前可能不推荐
调研
我从
📊 评审维度明细：
1. 代码生成能力（权重40%）
测试目标 ：模型独立完成指定功能代码的能力
- 测评数据集：HumanEval 经典编程题（抽样10题）
- 核心指标： Pass@1 （一次生成代码直接通过所有测试用例的比例）
- 评分逻辑：题目完全通过得10分，失败得0分
- 实测结果：DeepSeek 10/10（100%通过），Kimi 2/10（20%通过）
2. Debug修复能力（权重35%）
测试目标 ：模型排查和修复代码问题的能力
- 测评数据集：DebugBench 真实bug场景（抽样9题）
- 覆盖Bug类型：语法错误、逻辑错误、性能优化三类
- 核心指标：Bug修复通过率
- 评分逻辑：成功修复得10分，修复失败/引入新问题得0分
- 实测结果：DeepSeek 9/9（100%通过），Kimi 7/9（77.8%通过）
3. 代码重构/项目理解能力（权重25%）
测试目标 ：模型对复杂项目的理解和工程化能力
- 测评题目：手工设计的企业级真实场景（10题）
- 覆盖题型：
- 读懂代码意图
- 函数拆分重构
- 接口改造升级
- 单元测试生成
- 跨文件依赖问题排查
- 评分维度：每道题从**正确性(40%)、可读性(30%)、完整性(30%)**三个角度综合打分（满分10分）
- 实测结果：DeepSeek 平均9.2/10，Kimi 平均9.0/10
4. 性价比维度
测试目标 ：模型的投入产出比
- 统计指标：
- 实际消耗的总Token量
- 输入/输出Token单价
- 本次测试实际花费金额
- 百万Tokens调用成本估算
- 实测结果：DeepSeek 4.5万tokens花费0.19元，性价比是Kimi的2.26倍
5. 公平性校验维度
为了保证测评结果客观公正，专门对可能影响结果的因素做了校验：
- Temperature差异影响：Kimi API强制t=1 vs DeepSeek可设置t=0，明确标注对代码生成任务的影响
- 裁判偏差：DeepSeek自裁判可能偏高，Kimi使用DeepSeek作为第三方裁判更客观
- 样本量说明：当前样本量30题，统计意义有限，建议后续扩大到100+题
- 数据污染风险：评估经典题目被模型训练集见过的可能性
6. 环境一致性维度
所有模型在完全相同的环境下测试：
- 统一评测框架：llm-coding-bench v1.0
- 统一代码执行超时：10秒
- 统一随机种子：42
- 统一裁判模型：DeepSeek-Chat（第三方交叉验证）
🎯 综合评分公式：
综合分 = (代码生成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%通过） |
专项能力排名
1. 代码能力排名
- DeepSeek V2（98.0 ✅ 实测代码生成100%通过）
- Claude Sonnet 4.5（88）
- Claude Opus 4.6（92）
- 智谱GLM-5（85）
- MiniMax M2.5（80）
- Kimi K2.5（57.5 ✅ 受强制temperature=1影响）
2. 性价比排名
- DeepSeek V2（95 成本仅为Opus的1%）
- Claude Sonnet 4.5（75）
- 智谱GLM-5（70）
- MiniMax M2.5（72）
- Kimi K2.5（65）
- Claude Opus 4.6（50 成本最高）
3. 长上下文能力排名
- Kimi K2.5（1M tokens）
- Claude Opus 4.6 / Sonnet 4.5（200K tokens）
- 智谱GLM-5 / MiniMax M2.5 / DeepSeek V2（128K tokens）
4. 中文能力排名
- 智谱GLM-5（94）
- Kimi K2.5（90）
- MiniMax M2.5（88）
- Claude Opus 4.6（87）
- Claude Sonnet 4.5（85）
- DeepSeek V2（82）
选型推荐
| 场景 | 首选模型 | 备选模型 |
|---|---|---|
| 专业领域（法律/医疗/金融） | 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开源系列 |
ai coding 能力
因为 我对 java rust语言比较熟悉，所以想着以下面的提示词 开发项目，看项目的吞吐量和完善程度 来决定ai coding的能力
开发一个最高吞吐量的网关项目（任何语言都可以），开发完输出 吞吐量详细测试报告
第一优先级是吞吐量最高
ai coding 结论
kimi2.5 开发的确实吞吐量高，但是他就一个ts 直接实现，没考虑扩展性和配置结构 ，连接池等问题，可能通过提示词 或者 skills 能让其代码质量提升，但是没必要
opus 4.6 表现就好很多，代码结构和我想的差不多，也对Cluster 多进程 和 trie树 进行了优化
kimi2.5
🚀 峰值性能指标:
- 最高吞吐量: 249,935 RPS (约250K RPS)
- 最低延迟: 1.23ms 平均延迟
- 最高并发: 50,000 并发连接
- 带宽利用率: 245.12 Mbps
- 成功率: 100% (所有测试场景)
opus 4.6
Gateway-Ops 吞吐量测试报告
测试环境
| 项目 | 值 |
|---|---|
| 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 (网关侧) |
详细场景测试结果
场景 1: Small JSON (32 Bytes)
小 JSON 响应体，模拟典型 API 调用。
| 指标 | 经网关 | 直连 | 开销 |
|---|---|---|---|
| Requests/sec | 9,069 | 26,542 | 65.8% |
| 总请求数 | 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 | - |
场景 2: Medium JSON (~5KB)
中等 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 | - |
场景 3: Large Payload (64KB)
大响应体，模拟文件下载/大数据传输。
| 指标 | 经网关 | 直连 | 开销 |
|---|---|---|---|
| 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 | - |
场景 4: High Concurrency (1000 并发)
超高并发场景，测试网关在极端负载下的稳定性。
| 指标 | 经网关 | 直连 | 开销 |
|---|---|---|---|
| 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 # 本报告 
