kimikimi-k3open-weightslocal-deploy

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

2026年11月10日by EXAIV Team

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

Kimi K3 是 Moonshot 开放线的顶端：2,779,931,837,184 总参数的 MoE，93 层、896 专家、max_position_embeddings 1048576，官方 config.json 里带 vision_config 与 image_placeholder。HuggingFace 标签是 image-text-to-text，2026 年 11 月采样的 30 天下载量 751,953、点赞 11,965。K2.5 与 K2.6 是更早的 1,026,879,376,368 参数快照，61 层、262144 上下文。EXAIV 云端目录里只有 kimi-k3，所以 K2.5、K2.6 只能本地部署，本文也不为它们编造仓库名。

30 秒版本

云端用 kimi-k3；K2.5、K2.6 只作为本地开放权重。config 能证明带视觉输入的条件生成架构，不等于视频生成。价格与 ID 以实时页面为准。

规格对照

维度	数值	说明
Total parameters	2,779,931,837,184	30-day downloads 751,953
Architecture	KimiK3ForConditionalGeneration	model_type kimi_k3
Text config	93 layers, 896 experts	Max position 1048576 (1M)
Vision keys	vision_config, image_placeholder	HuggingFace tag image-text-to-text
Likes	11,965	Licence license:other
EXAIV cloud ID	kimi-k3	Callable today
Local GGUF	Follow the official model card	No fabricated repo names
Video claims	Needs measurement	Config proves image-text input, not video generation

事实边界

本文所有数字都来自 HuggingFace API 或对应仓库的原始 config.json。这个区分很重要，因为多模态最容易被夸大：vision_config 与 image_placeholder 能证明这是带视觉能力的条件生成架构，但本身不能证明视频生成、某种具体请求格式或某项跑分。超出 config 的部分一律标注为「需实测」，最终以官方模型卡为准。

显存与部署现实

显存规划与所有万亿级 MoE 一样：算力按激活参数算，显存按总参数算。1T 模型即使 4-bit，权重本身也要约 500GB，K2.5、K2.6 明确属于多卡服务器场景，K3 的 2.78T 更大。单张消费卡请去看轻量家族。本地路径是 vLLM 或 SGLang 配官方权重；社区转换文件要先核对来源与量化标签再用。

云端与成本

在 EXAIV 上，kimi-k3 通过 https://exaiv.com/api/ai/v1 这个 OpenAI 兼容端点调用，只改 base_url、api_key、model 三项，流式与工具调用保持标准格式。本文不写死价格，实时 /pricing 页面才是准绳；哪些 ID 真正可用由 /models 实时目录决定。建议记录模型 ID、token 数与延迟，日后换模型才有同一套基线可比。

场景选择

场景	建议
Image understanding with long context	Kimi K3
Million-token document analysis	Kimi K3
Use it immediately on cloud	kimi-k3 on EXAIV
Need verified video generation	Check the official model card
Need a small local model	Look at the lightweight lines
Confirm exact licence	Official model card

FAQ

EXAIV 上该用哪个模型 ID？

kimi-k3，上线前对照 /models 实时目录确认。

K2.5、K2.6 能云端调用吗？

不能，两者都不在 EXAIV 目录里，只能本地部署开放权重。

config 能证明视频生成吗？

不能，只能证明带视觉能力的条件生成架构；视频能力需实测。

需要换 SDK 吗？

不需要，保留 OpenAI SDK，只改三项配置。

数字从哪里来？

HuggingFace API 与原始 config.json，2026 年 11 月采样。

价格在哪里看？

实时 /pricing 页面，本文不写死价格。

数据来源

参数与文件数据为 2026 年 11 月采样，随时间变化。

国产模型一个 Key 调用

EXAIV 已接入 Qwen / DeepSeek / Kimi / GLM，OpenAI 兼容端点，注册即用

查看充值套餐

通用本地部署检查清单

散落的教程讲的是「单点」：怎么装 Ollama、怎么下 GGUF、怎么配插件。但真正部署一套能日常用的本地模型，是一条完整的链路——硬件够不够、模型选哪个档、下哪个文件、怎么起服务、怎么接进工具、出问题怎么查。这篇手册按七步走完这条链路，每步给出可执行命令和「什么时候该停/该换」的判断标准。

30 秒版本

七步：① 查硬件（显存/内存/磁盘）② 反查模型（按显存选规模+档位）③ 下 GGUF ④ 跑起来（Ollama 或 llama.cpp）⑤ 暴露本地端点 ⑥ 接进工具（Cursor/Continue/Open WebUI）⑦ 监控排障。任何一步卡住，回到判断标准而不是硬试。

第 1 步：检查硬件与算力预算

先确认三件事，任何一项不满足就调整目标，而不是硬上：

项目	最低	建议	检查方法
显存	8GB	按目标模型定（见下）	`nvidia-smi`
系统内存	32GB	64GB+	`free -g` / 系统信息
磁盘	100GB 空闲	200GB+	`df -h`

显存的算法：目标模型参数 × 量化字节系数 + KV cache + 2GB 开销。完整公式和算例见显存计算实战。一句话版本：27B 模型要 24GB 级显存才舒服，14B 级 16GB 够用，4B 级 8GB 轻松。

磁盘经常被忽略

一个 27B 模型的 Q4 GGUF 就约 16GB，想同时留几个档位、几个模型对比，100GB 很快见底。模型缓存目录（Ollama 默认在用户目录）在系统盘上，容易撑爆系统盘——建议把模型目录移到独立磁盘。

第 2 步：按显存反查模型与档位

有了显存预算，反查能跑什么：

你的显存	建议目标	量化档位
8GB	4B 级全家桶 / 7-8B Q4	Q4_K_M
16GB	14B Q4/Q5，或 27B Q3	Q4_K_M 起
24GB	27B Q4/Q5 舒服跑	Q4_K_M / Q5_K_M
48GB+	70B 级 Q4，或 27B Q8	按质量需求

模型家族选择参考：Qwen 系列怎么选、DeepSeek V4 全系盘点、混元 hy4 与 A13B。档位取舍参考：GGUF 量化器对比。

第 3 步：下载 GGUF

从 HuggingFace 下载目标模型的 GGUF。两条路：

bash

# 用 huggingface-cli 下载指定文件（模型卡上确认实际文件名）
huggingface-cli download <作者>/<模型>-GGUF \
  <模型>-Q4_K_M.gguf --local-dir ./models

或者用支持直接拉取的推理工具（如 Ollama 部分模型支持直接 pull 官方版本）。下载前核对模型卡上的文件大小，避免下完发现显存装不下。

别按文件名猜体积

同一个模型的不同量化档位体积相差几倍。下单前先看模型卡上每个文件的尺寸和最低硬件要求——这是最省时间的一步核对。

第 4 步：跑起来

路线 A：Ollama（最快跑通）

bash

# 写 Modelfile 指向本地 GGUF
# FROM ./models/<模型>-Q4_K_M.gguf
ollama create mymodel -f Modelfile
ollama run mymodel "用一句话介绍你自己"

路线 B：llama.cpp（要控制和服务）

bash

git clone https://github.com/ggerganov/llama.cpp && cd llama.cpp && make -j

./build/bin/llama-server \
  -m ./models/<模型>-Q4_K_M.gguf \
  -ngl 35 \
  -c 8192 \
  --host 127.0.0.1 --port 8080

两条路线怎么选

只想验证效果：Ollama，一条命令。要调 GPU 层数、上下文、并发，或要长期跑服务：llama.cpp（llama-server 带 OpenAI 兼容接口）。两者底层都吃 GGUF，模型文件通用，随时可以切换。

第 5 步：暴露本地端点

要把模型接进工具，需要一个长期运行的 HTTP 端点：

Ollama：默认监听 127.0.0.1:11434，提供 OpenAI 兼容接口
llama.cpp：llama-server 启动后监听你指定的端口，同样兼容 /v1/chat/completions

端点安全边界

默认绑定 127.0.0.1，只有本机可访问——这是正确的默认。要让局域网其他机器用，必须显式改绑定地址，并且明白这等于把「无鉴权的推理服务」暴露到网络上：加防火墙规则、只在可信网络开放，或加一层带鉴权的反代。

第 6 步：接进你的工具

本地端点起来后，接入已有工具只需要「指向地址 + 选模型」：

工具	接入方式	指南
Cursor	Override OpenAI Base URL 指到本地端点	Cursor 接入
Continue	config 文件声明 apiBase	Continue 接入
Open WebUI	连接配置里填 API Base URL	Open WebUI 接入
自研程序	OpenAI SDK 改 base_url	本地编码工作流

一个实用细节：编辑器插件通常有超时设置，而本地模型首次加载需要时间——把超时调大，或先跑几条 warmup 请求再接入。

第 7 步：监控、排障与回退

监控：nvidia-smi 看显存峰值；llama.cpp 日志看 KV cache 分配和 token/s。

排障固定顺序：

显存不够 → 降上下文（-c）或降档位
上下文够但速度慢 → 减少内存卸载层、检查是否在用 GPU
输出乱码/加载失败 → 更新推理引擎（MoE 架构对引擎版本敏感）
工具侧报错 → 先 curl 直接打端点，分清是「端点问题」还是「工具配置问题」

回退方案：本地模型是主力，云端是兜底。当本地服务慢、挂掉、或需要旗舰质量时，一条 fallback 代码切到云端 API（EXAIV OpenAI 兼容端点，模型 ID 以 /models 实时为准）即可，开发流程不中断。成本上的取舍见本地算力成本模型。

什么时候不该继续折腾本地

如果目标模型必须旗舰质量、或并发量本地硬件撑不住、或团队没有维护精力——本地不是唯一答案。云端 API 在这些场景下更省心。判断标准不是「哪个更酷」，而是「哪种模式匹配你的使用量、隐私要求和运维能力」。

FAQ

整个流程要准备多久？

如果硬件就绪、目标明确：Ollama 路线半天内能跑通；llama.cpp 加服务化和工具接入，一到两天。主要时间消耗在下载模型和踩引擎版本兼容的坑上。

Ollama 和 llama.cpp 能同时用吗？

能，它们互不冲突（不同端口）。常见组合：Ollama 平时跑聊天，llama-server 跑需要调参或对外服务的场景。

本地模型多久更新一次？

看模型迭代节奏。Qwen/DeepSeek 这类活跃家族可能几周一个新版本，建议锁定一个稳定版本日常用，新版本先在小评估集上验证再切换。

本地部署需要联网吗？

下载模型和依赖需要；跑起来之后完全离线可用——这正是本地部署的核心价值之一（数据不出机、无网络依赖）。

多用户使用要注意什么？

本地单机并发能力有限，KV cache 按并发倍增。团队共用建议限制并发数，或把高并发场景交给云端 API。具体容量算法见显存计算实战。

部署完发现速度不满意怎么办？

先确认真的在用 GPU（-ngl 生效、显存有占用），再检查上下文/批量是否过大。若确认是硬件瓶颈，要么降档位/换小模型，要么把高频任务放本地、重任务放云端。

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

2026年11月10日by EXAIV Team

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

30 秒版本

云端用 kimi-k3；K2.5、K2.6 只作为本地开放权重。config 能证明带视觉输入的条件生成架构，不等于视频生成。价格与 ID 以实时页面为准。

规格对照

维度	数值	说明
Total parameters	2,779,931,837,184	30-day downloads 751,953
Architecture	KimiK3ForConditionalGeneration	model_type kimi_k3
Text config	93 layers, 896 experts	Max position 1048576 (1M)
Vision keys	vision_config, image_placeholder	HuggingFace tag image-text-to-text
Likes	11,965	Licence license:other
EXAIV cloud ID	kimi-k3	Callable today
Local GGUF	Follow the official model card	No fabricated repo names
Video claims	Needs measurement	Config proves image-text input, not video generation

场景	建议
Image understanding with long context	Kimi K3
Million-token document analysis	Kimi K3
Use it immediately on cloud	kimi-k3 on EXAIV
Need verified video generation	Check the official model card
Need a small local model	Look at the lightweight lines
Confirm exact licence	Official model card

FAQ

EXAIV 上该用哪个模型 ID？

kimi-k3，上线前对照 /models 实时目录确认。

K2.5、K2.6 能云端调用吗？

不能，两者都不在 EXAIV 目录里，只能本地部署开放权重。

config 能证明视频生成吗？

不能，只能证明带视觉能力的条件生成架构；视频能力需实测。

需要换 SDK 吗？

不需要，保留 OpenAI SDK，只改三项配置。

数字从哪里来？

HuggingFace API 与原始 config.json，2026 年 11 月采样。

价格在哪里看？

实时 /pricing 页面，本文不写死价格。

数据来源

参数与文件数据为 2026 年 11 月采样，随时间变化。

国产模型一个 Key 调用

EXAIV 已接入 Qwen / DeepSeek / Kimi / GLM，OpenAI 兼容端点，注册即用

查看充值套餐

通用本地部署检查清单

30 秒版本

第 1 步：检查硬件与算力预算

先确认三件事，任何一项不满足就调整目标，而不是硬上：

项目	最低	建议	检查方法
显存	8GB	按目标模型定（见下）	`nvidia-smi`
系统内存	32GB	64GB+	`free -g` / 系统信息
磁盘	100GB 空闲	200GB+	`df -h`

磁盘经常被忽略

第 2 步：按显存反查模型与档位

有了显存预算，反查能跑什么：

你的显存	建议目标	量化档位
8GB	4B 级全家桶 / 7-8B Q4	Q4_K_M
16GB	14B Q4/Q5，或 27B Q3	Q4_K_M 起
24GB	27B Q4/Q5 舒服跑	Q4_K_M / Q5_K_M
48GB+	70B 级 Q4，或 27B Q8	按质量需求

模型家族选择参考：Qwen 系列怎么选、DeepSeek V4 全系盘点、混元 hy4 与 A13B。档位取舍参考：GGUF 量化器对比。

第 3 步：下载 GGUF

从 HuggingFace 下载目标模型的 GGUF。两条路：

bash

# 用 huggingface-cli 下载指定文件（模型卡上确认实际文件名）
huggingface-cli download <作者>/<模型>-GGUF \
  <模型>-Q4_K_M.gguf --local-dir ./models

或者用支持直接拉取的推理工具（如 Ollama 部分模型支持直接 pull 官方版本）。下载前核对模型卡上的文件大小，避免下完发现显存装不下。

别按文件名猜体积

同一个模型的不同量化档位体积相差几倍。下单前先看模型卡上每个文件的尺寸和最低硬件要求——这是最省时间的一步核对。

第 4 步：跑起来

路线 A：Ollama（最快跑通）

bash

# 写 Modelfile 指向本地 GGUF
# FROM ./models/<模型>-Q4_K_M.gguf
ollama create mymodel -f Modelfile
ollama run mymodel "用一句话介绍你自己"

路线 B：llama.cpp（要控制和服务）

bash

git clone https://github.com/ggerganov/llama.cpp && cd llama.cpp && make -j

./build/bin/llama-server \
  -m ./models/<模型>-Q4_K_M.gguf \
  -ngl 35 \
  -c 8192 \
  --host 127.0.0.1 --port 8080

两条路线怎么选

第 5 步：暴露本地端点

要把模型接进工具，需要一个长期运行的 HTTP 端点：

Ollama：默认监听 127.0.0.1:11434，提供 OpenAI 兼容接口
llama.cpp：llama-server 启动后监听你指定的端口，同样兼容 /v1/chat/completions

端点安全边界

第 6 步：接进你的工具

本地端点起来后，接入已有工具只需要「指向地址 + 选模型」：

工具	接入方式	指南
Cursor	Override OpenAI Base URL 指到本地端点	Cursor 接入
Continue	config 文件声明 apiBase	Continue 接入
Open WebUI	连接配置里填 API Base URL	Open WebUI 接入
自研程序	OpenAI SDK 改 base_url	本地编码工作流

一个实用细节：编辑器插件通常有超时设置，而本地模型首次加载需要时间——把超时调大，或先跑几条 warmup 请求再接入。

第 7 步：监控、排障与回退

监控：nvidia-smi 看显存峰值；llama.cpp 日志看 KV cache 分配和 token/s。

排障固定顺序：

显存不够 → 降上下文（-c）或降档位
上下文够但速度慢 → 减少内存卸载层、检查是否在用 GPU
输出乱码/加载失败 → 更新推理引擎（MoE 架构对引擎版本敏感）
工具侧报错 → 先 curl 直接打端点，分清是「端点问题」还是「工具配置问题」

什么时候不该继续折腾本地

FAQ

整个流程要准备多久？

如果硬件就绪、目标明确：Ollama 路线半天内能跑通；llama.cpp 加服务化和工具接入，一到两天。主要时间消耗在下载模型和踩引擎版本兼容的坑上。

Ollama 和 llama.cpp 能同时用吗？

能，它们互不冲突（不同端口）。常见组合：Ollama 平时跑聊天，llama-server 跑需要调参或对外服务的场景。

本地模型多久更新一次？

看模型迭代节奏。Qwen/DeepSeek 这类活跃家族可能几周一个新版本，建议锁定一个稳定版本日常用，新版本先在小评估集上验证再切换。

本地部署需要联网吗？

下载模型和依赖需要；跑起来之后完全离线可用——这正是本地部署的核心价值之一（数据不出机、无网络依赖）。

多用户使用要注意什么？

本地单机并发能力有限，KV cache 按并发倍增。团队共用建议限制并发数，或把高并发场景交给云端 API。具体容量算法见显存计算实战。

部署完发现速度不满意怎么办？

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

规格对照

事实边界

显存与部署现实

云端与成本

场景选择

FAQ

相关阅读

数据来源

通用本地部署检查清单

第 1 步：检查硬件与算力预算

第 2 步：按显存反查模型与档位

第 3 步：下载 GGUF

第 4 步：跑起来

第 5 步：暴露本地端点

第 6 步：接进你的工具

第 7 步：监控、排障与回退

FAQ

相关阅读

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

Kimi K3 多模态指南：从 config 能确认什么、不能确认什么

规格对照

事实边界

显存与部署现实

云端与成本

场景选择

FAQ

相关阅读

数据来源

通用本地部署检查清单

第 1 步：检查硬件与算力预算

第 2 步：按显存反查模型与档位

第 3 步：下载 GGUF

第 4 步：跑起来

第 5 步：暴露本地端点

第 6 步：接进你的工具

第 7 步：监控、排障与回退

FAQ

相关阅读