分享一套双 DGX Spark 环境下的多模型对比测试方法。最近社区里关于“双 DGX 测试”的讨论很热大家关心同一套本地算力跑 DeepSeek、Gemini、GLM 系列模型到底差距多大也关心 API 价格到底谁更划算。这篇文章不替某个测试结论背书而是把这类对比测试按工程方法拆开硬件和软件栈怎么规划、评测指标怎么选、成本怎么算、脚本怎么写、报错怎么排查。无论你最终测的是哪个具体版本这套流程都能直接复用。1. 背景与核心概念1.1 为什么双 DGX Spark 多模型评测这么火DGX Spark 是 NVIDIA 面向个人和工作室场景推出的桌面级 AI 设备它把过去需要一个机架才能跑的大模型推理能力压缩到了一台主机里。对于个人开发者来说这意味着可以本地跑几十 B 甚至上百 B 参数的模型不再完全依赖云 API。但单台设备能承载的模型参数量和并发总有上限于是“双 DGX”甚至多台设备组成的方案开始流行。两台机器组成一个小集群既能用张量并行承载更大的模型也能把不同模型分别部署在一台机器上做对照评测。与此同时大模型 API 的定价、限流策略、能力侧重点差异很大。同一个任务用不同模型跑延迟和输出质量可能相差数倍。这就带来一个很实际的问题到底该用哪家的 API还是该自己部署开源模型要回答这个问题就需要一套规范的评测流程。1.2 三个模型在产品形态上的区别标题里提到的模型虽然都叫“大模型”但产品形态差异很大直接决定了评测方式。DeepSeek 系列是开放权重模型既可以通过官方 API 调用也可以下载权重部署到本地。对于双 DGX Spark 这种本地算力环境DeepSeek 是典型的“可以真正跑在自己机器上”的模型。Gemini 1.5 Flash 是闭源 API 服务评测时主要走官方 API 或 SDK本地不能直接部署。GLM-4-Plus 也是闭源 API 服务来自智谱 AI适合通过 API 做对比测试。这里要特别提醒大模型版本迭代非常快标题中出现的具体版本名称比如某些博主提到的 V4 系列命名可能在你读到这篇文章时已经变化。任何测试文章里的模型 ID、接口地址、价格都要以官方文档为准。本文的重点是“评测方法”而不是某个具体版本的数据。1.3 DGX Spark 与双机并行原理在双 DGX Spark 环境下做测试先要搞清两种使用方式。第一种是“双机各跑各的”。一台机器部署模型 A另一台部署模型 B然后通过脚本分别请求两个服务得到延迟和吞吐数据。这种方式配置简单适合做 API 对比测试。第二种是“双机联合跑一个大模型”也就是把一个大模型切到两台设备的 GPU 上这就是并行策略中的张量并行Tensor Parallelism。张量并行的思路是把模型某一层的参数矩阵切分成多份分别放在不同的 GPU 上计算时通过高速通信交换中间结果。张量并行的好处是能承载单台机器放不下的模型但它的瓶颈也很明显跨机器通信延迟远高于单机内部显存访问。如果两台机器之间的网络带宽不够模型甚至会越跑越慢。所以在做多机并行之前先确认网络方案再确认推理引擎对跨节点张量并行的支持情况。2. 环境准备与版本说明2.1 硬件与网络规划双 DGX 测试的第一步不是装软件而是先把硬件拓扑画清楚。最常用的拓扑有两种拓扑类型适用场景注意事项双机独立两个模型分别部署API 对比评测网络压力小配一台交换机即可双机联合张量并行跑大模型网络带宽决定性能上限优先使用高带宽直连方案DGX Spark 的具体硬件参数、显存容量、内存带宽以 NVIDIA 官方规格书为准。网络方面如果要做双机张量并行不要用普通千兆网卡建议使用支持 RDMA 或 RoCE 的高速网络。如果条件有限至少也要保证万兆以上带宽否则通信开销会吃掉大部分算力收益。2.2 软件栈与容器方案软件栈可以按下面四层来准备操作系统建议使用 Ubuntu 22.04 LTS 或更新的 LTS 版本。NVIDIA 驱动与 CUDA安装与显卡匹配的驱动版本CUDA 版本参考推理引擎官方要求。容器运行环境DGX 设备通常自带 NVIDIA Container Toolkit建议把软件环境放进容器避免污染宿主机。推理引擎vLLM、SGLang 是常见的开源推理框架也可以直接使用官方提供的模型服务镜像。版本这里不写死因为驱动、CUDA、推理引擎之间耦合性较强。建议先查你安装的推理引擎文档确认它支持的 CUDA 和 PyTorch 版本再反推驱动版本。2.3 工作目录与项目结构为了后续评测结果可复用建议在一台机器上建立统一的工作目录~/dgx-bench/ ├── config/ │ ├── deepseek.yaml │ ├── gemini.yaml │ └── glm.yaml ├── data/ │ ├── prompts.jsonl │ └── benchmark.jsonl ├── scripts/ │ ├── run_benchmark.py │ ├── stress_test.py │ └── analyze_results.py ├── results/ │ └── 2026-01-01/ └── README.md目录含义很清楚config 存放各模型接入配置data 存放评测数据集scripts 存放测试脚本results 按日期保存结果。这样跑完一次测试所有产物都有迹可循。3. 评测思路与核心指标3.1 评测维度的确定很多人的对比测试只比“谁生成得更快”但实际业务里延迟、吞吐、稳定性和成本同样重要。建议至少记录以下五个维度指标含义测试方法首 Token 延迟从发起请求到收到第一个 Token 的时间单请求计时生成吞吐每秒生成的 Token 数统计一段时间内总生成量并发能力在多请求并发下的吞吐和错误率用压测工具逐步增加并发稳定性多轮测试的波动情况同一请求重复 N 次计算方差成本完成固定任务集的总费用按 API 计价规则换算另外还有模型效果的评估比如代码生成正确率、数学推理得分、摘要忠实度。这部分需要准备一份带参考答案的评测集用自动化脚本打分。没有评测集的对比只能算“体验”不能算“测试”。3.2 评测集与 Prompt 设计评测集的设计决定了测试结果是否有说服力。建议按下面几个方向准备中文理解新闻摘要、情感分析、观点问答。代码生成LeetCode 风格题目、SQL 编写、Bug 修复。数学推理代数题、逻辑题、应用题。长文本处理长文档摘要、关键信息抽取。每个方向准备 20 到 50 条 Prompt总样本量不用特别大但要有代表性。Prompt 不要临时在命令行里手输统一放在data/benchmark.jsonl里方便重复跑和对比。3.3 成本测算方法API 服务的计价通常按 Token 计算且输入和输出价格不同。成本测算公式如下总成本 (总输入 Token 数 / 1000000) × 输入单价 (总输出 Token 数 / 1000000) × 输出单价很多模型还会对命中缓存、长上下文提供不同价格。所以不要只看官方标价里那个最小数字要结合你的实际业务特点计算。比如一个以“长文档问答”为主的应用输入 Token 很大必须重点关注输入单价而一个以“代码生成”为主的应用输出 Token 很大就要关注输出单价。“价格屠榜”这个说法是否成立要看完真实账单才知道。正确做法是把上面这套公式写进结果分析脚本里每跑完一轮评测自动输出总成本对比。4. API 接入与本地部署方案4.1 API 接入OpenAI 兼容接口目前大部分主流模型的 API 都兼容 OpenAI 接口格式DeepSeek、GLM 以及部分 Gemini 中转服务都采用这种方式。接入时只需要准备api_key和base_url两个参数。为了不把密钥写死在代码里建议通过环境变量读取。示例export MY_API_KEYyour-api-key export MY_BASE_URLhttps://api.example.com/v1 export MY_MODELyour-model-id使用curl快速验证接口是否可用curl $MY_BASE_URL/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $MY_API_KEY \ -d { model: $MY_MODEL, messages: [{role: user, content: 你好请用一句话介绍自己。}] }如果返回choices数组里有内容说明接口通了。注意不同服务商的鉴权头可能不同有的要求Authorization有的要求自定义请求头以官方文档为准。4.2 本地部署以开源推理引擎为例本地部署的目的是在双 DGX 环境下跑开放权重模型。常见的开源推理引擎是 vLLM它支持 OpenAI 兼容的接口方便后续评测脚本复用。假设你的模型权重在本地目录启动一个服务的典型思路如下vllm serve /path/to/your-model \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192注意tensor-parallel-size默认是 1也就是单卡推理。如果做单机多卡并行可以设置为该机器的 GPU 数量。跨双机并行需要额外的分布式运行时和网络配置具体参数以 vLLM 官方文档为准。启动后可以用curl验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /path/to/your-model, messages: [{role: user, content: 测试}] }本地部署的坑在于版本兼容。如果启动时出现 CUDA 版本不匹配、显存不足、权重格式错误优先检查三个东西驱动版本、PyTorch 版本、模型权重的下载完整性。4.3 Harness 评测编排思路Harness 是当前社区比较关注的 AI 评测编排工具。它解决的核心问题是“把评测流程代码化、可复用”。你可以把数据集、模型配置、评测指标写在一个配置文件里之后每次跑测试都走同一套流程避免人为操作导致结果偏差。不同版本的 harness 配置格式有差异但整体思路通常包括三个部分数据集定义、模型定义、评测输出配置。这里给出一个通用思路# 配置文件示例具体字段以你使用的 harness 版本文档为准 dataset: file: ./data/benchmark.jsonl prompt_key: prompt model: type: openai base_url: ${MY_BASE_URL} api_key: ${MY_API_KEY} model_name: ${MY_MODEL} eval: metrics: - latency - throughput - cost output_dir: ./results使用 harness 的好处是跑完一条命令就能得到结构化输出不需要自己写复杂的调度逻辑。如果你只是做一个 50 条 Prompt 的小评测手动脚本也够用但如果要做多模型、多轮次、多指标的正式测试建议学习一下 harness 这类工具。5. 完整实战多模型对比测试脚本5.1 创建项目文件先按第 2 节的目录结构创建项目。下面我们从零开始实现一个最小可用的对比测试脚本。mkdir -p ~/dgx-bench/{config,data,scripts,results} cd ~/dgx-bench准备一个评测集文件data/prompts.jsonl每行一个 JSON{id: 1, prompt: 用 Python 实现快速排序并解释时间复杂度。} {id: 2, prompt: 把下面这段话总结成一句话人工智能正在改变软件开发的流程。} {id: 3, prompt: 一辆汽车行驶 120 公里需要 2 小时提速后速度提高 20%行驶同样距离需要多少分钟}5.2 编写批量评测脚本下面这个脚本会用requests库分别调用多个模型接口记录响应时间、输出内容和 Token 数量。# 文件路径scripts/run_benchmark.py import json import os import time import requests # 模型配置按需修改建议从环境变量读取 MODELS [ { name: deepseek, base_url: os.getenv(DEEPSEEK_BASE_URL, https://api.example.com/v1), api_key: os.getenv(DEEPSEEK_API_KEY, ), model: os.getenv(DEEPSEEK_MODEL, deepseek-model), }, { name: glm, base_url: os.getenv(GLM_BASE_URL, https://api.example.com/v1), api_key: os.getenv(GLM_API_KEY, ), model: os.getenv(GLM_MODEL, glm-model), }, ] def load_prompts(path): prompts [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: prompts.append(json.loads(line)) return prompts def call_model(model_conf, prompt): url f{model_conf[base_url]}/chat/completions headers { Content-Type: application/json, Authorization: fBearer {model_conf[api_key]}, } payload { model: model_conf[model], messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: 512, } start time.time() resp requests.post(url, headersheaders, jsonpayload, timeout120) elapsed time.time() - start resp.raise_for_status() data resp.json() output_text data[choices][0][message][content] usage data.get(usage, {}) return { output: output_text, elapsed: elapsed, input_tokens: usage.get(prompt_tokens, 0), output_tokens: usage.get(completion_tokens, 0), } def main(): prompts load_prompts(data/prompts.jsonl) results [] for model_conf in MODELS: for item in prompts: try: r call_model(model_conf, item[prompt]) results.append({ model: model_conf[name], prompt_id: item[id], elapsed: round(r[elapsed], 3), output_tokens: r[output_tokens], input_tokens: r[input_tokens], output_preview: r[output][:50], }) print(f{model_conf[name]} | prompt {item[id]} | {r[elapsed]:.2f}s) except Exception as e: results.append({ model: model_conf[name], prompt_id: item[id], error: str(e), }) print(f{model_conf[name]} | prompt {item[id]} | ERROR: {e}) with open(results/result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(done) if __name__ __main__: main()运行方式export DEEPSEEK_API_KEYyour-key export GLM_API_KEYyour-key python scripts/run_benchmark.py这个脚本是“串行”的也就是一个 Prompt 一个 Prompt 地调用。它的优点是实现简单、结果稳定适合小数据集。如果要测并发不要用这个脚本。5.3 并发压测思路串行评测只能反映单请求表现。真实业务里模型服务通常要同时扛几十个请求所以还需要并发测试。这里给出一个基于asyncio和aiohttp的并发版思路它会同时发出concurrency个请求统计整体吞吐# 文件路径scripts/stress_test.py import asyncio import aiohttp import time async def send_one(session, url, headers, payload): start time.time() async with session.post(url, headersheaders, jsonpayload, timeout120) as resp: data await resp.json() elapsed time.time() - start return elapsed, data.get(usage, {}).get(completion_tokens, 0) async def main(): url http://localhost:8000/v1/chat/completions headers {Content-Type: application/json} payload { model: your-model, messages: [{role: user, content: 请写一段冒泡排序代码}], max_tokens: 128, } concurrency 8 total_requests 64 async with aiohttp.ClientSession() as session: tasks [] for _ in range(total_requests): tasks.append(send_one(session, url, headers, payload)) start time.time() results await asyncio.gather(*tasks) total_time time.time() - start total_tokens sum(r[1] for r in results) print(f总请求数: {total_requests}) print(f总耗时: {total_time:.2f}s) print(f吞吐: {total_tokens / total_time:.2f} tokens/s) if __name__ __main__: asyncio.run(main())并发测试时要注意不要一上来就加到很高的并发数而是从 1、2、4、8、16 这样逐步增加观察错误率和吞吐的变化。如果某个并发数下开始大量超时说明已经接近服务的承载上限。5.4 结果输出与对比分析跑完评测后results/result.json里会有每一条请求的耗时和 Token 数。建议再用脚本生成汇总表格核心统计字段如下模型平均耗时(s)总输入Token总输出Token预估成本deepseek1.23428015320按官方价格填入glm1.87430114980按官方价格填入注意这里的“平均耗时”在串行评测里基本等于单请求响应时间。如果要对比并发能力还得看 5.3 节里不同并发数下的吞吐曲线。建议把测试日期、模型版本、评测集版本一并写进结果文件方便后续追溯。6. 常见问题与排查思路6.1 API 调用报错问题现象常见原因解决思路返回 401 UnauthorizedAPI Key 错误或已过期检查环境变量、重新生成 Key返回 404 Not Foundbase_url 或模型 ID 不正确对照官方接口文档核对返回 429 Too Many Requests触发了限流降低并发或申请更高配额提示所在地不可用服务有地区限制使用合规服务或改用本地部署方案返回超时单次生成过长或网络不通检查网络增大 timeout 参数Gemini 系列服务在一些地区并不开放报错文案通常是服务不可用之类。如果你的业务必须使用这类服务请先确认合规渠道否则建议选择本地部署或合规可用的 API 产品。6.2 双 DGX 并行性能问题双机做张量并行时常常出现“机器多了一倍性能反而下降”的情况。原因通常是下面之一网络带宽不足通信时间超过计算节省的时间。并行策略配置错误比如没有指定正确的分布式运行时。模型较小单机显存已经能放下强行并行反而增加开销。排查思路是先跑单机基准再跑双机并行对比同一模型在不同配置下的延迟和吞吐。如果双机并行没有收益说明这个模型并不需要跨机器并行直接退回单机部署更划算。6.3 评测结果不稳定同一 Prompt 在不同时间跑结果差异很大可能是温度设置或服务端负载导致的。解决方法是在代码中固定temperature0或很低的数值。同一请求连续跑 3 到 5 次取中位数。记录测试时间点避开服务端高峰时段。6.4 成本超预算调用 API 测试时如果不控制输出长度成本会快速累积。建议在请求体中加上max_tokens同时设置账户级配额告警。最好先在本地用小样本验证脚本再放大到完整评测集。7. 最佳实践与工程建议7.1 保证评测可复现评测最怕“这次 1.2 秒下次 2.1 秒但说不清为什么”。建立可复现体系要从三方面入手第一代码版本固定。评测脚本要纳入 Git 管理每次改动都留记录。第二评测集版本固定不要随便增删 Prompt如果调整了数据集要在结果中标注数据集版本。第三模型版本固定API 端模型经常更新需要在请求日志里记录模型 ID本地部署则记录权重文件的校验值。7.2 成本与配额控制预算管理的核心是“先小后大”。先用 10 条以内的 Prompt 验证评测全流程确认脚本、结果统计、成本计算都正常再跑到完整评测集。同时给每次评测设置成本上限可以通过统计返回参数usage里的 Token 数做实时判断。对于本地部署的模型虽然不需要按 Token 付费但硬件电费、机房散热、设备折旧也是成本。双 DGX 满负荷运行的功耗并不低长周期测试记得估算这部分开销。7.3 安全与合规注意事项调用 API 时Key 不要硬编码在代码里也不要把带密钥的配置文件传到公开仓库。可以用环境变量或者本地密钥管理工具。评测集如果包含业务敏感数据必须先在团队内部做脱敏处理。另外无论是调用第三方 API 还是本地部署模型都要遵守相应条款。涉及生产环境变更时先在测试环境跑通流程做好备份最小化权限操作。7.4 混合部署策略在真实项目中API 和本地部署并不是二选一。更常见的策略是“按场景混合”对数据敏感的场景优先本地部署开源模型。对需要最新能力或高质量输出的场景使用商业 API。对高频低难度任务用小模型降低成本。对低频高难度任务用大模型保障质量。评测的最终产出不应该只是一张对比表而是一份“在什么场景下选什么方案”的决策依据。8. 总结与下一步行动建议整套双 DGX 多模型测试流程核心是把“感觉”变成“数据”。你真正需要掌握的是硬件拓扑如何规划、评测指标如何定义、成本如何计算、脚本如何组织、报错如何排查。这些能力比某个模型的具体测试数值更保值因为模型版本会变但评测方法论可以长期复用。如果你第一次接触这类对比测试建议按这个顺序行动先准备 10 条评测 Prompt用串行脚本在 API 模式跑通全流程然后逐步扩展到完整评测集和并发压测最后再考虑双 DGX 张量并行这类高级玩法。在跑测试时记得把每一轮的模型版本、评测集版本、网络环境、并发参数都记下来。时间久了你会发现真正有价值的不是某次测试的输赢而是你手里这套可以随时复现、随时追溯的评测体系。希望这篇文章能帮你少走一些弯路尽快跑出自己那份可信的对比数据。
分享一套双 DGX Spark 环境下的多模型对比测试方法。最近社区里关于“双 DGX 测试”的讨论很热大家关心同一套本地算力跑 DeepSeek、Gemini、GLM 系列模型到底差距多大也关心 API 价格到底谁更划算。这篇文章不替某个测试结论背书而是把这类对比测试按工程方法拆开硬件和软件栈怎么规划、评测指标怎么选、成本怎么算、脚本怎么写、报错怎么排查。无论你最终测的是哪个具体版本这套流程都能直接复用。1. 背景与核心概念1.1 为什么双 DGX Spark 多模型评测这么火DGX Spark 是 NVIDIA 面向个人和工作室场景推出的桌面级 AI 设备它把过去需要一个机架才能跑的大模型推理能力压缩到了一台主机里。对于个人开发者来说这意味着可以本地跑几十 B 甚至上百 B 参数的模型不再完全依赖云 API。但单台设备能承载的模型参数量和并发总有上限于是“双 DGX”甚至多台设备组成的方案开始流行。两台机器组成一个小集群既能用张量并行承载更大的模型也能把不同模型分别部署在一台机器上做对照评测。与此同时大模型 API 的定价、限流策略、能力侧重点差异很大。同一个任务用不同模型跑延迟和输出质量可能相差数倍。这就带来一个很实际的问题到底该用哪家的 API还是该自己部署开源模型要回答这个问题就需要一套规范的评测流程。1.2 三个模型在产品形态上的区别标题里提到的模型虽然都叫“大模型”但产品形态差异很大直接决定了评测方式。DeepSeek 系列是开放权重模型既可以通过官方 API 调用也可以下载权重部署到本地。对于双 DGX Spark 这种本地算力环境DeepSeek 是典型的“可以真正跑在自己机器上”的模型。Gemini 1.5 Flash 是闭源 API 服务评测时主要走官方 API 或 SDK本地不能直接部署。GLM-4-Plus 也是闭源 API 服务来自智谱 AI适合通过 API 做对比测试。这里要特别提醒大模型版本迭代非常快标题中出现的具体版本名称比如某些博主提到的 V4 系列命名可能在你读到这篇文章时已经变化。任何测试文章里的模型 ID、接口地址、价格都要以官方文档为准。本文的重点是“评测方法”而不是某个具体版本的数据。1.3 DGX Spark 与双机并行原理在双 DGX Spark 环境下做测试先要搞清两种使用方式。第一种是“双机各跑各的”。一台机器部署模型 A另一台部署模型 B然后通过脚本分别请求两个服务得到延迟和吞吐数据。这种方式配置简单适合做 API 对比测试。第二种是“双机联合跑一个大模型”也就是把一个大模型切到两台设备的 GPU 上这就是并行策略中的张量并行Tensor Parallelism。张量并行的思路是把模型某一层的参数矩阵切分成多份分别放在不同的 GPU 上计算时通过高速通信交换中间结果。张量并行的好处是能承载单台机器放不下的模型但它的瓶颈也很明显跨机器通信延迟远高于单机内部显存访问。如果两台机器之间的网络带宽不够模型甚至会越跑越慢。所以在做多机并行之前先确认网络方案再确认推理引擎对跨节点张量并行的支持情况。2. 环境准备与版本说明2.1 硬件与网络规划双 DGX 测试的第一步不是装软件而是先把硬件拓扑画清楚。最常用的拓扑有两种拓扑类型适用场景注意事项双机独立两个模型分别部署API 对比评测网络压力小配一台交换机即可双机联合张量并行跑大模型网络带宽决定性能上限优先使用高带宽直连方案DGX Spark 的具体硬件参数、显存容量、内存带宽以 NVIDIA 官方规格书为准。网络方面如果要做双机张量并行不要用普通千兆网卡建议使用支持 RDMA 或 RoCE 的高速网络。如果条件有限至少也要保证万兆以上带宽否则通信开销会吃掉大部分算力收益。2.2 软件栈与容器方案软件栈可以按下面四层来准备操作系统建议使用 Ubuntu 22.04 LTS 或更新的 LTS 版本。NVIDIA 驱动与 CUDA安装与显卡匹配的驱动版本CUDA 版本参考推理引擎官方要求。容器运行环境DGX 设备通常自带 NVIDIA Container Toolkit建议把软件环境放进容器避免污染宿主机。推理引擎vLLM、SGLang 是常见的开源推理框架也可以直接使用官方提供的模型服务镜像。版本这里不写死因为驱动、CUDA、推理引擎之间耦合性较强。建议先查你安装的推理引擎文档确认它支持的 CUDA 和 PyTorch 版本再反推驱动版本。2.3 工作目录与项目结构为了后续评测结果可复用建议在一台机器上建立统一的工作目录~/dgx-bench/ ├── config/ │ ├── deepseek.yaml │ ├── gemini.yaml │ └── glm.yaml ├── data/ │ ├── prompts.jsonl │ └── benchmark.jsonl ├── scripts/ │ ├── run_benchmark.py │ ├── stress_test.py │ └── analyze_results.py ├── results/ │ └── 2026-01-01/ └── README.md目录含义很清楚config 存放各模型接入配置data 存放评测数据集scripts 存放测试脚本results 按日期保存结果。这样跑完一次测试所有产物都有迹可循。3. 评测思路与核心指标3.1 评测维度的确定很多人的对比测试只比“谁生成得更快”但实际业务里延迟、吞吐、稳定性和成本同样重要。建议至少记录以下五个维度指标含义测试方法首 Token 延迟从发起请求到收到第一个 Token 的时间单请求计时生成吞吐每秒生成的 Token 数统计一段时间内总生成量并发能力在多请求并发下的吞吐和错误率用压测工具逐步增加并发稳定性多轮测试的波动情况同一请求重复 N 次计算方差成本完成固定任务集的总费用按 API 计价规则换算另外还有模型效果的评估比如代码生成正确率、数学推理得分、摘要忠实度。这部分需要准备一份带参考答案的评测集用自动化脚本打分。没有评测集的对比只能算“体验”不能算“测试”。3.2 评测集与 Prompt 设计评测集的设计决定了测试结果是否有说服力。建议按下面几个方向准备中文理解新闻摘要、情感分析、观点问答。代码生成LeetCode 风格题目、SQL 编写、Bug 修复。数学推理代数题、逻辑题、应用题。长文本处理长文档摘要、关键信息抽取。每个方向准备 20 到 50 条 Prompt总样本量不用特别大但要有代表性。Prompt 不要临时在命令行里手输统一放在data/benchmark.jsonl里方便重复跑和对比。3.3 成本测算方法API 服务的计价通常按 Token 计算且输入和输出价格不同。成本测算公式如下总成本 (总输入 Token 数 / 1000000) × 输入单价 (总输出 Token 数 / 1000000) × 输出单价很多模型还会对命中缓存、长上下文提供不同价格。所以不要只看官方标价里那个最小数字要结合你的实际业务特点计算。比如一个以“长文档问答”为主的应用输入 Token 很大必须重点关注输入单价而一个以“代码生成”为主的应用输出 Token 很大就要关注输出单价。“价格屠榜”这个说法是否成立要看完真实账单才知道。正确做法是把上面这套公式写进结果分析脚本里每跑完一轮评测自动输出总成本对比。4. API 接入与本地部署方案4.1 API 接入OpenAI 兼容接口目前大部分主流模型的 API 都兼容 OpenAI 接口格式DeepSeek、GLM 以及部分 Gemini 中转服务都采用这种方式。接入时只需要准备api_key和base_url两个参数。为了不把密钥写死在代码里建议通过环境变量读取。示例export MY_API_KEYyour-api-key export MY_BASE_URLhttps://api.example.com/v1 export MY_MODELyour-model-id使用curl快速验证接口是否可用curl $MY_BASE_URL/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $MY_API_KEY \ -d { model: $MY_MODEL, messages: [{role: user, content: 你好请用一句话介绍自己。}] }如果返回choices数组里有内容说明接口通了。注意不同服务商的鉴权头可能不同有的要求Authorization有的要求自定义请求头以官方文档为准。4.2 本地部署以开源推理引擎为例本地部署的目的是在双 DGX 环境下跑开放权重模型。常见的开源推理引擎是 vLLM它支持 OpenAI 兼容的接口方便后续评测脚本复用。假设你的模型权重在本地目录启动一个服务的典型思路如下vllm serve /path/to/your-model \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192注意tensor-parallel-size默认是 1也就是单卡推理。如果做单机多卡并行可以设置为该机器的 GPU 数量。跨双机并行需要额外的分布式运行时和网络配置具体参数以 vLLM 官方文档为准。启动后可以用curl验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /path/to/your-model, messages: [{role: user, content: 测试}] }本地部署的坑在于版本兼容。如果启动时出现 CUDA 版本不匹配、显存不足、权重格式错误优先检查三个东西驱动版本、PyTorch 版本、模型权重的下载完整性。4.3 Harness 评测编排思路Harness 是当前社区比较关注的 AI 评测编排工具。它解决的核心问题是“把评测流程代码化、可复用”。你可以把数据集、模型配置、评测指标写在一个配置文件里之后每次跑测试都走同一套流程避免人为操作导致结果偏差。不同版本的 harness 配置格式有差异但整体思路通常包括三个部分数据集定义、模型定义、评测输出配置。这里给出一个通用思路# 配置文件示例具体字段以你使用的 harness 版本文档为准 dataset: file: ./data/benchmark.jsonl prompt_key: prompt model: type: openai base_url: ${MY_BASE_URL} api_key: ${MY_API_KEY} model_name: ${MY_MODEL} eval: metrics: - latency - throughput - cost output_dir: ./results使用 harness 的好处是跑完一条命令就能得到结构化输出不需要自己写复杂的调度逻辑。如果你只是做一个 50 条 Prompt 的小评测手动脚本也够用但如果要做多模型、多轮次、多指标的正式测试建议学习一下 harness 这类工具。5. 完整实战多模型对比测试脚本5.1 创建项目文件先按第 2 节的目录结构创建项目。下面我们从零开始实现一个最小可用的对比测试脚本。mkdir -p ~/dgx-bench/{config,data,scripts,results} cd ~/dgx-bench准备一个评测集文件data/prompts.jsonl每行一个 JSON{id: 1, prompt: 用 Python 实现快速排序并解释时间复杂度。} {id: 2, prompt: 把下面这段话总结成一句话人工智能正在改变软件开发的流程。} {id: 3, prompt: 一辆汽车行驶 120 公里需要 2 小时提速后速度提高 20%行驶同样距离需要多少分钟}5.2 编写批量评测脚本下面这个脚本会用requests库分别调用多个模型接口记录响应时间、输出内容和 Token 数量。# 文件路径scripts/run_benchmark.py import json import os import time import requests # 模型配置按需修改建议从环境变量读取 MODELS [ { name: deepseek, base_url: os.getenv(DEEPSEEK_BASE_URL, https://api.example.com/v1), api_key: os.getenv(DEEPSEEK_API_KEY, ), model: os.getenv(DEEPSEEK_MODEL, deepseek-model), }, { name: glm, base_url: os.getenv(GLM_BASE_URL, https://api.example.com/v1), api_key: os.getenv(GLM_API_KEY, ), model: os.getenv(GLM_MODEL, glm-model), }, ] def load_prompts(path): prompts [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: prompts.append(json.loads(line)) return prompts def call_model(model_conf, prompt): url f{model_conf[base_url]}/chat/completions headers { Content-Type: application/json, Authorization: fBearer {model_conf[api_key]}, } payload { model: model_conf[model], messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: 512, } start time.time() resp requests.post(url, headersheaders, jsonpayload, timeout120) elapsed time.time() - start resp.raise_for_status() data resp.json() output_text data[choices][0][message][content] usage data.get(usage, {}) return { output: output_text, elapsed: elapsed, input_tokens: usage.get(prompt_tokens, 0), output_tokens: usage.get(completion_tokens, 0), } def main(): prompts load_prompts(data/prompts.jsonl) results [] for model_conf in MODELS: for item in prompts: try: r call_model(model_conf, item[prompt]) results.append({ model: model_conf[name], prompt_id: item[id], elapsed: round(r[elapsed], 3), output_tokens: r[output_tokens], input_tokens: r[input_tokens], output_preview: r[output][:50], }) print(f{model_conf[name]} | prompt {item[id]} | {r[elapsed]:.2f}s) except Exception as e: results.append({ model: model_conf[name], prompt_id: item[id], error: str(e), }) print(f{model_conf[name]} | prompt {item[id]} | ERROR: {e}) with open(results/result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(done) if __name__ __main__: main()运行方式export DEEPSEEK_API_KEYyour-key export GLM_API_KEYyour-key python scripts/run_benchmark.py这个脚本是“串行”的也就是一个 Prompt 一个 Prompt 地调用。它的优点是实现简单、结果稳定适合小数据集。如果要测并发不要用这个脚本。5.3 并发压测思路串行评测只能反映单请求表现。真实业务里模型服务通常要同时扛几十个请求所以还需要并发测试。这里给出一个基于asyncio和aiohttp的并发版思路它会同时发出concurrency个请求统计整体吞吐# 文件路径scripts/stress_test.py import asyncio import aiohttp import time async def send_one(session, url, headers, payload): start time.time() async with session.post(url, headersheaders, jsonpayload, timeout120) as resp: data await resp.json() elapsed time.time() - start return elapsed, data.get(usage, {}).get(completion_tokens, 0) async def main(): url http://localhost:8000/v1/chat/completions headers {Content-Type: application/json} payload { model: your-model, messages: [{role: user, content: 请写一段冒泡排序代码}], max_tokens: 128, } concurrency 8 total_requests 64 async with aiohttp.ClientSession() as session: tasks [] for _ in range(total_requests): tasks.append(send_one(session, url, headers, payload)) start time.time() results await asyncio.gather(*tasks) total_time time.time() - start total_tokens sum(r[1] for r in results) print(f总请求数: {total_requests}) print(f总耗时: {total_time:.2f}s) print(f吞吐: {total_tokens / total_time:.2f} tokens/s) if __name__ __main__: asyncio.run(main())并发测试时要注意不要一上来就加到很高的并发数而是从 1、2、4、8、16 这样逐步增加观察错误率和吞吐的变化。如果某个并发数下开始大量超时说明已经接近服务的承载上限。5.4 结果输出与对比分析跑完评测后results/result.json里会有每一条请求的耗时和 Token 数。建议再用脚本生成汇总表格核心统计字段如下模型平均耗时(s)总输入Token总输出Token预估成本deepseek1.23428015320按官方价格填入glm1.87430114980按官方价格填入注意这里的“平均耗时”在串行评测里基本等于单请求响应时间。如果要对比并发能力还得看 5.3 节里不同并发数下的吞吐曲线。建议把测试日期、模型版本、评测集版本一并写进结果文件方便后续追溯。6. 常见问题与排查思路6.1 API 调用报错问题现象常见原因解决思路返回 401 UnauthorizedAPI Key 错误或已过期检查环境变量、重新生成 Key返回 404 Not Foundbase_url 或模型 ID 不正确对照官方接口文档核对返回 429 Too Many Requests触发了限流降低并发或申请更高配额提示所在地不可用服务有地区限制使用合规服务或改用本地部署方案返回超时单次生成过长或网络不通检查网络增大 timeout 参数Gemini 系列服务在一些地区并不开放报错文案通常是服务不可用之类。如果你的业务必须使用这类服务请先确认合规渠道否则建议选择本地部署或合规可用的 API 产品。6.2 双 DGX 并行性能问题双机做张量并行时常常出现“机器多了一倍性能反而下降”的情况。原因通常是下面之一网络带宽不足通信时间超过计算节省的时间。并行策略配置错误比如没有指定正确的分布式运行时。模型较小单机显存已经能放下强行并行反而增加开销。排查思路是先跑单机基准再跑双机并行对比同一模型在不同配置下的延迟和吞吐。如果双机并行没有收益说明这个模型并不需要跨机器并行直接退回单机部署更划算。6.3 评测结果不稳定同一 Prompt 在不同时间跑结果差异很大可能是温度设置或服务端负载导致的。解决方法是在代码中固定temperature0或很低的数值。同一请求连续跑 3 到 5 次取中位数。记录测试时间点避开服务端高峰时段。6.4 成本超预算调用 API 测试时如果不控制输出长度成本会快速累积。建议在请求体中加上max_tokens同时设置账户级配额告警。最好先在本地用小样本验证脚本再放大到完整评测集。7. 最佳实践与工程建议7.1 保证评测可复现评测最怕“这次 1.2 秒下次 2.1 秒但说不清为什么”。建立可复现体系要从三方面入手第一代码版本固定。评测脚本要纳入 Git 管理每次改动都留记录。第二评测集版本固定不要随便增删 Prompt如果调整了数据集要在结果中标注数据集版本。第三模型版本固定API 端模型经常更新需要在请求日志里记录模型 ID本地部署则记录权重文件的校验值。7.2 成本与配额控制预算管理的核心是“先小后大”。先用 10 条以内的 Prompt 验证评测全流程确认脚本、结果统计、成本计算都正常再跑到完整评测集。同时给每次评测设置成本上限可以通过统计返回参数usage里的 Token 数做实时判断。对于本地部署的模型虽然不需要按 Token 付费但硬件电费、机房散热、设备折旧也是成本。双 DGX 满负荷运行的功耗并不低长周期测试记得估算这部分开销。7.3 安全与合规注意事项调用 API 时Key 不要硬编码在代码里也不要把带密钥的配置文件传到公开仓库。可以用环境变量或者本地密钥管理工具。评测集如果包含业务敏感数据必须先在团队内部做脱敏处理。另外无论是调用第三方 API 还是本地部署模型都要遵守相应条款。涉及生产环境变更时先在测试环境跑通流程做好备份最小化权限操作。7.4 混合部署策略在真实项目中API 和本地部署并不是二选一。更常见的策略是“按场景混合”对数据敏感的场景优先本地部署开源模型。对需要最新能力或高质量输出的场景使用商业 API。对高频低难度任务用小模型降低成本。对低频高难度任务用大模型保障质量。评测的最终产出不应该只是一张对比表而是一份“在什么场景下选什么方案”的决策依据。8. 总结与下一步行动建议整套双 DGX 多模型测试流程核心是把“感觉”变成“数据”。你真正需要掌握的是硬件拓扑如何规划、评测指标如何定义、成本如何计算、脚本如何组织、报错如何排查。这些能力比某个模型的具体测试数值更保值因为模型版本会变但评测方法论可以长期复用。如果你第一次接触这类对比测试建议按这个顺序行动先准备 10 条评测 Prompt用串行脚本在 API 模式跑通全流程然后逐步扩展到完整评测集和并发压测最后再考虑双 DGX 张量并行这类高级玩法。在跑测试时记得把每一轮的模型版本、评测集版本、网络环境、并发参数都记下来。时间久了你会发现真正有价值的不是某次测试的输赢而是你手里这套可以随时复现、随时追溯的评测体系。希望这篇文章能帮你少走一些弯路尽快跑出自己那份可信的对比数据。
