[Bug][Linux] /v1/embeddings always fails with qds_device::wait() unexpected command state (Krackan Point, FLM 1.0.6)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 40/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- ai-infra-agents, backend, devtools
Hướng nghiên cứu
The issue is in the NPU driver stack, likely in the XRT plugin or amdxdna driver. Start by examining the server logs around the embedding dispatch and the error 'qds_device::wait() unexpected command state'. Look at the related issues #732, #661, #647, #655 for context on similar Linux/NPU problems. Check the embedding model loading and inference path in the FastFlowLM codebase, focusing on how it interfaces with the XRT API for the Krackan Point hardware. Reproduce the error with the given steps to confirm the environment.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem Description
On Linux, every request to /v1/embeddings fails with the same internal XRT error, deterministically, while chat completions on the same server instance keep working fine.
Request:
curl http://127.0.0.1:52625/v1/embeddings \
-d '{"model":"embed-gemma:300m","input":"hola"}'
Response (100% of requests):
{"error":"qds_device::wait() unexpected command state"}
Server log shows the request arriving and being accepted, then the error:
[LOG] Target: /v1/embeddings
"model": "embed-gemma:300m"
Embedding input[0]: hola
→ {"error":"qds_device::wait() unexpected command state"}
Notes:
- Happens with single-string input and with arrays.
flm serve llama3.2:1b --embed 1loads both models successfully (Embedding mode enabled: reserving additional 300MB); failure only occurs at the actual embed dispatch.- Without
--embed 1, chat on the same box is fine (96 tok/s prefill / 42 tok/s decode with llama3.2:1b). - The error message text matches the generic XRT/NPU queue-state error also seen in Xilinx/mlir-aie#1751 and amd/RyzenAI-SW#177.
Related issues (but not the same symptom): #732 and #661 report embeddings that complete but are wrong/collapsed on Linux; #647 reports non-determinism; #655 reports an IOCTL regression on the same chip family (Krackan Point). This report adds the case where the embed dispatch itself errors out on every request.
Environment
| Item | Value |
|---|---|
| Hardware | AMD Ryzen AI 5 PRO 340 (Krackan Point), PCI 1022:17f0, Lenovo subsystem |
| OS | Omarchy (Arch Linux), Wayland |
| Kernel | 7.2.5-4-omarchy |
| NPU FW | 1.1.2.64 |
| Device | /dev/accel/accel0 with 8 columns |
| amdxdna | in-tree, reported as 0.10 by flm validate |
| XRT | xrt 2.21.75-14 + xrt-plugin-amdxdna 2.21.75-2 (Arch extra) |
| FLM | fastflowlm 1.0.6-1 (Arch extra) |
| Memlock | unlimited (via ulimit wrapper) |
flm validate output:
[Linux] Kernel: 7.2.5-4-omarchy
[Linux] NPU: /dev/accel/accel0 with 8 columns
[Linux] NPU FW Version: 1.1.2.64
[Linux] amdxdna version: 0.10
[Linux] Memlock Limit: infinity
Steps to reproduce
flm pull llama3.2:1b
flm pull embed-gemma:300m
flm serve llama3.2:1b --embed 1
curl http://127.0.0.1:52625/v1/embeddings \
-H 'Content-Type: application/json' \
-d '{"model":"embed-gemma:300m","input":"hola"}'
Expected
A vector array response:
{"data":[{"embedding":[...],...}]}
Actual
{"error":"qds_device::wait() unexpected command state"}
CPU governor/pmode (--pmode balanced) does not change the outcome; also reproduced with pmode default. Model files pass flm check after a fresh verified download.
- Ngôn ngữ chính
- C++
- Star
- 1.9k
- Fork
- 152
- Merge trung bình
- 1 ngày 13 giờ
- Pull request đã merge (30 ngày)
- 15
Chuẩn bị môi trường
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ROCm/FastFlowLM
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
ROCm/FastFlowLM#753 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
No valid checkpoint to restore + Max length reached on multi-turn tool calls (Qwen3.6-MoE, NPU)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
ROCm/FastFlowLM#744 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
ROCm/FastFlowLM#741 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Download timeoutĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
ROCm/FastFlowLM#520 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Nice-to-have] /v1/pingĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ROCm/FastFlowLM#434 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của ROCm/FastFlowLM
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
KhronosGroup/Vulkan-Tutorial#524 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
microsoft/onnxruntime-genai#2633 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
mapper bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
firebase/firebase-ios-sdk#16718 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
tesseract-ocr/tesseract#4627 ·