最近，知名 YouTuber PewDiePie 开源了一个叫做 Odysseus AI 的自托管 AI 工作空间项目，在海外社区引发了不小的关注。作为一个长期关注本地 AI 部署的人，我花了一下午时间研究了一番，写下这篇分享。 Odysseus AI 是什么？ 首先要澄清一个最常见的误解： Odysseus AI 不是一个新的 AI 模型 ，而是一个运行在你自己机器上的 AI 工作台（ workspace ）。用一个比喻来说，它是"驾驶舱"，而不是"发动机"——它本身不提供任何大模型权重，而是通过统一界面对接你选择的模型后端，例如 Ollama 、llama.cpp 、vLLM ，或者 OpenAI 、OpenRouter 等云端 API 。 根据 odysseusai.site 上的介绍，它集成了以下能力： 多轮对话 Chat 自主 Agent （可执行多步任务） 深度研究（ Deep Research ） 邮件与日历工具 本地模型服务管理 所有数据留在本地 ，无遥测，完全私有化部署。 安装上手 官方代码托管在 GitHub 的 pewdiepie-archdaemon/odysseus 仓库，安装流程非常简洁。以 Linux/macOS 为例： git clone https://github.com/pewdiepie-archdaemon/odysseus.git cd odysseus ./start.sh Windows 用户则运行： powershell -ExecutionPolicy Bypass -File .\launch-windows.ps1 启动后，服务默认跑在 http://localhost:7000 （ macOS 默认为 :7860 ），终端会打印一个临时 admin 密码，登录后即可使用。整个过程在干净机器上大约 10–15 分钟。 几个常见坑 安装过程中有四类典型问题值得提前了解： 1. 端口被占用 ：macOS 上的 AirPlay 会默认占用 7000 端口，可以改用 ./ start-macos.sh ，它会自动走 7860 。 2. Docker 内无法连接 Ollama ：容器内的 localhost 指向容器本身而非宿主机，需要将 Ollama 地址改为 http://host.docker.internal:11434/v1 。 3. 忘记初始密码 ：密码只在首次启动时打印一次，如果没来得及复制，可以删除 data/auth.json 并重启，系统会重新生成。 4. 模型下拉框为空 ：Odysseus AI 不内置模型，需要先安装 Ollama 并拉取一个模型，例如： ollama pull llama3.2:3b 横向对比 目前自托管 AI 工作台赛道的几个主要选手： 工具 部署方式 亮点 短板 Odysseus AI 自托管 Chat + Agent + 邮件 + 研究 一体化 项目较新，生态尚不成熟 Open WebUI 自托管 成熟的 Ollama 前端，RAG 强 以 Chat 为主，Agent 功能弱 Jan AI 桌面应用 非技术用户最易上手 单机桌面，不适合多人部署 LibreChat 自托管 多 Provider 支持，权限管理完善 Agent 工具链相对薄弱 ChatGPT/Claude 云端 极致体验，无需维护 数据上传云端，无法完全私有化 安全提示 有一点值得特别强调： 不要把 Odysseus AI 直接暴露在公网上 。它本质上是一个拥有 Shell 访问、文件上传、模型下载和 API 密钥存储能力的管理后台，绝非设计给匿名公开访问的。如果有远程访问需求，建议配合 Tailscale 或 Cloudflare Access 做私有隧道，或在 Nginx 后面加上 HTTPS + 认证层。 小结 Odysseus AI 代表了一类"本地优先、隐私优先"的 AI 工作台新思路。对于关注数据主权、希望把 AI 能力完整跑在自己硬件上的用户来说，值得关注和尝试。当然作为一个新项目，它的生态和稳定性还需要时间打磨，建议保持对官方仓库的关注。 参考资料： odysseusai.site
昨天玩了下站内佬的虚拟伴侣项目，成功跑起来了： github.com GitHub - Open-LLM-VTuber/Open-LLM-VTuber: Talk to any LLM with hands-free voice interaction,... Talk to any LLM with hands-free voice interaction, voice interruption, and Live2D taking face running locally across platforms 现在想搞个声音克隆，让ai回答的时候文字转成克隆的tts； 在站内查了下，相关的帖子大多都是半年前一年前的了。。。 大概查到这些： GitHub - RVC-Boss/GPT-SoVITS: 1 min voice data can also be used to train a good TTS model! (few shot voice cloning) · GitHub GitHub - index-tts/index-tts: An Industrial-Level Controllable and Efficient Zero-Shot Text-To-Speech System · GitHub VoxCPM/README_zh.md at main · OpenBMB/VoxCPM · GitHub 声音复刻简介_声音复刻购买指南_声音复刻操作指南-腾讯云 音色快速复刻 - MiniMax 开放平台文档中心 我是更倾向于调api的方式（怕电脑跑不动），目前想着用minimax，但好像挺昂贵啊 佬们有没有其他或者做成了的方案捏？ 6 个帖子 - 6 位参与者 阅读完整话题
IT之家 6 月 4 日消息，在新任总裁吉尔 · 黑泽尔贝克的主导下，Uber 正对人力资源部门裁员 23%，以此精简运营架构。 首席执行官达拉 · 科斯罗萨西在一份内部备忘录中表示：“此番调整势在必行，目的是最大限度提升人力团队效率，充分释放公司未来巨大的发展潜力。” 此次裁员波及招聘及各类人力资源岗位。Uber 并未公布具体裁员人数，但这家网约车巨头的发言人透露，本次被裁人员占其 3.4 万名全体员工总数的远不足 1%。 上月刚升任总裁兼首席企业事务官的黑泽尔贝克在发给受影响团队的通知中称，本轮裁员旨在打造“协同性更强、现代化程度更高、运营表现更优异的组织体系”。 她补充说道，部分业务板块现已变得“架构繁杂、职能分散，存在职责重叠、权属不明的问题，相关团队和其所服务的业务线、合作方脱节严重”。 如今越来越多企业开启裁员，Uber 也加入这一行列，不少企业将人工智能能够实现工作自动化、提效降本作为裁员理由。 不过这家兼具外卖配送与网约车业务的企业表示，本次裁员和人工智能无关。 Uber 于本周证实，已针对员工使用的 AI 智能体工具设置分级消费限额。公司称，基础档位月额度为 1500 美元（IT之家注：现汇率约合 10168 元人民币），更高档位限额在此基础上逐级上调。 据《The Information》早前报道，Uber 首席技术官此前透露，公司仅用四个月就耗尽了 2026 年度人工智能项目全部预算。 Uber 发言人在致 CNBC 的邮件中表示，上述额度属于针对智能体、编程类技术设置的柔性限额，各类工具均单独划定预算。发言人写道：“数月以来，我们已对部分智能体工具实行分级花销管控。”
IT之家 6 月 3 日消息，人工智能使用成本日渐走高，部分企业开始缩减相关用量以控制开支，Uber 就在其中。为削减高昂的人工智能开销，该公司近期出台了内部使用限额制度。 据彭博社消息，Uber 落地新规：员工使用各类智能体编程工具（Anthropic 的 Claude Code 或 Cursor）时，单人单工具每月消费上限为 1500 美元（IT之家注：现汇率约合 10171 元人民币）。公司表示，每位员工均可通过内部数据面板查看用量数据；特殊场景下，经审批能够突破限额。 这一消息并不算出人意料。据《The Information》此前报道，Uber 曾鼓励员工“尽可能多用人工智能”，还在内部榜单比拼全员 AI 使用量。受该举措影响，这家网约车巨头的首席技术官早在今年 4 月就透露，公司全年人工智能预算仅四个月就已耗尽。 Uber 首席运营官安德鲁 · 麦克唐纳近期也对人工智能的实际增效效果提出质疑，他在一档播客节目中坦言，很难厘清 AI 应用和新品功能落地之间的实际关联。 Uber 缩减 AI 投入，折射出整个科技行业共同面临的难题：各大企业持续重金投入人工智能，但投资回报究竟在哪？现阶段，人工智能的投资回报率大多仍停留在理论层面，企业都在期盼收益落地，不少公司在漫长等待中已然失去耐心。
IT之家 6 月 1 日消息，优步（Uber）今天宣布与 Autobrains 公司建立战略合作伙伴关系，共同推进德国慕尼黑自动驾驶出租车服务。 据悉，本次合作计划不仅整合了优步的网约车平台，还结合了英伟达的 Hyperion 平台，旨在实现商业化自动驾驶出行解决方案。 根据计划，优步将在德国慕尼黑试点自动驾驶出租车计划，并在获得监管机构批准后， 采用无 OEM 限制的模式 ， 让不同车辆平台也能够扩充服务 。 IT之家注：Autobrains 是一家位于以色列的 AI 出行公司，提供高级辅助驾驶（ADAS）、完全自动驾驶解决方案。战略投资者包括 BMW i Ventures、VinFast、Continental AG、Knorr-Bremse AG 等。
我尝试搜索很多年以前看过的一个youtuber，因为太久远了，我只能大概说一个人物肖像的描述，问gpt意料之中啥也没搜到。结果用谷歌的ai搜索直接精准定位，震撼！ 另外，注意右侧的帖子是19年的，豆包已经找不到这个帖子了，网页快照会保留这么多年吗？ 7 个帖子 - 6 位参与者 阅读完整话题
最近在看 Kubernetes 上 AI 推理服务的冷启动问题，发现很多时候慢的不只是模型加载，容器镜像本身也很夸张。 比如 vLLM 这类镜像，里面有 PyTorch 、CUDA 、Python 依赖、系统库，动不动就是 10GB+。传统 containerd / overlayfs 路径下，节点要先完整下载并解压镜像，Pod 才能真正起来。对 Karpenter 这种弹性扩容场景来说，这部分时间会很明显。 我们做了一个小项目 Hermes： https://github.com/cloudpilot-ai/hermes 想法是：不让业务团队改 Dockerfile 、不重建镜像、不改 CI/CD ，也不改原来的 image reference 。平台侧定义一个 HermesPolicy ，controller 在集群内自动为匹配到的镜像构建并缓存 SOCI index ，节点上的 daemon 再用这些 index 做 lazy loading 。 这次用 EKS + Karpenter 跑了一个简单对比，镜像是： 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 大概 10.8GB 。 普通节点上，从 Pod 调度到节点后，到容器 Running/Ready： 5m04s - 29s = 4m35s 开启 Hermes 的节点上，在 HermesPolicy 已经 Ready 、SOCI artifact 已经构建好的前提下： 44s - 30s = 14s 也就是这个场景里，镜像拉取/挂载到容器启动这段，从 4m35s 降到了 14s 。 需要强调一下：这个结果不包含首次 index 构建耗时，也不等于 vLLM first token latency 。Pod Ready 变快，只说明容器镜像这条路径被 lazy loading 优化了。后面还需要继续测 vLLM readiness 、first request TTFT 、warmup 后真实请求延迟。 Hermes 现在的定位更像一个集群侧能力：应用继续发原来的 OCI image ，平台通过策略决定哪些镜像需要被 lazy load 。类似： apiVersion: hermes.cloudpilot.ai/v1alpha1 kind: HermesPolicy metadata: name: prod-large-images spec: paused: false imageSelectors: - imageRegex: ".*vllm.*" platforms: - linux/amd64 目前还比较早期，欢迎大家关注项目： https://github.com/cloudpilot-ai/hermes
最近在看 Kubernetes 上 AI 推理服务的冷启动问题，发现很多时候慢的不只是模型加载，容器镜像本身也很夸张。 比如 vLLM 这类镜像，里面有 PyTorch 、CUDA 、Python 依赖、系统库，动不动就是 10GB+。传统 containerd / overlayfs 路径下，节点要先完整下载并解压镜像，Pod 才能真正起来。对 Karpenter 这种弹性扩容场景来说，这部分时间会很明显。 我们做了一个小项目 Hermes： https://github.com/cloudpilot-ai/hermes 想法是：不让业务团队改 Dockerfile 、不重建镜像、不改 CI/CD ，也不改原来的 image reference 。平台侧定义一个 HermesPolicy ，controller 在集群内自动为匹配到的镜像构建并缓存 SOCI index ，节点上的 daemon 再用这些 index 做 lazy loading 。 这次用 EKS + Karpenter 跑了一个简单对比，镜像是： 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 大概 10.8GB 。 普通节点上，从 Pod 调度到节点后，到容器 Running/Ready： 5m04s - 29s = 4m35s 开启 Hermes 的节点上，在 HermesPolicy 已经 Ready 、SOCI artifact 已经构建好的前提下： 44s - 30s = 14s 也就是这个场景里，镜像拉取/挂载到容器启动这段，从 4m35s 降到了 14s 。 需要强调一下：这个结果不包含首次 index 构建耗时，也不等于 vLLM first token latency 。Pod Ready 变快，只说明容器镜像这条路径被 lazy loading 优化了。后面还需要继续测 vLLM readiness 、first request TTFT 、warmup 后真实请求延迟。 Hermes 现在的定位更像一个集群侧能力：应用继续发原来的 OCI image ，平台通过策略决定哪些镜像需要被 lazy load 。类似： apiVersion: hermes.cloudpilot.ai/v1alpha1 kind: HermesPolicy metadata: name: prod-large-images spec: paused: false imageSelectors: - imageRegex: ".*vllm.*" platforms: - linux/amd64 目前还比较早期，欢迎大家关注项目： https://github.com/cloudpilot-ai/hermes
最近在看 Kubernetes 上 AI 推理服务的冷启动问题，发现很多时候慢的不只是模型加载，容器镜像本身也很夸张。 比如 vLLM 这类镜像，里面有 PyTorch 、CUDA 、Python 依赖、系统库，动不动就是 10GB+。传统 containerd / overlayfs 路径下，节点要先完整下载并解压镜像，Pod 才能真正起来。对 Karpenter 这种弹性扩容场景来说，这部分时间会很明显。 我们做了一个小项目 Hermes： https://github.com/cloudpilot-ai/hermes 想法是：不让业务团队改 Dockerfile 、不重建镜像、不改 CI/CD ，也不改原来的 image reference 。平台侧定义一个 HermesPolicy ，controller 在集群内自动为匹配到的镜像构建并缓存 SOCI index ，节点上的 daemon 再用这些 index 做 lazy loading 。 这次用 EKS + Karpenter 跑了一个简单对比，镜像是： 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 大概 10.8GB 。 普通节点上，从 Pod 调度到节点后，到容器 Running/Ready： 5m04s - 29s = 4m35s 开启 Hermes 的节点上，在 HermesPolicy 已经 Ready 、SOCI artifact 已经构建好的前提下： 44s - 30s = 14s 也就是这个场景里，镜像拉取/挂载到容器启动这段，从 4m35s 降到了 14s 。 需要强调一下：这个结果不包含首次 index 构建耗时，也不等于 vLLM first token latency 。Pod Ready 变快，只说明容器镜像这条路径被 lazy loading 优化了。后面还需要继续测 vLLM readiness 、first request TTFT 、warmup 后真实请求延迟。 Hermes 现在的定位更像一个集群侧能力：应用继续发原来的 OCI image ，平台通过策略决定哪些镜像需要被 lazy load 。类似： apiVersion: hermes.cloudpilot.ai/v1alpha1 kind: HermesPolicy metadata: name: prod-large-images spec: paused: false imageSelectors: - imageRegex: ".*vllm.*" platforms: - linux/amd64 目前还比较早期，欢迎大家关注项目： https://github.com/cloudpilot-ai/hermes
IT之家 5 月 27 日消息，据外媒《商业内幕》27 日（今天）下午报道，一名 Waymo 自动驾驶出租车乘客萨姆 · 施瓦茨反映称，本月早些时候，他和妻子在旧金山市中心乘坐 Waymo 出租车时，距离酒店只剩大约 0.48 公里时，车辆却突然停下，并拒绝继续前进。 施瓦茨随后联系 Waymo 客服，试图弄清原因。然而客服人员表示， 前方存在“巨大阻塞”，车辆无法继续驶向酒店 。随后，对方却建议：“你们可以重新叫车，比方说 可以选 Uber 或者 Lyft 。” 施瓦茨直言：“正如我儿子说的，这简直是在给 Uber 做广告。” Waymo 发言人则表示，车辆停下的原因，是运营团队获知 当地存在“计划中的抗议活动”后 ，对车辆设置了限制措施。不过，Waymo 并未说明具体抗议活动的细节。当车辆无法抵达乘客目的地时，公司会建议用户改用其他交通方式。“除了退款之外，我们也正在进一步调查此事，看看未来是否能够在类似情况下为乘客提供更好的服务。” 施瓦茨的经历，也反映出 Waymo 自动驾驶出租车在美国快速扩张过程中，仍然存在一些问题。据IT之家了解，本月至少已有 两起 Waymo 车辆误驶入积水区域 的事件。随后，Waymo 发布软件召回，并暂停亚特兰大和圣安东尼奥等 6 座城市的服务。另外，Waymo 目前也 暂停了高速公路载客服务 ，以改善车辆在施工区域附近的表现。 最终，施瓦茨和妻子只能步行返回酒店。不过施瓦茨表示，自己的妻子存在残障情况，长距离步行并不方便。Waymo 之后 退还了此次车费 。 施瓦茨表示，自己这次专门前往旧金山， 很大原因就是想体验 Waymo 自动驾驶汽车 。施瓦茨本人是一名作家，曾于 2018 年出版自动驾驶题材书籍《No One at the Wheel》，目前还正在创作一部与自动驾驶相关的小说。 在其看来，Waymo 带来的体验依然令人印象深刻。在同一次旧金山之行中的另一段乘车过程中，Waymo 车辆曾 非常流畅地绕过另一辆自动驾驶汽车 ，两车距离仅有几厘米，但车辆始终没有像人类司机那样出现犹豫。“Waymo 的动作精确得惊人。我对这项技术印象深刻。” 不过，前往酒店时那次“半路撂挑子”的经历，也让施瓦茨开始怀疑 Waymo 未来在其他城市推广服务的能力。相比旧金山，曼哈顿和布鲁克林市中心等地区的人口密度与交通复杂程度还要高得多。“如果连这种情况都处理不了，那 Waymo 根本不可能在纽约生存下去。”
IT之家 5 月 26 日消息，据报道，Uber 在 2026 年仅过去四个月就耗尽了全年人工智能预算，如今该公司开始质疑这笔投入是否真正产生了实质回报。Uber 总裁兼首席运营官安德鲁 · 麦克唐纳在接受 Rapid Response 采访时表示，公司并未发现 Claude Code 的词元（token）使用量激增，与面向用户推出更实用功能之间存在关联。 麦克唐纳称：“目前二者还看不出关联，对吧？我能感觉到上线的产品功能或许变多了，但很难把这类数据和‘我们如今面向用户推出的实用功能提升了 25%’直接划上等号。即便部分底层数据正呈爆发式增长，现阶段也依旧难以证实其中的联系。我相信在未来几个季度乃至数年里，这一问题或许会逐渐明朗。” 2025 年，Uber 研发投入达 34 亿美元（IT之家注：现汇率约合 231.13 亿元人民币），较上一年增长 9%。本月早些时候，Uber 首席执行官达拉 · 霍斯劳沙希表示，公司正通过缩减人员招聘规模，来承担不断增加的人工智能相关投入。 麦克唐纳说道：“我们不得不开始权衡词元使用量、相关成本与人员编制三者的关系。如果无法明确证明投入能转化为向用户交付的实用功能与服务，那么这种权衡就更难证明其合理性。”
Uber Technologies Inc．已提议收购德国外卖配送公司Delivery Hero SE，交易对后者的估值约为100亿欧元（116亿美元）。Uber正寻求加大与DoorDash Inc．在美国以外市场的竞争。 总部位于柏林的Delivery Hero周六在公告中表示，已收到Uber提出的每股33欧元的收购报价，“公司仍将全力执行战略评估流程”。这一报价略高于Delivery Hero上周四的收盘价。 根据条款，持有Delivery Hero 20%股份的Uber将需要支付约80亿欧元。这家美国公司上周一披露，它还拥有另外5.6%股份的期权。 在股东的压力下，Delivery Hero一直在对其资产进行战略评估。受增长放缓和激烈竞争的影响，全球食品配送行业正在整合，Delivery Hero在欧洲的多家同行已成为整合目标。美国餐饮配送市场的领军企业DoorDash去年同意收购英国的Deliveroo Plc。几个月前，Prosus宣布收购荷兰Just Eat Takeaway.com NV的计划。 查看评论
Elden Linux / Kubernetes / Network Troubleshooting / Cloud / DevOps Engineer 邮箱： [email protected] 语言：粤语（母语）｜普通话（母语）｜英语（流利） 个人简介 具备 Linux 生产环境运维与稳定性保障经验，长期负责电商系统、Web 架构、云端服务与 Kubernetes 集群的故障排查、性能优化与日常运维。 擅长在生产环境中快速定位问题根因，能从网络、进程、线程、系统调用与应用逻辑多层协同分析，处理延迟、卡顿、连接堆积与资源瓶颈等问题。 独立维护过 1 个 8 节点 Kubernetes 集群，并完成 WordPress / WooCommerce 、阿里云 OSS 、CDN 、WebP 、SSL 、缓存与 SEO 等全案优化，直接改善网站访问速度与运维成本。 持有 CKA 与 CCNA ，具备云端迁移、容器化、网络排障与运维自动化能力，适合 Linux Infra 、DevOps 、Cloud Ops 、Platform 类岗位。 核心能力 生产排障与根因分析：能沿着“流量 → socket → 进程 → 线程 → 系统调用 → 应用行为”链路定位问题，不停留在表面现象。 Linux 网络与性能观测：擅长判断网卡、softirq 、socket backlog 、连接状态与进程资源归属，区分网络、内核、进程与应用问题。 多线程进程分析：能用进程与线程视角找出真正消耗资源的工作单元，分析锁等待、I/O 阻塞与 epoll 行为。 Kubernetes 与入口流量：理解 Ingress Nginx 、路由、TLS 与负载均衡，能处理集群入口与上游服务问题。 Web 性能优化：能独立完成 WordPress / WooCommerce 的静态资源、图片分发、缓存与 SSL 优化。 云平台与自动化：熟悉阿里云 ECS / RDS / OSS 、Shell / Python 自动化、GitHub Actions 、Docker 与基础 CI/CD 。
Elden Linux / Kubernetes / Network Troubleshooting / Cloud / DevOps Engineer 电话：+86 18023186848 邮箱： [email protected] 语言：粤语（母语）｜普通话（母语）｜英语（流利） 个人简介 具备 8 年 Linux 生产环境运维与稳定性保障经验，长期负责电商系统、Web 架构、云端服务与 Kubernetes 集群的故障排查、性能优化与日常运维。 擅长在生产环境中快速定位问题根因，能从网络、进程、线程、系统调用与应用逻辑多层协同分析，处理延迟、卡顿、连接堆积与资源瓶颈等问题。 独立维护过 1 个 8 节点 Kubernetes 集群，并完成 WordPress / WooCommerce 、阿里云 OSS 、CDN 、WebP 、SSL 、缓存与 SEO 等全案优化，直接改善网站访问速度与运维成本。 持有 CKA 与 CCNA ，具备云端迁移、容器化、网络排障与运维自动化能力，适合 Linux Infra 、DevOps 、Cloud Ops 、Platform 类岗位。 核心能力 生产排障与根因分析：能沿着“流量 → socket → 进程 → 线程 → 系统调用 → 应用行为”链路定位问题，不停留在表面现象。 Linux 网络与性能观测：擅长判断网卡、softirq 、socket backlog 、连接状态与进程资源归属，区分网络、内核、进程与应用问题。 多线程进程分析：能用进程与线程视角找出真正消耗资源的工作单元，分析锁等待、I/O 阻塞与 epoll 行为。 Kubernetes 与入口流量：理解 Ingress Nginx 、路由、TLS 与负载均衡，能处理集群入口与上游服务问题。 Web 性能优化：能独立完成 WordPress / WooCommerce 的静态资源、图片分发、缓存与 SSL 优化。 云平台与自动化：熟悉阿里云 ECS / RDS / OSS 、Shell / Python 自动化、GitHub Actions 、Docker 与基础 CI/CD 。
最近折腾了一个小工具，名字叫：kop 它是一个运行在终端里的 Kubernetes TUI （ Terminal UI ）工具，可以理解成「终端版 Kubernetes 管理面板」。 灵感最早来自于 lens，但在实际使用过程中，我发现很多场景下我想要的是： 更轻量 更直观 更适合 DevOps/SRE 日常排障 在没有桌面环境的终端中运行 于是就自己开始写了 kop 。整体风格类似 lens ，但是 UI 在终端中呈现,可使用鼠标点击操作 目前已经支持的功能 资源管理 查看资源列表 查看资源详细信息 资源的增删改查 查看 pod logs 进入 pod 终端 pod/service 端口转发 .... kop 已经实现了大部分和 lens 相同的功能 为什么不用 Web UI 和桌面客户端？ kop 主要解决在没有桌面环境和私有化场景下的 k8s 运维工作，web 和桌面客户端在某些场景下可能不适用。 这些环境里： Terminal UI 的效率其实非常高。 尤其是： 不依赖浏览器 不依赖鼠标 不占太多资源 SSH 环境直接可用 项目地址 GitHub： kop Github 文档： kop Docs 如果你平时也经常： kubectl Kubernetes 运维 云原生开发 DevOps/SRE 喜欢 Terminal UI 欢迎体验一下，目前正在持续优化中，也欢迎提建议。 🚀
最近折腾了一个小工具，名字叫：kop 它是一个运行在终端里的 Kubernetes TUI （ Terminal UI ）工具，可以理解成「终端版 Kubernetes 管理面板」。 灵感最早来自于 lens，但在实际使用过程中，我发现很多场景下我想要的是： 更轻量 更直观 更适合 DevOps/SRE 日常排障 在没有桌面环境的终端中运行 于是就自己开始写了 kop 。整体风格类似 lens ，但是 UI 在终端中呈现,可使用鼠标点击操作 目前已经支持的功能 资源管理 查看资源列表 查看资源详细信息 资源的增删改查 查看 pod logs 进入 pod 终端 pod/service 端口转发 .... kop 已经实现了大部分和 lens 相同的功能 为什么不用 Web UI 和桌面客户端？ kop 主要解决在没有桌面环境和私有化场景下的 k8s 运维工作，web 和桌面客户端在某些场景下可能不适用。 这些环境里： Terminal UI 的效率其实非常高。 尤其是： 不依赖浏览器 不依赖鼠标 不占太多资源 SSH 环境直接可用 项目地址 GitHub： kop Github 文档： kop Docs 如果你平时也经常： kubectl Kubernetes 运维 云原生开发 DevOps/SRE 喜欢 Terminal UI 欢迎体验一下，目前正在持续优化中，也欢迎提建议。 🚀
最近折腾了一个小工具，名字叫：kop 它是一个运行在终端里的 Kubernetes TUI （ Terminal UI ）工具，可以理解成「终端版 Kubernetes 管理面板」。 灵感最早来自于 lens，但在实际使用过程中，我发现很多场景下我想要的是： 更轻量 更直观 更适合 DevOps/SRE 日常排障 在没有桌面环境的终端中运行 于是就自己开始写了 kop 。整体风格类似 lens ，但是 UI 在终端中呈现,可使用鼠标点击操作 目前已经支持的功能 资源管理 查看资源列表 查看资源详细信息 资源的增删改查 查看 pod logs 进入 pod 终端 pod/service 端口转发 .... kop 已经实现了大部分和 lens 相同的功能 为什么不用 Web UI 和桌面客户端？ kop 主要解决在没有桌面环境和私有化场景下的 k8s 运维工作，web 和桌面客户端在某些场景下可能不适用。 这些环境里： Terminal UI 的效率其实非常高。 尤其是： 不依赖浏览器 不依赖鼠标 不占太多资源 SSH 环境直接可用 项目地址 GitHub： kop Github 文档： kop Docs 如果你平时也经常： kubectl Kubernetes 运维 云原生开发 DevOps/SRE 喜欢 Terminal UI 欢迎体验一下，目前正在持续优化中，也欢迎提建议。 🚀
最近折腾了一个小工具，名字叫：kop 它是一个运行在终端里的 Kubernetes TUI （ Terminal UI ）工具，可以理解成「终端版 Kubernetes 管理面板」。 灵感最早来自于 lens，但在实际使用过程中，我发现很多场景下我想要的是： 更轻量 更直观 更适合 DevOps/SRE 日常排障 在没有桌面环境的终端中运行 于是就自己开始写了 kop 。整体风格类似 lens ，但是 UI 在终端中呈现,可使用鼠标点击操作 目前已经支持的功能 资源管理 查看资源列表 查看资源详细信息 资源的增删改查 查看 pod logs 进入 pod 终端 pod/service 端口转发 .... kop 已经实现了大部分和 lens 相同的功能 为什么不用 Web UI 和桌面客户端？ kop 主要解决在没有桌面环境和私有化场景下的 k8s 运维工作，web 和桌面客户端在某些场景下可能不适用。 这些环境里： Terminal UI 的效率其实非常高。 尤其是： 不依赖浏览器 不依赖鼠标 不占太多资源 SSH 环境直接可用 项目地址 GitHub： kop Github 文档： kop Docs 如果你平时也经常： kubectl Kubernetes 运维 云原生开发 DevOps/SRE 喜欢 Terminal UI 欢迎体验一下，目前正在持续优化中，也欢迎提建议。 🚀
IT之家 5 月 7 日消息，Uber（优步）今日发布 2026 财年（2026 年 1 月～2026 年 12 月）第一财季报告： 营业总收入 ： 132.03 亿美元，同比增长 14%（按固定汇率计算增长 10%） 归母净利润 ： 2.63 亿美元，同比下降 85% 经营现金流 ： 23.51 亿美元，同比增长 1% 稀释每股收益 ：0.13 美元 / 股，同比下降 85% Uber 首席执行官 Dara Khosrowshahi 表示： 正如我们在 GO-GET 大会上所强调的，从创新的出行整合到全新的购物方式，我们正持续深化 Uber 在日常生活中的作用。 Uber One 会员数量达到 5000 万是一个令人振奋的里程碑，这标志着我们在执行平台战略方面取得了进展，目前会员贡献了出行和配送业务总预订额的一半。 🤖 AI 解读 优步 2026 财年第一财季整体表现亮眼，核心业务规模持续扩张。 总订单金额（Gross Bookings） 同比增长 25% 至 537.20 亿美元，按固定汇率计算增长 21%，已连续三个季度增长超过 21%； 营业收入 同比增长 14% 至 132.03 亿美元，按固定汇率计算增长 10%。 用户规模和订单量同步增长， 月度活跃平台消费者（MAPCs） 同比增长 17% 至 1.99 亿，订单量同比增长 20% 至 36.43 亿单。分业务来看，出行板块（Mobility）订单金额同比增长 25% 至 263.94 亿美元，营收同比增长 5% 至 67.98 亿美元；配送板块（Delivery）订单金额同比增长 28% 至 259.92 亿美元，营收同比增长 34% 至 50.68 亿美元，成为营收增长的重要动力。 盈利方面，受股权投资估值调整带来的 15 亿美元税前净损失影响， GAAP 归属于优步股东的净利润 为 2.63 亿美元，同比下降 85%；但非 GAAP 表现亮眼， 非 GAAP 营业收入 同比增长 42% 至 18.83 亿美元， 非 GAAP 净利润 同比增长 39% 至 14.93 亿美元， 非 GAAP 摊薄每股收益 同比增长 44% 至 0.72 美元。经营活动产生的现金流量净额为 23.51 亿美元，自由现金流为 22.86 亿美元，保持了良好的现金生成能力。 风险提示：本文内容由 AI 自动分析生成，仅供参考，不代表IT之家观点。如有出入请以证监会指定上市公司信息披露平台为准。本文内容不构成投资建议，如有投资者据此操作，风险自担，IT之家对此不承担任何责任。
在结束自建自动驾驶项目多年之后，Uber 正试图以另一种方式重返无人车版图：把全球数百万名网约车司机的车辆，改造成为自动驾驶公司和其他实体世界 AI 模型提供数据的移动“传感器阵列”。 Uber 首席技术官 Praveen Neppalli Naga 在接受采访时披露了这一长期构想，并将其描述为公司今年 1 月底宣布的新项目 AV Labs 的“自然延伸”。 他表示，Uber 的最终方向，是在不远的将来给人类司机的私家车加装各类传感器，用于采集真实道路场景数据。Naga 同时强调，在迈向这一步之前，公司需要先彻底弄清不同传感器套件的能力与工作方式，并等待美国各州在“什么是传感器、如何共享数据”上给出更明确的监管指引。 目前，AV Labs 仍运行在一支规模有限的专用车队之上，这些车辆配备传感器，由 Uber 自行运营，与日常接单的司机群体相互独立。 但从 Uber 的叙述可以看出，这只是一个起点：Uber 在全球拥有数以百万计的司机，即便只有一小部分车辆安装了传感器，也足以构建起一张任何单一自动驾驶公司都难以匹敌的道路数据采集网。Naga 认为，如今制约自动驾驶技术演进的瓶颈已经不在底层算法或算力，而是高质量、足够多样的真实世界数据。“瓶颈是数据，”他说，“像 Waymo 这样的公司需要不断出去采集数据，覆盖不同的场景。” 在他的设想中，自动驾驶企业可以通过 Uber 的网络，按需订制极为精细的训练数据，比如提出“在旧金山某所学校门口的路口，在某个特定时间段采集交通情况，以训练模型”的需求。 真正的问题在于，绝大多数自动驾驶公司并没有充足的资本在全球大规模铺设自有车队，去高密度覆盖这些长尾场景。Uber 如果能调动已有的司机和车辆资源，就有望成为整个行业的数据供给层，为自动驾驶技术提供源源不断的“燃料”。 外界曾长期质疑，在放弃自建无人车后，Uber 是否会在未来被自动驾驶公司“绕开”，甚至在出行生态中被边缘化。 联合创始人 Travis Kalanick 也曾公开表示，放弃自动驾驶是一个“巨大错误”。 如今，通过 AV Labs，Uber 正试图把自己的角色从自动驾驶整车开发者，转变为这一领域的基础设施和数据平台，借助广泛的司机网络和订单流量，为所有参与者提供底层能力。 Uber 目前已经与全球 25 家自动驾驶公司达成合作，其中包括在伦敦运营的 Wayve 等玩家。 在此基础上，公司正在搭建一个所谓“AV 云”：即一个标注完备的多模态传感器数据仓库，合作伙伴可以在其中进行检索和调用，用于训练各自的自动驾驶模型。 Naga 介绍，合作公司还可以在 Uber 平台上对真实订单运行“影子模式”推理——也就是在真实行程数据上模拟自己的自动驾驶系统会如何决策，而无需真正把无人车投放到路面上。 从对外表态来看，Uber 试图将这一平台包装为“行业公共设施”。“我们的目标不是靠这些数据赚钱，”Naga 说，“而是希望把它民主化。” 不过，考虑到优质数据在自动驾驶和更广泛 AI 领域的商业价值以及稀缺性，这样的定位未来能否持续仍存疑问。事实上，Uber 近年已经对多家自动驾驶公司进行了股权投资，而如果其掌握的大规模、差异化训练数据成为合作伙伴核心竞争力的一部分，Uber 在这些公司面前的议价能力很可能进一步加强。 在这套构想背后，Uber 的逻辑正在从“造车”转向“做平台”：一方面，它通过自身的出行和外卖网络，继续维持在终端用户层面的入口优势；另一方面，则尝试把司机车辆的真实行程和场景沉淀为结构化数据资产，为自动驾驶企业乃至其他需要实体世界训练数据的大模型公司服务。 对于一家早已不再亲自做自动驾驶硬件和软件栈的公司而言，这或许是继续参与下一轮交通技术变革、并在其中保持存在感的全新路径。 查看评论