本地Kimi K3秒变OpenAI兼容API：WARP serve流式输出与工具调用完整教程

本地Kimi K3秒变OpenAI兼容API：WARP serve流式输出与工具调用完整教程

【免费下载链接】warpRun the full 2.78-trillion-parameter Kimi K3 model, DeepSeek V4.1 Flash or GLM-5.3-Flash beyond available RAM by streaming activated weights directly from NVMe. A dependency-free, embeddable C inference engine.项目地址: https://gitcode.com/gh_mirrors/was/warp

想用本地 Kimi K3 提供 OpenAI 兼容 API？开源项目 WARP（GitHub 加速计划 was/warp）内置的serve服务器可以办到：一条命令把 2.78 万亿参数的 Kimi K3 变成支持流式输出（SSE）、工具调用（Tool Calling）、结构化输出和图片输入的 HTTP 服务，且零第三方依赖。本教程带你从零完成搭建。

一、为什么是 WARP？💡

WARP 是一个用 C 编写的可嵌入推理引擎，它不要求把整个模型塞进内存，而是把模型主干放在 RAM 中、按需从 NVMe 磁盘流式读取激活的专家权重（MoE 中每 token 只激活约 4% 的参数）。这正是超大规模模型能在消费级硬件上跑起来的关键。

serve服务器是libwasteC 引擎的第二个客户端：所有推理计算都通过 ctypes 交给 C 库，Python 只负责 OpenAI 协议渲染、请求校验和 SSE 分帧——只用标准库，不需要 pip 安装任何东西。

二、快速开始：一键启动 WARP serve 服务器 🚀

1. 构建引擎

git clone https://gitcode.com/gh_mirrors/was/warp cd warp make make libwaste.so # macOS 上为 make libwaste.dylib

make会生成wasteCLI 和libwaste.a，服务器还需要动态库libwaste.so（macOS 为.dylib）。构建无需权重，不到一分钟。

2. 准备模型容器

模型.waste容器要放在内置 NVMe上（外置 USB 盘实测只有 0.94 GB/s，内置 SSD 可达 12.78 GB/s）。K3 可以直接下载已转换好的容器（约 982 GB），也可用 tools/fetch_weights.sh + tools/convert.py 自行转换。

3. 启动服务器

python3 -m serve ~/models/k3.waste --port 8000

启动时会打印模型信息、内存预算、以及该容器支持哪些能力（普通对话 / 推理频道 / 工具协议 / 图片），例如：

model k3 — 81 layers, ... experts memory 29.2 GB resident, expert cache 17.6 GB thinking on — reasoning_effort per request listening on http://127.0.0.1:8000 (POST /v1/chat/completions)

4. 验证服务

curl localhost:8000/health curl localhost:8000/v1/models

至此，一个标准的 OpenAI 兼容接口就已经就位，端点一览（详见 docs/SERVE.md）：

三、流式输出：SSE 逐 token 推送 📡

WARP 每 token 的生成耗时可达秒级，流式输出几乎是必选项。请求中加上"stream": true，服务器即按标准 SSE（data: {...}行 + 结尾data: [DONE]）推送chat.completion.chunk：

curl -N localhost:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{ "model": "k3", "stream": true, "stream_options": {"include_usage": true}, "messages": [{"role": "user", "content": "用一句话介绍本地推理"}] }'

流式实现有几个值得注意的细节：

• 推理与正文分开推送：响应里reasoning_content（思考过程）和content（正式回答）是两个字段，每个 SSE delta 都会带，客户端可以分别渲染；
• 断开即停止：流式直接写在 token 回调线程上，客户端挂断会立刻回传给引擎终止生成——对每秒只有几个 token 的模型，这能省下一整段空烧的算力；
• 附带waste统计：响应多一个waste对象，报告专家缓存命中率、读取字节数等，OpenAI 原始 schema 里没有这些字段。

阻塞式请求同样支持"reasoning_effort": "off"直接跳过思考：

curl localhost:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model":"k3","messages":[{"role":"user","content":"为什么天空是蓝的？"}],"reasoning_effort":"off"}'

四、工具调用：让本地 K3 使用 Function 🛠️

Kimi K3 的提示词格式是独特的 XTML 标记语言（<|open|>、<|sep|>等特殊 token 组成的类 XML 结构），工具声明、工具结果都有专门的元素。serve/xtml.py 完整实现了协议渲染，serve/regions.py 则负责把模型回复增量解析回 OpenAI 的tool_calls结构。

一个标准 OpenAI 格式的工具调用请求就能直接跑：

curl localhost:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{ "model": "k3", "messages": [{"role": "user", "content": "罗马现在天气怎么样？"}], "tools": [{"type": "function", "function": { "name": "weather", "description": "查询当前天气", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}}], "tool_choice": "required" }'

模型决定调用工具时，finish_reason返回"tool_calls"，message.tool_calls中带函数名和参数；你执行完函数后，把结果作为role: "tool"的消息（按tool_call_id对应）追加回messages再请求一次即可，乱序的工具结果服务器会自动重排。完整请求示例见 examples/README.md。

另外两个"协议级"字段同样可用：

• tool_choice：支持required/none，以合成系统消息注入（K3 没有对应请求字段）；
• response_format：支持json_object和json_schema，让模型按你给的 JSON Schema 输出结构化数据。

💡 GLM-5.3-Flash 和 Kimi-Linear 的容器也能被 serve：它们的分词器自带原生工具协议标记（GLM 为 9 个 XML 标记，Kimi 为 5 个），由 serve/glmtools.py 和 serve/kimitools.py 渲染；服务器启动时会明确告知当前容器具备哪些能力。

五、控制"思考"：reasoning_effort 🧠

K3 默认开启思考频道（这也是它训练时的状态），但技术报告显示推理 token 可占请求的 73%——在这台引擎的速度下，那就是漫长的等待。控制方式：

如果整体希望"先回答、要思考再按请求开"，启动服务器时加--no-thinking即可。

六、图片输入：多模态请求 🖼️

需要图片理解时，用--vision启动服务器加载视觉塔（K3 约 434 MB 权重）：

python3 -m serve ~/models/k3.waste --port 8000 --vision

图片以 base64data:URL 传入（服务器不会抓取远程 HTTP URL，本地路径需显式开启--allow-local-images，两者都是安全设计）：

IMAGE_B64="$(base64 < photo.jpg | tr -d '\n')" curl localhost:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ --data-binary "{\"model\":\"k3\",\"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"image_url\",\"image_url\":{\"url\":\"data:image/jpeg;base64,${IMAGE_B64}\"}},{\"type\":\"text\",\"text\":\"描述这张图\"}]}],\"reasoning_effort\":\"off\"}"

⚠️ 提醒：一张 896×896 的图会展开为 256 个提示位置，每个位置的 prefill 成本与文本相当，图片请求整体较慢。

七、生产部署与常见坑 ⚙️

• --max-tokens：服务器默认上限 4096。Open-WebUI 等客户端不传max_tokens时就停在这里，长文回答记得调大；
• --host 0.0.0.0+--api-key：默认只监听 127.0.0.1；要跨机器访问必须同时设置 API Key（--api-key或环境变量WASTE_API_KEY），否则服务器会打印警告；
• 无状态设计：每个请求都会先重置会话状态，不存在"上一个请求污染下一个请求"的问题，请求之间串行排队（引擎本身非线程安全）；
• Open-WebUI 对接：把它的 API base 指向http://<host>:8000/v1（注意带/v1），建议关闭自动标题/建议等后台任务，避免它们排队占用生成锁；
• 内存预算：--budget 48G可硬性限制 RAM，默认由引擎自动选择并拒绝低于模型下限的预算；--plan可只打印内存规划直接退出。

八、小结

WARP serve 用不到十行配置，就把本地 Kimi K3 变成了一个功能完整的 OpenAI 兼容端点：标准 SSE 流式输出、tool_calls工具调用、json_schema结构化输出、reasoning_content思考频道和图片输入，全部开箱即用。核心代码集中在 serve/ 目录，服务器主入口是 serve/main.py，请求协议实现在 serve/api.py；完整的端点行为、安全说明与差异测试文档见 docs/SERVE.md，引擎原理见 docs/ENGINE.md 和 README.md。

从磁盘流式加载万亿参数、再以标准 API 对外服务——这就是"权重在 NVMe 上、智能在 API 里"的完整闭环。🚀

【免费下载链接】warpRun the full 2.78-trillion-parameter Kimi K3 model, DeepSeek V4.1 Flash or GLM-5.3-Flash beyond available RAM by streaming activated weights directly from NVMe. A dependency-free, embeddable C inference engine.项目地址: https://gitcode.com/gh_mirrors/was/warp