全部动态

本页 40 条
10月13日 周二
SiliconANGLE AI46

Dell’s AI partner ecosystem adapts to Silicon Valley’s build-it-yourself buyers

Silicon Valley’s AI partner ecosystem is changing as enterprises push artificial intelligence projects out of pilots and into production. In the region where much of the AI stack is invented, infrastructure providers are learning that selling to builders takes a different playbook. That shift is reshaping how Dell Technologies Inc. approaches its West Coast customers. […] The post Dell’s AI partner ecosystem adapts to Silicon Valley’s build-it-yourself buyers appeared first on SiliconANGLE .

Simon Willison

Hello Python 3.15, goodbye 3.10, and now I can use 3.11

Python 3.15 is here ! Here's the essential What's new in Python 3.15 guide, this year curated by 3.14 and 3.15 release manager Hugo van Kemenade. As someone who builds open source software that works in every supported Python version, I get to say goodbye to Python 3.10 and start embracing features from Python 3.11. First, some highlights from Python 3.15. Explicit lazy imports I'm most excited about Explicit lazy imports from PEP 810 . These let you import modules like so: lazy import json lazy from pathlib import Path The module will then be imported the first time those symbols are used in the code that follows. My LLM CLI tool implements plugins. I had to recommend manual lazy imports in the plugin author documentation, because simply installing plugins that used heavy dependencies such as sentence_transformers could add multiple seconds to every invocation of the llm command. Lazy imports directly address this startup cost. Unpacking in comprehensions The new [*sublist for sublist in lists] unpacking syntax is neat. Here's an illustration lifted from the documentation : lists = [[ 1 , 2 ], [ 3 , 4 ], [ 5 ]] [ * L for L in lists ] # [1, 2, 3, 4, 5] # equivalent to [x for L in lists for x in L] sets = [{ 1 , 2 }, { 2 , 3 }, { 3 , 4 }] { * s for s in sets } # {1, 2, 3, 4} # equivalent to {x for s in sets for x in s} dicts = [{ 'a' : 1 }, { 'b' : 2 }, { 'a' : 3 }] { ** d for d in dicts } # {'a': 3, 'b': 2} # equivalent to {k: v for d in dicts for k,v in d.items()} PEP 798: Unpacking in Comprehensions by Adam Hartz and Erik Demaine proposed this as an extension of the unpacking syntax from PEP 448 , which landed in Python 3.5 back in 2015. A sampling profiler Python's existing tracing profiler has been renamed from cProfile to profiling.tracing , and has been joined by an exciting new sampling profiler called Tachyon, aka profiling.sampling . Sampling profilers work by periodically capturing stack traces from running processes, then using those to calculate which functions have the most time spent inside of them. They're very low overhead and can provide a deep insight into running systems, without needing to instrument those systems first. I've previously used tools like py-spy for this. Now this capability is baked into the standard library. If you have the PID of an existing Python 3.15 process you can start gathering samples by running this (I had to use sudo on macOS): sudo uv run --python 3.15 python -m profiling.sampling attach 1234 Interact with the main program a bit, then hit Ctrl+C to stop gathering and see a report, which looks something like this: Screenshot of terminal output from a Python sampling profiler with colored text on a black background. Header lines report 2,651 samples captured in 2.65 seconds at a sample rate of 999.98 samples/sec with an error rate of 0.19. A Profile Stats table with columns for nsamples, sample%, tottime, cumul%, cumtime and filename:lineno(function) shows that 99.9% of samples (2.644 seconds) were spent directly in selectors.py KqueueSelector.select, meaning the process was almost entirely idle waiting on the asyncio event loop. The rest of the table lists the call stack beneath it with zero direct time but 100% cumulative presence: asyncio base_events.py run_once, run_forever and run_until_complete, runners.py Runner.run and run, cli.py serve and sqlite_extensions wrapped, and several click core.py invoke, main and call frames. A legend explains each column, followed by a Summary of Interesting Functions section listing hot spots (KqueueSelector.select at 99.9% direct samples), the most frequently present functions on the stack (run_forever, run_until_complete and Runner.run at 100%), and the highest call magnification (2645.0x for BaseEventLoop._run_once). It can also produce flame graphs like this and heat maps like this , and can even output a format that can be viewed in the Firefox profiler UI. 3.15 isn't much faster than 3.14 Miguel Grinberg investigated How fast is Python 3.15? the other day against the 3.15.0rc3 release and found performance to be mostly the same as 3.14, with the exception of the experimental JIT. The JIT gave a 1.2x boost over the standard 3.15 interpreter (on a Fibonacci test), the first time Miguel observed a meaningful JIT performance increase. Miguel's explorations of 3.14 last year found significant boosts against Python 3.13 across many more categories. Upgrading to Python 3.15 with uv I used the following sequence of commands to get uv to use Python 3.15 on my Mac. First I had to upgrade uv itself to ensure it knew about the new release: uv self update Then I installed the stable 3.15 release: uv python install 3.15 And told uv that I wanted that to be the default for every uv run command, unless the project itself pinned a different version: uv python pin --global 3.15 Now the following reports 3.15 as the version: uv run python --version I already have a bunch of tools installed using uv tool install . I reinstalled them to use Python 3.15 like this: uv tool upgrade datasette --python 3.15 Then I can confirm the version like this: datasette --get /-/versions.json | jq Highlights from Python 3.11 The release of 3.15 means that Python 3.10 (released in 2021) is officially no longer supported . My policy for my main open source projects is to keep them working in every supported Python version. I can now drop 3.10 and start using features that were introduced in 3.11. Here's the What's new in Python 3.11 document. I finally get to rely on tomllib being available! Datasette makes extensive use of asyncio . 3.11 adds TaskGroup and timeout() , and several more new features. datetime.UTC is a new in 3.11 alias for datetime.timezone.utc . Python's SQLite support got some significant upgrades in 3.11, including: setlimit() and getlimit() expose a mechanism for setting SQLite runtime limits from Python. create_window_function() lets us create custom window functions in Python, as a class with step() , value() , inverse() , and finalize() methods. blobopen() provides an efficient mechanism for partial reads and writes of large BLOB binary values stored in a SQLite row. You can now call set_authorizer(None) to remove a SQLite authorizer. Datasette had a workaround for this! Plus a whole bunch of improvements to Python's typing system . I plan to land Python 3.11 improvements to a bunch of my projects over the next few weeks. Here's my first Datasette PR removing that set_authorizer(None) workaround. I've also updated my click-app , datasette-plugin , python-lib , and llm-plugin cookiecutter templates to test against Python 3.11 through Python 3.15. Tags: open-source , profiling , python , sqlite , uv

The Decoder69

Sakana AI's self-improving model gets better at solving and judging, but can't catch its own blind spots

Robot stations equipped with conveyor belts sort colorful shapes and assemble them into complex cubes in a closed-loop process. Sakana AI's MASS method lets one language model improve itself by solving tasks, judging results, and refining workflows, reaching a win rate of nearly 70 percent against the base model after two rounds. But when the model misses the same errors across all three roles, it can mistake them for progress and reinforce them during training. The article Sakana AI's self-improving model gets better at solving and judging, but can't catch its own blind spots appeared first on The Decoder .

Hacker News 熱門69

Launch HN：Agent37 (YC F26) – 用于运行智能体的低成本沙箱

大家好，我是 Agent37（https://agent37.com）的 Vishnu。我们构建了用于运行 AI 智能体的沙箱，成本不到大多数沙箱服务商的 10%。我们的客户平均每个沙箱每月只需支付 0.37 美元。你可以在这里观看产品演示视频：https://youtu.be/DK5ISR2tbNo 我们在今年 2 月起步时，是 OpenClaw 封装公司中的一家（没错……大家尽管批评我）。后来，我们逐渐加入了越来越多的运行框架。当时我的目标之一，是为用户提供免费套餐，以获取更多市场份额。但一开始这样做的成本实在太高，尤其是我们当时是自筹资金，服务器费用都靠我的积蓄承担。 如今，得益于此后进行的优化，我们终于能够提供免费套餐了。我们新增注册用户中有超过 90% 选择了免费套餐，他们在我们的云端托管自己的 Hermes、Openclaw、Claude Code 等服务。免费沙箱的基础设施成本平均约为每位用户每月 0.05 至 0.10 美元。 以下是一些帮助我们降低成本的技术： * 观察智能体运行框架时，你会发现它们消耗 CPU 和 RAM 的方式存在某些规律。它们在初始化或执行特定任务时需要突发性的 CPU 资源，但除此之外通常不会持续达到峰值。浏览器和计算机操作等任务需要更多 RAM，而任务完成后，资源使用量通常会回落。降低成本的关键就在于这一点，因此通过高效管理 CPU/RAM 的使用率，我们能够降低成本。 * 其次，租用主机时必须避开超大规模云服务商。我以前在 Amazon 工作过，他们在虚拟机上的利润率高达 80% 至 90%。因此，在查看价格后，我很自然地选择了向下游寻找 Hetzner 和 OVH 这样的供应商。仅这一点，可能就是降低成本最重要的手段之一。 * 第三，你还需要选择一种能够在主机之间高效缓存和共享资源的技术栈。我们使用 gVisor，以实现更高的资源利用率和更快的启动速度。这样，我们就能在多个沙箱之间使用主机上可用的内存，而不必为每个沙箱预留一整台虚拟机的内存。当然，这也存在取舍：我们的 gVisor 沙箱不支持 Docker-in-Docker 或 Android 模拟器等工作负载。 * 最后，你购买的主机的规模和配置也会产生很大影响。就成本而言，瓶颈通常在 RAM，而不是 CPU。对于智能体运行框架工作负载来说尤其如此，因此购买服务器时，我们会优化配置，以便在单台主机中装入更多 RAM。对于有完整虚拟机需求的工作负载，我们也提供完整虚拟机沙箱，包括以略高的价格运行 Docker；不过，综合采用上述其他技术后，它们的成本仍然相当低。 总的来说，我的经验是，只要专注于沙箱使用场景中的某个细分领域，并针对该领域进行优化，就能提供更好的成本与性能平衡。 我之前曾在 Amazon 担任高级软件工程师，并在 Quantcast 担任工程经理。我构建了 Amazon 内部的 AI 聊天机器人 Diya，以及其内部的代码运行框架 Ziya。 如果你想在沙箱中运行智能体，正在寻找沙箱供应商，欢迎来看看我们。我们尤其希望从事消息智能体开发的开发者试用自己的工作负载，挑战我们平台的极限及其经济性。 谢谢！https://agent37.com 评论链接：https://news.ycombinator.com/item?id=50059096 分数：8 评论数：0