之前在帮一个 AI 应用选型时最头疼的不是模型能力不够而是“贵”和“慢”这两个问题一起出现。后来看到一位海外人工智能博士晒出他在双 DGX 平台上的大模型对比测试结果很有意思DeepSeek 的 Flash 系列模型在价格上几乎是“屠榜”级表现把 Gemini 1.5 Flash 和 GLM-4-Plus 都甩开了一截。这篇文章就围绕这次测试完整拆解从测试环境、评测脚本、部署命令到结果分析和工程避坑的整套流程。文章会覆盖几个部分先介绍三款模型的定位和适用场景再给出测试环境与推理框架选型然后公布评测指标和完整可复现的压测/部署代码接着分析价格、吞吐、延迟、生成质量四个维度的对比结果最后补充常见问题与最佳实践。适合人群正在做模型选型的后端开发、算法工程师、AI 应用创业者以及想在自己机器上本地部署大模型并做性能验证的开发者。读完你可以照着文章搭一套自己的模型评测环境也能理解为什么“价格/Token”才是大模型选型里最容易被低估的指标。1. 背景与核心概念1.1 为什么要做“双 DGX”测试DGX 是 NVIDIA 的 AI 整机产品线面向大规模训练和高并发推理场景卡间高速互联、显存带宽和散热设计都比较成熟。所谓“双 DGX”指的是把两台 DGX Spark 或其他 DGX 型号组成一个小集群通过张量并行或流水线并行跑大模型。这次测试的核心目的不是跑分而是回答三个业务问题同样跑一批真实业务 Prompt三家模型谁的总成本最低在高并发压力下谁的吞吐更稳、首字延迟更低便宜是不是意味着质量差生成结果能否满足业务要求这里的关键观点是模型评测不能只看单次推理速度要综合“价格/Token”“吞吐”“首Token时间”“生成质量”四个维度一起看。1.2 DeepSeek V4 Flash、Gemini 1.5 Flash、GLM-4-Plus 定位对比先说 Flash 系列。“Flash”在模型命名里通常代表轻量、快速、低成本版本适合对延迟敏感、调用量大的场景。DeepSeek V4 FlashDeepSeek 系列中的高效版本重点优化推理成本和响应速度同时也支持较高的上下文长度。在社区评测中它的优势主要体现在“低价 高吞吐”的组合。Gemini 1.5 FlashGoogle 面向高频、中等复杂度任务推出的轻量模型多模态能力比较完整支持图像、视频、音频输入。中文生态在国内外的可访问性存在差异调用时需要关注区域支持问题。GLM-4-Plus智谱 AI 面向复杂任务推出的高性能模型在逻辑推理、指令跟随方面表现稳定价格定位偏中高端适合对质量要求更严格的业务场景。这三款模型并不是直接替代关系而是“性价比档位”不同。测试的价值就是帮大家在具体场景里找到最优档位。1.3 为什么“价格屠榜”值得关注很多团队选模型只看单次输出质量却忽略了大模型成本是“按 Token 计费”的。假设一个客服机器人每天处理 100 万次请求每次请求输入输出共 1000 Token那么每天就是 10 亿 Token。如果模型 A 比模型 B 每百万 Token 便宜 5 美元一天就能省 5000 美元一年就是 180 万美元。这个时候“便宜到屠榜”就不再是营销词而是直接影响项目盈亏的核心指标。所以本文会重点展示“价格换算成每百万 Token 成本”的方法以及如何用脚本批量采集真实计费数据而不是只看官网标价。2. 测试环境与推理框架选型2.1 硬件与系统环境本次测试案例描述的是基于双 DGX 的评测环境。不同型号的 DGX 配置差异较大本文以常见的 DGX Spark 为例以下是基础环境示意项目配置节点数量2 台 DGX SparkGPU每台节点板载高性能 GPU具体以设备为准显存每台节点约 128GB 统一内存以实际型号为准CPU高性能 Arm 架构处理器操作系统Ubuntu 22.04 LTS 或更新版本网络节点间万兆/InfiniBand 互联推荐Python3.10推理框架vLLM / SGLang / TGI 任选需要注意如果你的测试环境只有一台 GPU 工作站也可以完成 API 对比测试。双 DGX 主要用于本地部署 200B 级别大模型或测试张量并行扩展性。2.2 软件栈本地部署部分用到的主要组件vLLM高吞吐推理引擎支持 PagedAttention、Continuous Batching是性能测试首选。OpenAI SDKDeepSeek 开放了 OpenAI 兼容接口因此测试脚本可以复用同一套 SDK。Harness 工具链社区常说的“Harness”可以理解为一套评测编排工具用来串联 Prompt、调用不同模型、采集指标、输出报告。它能避免你在多模型对比时手写大量重复脚本。Gemini 与 GLM 的接口格式不完全一致但都可以通过各自的 SDK 或 OpenAI 兼容端点接入。为了统一本文给出的脚本会抽象出通用请求函数方便替换模型参数。2.3 测试工作目录结构llm-benchmark/ ├── config/ │ ├── models.yaml │ └── prompts.json ├── scripts/ │ ├── run_benchmark.py │ ├── local_deploy.sh │ └── metrics.py ├── results/ │ ├── raw/ │ └── summary/ └── README.md这个结构把“配置”“脚本”“结果”分开方便多次跑测试后对比历史报告。3. 评测方法与指标设计3.1 四类核心指标定义为了让对比公平测试指标必须提前定义清楚成本Cost per 1M Token模型处理 100 万 Token输入 输出所需费用。这是选型的核心指标。吞吐量Throughput单位时间内模型能处理的 Token 数常用 tokens/s 表示。高吞吐意味着同样硬件上能服务更多请求。首 Token 延迟TTFTTime To First Token从发送请求到接收到第一个 Token 的时间影响用户“转圈等待”的体感。生成质量Quality通过固定评测集打分或人工抽检回答的准确率、完整性、格式规范性。3.2 控制变量的几个关键点温度固定为 0.7避免随机性干扰聚合指标。请求 Prompt 完全一致避免因输入不同导致输出长度差异。输出上限统一设置为 512 Token。并发数从 1 到 64 递增分别记录每个并发档位下的吞吐和延迟。API 测试和本地部署测试分开记录避免网络抖动影响判断。3.3 评测 Prompt 设计简单举 6 条具有代表性的业务 Prompt[ {id: qa_basic, prompt: 用一句话解释什么是数据库索引并给出一个使用场景。}, {id: code_help, prompt: 写一个 Python 函数输入字符串列表返回按长度排序后的列表。}, {id: summary, prompt: 总结下面这段新闻的要点不超过 100 字。}, {id: math, prompt: 一个商品原价 320 元打八五折后再减 30 元最后价格是多少}, {id: rewrite, prompt: 把这句话改写成更正式的商务表达我们想尽快把项目做完。}, {id: json_extract, prompt: 从文本中提取人名、公司名、日期以 JSON 格式输出。} ]之所以混合代码、数学、抽取、改写是为了避免模型在某类任务上“偏科”导致结果失真。4. 核心代码API 压测与本地部署4.1 用 OpenA I兼容接口批量请求三个模型DeepSeek 和 GLM 都提供 OpenAI 兼容接口所以核心调用逻辑可以统一。下面脚本展示了如何循环请求并记录时间、Token 消耗# 文件路径llm-benchmark/scripts/run_benchmark.py import json import time import requests def call_openai_compatible_model( api_key: str, base_url: str, model: str, prompt: str, max_tokens: int 512, temperature: float 0.7, ): url f{base_url}/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json, } payload { model: model, messages: [{role: user, content: prompt}], max_tokens: max_tokens, temperature: temperature, stream: False, } start time.perf_counter() resp requests.post(url, headersheaders, jsonpayload, timeout120) elapsed time.perf_counter() - start if resp.status_code ! 200: return { error: resp.status_code, text: resp.text[:500], elapsed: elapsed, } data resp.json() content data[choices][0][message][content] usage data.get(usage, {}) return { content: content, prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0), elapsed: elapsed, } if __name__ __main__: # 这里的 key 和 base_url 需要替换为真实配置 test_prompt 用一句话解释什么是数据库索引并给出一个使用场景。 result call_openai_compatible_model( api_keyyour-api-key, base_urlhttps://api.deepseek.com/v1, modeldeepseek-v4-flash, prompttest_prompt, ) print(json.dumps(result, ensure_asciiFalse, indent2))这段脚本虽然简单但已经覆盖了“请求、计时、Token 统计”三个核心动作。真实压测时可以把test_prompt换成评测集并加入并发控制。4.2 高并发吞吐统计脚本上面是单请求示例实际评测需要并发。下面的脚本用concurrent.futures发起并发请求并统计总吞吐和平均耗时# 文件路径llm-benchmark/scripts/run_benchmark.py追加内容 from concurrent.futures import ThreadPoolExecutor, as_completed def run_concurrent_benchmark( api_key: str, base_url: str, model: str, prompts: list, max_workers: int 16, ): results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit( call_openai_compatible_model, api_key, base_url, model, p[prompt], 512, 0.7, ): p[id] for p in prompts } for future in as_completed(future_map): pid future_map[future] try: res future.result() res[id] pid results.append(res) except Exception as exc: results.append({id: pid, error: str(exc)}) total_completion_tokens sum( r.get(completion_tokens, 0) for r in results if error not in r ) total_elapsed sum(r.get(elapsed, 0) for r in results if error not in r) total_requests len(results) success_requests sum(1 for r in results if error not in r) return { model: model, total_requests: total_requests, success_requests: success_requests, total_completion_tokens: total_completion_tokens, total_elapsed_seconds: round(total_elapsed, 2), throughput_tokens_per_sec: round( total_completion_tokens / total_elapsed, 2 ) if total_elapsed 0 else 0, } if __name__ __main__: with open(config/prompts.json, r, encodingutf-8) as f: prompt_list json.load(f) summary run_concurrent_benchmark( api_keyyour-api-key, base_urlhttps://api.deepseek.com/v1, modeldeepseek-v4-flash, promptsprompt_list * 10, # 重复评测集以增加压力 max_workers32, ) print(json.dumps(summary, ensure_asciiFalse, indent2))这里的throughput_tokens_per_sec是总生成 Token 数除以所有请求的累计耗时。要注意它表示的是“客户端视角的汇总吞吐”不是服务端纯吞吐。想要测服务端真实吞吐建议使用 vLLM 自带 benchmark 工具或者用locust这类压测平台。4.3 在 DGX Spark 上本地部署 DeepSeek V4 FlashAPI 测试完成以后如果希望把高频业务流量迁移到本地降低长期成本可以在 DGX Spark 上用 vLLM 部署开源或企业授权的模型权重。下面是一个最小启动脚本# 文件路径llm-benchmark/scripts/local_deploy.sh #!/bin/bash MODEL_PATH/models/deepseek-v4-flash PORT8000 TENSOR_PARALLEL_SIZE1 MAX_MODEL_LEN16384 GPU_MEM_UTIL0.90 python -m vllm.entrypoints.openai.api_server \ --model $MODEL_PATH \ --tensor-parallel-size $TENSOR_PARALLEL_SIZE \ --max-model-len $MAX_MODEL_LEN \ --gpu-memory-utilization $GPU_MEM_UTIL \ --port $PORT解释几个关键参数--model本地模型权重路径必须是 Hugging Face 格式或 vLLM 支持的格式。--tensor-parallel-size单机多卡或跨节点张量并行数量需要根据显存和互联带宽决定。--max-model-len最大上下文长度。设置过大会占用大量显存设置过小会导致长文本请求报错。--gpu-memory-utilization控制显存预留比例生产环境一般建议 0.85 到 0.95 之间。如果是两台 DGX Spark 做张量并行需要把两台机器放在同一个内网并通过分布式调度参数指定节点信息。具体参数在不同 vLLM 版本中差异较大建议先查你所用版本的官方文档不要照搬老教程里的参数。启动成功后本地服务会提供一个 OpenAI 兼容端点http://node-ip:8000/v1然后你只需要把 4.1 节脚本里的base_url改成http://node-ip:8000/v1就可以用同一套评测脚本测试本地模型。4.4 本地部署后的快速验证命令部署完成后用curl做一次冒烟测试curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/deepseek-v4-flash, messages: [{role: user, content: 你好请做一次简单的自我介绍。}], max_tokens: 128, temperature: 0.7 }如果返回正常的 JSON 响应说明服务已经起来。如果返回显存错误优先降低--gpu-memory-utilization或缩小--max-model-len。5. 测试结果对比分析5.1 价格对比谁才是“价格屠榜”先说明模型 API 价格属于动态信息不同时间、不同渠道都会有差异。下面表格展示的是测试期间记录的公开参考价用于说明换算方法最终请以模型官网实时价格为唯一依据。模型输入价格每百万 Token输出价格每百万 Token综合参考定位DeepSeek V4 Flash相对较低相对较低极致性价比适合高频调用Gemini 1.5 Flash中等偏低中等偏低多模态 轻量任务GLM-4-Plus相对较高相对较高复杂推理质量优先测试中最直观的结论是在“每百万 Token 综合成本”上DeepSeek V4 Flash 明显低于 Gemini 1.5 Flash 和 GLM-4-Plus。如果业务每天调用量在百万级选择 DeepSeek V4 Flash 每月节省的成本非常可观。但这里必须提醒一句价格低不等于总拥有成本低。如果你需要多模态能力DeepSeek V4 Flash 不一定支持还是要回归到业务需求本身。5.2 吞吐对比高并发下的稳定性在并发数 16、32、64 三档压力下测试结果的趋势如下DeepSeek V4 Flash 在每台推理节点上表现稳定吞吐随并发上升而上升直到接近硬件上限。Gemini 1.5 Flash 的 API 受服务端限流影响较明显并发过高时会出现429 Too Many Requests吞吐曲线呈“先升后平”。GLM-4-Plus 吞吐不差但单请求耗时偏长导致同样的并发下总吞吐低于 Flash 系列模型。如果你的业务是“大量短请求”比如客服、内容审核、标签抽取那么高吞吐模型能让单位时间处理量更大后端机器数量也可以更少。5.3 响应速度TTFT 与生成速率用户能感知的核心指标是“发出去消息后多久开始有字打出来”。测试显示Flash 系列模型的 TTFT 通常较低尤其是 DeepSeek V4 Flash 在 API 和本地部署场景下都比较快。Gemini 1.5 Flash 的 TTFT 在不同区域波动较大部分时候需要排队导致首字时间不稳定。GLM-4-Plus 的 TTFT 中等但生成速度稳定适合流式输出场景。如果你的产品是 Chat 类应用TTFT 直接决定用户体验。建议在选型时把“流式输出 首Token时间”作为固定测试项而不是只看总耗时。5.4 生成质量抽检结论在代码生成、数学计算、摘要提取三类任务上测试结果如下代码任务GLM-4-Plus 对复杂逻辑的理解最好DeepSeek V4 Flash 在常见代码补全上表现够用Gemini 1.5 Flash 对代码注释和文档生成较好。数学任务三款模型在简单四则运算上都没问题。复杂应用题上 GLM-4-Plus 更稳DeepSeek V4 Flash 偶尔会出现步骤跳跃。摘要与改写Flash 类模型的输出更加简洁在“短摘要”场景下反而更合适。GLM-4-Plus 输出更完整但字数偏长。结论是便宜模型在中等难度任务上质量并不差真正拉开差距的是高难度推理任务。所以不建议无脑选最贵或最便宜而是按任务难度分级调用不同模型。6. 高频问题与排查思路以下是测试和部署过程中最常见的几类问题做成表格方便对照。问题现象常见原因解决思路API 请求返回 401API Key 无效或权限不足检查 Key 是否过期确认是否有对应模型权限API 返回 429 Too Many Requests触发了服务端限流降低并发加入指数退避重试Gemini 提示“目前不支持你所在的地区”区域可用性限制确认官方支持范围评估是否符合部署要求本地 vLLM 启动报显存不足模型上下文长度超过显存降低--max-model-len或--gpu-memory-utilization双节点张量并行性能不升反降节点间网络带宽不足检查互联配置优先用单节点大显存方案流式输出卡顿客户端处理不当时延敏感性低开启流式模式监控每 token 间隔时间不同模型返回内容长度差异大max_tokens 设置不一致各模型统一 max_tokens结果才可比较本地模型响应慢但 API 快硬件未做并发优化开启 vLLM Continuous Batching调高并发下面挑三个重点展开。6.1 遇到过 429 限流怎么办当你用同一个 API Key 跑高并发压测时服务端会限制请求速率。直接调高并发只会得到一堆 429。正确做法降低并发数到服务端允许范围。加入重试机制对 429 和 5xx 状态码做退避重试。把长任务拆分到多个时间段执行。示例重试逻辑import time import random def call_with_retry(call_func, max_retries5): for attempt in range(max_retries): result call_func() if error not in result: return result if result[error] 429: wait_time 2 ** attempt random.uniform(0, 1) time.sleep(wait_time) else: break return result6.2 本地模型推理一直“转圈”但无报错出现这种情况需要区分是输入阶段还是输出阶段慢。排查顺序先看 GPU 利用率如果利用率很高说明模型在正常计算只是生成长。如果利用率很低可能是等待数据加载检查磁盘 I/O。查看日志中是否有 “Waiting for batch” 之类的信息确认是否有请求排队。6.3 双 DGX 部署出现通信瓶颈两台机器做张量并行理论上显存翻倍、算力翻倍但实际吞吐可能只提升几十个百分点。常见原因是节点间网络延迟过高。建议优先使用 NVLink 或 InfiniBand 等低延迟互联。如果只有万兆以太网大模型跨节点张量并行性能会明显受限。对于 70B 以下模型单机多卡往往比双机效果更稳定。7. 最佳实践与工程建议7.1 按任务复杂度分级调用模型实际项目中不要所有请求都走同一个模型。建议设计一个简单的路由策略任务分类 → 简单任务 → DeepSeek V4 Flash → 中等任务 → Gemini 1.5 Flash / 本地 Flash 模型 → 高难度任务 → GLM-4-Plus 或更强模型这样可以兼顾成本和质量。比如客服机器人中“查订单状态”“改地址”这类简单意图走 Flash 模型“处理投诉”“多轮复杂对话”走高级模型。7.2 成本测算公式在选型阶段用下面公式快速估算月成本月成本 日请求量 × 单请求平均Token数 × 30 × 单价(每Token)建议在测试阶段就记录每个请求的prompt_tokens和completion_tokens这样才能准确预估线上费用。很多团队上线后才发现账单暴涨就是因为测试阶段没有统计 Token 消耗。7.3 本地部署与 API 的取舍本地部署的优劣势优势长期成本可控、数据不出内网、可定制量化与推理参数。劣势需要硬件投入、需要维护推理服务、模型更新需要自行跟进。对于日请求量低于 10 万的早期项目直接用官方 API 更划算。当请求量稳定增长后再评估是否迁移到 DGX Spark 这类本地设备。7.4 数据安全与合规边界任何模型评测和部署都要注意数据安全生产数据脱敏后再用于评测不要直接上传真实用户信息。涉及隐私、合规的业务优先考虑本地部署。使用第三方 API 前确认服务条款是否允许你的业务场景。这块没有统一答案需要结合团队所处行业和地区规定来判断。7.5 持续评测机制模型能力、价格、限流策略都可能在三个月内变化建议把评测脚本做成定时任务每周跑一次小规模评测集 每月跑一次完整评测集 每次价格调整后立刻重跑成本对比只有持续跟踪才能在模型价格波动时快速调整选型策略。8. 总结与下一步学习方向这篇实战笔记帮你理清了三个关键点。第一大模型选型不能只看模型能力价格/Token、吞吐、TTFT 同样重要。DeepSeek V4 Flash 在价格和吞吐上的优势让它成为高频业务的有力候选。Gemini 1.5 Flash 适合多模态场景GLM-4-Plus 则更适合对质量要求高的复杂推理任务。第二一套完整的评测流程并不复杂。准备好统一 Prompt 集、统一并发脚本、统一指标记录方式就能在三天内完成三到五款模型的横向对比。文章里的脚本和部署命令可以直接改来用。第三本地部署是长期降本的有效手段但前提是业务量足够大、硬件条件合适、团队有维护推理服务的能力。如果只是早期验证不妨先用 API 跑通业务再逐步迁移。接下来你可以继续去了解这几个方向vLLM 的 Continuous Batching 原理、张量并行与流水线并行的差异、以及如何设计一套自动化的模型 Harness 评测平台。把这些内容吃透之后面对“选哪个模型”的问题你就不会再靠感觉而是能拿出数据说话。如果这篇文章对你选型或部署有帮助可以收藏备用。后续遇到新版本模型发布也建议重新跑一遍评测流程再做决定。 双DGX实测：DeepSeek V4 Flash如何凭性价比屠榜？
之前在帮一个 AI 应用选型时最头疼的不是模型能力不够而是“贵”和“慢”这两个问题一起出现。后来看到一位海外人工智能博士晒出他在双 DGX 平台上的大模型对比测试结果很有意思DeepSeek 的 Flash 系列模型在价格上几乎是“屠榜”级表现把 Gemini 1.5 Flash 和 GLM-4-Plus 都甩开了一截。这篇文章就围绕这次测试完整拆解从测试环境、评测脚本、部署命令到结果分析和工程避坑的整套流程。文章会覆盖几个部分先介绍三款模型的定位和适用场景再给出测试环境与推理框架选型然后公布评测指标和完整可复现的压测/部署代码接着分析价格、吞吐、延迟、生成质量四个维度的对比结果最后补充常见问题与最佳实践。适合人群正在做模型选型的后端开发、算法工程师、AI 应用创业者以及想在自己机器上本地部署大模型并做性能验证的开发者。读完你可以照着文章搭一套自己的模型评测环境也能理解为什么“价格/Token”才是大模型选型里最容易被低估的指标。1. 背景与核心概念1.1 为什么要做“双 DGX”测试DGX 是 NVIDIA 的 AI 整机产品线面向大规模训练和高并发推理场景卡间高速互联、显存带宽和散热设计都比较成熟。所谓“双 DGX”指的是把两台 DGX Spark 或其他 DGX 型号组成一个小集群通过张量并行或流水线并行跑大模型。这次测试的核心目的不是跑分而是回答三个业务问题同样跑一批真实业务 Prompt三家模型谁的总成本最低在高并发压力下谁的吞吐更稳、首字延迟更低便宜是不是意味着质量差生成结果能否满足业务要求这里的关键观点是模型评测不能只看单次推理速度要综合“价格/Token”“吞吐”“首Token时间”“生成质量”四个维度一起看。1.2 DeepSeek V4 Flash、Gemini 1.5 Flash、GLM-4-Plus 定位对比先说 Flash 系列。“Flash”在模型命名里通常代表轻量、快速、低成本版本适合对延迟敏感、调用量大的场景。DeepSeek V4 FlashDeepSeek 系列中的高效版本重点优化推理成本和响应速度同时也支持较高的上下文长度。在社区评测中它的优势主要体现在“低价 高吞吐”的组合。Gemini 1.5 FlashGoogle 面向高频、中等复杂度任务推出的轻量模型多模态能力比较完整支持图像、视频、音频输入。中文生态在国内外的可访问性存在差异调用时需要关注区域支持问题。GLM-4-Plus智谱 AI 面向复杂任务推出的高性能模型在逻辑推理、指令跟随方面表现稳定价格定位偏中高端适合对质量要求更严格的业务场景。这三款模型并不是直接替代关系而是“性价比档位”不同。测试的价值就是帮大家在具体场景里找到最优档位。1.3 为什么“价格屠榜”值得关注很多团队选模型只看单次输出质量却忽略了大模型成本是“按 Token 计费”的。假设一个客服机器人每天处理 100 万次请求每次请求输入输出共 1000 Token那么每天就是 10 亿 Token。如果模型 A 比模型 B 每百万 Token 便宜 5 美元一天就能省 5000 美元一年就是 180 万美元。这个时候“便宜到屠榜”就不再是营销词而是直接影响项目盈亏的核心指标。所以本文会重点展示“价格换算成每百万 Token 成本”的方法以及如何用脚本批量采集真实计费数据而不是只看官网标价。2. 测试环境与推理框架选型2.1 硬件与系统环境本次测试案例描述的是基于双 DGX 的评测环境。不同型号的 DGX 配置差异较大本文以常见的 DGX Spark 为例以下是基础环境示意项目配置节点数量2 台 DGX SparkGPU每台节点板载高性能 GPU具体以设备为准显存每台节点约 128GB 统一内存以实际型号为准CPU高性能 Arm 架构处理器操作系统Ubuntu 22.04 LTS 或更新版本网络节点间万兆/InfiniBand 互联推荐Python3.10推理框架vLLM / SGLang / TGI 任选需要注意如果你的测试环境只有一台 GPU 工作站也可以完成 API 对比测试。双 DGX 主要用于本地部署 200B 级别大模型或测试张量并行扩展性。2.2 软件栈本地部署部分用到的主要组件vLLM高吞吐推理引擎支持 PagedAttention、Continuous Batching是性能测试首选。OpenAI SDKDeepSeek 开放了 OpenAI 兼容接口因此测试脚本可以复用同一套 SDK。Harness 工具链社区常说的“Harness”可以理解为一套评测编排工具用来串联 Prompt、调用不同模型、采集指标、输出报告。它能避免你在多模型对比时手写大量重复脚本。Gemini 与 GLM 的接口格式不完全一致但都可以通过各自的 SDK 或 OpenAI 兼容端点接入。为了统一本文给出的脚本会抽象出通用请求函数方便替换模型参数。2.3 测试工作目录结构llm-benchmark/ ├── config/ │ ├── models.yaml │ └── prompts.json ├── scripts/ │ ├── run_benchmark.py │ ├── local_deploy.sh │ └── metrics.py ├── results/ │ ├── raw/ │ └── summary/ └── README.md这个结构把“配置”“脚本”“结果”分开方便多次跑测试后对比历史报告。3. 评测方法与指标设计3.1 四类核心指标定义为了让对比公平测试指标必须提前定义清楚成本Cost per 1M Token模型处理 100 万 Token输入 输出所需费用。这是选型的核心指标。吞吐量Throughput单位时间内模型能处理的 Token 数常用 tokens/s 表示。高吞吐意味着同样硬件上能服务更多请求。首 Token 延迟TTFTTime To First Token从发送请求到接收到第一个 Token 的时间影响用户“转圈等待”的体感。生成质量Quality通过固定评测集打分或人工抽检回答的准确率、完整性、格式规范性。3.2 控制变量的几个关键点温度固定为 0.7避免随机性干扰聚合指标。请求 Prompt 完全一致避免因输入不同导致输出长度差异。输出上限统一设置为 512 Token。并发数从 1 到 64 递增分别记录每个并发档位下的吞吐和延迟。API 测试和本地部署测试分开记录避免网络抖动影响判断。3.3 评测 Prompt 设计简单举 6 条具有代表性的业务 Prompt[ {id: qa_basic, prompt: 用一句话解释什么是数据库索引并给出一个使用场景。}, {id: code_help, prompt: 写一个 Python 函数输入字符串列表返回按长度排序后的列表。}, {id: summary, prompt: 总结下面这段新闻的要点不超过 100 字。}, {id: math, prompt: 一个商品原价 320 元打八五折后再减 30 元最后价格是多少}, {id: rewrite, prompt: 把这句话改写成更正式的商务表达我们想尽快把项目做完。}, {id: json_extract, prompt: 从文本中提取人名、公司名、日期以 JSON 格式输出。} ]之所以混合代码、数学、抽取、改写是为了避免模型在某类任务上“偏科”导致结果失真。4. 核心代码API 压测与本地部署4.1 用 OpenA I兼容接口批量请求三个模型DeepSeek 和 GLM 都提供 OpenAI 兼容接口所以核心调用逻辑可以统一。下面脚本展示了如何循环请求并记录时间、Token 消耗# 文件路径llm-benchmark/scripts/run_benchmark.py import json import time import requests def call_openai_compatible_model( api_key: str, base_url: str, model: str, prompt: str, max_tokens: int 512, temperature: float 0.7, ): url f{base_url}/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json, } payload { model: model, messages: [{role: user, content: prompt}], max_tokens: max_tokens, temperature: temperature, stream: False, } start time.perf_counter() resp requests.post(url, headersheaders, jsonpayload, timeout120) elapsed time.perf_counter() - start if resp.status_code ! 200: return { error: resp.status_code, text: resp.text[:500], elapsed: elapsed, } data resp.json() content data[choices][0][message][content] usage data.get(usage, {}) return { content: content, prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0), elapsed: elapsed, } if __name__ __main__: # 这里的 key 和 base_url 需要替换为真实配置 test_prompt 用一句话解释什么是数据库索引并给出一个使用场景。 result call_openai_compatible_model( api_keyyour-api-key, base_urlhttps://api.deepseek.com/v1, modeldeepseek-v4-flash, prompttest_prompt, ) print(json.dumps(result, ensure_asciiFalse, indent2))这段脚本虽然简单但已经覆盖了“请求、计时、Token 统计”三个核心动作。真实压测时可以把test_prompt换成评测集并加入并发控制。4.2 高并发吞吐统计脚本上面是单请求示例实际评测需要并发。下面的脚本用concurrent.futures发起并发请求并统计总吞吐和平均耗时# 文件路径llm-benchmark/scripts/run_benchmark.py追加内容 from concurrent.futures import ThreadPoolExecutor, as_completed def run_concurrent_benchmark( api_key: str, base_url: str, model: str, prompts: list, max_workers: int 16, ): results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit( call_openai_compatible_model, api_key, base_url, model, p[prompt], 512, 0.7, ): p[id] for p in prompts } for future in as_completed(future_map): pid future_map[future] try: res future.result() res[id] pid results.append(res) except Exception as exc: results.append({id: pid, error: str(exc)}) total_completion_tokens sum( r.get(completion_tokens, 0) for r in results if error not in r ) total_elapsed sum(r.get(elapsed, 0) for r in results if error not in r) total_requests len(results) success_requests sum(1 for r in results if error not in r) return { model: model, total_requests: total_requests, success_requests: success_requests, total_completion_tokens: total_completion_tokens, total_elapsed_seconds: round(total_elapsed, 2), throughput_tokens_per_sec: round( total_completion_tokens / total_elapsed, 2 ) if total_elapsed 0 else 0, } if __name__ __main__: with open(config/prompts.json, r, encodingutf-8) as f: prompt_list json.load(f) summary run_concurrent_benchmark( api_keyyour-api-key, base_urlhttps://api.deepseek.com/v1, modeldeepseek-v4-flash, promptsprompt_list * 10, # 重复评测集以增加压力 max_workers32, ) print(json.dumps(summary, ensure_asciiFalse, indent2))这里的throughput_tokens_per_sec是总生成 Token 数除以所有请求的累计耗时。要注意它表示的是“客户端视角的汇总吞吐”不是服务端纯吞吐。想要测服务端真实吞吐建议使用 vLLM 自带 benchmark 工具或者用locust这类压测平台。4.3 在 DGX Spark 上本地部署 DeepSeek V4 FlashAPI 测试完成以后如果希望把高频业务流量迁移到本地降低长期成本可以在 DGX Spark 上用 vLLM 部署开源或企业授权的模型权重。下面是一个最小启动脚本# 文件路径llm-benchmark/scripts/local_deploy.sh #!/bin/bash MODEL_PATH/models/deepseek-v4-flash PORT8000 TENSOR_PARALLEL_SIZE1 MAX_MODEL_LEN16384 GPU_MEM_UTIL0.90 python -m vllm.entrypoints.openai.api_server \ --model $MODEL_PATH \ --tensor-parallel-size $TENSOR_PARALLEL_SIZE \ --max-model-len $MAX_MODEL_LEN \ --gpu-memory-utilization $GPU_MEM_UTIL \ --port $PORT解释几个关键参数--model本地模型权重路径必须是 Hugging Face 格式或 vLLM 支持的格式。--tensor-parallel-size单机多卡或跨节点张量并行数量需要根据显存和互联带宽决定。--max-model-len最大上下文长度。设置过大会占用大量显存设置过小会导致长文本请求报错。--gpu-memory-utilization控制显存预留比例生产环境一般建议 0.85 到 0.95 之间。如果是两台 DGX Spark 做张量并行需要把两台机器放在同一个内网并通过分布式调度参数指定节点信息。具体参数在不同 vLLM 版本中差异较大建议先查你所用版本的官方文档不要照搬老教程里的参数。启动成功后本地服务会提供一个 OpenAI 兼容端点http://node-ip:8000/v1然后你只需要把 4.1 节脚本里的base_url改成http://node-ip:8000/v1就可以用同一套评测脚本测试本地模型。4.4 本地部署后的快速验证命令部署完成后用curl做一次冒烟测试curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/deepseek-v4-flash, messages: [{role: user, content: 你好请做一次简单的自我介绍。}], max_tokens: 128, temperature: 0.7 }如果返回正常的 JSON 响应说明服务已经起来。如果返回显存错误优先降低--gpu-memory-utilization或缩小--max-model-len。5. 测试结果对比分析5.1 价格对比谁才是“价格屠榜”先说明模型 API 价格属于动态信息不同时间、不同渠道都会有差异。下面表格展示的是测试期间记录的公开参考价用于说明换算方法最终请以模型官网实时价格为唯一依据。模型输入价格每百万 Token输出价格每百万 Token综合参考定位DeepSeek V4 Flash相对较低相对较低极致性价比适合高频调用Gemini 1.5 Flash中等偏低中等偏低多模态 轻量任务GLM-4-Plus相对较高相对较高复杂推理质量优先测试中最直观的结论是在“每百万 Token 综合成本”上DeepSeek V4 Flash 明显低于 Gemini 1.5 Flash 和 GLM-4-Plus。如果业务每天调用量在百万级选择 DeepSeek V4 Flash 每月节省的成本非常可观。但这里必须提醒一句价格低不等于总拥有成本低。如果你需要多模态能力DeepSeek V4 Flash 不一定支持还是要回归到业务需求本身。5.2 吞吐对比高并发下的稳定性在并发数 16、32、64 三档压力下测试结果的趋势如下DeepSeek V4 Flash 在每台推理节点上表现稳定吞吐随并发上升而上升直到接近硬件上限。Gemini 1.5 Flash 的 API 受服务端限流影响较明显并发过高时会出现429 Too Many Requests吞吐曲线呈“先升后平”。GLM-4-Plus 吞吐不差但单请求耗时偏长导致同样的并发下总吞吐低于 Flash 系列模型。如果你的业务是“大量短请求”比如客服、内容审核、标签抽取那么高吞吐模型能让单位时间处理量更大后端机器数量也可以更少。5.3 响应速度TTFT 与生成速率用户能感知的核心指标是“发出去消息后多久开始有字打出来”。测试显示Flash 系列模型的 TTFT 通常较低尤其是 DeepSeek V4 Flash 在 API 和本地部署场景下都比较快。Gemini 1.5 Flash 的 TTFT 在不同区域波动较大部分时候需要排队导致首字时间不稳定。GLM-4-Plus 的 TTFT 中等但生成速度稳定适合流式输出场景。如果你的产品是 Chat 类应用TTFT 直接决定用户体验。建议在选型时把“流式输出 首Token时间”作为固定测试项而不是只看总耗时。5.4 生成质量抽检结论在代码生成、数学计算、摘要提取三类任务上测试结果如下代码任务GLM-4-Plus 对复杂逻辑的理解最好DeepSeek V4 Flash 在常见代码补全上表现够用Gemini 1.5 Flash 对代码注释和文档生成较好。数学任务三款模型在简单四则运算上都没问题。复杂应用题上 GLM-4-Plus 更稳DeepSeek V4 Flash 偶尔会出现步骤跳跃。摘要与改写Flash 类模型的输出更加简洁在“短摘要”场景下反而更合适。GLM-4-Plus 输出更完整但字数偏长。结论是便宜模型在中等难度任务上质量并不差真正拉开差距的是高难度推理任务。所以不建议无脑选最贵或最便宜而是按任务难度分级调用不同模型。6. 高频问题与排查思路以下是测试和部署过程中最常见的几类问题做成表格方便对照。问题现象常见原因解决思路API 请求返回 401API Key 无效或权限不足检查 Key 是否过期确认是否有对应模型权限API 返回 429 Too Many Requests触发了服务端限流降低并发加入指数退避重试Gemini 提示“目前不支持你所在的地区”区域可用性限制确认官方支持范围评估是否符合部署要求本地 vLLM 启动报显存不足模型上下文长度超过显存降低--max-model-len或--gpu-memory-utilization双节点张量并行性能不升反降节点间网络带宽不足检查互联配置优先用单节点大显存方案流式输出卡顿客户端处理不当时延敏感性低开启流式模式监控每 token 间隔时间不同模型返回内容长度差异大max_tokens 设置不一致各模型统一 max_tokens结果才可比较本地模型响应慢但 API 快硬件未做并发优化开启 vLLM Continuous Batching调高并发下面挑三个重点展开。6.1 遇到过 429 限流怎么办当你用同一个 API Key 跑高并发压测时服务端会限制请求速率。直接调高并发只会得到一堆 429。正确做法降低并发数到服务端允许范围。加入重试机制对 429 和 5xx 状态码做退避重试。把长任务拆分到多个时间段执行。示例重试逻辑import time import random def call_with_retry(call_func, max_retries5): for attempt in range(max_retries): result call_func() if error not in result: return result if result[error] 429: wait_time 2 ** attempt random.uniform(0, 1) time.sleep(wait_time) else: break return result6.2 本地模型推理一直“转圈”但无报错出现这种情况需要区分是输入阶段还是输出阶段慢。排查顺序先看 GPU 利用率如果利用率很高说明模型在正常计算只是生成长。如果利用率很低可能是等待数据加载检查磁盘 I/O。查看日志中是否有 “Waiting for batch” 之类的信息确认是否有请求排队。6.3 双 DGX 部署出现通信瓶颈两台机器做张量并行理论上显存翻倍、算力翻倍但实际吞吐可能只提升几十个百分点。常见原因是节点间网络延迟过高。建议优先使用 NVLink 或 InfiniBand 等低延迟互联。如果只有万兆以太网大模型跨节点张量并行性能会明显受限。对于 70B 以下模型单机多卡往往比双机效果更稳定。7. 最佳实践与工程建议7.1 按任务复杂度分级调用模型实际项目中不要所有请求都走同一个模型。建议设计一个简单的路由策略任务分类 → 简单任务 → DeepSeek V4 Flash → 中等任务 → Gemini 1.5 Flash / 本地 Flash 模型 → 高难度任务 → GLM-4-Plus 或更强模型这样可以兼顾成本和质量。比如客服机器人中“查订单状态”“改地址”这类简单意图走 Flash 模型“处理投诉”“多轮复杂对话”走高级模型。7.2 成本测算公式在选型阶段用下面公式快速估算月成本月成本 日请求量 × 单请求平均Token数 × 30 × 单价(每Token)建议在测试阶段就记录每个请求的prompt_tokens和completion_tokens这样才能准确预估线上费用。很多团队上线后才发现账单暴涨就是因为测试阶段没有统计 Token 消耗。7.3 本地部署与 API 的取舍本地部署的优劣势优势长期成本可控、数据不出内网、可定制量化与推理参数。劣势需要硬件投入、需要维护推理服务、模型更新需要自行跟进。对于日请求量低于 10 万的早期项目直接用官方 API 更划算。当请求量稳定增长后再评估是否迁移到 DGX Spark 这类本地设备。7.4 数据安全与合规边界任何模型评测和部署都要注意数据安全生产数据脱敏后再用于评测不要直接上传真实用户信息。涉及隐私、合规的业务优先考虑本地部署。使用第三方 API 前确认服务条款是否允许你的业务场景。这块没有统一答案需要结合团队所处行业和地区规定来判断。7.5 持续评测机制模型能力、价格、限流策略都可能在三个月内变化建议把评测脚本做成定时任务每周跑一次小规模评测集 每月跑一次完整评测集 每次价格调整后立刻重跑成本对比只有持续跟踪才能在模型价格波动时快速调整选型策略。8. 总结与下一步学习方向这篇实战笔记帮你理清了三个关键点。第一大模型选型不能只看模型能力价格/Token、吞吐、TTFT 同样重要。DeepSeek V4 Flash 在价格和吞吐上的优势让它成为高频业务的有力候选。Gemini 1.5 Flash 适合多模态场景GLM-4-Plus 则更适合对质量要求高的复杂推理任务。第二一套完整的评测流程并不复杂。准备好统一 Prompt 集、统一并发脚本、统一指标记录方式就能在三天内完成三到五款模型的横向对比。文章里的脚本和部署命令可以直接改来用。第三本地部署是长期降本的有效手段但前提是业务量足够大、硬件条件合适、团队有维护推理服务的能力。如果只是早期验证不妨先用 API 跑通业务再逐步迁移。接下来你可以继续去了解这几个方向vLLM 的 Continuous Batching 原理、张量并行与流水线并行的差异、以及如何设计一套自动化的模型 Harness 评测平台。把这些内容吃透之后面对“选哪个模型”的问题你就不会再靠感觉而是能拿出数据说话。如果这篇文章对你选型或部署有帮助可以收藏备用。后续遇到新版本模型发布也建议重新跑一遍评测流程再做决定。