这段时间身边讨论大模型选型的朋友越来越多尤其是几个新模型的名字频繁出现在技术群、热搜和评测榜单里。我自己的感受是模型越多选型反而越难。光看榜单分数和宣传口径很难判断哪个模型真正适合自己业务的调用场景。本文打算围绕 GLM-5.3 Flash、Claude Opus 4.6、腾讯 Hy4 这三个模型梳理一套完整的对比方法和实操脚本。文章不是帮大家下结论“谁最强”而是给出一个可以自行验证的对比框架包括评测维度、测试脚本、成本估算思路和上生产前必须做的验证项。1. 背景为什么模型对比越来越复杂1.1 三个模型各自代表什么方向GLM-5.3 Flash 属于国产大模型阵营中的高性价比轻量系列Flash 后缀通常意味着更快的响应速度和更低的推理成本适合对延迟敏感、流量较大的应用场景。Claude Opus 4.6 则偏向海外闭源模型中的旗舰能力路线Opus 系列在长文本理解、复杂推理、代码生成等场景的口碑一直比较稳但价格也相对更高。腾讯 Hy4 是腾讯混元系列的新版本代号定位在大厂自研基础模型主要服务腾讯云生态内的企业客户强调中文场景能力和云端一体化部署。这里需要注意三个模型的版本细节、参数量、上下文窗口、价格等数据在撰写本文时仍以各厂商官方模型卡和 API 文档为准。原因是模型迭代速度非常快公开资料里很容易出现新旧版本参数混用的情况与其记死一组数据不如掌握一套查询和验证的方法。1.2 选模型不是在选“最强”而是在选“最合适”很多团队选型时习惯直接看综合榜单谁排在前面就接入谁。但实际落地时会发现榜单分数高不代表你的业务场景效果好。比如一个客服系统可能对响应速度要求极高一个代码补全工具可能更看重代码正确率一个合同分析系统可能对长文档理解能力更敏感。对比模型时必须先把业务场景拆成可量化的指标然后针对这些指标设计测试用例。否则就会出现“榜单上是第一名接进来后效果一般”的落差。这也是本文反复强调的一个核心观点对比模型的关键是先定义清楚自己的需求而不是先去查别人的结论。1.3 本文适合哪些读者本文适合正在做大模型应用选型的技术负责人、后端开发工程师和算法工程师。如果你是刚接触大模型 API 的新手文章里的概念解释和脚本可以直接帮你跑通对比流程如果你已经有接入经验也可以把文中的评测集设计、成本估算和灰度策略直接用到生产选型中。下面先从对比前必须确认的信息开始。2. 对比前必须确认三件事2.1 模型版本和文档版本要对齐模型名里的后缀非常重要比如 GLM-5.3 Flash 中的 Flash 表示轻量快速版本Claude Opus 4.6 中的 Opus 表示旗舰版本腾讯 Hy4 可能还有不同尺寸的衍生版本。接入前要先在官方文档里确认以下信息完整的模型名称包括版本号和后缀。上下文窗口长度单位通常是 token。是否支持多模态输入。是否支持结构化输出、函数调用等高级能力。该版本是稳定版还是预览版。如果团队内部有多个项目同时接入模型建议建立一个模型版本登记表记录每个项目使用的厂商、模型名、接入日期、主要用途。否则模型一升级线上行为可能发生细微变化到时候排查问题会很被动。2.2 API 接入方式和鉴权方式差异三个模型的 API 形态不完全一样。有的厂商直接提供 OpenAI 兼容接口有的则需要使用厂商自己的 SDK。更常见的情况是同一个厂商同时提供两种接入方式。对比评估时建议统一用 OpenAI 兼容接口做测试这样可以减少代码分支。所以拿到 API 文档后第一件事不是写业务代码而是确认三件事Base URL 指向哪个地址。请求头里的鉴权字段是 Authorization Bearer 还是自定义 Header。请求体和响应体是否符合 OpenAI Chat Completions 的格式。如果三个模型都能通过 OpenAI 兼容接口访问后续写对比脚本会非常省力只需要切换不同的 base_url、api_key、model 名称即可。2.3 数据合规和部署方式这一点往往被技术团队忽略但在真正的企业场景中可能是决定性因素。要确认你的业务数据是否允许发送到模型提供方的云端。比如涉及金融、医疗、政务等敏感数据时很多团队只能选择私有化部署或专有云版本。对比选型时要把可部署方式当作一个硬性筛选条件而不是最后再考虑的因素。如果某个模型在你的合规要求下根本不能使用那么它的能力再强也不在你的候选列表里。3. 核心对比维度拆解3.1 基础能力理解、生成、推理、代码基础能力评测通常包括问答准确性、逻辑推理、代码生成正确率、中英文能力、长文本理解等。公开评测集如 MMLU、GSM8K、HumanEval 等可以做为参考但不能照搬因为这些评测集和真实业务场景存在较大差异。做基础能力对比时建议按以下方式设计用例问答类准备 20 到 50 道与业务相关的知识性问题。推理类包含数学计算、逻辑判断、条件推导。代码类包含函数实现、Bug 修复、代码解释。长文本类准备一份超过上下文窗口一半长度的文档让模型做摘要或信息抽取。每个用例都要预先给定“标准答案”或“评分标准”避免人工主观打分导致偏差。更规范的做法是让同一个用例发给三个模型然后把输出顺序打乱后再交给人工评分减少已知品牌对评分者的心理暗示。3.2 性能指标首 token 延迟、吞吐、稳定性性能指标是选型中最容易被低估的部分。因为很多评测只关注“答案质量”而实际业务对响应速度非常敏感。重点关注这几个指标TTFTTime to First Token从发起请求到收到第一个 token 的时间这个指标直接影响用户感知的响应速度。Token 生成速率每秒生成的 token 数量影响长文本生成场景的总耗时。并发稳定性在固定并发下测试错误率、超时率、限流情况。长时间运行稳定性连续调用数小时观察是否出现内存泄漏、连接池耗尽、服务端 5xx 等问题。性能测试不能用单个请求的结果下结论应该用不同并发梯度反复测试每个梯度至少压测 5 到 10 分钟。例如并发 1、10、50、100 四档记录 p50、p95、p99 延迟。3.3 成本模型不只是 Token 单价成本对比最容易踩的坑是只对比每百万 token 的单价却忽略其他因素。一个完整的成本模型至少包括以下部分输入 token 单价和输出 token 单价。缓存命中价格是否更低。请求量大时是否有阶梯折扣。是否必须开通更高等级的套餐。如果做私有化部署还需要计算 GPU 资源成本和运维成本。另外不同模型对 token 的切分方式也不同。同一段中文文本在不同模型下消耗的 token 数可能相差不少所以成本对比不能只看单价还要用业务真实文本测量实际的 token 消耗量再结合单价计算总成本。3.4 生态与工程化能力模型能力之外还要看模型周边的工程化生态。比如是否支持流式输出。是否支持函数调用和工具使用。是否支持 JSON 结构化输出。SDK 和官方文档是否完善。是否有官方提供的监控、日志、版本管理工具。是否支持在主流云平台上直接托管。这些工程化能力决定了接入成本和后期维护成本。一个模型即使模型本身很强如果 SDK 老旧、文档缺失开发团队接入时也会浪费大量时间。4. 建立一套可复用的对比流程4.1 先定义业务场景和验收标准对比流程的第一步是定义业务场景。举个例子如果我们要做一个智能客服场景就可以拆成意图识别、知识库问答、情绪安抚、多轮对话。每个场景都要有明确的验收标准比如“意图识别准确率 ≥ 90%”“知识库回答引用正确率 ≥ 85%”。没有验收标准就上对比测试最后只能凭感觉给结论。这在团队协作中是很危险的因为不同人对“效果不错”的标准完全不同。4.2 设计评测集和评分卡评测集的来源可以分成三类业务历史数据从日志中抽取真实用户请求。人工构造数据针对边界情况手动编写。公开评测集作为横向参考。建议先把业务数据整理成 JSONL 格式每一行包含输入、期望输出、评分说明。然后再准备一份评分卡用 1 到 5 分对模型的每次输出进行打分。评分标准要细化不能只写“回答是否准确”要拆成“事实准确性”“逻辑完整性”“格式规范性”“可执行性”等子项。4.3 控制评测过程的变量为了让对比结果可信评测过程中要控制变量。比如统一使用相同的 temperature、max_tokens 等参数避免因为采样温度不同导致结果差异。三个模型的请求顺序要随机打乱防止某个模型因为网络波动周期性失败。评测脚本要记录每一次请求的时间、token 数、返回码、输出内容方便复盘。5. 实战用 Python 写一个对比评测脚本5.1 准备环境与依赖本文的评测脚本使用 Python 编写依赖 openai 库和 tiktoken用于 token 统计。建议使用 Python 3.10 或以上版本。先安装依赖pip install openai tiktoken5.2 统一模型配置为了方便对比把三个模型的接入信息放在一个配置文件里。这里以 OpenAI 兼容接口为例各自对应的 base_url、api_key、model_name 需要根据你实际申请到的接入信息填写。# config.py MODELS { glm: { base_url: https://your-endpoint.example.com/v1, api_key: your-api-key, model_name: glm-5.3-flash, price_per_1m_input: 0, # 单价以官方定价页为准 price_per_1m_output: 0, }, claude: { base_url: https://your-endpoint.example.com/v1, api_key: your-api-key, model_name: claude-opus-4.6, price_per_1m_input: 0, price_per_1m_output: 0, }, hunyuan: { base_url: https://your-endpoint.example.com/v1, api_key: your-api-key, model_name: hy4, price_per_1m_input: 0, price_per_1m_output: 0, }, }说明一下配置文件里的价格字段需要你到各厂商官网查询后填写。不同厂商的计费单位可能不同有的是每百万 token 计费有的是按千 token 计费换算时要统一单位。5.3 实现统一调用层下面这个类封装了 OpenAI 兼容接口的调用逻辑同时记录了请求耗时和 token 消耗。这个类的设计目标是让后续测试函数只关注业务逻辑不用关心不同模型之间的接入差异。# model_client.py import time from openai import OpenAI from config import MODELS class ModelClient: def __init__(self, model_key: str): if model_key not in MODELS: raise ValueError(fUnknown model key: {model_key}) self.model_key model_key cfg MODELS[model_key] self.client OpenAI( base_urlcfg[base_url], api_keycfg[api_key], ) self.model_name cfg[model_name] self.price_per_1m_input cfg[price_per_1m_input] self.price_per_1m_output cfg[price_per_1m_output] def chat(self, messages, temperature0.7, max_tokens1024, streamFalse): start time.time() resp self.client.chat.completions.create( modelself.model_name, messagesmessages, temperaturetemperature, max_tokensmax_tokens, streamstream, ) elapsed time.time() - start output_text resp.choices[0].message.content usage resp.usage return { output: output_text, elapsed: elapsed, prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, } def chat_stream(self, messages, temperature0.7, max_tokens1024): start time.time() ttft None chunks [] resp self.client.chat.completions.create( modelself.model_name, messagesmessages, temperaturetemperature, max_tokensmax_tokens, streamTrue, ) for chunk in resp: if ttft is None and chunk.choices[0].delta.content: ttft time.time() - start content chunk.choices[0].delta.content if content: chunks.append(content) elapsed time.time() - start output_text .join(chunks) completion_tokens len(output_text) return { output: output_text, elapsed: elapsed, ttft: ttft, completion_tokens: completion_tokens, } def estimate_cost(self, prompt_tokens, completion_tokens): input_cost prompt_tokens / 1_000_000 * self.price_per_1m_input output_cost completion_tokens / 1_000_000 * self.price_per_1m_output return input_cost output_cost这里的 chat_stream 方法用于测量 TTFT 和生成吞吐。注意流式模式下 usage 可能不返回因此 completion_tokens 先用输出字符数近似更精确的统计可以结合 tiktoken 做 token 级计算。5.4 准备评测集评测集使用 JSONL 格式每一行包含一个测试用例。下面给出一个简单示例实际使用时替换成你自己的业务数据。{id: 1, prompt: 用一句话解释什么是大模型微调。, expected: 包含数据、训练、任务适配等关键词} {id: 2, prompt: 写一个 Python 函数判断一个字符串是否为回文。, expected: 代码正确且包含边界判断} {id: 3, prompt: 请阅读以下合同条款找出对甲方不利的条款并说明原因。\n此处粘贴合同文本, expected: 输出中提到甲方责任过大、赔偿条款不对等等风险点}评测集数量建议至少准备 30 到 50 条覆盖不同难度和不同场景。数量太少模型之间的差异很难体现出来。5.5 执行评测并输出结果下面这段代码会依次调用三个模型跑完整个评测集并输出一个简单的对比报告。# run_eval.py import json import time from model_client import ModelClient def load_dataset(patheval_set.jsonl): cases [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: cases.append(json.loads(line)) return cases def run_eval(): dataset load_dataset() model_keys [glm, claude, hunyuan] clients {k: ModelClient(k) for k in model_keys} results {k: [] for k in model_keys} for case in dataset: messages [ {role: system, content: 你是一个严谨的测试模型请严格根据题目要求回答。}, {role: user, content: case[prompt]}, ] for key, client in clients.items(): try: res client.chat(messages, temperature0.3, max_tokens1024) results[key].append({ case_id: case[id], output: res[output], elapsed: res[elapsed], prompt_tokens: res[prompt_tokens], completion_tokens: res[completion_tokens], }) except Exception as e: results[key].append({ case_id: case[id], error: str(e), }) time.sleep(0.5) # 控制请求频率避免触发限流 # 输出摘要 for key, items in results.items(): total_elapsed 0 total_prompt 0 total_completion 0 error_count 0 for item in items: if error in item: error_count 1 continue total_elapsed item[elapsed] total_prompt item[prompt_tokens] total_completion item[completion_tokens] avg_elapsed total_elapsed / max(len(items), 1) print(f模型 {key}: 完成 {len(items)} 条, 错误 {error_count}, f平均耗时 {avg_elapsed:.2f}s, f输入 token 总计 {total_prompt}, 输出 token 总计 {total_completion}) if __name__ __main__: run_eval()这个脚本输出的还只是基础指标真正的质量判断需要结合人工评分。你可以把每个模型的输出导出到 Excel 或 CSV 文件中交给业务人员评分。5.6 增加性能压测逻辑除了逐条评测我们还需要一个简单的并发压测脚本用来观察三个模型在并发场景下的表现。下面的脚本使用线程池模拟并发请求并统计 p50、p95、p99 延迟。# pressure_test.py import concurrent.futures import statistics import time from model_client import ModelClient def single_request(client): messages [ {role: user, content: 请用三句话介绍人工智能的发展历史。} ] start time.time() res client.chat_stream(messages, max_tokens256) elapsed time.time() - start return { elapsed: elapsed, ttft: res[ttft], } def pressure_test(model_key, concurrency10, total_requests50): client ModelClient(model_key) results [] with concurrent.futures.ThreadPoolExecutor(max_workersconcurrency) as executor: futures [executor.submit(single_request, client) for _ in range(total_requests)] for future in concurrent.futures.as_completed(futures): try: results.append(future.result()) except Exception as e: print(f请求失败: {e}) if not results: print(f{model_key}: 无有效结果) return elapsed_list sorted([r[elapsed] for r in results]) ttft_list sorted([r[ttft] for r in results if r[ttft] is not None]) def percentile(data, p): if not data: return 0 idx min(int(len(data) * p), len(data) - 1) return data[idx] print(f模型 {model_key}: 并发 {concurrency}, 完成 {len(results)} 条) print(f 总耗时 p50: {percentile(elapsed_list, 0.5):.2f}s, fp95: {percentile(elapsed_list, 0.95):.2f}s, fp99: {percentile(elapsed_list, 0.99):.2f}s) if ttft_list: print(f TTFT p50: {percentile(ttft_list, 0.5):.2f}s, fp95: {percentile(ttft_list, 0.95):.2f}s) if __name__ __main__: for key in [glm, claude, hunyuan]: pressure_test(key, concurrency10, total_requests30)这个脚本虽然简单但已经能发现一些明显问题比如某个模型在并发升高时频繁报 429 限流或者 TTFT 明显比其他模型高。真实的压测应该使用更专业的工具并在不同地域、不同网络环境、不同时间段重复测试。6. 常见问题与排查思路下面整理了一些型号对比评估中常见的问题和解决方案问题现象常见原因解决思路三个模型返回格式不一致未统一使用相同的请求参数统一 temperature、max_tokens使用相同的 system prompt同一模型重复测试结果差异大采样温度较高导致随机性增强评测时设置 temperature ≤ 0.3或多个用例取平均某个模型频繁报 429 限流触发厂商 QPS 限制降低并发增加重试机制或申请更高配额Token 统计差异较大不同模型 tokenizer 不一致使用 tiktoken 或模型自带 tokenizer 分别统计流式输出与普通输出结果不一致流式模式下 usage 字段不可用用 tiktoken 对输出文本重新计算 token成本估算偏差大只算单价忽略 token 消耗差异用真实业务文本测量 token 消耗后再估算长文档测试时超出上下文限制输入超过模型上下文窗口先做文本切片或摘要再送入模型评分主观性过强评分标准不清晰把评分项拆分子指标多人评分取平均这里再单独说一下限流的问题。压测时发现某个模型并发一高就报错不一定是模型质量差可能是因为免费额度或默认配额比较低。对比时务必确认所有模型使用的是同等配额等级否则对比结果会偏差很大。7. 选型最佳实践与工程建议7.1 不要只依赖公开榜单要跑通自己的评测集公开榜单是了解模型能力下限的快速渠道但不应该是选型决策的唯一依据。每个团队都应该维护一套自己的评测集并且随着业务发展不断扩充。一个正常的节奏是每季度或者每半年跑一次模型评测把结果沉淀成报告。这样当新模型发布时就能快速判断是否值得切换。7.2 上生产前必须做的三次验证第一个是功能验证确认模型在目标场景下的输出质量。第二个是性能验证确认模型在预估并发下的响应时间和错误率。第三个是成本验证用真实业务流量做小规模试点统计实际 token 消耗和费用。三次验证全部通过后才建议进入灰度阶段。7.3 多模型共存比单一模型更稳妥实际工程中不建议把所有业务都绑定到一个模型上。更稳妥的做法是一个模型作为主模型另一个模型作为备用模型。主模型故障或限流时可以通过降级策略切到备用模型。不同场景也可以选择不同模型比如简单意图识别用轻量快速模型复杂推理用旗舰模型。7.4 关注模型版本升级带来的隐性变化模型厂商升级版本后即使名字不变内部行为也可能发生变化。比如同一段 prompt 的返回格式、语气、拒绝策略都可能改变。建议在代码中固定模型版本号并建立版本升级的回归测试机制。升级前先在测试环境跑一遍评测集确认核心指标没有回退再逐步切到生产环境。7.5 重视数据回流和评测集的持续更新最后一条建议是把评测集当成代码一样去维护。每次业务迭代中出现的新问题、新边界案例都应该补充到评测集里。这样模型的对比结果才会越来越贴近真实业务而不是停留在最初测试那几十条用例的层面。8. 总结与下一步可以去做什么本文围绕 GLM-5.3 Flash、Claude Opus 4.6、腾讯 Hy4 三个模型整理了一套可操作的对比选型方法。核心要点可以归纳为先明确业务场景再设计评测集控制好变量做测试最后结合质量、性能、成本、合规四个维度做综合判断。文中给出的 Python 脚本可以直接用来跑通基础评测、性能压测和成本估算流程。下一步建议你先把这个脚本跑起来用自己的业务数据替换评测集跑完一轮后把各个模型的输出导出成文件发给业务同事做人工评分。这轮评估做完你对这三个模型的差异会有一个比任何榜单都准确的认识。如果后续模型版本更新也可以复用这套流程快速重新评估。如果你在跑评测过程中遇到限流、格式不一致、成本估算偏差等问题可以对照上面的排查表格逐个定位。模型选型没有一劳永逸的答案但一套稳定的评估流程能让你在每次模型更新时都掌握主动权。