Skip to content

Fix missing numpy dependency in pyproject.toml - #524

Merged
merrymercy merged 1 commit into
sgl-project:mainfrom
fpreiss:fpreiss/dependencies
Jun 10, 2024
Merged

merrymercy merged 1 commit into
sgl-project:mainfrom
fpreiss:fpreiss/dependencies

Conversation

@fpreiss

@fpreiss fpreiss commented Jun 10, 2024

Copy link
Copy Markdown
Contributor

numpy is currently listed as an optional dependency. With the current version on pypi and on the master branch, sglang will fail to import without numpy installed. See the log output below:

Python 3.11.9 (main, May 27 2024, 20:31:01) [GCC 14.1.1 20240507] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sglang
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/fpreiss/Downloads/github/sglang/python/sglang/__init__.py", line 4, in <module>
    from sglang.api import (
  File "/home/fpreiss/Downloads/github/sglang/python/sglang/api.py", line 7, in <module>
    from sglang.backend.base_backend import BaseBackend
  File "/home/fpreiss/Downloads/github/sglang/python/sglang/backend/base_backend.py", line 4, in <module>
    from sglang.lang.interpreter import StreamExecutor
  File "/home/fpreiss/Downloads/github/sglang/python/sglang/lang/interpreter.py", line 34, in <module>
    from sglang.utils import (
  File "/home/fpreiss/Downloads/github/sglang/python/sglang/utils.py", line 15, in <module>
    import numpy as np
ModuleNotFoundError: No module named 'numpy'

This commit proposes a simple fix by requiring numpy in the pyproject.toml.

@merrymercy
merrymercy merged commit 542bc73 into sgl-project:main Jun 10, 2024
timethink pushed a commit to timethink/sglang that referenced this pull request Mar 9, 2025
vschandramourya pushed a commit to vschandramourya/sglang that referenced this pull request Feb 3, 2026
* update

* update

* update

* Add null-to-string conversion for string-type parameters in KimiK2Detector

When a parameter schema expects a string type but receives null, convert it to
the string "null" instead. This matches the behavior in Qwen3CoderDetector and
ensures proper type handling for string parameters.

* update

---------

Co-authored-by: Qingyang Wu <qywu@research-common-h200-01.cloud.together.ai>
efschu added a commit to efschu/htsglang that referenced this pull request Aug 16, 2026
…th collective

sgl-project#517 named five BAR1 broadcasts on the HOST path per NEXTN decode round.
Verified against the current tree, that inventory is now THREE, not five:
the three verify-result syncs were fused into one by pack_accept_payload
(#616c). The remaining two are the draft-pick sync in
_draft_extend_for_decode, which capture_safe_tp_broadcast still issues one
collective PER tensor from its loop.

This fuses that pair into one buffer. The picks have mixed dtypes
(topk_index integer, topk_p float32 at the SAME shape), so unlike the
int32 accept payload the fusion is byte-level. Contiguity is required
rather than coerced: reshape(-1) on a non-contiguous tensor returns a
copy, so an in-place unpack through it would silently drop the broadcast.

fuse is opt-in per call site and defaults OFF. _broadcast_draft_picks is
also called from inside the draft CUDA-graph capture (draft_forward), and
enabling fusion globally would change what a captured region allocates --
a capture change. Only the site that is both per-decode-round and outside
any captured region opts in; the prefill, catchup and in-loop sites stay
byte-identical.

Not claimed here: a ms/round figure. sgl-project#476's 6.64 pp Seam A cost was
measured with the pre-sgl-project#517 guard, which synchronised once per collective;
sgl-project#517 removed that sync, so the per-collective price must be re-measured on
metal rather than carried over. The A/B is window-gated.

Tests: test_draft_pick_fusion_524.py, 7 passed (red first: the three
symbols did not exist). Regression over test/registered/unit/debug
-k "616 or spec_util or draft_pick or eagle or broadcast": 351 passed,
4 failed. Those 4 are pre-existing and unrelated -- verified by reverting
both source files and re-running: test_barlink_bar1_abort_poll_616f.py
fails identically on the clean tree (SimpleNamespace missing _round_dev,
a sgl-project#624-class stub drift). ruff check clean on both changed files (the one
F401 in eagle_worker_v2.py is pre-existing on HEAD); ruff format applied.
efschu added a commit to efschu/htsglang that referenced this pull request Aug 16, 2026
… dry run, and the vouch

The notes were written at 3c984ad and had gone stale in three ways.

Chain: 18 commits at e21e87f -> 22 at 5939d0e. Added sgl-project#697
(8fb86ef), sgl-project#441 (5e0fa1e), sgl-project#524 (5939d0e) and the revision-1 docs
commit. Runtime-touching is now 8 of 22, and sgl-project#441 is recorded as NOT runtime
despite its ticket -- it adds a handover script and one test guard.

Target: integration/r2 has moved a73a0d8 -> a157bf1, so the dry run was
re-run rather than carried over. Still zero conflicts. Scope shrank with the
target's advance: 115 -> 109 commits, 129 -> 124 files, +22731 -> +22196.
Merged-tree tests: managers 2093 passed / 0 failed; planner plus the three new
test files 2594 passed / 2 failed. Those 2 are PpWithSpecEvidenceTest in
test_rejected_evidence_pins.py and were re-verified as pre-existing by
aborting the merge and running that file on clean a157bf1 -- same 2 failed,
2 passed. The chain introduces no new failure. Because the target tip moved,
this was re-checked instead of quoting revision 1's finding.

Holds: sgl-project#690 (e21e87f) and sgl-project#697 (8fb86ef) are in F4-r4's bundle, so
revision 1's objection to landing sgl-project#690 ahead of the sgl-project#694 soak is spent; both
lift to group 1 on his boot commit. sgl-project#524 (5939d0e) joins the hold list --
desk-verified only, never on metal, A/B window-gated. sgl-project#685 (5301b94) stays
held on the unmade R' decision.

Vouch (new section 5): the four F4-r4 cherry-picks are byte-identical to the
originals by git patch-id --stable -- f630947/c41645c8c9,
7c58aba/ce6035884d, f1f31d2/658ea3ac11, de92bb6/84b0171fa6 -- so
preferring the originals is free and the only real risk is double attribution.
1073702 is excluded: patch-id 8595e66885ac matches nothing here, it is
diagnostic scaffolding and not mine to vouch for.

Section 6 records that 5af1531 (sgl-project#696) and c738ef5 (sgl-project#689) are F4-r4's
line, not this branch, and are listed only because they lift holds; sgl-project#696 is
what was DoSing the lanes.

Docs only. No merge performed; the dry-run worktree was removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants