分清产品、模型与服务商
聊天网站是产品入口，模型是处理请求的系统，API 服务商负责提供访问。一个产品可能调用多个模型，一个模型也可能由不同服务商提供。记录完整模型 ID 与来源，不只写“用的是 GPT”或“用的是 Claude”。
费用入口可以在官方 API 价格监控查找原表，网页会员另见会员与 API 的区别。
建立自己的任务样本
挑选十几条典型输入，包含正常情况、信息缺失、长文本和错误格式。提前写出可接受结果与不能出现的错误。写作、编程、分类和检索需要不同验收标准。
对每个候选保留输入、参数、输出和人工评分，不把一次表现最好当成整体最好。
上下文与输出限制
上下文包含输入、对话历史、工具内容及相关开销，具体计算取决于模型。长上下文支持不代表放入大量无关内容就能提高效果。先提供必要资料，再测试检索或分段处理。
本地运行涉及量化时，可查Hugging Face 量化文档理解方法差异，不能只用参数量推算实际运行质量。
协议兼容如何验证
用模型一致性检测检查结构化输出、响应标签和工具调用，再用API 测速观察耗时与失败。兼容检查能找到线索，但不能证明中转站背后一定使用了某个真实模型。
需要比较不同服务商时，保持模型 ID、参数、输入和测试网络一致。
最终选择看总成本
把输入、输出、缓存、重试、检索与人工复核算在一起。便宜的单价如果带来很多失败和返工，未必便宜。可以使用Token 费用计算器做清楚标注假设的预算，再用真实账单修正。