kimi-k3-1 与 kimi-k3：字符串不同不等于上游身份已证实
本站新增调用代号是 kimi-k3-1。2026-10-17 核对的官方价格及快速开始资料仍使用 kimi-k3。两个请求字符串不同，但这不足以判断它们是否映射同一上游；本文不把渠道展示名当成独立官方版本证明。
先在当前账号控制台确认可用代号，再发最小请求。模型列表只能证明账号可见性，响应的 model 字段也只是网关返回的元数据；要核实实际路由，需要渠道说明或可追溯日志，而不是让模型自报身份。
| 证据 | 能说明什么 | 不能说明什么 |
|---|---|---|
| 官方 K3 文档 | kimi-k3 的公开规格与接口约定 | K3.1 自动继承全部能力 |
| 账号模型列表 | 当前 Key 可见的请求 ID | 所有套餐均可用、上游身份 |
| 脱敏响应与账单 | 一次请求的字段、消耗与扣费 | 未来固定价格或长期质量 |
Kimi K3.1 价格：先分清示例与报价
官方 kimi-k3 当前公开价为每百万 tokens：未命中输入 ¥20、命中输入 ¥2、输出 ¥100。按本站国产渠道 0.2x 做K3 家族预算演算，未命中输入 / 输出为 ¥4 / ¥20；这不是已核实的 K3.1 独立官价或账号报价。
例如 20,000 输入、4,000 输出，未命中缓存的演算是 0.02 × 4 + 0.004 × 20 = ¥0.16。推理消耗、缓存写入、重试或渠道计费规则都会改变结果；计算只用于检查量级，不是扣费承诺。
先从控制台记下币种、计价单位、倍率、缓存读写规则和生效日期。保留同一次请求的 usage、请求编号与账单差额，不要把人民币和美元、上游目录价与站内扣费混算。旧 Kimi K3 模型页的渠道目录数字不应自动套用到 K3.1。
最小调用
from openai import OpenAI
client = OpenAI(base_url="https://www.codex789.com/v1", api_key="YOUR_KEY")
resp = client.chat.completions.create(
model="kimi-k3-1",
messages=[{"role": "user", "content": "计算 17 + 25，只返回结果。"}],
)
print(resp.model)
print(resp.usage)
print(getattr(resp.choices[0].message, "reasoning_content", None))该示例仅验证一次基础文本请求，不验证上游身份，也不证明工具调用可用。生产 Key 放在环境变量，勿提交代码或粘贴到公开日志；请求前先设置账号消费上限。多轮字段如何保留需按实际接口约定验收，不能假设兼容网关完整透传原生对象。
思考模式会改变账单形态
官方 K3 始终开启思考，并可用 reasoning_effort 的 low / high / max，默认 max。流式响应里 reasoning 走 reasoning_content，最终答案走 content。如果应用只渲染 content，用户会觉得“没在思考”，但 usage 仍可能包含推理 tokens。
kimi-k3-1 是否完整继承这些字段，需要用上面的最小请求验证。未验证前，不要把 max effort 写成默认生产配置。
和 kimi-k3、K2.7 Code 怎么选
| 需求 | 先试 | 不要做的事 |
|---|---|---|
| 控制台已给 kimi-k3-1，要做新 ID 对照 | kimi-k3-1 | 不要假设和 kimi-k3 同价同能力 |
| 现有 kimi-k3 流水线已稳定 | 继续 kimi-k3，抽样对照 | 不要在重试里来回切换两个 ID |
| 预算敏感的代码补全 | K2.7 Code | 不要用 K3 系列单价去估 K2 任务 |
本文没有认证调用截图，也没有把未公布的独立官价写成已核实挂牌。
上线前验收：从一次成功到可用流水线
以下是待执行的测试方案，不是本站已经取得的实测成绩。使用脱敏输入，固定 Key 所属分组、提示词和重试规则，一项一项验收；基础文本通过后再增加能力，避免一次失败却不知道是哪个字段导致。
| 测试 | 通过条件 | 不通过如何处理 |
|---|---|---|
| 基础文本 | HTTP 成功、答案为 42、usage 可记录 | 检查 ID、权限、余额；不盲目重试 |
| 流式输出 | 能区分推理与最终文本，结束信号完整 | 保存脱敏事件类型，定位网关或客户端解析 |
| 多轮上下文 | 按接口允许的格式带回历史，第二轮保留约束 | 检查序列化及推理字段约定 |
| 工具调用 | 工具名、参数及调用 ID 正确，结果能接回 | 暂停 Agent 接入，不能仅凭 HTTP 200 判定通过 |
| 结构化结果 | 按应用 schema 解析，必填字段不缺失 | 区分提示词 JSON 与原生约束能力 |
| 长输入与费用 | 小步递增长度，关键证据可检索，账单可解释 | 不要直接拿 K3 的 1M 窗口做 K3.1 压测上限 |
建议表头：日期、请求 ID、请求模型、返回模型、输入 / 输出 tokens、缓存 tokens、耗时、结束原因、账单差额、测试是否通过、人工修复分钟。缺失字段标为“未返回”，不要记为零。只保存验证所需的脱敏数据，不公开用户输入。
错误分流、灰度与回退
401 / 403 先查 Key 和分组权限；404 查请求路径及模型 ID；400 查参数和消息结构；429 查额度或限流；5xx 或断流保留请求编号后再做有上限的重试。具体含义以网关错误体为准，重试前确认请求是否已生成或扣费，防止重复费用。
保留旧配置快照，先用离线任务对照，再按团队自定的小流量比例灰度。涉及工具的会话应保持模型与消息链一致；不要在同一工具循环里随机切换 K3 与 K3.1。失败率超过事先约定阈值、账单无法解释、权限不稳定，任一出现即暂停放量，恢复已验证配置。
本文由本站技术团队维护，本站提供商业接入服务。没有认证调用截图或独立 K3.1 官价证据；本文的价值是给出可复核的接入与账单检查方法，而非发布未经验证的性能排名。价格基础另见计费说明，模型集合见模型广场。
来源与核对日期
2026-10-17 核对；官方资料用于说明 K3，不作为 K3.1 的独立规格证明。