Kimi K3.1 Pro 权重已上线:11-02 建仓,本站前三轮「未上线」口径订正
复核确认 moonshotai/Kimi-K3.1-Pro 已于 2026-11-02 建仓:112 个文件、8-bit、797 次下载;前三轮「未上线」源于镜像列表端点漏返,已订正。
2026-11-05 · Hugging Face 镜像 REST 端点一手核对(detail / author 列表 / search 三端点交叉,2026-11-05)+ 官方技术博客 Availability 原文
发布 2026-11-05核实 2026-11-05要点
- Kimi K3.1 Pro 的权重仓库已存在:
moonshotai/Kimi-K3.1-Pro,detail 端点返回createdAt2026-11-02T04:13:51Z(lastModified同值)、112 个文件、797 次下载、386 likes、gated: false、private: false。 - 本站前三轮(11-02 / 11-03 / 11-04)写「权重未上线」是误判:当时只查了镜像的默认列表端点,该端点返回的 19 个仓库里没有它。取证方法与结论都要改。
- 官方公告页仍未同步:
kimi.ai/blog/kimi-k3-1-pro截至 2026-11-05 的 Availability 一节仍写 "Full model weights will be released by Nov 4, 2026.",没有改成「已发布」。仓库在、公告页没更新,两件事并存。 - 这是量化权重,不是全精度:标签含
8-bit、compressed-tensors、custom_code,library_name: transformers,pipeline_tag: image-text-to-text,112 个文件说明按分片组织。 - 许可证仍是自定义条款:
license: other+license_name: kimi-k3.1-pro,不是 Apache / MIT,商用前必须读原文。 - 仍有冒名仓库在检索结果里:
?search=Kimi-K3.1只返回audnai/penclaw-Kimi-K3.1-pro-unrestricted(0 下载 / 124 likes),官方仓库反而搜不到。
仓库事实(2026-11-05 复核)
| 字段 | 值 |
|---|---|
| 仓库 | moonshotai/Kimi-K3.1-Pro |
createdAt / lastModified | 2026-11-02T04:13:51Z(两者相同) |
| 文件数(siblings) | 112 |
| 下载 / 点赞 | 797 / 386 |
pipeline_tag / library_name | image-text-to-text / transformers |
| 关键标签 | kimi_k31、compressed-tensors、8-bit、custom_code、eval-results、endpoints_compatible |
| 许可证 | other / license_name: kimi-k3.1-pro |
| 门禁 | gated: false、private: false |
为什么前三轮看错了:镜像列表端点不可信
同一时刻,三个端点给出三种答案:
| 端点 | 返回 | 是否含 K3.1-Pro |
|---|---|---|
?author=moonshotai(默认) | 19 个仓库 | 不含 |
?author=moonshotai&sort=createdAt&direction=-1&limit=40 | 20 个仓库,K3.1-Pro 排第一 | 含 |
?author=moonshotai&search=Kimi-K3.1(search) | 只有冒名仓库 | 不含官方仓库 |
/api/models/moonshotai/Kimi-K3.1-Pro(detail) | 完整元数据 | 200 |
前三轮核对用的正是第一行那个端点——它返回 19 条、最新仍是 Kimi-K3,于是「无任何 K3.1 仓库」的结论被写进了三篇稿子。结论本身在当时是「按该端点如实记录」,但它不是「事实」。
本站据此固化一条判据:
判「某个权重仓库是否存在」,必须打 detail 端点(
/api/models/<org>/<name>)拿 200/404,不能只看 author 列表。 列表端点受缓存分片与分页影响,会给出「不存在」这种看起来很像结论的假象。搜索端点更差——它可能只返回冒名仓库。
顺带解释另一件旧事:10-24 发布、承诺「by Nov 4」的权重为什么在 11-02 就有仓库。createdAt 只说明仓库创建时刻,不说明何时转为公开;本站不对「何时公开」作推断。
对现有内容的影响
| 页面 | 原口径 | 现处置 |
|---|---|---|
| Kimi K3.1 Pro 发布资讯 | 标注「权重未核对」 | 不回炉(资讯纪律),以本篇为后续注记 |
| Kimi K3 模型卡 | 「未核对权重仓库」 | 已订正为「K3.1 Pro 权重仓库已存在」并更新核对日 |
| Kimi Code 工具卡 | 版本停在 2.4.1 | 已同步 2.5.0(11-04 发布) |
仍未核实的部分
- 实际参数量:官方称「3T 级」,仓库未读
config.json,本文不写具体激活参数。 - 显存占用:
8-bit只是标签,没有实测数据;112 个分片下的实际峰值内存需自行测量。 - 许可证条款原文:
kimi-k3.1-pro自定义许可的具体限制(商用、蒸馏、再分发)未读原文。 - 官方是否已宣布发布:公告页未更新,也未检索到独立发布帖;「仓库已可读」与「官方宣布发布」是两件事。
AI 之家 观点
这一篇是纠错,不是发布。 我们连续三轮把「镜像列表没返给我」当成「权重不存在」,语气还一次比一次肯定——这正是本站自己定的纪律里最不该犯的那类错误:取证失败当否定结论。
技术上的教训很具体:列表类端点天生不可靠,判定存在性要用 detail 端点。这条经验值钱的地方不在 Kimi,而在下一次——任何「官方有没有放出 X」的问题,都该先打一个确定的 GET,而不是翻一页列表。
内容上的教训更该记住:当三篇稿子都在重复同一句「仍未上线」时,第四轮就应该去怀疑方法,而不是继续加码语气。 我们已经把「取证失败 ≠ 否定结论」写进规范,这次是没执行到位。
对读者的实用建议:仓库能读 ≠ 你能跑。8-bit 量化 + 3T 级 + 自定义许可证,这三条叠在一起,落地成本远高于「权重放出来了」这五个字给人的预期。想试就先看 config.json 与 LICENSE 原文,别直接上生产。
相关阅读
- Kimi K3 模型卡——完整参数、定价与替代关系
- Kimi Code 工具卡——CLI 版本演进与套餐
- Kimi K3.1 Pro 发布资讯——原始发布口径(含「by Nov 4」承诺)
- 本地部署与量化——MoE 架构与量化部署的关系
- 11-05 版本复核——同日七条 CLI 版本线
来源
- ⭐ moonshotai/Kimi-K3.1-Pro(Hugging Face 镜像 detail 端点,2026-11-05 复核)——仓库元数据、文件数、下载与点赞、许可证、标签
- ⭐ Kimi K3.1 Pro 官方技术博客(Availability 原文)——「Full model weights will be released by Nov 4, 2026」原句与三处评测脚注
- moonshotai 组织模型列表(sort=createdAt&limit=40,含 K3.1-Pro)——用于说明列表端点不一致
- moonshotai 组织模型列表(默认参数,19 条不含 K3.1-Pro)——还原前三轮误判的取数路径
取证边界:huggingface.co 直连在本机连续多轮不可用,全部数据取自 hf-mirror.com 镜像的同套 REST 接口,字段与官方一致但更新时间可能滞后。未加载模型、未实测显存、未读许可证全文、未读 config.json——本文对参数量与推理成本不作任何断言。镜像端点的列表不一致属镜像侧现象,不能推断官方 Hub 行为。
常见问题
Kimi K3.1 Pro 的权重到底放出来了吗?
仓库已存在且可读:moonshotai/Kimi-K3.1-Pro,detail 端点返回 createdAt 2026-11-02T04:13:51Z、112 个文件、797 次下载、386 likes,gated 为 false。但官方技术博客的 Availability 一节截至 2026-11-05 仍写「Full model weights will be released by Nov 4, 2026」,未改为已发布。两件事同时成立:仓库在,公告页未同步。
为什么本站之前三轮都说没上线?
因为当时只查了镜像的 author 列表端点。该端点返回不一致:默认 ?author=moonshotai 只给 19 个仓库、不含 K3.1-Pro;加 sort=createdAt&direction=-1&limit=40 则返回 20 个、含 K3.1-Pro。当时取到的是 19 条那份。判定「某个仓库是否存在」必须打 detail 端点,不能只看列表。
能直接用 transformers 加载吗?
仓库带 8-bit 与 compressed-tensors 标签、custom_code 与 transformers 库标签,属于量化权重而非全精度。本站未做实际加载与显存实测,具体显存占用与推理框架支持范围仍需自行验证。