模型选型这件事最怕的不是没有选择而是选择太多。Kimi K3、Claude Fable、GPT 5.6 这几个名字在近期的技术讨论里热度很高很多人都在问“Kimi K3 真的能打”或者“Claude Fable 与 GPT 5.6 谁更聪明”但真正要回答这些问题靠几张截图和几条热搜词是不够的因为模型评测非常容易被 prompt 写法、采样参数、上下文长度、模型版本和任务类型影响。与其人云亦云不如建立一套最小可复现的模型对战框架把 Kimi K3、Claude Fable、GPT 5.6 放到同一起跑线上跑一轮用可验证的数据而不是印象流来下结论。需要先说明一点Kimi K3、Claude Fable、GPT 5.6 都属于迭代速度极快的模型代号本文不讨论这些名称背后的具体版本细节而是把它们当作“被测模型”来处理。实际接入时请把代码里的模型 ID 替换成对应服务商当前真正可用、文档里写清楚的 ID。评测流程本身才是这篇文章最有价值的产出因为模型会换代但公平评测的方法不会过时。1. 先搞清楚“真的能打”到底是什么指标1.1 能力谱系先从推理和代码开始模型对战最容易犯的错误是只比“谁的回答看起来有道理”。但“看起来有道理”既不能量化也不能复现更不能用来做技术决策。真实项目里判断一个模型能不能打第一层要看能力谱系也就是它能不能完成一类具体任务。能力谱系通常按这几类拆开数学推理、逻辑推理、代码生成、代码审查、长文本理解、多模态理解、指令遵循、中文表达。每一类都是独立的能力维度。一个模型可能在数学推理上很强但代码生成经常截断也可能代码能力优秀但中文长文档总结会丢失关键信息。这种差异直接决定了它适合放在哪个业务场景。评测时不要把多个维度混在一个 prompt 里。比如“请写一个 Python 快排并解释时间复杂度和空间复杂度然后给一个例子”这个问题同时考察代码生成、算法理解和表达组织一旦模型输出不完整你很难判断是代码能力弱还是解释能力弱。正确的做法是一个任务只测一个维度代码题只要求输出可运行的代码推理题只要求给出推导过程和最终答案。1.2 工程体验速度、吞吐和稳定性第二个维度经常被忽略模型再聪明如果 API 响应要等 1 分钟或者并发一高就限流生产环境根本用不了。工程体验包括首 token 延迟、吞吐量、上下文处理能力、API 稳定性、限流配额和错误率。首 token 延迟是用户能直接感知的指标。对聊天类和 Agent 类场景用户更在意“第一个字多久出现”而不是整段回复的总时长。对批量离线任务比如日志分类、文档摘要吞吐量更重要单位时间能处理多少条请求直接决定任务成本和人力。稳定性则要看连续请求的失败率、超时率、报错频率。这些指标很难通过一两道题测出来需要构造一批重复请求统计延迟分布和错误率。我在后面的批量评测脚本里会给出一个简易实现。1.3 成本模型单价只是起点成本是“能不能打”的硬约束。一个模型即使分数最高如果单次请求价格是其他模型的几倍吞吐又低那很多业务场景只能放弃。成本模型不能只看每百万 token 的单价还要看实际消耗。同一个任务有的模型要用更多输出 token 才能表达清楚有的模型会反复解释冗余内容长上下文任务里输入 token 的消耗往往占大头这时候上下文长度和计费方式就非常重要。更隐蔽的成本出现在重试和人工修正上。如果模型输出 5 次里有一次 JSON 格式错误程序就得重试或人工修复这部分隐性成本很难从 API 账单里直接看出来但会显著抬升真实成本。所以评测里不仅要记 token 数还要记录格式合法率、重试次数、人工介入次数。1.4 评测公平性参数、版本和 prompt 必须一致模型对战的底线是公平。很多评测翻车不是因为模型差而是因为控制变量没做好。同一个问题temperature 一个设 0一个设 0.7结果完全不可比同一个模型昨天用的版本和今天的版本不一样结果也会漂移一个模型用长系统提示词另一个模型只用一句话这也不公平。公平评测至少要做到同一套 prompt、同一组采样参数、同一个最大输出长度、同一轮上下文信息、相同次数的重复采样。模型 ID 要固定不能今天用正式版明天用预览版否则结果无法追溯。所有请求参数都要写入日志这才有复盘价值。2. 搭建模型对战环境让三个模型可以被同一套代码调用2.1 基础环境准备开始写代码之前先准备好 Python 环境和依赖。建议使用 Python 3.10 以上版本并创建虚拟环境避免依赖冲突。mkdir llm-battle cd llm-battle python -m venv venv source venv/bin/activate pip install httpx这里只引入 httpx 一个核心依赖用来发送异步 HTTP 请求。不引入大型 SDK是因为不同模型厂商的 SDK 版本差异会影响参数行为统一走 HTTP 接口反而更容易控制参数。如果你的服务商只提供 SDK 方式也可以保留 SDK但一定要固定版本并在评测报告里写清楚。还需要准备环境变量文件把 API Key 放在环境变量里不要写进代码或提交到仓库。export KIMI_API_KEYyour_kimi_key_here export CLAUDE_FABLE_API_KEYyour_claude_key_here export GPT56_API_KEYyour_gpt_key_here2.2 用一个统一接口接住不同厂商的模型不同模型厂商的接口格式可能不同但大部分都提供 OpenAI 兼容接口也就是POST /chat/completions请求体里包含model、messages、temperature、max_tokens。为了让三个模型可以共用一套评测逻辑我先定义一个统一的数据结构然后在代码里做一次转换。# model_client.py import os import time import httpx from dataclasses import dataclass, asdict from typing import List, Optional dataclass class ChatMessage: role: str content: str dataclass class ModelResponse: model: str task_id: str answer: str elapsed_sec: float input_tokens: int output_tokens: int error: str MODELS { kimi-k3: { base_url: REPLACE_WITH_KIMI_BASE_URL, api_key_env: KIMI_API_KEY, model_id: REPLACE_WITH_KIMI_MODEL_ID, }, claude-fable: { base_url: REPLACE_WITH_CLAUDE_BASE_URL, api_key_env: CLAUDE_FABLE_API_KEY, model_id: REPLACE_WITH_CLAUDE_MODEL_ID, }, gpt-5.6: { base_url: REPLACE_WITH_GPT_BASE_URL, api_key_env: GPT56_API_KEY, model_id: REPLACE_WITH_GPT_MODEL_ID, }, } async def call_model(model_name: str, messages: List[ChatMessage], temperature: float, max_tokens: int): config MODELS[model_name] headers { Authorization: fBearer {os.environ[config[api_key_env]]}, Content-Type: application/json, } payload { model: config[model_id], messages: [asdict(m) for m in messages], temperature: temperature, max_tokens: max_tokens, } start time.time() async with httpx.AsyncClient(timeout120) as client: try: resp await client.post( f{config[base_url]}/chat/completions, headersheaders, jsonpayload, ) elapsed time.time() - start if resp.status_code ! 200: return ModelResponse( modelmodel_name, task_id, answer, elapsed_secelapsed, input_tokens0, output_tokens0, errorfHTTP {resp.status_code}: {resp.text[:500]} ) data resp.json() content data[choices][0][message][content] usage data.get(usage, {}) return ModelResponse( modelmodel_name, task_id, answercontent, elapsed_secelapsed, input_tokensusage.get(prompt_tokens, 0), output_tokensusage.get(completion_tokens, 0), error ) except Exception as e: elapsed time.time() - start return ModelResponse( modelmodel_name, task_id, answer, elapsed_secelapsed, input_tokens0, output_tokens0, errorstr(e) )这段代码有几个关键点。MODELS字典把三个模型的服务地址、环境变量名、模型 ID 都收拢到一处后续跑题集时只需要传model_name。base_url和model_id必须根据各家最新文档替换不能照抄占位符。响应里不仅记录答案还记录延迟和 token 消耗这些字段在后面的成本分析里会用到。还要注意有的模型服务商接口使用的是max_completion_tokens而不是max_tokens有的是/v1/messages而不是/chat/completions。如果遇到 400 参数错误第一步就是检查参数名和 endpoint 是否匹配不要急着怀疑模型能力。2.3 记录请求参数保证后续可比评测过程中所有请求参数都必须落盘。光有答案没有参数等于没有评测。最简单的做法是写一个append_result函数把每次请求的模型名、题号、温度、最大 token、答案、延迟、token 用量和错误信息追加到 JSONL 文件里。# runner.py import json import asyncio from model_client import call_model, ChatMessage, ModelResponse RESULTS_FILE results.jsonl def save_to_jsonl(task_id: str, model: str, prompt: str, response: ModelResponse): record { task_id: task_id, model: model, prompt: prompt, answer: response.answer, elapsed_sec: round(response.elapsed_sec, 2), input_tokens: response.input_tokens, output_tokens: response.output_tokens, error: response.error, } with open(RESULTS_FILE, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)为什么用 JSONL 而不是 JSON因为评测任务会持续追加JSONL 每行一条记录方便增量写入也方便用pandas或命令行工具按行读取不需要在每次追加时把整个文件读进内存。后续做统计时过滤出模型名和题号即可。2.4 本地部署模型的额外控制点如果某个模型是本地部署比如通过 vLLM、Ollama、llama.cpp 暴露服务评测环境和云 API 不同需要额外控制几个变量量化精度是 FP16、INT8 还是 INT4推理框架是 vLLM 还是 Transformers显卡型号和显存大小并发数以及 KV Cache 策略。这些因素都会影响输出质量和延迟所以本地模型的评测结果只能代表“当前这台机器、当前这个推理框架下的表现”不能代表模型本身的全部能力。如果要在评测报告里同时对比云 API 模型和本地部署模型建议在结果表里额外增加一列“部署方式”否则很容易拿着本地部署的量化模型分数去质疑云端原版模型这是不公平的。3. 设计一套公平的对战题集3.1 测试集要覆盖业务真实场景对战题集的质量直接决定评测结果是否可信。理想测试集不是从网上随便找 10 道题而是从你的业务场景里抽取真实任务再加上一批已经确定答案的标准题作为“锚点”。标准题用来验证模型的基础能力答案应该是确定的。比如“计算 7 的 8 次方”“用 Python 写一个二分查找”“把一段中文翻译成英文”。这类题目方便快速判断模型是否在线、是否具备基本能力。业务题用来验证实际可用性比如“根据这个支付订单日志找出退款异常的原因”“把这段用户投诉内容分类并给出回复策略”。业务题没有唯一答案需要结合领域知识评分。测试集建议按 JSON 格式维护每个任务包含task_id、category、prompt、reference_answer、judge_type五个字段。{ tasks: [ { task_id: reasoning_001, category: math, prompt: 一个水池有一个进水管和一个出水管。单独打开进水管 3 小时注满水池单独打开出水管 4 小时放空水池。如果两个水管同时打开多少小时可以注满水池要求给出推导过程和最终答案。, reference_answer: 12 小时, judge_type: exact_match }, { task_id: code_001, category: code, prompt: 用 Python 写一个函数输入整数列表返回列表中第二大的数。如果列表长度小于 2返回 None。只输出代码不要解释。, reference_answer: , judge_type: code_check }, { task_id: chinese_001, category: chinese, prompt: 把下面这段产品介绍改写成适合电商详情页的中文文案要求保留所有卖点总字数不超过 150 字……, reference_answer: , judge_type: human_score } ] }judge_type决定了评分方式。exact_match是看答案是否与参考答案一致适合数学题、选择题code_check是运行或审查代码适合编程题human_score是人工按 1 到 5 分打分适合开放型写作、总结、翻译题。3.2 Prompt 写法不能偏向某个模型同一个任务prompt 写法会显著影响结果。如果对某个模型使用英文 prompt对另一个模型使用中文 prompt天然不公平。推荐所有 prompt 使用同一套语言并且在撰写时不带倾向性。这里有一条容易被忽略的原则不要在 prompt 里泄漏目标模型的名称。比如“作为 Kimi K3请回答”这种写法没有任何评测价值。对战评测的 prompt 应当是中性的工作任务描述只告诉模型要做什么、输出什么格式、有哪些限制不暗示身份。构造 prompt 时还建议统一加上输出格式要求。比如“只输出 JSON”“分点列出答案”“先给结论再给理由”。这样可以观察模型的格式遵循能力也方便后续自动化判断。但要注意格式要求本身也是一种能力测试不要所有题目都加否则会掩盖模型在某些场景下的真实表现。3.3 每题跑多次看分布而不是单次结果大模型输出具有随机性。同一个模型、同一个 prompt温度大于 0 时每次回答都可能不同。如果每个题目只跑一次就下结论可能会因为一道题的运气而误判模型。推荐每个任务至少跑 3 到 5 次温度设置为 0.2 到 0.3。这样既能保留一定多样性又不会太随机。分数统计时既记录最佳分数也记录平均分数和标准差。标准差很大说明稳定性差这在生产环境里是严重问题因为稳定可控比偶尔聪明更重要。重复采样会带来成本所以测试集不要盲目做大。建议核心锚点题 20 道业务题 15 道每个模型跑 3 次也就是每轮对战约 105 次请求。这个量级在大多数模型服务商的试用配额之内完成一轮基本够用。4. 跑一轮真实对战并记录结果4.1 单题盲测脚本单题盲测适合观察模型在某个具体任务上的表现。下面这个脚本会读取测试集里的某一题依次发给三个模型把原始输出打印出来。# run_single_task.py import asyncio from model_client import call_model, ChatMessage from runner import save_to_jsonl PROMPT 一个水池有一个进水管和一个出水管。单独打开进水管 3 小时注满水池单独打开出水管 4 小时放空水池。如果两个水管同时打开多少小时可以注满水池要求给出推导过程和最终答案。 async def main(): for model in [kimi-k3, claude-fable, gpt-5.6]: messages [ChatMessage(roleuser, contentPROMPT)] resp await call_model(model, messages, temperature0.2, max_tokens1000) print(f {model} ) print(resp.answer) print(f延迟: {resp.elapsed_sec:.2f}s, 输入token: {resp.input_tokens}, 输出token: {resp.output_tokens}) save_to_jsonl(reasoning_001, model, PROMPT, resp) asyncio.run(main())注意这个脚本是串行请求三个模型。在实际对战中如果有一个模型 API 超时或限流后面的模型也会被阻塞。建议后续改成并发调用每个模型独立超时互不影响。并发脚本见下一节。4.2 批量评测脚本批量评测要解决三个问题按测试集循环、控制并发、把结果落盘。下面这个脚本用asyncio.Semaphore控制最大并发数避免一次性打爆某个模型服务商的配额。# run_battle.py import asyncio import json import random from model_client import call_model, ChatMessage from runner import save_to_jsonl MODELS [kimi-k3, claude-fable, gpt-5.6] CONCURRENCY 5 TEMPERATURE 0.2 MAX_TOKENS 2000 RUNS_PER_TASK 3 async def run_one(task: dict, model: str, run_index: int): messages [ChatMessage(roleuser, contenttask[prompt])] resp await call_model(model, messages, TEMPERATURE, MAX_TOKENS) task_id f{task[task_id]}_run{run_index} save_to_jsonl(task_id, model, task[prompt], resp) print(f[{task_id}] {model} 完成耗时 {resp.elapsed_sec:.2f}s) if resp.error: print(f[{task_id}] {model} 错误: {resp.error}) async def main(): with open(tasks.json, r, encodingutf-8) as f: tasks json.load(f)[tasks] random.seed(42) jobs [] for task in tasks: for i in range(RUNS_PER_TASK): for model in MODELS: jobs.append((task, model, i)) random.shuffle(jobs) semaphore asyncio.Semaphore(CONCURRENCY) async def worker(task, model, i): async with semaphore: await run_one(task, model, i) await asyncio.gather(*[worker(t, m, i) for t, m, i in jobs]) if __name__ __main__: asyncio.run(main())这个脚本有几个设计点。random.seed(42)固定随机种子虽然不一定影响模型输出但能让评测记录里的执行顺序可复现。random.shuffle(jobs)打乱任务顺序避免某个模型一直排在前面因为热点时段不同先跑和后跑的模型可能遇到不同的服务端负载。Semaphore控制并发为 5既能提速又不会把限流打出来。4.3 结果汇总和人工评分批量跑完后results.jsonl里已经积累了大量原始记录。下一步是汇总成一个适合评分和阅读的表格。可以使用 pandas 生成宽表每一行是一个任务每一列是一个模型在第一次运行时的答案摘要。# summarize.py import pandas as pd import json rows [] with open(results.jsonl, r, encodingutf-8) as f: for line in f: rows.append(json.loads(line)) df pd.DataFrame(rows) summary df.groupby([task_id, model]).agg( avg_elapsed_sec(elapsed_sec, mean), avg_input_tokens(input_tokens, mean), avg_output_tokens(output_tokens, mean), error_count(error, lambda x: (x ! ).sum()), ).reset_index() summary.to_csv(summary.csv, indexFalse, encodingutf-8-sig) print(summary.head(20))人工评分时建议把答案按题目聚合并导出成 markdown 表格然后对照参考标准逐题打分。4.4 结果表怎么读下面是一张状态较为理想的结果记录表用于说明格式不代表任何模型的真实性能。task_idmodelanswer摘要耗时(秒)input_tokensoutput_tokens错误reasoning_001_run0kimi-k3推导过程正确最终 12 小时8.2180120无reasoning_001_run0claude-fable推导过程正确最终 12 小时12.4190140无reasoning_001_run0gpt-5.6第一次答成 7 小时第二次自我修正15.1210260无code_001_run1kimi-k3输出完整可运行代码6.515090无code_001_run1claude-fable输出代码缺少边界检查9.8160110无code_001_run1gpt-5.6API 超时120.000timeout这张表告诉我们三个信息正确性、延迟、稳定性。观察一个模型不能只看第一题要看它在所有任务上的“平均分 失误率 最大延迟”。如果一个模型回答质量最高但超时严重它在实时交互场景中就不可用如果一个模型正确率稳定但从未有惊艳答案它在批量处理中反而更可靠。注意不要只验证程序能启动还要验证输出、延迟、token 和异常分支是否符合预期。评测脚本本身也可能有 bug第一次跑完后先抽几行 JSONL 人工核对不要直接拿数据写结论。5. 从对战数据中看模型差距5.1 正确率之外更要关注失败模式正确率是一个汇总数字但真正对技术决策有用的是失败模式。两个模型可能正确率都是 80%但一个模型的错误集中在数学推理一个模型的错误集中在代码输出截断这两者的应对策略完全不同。建议每轮评测结束后把失败案例单独提取出来按错误类型分类。常见错误类型包括计算错误、逻辑跳跃、代码语法错误、代码不完整、JSON 格式错误、拒答、上下文丢失、中文表达混乱、幻觉补充不可靠信息。每个类型背后对应不同的工程适配方案。比如代码不完整可以通过提高max_tokens缓解JSON 格式错误可以在 prompt 里加 few-shot 示例或在程序里增加重试和解析修复逻辑幻觉问题则要引入检索约束或降低温度。5.2 延迟和成本会让聪明打折扣假设模型 A 回答质量 90 分单次请求 3 元模型 B 质量 85 分单次请求 0.5 元但模型 B 需要额外写 500 行代码做输出清洗才能达到 88 分。这时候总成本反而是模型 B 更高因为不是模型本身贵而是“使用成本”贵。在评估结果表里建议额外增加一个“质量达标成本”列质量分除以单次成本。这个比值比单纯的质量分更有业务意义。比如某个模型虽然贵一点但输出格式稳定、几乎不需要清洗反而可能是综合成本更低的选择。延迟同样要结合场景。在线客服、Copilot 这类交互场景要求首 token 延迟低于 2 秒离线文档处理、日志分析则可以容忍 30 秒以上的长耗时。评测报告里不要只写平均值至少给出 P50 和 P95因为 P95 高说明在高峰期容易拖垮用户体验。5.3 用 LLM-as-Judge 做初筛人工评分准确但效率低当测试集从几十题扩展到几百题时可以引入 LLM-as-Judge 做初筛。也就是用另一个模型作为裁判对被测模型的答案按标准打分。但裁判模型不能和被测模型相同否则可能有系统性的偏袒或宽容。裁判 prompt 要写成明确的评分标准。JUDGE_PROMPT 你是一个严格的评测助手。请根据下面给出的参考答案对候选回答进行打分。 题目 {question} 参考答案 {reference_answer} 候选回答 {candidate_answer} 请从正确性、完整性、格式三个维度分别打分每个维度 1 到 5 分最后给出平均分。 只输出 JSON不要输出其他内容格式如下 {{correctness: 5, completeness: 4, format: 5, score: 4.7}} LLM-as-Judge 的缺点是需要额外消耗 token而且裁判模型本身会受 prompt 影响。所以通常只把它当作第一轮筛选分数接近的模型或争议较大的题目仍然需要人工复核。5.4 最终决策要回到业务场景模型对战跑完得到一大堆分数后最容易犯的错误是直接按总分数选模型。但业务场景从来不是单维的。如果是处理 50 万条历史工单批处理吞吐量和成本是第一优先级如果是做智能客服助手首 token 延迟和指令遵循是第一优先级如果是做代码生成插件代码正确率和格式稳定性是第一优先级。这张对比表可以辅助决策决策因素适合高权重适合低权重延迟敏感在线客服、Copilot、Prompt 链路中的中间节点离线批处理、日志分析成本敏感海量数据、高频调用低频管理类任务格式稳定性程序调用的模型、结构化输出场景人工阅读的写作辅助多轮记忆长会话 Agent、客服上下文单轮工具调用多模态图片审核、文档 OCR 场景纯文本场景把权重写进评分公式比直接比较平均分更有用。6. 模型对战节外生枝的典型坑6.1 参数没重置结果全部不可比现象第一轮测试用 temperature0 跑第二轮改代码后忘记调回来导致每个模型每轮答案都不一样分数波动很大。原因评测脚本在代码里写死了采样参数多次运行时没有回滚到统一配置。检查方式查看 JSONL 记录里是否包含 temperature 字段或者看同一题同一模型的多条记录输出是否差异过大。解决方式把 temperature 和 max_tokens 作为全局常量每次运行前打印当前配置结果表里增加 temperature 和 max_tokens 列方便回溯。6.2 max_tokens 太小代码题全部截断现象代码生成题里模型答案突然在函数中间断掉没有报错。原因max_tokens设为 500而模型要生成 800 token 的完整代码输出被强制截断。检查方式看输出 token 数是否经常等于max_tokens上限。如果是基本可以判断是截断。解决方式代码题和长文题单独提高max_tokens并增加“如果输出接近上限则任务失败”的判定。6.3 API 超时误判为模型能力差现象某个模型在多轮评测里频繁出现 120 秒超时分数表格里错误率很高。原因评测脚本统一使用 120 秒超时但某模型在高峰期响应特别慢或者某服务商对长输入任务处理时间本来就长。检查方式查看服务商状态页确认是否是平台限流或故障观察错误类型是 timeout 还是 connection reset。解决方式为每个模型单独配置超时时间把超时错误与普通错误区分开重试机制中增加指数退避而不是立即判定失败。6.4 system prompt 不一致结论失真现象模型 A 使用“你是专业助手”系统提示词模型 B 没有系统提示词结果模型 A 在格式和语气上分数更高。原因评测脚本里对不同模型使用了不同调用路径系统提示词没有统一。检查方式检查 JSONL 里的 prompt 是否完全一致如果 prompt 里拼接了系统提示词看是否每个模型都带了同一段。解决方式所有模型使用完全相同的 messages 列表系统提示词要么全部不加要么全部加相同内容。6.5 版本漂移昨天高分今天低分现象同一个模型 ID第一天评测分数很高过几天重跑发现明显下降。原因服务商可能在同一个模型 ID 下更新了内部版本或者在评测期间发生了服务降级。检查方式查看服务商文档中的模型版本号和更新日志对比两次评测的请求时间。解决方式评测时记录模型 ID、请求时间和服务商重要决策前在 24 小时内重新跑一轮核心题集不要用上周的结果做本周的决策。7. 把一次对战升级成长期评测机制7.1 测试集版本化避免评估口径漂移测试集会随业务变化不断修改如果改了题集又不记录版本那么新旧评测分数就没有可比性。推荐给测试集增加版本号每个版本的tasks.json打一个 tag 或复制一份快照。{ version: 2025-06-01, description: v1 核心题集包含数学、代码、中文、多模态四类, tasks: [...] }结果文件同样建议带上版本号例如results_2025-06-01.jsonl。这样任何时候回看一份数据都能知道用的是哪版题目、哪批模型、哪些参数。7.2 用 JSONL 和 CSV 双份归档JSONL 适合程序读取和增量写入但人工阅读不方便。跑完一轮后可以用脚本把 JSONL 转成 CSV再导出成 Excel 或在线表格进行评分。归档时两者都保留JSONL 是数据源CSV 是阅读视图。python summarize.py同时建议把MODELS配置、任务集版本、运行时间、API Key 环境变量名写进评测报告的开头。没有环境描述的评测数据可信度会打折扣因为别人无法判断结果是在什么条件下产生的。7.3 接入 CI 或定时任务做回归测试如果模型是产品的一部分应该在发布前自动跑一轮核心场景评测。可以把核心题集缩小到 10 道只覆盖最容易影响业务质量的关键场景。接入 CI 后每次改动 prompt、更换模型、调整参数都可以先跑一轮再决定是否上生产。定时任务则更适合监控模型线上表现。可以每天凌晨跑一轮核心题集把分数写入监控看板。当某天分数下降超过阈值时触发告警。这能提前发现服务商模型版本变化或服务降级避免用户先发现问题。7.4 发布前再跑一轮核心场景不要用旧分数模型版本更新频繁昨天评测的结果今天可能就失效。任何一次重要的模型替换或 prompt 调整都要在发布前 24 小时内重新跑一轮。哪怕只是测试集里 10 道核心题也能筛出大部分明显的回归问题。发布后保留当次评测结果作为回滚决策的参考依据。8. 最后说回“Kimi K3 真的能打吗”回到最初的问题Kimi K3 真的能打吗这个问题在看完一篇文章后无法得到准确答案因为模型能力高度依赖任务场景、调用方式、版本状态和主观需求。一个人说“能打”可能是因为它的长上下文处理满足了他所在场景另一个人说“不能打”可能是因为它在某类数学题上得分不稳定。两个人可能都对。真正有用的做法是把你自己的题目整理成测试集用本文这套流程跑一轮记录答案、延迟、token 和错误率。然后用你的业务权重去加权计算而不是简单比较总分。这里给出一份可以直接复用的对仗复验清单任何一次新模型上线前都可以按这个顺序过一遍确认被测模型 ID 和版本记录评测日期。统一 temperature、max_tokens、超时时间。准备至少 20 道锚点题和 10 道业务题。每个任务跑 3 次记录最佳、平均和波动。额外记录首 token 延迟、吞吐、错误率。检查 JSON 格式合法率尤其是程序调用场景。失败案例按错误类型分类不要只看总分。用业务权重计算综合评分结合成本给出推荐。保留 JSONL 原始结果和测试集版本号。24 小时内重新跑一轮核心题确认无版本漂移。模型对战的最终目的不是证明“谁更强”而是搞清楚“谁更适合我的场景”。把评测流程固定下来让每次模型换代都能快速得到结论这才是比单纯关注热搜排行更持久的技术能力。
大模型对战评测框架：从Kimi K3、Claude Fable到GPT 5.6
模型选型这件事最怕的不是没有选择而是选择太多。Kimi K3、Claude Fable、GPT 5.6 这几个名字在近期的技术讨论里热度很高很多人都在问“Kimi K3 真的能打”或者“Claude Fable 与 GPT 5.6 谁更聪明”但真正要回答这些问题靠几张截图和几条热搜词是不够的因为模型评测非常容易被 prompt 写法、采样参数、上下文长度、模型版本和任务类型影响。与其人云亦云不如建立一套最小可复现的模型对战框架把 Kimi K3、Claude Fable、GPT 5.6 放到同一起跑线上跑一轮用可验证的数据而不是印象流来下结论。需要先说明一点Kimi K3、Claude Fable、GPT 5.6 都属于迭代速度极快的模型代号本文不讨论这些名称背后的具体版本细节而是把它们当作“被测模型”来处理。实际接入时请把代码里的模型 ID 替换成对应服务商当前真正可用、文档里写清楚的 ID。评测流程本身才是这篇文章最有价值的产出因为模型会换代但公平评测的方法不会过时。1. 先搞清楚“真的能打”到底是什么指标1.1 能力谱系先从推理和代码开始模型对战最容易犯的错误是只比“谁的回答看起来有道理”。但“看起来有道理”既不能量化也不能复现更不能用来做技术决策。真实项目里判断一个模型能不能打第一层要看能力谱系也就是它能不能完成一类具体任务。能力谱系通常按这几类拆开数学推理、逻辑推理、代码生成、代码审查、长文本理解、多模态理解、指令遵循、中文表达。每一类都是独立的能力维度。一个模型可能在数学推理上很强但代码生成经常截断也可能代码能力优秀但中文长文档总结会丢失关键信息。这种差异直接决定了它适合放在哪个业务场景。评测时不要把多个维度混在一个 prompt 里。比如“请写一个 Python 快排并解释时间复杂度和空间复杂度然后给一个例子”这个问题同时考察代码生成、算法理解和表达组织一旦模型输出不完整你很难判断是代码能力弱还是解释能力弱。正确的做法是一个任务只测一个维度代码题只要求输出可运行的代码推理题只要求给出推导过程和最终答案。1.2 工程体验速度、吞吐和稳定性第二个维度经常被忽略模型再聪明如果 API 响应要等 1 分钟或者并发一高就限流生产环境根本用不了。工程体验包括首 token 延迟、吞吐量、上下文处理能力、API 稳定性、限流配额和错误率。首 token 延迟是用户能直接感知的指标。对聊天类和 Agent 类场景用户更在意“第一个字多久出现”而不是整段回复的总时长。对批量离线任务比如日志分类、文档摘要吞吐量更重要单位时间能处理多少条请求直接决定任务成本和人力。稳定性则要看连续请求的失败率、超时率、报错频率。这些指标很难通过一两道题测出来需要构造一批重复请求统计延迟分布和错误率。我在后面的批量评测脚本里会给出一个简易实现。1.3 成本模型单价只是起点成本是“能不能打”的硬约束。一个模型即使分数最高如果单次请求价格是其他模型的几倍吞吐又低那很多业务场景只能放弃。成本模型不能只看每百万 token 的单价还要看实际消耗。同一个任务有的模型要用更多输出 token 才能表达清楚有的模型会反复解释冗余内容长上下文任务里输入 token 的消耗往往占大头这时候上下文长度和计费方式就非常重要。更隐蔽的成本出现在重试和人工修正上。如果模型输出 5 次里有一次 JSON 格式错误程序就得重试或人工修复这部分隐性成本很难从 API 账单里直接看出来但会显著抬升真实成本。所以评测里不仅要记 token 数还要记录格式合法率、重试次数、人工介入次数。1.4 评测公平性参数、版本和 prompt 必须一致模型对战的底线是公平。很多评测翻车不是因为模型差而是因为控制变量没做好。同一个问题temperature 一个设 0一个设 0.7结果完全不可比同一个模型昨天用的版本和今天的版本不一样结果也会漂移一个模型用长系统提示词另一个模型只用一句话这也不公平。公平评测至少要做到同一套 prompt、同一组采样参数、同一个最大输出长度、同一轮上下文信息、相同次数的重复采样。模型 ID 要固定不能今天用正式版明天用预览版否则结果无法追溯。所有请求参数都要写入日志这才有复盘价值。2. 搭建模型对战环境让三个模型可以被同一套代码调用2.1 基础环境准备开始写代码之前先准备好 Python 环境和依赖。建议使用 Python 3.10 以上版本并创建虚拟环境避免依赖冲突。mkdir llm-battle cd llm-battle python -m venv venv source venv/bin/activate pip install httpx这里只引入 httpx 一个核心依赖用来发送异步 HTTP 请求。不引入大型 SDK是因为不同模型厂商的 SDK 版本差异会影响参数行为统一走 HTTP 接口反而更容易控制参数。如果你的服务商只提供 SDK 方式也可以保留 SDK但一定要固定版本并在评测报告里写清楚。还需要准备环境变量文件把 API Key 放在环境变量里不要写进代码或提交到仓库。export KIMI_API_KEYyour_kimi_key_here export CLAUDE_FABLE_API_KEYyour_claude_key_here export GPT56_API_KEYyour_gpt_key_here2.2 用一个统一接口接住不同厂商的模型不同模型厂商的接口格式可能不同但大部分都提供 OpenAI 兼容接口也就是POST /chat/completions请求体里包含model、messages、temperature、max_tokens。为了让三个模型可以共用一套评测逻辑我先定义一个统一的数据结构然后在代码里做一次转换。# model_client.py import os import time import httpx from dataclasses import dataclass, asdict from typing import List, Optional dataclass class ChatMessage: role: str content: str dataclass class ModelResponse: model: str task_id: str answer: str elapsed_sec: float input_tokens: int output_tokens: int error: str MODELS { kimi-k3: { base_url: REPLACE_WITH_KIMI_BASE_URL, api_key_env: KIMI_API_KEY, model_id: REPLACE_WITH_KIMI_MODEL_ID, }, claude-fable: { base_url: REPLACE_WITH_CLAUDE_BASE_URL, api_key_env: CLAUDE_FABLE_API_KEY, model_id: REPLACE_WITH_CLAUDE_MODEL_ID, }, gpt-5.6: { base_url: REPLACE_WITH_GPT_BASE_URL, api_key_env: GPT56_API_KEY, model_id: REPLACE_WITH_GPT_MODEL_ID, }, } async def call_model(model_name: str, messages: List[ChatMessage], temperature: float, max_tokens: int): config MODELS[model_name] headers { Authorization: fBearer {os.environ[config[api_key_env]]}, Content-Type: application/json, } payload { model: config[model_id], messages: [asdict(m) for m in messages], temperature: temperature, max_tokens: max_tokens, } start time.time() async with httpx.AsyncClient(timeout120) as client: try: resp await client.post( f{config[base_url]}/chat/completions, headersheaders, jsonpayload, ) elapsed time.time() - start if resp.status_code ! 200: return ModelResponse( modelmodel_name, task_id, answer, elapsed_secelapsed, input_tokens0, output_tokens0, errorfHTTP {resp.status_code}: {resp.text[:500]} ) data resp.json() content data[choices][0][message][content] usage data.get(usage, {}) return ModelResponse( modelmodel_name, task_id, answercontent, elapsed_secelapsed, input_tokensusage.get(prompt_tokens, 0), output_tokensusage.get(completion_tokens, 0), error ) except Exception as e: elapsed time.time() - start return ModelResponse( modelmodel_name, task_id, answer, elapsed_secelapsed, input_tokens0, output_tokens0, errorstr(e) )这段代码有几个关键点。MODELS字典把三个模型的服务地址、环境变量名、模型 ID 都收拢到一处后续跑题集时只需要传model_name。base_url和model_id必须根据各家最新文档替换不能照抄占位符。响应里不仅记录答案还记录延迟和 token 消耗这些字段在后面的成本分析里会用到。还要注意有的模型服务商接口使用的是max_completion_tokens而不是max_tokens有的是/v1/messages而不是/chat/completions。如果遇到 400 参数错误第一步就是检查参数名和 endpoint 是否匹配不要急着怀疑模型能力。2.3 记录请求参数保证后续可比评测过程中所有请求参数都必须落盘。光有答案没有参数等于没有评测。最简单的做法是写一个append_result函数把每次请求的模型名、题号、温度、最大 token、答案、延迟、token 用量和错误信息追加到 JSONL 文件里。# runner.py import json import asyncio from model_client import call_model, ChatMessage, ModelResponse RESULTS_FILE results.jsonl def save_to_jsonl(task_id: str, model: str, prompt: str, response: ModelResponse): record { task_id: task_id, model: model, prompt: prompt, answer: response.answer, elapsed_sec: round(response.elapsed_sec, 2), input_tokens: response.input_tokens, output_tokens: response.output_tokens, error: response.error, } with open(RESULTS_FILE, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)为什么用 JSONL 而不是 JSON因为评测任务会持续追加JSONL 每行一条记录方便增量写入也方便用pandas或命令行工具按行读取不需要在每次追加时把整个文件读进内存。后续做统计时过滤出模型名和题号即可。2.4 本地部署模型的额外控制点如果某个模型是本地部署比如通过 vLLM、Ollama、llama.cpp 暴露服务评测环境和云 API 不同需要额外控制几个变量量化精度是 FP16、INT8 还是 INT4推理框架是 vLLM 还是 Transformers显卡型号和显存大小并发数以及 KV Cache 策略。这些因素都会影响输出质量和延迟所以本地模型的评测结果只能代表“当前这台机器、当前这个推理框架下的表现”不能代表模型本身的全部能力。如果要在评测报告里同时对比云 API 模型和本地部署模型建议在结果表里额外增加一列“部署方式”否则很容易拿着本地部署的量化模型分数去质疑云端原版模型这是不公平的。3. 设计一套公平的对战题集3.1 测试集要覆盖业务真实场景对战题集的质量直接决定评测结果是否可信。理想测试集不是从网上随便找 10 道题而是从你的业务场景里抽取真实任务再加上一批已经确定答案的标准题作为“锚点”。标准题用来验证模型的基础能力答案应该是确定的。比如“计算 7 的 8 次方”“用 Python 写一个二分查找”“把一段中文翻译成英文”。这类题目方便快速判断模型是否在线、是否具备基本能力。业务题用来验证实际可用性比如“根据这个支付订单日志找出退款异常的原因”“把这段用户投诉内容分类并给出回复策略”。业务题没有唯一答案需要结合领域知识评分。测试集建议按 JSON 格式维护每个任务包含task_id、category、prompt、reference_answer、judge_type五个字段。{ tasks: [ { task_id: reasoning_001, category: math, prompt: 一个水池有一个进水管和一个出水管。单独打开进水管 3 小时注满水池单独打开出水管 4 小时放空水池。如果两个水管同时打开多少小时可以注满水池要求给出推导过程和最终答案。, reference_answer: 12 小时, judge_type: exact_match }, { task_id: code_001, category: code, prompt: 用 Python 写一个函数输入整数列表返回列表中第二大的数。如果列表长度小于 2返回 None。只输出代码不要解释。, reference_answer: , judge_type: code_check }, { task_id: chinese_001, category: chinese, prompt: 把下面这段产品介绍改写成适合电商详情页的中文文案要求保留所有卖点总字数不超过 150 字……, reference_answer: , judge_type: human_score } ] }judge_type决定了评分方式。exact_match是看答案是否与参考答案一致适合数学题、选择题code_check是运行或审查代码适合编程题human_score是人工按 1 到 5 分打分适合开放型写作、总结、翻译题。3.2 Prompt 写法不能偏向某个模型同一个任务prompt 写法会显著影响结果。如果对某个模型使用英文 prompt对另一个模型使用中文 prompt天然不公平。推荐所有 prompt 使用同一套语言并且在撰写时不带倾向性。这里有一条容易被忽略的原则不要在 prompt 里泄漏目标模型的名称。比如“作为 Kimi K3请回答”这种写法没有任何评测价值。对战评测的 prompt 应当是中性的工作任务描述只告诉模型要做什么、输出什么格式、有哪些限制不暗示身份。构造 prompt 时还建议统一加上输出格式要求。比如“只输出 JSON”“分点列出答案”“先给结论再给理由”。这样可以观察模型的格式遵循能力也方便后续自动化判断。但要注意格式要求本身也是一种能力测试不要所有题目都加否则会掩盖模型在某些场景下的真实表现。3.3 每题跑多次看分布而不是单次结果大模型输出具有随机性。同一个模型、同一个 prompt温度大于 0 时每次回答都可能不同。如果每个题目只跑一次就下结论可能会因为一道题的运气而误判模型。推荐每个任务至少跑 3 到 5 次温度设置为 0.2 到 0.3。这样既能保留一定多样性又不会太随机。分数统计时既记录最佳分数也记录平均分数和标准差。标准差很大说明稳定性差这在生产环境里是严重问题因为稳定可控比偶尔聪明更重要。重复采样会带来成本所以测试集不要盲目做大。建议核心锚点题 20 道业务题 15 道每个模型跑 3 次也就是每轮对战约 105 次请求。这个量级在大多数模型服务商的试用配额之内完成一轮基本够用。4. 跑一轮真实对战并记录结果4.1 单题盲测脚本单题盲测适合观察模型在某个具体任务上的表现。下面这个脚本会读取测试集里的某一题依次发给三个模型把原始输出打印出来。# run_single_task.py import asyncio from model_client import call_model, ChatMessage from runner import save_to_jsonl PROMPT 一个水池有一个进水管和一个出水管。单独打开进水管 3 小时注满水池单独打开出水管 4 小时放空水池。如果两个水管同时打开多少小时可以注满水池要求给出推导过程和最终答案。 async def main(): for model in [kimi-k3, claude-fable, gpt-5.6]: messages [ChatMessage(roleuser, contentPROMPT)] resp await call_model(model, messages, temperature0.2, max_tokens1000) print(f {model} ) print(resp.answer) print(f延迟: {resp.elapsed_sec:.2f}s, 输入token: {resp.input_tokens}, 输出token: {resp.output_tokens}) save_to_jsonl(reasoning_001, model, PROMPT, resp) asyncio.run(main())注意这个脚本是串行请求三个模型。在实际对战中如果有一个模型 API 超时或限流后面的模型也会被阻塞。建议后续改成并发调用每个模型独立超时互不影响。并发脚本见下一节。4.2 批量评测脚本批量评测要解决三个问题按测试集循环、控制并发、把结果落盘。下面这个脚本用asyncio.Semaphore控制最大并发数避免一次性打爆某个模型服务商的配额。# run_battle.py import asyncio import json import random from model_client import call_model, ChatMessage from runner import save_to_jsonl MODELS [kimi-k3, claude-fable, gpt-5.6] CONCURRENCY 5 TEMPERATURE 0.2 MAX_TOKENS 2000 RUNS_PER_TASK 3 async def run_one(task: dict, model: str, run_index: int): messages [ChatMessage(roleuser, contenttask[prompt])] resp await call_model(model, messages, TEMPERATURE, MAX_TOKENS) task_id f{task[task_id]}_run{run_index} save_to_jsonl(task_id, model, task[prompt], resp) print(f[{task_id}] {model} 完成耗时 {resp.elapsed_sec:.2f}s) if resp.error: print(f[{task_id}] {model} 错误: {resp.error}) async def main(): with open(tasks.json, r, encodingutf-8) as f: tasks json.load(f)[tasks] random.seed(42) jobs [] for task in tasks: for i in range(RUNS_PER_TASK): for model in MODELS: jobs.append((task, model, i)) random.shuffle(jobs) semaphore asyncio.Semaphore(CONCURRENCY) async def worker(task, model, i): async with semaphore: await run_one(task, model, i) await asyncio.gather(*[worker(t, m, i) for t, m, i in jobs]) if __name__ __main__: asyncio.run(main())这个脚本有几个设计点。random.seed(42)固定随机种子虽然不一定影响模型输出但能让评测记录里的执行顺序可复现。random.shuffle(jobs)打乱任务顺序避免某个模型一直排在前面因为热点时段不同先跑和后跑的模型可能遇到不同的服务端负载。Semaphore控制并发为 5既能提速又不会把限流打出来。4.3 结果汇总和人工评分批量跑完后results.jsonl里已经积累了大量原始记录。下一步是汇总成一个适合评分和阅读的表格。可以使用 pandas 生成宽表每一行是一个任务每一列是一个模型在第一次运行时的答案摘要。# summarize.py import pandas as pd import json rows [] with open(results.jsonl, r, encodingutf-8) as f: for line in f: rows.append(json.loads(line)) df pd.DataFrame(rows) summary df.groupby([task_id, model]).agg( avg_elapsed_sec(elapsed_sec, mean), avg_input_tokens(input_tokens, mean), avg_output_tokens(output_tokens, mean), error_count(error, lambda x: (x ! ).sum()), ).reset_index() summary.to_csv(summary.csv, indexFalse, encodingutf-8-sig) print(summary.head(20))人工评分时建议把答案按题目聚合并导出成 markdown 表格然后对照参考标准逐题打分。4.4 结果表怎么读下面是一张状态较为理想的结果记录表用于说明格式不代表任何模型的真实性能。task_idmodelanswer摘要耗时(秒)input_tokensoutput_tokens错误reasoning_001_run0kimi-k3推导过程正确最终 12 小时8.2180120无reasoning_001_run0claude-fable推导过程正确最终 12 小时12.4190140无reasoning_001_run0gpt-5.6第一次答成 7 小时第二次自我修正15.1210260无code_001_run1kimi-k3输出完整可运行代码6.515090无code_001_run1claude-fable输出代码缺少边界检查9.8160110无code_001_run1gpt-5.6API 超时120.000timeout这张表告诉我们三个信息正确性、延迟、稳定性。观察一个模型不能只看第一题要看它在所有任务上的“平均分 失误率 最大延迟”。如果一个模型回答质量最高但超时严重它在实时交互场景中就不可用如果一个模型正确率稳定但从未有惊艳答案它在批量处理中反而更可靠。注意不要只验证程序能启动还要验证输出、延迟、token 和异常分支是否符合预期。评测脚本本身也可能有 bug第一次跑完后先抽几行 JSONL 人工核对不要直接拿数据写结论。5. 从对战数据中看模型差距5.1 正确率之外更要关注失败模式正确率是一个汇总数字但真正对技术决策有用的是失败模式。两个模型可能正确率都是 80%但一个模型的错误集中在数学推理一个模型的错误集中在代码输出截断这两者的应对策略完全不同。建议每轮评测结束后把失败案例单独提取出来按错误类型分类。常见错误类型包括计算错误、逻辑跳跃、代码语法错误、代码不完整、JSON 格式错误、拒答、上下文丢失、中文表达混乱、幻觉补充不可靠信息。每个类型背后对应不同的工程适配方案。比如代码不完整可以通过提高max_tokens缓解JSON 格式错误可以在 prompt 里加 few-shot 示例或在程序里增加重试和解析修复逻辑幻觉问题则要引入检索约束或降低温度。5.2 延迟和成本会让聪明打折扣假设模型 A 回答质量 90 分单次请求 3 元模型 B 质量 85 分单次请求 0.5 元但模型 B 需要额外写 500 行代码做输出清洗才能达到 88 分。这时候总成本反而是模型 B 更高因为不是模型本身贵而是“使用成本”贵。在评估结果表里建议额外增加一个“质量达标成本”列质量分除以单次成本。这个比值比单纯的质量分更有业务意义。比如某个模型虽然贵一点但输出格式稳定、几乎不需要清洗反而可能是综合成本更低的选择。延迟同样要结合场景。在线客服、Copilot 这类交互场景要求首 token 延迟低于 2 秒离线文档处理、日志分析则可以容忍 30 秒以上的长耗时。评测报告里不要只写平均值至少给出 P50 和 P95因为 P95 高说明在高峰期容易拖垮用户体验。5.3 用 LLM-as-Judge 做初筛人工评分准确但效率低当测试集从几十题扩展到几百题时可以引入 LLM-as-Judge 做初筛。也就是用另一个模型作为裁判对被测模型的答案按标准打分。但裁判模型不能和被测模型相同否则可能有系统性的偏袒或宽容。裁判 prompt 要写成明确的评分标准。JUDGE_PROMPT 你是一个严格的评测助手。请根据下面给出的参考答案对候选回答进行打分。 题目 {question} 参考答案 {reference_answer} 候选回答 {candidate_answer} 请从正确性、完整性、格式三个维度分别打分每个维度 1 到 5 分最后给出平均分。 只输出 JSON不要输出其他内容格式如下 {{correctness: 5, completeness: 4, format: 5, score: 4.7}} LLM-as-Judge 的缺点是需要额外消耗 token而且裁判模型本身会受 prompt 影响。所以通常只把它当作第一轮筛选分数接近的模型或争议较大的题目仍然需要人工复核。5.4 最终决策要回到业务场景模型对战跑完得到一大堆分数后最容易犯的错误是直接按总分数选模型。但业务场景从来不是单维的。如果是处理 50 万条历史工单批处理吞吐量和成本是第一优先级如果是做智能客服助手首 token 延迟和指令遵循是第一优先级如果是做代码生成插件代码正确率和格式稳定性是第一优先级。这张对比表可以辅助决策决策因素适合高权重适合低权重延迟敏感在线客服、Copilot、Prompt 链路中的中间节点离线批处理、日志分析成本敏感海量数据、高频调用低频管理类任务格式稳定性程序调用的模型、结构化输出场景人工阅读的写作辅助多轮记忆长会话 Agent、客服上下文单轮工具调用多模态图片审核、文档 OCR 场景纯文本场景把权重写进评分公式比直接比较平均分更有用。6. 模型对战节外生枝的典型坑6.1 参数没重置结果全部不可比现象第一轮测试用 temperature0 跑第二轮改代码后忘记调回来导致每个模型每轮答案都不一样分数波动很大。原因评测脚本在代码里写死了采样参数多次运行时没有回滚到统一配置。检查方式查看 JSONL 记录里是否包含 temperature 字段或者看同一题同一模型的多条记录输出是否差异过大。解决方式把 temperature 和 max_tokens 作为全局常量每次运行前打印当前配置结果表里增加 temperature 和 max_tokens 列方便回溯。6.2 max_tokens 太小代码题全部截断现象代码生成题里模型答案突然在函数中间断掉没有报错。原因max_tokens设为 500而模型要生成 800 token 的完整代码输出被强制截断。检查方式看输出 token 数是否经常等于max_tokens上限。如果是基本可以判断是截断。解决方式代码题和长文题单独提高max_tokens并增加“如果输出接近上限则任务失败”的判定。6.3 API 超时误判为模型能力差现象某个模型在多轮评测里频繁出现 120 秒超时分数表格里错误率很高。原因评测脚本统一使用 120 秒超时但某模型在高峰期响应特别慢或者某服务商对长输入任务处理时间本来就长。检查方式查看服务商状态页确认是否是平台限流或故障观察错误类型是 timeout 还是 connection reset。解决方式为每个模型单独配置超时时间把超时错误与普通错误区分开重试机制中增加指数退避而不是立即判定失败。6.4 system prompt 不一致结论失真现象模型 A 使用“你是专业助手”系统提示词模型 B 没有系统提示词结果模型 A 在格式和语气上分数更高。原因评测脚本里对不同模型使用了不同调用路径系统提示词没有统一。检查方式检查 JSONL 里的 prompt 是否完全一致如果 prompt 里拼接了系统提示词看是否每个模型都带了同一段。解决方式所有模型使用完全相同的 messages 列表系统提示词要么全部不加要么全部加相同内容。6.5 版本漂移昨天高分今天低分现象同一个模型 ID第一天评测分数很高过几天重跑发现明显下降。原因服务商可能在同一个模型 ID 下更新了内部版本或者在评测期间发生了服务降级。检查方式查看服务商文档中的模型版本号和更新日志对比两次评测的请求时间。解决方式评测时记录模型 ID、请求时间和服务商重要决策前在 24 小时内重新跑一轮核心题集不要用上周的结果做本周的决策。7. 把一次对战升级成长期评测机制7.1 测试集版本化避免评估口径漂移测试集会随业务变化不断修改如果改了题集又不记录版本那么新旧评测分数就没有可比性。推荐给测试集增加版本号每个版本的tasks.json打一个 tag 或复制一份快照。{ version: 2025-06-01, description: v1 核心题集包含数学、代码、中文、多模态四类, tasks: [...] }结果文件同样建议带上版本号例如results_2025-06-01.jsonl。这样任何时候回看一份数据都能知道用的是哪版题目、哪批模型、哪些参数。7.2 用 JSONL 和 CSV 双份归档JSONL 适合程序读取和增量写入但人工阅读不方便。跑完一轮后可以用脚本把 JSONL 转成 CSV再导出成 Excel 或在线表格进行评分。归档时两者都保留JSONL 是数据源CSV 是阅读视图。python summarize.py同时建议把MODELS配置、任务集版本、运行时间、API Key 环境变量名写进评测报告的开头。没有环境描述的评测数据可信度会打折扣因为别人无法判断结果是在什么条件下产生的。7.3 接入 CI 或定时任务做回归测试如果模型是产品的一部分应该在发布前自动跑一轮核心场景评测。可以把核心题集缩小到 10 道只覆盖最容易影响业务质量的关键场景。接入 CI 后每次改动 prompt、更换模型、调整参数都可以先跑一轮再决定是否上生产。定时任务则更适合监控模型线上表现。可以每天凌晨跑一轮核心题集把分数写入监控看板。当某天分数下降超过阈值时触发告警。这能提前发现服务商模型版本变化或服务降级避免用户先发现问题。7.4 发布前再跑一轮核心场景不要用旧分数模型版本更新频繁昨天评测的结果今天可能就失效。任何一次重要的模型替换或 prompt 调整都要在发布前 24 小时内重新跑一轮。哪怕只是测试集里 10 道核心题也能筛出大部分明显的回归问题。发布后保留当次评测结果作为回滚决策的参考依据。8. 最后说回“Kimi K3 真的能打吗”回到最初的问题Kimi K3 真的能打吗这个问题在看完一篇文章后无法得到准确答案因为模型能力高度依赖任务场景、调用方式、版本状态和主观需求。一个人说“能打”可能是因为它的长上下文处理满足了他所在场景另一个人说“不能打”可能是因为它在某类数学题上得分不稳定。两个人可能都对。真正有用的做法是把你自己的题目整理成测试集用本文这套流程跑一轮记录答案、延迟、token 和错误率。然后用你的业务权重去加权计算而不是简单比较总分。这里给出一份可以直接复用的对仗复验清单任何一次新模型上线前都可以按这个顺序过一遍确认被测模型 ID 和版本记录评测日期。统一 temperature、max_tokens、超时时间。准备至少 20 道锚点题和 10 道业务题。每个任务跑 3 次记录最佳、平均和波动。额外记录首 token 延迟、吞吐、错误率。检查 JSON 格式合法率尤其是程序调用场景。失败案例按错误类型分类不要只看总分。用业务权重计算综合评分结合成本给出推荐。保留 JSONL 原始结果和测试集版本号。24 小时内重新跑一轮核心题确认无版本漂移。模型对战的最终目的不是证明“谁更强”而是搞清楚“谁更适合我的场景”。把评测流程固定下来让每次模型换代都能快速得到结论这才是比单纯关注热搜排行更持久的技术能力。
