尧图网站建设 
当一款新的大模型发布时最先冒出来的往往是各种抽象的评价更强了更聪明了性价比更高了。但作为开发者我们不能只凭宣传词做技术选型。以 Qwen3.8 Max 这类模型为例真正需要回答的问题是它在数学推理、代码生成、中文理解上的实际水平如何接口延迟和并发能力能不能支撑真实业务按 token 计费后跑一个完整场景到底要花多少钱本文不打算替你下结论而是给出一个可以复现、可以本地运行的大模型三维评估框架智力Intelligence、性能Performance、价格Price。无论你评估的是 Qwen3.8 Max还是其他兼容 OpenAI 接口的模型都可以把下面的脚本和思路直接拿过去用。适合读者需要做大模型选型的技术负责人、正在接大模型 API 的后端开发、以及想系统了解大模型评测方法的算法工程师。读完本文你会得到一套完整的评估脚本、一套成本计算模型以及一份可以直接改造成团队内部工具的调研报告模板。1. 为什么需要系统评估大模型1.1 宣传文案与真实体验之间的差距模型的官方介绍通常会给出大量亮点描述比如复杂推理能力提升代码生成质量领先。这些描述在特定测试集上可能是成立的但到了你的业务场景中效果可能完全不同。原因主要有三点。第一评测数据与业务数据分布不一致。官方测试往往覆盖通用知识、数学、代码等大类而你的业务可能是法律文书、医疗问答、电商评论这些垂直领域的表现需要单独验证。一个在通用基准上得分很高的模型在特定行业术语、特定格式要求下未必能稳定输出合格结果。第二同样的模型在不同调用方式下表现不同。temperature、max_tokens、system prompt、是否流式返回都会影响最终的响应质量和延迟。模型是一个参数空间里的概率系统而不是一个静态程序。同样的输入参数不同输出差异可能非常大。第三性能指标具有很强的环境相关性。同样的模型在低并发下可能响应很快高并发下可能显著劣化。单次调用体验好不代表能扛住业务峰值。如果服务商在高峰期对 API 做了限流你的服务可能大面积超时而这种问题在小规模测试时几乎不会暴露。1.2 评估的常见误区在做大模型评估时开发者容易陷入几个误区。一是只用一两个例子下结论。拿一个问题问一遍回答得好就说模型很强回答得差就说模型不行。这种判断没有统计意义因为大模型生成结果带有随机性任何单次回答都不能代表真实水平。二是只看基准测试分数。MMLU、C-Eval、GSM8K 等基准确实重要但它们和真实业务的 gap 往往很大。基准题目有标准答案、有固定格式业务问题则可能高度开放、依赖上下文、需要多轮对话。基准分数可以作为初筛但不能作为最终选型的唯一依据。三是只算单价不算总成本。很多人在模型选型时只对比每百万 token 多少钱这是远远不够的。不同模型处理同一任务的 token 效率不同有的模型输出冗长有的简洁。价格分析必须结合真实任务的实际 token 消耗。1.3 三个维度缺一不可本文关注的核心是三个维度智力Intelligence模型理解、推理、生成内容质量的能力。性能Performance模型服务的响应速度、吞吐量、稳定性。价格Price调用成本包括输入 token、输出 token 的费用以及自部署时的算力成本。只有把三个维度放在一起看才能回答这个模型适不适合我的场景。举个例子一个模型智商再高如果单次响应要 30 秒也没办法做实时客服一个模型再便宜如果逻辑错误率 30%人工修复成本就会抵消掉差价。评估的最终目标是找到某一类业务场景下的最优平衡点。2. 评估前需要准备什么2.1 运行环境本文示例使用 Python 3代码量不大只需要安装两个依赖pip install openai pip install requests如果你的模型服务商提供了专属 SDK也可以替换为对应的包但原理是一样的。为了统一本文所有示例都采用 OpenAI 兼容的接口格式这也是目前绝大多数大模型服务商的通用做法。这样做的另一个好处是以后切换模型服务商时评估脚本基本不需要修改只需要更换 API Key、接入地址和模型名称。2.2 获取 API Key 与接入地址评估一个模型之前你需要确认以下信息API Key调用模型服务的凭证需要向模型服务商申请。请妥善保管不要提交到 Git 仓库也不要写死在代码里。接入地址Base URL例如https://your-endpoint.example.com/v1。具体地址以服务商文档为准。模型名称Model Name例如qwen3.8-max。不同服务商对模型名称的命名可能存在差异务必以官方文档为准。这里需要提醒的是大模型 API 属于计费服务评估过程会产生费用。建议先做小规模测试确认功能正常再逐步扩大测试规模。涉及生产环境前务必确认你已经获得合法授权并且对费用有预估。如果评估结束后发现费用异常第一时间检查是否有请求陷入了重试死循环。2.3 项目结构建议先建一个干净的目录把所有评估脚本集中管理llm-eval/ ├── eval_intelligence.py # 智力评估脚本 ├── benchmark_performance.py # 性能压测脚本 ├── estimate_cost.py # 成本测算脚本 ├── config.py # 统一配置 ├── report/ # 评估报告输出目录 ├── results/ # 原始结果目录 └── README.md # 记录评估日期、版本、结论把配置、脚本、结果分开管理可以保证评估过程可追溯。README 里建议记录每次评估的时间、模型版本、测试参数和主要结论方便后续对比。2.4 统一配置示例创建一个config.py把模型名称、接入地址、API Key 集中管理# 文件路径config.py import os MODEL_NAME os.getenv(MODEL_NAME, qwen3.8-max) API_KEY os.getenv(API_KEY, ) BASE_URL os.getenv(BASE_URL, https://your-endpoint.example.com/v1) DEFAULT_TEMPERATURE 0.3 DEFAULT_MAX_TOKENS 1024 TIMEOUT_SECONDS 60通过环境变量读取 API Key 而不是硬编码是为了避免密钥泄露。在实际项目中更推荐使用密钥管理服务如云厂商的 KMS 或 Vault让密钥只存在于运行时环境中。评估脚本只是工具安全习惯要从一开始就建立。3. 智力维度如何量化聪明3.1 智力评估的常见方法智力是三个维度中最难量化的。目前业界通常分三层。第一层是通用基准评测。例如 MMLU多任务语言理解、C-Eval中文评估基准、GSM8K数学应用题、HumanEval代码生成等。这些基准的好处是有标准答案可以横向对比缺点是题目偏学术和真实业务差距较大。如果你关注中文场景C-Eval 这类中文基准的参考价值会更高一些。第二层是人工对抗式测试。由领域专家设计一批贴近业务的题目逐个询问模型再人工打分。这种方式更贴近真实使用但成本高、不可复现且打分标准容易受主观因素影响。第三层是自动化的业务样例回归。把日常业务中积累的问答对整理成测试集每次模型升级后跑一遍看正确率是否有回退。这也是我们最推荐团队长期维护的方式。它不需要每次请专家只需要在最初设计题目时投入精力后续价值会越来越大。3.2 设计一份小型评估题目集在还没有业务数据的情况下可以先设计一份覆盖常见能力点的题目集包括数学推理、代码生成、逻辑推理、中文理解、长文本归纳等。每个题目要带上参考标准方便后续人工或自动打分。下面是一个可以直接运行的智力评估脚本# 文件路径eval_intelligence.py import time import json from openai import OpenAI from config import API_KEY, BASE_URL, MODEL_NAME, DEFAULT_TEMPERATURE, DEFAULT_MAX_TOKENS client OpenAI(api_keyAPI_KEY, base_urlBASE_URL) test_cases [ { category: 数学推理, prompt: 一个水池有一个进水管和一个出水管。进水管单独注满水池需要 6 小时出水管单独放空水池需要 9 小时。如果两个水管同时打开多长时间可以注满水池, reference: 18小时, scoring: 参考答案是否一致且推导过程完整 }, { category: 代码生成, prompt: 请用 Python 写一个函数输入一个整数列表返回其中出现次数最多的元素。如果有多个返回任意一个。, reference: 函数可以运行并且能返回正确众数, scoring: 代码可执行、边界处理正确、有基本注释 }, { category: 逻辑推理, prompt: 有三个盒子一个盒子只装苹果一个盒子只装橘子一个盒子装苹果和橘子。三个盒子上分别贴着苹果、橘子、苹果和橘子的标签但所有标签都贴错了。你只能从一个盒子中取一个水果。应该从哪个盒子取水果才能确定每个盒子里装的是什么, reference: 从贴苹果和橘子的盒子里取, scoring: 结论正确并解释所有标签都贴错这一关键条件 }, { category: 中文理解, prompt: 请解释成语杯水车薪的含义并用它造一个句子。, reference: 解释准确句子通顺自然, scoring: 语义准确无事实错误例句自然 }, { category: 长文本归纳, prompt: 以下是一段用户反馈的摘要请用 3 句话概括核心问题我们平台上周新增了拼团功能但用户普遍反映支付成功后订单状态不更新客服工单数量比上周增加了 300%主要集中在安卓端。开发排查发现是回调接口超时导致但产品经理认为需要先上线一个前端提示来缓解用户焦虑。, reference: 核心问题为支付回调超时导致订单状态不同步, scoring: 能抓住回调超时订单状态不更新安卓端集中三个关键信息 } ] def ask_model(prompt: str) - str: resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperatureDEFAULT_TEMPERATURE, max_tokensDEFAULT_MAX_TOKENS ) return resp.choices[0].message.content def main(): results [] for case in test_cases: start time.time() answer ask_model(case[prompt]) elapsed round(time.time() - start, 2) results.append({ category: case[category], prompt: case[prompt], answer: answer, reference: case[reference], scoring: case[scoring], elapsed_seconds: elapsed }) print(f[{case[category]}] 耗时 {elapsed}s) print(回答, answer[:200]) print(参考, case[reference]) print( * 60) with open(results/intelligence_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(结果已保存到 results/intelligence_results.json) if __name__ __main__: main()运行python eval_intelligence.py3.3 如何解读智力测试结果跑完脚本后你会得到一份 JSON 结果。接下来要做的是对照 reference 给每题打分。建议分为三档优秀结论正确推理完整几乎不需要修改。合格结论正确但缺少关键解释或格式不符合要求。不合格结论错误或存在明显的事实性错误。需要特别注意的是单次回答具有随机性。同一个问题即使 temperature 设为 0多次回答也可能不同。所以正式评估时建议每个问题重复 3 到 5 次统计正确率而不是只看一次结果。如果你的目标是长期跟踪模型质量建议把这份题目集沉淀为团队的评估资产。后续模型升级、换服务商、改 prompt 时都先跑一遍回归避免感觉变好了实际变差了的错觉。这是own your intelligence理念的具体落地不要被动接受厂商的结论而是建立属于自己的评测数据集和评分标准。3.4 业务测试集的设计思路通用题目集只能做初筛真正决定选型的一定是业务测试集。设计业务测试集时有几个建议。一是从真实日志里提取。翻出过去三个月用户最常见的提问、客服最常处理的工单整理成 50 到 100 条题目。这些题目才是你业务的核心。二是按难度分层。不要全是简单问题也要包含需要多步推理、需要结合上下文、需要输出结构化 JSON 的复杂场景。否则评估结果会虚高。三是提前定好评分标准。每条题目都要明确什么算对最好能写出简短参考答案。这样可以保证多人打分时标准一致也方便将来自动化评估。4. 性能维度从能答到答得快4.1 性能指标不只有快很多同学评估模型性能时只盯着响应时间这在真实项目中是不够的。要完整描述一个大模型服务的性能至少需要关注四个指标首 token 延迟TTFTTime To First Token发起请求到返回第一个 token 的时间。这个指标决定了用户感知到的响应速度。生成吞吐Tokens per Second每秒生成的 token 数量决定了整体等待时间。并发能力在多个请求同时发起时延迟是否还能保持稳定。稳定性长时间压测时是否出现超时、限流、错误率上升。打个比方前端开发者会用浏览器的 Performance 面板分析页面渲染耗时移动端开发者会用 Android Performance AnalyzerAPA这类工具定位应用卡顿。同样道理大模型服务也需要一套标准化的观测手段。只看一次请求的耗时很难说明问题。性能分析本质上是一套指标采集 数据对比 瓶颈定位的方法论无论在哪个技术栈都适用。4.2 性能压测脚本下面这个脚本分别用并发数 1、5、10 各打 10 个请求统计平均延迟、P95 延迟和生成速度# 文件路径benchmark_performance.py import time import statistics from concurrent.futures import ThreadPoolExecutor from openai import OpenAI from config import API_KEY, BASE_URL, MODEL_NAME, TIMEOUT_SECONDS client OpenAI(api_keyAPI_KEY, base_urlBASE_URL, timeoutTIMEOUT_SECONDS) TEST_PROMPT 请用 200 字左右介绍大语言模型的工作原理。 def single_request(): start time.time() resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: TEST_PROMPT}], max_tokens512, streamFalse ) end time.time() total_latency end - start usage resp.usage output_tokens usage.completion_tokens if usage else 0 input_tokens usage.prompt_tokens if usage else 0 throughput output_tokens / total_latency if total_latency 0 else 0 return { latency: total_latency, output_tokens: output_tokens, input_tokens: input_tokens, throughput: throughput, success: True } def run_batch(concurrency: int, total_requests: int): results [] with ThreadPoolExecutor(max_workersconcurrency) as executor: futures [executor.submit(single_request) for _ in range(total_requests)] for future in futures: try: results.append(future.result()) except Exception as exc: results.append({ latency: float(inf), output_tokens: 0, throughput: 0, success: False, error: str(exc) }) return results def summarize(results, concurrency): success [r for r in results if r.get(success)] failed [r for r in results if not r.get(success)] print(f并发数: {concurrency}, 请求数: {len(results)}, 成功: {len(success)}, 失败: {len(failed)}) if not success: print(全部请求失败请检查网络、鉴权和限流配置) return latencies [r[latency] for r in success] throughputs [r[throughput] for r in success if r[throughput] 0] print(f平均延迟: {statistics.mean(latencies):.2f}s) print(fP95 延迟: {sorted(latencies)[int(len(latencies) * 0.95) - 1]:.2f}s) if throughputs: print(f平均生成速度: {statistics.mean(throughputs):.2f} tokens/s) if __name__ __main__: for concurrency in [1, 5, 10]: results run_batch(concurrency, 10) summarize(results, concurrency) print(- * 60)运行python benchmark_performance.py4.3 结果怎么分析假设你拿到一组数据并发 1 时平均延迟 1.8 秒并发 10 时平均延迟 5.2 秒同时出现少量超时。这说明服务在低并发下表现不错但并发能力可能不够需要在架构上做排队削峰或者换成更高规格的服务。如果并发 1 时延迟就很高比如 10 秒以上先不要急着下结论。检查一下是不是请求内容过长、max_tokens 设置过大或者当前网络到服务端点的链路存在问题。另外生成类任务本身耗时与输出长度强相关比较延迟时要保证 max_tokens 和 prompt 长度一致否则数据没有可比性。如果测试结果出现大量 429 或超时说明触发了服务商限流。这种情况需要参考服务商文档中的 QPS每秒请求数和 TPM每分钟 token 数限制重新设计压测参数。建议在压测脚本中加入指数退避重试逻辑避免失败请求瞬间堆积放大压力。4.4 流式接口对性能体验的影响上面的压测用的是非流式接口也就是等全部内容生成完再一次性返回。真实业务中更推荐使用流式接口streamTrue让用户先看到第一个 token 出现明显改善等待体验。流式接口对性能观测 大模型三维评估框架：智力、性能与成本实战指南
当一款新的大模型发布时最先冒出来的往往是各种抽象的评价更强了更聪明了性价比更高了。但作为开发者我们不能只凭宣传词做技术选型。以 Qwen3.8 Max 这类模型为例真正需要回答的问题是它在数学推理、代码生成、中文理解上的实际水平如何接口延迟和并发能力能不能支撑真实业务按 token 计费后跑一个完整场景到底要花多少钱本文不打算替你下结论而是给出一个可以复现、可以本地运行的大模型三维评估框架智力Intelligence、性能Performance、价格Price。无论你评估的是 Qwen3.8 Max还是其他兼容 OpenAI 接口的模型都可以把下面的脚本和思路直接拿过去用。适合读者需要做大模型选型的技术负责人、正在接大模型 API 的后端开发、以及想系统了解大模型评测方法的算法工程师。读完本文你会得到一套完整的评估脚本、一套成本计算模型以及一份可以直接改造成团队内部工具的调研报告模板。1. 为什么需要系统评估大模型1.1 宣传文案与真实体验之间的差距模型的官方介绍通常会给出大量亮点描述比如复杂推理能力提升代码生成质量领先。这些描述在特定测试集上可能是成立的但到了你的业务场景中效果可能完全不同。原因主要有三点。第一评测数据与业务数据分布不一致。官方测试往往覆盖通用知识、数学、代码等大类而你的业务可能是法律文书、医疗问答、电商评论这些垂直领域的表现需要单独验证。一个在通用基准上得分很高的模型在特定行业术语、特定格式要求下未必能稳定输出合格结果。第二同样的模型在不同调用方式下表现不同。temperature、max_tokens、system prompt、是否流式返回都会影响最终的响应质量和延迟。模型是一个参数空间里的概率系统而不是一个静态程序。同样的输入参数不同输出差异可能非常大。第三性能指标具有很强的环境相关性。同样的模型在低并发下可能响应很快高并发下可能显著劣化。单次调用体验好不代表能扛住业务峰值。如果服务商在高峰期对 API 做了限流你的服务可能大面积超时而这种问题在小规模测试时几乎不会暴露。1.2 评估的常见误区在做大模型评估时开发者容易陷入几个误区。一是只用一两个例子下结论。拿一个问题问一遍回答得好就说模型很强回答得差就说模型不行。这种判断没有统计意义因为大模型生成结果带有随机性任何单次回答都不能代表真实水平。二是只看基准测试分数。MMLU、C-Eval、GSM8K 等基准确实重要但它们和真实业务的 gap 往往很大。基准题目有标准答案、有固定格式业务问题则可能高度开放、依赖上下文、需要多轮对话。基准分数可以作为初筛但不能作为最终选型的唯一依据。三是只算单价不算总成本。很多人在模型选型时只对比每百万 token 多少钱这是远远不够的。不同模型处理同一任务的 token 效率不同有的模型输出冗长有的简洁。价格分析必须结合真实任务的实际 token 消耗。1.3 三个维度缺一不可本文关注的核心是三个维度智力Intelligence模型理解、推理、生成内容质量的能力。性能Performance模型服务的响应速度、吞吐量、稳定性。价格Price调用成本包括输入 token、输出 token 的费用以及自部署时的算力成本。只有把三个维度放在一起看才能回答这个模型适不适合我的场景。举个例子一个模型智商再高如果单次响应要 30 秒也没办法做实时客服一个模型再便宜如果逻辑错误率 30%人工修复成本就会抵消掉差价。评估的最终目标是找到某一类业务场景下的最优平衡点。2. 评估前需要准备什么2.1 运行环境本文示例使用 Python 3代码量不大只需要安装两个依赖pip install openai pip install requests如果你的模型服务商提供了专属 SDK也可以替换为对应的包但原理是一样的。为了统一本文所有示例都采用 OpenAI 兼容的接口格式这也是目前绝大多数大模型服务商的通用做法。这样做的另一个好处是以后切换模型服务商时评估脚本基本不需要修改只需要更换 API Key、接入地址和模型名称。2.2 获取 API Key 与接入地址评估一个模型之前你需要确认以下信息API Key调用模型服务的凭证需要向模型服务商申请。请妥善保管不要提交到 Git 仓库也不要写死在代码里。接入地址Base URL例如https://your-endpoint.example.com/v1。具体地址以服务商文档为准。模型名称Model Name例如qwen3.8-max。不同服务商对模型名称的命名可能存在差异务必以官方文档为准。这里需要提醒的是大模型 API 属于计费服务评估过程会产生费用。建议先做小规模测试确认功能正常再逐步扩大测试规模。涉及生产环境前务必确认你已经获得合法授权并且对费用有预估。如果评估结束后发现费用异常第一时间检查是否有请求陷入了重试死循环。2.3 项目结构建议先建一个干净的目录把所有评估脚本集中管理llm-eval/ ├── eval_intelligence.py # 智力评估脚本 ├── benchmark_performance.py # 性能压测脚本 ├── estimate_cost.py # 成本测算脚本 ├── config.py # 统一配置 ├── report/ # 评估报告输出目录 ├── results/ # 原始结果目录 └── README.md # 记录评估日期、版本、结论把配置、脚本、结果分开管理可以保证评估过程可追溯。README 里建议记录每次评估的时间、模型版本、测试参数和主要结论方便后续对比。2.4 统一配置示例创建一个config.py把模型名称、接入地址、API Key 集中管理# 文件路径config.py import os MODEL_NAME os.getenv(MODEL_NAME, qwen3.8-max) API_KEY os.getenv(API_KEY, ) BASE_URL os.getenv(BASE_URL, https://your-endpoint.example.com/v1) DEFAULT_TEMPERATURE 0.3 DEFAULT_MAX_TOKENS 1024 TIMEOUT_SECONDS 60通过环境变量读取 API Key 而不是硬编码是为了避免密钥泄露。在实际项目中更推荐使用密钥管理服务如云厂商的 KMS 或 Vault让密钥只存在于运行时环境中。评估脚本只是工具安全习惯要从一开始就建立。3. 智力维度如何量化聪明3.1 智力评估的常见方法智力是三个维度中最难量化的。目前业界通常分三层。第一层是通用基准评测。例如 MMLU多任务语言理解、C-Eval中文评估基准、GSM8K数学应用题、HumanEval代码生成等。这些基准的好处是有标准答案可以横向对比缺点是题目偏学术和真实业务差距较大。如果你关注中文场景C-Eval 这类中文基准的参考价值会更高一些。第二层是人工对抗式测试。由领域专家设计一批贴近业务的题目逐个询问模型再人工打分。这种方式更贴近真实使用但成本高、不可复现且打分标准容易受主观因素影响。第三层是自动化的业务样例回归。把日常业务中积累的问答对整理成测试集每次模型升级后跑一遍看正确率是否有回退。这也是我们最推荐团队长期维护的方式。它不需要每次请专家只需要在最初设计题目时投入精力后续价值会越来越大。3.2 设计一份小型评估题目集在还没有业务数据的情况下可以先设计一份覆盖常见能力点的题目集包括数学推理、代码生成、逻辑推理、中文理解、长文本归纳等。每个题目要带上参考标准方便后续人工或自动打分。下面是一个可以直接运行的智力评估脚本# 文件路径eval_intelligence.py import time import json from openai import OpenAI from config import API_KEY, BASE_URL, MODEL_NAME, DEFAULT_TEMPERATURE, DEFAULT_MAX_TOKENS client OpenAI(api_keyAPI_KEY, base_urlBASE_URL) test_cases [ { category: 数学推理, prompt: 一个水池有一个进水管和一个出水管。进水管单独注满水池需要 6 小时出水管单独放空水池需要 9 小时。如果两个水管同时打开多长时间可以注满水池, reference: 18小时, scoring: 参考答案是否一致且推导过程完整 }, { category: 代码生成, prompt: 请用 Python 写一个函数输入一个整数列表返回其中出现次数最多的元素。如果有多个返回任意一个。, reference: 函数可以运行并且能返回正确众数, scoring: 代码可执行、边界处理正确、有基本注释 }, { category: 逻辑推理, prompt: 有三个盒子一个盒子只装苹果一个盒子只装橘子一个盒子装苹果和橘子。三个盒子上分别贴着苹果、橘子、苹果和橘子的标签但所有标签都贴错了。你只能从一个盒子中取一个水果。应该从哪个盒子取水果才能确定每个盒子里装的是什么, reference: 从贴苹果和橘子的盒子里取, scoring: 结论正确并解释所有标签都贴错这一关键条件 }, { category: 中文理解, prompt: 请解释成语杯水车薪的含义并用它造一个句子。, reference: 解释准确句子通顺自然, scoring: 语义准确无事实错误例句自然 }, { category: 长文本归纳, prompt: 以下是一段用户反馈的摘要请用 3 句话概括核心问题我们平台上周新增了拼团功能但用户普遍反映支付成功后订单状态不更新客服工单数量比上周增加了 300%主要集中在安卓端。开发排查发现是回调接口超时导致但产品经理认为需要先上线一个前端提示来缓解用户焦虑。, reference: 核心问题为支付回调超时导致订单状态不同步, scoring: 能抓住回调超时订单状态不更新安卓端集中三个关键信息 } ] def ask_model(prompt: str) - str: resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperatureDEFAULT_TEMPERATURE, max_tokensDEFAULT_MAX_TOKENS ) return resp.choices[0].message.content def main(): results [] for case in test_cases: start time.time() answer ask_model(case[prompt]) elapsed round(time.time() - start, 2) results.append({ category: case[category], prompt: case[prompt], answer: answer, reference: case[reference], scoring: case[scoring], elapsed_seconds: elapsed }) print(f[{case[category]}] 耗时 {elapsed}s) print(回答, answer[:200]) print(参考, case[reference]) print( * 60) with open(results/intelligence_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(结果已保存到 results/intelligence_results.json) if __name__ __main__: main()运行python eval_intelligence.py3.3 如何解读智力测试结果跑完脚本后你会得到一份 JSON 结果。接下来要做的是对照 reference 给每题打分。建议分为三档优秀结论正确推理完整几乎不需要修改。合格结论正确但缺少关键解释或格式不符合要求。不合格结论错误或存在明显的事实性错误。需要特别注意的是单次回答具有随机性。同一个问题即使 temperature 设为 0多次回答也可能不同。所以正式评估时建议每个问题重复 3 到 5 次统计正确率而不是只看一次结果。如果你的目标是长期跟踪模型质量建议把这份题目集沉淀为团队的评估资产。后续模型升级、换服务商、改 prompt 时都先跑一遍回归避免感觉变好了实际变差了的错觉。这是own your intelligence理念的具体落地不要被动接受厂商的结论而是建立属于自己的评测数据集和评分标准。3.4 业务测试集的设计思路通用题目集只能做初筛真正决定选型的一定是业务测试集。设计业务测试集时有几个建议。一是从真实日志里提取。翻出过去三个月用户最常见的提问、客服最常处理的工单整理成 50 到 100 条题目。这些题目才是你业务的核心。二是按难度分层。不要全是简单问题也要包含需要多步推理、需要结合上下文、需要输出结构化 JSON 的复杂场景。否则评估结果会虚高。三是提前定好评分标准。每条题目都要明确什么算对最好能写出简短参考答案。这样可以保证多人打分时标准一致也方便将来自动化评估。4. 性能维度从能答到答得快4.1 性能指标不只有快很多同学评估模型性能时只盯着响应时间这在真实项目中是不够的。要完整描述一个大模型服务的性能至少需要关注四个指标首 token 延迟TTFTTime To First Token发起请求到返回第一个 token 的时间。这个指标决定了用户感知到的响应速度。生成吞吐Tokens per Second每秒生成的 token 数量决定了整体等待时间。并发能力在多个请求同时发起时延迟是否还能保持稳定。稳定性长时间压测时是否出现超时、限流、错误率上升。打个比方前端开发者会用浏览器的 Performance 面板分析页面渲染耗时移动端开发者会用 Android Performance AnalyzerAPA这类工具定位应用卡顿。同样道理大模型服务也需要一套标准化的观测手段。只看一次请求的耗时很难说明问题。性能分析本质上是一套指标采集 数据对比 瓶颈定位的方法论无论在哪个技术栈都适用。4.2 性能压测脚本下面这个脚本分别用并发数 1、5、10 各打 10 个请求统计平均延迟、P95 延迟和生成速度# 文件路径benchmark_performance.py import time import statistics from concurrent.futures import ThreadPoolExecutor from openai import OpenAI from config import API_KEY, BASE_URL, MODEL_NAME, TIMEOUT_SECONDS client OpenAI(api_keyAPI_KEY, base_urlBASE_URL, timeoutTIMEOUT_SECONDS) TEST_PROMPT 请用 200 字左右介绍大语言模型的工作原理。 def single_request(): start time.time() resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: TEST_PROMPT}], max_tokens512, streamFalse ) end time.time() total_latency end - start usage resp.usage output_tokens usage.completion_tokens if usage else 0 input_tokens usage.prompt_tokens if usage else 0 throughput output_tokens / total_latency if total_latency 0 else 0 return { latency: total_latency, output_tokens: output_tokens, input_tokens: input_tokens, throughput: throughput, success: True } def run_batch(concurrency: int, total_requests: int): results [] with ThreadPoolExecutor(max_workersconcurrency) as executor: futures [executor.submit(single_request) for _ in range(total_requests)] for future in futures: try: results.append(future.result()) except Exception as exc: results.append({ latency: float(inf), output_tokens: 0, throughput: 0, success: False, error: str(exc) }) return results def summarize(results, concurrency): success [r for r in results if r.get(success)] failed [r for r in results if not r.get(success)] print(f并发数: {concurrency}, 请求数: {len(results)}, 成功: {len(success)}, 失败: {len(failed)}) if not success: print(全部请求失败请检查网络、鉴权和限流配置) return latencies [r[latency] for r in success] throughputs [r[throughput] for r in success if r[throughput] 0] print(f平均延迟: {statistics.mean(latencies):.2f}s) print(fP95 延迟: {sorted(latencies)[int(len(latencies) * 0.95) - 1]:.2f}s) if throughputs: print(f平均生成速度: {statistics.mean(throughputs):.2f} tokens/s) if __name__ __main__: for concurrency in [1, 5, 10]: results run_batch(concurrency, 10) summarize(results, concurrency) print(- * 60)运行python benchmark_performance.py4.3 结果怎么分析假设你拿到一组数据并发 1 时平均延迟 1.8 秒并发 10 时平均延迟 5.2 秒同时出现少量超时。这说明服务在低并发下表现不错但并发能力可能不够需要在架构上做排队削峰或者换成更高规格的服务。如果并发 1 时延迟就很高比如 10 秒以上先不要急着下结论。检查一下是不是请求内容过长、max_tokens 设置过大或者当前网络到服务端点的链路存在问题。另外生成类任务本身耗时与输出长度强相关比较延迟时要保证 max_tokens 和 prompt 长度一致否则数据没有可比性。如果测试结果出现大量 429 或超时说明触发了服务商限流。这种情况需要参考服务商文档中的 QPS每秒请求数和 TPM每分钟 token 数限制重新设计压测参数。建议在压测脚本中加入指数退避重试逻辑避免失败请求瞬间堆积放大压力。4.4 流式接口对性能体验的影响上面的压测用的是非流式接口也就是等全部内容生成完再一次性返回。真实业务中更推荐使用流式接口streamTrue让用户先看到第一个 token 出现明显改善等待体验。流式接口对性能观测