1. 文本生成模型选型，为什么总是"看着都行，一用就废"

1.1 榜单分数的陷阱：高分模型未必适配你的业务

先聊一个很常见的现象：打开评测榜单，头部模型的分数差距往往不到一两个点，看起来都差不多。于是很多团队就按排行榜"从高到低"直接选，结果上线第一周就出问题。

问题出在评测集和你的业务数据根本不是一回事。通用评测考察的是知识问答、推理、代码生成，而你的业务可能是客服话术、法律文书摘要、短视频脚本，这些场景里的表达习惯、术语体系、结构化要求，通用评测不会替你丈量。一个在问答评测里表现很好的模型，可能在几十轮长对话后开始逻辑漂移；一个在英文场景下流畅的模型，可能在中文古文、方言、行业黑话面前束手无策。

我自己的习惯是：拿到候选模型后，先不听宣传，不看榜单，直接跑"业务复刻测试"。方式是拿过去三个月里真实业务的脱敏数据，抽出 50~100 条典型样本，做成固定prompt集，让每个候选模型都跑一遍，再按维度打分。这个测试虽然原始，但比任何第三方榜单都更能说明问题。

1.2 我的三把尺子：质量、速度、成本

与客户和内部研发讨论得多了，我慢慢把选型标准收敛成三个硬指标：

• 生成质量：语义连贯性、指令遵循度、知识准确性，以及业务场景的适配度
• 推理速度：首token时延、生成吞吐量、并发稳定性
• 成本效益：单位token价格、隐藏开销、总体拥有成本

三把尺子缺一不可。质量差，产品没法用；速度慢，流量上来后体验崩塌；成本高，业务跑起来没利润。而能同时在这三方面给出稳定表现的平台，才是值得进入终选的平台。

这次重点看的是"云曦"这家平台。它来自某综合性云厂商，属于厂商自研的大模型开放平台，支持多种规模的文本生成模型，也提供推理、微调、部署等配套能力。为什么拿它做样本？因为在过去一段时间里，好几个项目同时选了它做主线模型，我手头积累了不少真实调用数据和踩坑记录，正好借这个机会把其中的判断逻辑整理出来。

2. 硬指标一：生成质量——不是分数高就好，而是贴合业务才算好

2.1 质量拆解成四个可量化的子维度

我把生成质量拆成四件事：

第一是语义连贯性。长文本生成尤其考这一点，模型能不能在主题不变的前提下保持逻辑递进，而不是写到最后不知所云。第二是指令遵循度。给模型一段任务说明外加若干约束条件，它能不能全部落实，比如"不超过200字"就真的不超，而不是超到260字。第三是知识准确性。涉及实体、数字、日期、引文等信息，模型会不会一本正经地编造。第四是创造性控制。创意写作、营销文案、剧本生成，模型能不能在风格一致的前提下给出有变化的输出，而不是每次都像复读机。

这四个维度无法用一个综合benchmark分数概括。一个模型可能知识准确性很高，但指令遵循稀烂；另一个模型创造力很强，但长文本写到中段就开始重复。所以我在选型时从来不问"这个模型多少分"，而是问"这个模型在这四件事上分别什么表现，是否能满足我的核心业务场景"。

2.2 我的"业务复刻测试"怎么设计和打分

这里分享一下我的具体做法。假设要搭建一个电商客服场景的自动应答系统，我会构造 50 条高仿真客户对话记录，类型覆盖售前咨询、售后退换、物流查询、投诉升级，然后给每个模型固定同一套提示词模板，要求输出包含安抚话术、解决方案、风险提示三个部分。

评分采用 1~5 分制，每个维度单独打分，最后按业务权重加权。比如售后场景里，知识准确性和指令遵循各占 35%，语义连贯性占 20%，创造性占 10%。这样的权重设计，是为了让分数反映真实业务需要，而不是实验室里的平均能力。

做完这一套测试之后，不同模型的差异会非常明显。有的模型前半段很好，后半段开始答非所问；有的模型回复很漂亮，但没有遵循"先安抚再给方案"的结构要求；还有的模型稳定是稳定，只是输出像复读机，每次话术几乎一模一样，客户一眼就能看出是机器人。

2.3 云曦在质量维度上的实际表现

拿云曦来做同样的测试，结果是：中规中矩之上，偶尔有惊喜。它的中文语义连贯性在长文本场景里表现比较稳定，比如生成 1000 字左右的行业分析报告，段落之间的逻辑衔接比较顺，很少出现中间跑题、结尾接不上的问题。指令遵循能力属于第一梯队，带约束条件的prompt基本能严格执行，这个特点在客服、行政文书等规范化场景里很值钱。

值得说明的是，知识准确性受模型版本影响较大。云曦平台把不同规模的模型分成了多个版本，参数规格大的版本在知识问答类任务上明显更强，但推理成本也更高。如果你的业务以事实问答为主，建议直接选大规格版本，别为了省成本选轻量版，否则幻觉问题会消耗你大量返工时间。

我在实际项目里的评分结果大概是这样（数值是我个人测试集上的记录，只反映当时版本）：

表格里的差距很直观：如果你的业务只是做结构化摘要，标准版已经够用；但要拿它做知识密集型问答，还是得上大规格版本。这个"按需选规格"的意识，比单纯看平台名称重要得多。

3. 硬指标二：推理速度与并发稳定性——用户流失往往发生在等待的三秒里

3.1 首token时延、生成吞吐量、并发错误率，到底测得是什么

聊质量标准的时候大家都还比较淡定，一聊到速度，做过线上系统的开发基本都会心头一紧。文本生成模型的"慢"和传统接口的"慢"完全不是一个量级，传统接口可能是几百毫秒，文本生成是按秒算的，首token可能就要一两秒，生成几百字可能耗时几十秒。

所以我不建议只盯着一个"平均响应时间"看，必须拆开看三个具体指标：

首token时延（TTFT）：从发出请求到收到第一个输出token的时间。这个时间决定用户的第一感知，对话式场景尤其敏感，超过3秒用户就会觉得卡。

生成吞吐量：每秒输出多少个token（tokens/s）。这个决定长文本任务的完成时间，文档摘要、批量写作等场景非常依赖它。

并发稳定性：在多个请求同时打进来的时候，平台的时延和错误率是否会急剧恶化。这个最容易被Demo阶段忽略，因为测试时往往只有一个请求，线上却有成百上千个并发调用。

3.2 我自己执行的压测方案和代码

压测我没有用复杂的平台工具，直接抓了一个开源的压测脚本，稍做改动就够用。核心思路是：模拟不同并发数，持续发送文本生成请求，记录TTFT、生成速率、错误率三个数据。

下面是简化的思路，你可以参考：

import asyncio import time from statistics import mean async def single_request(sem, task_id, payload): async with sem: start = time.time() # 替换成真实的模型调用接口 response = await call_model(payload) ttft = response.first_token_time - start tokens = response.total_tokens duration = response.finish_time - start return { "task_id": task_id, "ttft": ttft, "tps": tokens / duration, "ok": True, } async def run_load_test(concurrency, total_requests, payload): sem = asyncio.Semaphore(concurrency) tasks = [single_request(sem, i, payload) for i in range(total_requests)] results = await asyncio.gather(*tasks, return_exceptions=True) ok_results = [r for r in results if isinstance(r, dict)] error_count = total_requests - len(ok_results) avg_ttft = mean([r["ttft"] for r in ok_results]) avg_tps = mean([r["tps"] for r in ok_results]) return {"ok": ok_results, "error_rate": error_count / total_requests, "avg_ttft": avg_ttft, "avg_tps": avg_tps}

实际执行时，我会跑三组：并发1、并发20、并发100，每组连续发200个请求，取平均值。这样既能看出单请求的极限速度，也能看出平台在压力下的表现。

这里有个容易踩的坑：压测时一定要设置合理的超时时间，有些模型接口在排队严重时返回很慢，如果不设超时，压测进程会卡死，统计出来的数据也会被拖跨。我一般把单请求超时设置为60秒，超过就直接记为失败。

3.3 云曦平台的速度实测与观察

在相同测试条件下，云曦平台的表现可以总结为一句：单路快，多路稳。单请求场景下，首token时延基本能控制在1秒左右，长的复杂prompt会慢一些，但整体体感不错。并发20时，平均TTFT大约上升0.3~0.6秒，错误率接近于零，说明平台有比较充足的算力缓冲。

并发100是一个分水岭。这个并发量对于大多数中小业务来说已经算是流量高峰了，云曦在这个压力下平均TTFT会到3秒上下，生成吞吐量下降大约四成，但几乎没有请求失败，整体表现属于可接受范围。如果你的业务会经常超过100并发，建议提前开通弹性资源池，或者做好请求队列本地缓存，避免把压力全部堆积到模型接口上。

这一点我特别想强调：很多人选模型只看生成质量，忽略了并发场景下的表现。实际上模型再聪明，如果高峰期接口大面积超时，你的产品口碑一样会崩。所以压测步骤绝对不能省，并且要把"错误率"作为一票否决项——一个错误率超过5%的平台，哪怕再便宜、质量再高，我也不建议作为线上主用。

4. 硬指标三：成本效益——别被单价吸引，要看总账

4.1 单位价格拆解：输入token、输出token、缓存token

文本生成模型的计费方式通常不是一口价，而是按token计费。token可以粗略理解为"模型处理的最小文本单位"，一个中文字大约对应1~2个token。大多数平台会区分输入token和输出token定价，因为生成逻辑决定了输出token的计算成本更高。

云曦的计费逻辑也类似，不同版本模型的单价不同，规格越大单价越高。粗略对比下来，它的标准版本价格处在市场中间位置，不便宜，但考虑到实际生成质量，性价比并不差。大规格版本则要贵不少，适合对质量有硬要求的业务。

另外很多平台提供了缓存token优惠，也就是把重复使用的prompt前缀缓存起来，后续请求命中缓存的部分可以打折甚至免费。这个政策对客服、查档、固定模板类业务非常有用，因为这类业务的prompt前缀几乎是固定的，缓存命中率能到八成以上，成本节省十分可观。

4.2 隐藏成本：重试、返工、迁移、维护，每一项都在掏钱

只看单价是选型中最典型的误区。我见过不止一个团队，被某平台的低价吸引上线，结果因为模型经常生成不合规的文案，又要对每个输出做二次审核，人工成本远比省下来的token费用高。

隐藏成本大概有四类：

• 重试成本：模型出现掉线、超时、服务不可用时，业务系统要重发请求，多出来的调用量都是钱
• 返工成本：输出质量不稳定，开发或运营需要人工矫正，这部分人力成本很难量化，但往往最大
• 迁移成本：从A平台切到B平台，prompt要重写，测试要重跑，如果之前做了大量prompt调优，搬家成本可能相当于半个项目预算
• 运维成本：日志采集、错误监控、成本账单分析，这些配套如果平台没有现成能力，都要自己搭

所以在比价之前，我会先做一个"总拥有成本"估算，公式很简单：

总成本 = 预计调用量 × 实际单价 + 集成开发人力成本 + 维护成本 + 返工概率带来的风险成本

4.3 我给云曦做的成本模型示例

用一个真实规模的例子来说明。假设一个内容生成业务，每月调用500万次，平均每次消耗输入token 1200个、输出token 600个（这是一次中等长度生成的典型消耗）。按云曦标准版本的公开报价估算，月费用大概在几万元区间，具体数字取决于折扣和资源包。

如果把同样的量放到大规格版本上，费用会上升到前者的2.5倍左右。但与此同时，大规格版本的知识准确性提升带来了返工率的下降，如果返工率能从8%降到3%，人力成本省下来的钱，可能比差价还多。

我的建议是：不要用"默认最大模型"作为生产配置，而是根据任务复杂度做分层。简单任务走轻量版，复杂任务走大规格版本，中间档走标准版。云曦的平台支持按需切换模型规格，这给分层调用留了很大的空间。用这种策略，我在多个项目里都把单位生成成本压低了20%~30%，同时没有牺牲业务质量。

5. 综合评分与横向对比——三个指标加在一起，云曦处在什么位置

5.1 一个简单的综合评分框架

三个硬指标各有权重，具体怎么分，取决于业务类型。我给自己的项目设了一个参考权重：质量40%、速度30%、成本30%。这个权重适合交互式产品，如果是批量文本生产，成本的权重可以提到40%，速度降为20%。

打分的时候不要只打整体分，三个维度分开打，最后加权。我习惯用十分制，质量方面把业务复刻测试的加权结果映射到十分制，速度把压测数据与其他候选平台对比后打分，成本则按总拥有成本的相对高低打分。

5.2 云曦与其他候选平台的对比记录

这一年多里，我实际对比过三四个平台，为了便于说明，这里用代号表示。云曦的总体印象是：没有明显短板，且稳定性突出。

这个表是根据我手头项目的真实需求设置的权重算出来的，换一个业务场景，排名完全可能反过来。平台A的质量分很高，但速度短板明显，直播互动类业务就不能选它；平台B便宜又快，但在长文本质量和稳定性上不够，金融报告这类对措辞严谨度要求高的业务就得谨慎评估。

云曦在表里的特点是均衡。它在质量、速度、成本三项上都处于中等偏上，稳定性则是最突出的，过去一年我几乎没有遇到因为平台本身导致的大规模服务中断。这个特点决定了它非常适合作为"业务主线模型"使用——你不会因为它某个单点优势而惊喜，但也不会因为它某个短板而踩坑。

5.3 除了三指标，我还会再看的两件软事

三个硬指标之外，我还会花半天了解一下平台的配套生态，这里简单带过。

一是API稳定性与文档质量。接口鉴权是否简单、限流策略是否清晰、错误码是否可读，这些细节决定了接入时是顺滑还是折磨。云曦在这块的体验是合格的，文档更新也比较及时，新模型版本的切换有迁移指南，不需要开发自己去猜。

二是模型版本迭代路径是否清晰。文本生成模型更新很快，平台有没有稳定的版本治理策略，直接影响你后续的升级成本。云曦的做法是保留旧版本一段时间，同时提供新旧版本的对比测试入口，这个设计对生产系统友好很多。真实的模型选型从来不是一次性的决策，而是持续评估的动态过程。

6. 落地建议：怎么把三个硬指标用在自己的选型里

6.1 一张决策清单，照着做就不容易翻车

如果你现在正好在选文本生成模型，我建议你按下面这个流程走，不需要复杂的理论，但每一步都不要跳过：

1. 先写下你的核心业务场景，最多写三个，别贪多
2. 针对每个场景准备50条左右的真实业务测试样本
3. 定下三个硬指标的权重，给每个候选平台跑一轮业务复刻测试
4. 对测试结果不错的两三家平台做压测，把并发数据拿到手
5. 用真实调用量估算总拥有成本，而不是只比单价
6. 做一个小范围灰度上线，观察一周的真实数据再决定主线平台

这套流程看起来繁琐，实际执行下来也就一到两周。比起上线后再因为模型能力不足而重构，这点前置成本非常划算。

6.2 两个我在项目里反复验证的技巧

第一个技巧是"双平台冷备"。文本生成模型再稳定，也存在服务降级的可能，所以对核心业务，我通常会在主平台之外留一个备选平台账号，平时不用，但保持最低限度的调用。一旦主平台出问题，可以在一小时内切换过去，而不是干等平台恢复。这种保险不会增加太多成本，但能显著降低业务中断风险。

第二个技巧是"分层调用"。不要所有请求都打同一个模型版本，要按任务难度分流。简单指令、模板生成、固定格式输出走轻量版；需要理解的、需要推理的、需要创造性的内容走大规格版本。这个策略做好了，成本能省下两成以上，而且用户体验并不会变差。

6.3 最后说点个人体会

做了那么多轮模型选型，最大的感受是：文本生成模型推荐哪家这个问题，其实不存在标准答案。每个业务都是一套不同的约束条件集，而所谓核心竞争力的判断，就是看平台能不能在你的约束条件下做到质量、速度、成本三者均衡。如果你的团队正准备选型，别急着让某个平台的名字进入讨论，先把你自己的三把尺子立起来，再拿尺子去量它们。量完你会发现，曾经纠结的"哪家更好"，往往会变成"哪家更适合我"，而后者才是真正能被落地验证的问题。

我在实际项目中验证下来，云曦这类稳定均衡的平台，适合绝大多数文档生成、对话助手、内容摘要类业务作为主用选项；但如果你的业务存在极端的单点需求，比如对延迟零容忍，或者对生成质量极其挑剔，那么"按指标选型"永远比"按名字选型"靠谱得多。这就是我今天想分享的全部内容，希望对正在做选型的你有一点帮助。