ds4

这是一个 Metal FP32 数值测试失败,而不是推理崩溃:sqrt(softplus(x)) 以 log(1.0f + exp(x)) 的形式计算,在 M5 之前的 GPU 上,对于 -12 附近的 logits 会损失精度。请更新到最新的 main 分支(其中包含 PR #1044),然后重新构建并重新运行无模型测试:

git checkout main
git pull origin main
make clean
make tests/test_deepseek41_metal && ./tests/test_deepseek41_metal

合并的修复方案在全部四个 DeepSeek 路由变换位置,针对 exp(x) < 1/32 的情况,用精确的四项 log1p 级数替换了不精确的 1.0f + exp(x) 形式,对多项式输入进行了钳制,并在不放宽容差的情况下将 Metal 输出与共享的精确参考值进行比较。在较旧的提交上,临时解决方法是在主机参考实现中使用 log1pf(expf(v)) 并放宽测试容差,或者将 Metal 内核改为 log1p(exp(x))。

出现这些错误是因为外部启动器以不同的工作目录运行 ds4-server,而相对的 GGUF/Metal 路径会从该目录解析。请使用一个先切换到 ds4 安装目录的包装脚本:

#!/bin/sh
set -e
cd /path/to/ds4
exec ./ds4-server "$@"

为其添加可执行权限:

chmod +x /path/to/ds4/start-ds4.sh

然后将 llama-swap 指向该包装脚本。如果你的 ds4-server 构建不提供 /health,请使用 /v1/models 作为健康检查端点:

models:
  "deepseek-v4-flash":
    cmd: /path/to/ds4/start-ds4.sh
    proxy: http://127.0.0.1:5555
    checkEndpoint: /v1/models

或者,升级到包含路径解析修复的版本:此时,当在当前工作目录中找不到相对的模型路径和 Metal 资源路径时,将相对于可执行文件进行解析,并且 GET /health 可用于存活检查。

在 M5 级 GPU 上，自动 Metal 4 TensorOps 路径可能产生不准确的 matmul2d prefill 累加，导致 logits 与 simdgroup/参考内核不一致，并使贪心 argmax 结果发生翻转。通过运行时设置 DS4_METAL_DISABLE_METAL4=1 来禁用自动 TensorOps 路径，例如：

DS4_METAL_DISABLE_METAL4=1 ./ds4 -m gguf/GLM-5.3-Flash-Q2.gguf --metal --temp 0 -n 2 --ctx 32768 --prompt-file prompt.txt

或者，更新到包含该修复的构建版本，该修复会在 M5 设备上阻止自动启用 TensorOps。DS4_METAL_ENABLE_TENSOR=1 仍然是仅供性能测试使用的显式选择性启用项，在需要结果一致性时不应使用。更改操作数暂存精度或 matmul2d_descriptor::relaxed_precision 均无法解决该问题。

通过以下命令验证该变通方案：

DS4_TEST_MODEL=gguf/GLM-5.3-Flash-Q2.gguf \
DS4_TEST_VECTOR_FILE=tests/test-vectors/glm-openrouter/official.vec \
  ./ds4_test --metal-tensor-equivalence

在禁用 Metal 4 TensorOps 后，M5 的输出应在 logprob 转储、解码一致性检查和评估跟踪方面与 M5 之前的参考机器保持逐位一致。

构建 ds4 的 PR #621，从 Hugging Face PR #22 下载实验性的 GGUF，并提供匹配的 Vision 编码器 sidecar 文件。

1. 下载模型和编码器：

mkdir -p gguf

hf download antirez/deepseek-v4-gguf \
  DeepSeek-V4-Flash-Vision-Exp-IQ2XXS-w2Q2K-AProjQ4-SExpQ8-OutQ8-imatrix.gguf \
  --revision refs/pr/22 \
  --local-dir gguf

hf download antirez/deepseek-v4-gguf \
  DeepSeek-V4-Flash-Vision-Encoder.gguf \
  --revision main \
  --local-dir gguf

2. 验证语言模型的校验和。在 macOS 上使用 shasum -a 256；在 Linux 上使用 sha256sum。预期的 SHA-256：

a1d0fde967c910e37e4bea00c4db1b2e8a88978770828a95772bc66837386cb8

3. 获取并构建 PR 头：

git clone https://github.com/antirez/ds4.git ds4-vision-q4
cd ds4-vision-q4
git fetch origin pull/621/head:pr-621
git checkout pr-621
git rev-parse HEAD

# Apple Silicon / Metal
make clean && make

# 其他 NVIDIA CUDA 系统
make clean && make cuda-generic

# DGX Spark / GB10
make clean && make cuda-spark

# AMD Strix Halo / ROCm
make clean && make strix-halo -j"$(nproc)"

4. 先检查模型：

MODEL=gguf/DeepSeek-V4-Flash-Vision-Exp-IQ2XXS-w2Q2K-AProjQ4-SExpQ8-OutQ8-imatrix.gguf
VISION=gguf/DeepSeek-V4-Flash-Vision-Encoder.gguf

./ds4 --cpu --inspect -m "$MODEL"

预期的元数据包括 GGUF v3、1328 个张量、43 层、215 个 q4_k 张量、130 个 q8_0 张量，以及 78.62 GiB 的文件大小。

5. 使用 SSD 流式加载运行：

# Metal
./ds4 --metal --ssd-streaming --ctx 4096 --temp 0 \
  -m "$MODEL" --vision "$VISION"

# CUDA
./ds4 --cuda --ssd-streaming --ctx 4096 --temp 0 \
  -m "$MODEL" --vision "$VISION"

# ROCm
./ds4 --rocm --ssd-streaming --ctx 4096 --temp 0 \
  -m "$MODEL" --vision "$VISION"

对于完全驻留内存的测试，请移除 --ssd-streaming。78.62 GiB 的模型、视觉编码器、KV 缓存和运行时缓冲区必须全部能放入可用内存中。

在交互式 CLI 中，使用以下命令加载 PNG 或 JPEG：

/read /path/to/test-image.png

至少测试一张普通照片、一张包含文本的屏幕截图、一张示意图或图表，以及一个后续问题。报告确切的 commit、后端、流式/驻留模式、崩溃情况、图像理解错误、质量漂移和性能。

该错误是因为 Kimi 指向了 OpenAI 风格的 /v1/models 端点，其响应使用 object 和 data 字段。Kimi 的自定义 provider 注册表要求 provider 对象包含 id、name、api、type 和 models 字段。

将 ds4 升级到包含 Kimi 兼容注册表 PR 的发布/构建版本，然后改为添加专用的 /api.json 端点：

kimi provider add http://spark:8000/api.json

不要使用：

kimi provider add http://spark:8000/v1/models

新端点还会解析 Kimi 发送的查询字符串参数。如果你的构建中 /api.json 不可用，请更新 ds4，或者提供一个包含所需 provider 字段的 Kimi 兼容注册表 JSON，并添加该 URL。