Reviewer name and names of any other individual's who aided in reviewer	Boya Ji
Do you understand and agree to our policy of having open and named reviews, and having your review included with the published manuscript. (If no, please inform the editor that you cannot review this manuscript.)	Yes
Is the language of sufficient quality?	Yes
Please add additional comments on language quality to clarify if needed
Is there a clear statement of need explaining what problems the software is designed to solve and who the target audience is?	Yes
Additional Comments
Is the source code available, and has an appropriate Open Source Initiative license <a href="https://opensource.org/licenses" target="_blank">(https://opensource.org/licenses)</a> been assigned to the code?	No
Additional Comments
As Open Source Software are there guidelines on how to contribute, report issues or seek support on the code?	No
Additional Comments
Is the code executable?	Unable to test
Additional Comments
Is installation/deployment sufficiently outlined in the paper and documentation, and does it proceed as outlined?	Unable to test
Additional Comments
Is the documentation provided clear and user friendly?	Yes
Additional Comments
Additional Comments
Is there a clearly-stated list of dependencies, and is the core functionality of the software documented to a satisfactory level?	Yes
Additional Comments
Have any claims of performance been sufficiently tested and compared to other commonly-used packages?	Not applicable
Additional Comments
Additional Comments
Are there (ideally real world) examples demonstrating use of the software?	No
Additional Comments
Additional Comments
Any Additional Overall Comments to the Author	The manuscript addresses an important and practical problem in scalable scRNA-seq data processing. I recommend acceptance after revision： 1，The current comparison uses different hardware settings for the serverless and on-server workflows, which weakens the fairness of the speedup claim. The authors should add a controlled benchmark using the same input, same Piscem-Alevin Fry parameters, same storage type, and clearly matched CPU/thread resources. 2，Since the main advantage of serverless computing is elastic, pay-as-you-go execution, the manuscript should include a cost breakdown for EC2, Lambda, S3 storage, data transfer, and ECR usage. A “cost per GB” or “cost per million reads” metric would make the practical value much clearer. 3，The paper states that count matrices are identical in constrained runs, but it should also compare serverless and non-serverless outputs using cell barcode overlap, gene count correlation, UMI totals, detected genes per cell, and downstream clustering consistency. This would show that acceleration does not alter biological results. 4，The manuscript would benefit from a sensitivity analysis of shard size, Lambda memory, thread number, concurrency limit, S3 transfer time, and merge overhead. This would help readers understand when serverless processing is beneficial and when I/O or orchestration overhead becomes the bottleneck. 5，The Related Work section should cite recent computational biology and multimodal/graph-based biomedical modeling studies to better position the work within modern bioinformatics computing: 10.1016/j.patcog.2025.112078； 10.1038/s41467-026-72882-y； 10.1093/nsr/nwaf495； 10.1186/s13059-025-03606-6
Recommendation	Major Revisions